Le 30/05/2013 18:29, Marc Haber a écrit :
> On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters
> wrote:
>> Seems the solutions are very focussed on the assumption that things
>> cannot be changed. E.g. programs currently send email, so email it has
>> to be forever.
>
> It is not a good idea to dro
On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
> Steve Langasek wrote:
> > I can't speak to other distributions, but in Debian, the systemd maintainers
> > are in no position to decide that Debian will agree to rewrite its
>
> Focusing on "position to decide" seems less than construc
Russ Allbery (30/05/2013):
> Jonas Smedegaard writes:
> > Sorry, what bugreport?
>
> > I do not consider backports.debian.org of same quality as
> > debian.org so am concerned by what you outline above, and would
> > like to (at the least) read up on the relevant discussion
> > (i.e. avoid rehas
PATRICIA HERNANDEZ MARIN
TRANSPORTES ESPECIALIZADOS JEOMARA
229-989-02-11.
--
Patricia del Carmen Hernandez Marin
Transportes Especializados Jeomara SA de CV
Tel: (229)9890211
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact lis
On Thu, May 30, 2013 at 04:04:47PM +0200, Bastien ROUCARIES wrote:
> > Cons:
> >
> > - not all crypto libraries are equivalent; choosing one will exclude
> > some functionality provided by others
>
> SEE compat layer
> > - we somehow have to deal with legacy systems that can't convert
> > - adopti
On Fri, May 31, 2013 at 5:11 AM, Mark Symonds wrote:
> If Upstart makes it into Debian
Upstart is already in Debian.
> Dependency based init already works well, to replace it with a hive of bugs
> does not make sense. OpenRC is the only one which claims to be reverse
> compatible,
> if this is
Package: wnpp
Severity: wishlist
Owner: Micah Anderson
* Package name: python-scrypt
Version : 0.5.3
Upstream Author : Magnus Hallin
* URL : http://bitbucket.org/mhallin/py-scrypt
* License : BSD
Programming Lang: Python
Description : Python bindings f
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 492 (new: 5)
Total number of packages offered up for adoption: 141 (new: 0)
Total number of packages request
On Thursday, May 30, 2013 16:25:15, Christian PERRIER wrote:
> Quoting Thomas Goirand (z...@debian.org):
> > 1/ Your parents don't read mail? That is surprising to me. In this days
> > and age, everyone does.
Unfortunately I'm finding that the above is not always the case. I'm
increasingly runni
On Thursday, May 30, 2013 15:48:14, Carlos Alberto Lopez Perez wrote:
> On 29/05/13 08:18, Chris Knadle wrote:
> > On Monday, May 27, 2013 21:02:22, Marco d'Itri wrote:
> >> > Now that we are done with systemd for the time being, can we have the
> >> > flame war about replacing Exim with Postfix as
Vincent Bernat writes:
> I still use /etc/init.d/ start by habit and I find it convenient to
> divert to systemd but I have no strong opinion on this. As long as
> upstart jobs mask init scripts when booting, we are fine.
Completely independent of the discussion in this thread, I encourage y
❦ 30 mai 2013 23:47 CEST, Steve Langasek :
>> > No, it won't. What it will do is provide a shell function you can call to
>> > check if init is upstart, and if so, neuter your init script:
>
>> > if init_is_upstart; then
>> > exit 1
>> > fi
>
>> > Doing this automatically by including /
Steve Langasek wrote:
> I'm assuming you're talking here about things like /etc/default/locale and
> /etc/default/keyboard, which systemd upstream fails to handle.
>
> I can't speak to other distributions, but in Debian, the systemd maintainers
> are in no position to decide that Debian will agree
Hi Mark,
On Thu, May 30, 2013 at 02:41:06PM -0700, Mark Symonds wrote:
> …many of us have been to hell and back. Please be near-insanely careful
> when considering a new init:
> http://marc.merlins.org/perso/linux/post_2010-10-24_Ubuntu-Maverick_-Plymouth-Is-the-Worst-Thing-That-Happened-To-Lin
On Thu, May 30, 2013 at 10:41:56PM +0100, Ben Hutchings wrote:
> On Thu, May 30, 2013 at 02:07:10PM -0700, Steve Langasek wrote:
> > On Thu, May 30, 2013 at 10:00:40PM +0100, Ben Hutchings wrote:
> > > On Thu, May 30, 2013 at 10:39:55PM +0200, Ondřej Surý wrote:
> > > > Practical question: if I wer
Dear Halil,
you've reached the Debian development mailing list, this is not a
support channel for Ubuntu!
You should have a look here: http://www.ubuntu.com/support
Regards
Markus
2013/5/30 Halil Kaya :
> Hi.
> For last several weeks I face a Flash Player problem in Ubuntu 12.04. I open
> a vide
Hi.
For last several weeks I face a Flash Player problem in Ubuntu 12.04. I
open a video to watch. Then, sometimes it opens but several times it occurs
error and black screen appears. I looked for solves on the internet and I
did almost all the advices that people give in forums but it still persis
On Thu, May 30, 2013 at 02:41:06PM -0700, Mark Symonds wrote:
>
> …many of us have been to hell and back. Please be near-insanely careful when
> considering a new init:
>
> http://marc.merlins.org/perso/linux/post_2010-10-24_Ubuntu-Maverick_-Plymouth-Is-the-Worst-Thing-That-Happened-To-Linux.h
On Thu, May 30, 2013 at 11:36:42PM +0200, Vincent Bernat wrote:
> ❦ 30 mai 2013 23:07 CEST, Steve Langasek :
> >> . /lib/lsb/init-functions
> >> (Which should be near the top of your init script already.)
> >> This will automagically invoke systemd or upstart if appropriate.
> > No, it won't.
On May 28, 2013, at 11:49 PM, Marc Haber wrote:
> On Sat, 25 May 2013 11:27:36 -0700, Russ Allbery
> wrote:
>> (The shading of meaning between those two options could be clearer. I
>> took it as a measure of enthusiasm and personally answered "I welcome
>> systemd in Debian" because, regardles
…many of us have been to hell and back. Please be near-insanely careful when
considering a new init:
http://marc.merlins.org/perso/linux/post_2010-10-24_Ubuntu-Maverick_-Plymouth-Is-the-Worst-Thing-That-Happened-To-Linux.html
Best -
--
Mark
On Thu, May 30, 2013 at 02:07:10PM -0700, Steve Langasek wrote:
> On Thu, May 30, 2013 at 10:00:40PM +0100, Ben Hutchings wrote:
> > On Thu, May 30, 2013 at 10:39:55PM +0200, Ondřej Surý wrote:
> > > Practical question: if I were to support systemd .service, upstart
> > > init job and/or OpenRC to
❦ 30 mai 2013 23:07 CEST, Steve Langasek :
>> . /lib/lsb/init-functions
>
>> (Which should be near the top of your init script already.)
>> This will automagically invoke systemd or upstart if appropriate.
>
> No, it won't. What it will do is provide a shell function you can call to
> check if
+++ Josh Triplett [2013-05-29 11:50 -0700]:
> Moritz Muehlenhoff wrote:
> > One problematic aspect are the various xul-ext-* packages currently
> > packaged. It's very likely that some of them will break with ESR17
> > and ESR24 in the future.
> >
> > However, there's not much we can do here. We ca
On Thu, May 30, 2013 at 09:05:50PM +0200, Olav Vitters wrote:
> The goal is to make the boot more standard across distributions. So no
> unneeded differences in some configuration files, systemd conf files
> which are generic enough to be included upstream, etc.
> In the current state, each distri
Marc Haber writes:
> Russ Allbery wrote:
>> Get rid of some of that complexity because it is pointless (you'll find
>> that much of it is working around inadequacies in sysvinit).
> Explain.
For example, all the PID file handling is working around the inability to
determine via better mechanis
On Thu, May 30, 2013 at 10:00:40PM +0100, Ben Hutchings wrote:
> On Thu, May 30, 2013 at 10:39:55PM +0200, Ondřej Surý wrote:
> > Practical question: if I were to support systemd .service, upstart
> > init job and/or OpenRC together with standard sysvinit
> > script, how do I check for currently u
On Thu, May 30, 2013 at 10:39:55PM +0200, Ondřej Surý wrote:
> Practical question: if I were to support systemd .service, upstart
> init job and/or OpenRC together with standard sysvinit
> script, how do I check for currently used init system from sysvinit
> script to not start the service for a s
Russ Allbery wrote:
> Uoti Urpala writes:
> > Marc Haber wrote:
> >> And it is still completely inferior even to dpkg-conffile handling,
> >> which has huge wishes left open as well.
>
> > False. The message you replied to already listed advantages over
> > dpkg-conffile handling. This was also a
Please do. Minor is fine (any non-RC bug severity would be fine with me).
Ondřej Surý
On 29. 5. 2013, at 19:05, Sylvestre Ledru wrote:
> Hello,
>
> With the recent setup of the parallel build infrastructure using clang
> instead of gcc [1], I would like to start to report
> bugs on packages fa
]] Ondřej Surý
> Practical question: if I were to support systemd .service, upstart
> init job and/or OpenRC together with standard sysvinit
> script, how do I check for currently used init system from sysvinit
> script to not start the service for a second time?
With systemd, as long as the in
On Fri, 31 May 2013 01:53:01 +0800, Thomas Goirand
wrote:
>Though, I'm really not sure that if Debian decides to adopt Systemd now,
>rather than a bit later, it will influence its development, or change
>anything at all upstream.
Of course it won't. Upstream and Red Hat have shown many times that
On Thu, 30 May 2013 21:05:50 +0200, Olav Vitters
wrote:
>On Thu, May 30, 2013 at 06:27:13PM +0200, Marc Haber wrote:
>> And I am also opposing changes that will help in dropping the
>> "universal" out of Debian's claim.
>
>Do you actually run a kernel other than Linux
Actually no, but it is a ple
Practical question: if I were to support systemd .service, upstart init job
and/or OpenRC together with standard sysvinit script, how do I check
for currently used init system from sysvinit script to not start the service
for a second time?
Is there some material on wiki.d.o I can use (and if
On Thu, 30 May 2013 08:42:49 -0700, Russ Allbery
wrote:
>Get rid of some of that complexity because it is pointless (you'll find
>that much of it is working around inadequacies in sysvinit).
Explain.
> Get rid of
>more of it by building a static configuration from the dynamic
>configuration whe
On Thu, May 30, 2013 at 09:12:58PM +0200, Olav Vitters wrote:
> On Thu, May 30, 2013 at 09:38:40AM -0700, Steve Langasek wrote:
> > development (because unlike the systemd developers, the upstart developers
> > aren't trying to sell anyone a bill of goods about how their existing units
> > are perf
On Thu, 30 May 2013 19:45:48 +0200, Carlos Alberto Lopez Perez
wrote:
>Maybe is related to cPannel. Seems that cPannel 11.30 shipped Exim 4.69
>and 11.32 Exim 4.77 [2]
Judging from the sheer amount of clueless cpanel users showing up on
exim lists, this is a really big possibilty.
Greetings
Marc
Quoting Thomas Goirand (z...@debian.org):
> 1/ Your parents don't read mail? That is surprising to me. In this days
> and age, everyone does.
Yes.
Out of 5 adult people in my family, all of them read their mail daily.
4 of them do it through a web interface and have absolutely no use of
a mail
On 05/30/2013 08:06 PM, Scott Kitterman wrote:
> FWIW, Ubuntu has done this with their backports repositories for the last two
> years of releases
debian-live images have this by default since squeeze too.
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.
On 29/05/13 08:18, Chris Knadle wrote:
> On Monday, May 27, 2013 21:02:22, Marco d'Itri wrote:
>> > Now that we are done with systemd for the time being, can we have the
>> > flame war about replacing Exim with Postfix as the default MTA?
>> >
>> > Are there any objections other than "but I like i
Jonas Smedegaard writes:
> Sorry, what bugreport?
> I do not consider backports.debian.org of same quality as debian.org so
> am concerned by what you outline above, and would like to (at the least)
> read up on the relevant discussion (i.e. avoid rehashing it here).
I'm afraid I've expired the
On Thu, May 30, 2013 at 08:29:16PM +0200, Didier 'OdyX' Raboud wrote:
> > FWIW, I don't. I think the compromise that the security team is proposing is
> > much more reasonable than such an alternative.
>
> That compromise (which I do definitely support for wheezy) puzzles me
> most for the precede
On Thu, May 30, 2013 at 09:38:40AM -0700, Steve Langasek wrote:
> development (because unlike the systemd developers, the upstart developers
> aren't trying to sell anyone a bill of goods about how their existing units
> are perfect and nothing will ever need to be patched downstream). But there
On Thu, May 30, 2013 at 06:27:13PM +0200, Marc Haber wrote:
> On Thu, 30 May 2013 14:16:53 +0200, Olav Vitters
> wrote:
> >On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
> >> The init system case is special because supporting another init script
> >> system will most probably mean tha
On Thu, May 30, 2013 at 10:56:23AM -0700, Russ Allbery wrote:
> The actual proposal in the bug report is to add backports.debian.org
> to the default sources.list file in the installer, but not otherwise
> change anything about the backports configuration. Specifically, the
> archive would remain
On 30-05-13 19:53, Thomas Goirand wrote:
> On 05/30/2013 04:46 PM, Riku Voipio wrote:
>> While we are busy maintaining multiple indirection layers to
>> "support user choice"
>
> I don't think this is what Wouter was talking about (eg, he never said
> we should leave this as a choice to the user).
Quoting Russ Allbery (2013-05-30 19:56:23)
> Wouter Verhelst writes:
> > On 30-05-13 19:29, Thomas Goirand wrote:
>
> >> Maybe the best way forward is to have backports activated by
> >> default
>
> > No.
>
> > If we're going down that route, we might as well give up on doing a
> > stable rel
Uoti Urpala writes:
> Marc Haber wrote:
>> And it is still completely inferior even to dpkg-conffile handling,
>> which has huge wishes left open as well.
> False. The message you replied to already listed advantages over
> dpkg-conffile handling. This was also already discussed before:
> https:
Le jeudi, 30 mai 2013 15.29:22, Stefano Zacchiroli a écrit :
> On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote:
> > > Which web browsers would remain in stable if we applied this criterion
> > > consistently?
> >
> > Although that makes me very sad, if we (collectively) give u
On 05/30/2013 03:10 AM, Wouter Verhelst wrote:
> I think it makes perfect sense for us to support systemd, openrc, and
> upstart, at least for the time being; I doubt we'll continue supporting
> all three options until the end of times, but we don't have to do that.
I very much like the idea to gi
On Thursday, May 30, 2013 10:56:23 AM Russ Allbery wrote:
> Wouter Verhelst writes:
> > On 30-05-13 19:29, Thomas Goirand wrote:
> >> Maybe the best way forward is to have backports activated by default
> >
> > No.
> >
> > If we're going down that route, we might as well give up on doing a
> > s
Wouter Verhelst writes:
> On 30-05-13 19:29, Thomas Goirand wrote:
>> Maybe the best way forward is to have backports activated by default
> No.
> If we're going down that route, we might as well give up on doing a
> stable release.
Two issues keep getting confused when people talk about this,
Marc Haber wrote:
> On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp
> wrote:
> >So, this is not really RHEL specific, and some other non-RH software
> >also has this scheme of storing config files.
>
> And it is still completely inferior even to dpkg-conffile handling,
> which has huge wishes
On 30/05/13 13:27, Scott Kitterman wrote:
> On Thursday, May 30, 2013 01:01:46 PM Carlos Alberto Lopez Perez wrote:
>> On 30/05/13 12:27, Scott Kitterman wrote:
>>> On Thursday, May 30, 2013 12:16:38 PM Carlos Alberto Lopez Perez wrote:
On 29/05/13 08:18, Chris Knadle wrote:
> - Exim is
On 30-05-13 19:29, Thomas Goirand wrote:
> Maybe the best way forward is to have backports activated by default
No.
If we're going down that route, we might as well give up on doing a
stable release.
--
This end should point toward the ground if you want to go to space.
If it starts pointing t
On 30/05/13 13:19, Bastien ROUCARIES wrote:
> On Thu, May 30, 2013 at 12:50 PM, Dennis van Dok wrote:
>> On 26-05-13 20:02, Bastien ROUCARIES wrote:
>>> On Sat, May 25, 2013 at 2:27 PM, Charles Plessy wrote:
Hi Dennis and everybody,
somewhat related to this, I would like to know if
On 05/30/2013 09:29 PM, Stefano Zacchiroli wrote:
> On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote:
>>> Which web browsers would remain in stable if we applied this criterion
>>> consistently?
>>
>> Although that makes me very sad, if we (collectively) give up packaging
>> br
On Thu, May 30, 2013 at 12:32:59PM +0100, Simon McVittie wrote:
> On 30/05/13 11:19, Marc Haber wrote:
> > On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery
> > wrote:
> >> Using an imperative language for a descriptive purpose is a bad mismatch
> >> of tools and has been ever since the practical e
On Thu, May 30, 2013 at 04:27:43PM +0100, Simon McVittie wrote:
> > Anyone knows how Multi-Arch is handled for other similar plugin
> > packages, other than gkrellm2 plugins?
> telepathy-mission-control-5 specifically isn't Multi-Arch, because I
> didn't want to do a small transition (Mission Cont
On Wed, May 22, 2013 at 08:35:52PM +0200, John Paul Adrian Glaubitz wrote:
> >Please leave the FUD at the door. Writing upstart jobs is not difficult;
> >while there are some gotchas currently with process lifecycle (which will be
> >fixed soon), there is also very complete documentation (for thes
Matthias Klumpp wrote:
> 013/5/30 Marco d'Itri :
> > On May 30, Mathieu Parent wrote:
> >[···]
> >> > There is also the "kill features Red Hat does not care about" deal,
> >> Do you have an example?
> > Persistent naming of network interfaces.
> ... is entirely optional, and can be disabled if som
On Thu, May 30, 2013 at 04:35:07PM +0200, Marco d'Itri wrote:
> On May 30, Mathieu Parent wrote:
> > Do you have an example?
> The /etc/ /lib/ /usr/lib/ split with files overriding each other,
> invented because RPM systems do not prompt the user on package upgrades
> and Red Hat does not suppor
On Thu, 30 May 2013 14:16:53 +0200, Olav Vitters
wrote:
>On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
>> The init system case is special because supporting another init script
>> system will most probably mean that all packages delivering an init
>> script ($ ls /etc/init.d/ | wc -l
On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp
wrote:
>So, this is not really RHEL specific, and some other non-RH software
>also has this scheme of storing config files.
And it is still completely inferior even to dpkg-conffile handling,
which has huge wishes left open as well.
Greetings
M
On Thu, 30 May 2013 12:32:59 +0100, Simon McVittie
wrote:
>On 30/05/13 11:19, Marc Haber wrote:
>> On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery
>> wrote:
>>> Using an imperative language for a descriptive purpose is a bad mismatch
>>> of tools and has been ever since the practical effect of i
On Thu, 30 May 2013 16:42:28 +0200, Christoph Anton Mitterer
wrote:
>Agreed,... but that also somehow indicates to me, that this would be the
>more appropriate default MTA.
>It will do quite securely what most people need, especially those end
>user who have no clue about running mailservers at al
On Thu, 30 May 2013 16:53:56 +0200, m...@linux.it (Marco d'Itri) wrote:
>I think that ease of configurability is a major plus for Postfix when
>compared to Exim, since a common configurations is just a few lines long.
How many lines does an average update-exim4.conf.conf have?
Greetings
Marc
--
Package: wnpp
Severity: wishlist
Owner: Osamu Aoki
* Package name: pxe-pdhcp
Version : 0.1
Upstream Author : FURUHASHI Sadayuki
* URL : http://svn.coderepos.org/share/lang/c/pxe-pdhcp/
* License : MIT
Programming Lang: C
Description : ProxyDHCP server
Marco d'Itri writes:
> On May 30, Chris Knadle wrote:
>
>> There's a reason it feels like this. Postfix was designed with security in
>> mind, but wasn't focused on being a general purpose MTA.
> Says who? Because I was around at the time, and I remember pretty well
> that the goal was to wri
On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters
wrote:
>Seems the solutions are very focussed on the assumption that things
>cannot be changed. E.g. programs currently send email, so email it has
>to be forever.
It is not a good idea to drop the way that > 90 % of programs use to
deliver message
On Thu, 30 May 2013 13:31:14 +0200, Wouter Verhelst
wrote:
>On 30-05-13 12:27, Marc Haber wrote:
>> We should make local mail or other messages trivially and
>> automatically visible for people who have installed Debian in NNF[1]
>> compliant way, but if one has gone to length to use something
>>
Marc Haber writes:
> Russ Allbery wrote:
>> Using an imperative language for a descriptive purpose is a bad
>> mismatch of tools and has been ever since the practical effect of init
>> scripts has become fairly standardized.
> Some init scripts in Debian build dynamic configuration before the
>
Jonathan Dowland wrote:
> On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote:
> > Do you have any reason at all to believe that these were problems with
> > systemd, rather than problems in Debian configuration or mostly
> > independent bugs in other software that happened to trigger under
+++ Simon McVittie [2013-05-30 16:27 +0100]:
> The only plugins that do benefit from being Multi-Arch are those that
> are loaded by more than one executable: glibc NSS modules, PAM modules,
> ALSA plugins, that sort of thing.
Or plugins that are used in build-depends. I don't know if this ever
Package: wnpp
Severity: wishlist
Owner: Michael Schultheiss
* Package name: opendb
Version : 1.5.0.7
Upstream Author : Jason Pell
* URL : http://opendb.iamvegan.net
* License : GPL v2
Programming Lang: PHP
Description : PHP and MySQL based inventory app
Marc Haber writes:
> Chris Knadle wrote:
>> I don't like the fact that the /etc/exim4/passwd.client file is in a
>> plaintext format, but there are usually several such files on systems
>> such that realistically we're only really "safe" as long as the
>> machines we run haven't been broken into
On 30/05/13 16:02, John Paul Adrian Glaubitz wrote:
> I am maintaining one of the gkrellm2 plugin packages, namely
> gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
> plugins into /usr/lib/gkrellm2/plugins, including mine.
This seems appropriate.
> However, I was wondering w
2013/5/30 Marco d'Itri :
> On May 30, Mathieu Parent wrote:
>[···]
>> > There is also the "kill features Red Hat does not care about" deal,
>> Do you have an example?
> Persistent naming of network interfaces.
... is entirely optional, and can be disabled if someone doesn't want
it - but I can't s
2013/5/30 Marco d'Itri :
> On May 30, Mathieu Parent wrote:
>
>> (I'm afraid to feed the troll)
> Hint: before accusing somebody of trolling it is a good idea to find out
> who he is.
I apologize.
--
Mathieu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Thu, May 30, 2013 at 11:02 PM, John Paul Adrian Glaubitz
wrote:
> Hello!
>
> I am maintaining one of the gkrellm2 plugin packages, namely
> gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
> plugins into /usr/lib/gkrellm2/plugins, including mine.
>
> However, I was wonderin
Hello!
I am maintaining one of the gkrellm2 plugin packages, namely
gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
plugins into /usr/lib/gkrellm2/plugins, including mine.
However, I was wondering whether the plugins should actually
get installed into /usr/lib/${DEB_HOST_MU
On May 30, Mathieu Parent wrote:
> (I'm afraid to feed the troll)
Hint: before accusing somebody of trolling it is a good idea to find out
who he is.
> > There is also the "kill features Red Hat does not care about" deal,
> Do you have an example?
Persistent naming of network interfaces.
> > a
On May 30, Chris Knadle wrote:
> There's a reason it feels like this. Postfix was designed with security in
> mind, but wasn't focused on being a general purpose MTA.
Says who? Because I was around at the time, and I remember pretty well
that the goal was to write a sendmail replacement.
And a
On Thu, 2013-05-30 at 07:53 -0400, Chris Knadle wrote:
> There's a reason it feels like this. Postfix was designed with security in
> mind, but wasn't focused on being a general purpose MTA. It happens to
> /work/
> pretty well in that role in many cases, though.
>
>http://shearer.org/MTA
Hi Moritz.
Moritz Muehlenhoff wrote:
> In the future the majority of packages should thus rather be installed
> through http://addons.mozilla.org instead of Debian packages.
Form a security POV, I think this is really quite dangerous... actually
tendency should go towards the direction that users
On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote:
> Do you have any reason at all to believe that these were problems with
> systemd, rather than problems in Debian configuration or mostly
> independent bugs in other software that happened to trigger under
> systemd?
Whether or not syst
On Wed, 2013-05-29 at 12:19 +0200, Dennis van Dok wrote:
> ...which is included in mozilla. That discussion should be taken there
> (indeed was[1]) as in Debian it was agreed we're not going to do better
> than Mozilla at judging CAs[2].
Yeah... sure... I was just mentioning it...
Given that Mozill
Le 30 mai 2013 14:08, "Dennis van Dok" a écrit :
>
> On 30-05-13 13:16, Bastien ROUCARIES wrote:
>
> > Using only one lib for crypto (libnss) will allow to use only one
> > trust certificate format
>
> 'Allow only one' doesn't immediately strike me as beneficial, but I see
> what you mean. The dis
Mathieu Parent wrote:
> 2013/5/30 Marco d'Itri :
> > and the "invent a new a configuration files scheme because it better
> > suits RPM and Red Hat policies" deal.
>
> Do you have an example?
I think he's referring to the etc-overrides-lib semantics that systemd
uses for configuration files. But
On 2013-05-29 20:50, Josh Triplett wrote:
As a user of sid who also maintains various systems running stable, I
rely on packages like xul-ext-adblock-plus to make it easier to install
specific addons systemwide. I find it much easier to install those via
the Debian packaging system rather than a
Salvo Tomaselli wrote:
> I have tried systemd, and I like the approach it has, and in a few years I
> believe it has potential. But... using it to restart my computer i need to do
> an hard reset (and think of how happy would I be if my computer had been a
> server in a rack on the other side of
* Marc Haber [130530 12:39]:
> While I don't consider postfix as bad as you describe, I tend to
> describe Postfix as the menu in a better restaurant: A relatively
> small number of sophisticated dishes which you can choose from, and
> if you like them, you will be perfectly satisfied. If you wan
On Thu, May 30, 2013 at 8:53 PM, Florian Weimer wrote:
> Which web browsers would remain in stable if we applied this criterion
> consistently?
The best browser ever; lynx.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Thursday, May 30, 2013 09:34:06 AM Paul Tagliamonte wrote:
> On Thu, May 30, 2013 at 06:36:32AM -0400, Scott Kitterman wrote:
> > In that case, I'd say they aren't bugs at all. It may be that a FTBFS
> > with
> > clang is a symptom of some underlying issue that should be addressed, but
> > I
>
Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg
* Package name: javamail
Version : 1.5.0
Upstream Author : Bill Shannon
* URL : http://javamail.java.net
* License : CDDL-1.1 | GPL-2 with Classpath Exception
Programming Lang: Java
Description : J
On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote:
> > Which web browsers would remain in stable if we applied this criterion
> > consistently?
>
> Although that makes me very sad, if we (collectively) give up packaging
> browser extensions (hence letting our users rely on thir
On Thu, May 30, 2013 at 06:36:32AM -0400, Scott Kitterman wrote:
> In that case, I'd say they aren't bugs at all. It may be that a FTBFS with
> clang is a symptom of some underlying issue that should be addressed, but I
> don't think non-wishlist bugs should be filed ONLY on the basis of that
>
(I'm afraid to feed the troll)
2013/5/30 Marco d'Itri :
> On May 30, Gergely Nagy wrote:
>
>> I never quite understood why people seem to think systemd upstream is
>> uncooperative (well, apart from the whole non-linux porting deal, where
>> their stance is completely understandable too). My expe
Le jeudi, 30 mai 2013 14.53:44, Florian Weimer a écrit :
> * Didier Raboud:
> > If we can't handle the backporting of serious security issues on top
> > of our stable version (in order to maximise the avoidance of
> > regressions), then maybe said software shouldn't be shipped in
> > stable in the
* Didier Raboud:
> If we can't handle the backporting of serious security issues on top
> of our stable version (in order to maximise the avoidance of
> regressions), then maybe said software shouldn't be shipped in
> stable in the first place. Thoughts ?
Which web browsers would remain in stable
1 - 100 of 152 matches
Mail list logo
