On Mon, Feb 27, 2012 at 09:06:51AM +0100, Elena ``of Valhalla'' wrote:
> On 2012-02-26 at 00:26:14 +0100, Evgeni Golov wrote:
> > What's wrong with [...]
> > What are the benefits of python-gnupg? The homepage doesnt tell any,
> > neither does the description :)
>
> Mostly the documentation: pytho
Le lundi 27 février 2012 à 05:19 +0100, Sebastian Heinlein a écrit :
> Am Donnerstag, den 23.02.2012, 18:46 +0200 schrieb Timo Juhani
> Lindfors:
> > Josselin Mouette writes:
> > > (We even have a patch to allow only a subset of packages but it is
> > > unfortunately a bit too hackish.)
> >
> >
On 2012-02-26 at 00:26:14 +0100, Evgeni Golov wrote:
> What's wrong with [...]
> What are the benefits of python-gnupg? The homepage doesnt tell any,
> neither does the description :)
Mostly the documentation: python-gnupg's interface is fully documented
with docstrings (with examples checked in
On 21/02/12 22:57, Michael Biebl wrote:
On 21.02.2012 21:25, Russ Allbery wrote:
The most likely way forward is some period where either can be used and we
see how things shake out. Unfortunately, neither currently supports
kFreeBSD. The upstart upstream seems more amenable to doing so than t
On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote:
> > I have. Not on debian, but on debianish system with dash. And the result
> > was that shellscripts are indeed the bottleneck. We still did convert to
> > upstart since we believed it would allow us to cut down the amount of
> > sh
* Uoti Urpala [120226 20:20]:
> If someone complained about a nontrivial s390-specific problem in a
> context where I was upstream, I'd likely ignore him. In the Debian
> context, people other than porters should not be obligated to do
> significant work to resolve problems specific to fringe arch
Maybe interesting to read in this upstart vs. systemd vs. sysvinit
discussion is the comparison of these three init systems:
http://0pointer.de/blog/projects/why.html
Of course, Lennart Poettering did this, but the points mentioned are
valid. (Although the list is a bit outdated, at least on upstar
Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> discussion is the comparison of these three init systems:
> http://0pointer.de/blog/projects/why.html
> Of course, Lennart Poettering did this, but the points mention
clone 601455 -1
retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via
/etc/default/foo
quit
peter green wrote:
> regardless of any plan to discourage use of the /etc/default
> mechanism (I think removing it altogether is not really reasonable)
> I think the original bug o
Processing commands for cont...@bugs.debian.org:
> clone 601455 -1
Bug#601455: multiple, annoyingly different ways to disable an init script
Bug 601455 cloned as bug 661496.
> retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via
> /etc/default/foo
Bug #601455 [general] m
(moving Mikko to bcc to avoid spamming him)
Don Armstrong wrote:
> retitle 661241 vlc probably using wrong sound output by default (but not
> clear from reporter)
> reassign 661241 vlc
[...]
> Mikko Koho: I'm guessing as to what your problem is, but you're going
> to have to provide more informat
On Mon, Feb 27, 2012 at 05:45:14PM +0100, Matthias Klumpp wrote:
> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> discussion is the comparison of these three init systems:
> http://0pointer.de/blog/projects/why.html
> Of course, Lennart Poettering did this, but the points ment
2012/2/27 Samuel Thibault :
> Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
>> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
>> discussion is the comparison of these three init systems:
>> http://0pointer.de/blog/projects/why.html
>> Of course, Lennart Poetterin
On Mon, 27 Feb 2012, Jonathan Nieder wrote:
> The difficult cases are in between: carrying out the back-and-forth
> to get such details as what action precipitated the problem, what
> result was expected, what happened instead, and how the difference
> indicates a bug, with debian-devel cc-ed, does
On Mon, Feb 27, 2012 at 12:24:25PM +0200, Riku Voipio wrote:
> On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote:
> > > I have. Not on debian, but on debianish system with dash. And the result
> > > was that shellscripts are indeed the bottleneck. We still did convert to
> > > upstart
Matthias Klumpp, le Mon 27 Feb 2012 18:42:39 +0100, a écrit :
> 2012/2/27 Samuel Thibault :
> > Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
> >> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> >> discussion is the comparison of these three init systems:
> >> h
Bernhard R. Link wrote:
> While there might be some problems originating from some architecture,
> but most problems you will see and people claim to be "problems specific
> to fringe architectures" are actual bugs in the program you just do not
> *yet* see on your usual pet architectures. And some
Steve Langasek wrote:
> If no one's measured it, then converting scripts to C programs to
> avoid the added exec() calls is premature optimization. If the only
You keep repeating the same FUD. Again, avoiding shell is not just an
optimization, much less a premature one. Also, if I understand the
Uoti Urpala writes:
> Bernhard R. Link wrote:
>> Imagine how long amd64 would have taken, if people had not had years
>> to fix all those 64 bit bugs on alpha first (Which never really got
>> a mainstream architecture and where it was used was quite server-only.
>> Who would have guessed that fix
Steve Langasek writes:
> I would certainly welcome it if someone did profiling that showed whether
> the shells are a bottleneck. My own subjective experience is that this is
> probably not the low-hanging fruit on a general-purpose distro, but if it
> turns out that there are significant speed
I said this in another message, but I'm not sure I was sufficiently
explicit, so I'm going to try again to inject a bit more reality into this
thread.
The next step for looking at alternative init systems is finalizing the
Policy changes that are required to support alternative init systems.
That
Package: wnpp
Severity: normal
Owner: "Benjamin J. Scott"
* Package name: kvpm
Version : 0.8.5
Upstream Author : Benjamin J. Scott
* URL : http://http://sourceforge.net/projects/kvpm/
* License : GPL version 3
Programming Lang: C++
Description : Logica
Goswin von Brederlow wrote:
> Steve Langasek writes:
> > /etc/default/* files. The options here are all fairly poor:
> Option 2 is also bad. There is a reason why we have /etc/default instead
> of setting the options in the init.d scripts directly. Most importantly
> the init.d scripts can be up
Don Armstrong wrote:
> http://www.debian.org/Bugs/Reporting already tells people to contact
> -user if they are unable to determine which package their bug report
> should be filed against. I suppose text could be added to reportbug to
> mimic this... perhaps changing:
Very nice. Filed as http:/
Package: wnpp
Severity: wishlist
Owner: Jonathan McCrohan
* Package name: nyancat
Version : 0.1
Upstream Author : Kevin Lange
* URL : http://miku.acm.uiuc.edu/
* License : NCSA
Programming Lang: C
Description : Terminal-based Pop Tart Cat animation
N
On Sun, Feb 26, 2012 at 05:24:16PM +0100, Goswin von Brederlow wrote:
> > Well, I fudged a little here. You're right that, as written above, nis is
> > not guaranteed to start before autofs. Due to a (well-understood and
> > recognized) limitation of upstart's current event handling, if the
> > '
Steve Langasek writes:
> On Sun, Feb 26, 2012 at 05:24:16PM +0100, Goswin von Brederlow wrote:
>> > Well, I fudged a little here. You're right that, as written above, nis is
>> > not guaranteed to start before autofs. Due to a (well-understood and
>> > recognized) limitation of upstart's curren
27 matches
Mail list logo
