Re: Default display manager should not be gdm3

[Vincent Bernat]

OoO En cette  fin de nuit blanche du jeudi 23  février 2012, vers 06:47,
Miles Bader  disait :

>> We should not still be using this software.

> Er, given that gdm3 works fine for many people, that seems excessive.

> Moreover, the choice of default display manager seems unrelated to its
> ability to support obscure tweaks -- indeed, it's very common for
> default packages to be those that are nicer for "average" users, not
> those that are the most customizable.  You have the choice of easily
> installing other display managers that meet your criteria, so what's
> the big deal?

Moreover, other display  manager may not work correctly  because gdm3 is
the only  display manager supporting  all modern stuff. For  example, we
could switch to  something like "slim" but slim does  not play nice with
ConsoleKit which means that a  user logged with slim won't be considered
as a  local user and therefore  won't have rights  for power management,
network configuration and things like that. See:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601003

The main  problem is things are now  more complex than 10  years ago and
alternatives are  unable to  cope with all  the new things  necessary to
make a  desktop work correctly.  We have  to rely on parts  of the GNOME
desktop. Unfortunately, those parts are dependant on other parts and are
not as hackable and documented as we are used to.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plauger)


pgpx3YUqDEo0k.pgp
Description: PGP signature

Re: upstart: please update to latest upstream version

[Tollef Fog Heen]

]] Tzafrir Cohen 

> In sysv init scripts the daemon forks into the background. In upstrart
> and systemd it doesn't have to (or shouldn't). (not) forking requires a
> different command-line argument, normally. This leads to odd beasts such
> as safe_mysqld.

You can just use the --background switch to start-stop-daemon with
sysvinit scripts.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5ru2hkb@qurzaw.varnish-software.com

Re: Default display manager should not be gdm3

[Miles Bader]

Ian Jackson  writes:
> We should not still be using this software.

Er, given that gdm3 works fine for many people, that seems excessive.

Moreover, the choice of default display manager seems unrelated to its
ability to support obscure tweaks -- indeed, it's very common for
default packages to be those that are nicer for "average" users, not
those that are the most customizable.  You have the choice of easily
installing other display managers that meet your criteria, so what's
the big deal?

-miles

-- 
Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/buobooqksmr@dhlpc061.dev.necel.com

Bug#660957: ITP: arduino-mk -- CLI (makefile) for arduino platforms

[Scott Howard]

Package: wnpp
Severity: wishlist
Owner: Scott Howard 

* Package name: arduino-mk
  Version : 0.8
  Upstream Author : Martin Oldfield 
* URL : http:/mjo.tc/atelier/2009/02/arduino-cli.html
* License : LGPL-2.1
  Programming Lang: Perl, make
  Description : CLI (makefile) for arduino platforms

This is formally splitting out the makefile that is currently in the arduino-
core
package. arduino-core will then suggest this package, and this new package will
depend on arduino-core.

arduino-core and arduino-mk are two seperate projects. When arduino was first
packaged, they were kept in Debian as one package because they historically
used to be from the same upstream. Since the split, we've been maintaining
arduino-mk as patches in the arduino package. Since there is now an "upstream"
maintaining arduino-mk, it makes sense to seperate the two packages that now
have two seperate upstreams and releases.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120120053911.3965.87164.report...@debian-testing.hsd1.in.comcast.net

Re: upstart: please update to latest upstream version

[Tzafrir Cohen]

On Thu, Feb 23, 2012 at 12:47:15AM +, Roger Leigh wrote:
> On Wed, Feb 22, 2012 at 02:58:50PM -0800, Russ Allbery wrote:
> > John Paul Adrian Glaubitz  writes:
> > 
> > > But I don't see the problem, Debian has the choice. We're not going to
> > > drop system V init anytime soon. Providing both systemd, upstart as well
> > > as classical system V init leaves the up to the user and allows to
> > > support non-Linux kernels.
> > 
> > There's a serious drawback to supporting multiple init systems if one of
> > the goals is to stop writing init scripts.  The only common denominator is
> > init scripts; upstart and systemd configuration files look entirely
> > different, and would have to be maintained separately if we support both
> > without using the init script compatibility support.
> 
> Yes, there is absolutely a big cost to pay in supporting multiple
> init systems.  Choice is good when there's a benefit, but we should
> not ignore the cost we pay.
> 
> It would be good if we could generate init scripts from upstart
> and/or systemd service files, to permit migration to newer systems
> while still permitting the old system to be supported for the
> interim.  It would IMO be more productive to port systemd and/or
> upstart to kFreeBSD/Hurd to make it possible to use the modern
> systems on all arches.  The attitude of the systemd upstream is
> not encouraging here, however.

In sysv init scripts the daemon forks into the background. In upstrart
and systemd it doesn't have to (or shouldn't). (not) forking requires a
different command-line argument, normally. This leads to odd beasts such
as safe_mysqld.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120223021241.gf9...@pear.tzafrir.org.il

Re: upstart: please update to latest upstream version

[Raphael Geissert]

Russell Coker wrote:
> One of the design features of systemd is that it can be run by the user. 
> So you could have a login to GNOME or KDE launch a copy of systemd for the
> desktop environment services which would improve the login times.  I
> haven't used GNOME for quite a while, but the KDE login time on my system
> is quite long.

How would systemd improve the login time? have you profiled the login 
process?

Regards,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ji47im$3ut$1...@dough.gmane.org

Re: upstart: please update to latest upstream version

[Paul Wise]

On Thu, Feb 23, 2012 at 9:52 AM, Russell Coker wrote:

> This problem is being addressed to some extent.  Modern web browsers offer to
> reopen all previous windows and tabs when restarted.  IMHO a desktop
> environment would ideally be able to open everything again such that a reboot
> wouldn't be an issue that a user would care about.  I'd like to have
> OpenOffice save a copy of changed documents on logout and load them again on
> login so that my change history is preserved.  I'd like to have command line
> sessions reopen to the same CWD and the same screen contents.

The recent versions of MacOS X do that to some extent. I read an
article where someone was complaining that it destroys startup speed
(unless using an SSD) due to needing to load much more data off disk.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6hmpchakzpp0ois6aazanal+6udh7kw8uxsut1l2zg...@mail.gmail.com

Re: upstart: please update to latest upstream version

[Russell Coker]

On Thu, 23 Feb 2012, Stephan Seitz  wrote:
> We are talking about a minute or so.

If a million users spend a minute waiting for a system to boot that is 16,667 
hours of wasted time which is equivalent to almost 9 years of paid work for a 
40 hour week and a few weeks of holiday per year!

> When they are annoyed, it is not 
> because of the reboot time but because they have to save and close all 
> their applications.

This problem is being addressed to some extent.  Modern web browsers offer to 
reopen all previous windows and tabs when restarted.  IMHO a desktop 
environment would ideally be able to open everything again such that a reboot 
wouldn't be an issue that a user would care about.  I'd like to have 
OpenOffice save a copy of changed documents on logout and load them again on 
login so that my change history is preserved.  I'd like to have command line 
sessions reopen to the same CWD and the same screen contents.

On Thu, 23 Feb 2012, Adam Borowski  wrote:
> With recent improvements, booting itself is pretty fast.  But then, you get
> the {x,g,k}dm screen, log in, and have to wait way longer than the boot
> itself took -- and on slow machines, it can be a matter of over a minute.
> Worse, you don't have a second $BEVERAGE to get, so you need to have to
> actually wait.

One of the design features of systemd is that it can be run by the user.  So 
you could have a login to GNOME or KDE launch a copy of systemd for the 
desktop environment services which would improve the login times.  I haven't 
used GNOME for quite a while, but the KDE login time on my system is quite 
long.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202231252.13277.russ...@coker.com.au

Re: upstart: please update to latest upstream version

[Roger Leigh]

On Wed, Feb 22, 2012 at 02:58:50PM -0800, Russ Allbery wrote:
> John Paul Adrian Glaubitz  writes:
> 
> > But I don't see the problem, Debian has the choice. We're not going to
> > drop system V init anytime soon. Providing both systemd, upstart as well
> > as classical system V init leaves the up to the user and allows to
> > support non-Linux kernels.
> 
> There's a serious drawback to supporting multiple init systems if one of
> the goals is to stop writing init scripts.  The only common denominator is
> init scripts; upstart and systemd configuration files look entirely
> different, and would have to be maintained separately if we support both
> without using the init script compatibility support.

Yes, there is absolutely a big cost to pay in supporting multiple
init systems.  Choice is good when there's a benefit, but we should
not ignore the cost we pay.

It would be good if we could generate init scripts from upstart
and/or systemd service files, to permit migration to newer systems
while still permitting the old system to be supported for the
interim.  It would IMO be more productive to port systemd and/or
upstart to kFreeBSD/Hurd to make it possible to use the modern
systems on all arches.  The attitude of the systemd upstream is
not encouraging here, however.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120223004715.gf24...@codelibre.net

Re: upstart: please update to latest upstream version

[Adam Borowski]

On Wed, Feb 22, 2012 at 02:42:51PM +0100, Stephan Seitz wrote:
> I don’t doubt it, but the question is, who cares if the boot process
> takes a little bit longer?
> The desktop users I know are fetching their coffee while the system
> is booting.

With recent improvements, booting itself is pretty fast.  But then, you get
the {x,g,k}dm screen, log in, and have to wait way longer than the boot
itself took -- and on slow machines, it can be a matter of over a minute.
Worse, you don't have a second $BEVERAGE to get, so you need to have to
actually wait.

It's not the absolute time from pushing the button to usable desktop that
matters, it's whether you have to babysit it and do something in the middle.

As 99% desktops and laptops these days have only one user, loading that only
user's environment in the background would be a good idea.  #428617 has a
possible solution, although it would have to be done carefully.  Googling
around you can see a number of recipes floating around, all with an obvious
race condition.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

Default display manager should not be gdm3

[Ian Jackson]

On my netbook I'm running a pretty vanilla install of squeeze,
although my personal desktop session is very different to usual.

I wanted to add a command-line option to my X server.  I spent 15 mins
trawling through docs and grepping for config options with no luck.
So I asked a search engine.

It turns out that:
 * There is no way to do this without patching the gdm source code
   or using dpkg-divert to wrap the X server with a shell script
 * Such a feature was requested in a bug in the RH/Fedora bugzilla
   in June 2008 [1].  It's also in our BTS [2].  And in the upstream
   BTS multiple times with patches (September 2009, October 2010) [3].
   Despite a lot of demand, it still seems that this simple and
   essential feature simply wasn't on anyone's radar.
 * Worse, in September 2011 one of the upstream authors seems to
   poo-poo the idea [4]!  It looks like they are resistant to sanity.

gdm3 also has the crazy XAUTHORITY bug [5], which was reported
to upstream [6] who inserted a completely crazy "fix" [7] showing they
totally fail to understand how all this stuff is supposed to work.

That bug was fixed in Debian by the X maintainers adding a workaround
to the core X session startup scripts.  Madness.

We should not still be using this software.

I don't have much of an opinion about the rest of gnome because I
don't use it.  But we should be "considering our position" as they
say.

Ian.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=451562
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651693
[3] https://bugzilla.gnome.org/show_bug.cgi?id=586777
https://bugzilla.gnome.org/show_bug.cgi?id=632045
[4] http://mail.gnome.org/archives/gdm-list/2011-September/msg6.html
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586685
[6] https://bugzilla.gnome.org/show_bug.cgi?id=651431
[7] http://bugzilla-attachments.gnome.org/attachment.cgi?id=199386


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20293.32681.953043.814...@chiark.greenend.org.uk

Re: upstart: please update to latest upstream version

[Russ Allbery]

John Paul Adrian Glaubitz  writes:

> But I don't see the problem, Debian has the choice. We're not going to
> drop system V init anytime soon. Providing both systemd, upstart as well
> as classical system V init leaves the up to the user and allows to
> support non-Linux kernels.

There's a serious drawback to supporting multiple init systems if one of
the goals is to stop writing init scripts.  The only common denominator is
init scripts; upstart and systemd configuration files look entirely
different, and would have to be maintained separately if we support both
without using the init script compatibility support.

Thankfully, they're much simpler than init scripts, so supporting both
upstart and systemd isn't too bad, but both of them plus init scripts
reduces a lot (but not all) of the advantages of the new init systems.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obsqtqz9@windlord.stanford.edu

Re: upstart: please update to latest upstream version

[John Paul Adrian Glaubitz]

On Feb 22, 2012, at 11:21 PM, Svante Signell wrote:

> On Wed, 2012-02-22 at 00:32 +0100, Marco d'Itri wrote:
>> On Feb 21, John Paul Adrian Glaubitz  wrote:
>> 
>>> The biggest disadvantage of systemd is surely that it is Linux-only and
>>> probably won't work with other kernels in near future, so it's absolutely
>>> desirable to support several init systems in Debian.
>> No, it's not. If we want to keep supporting the toy ports it is 
>> desirable to use an init system which supports them (or at least can 
>> support them if the porters will provide patches).
>> Quite a different thing.
> 
> That is definitely not systemd. Any proposals, upstart?

I don't think someone is going to seriously port upstart to FreeBSD either.

But I don't see the problem, Debian has the choice. We're not going to drop
system V init anytime soon. Providing both systemd, upstart as well as classical
system V init leaves the up to the user and allows to support non-Linux kernels.

Adrian

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/af37fd2b-8b74-41db-bb09-ed4c3d119...@physik.fu-berlin.de

Re: upstart: please update to latest upstream version

[Svante Signell]

On Wed, 2012-02-22 at 00:32 +0100, Marco d'Itri wrote:
> On Feb 21, John Paul Adrian Glaubitz  wrote:
> 
> > The biggest disadvantage of systemd is surely that it is Linux-only and
> > probably won't work with other kernels in near future, so it's absolutely
> > desirable to support several init systems in Debian.
> No, it's not. If we want to keep supporting the toy ports it is 
> desirable to use an init system which supports them (or at least can 
> support them if the porters will provide patches).
> Quite a different thing.

That is definitely not systemd. Any proposals, upstart?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1329949276.18649.23.ca...@hp.my.own.domain

Bug#660926: ITP: libnet-openssh-compat-perl -- collection of compatibility modules for Net::OpenSSH

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libnet-openssh-compat-perl
  Version : 0.06
  Upstream Author : Salvador Fandiño 
* URL : http://search.cpan.org/perldoc?Net::OpenSSH::Compat
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : collection of compatibility modules for Net::OpenSSH

Net::OpenSSH::Compat and submodules are a set of adapter modules that
run on top of Net::OpenSSH providing the APIs of other SSH modules
available from CPAN. Currently, there are adapters available for
Net::SSH, Net::SSH2 and Net::SSH::Perl. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2012013026.11413.40518.report...@island.zedat.fu-berlin.de

Bug#660923: ITP: libnet-openssh-perl -- Perl SSH client package implemented on top of OpenSSH

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libnet-openssh-perl
  Version : 0.57 
  Upstream Author : Salvador Fandiño 
* URL : http://search.cpan.org/perldoc?Net::OpenSSH
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : Perl SSH client package implemented on top of OpenSSH

Net::OpenSSH is a secure shell client package implemented on top of the
OpenSSH binary client (ssh), leveraging the multiplexing feature found
in current versions of OpenSSH. That is, when a new Net::OpenSSH object
is created, ssh is run in master mode establishing a permanent
connection. Then, every time a new operation is requested, a new ssh
process is started in slave mode, reusing the master SSH
connection to send the request to the remote side. This makes
Net::OpenSSH very fast, as most of the latency of ssh is intrinsic to
the protocol.
..
If you like the API of other Perl SSH distributions like Net::SSH,
Net::SSH2 or Net::SSH::Perl, and would like to use them with
Net::OpenSSH, have a look at the libnet-openssh-compat-perl package.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2012012603.6532.48274.report...@island.zedat.fu-berlin.de

Re: upstart: please update to latest upstream version

[Thijs Kinkhorst]

On Wed, February 22, 2012 14:42, Stephan Seitz wrote:
> On Wed, Feb 22, 2012 at 03:24:47PM +0200, Riku Voipio 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
>
> I don't doubt it, but the question is, who cares if the boot process
> takes a little bit longer?
> The desktop users I know are fetching their coffee while the system is
> booting.
> The modern servers with e.g. RAID controllers are needing much more time
> from power-on to the grub screen than from grub screen to getty prompt.

Modern servers are virtual machines. They take hardly any noticeable time
from 'power-on' to the grub screen, so how fast the boot process is, is
really decided in the shell script phase. If from time to time you have to
reboot during production hours it's really useful that Squeeze boots up so
much faster than Lenny, and even faster would be even better.


Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/9318f429c3f0f0b3e1d402ffd2b75bdb.squir...@wm.kinkhorst.nl

Re: upstart: please update to latest upstream version

[Josselin Mouette]

Le mercredi 22 février 2012 à 15:43 +0100, Stephan Seitz a écrit : 
> True, but the question is: does the new system solves more problems than 
> it creates? And are the solved problems worth the disadvantages? For 
> a faster boot process?

Upstart and systemd were not written just to improve boot process. There
is a variety of problems that you cannot solve without using an
event-based init system.

> As I said, if you can save some seconds without breaking things, fine.  
> But for now we don’t have any numbers if the majority of Debian users 
> wants to take the risk or are concerned about some saved seconds.

I’m more concerned about the amount of problems that we will have if we
DON’T switch to a modern init system.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1329926738.3297.1306.camel@pi0307572

Re: upstart: please update to latest upstream version

[Stephan Seitz]

On Wed, Feb 22, 2012 at 03:09:51PM +, Ben Hutchings wrote:

The desktop users I know are fetching their coffee while the system is
booting.

What if they have to reboot in the middle of the day due to a kernel
upgrade?


Then they are taking a coffee break or they wait until they haved 
finished their work and switch off their system anyway.

Or they clean up their desk. Or they do some paper work.

We are talking about a minute or so. When they are annoyed, it is not 
because of the reboot time but because they have to save and close all 
their applications.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

[Paul Wise]

On Wed, Feb 22, 2012 at 11:09 PM, Ben Hutchings wrote:

> They also don't get turned off very often, but they do get rebooted.  It
> should be possible to avoid that long delay by using kexec, though I've
> never looked into how well that works in Debian.

I tried that today with my laptop running Linux 3.2.4-1 and systemd
and was pleasantly surprised when it worked, which I wasn't expecting.
Not sure how much time using it saved though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6GpavPnOEMYVnnMjCvfPZ8UrV2eneBEqrP=wm84pxg...@mail.gmail.com

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Tollef Fog Heen]

]] Roger Leigh 

> >   Line 3: "UTC" or "LOCAL".  Tells whether the Hardware Clock is set to
> >   Coordinated Universal Time or local time.  You can always override
> >   this value with options on the hwclock command line.
> 
> If you saw my mail of a couple of days ago, I have made patches
> for util-linux and clock-setup to enable this.

Yup, I'm catching up on mail after holidays and responded without
reading all the threads.

It's good to see it's moving in the right direction. :-)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqd6j3kc@qurzaw.varnish-software.com

Re: upstart: please update to latest upstream version

[Russ Allbery]

Mike Hommey  writes:
> On Tue, Feb 21, 2012 at 04:25:22PM -0800, Russ Allbery wrote:

>> I would like to stop writing the same complex 50-line shell script with
>> the same obscure and weird workarounds and strange conventions every time
>> I package another piece of software that runs a daemon.  Instead, I'd like
>> to just say "run this daemon with these arguments" and dispense with all
>> the obnoxious boilerplate.

> Arguably, you don't need upstart or systemd for that. See the gentoo
> startup scripts for something that's very much less of a burden to
> manage.

Sure.  But you end up having to build all the functionality that's in
upstart and systemd to do it.

I'm pragmatic; if someone does the work that way instead, I'm happy to use
it.  But upstart and systemd do solve my problems.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obsqew06@windlord.stanford.edu

Re: upstart: please update to latest upstream version

[Ben Hutchings]

On Wed, 2012-02-22 at 14:42 +0100, Stephan Seitz wrote:
> On Wed, Feb 22, 2012 at 03:24:47PM +0200, Riku Voipio 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 
> 
> I don’t doubt it, but the question is, who cares if the boot process 
> takes a little bit longer?
> The desktop users I know are fetching their coffee while the system is 
> booting.

What if they have to reboot in the middle of the day due to a kernel
upgrade?

> The modern servers with e.g. RAID controllers are needing much more time 
> from power-on to the grub screen than from grub screen to getty prompt.

They also don't get turned off very often, but they do get rebooted.  It
should be possible to avoid that long delay by using kexec, though I've
never looked into how well that works in Debian.

Ben.

> So while shellscripts may have maintenance issues, I don’t think 
> performance issues are a problem.
> 
> Shade and sweet water!
> 
>   Stephan
> 

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.


signature.asc
Description: This is a digitally signed message part

Re: upstart: please update to latest upstream version

[Stephan Seitz]

On Thu, Feb 23, 2012 at 01:18:41AM +1100, Russell Coker wrote:
Desktop users have a variety of different ways of using systems.  Some 
people like my parents turn their computer on when they are about to use 
it and watch it boot. It doesn't hurt to have a desktop system boot 
quickly while unattended but the attended boot times are annoying.


Well, my mother is sitting next to her computer as well while it is 
booting. But she has enough patience to wait. It only takes about 
a minute at most. I think I waisted more time at bus or train stations.


While there are a variety of problems we have to concentrate on the ones 
that we can solve.


True, but the question is: does the new system solves more problems than 
it creates? And are the solved problems worth the disadvantages? For 
a faster boot process?


Also as has been previously noted there is the case of virtual machines 
which have no BIOS delays etc. It would be nice to be able to reboot 
a virtual machine providing a service so quickly that the users barely 
notice the downtime.


In my experience VMs are booting faster than their hardware pendants.  
I have some system in VMs for testing purposes, and they are booting 
faster than the real systems.


As I said, if you can save some seconds without breaking things, fine.  
But for now we don’t have any numbers if the majority of Debian users 
wants to take the risk or are concerned about some saved seconds.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Re: upstart: please update to latest upstream version

[Uoti Urpala]

Steve Langasek wrote:
> The meme that systemd is better than upstart because it doesn't depend on
> a shell is poppycock.  No one has done any benchmarking to support the claim
> that /bin/sh is a bottleneck for upstart (particularly not on Debian or

This misrepresents the systemd position. Not using a shell is faster,
but that's not the only reason to avoid shell. Avoid shell in cases
where it's unnecessary would still be a net win even if it was somewhat
slower.

> OTOH, there are plenty of examples
> of how the limited use of upstart's built-in support for shell scripts makes
> for much more maintainable - and locally-modifiable - startup behavior than
> if this were all implemented in C.

This doesn't seem to match the experience of other people.

You made similar questionable claims earlier (see my reply then at
http://lists.debian.org/debian-devel/2011/07/msg00365.html
). You imply systemd design decisions are based solely on boot speed, to
the detriment of other features. This claim is false. You may disagree
with those design decisions, but it's a fact that they were chosen
because they were (and are) considered good for goals like
maintainability rather than just boot speed. You make claims about
"hard-coding policy into C", but have given no examples of concrete
problems or limitations. What is actually hard-coded so hard that it
would cause problems?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1329920064.5387.25.camel@glyph.nonexistent.invalid

Re: upstart: please update to latest upstream version

[Bernhard R. Link]

* Stephan Seitz  [120222 14:49]:
> I don’t doubt it, but the question is, who cares if the boot process
> takes a little bit longer?

Well, time to boot is quite important for many people, me included.

I would never want a system without shell scripts, though.
Booting (and shutting down) is a far too complex issue, so it will
never work perfectly. Not being able to fix a little shell script
or add some echos to some to see what actually fails is just too
brittle for non-toy usage. (Not to mention that most people will
simply not have the skills to fix a problem within some C daemon with
plugins, so using systemd will be quite a costly bet for most people)

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120222140818.ga5...@client.brlink.eu

Re: upstart: please update to latest upstream version

[Russell Coker]

On Thu, 23 Feb 2012, Stephan Seitz  wrote:
> I don’t doubt it, but the question is, who cares if the boot process 
> takes a little bit longer?
> The desktop users I know are fetching their coffee while the system is 
> booting.

Desktop users have a variety of different ways of using systems.  Some people 
like my parents turn their computer on when they are about to use it and watch 
it boot.  It doesn't hurt to have a desktop system boot quickly while 
unattended but the attended boot times are annoying.

> The modern servers with e.g. RAID controllers are needing much more time 
> from power-on to the grub screen than from grub screen to getty prompt.

While there are a variety of problems we have to concentrate on the ones that 
we can solve.

Also as has been previously noted there is the case of virtual machines which 
have no BIOS delays etc.  It would be nice to be able to reboot a virtual 
machine providing a service so quickly that the users barely notice the 
downtime.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202230118.41858.russ...@coker.com.au

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Roger Leigh]

On Wed, Feb 22, 2012 at 10:14:49AM +0100, Tollef Fog Heen wrote:
> ]] Roger Leigh 
> 
> > Just FYI, please see #659451.  I've split the UTC variable into
> > /etc/default/hwclock, which means /etc/default/rcS can become a
> > regular dpkg conffile (in current git only for now).  This needs
> > support in d-i clock-setup (done) and util-linux (pending) before
> > upload.
> 
> I really wish we could just use /etc/adjtime instead, from hwclock(8):
> 
>   The format of the adjtime file is, in ASCII:
> 
> [...]
> 
>   Line 3: "UTC" or "LOCAL".  Tells whether the Hardware Clock is set to
>   Coordinated Universal Time or local time.  You can always override
>   this value with options on the hwclock command line.

If you saw my mail of a couple of days ago, I have made patches
for util-linux and clock-setup to enable this.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120222140103.gd24...@codelibre.net

Re: upstart: please update to latest upstream version

[Gergely Nagy]

Stephan Seitz  writes:

> On Wed, Feb 22, 2012 at 03:24:47PM +0200, Riku Voipio 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 
>
> I don’t doubt it, but the question is, who cares if the boot process
> takes a little bit longer?

I do care. I boot and shutdown virtual machines rather often, in a boot,
get things done, shutdown, next machine cycle. If I can shave off a few
seconds from the boot time, I will.

On desktops and servers, I couldn't care less, either, but on the
virtual machines I keep poking on and off, every second counts.

-- 
|8]


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehtnx929.fsf@algernon.balabit

Re: leaks in our only-signed-software fortress

[Henrique de Moraes Holschuh]

On Tue, 21 Feb 2012, Gunnar Wolf wrote:
> Henrique de Moraes Holschuh dijo [Sat, Feb 18, 2012 at 10:46:50AM -0200]:
> > Good packaging developers go to great lengths to be sure they are not
> > going to distribute anything trojaned.  This takes a lot of work, and
> > often requires very goot working relationship with upstream to the point
> > of getting upstream to change his processes.  This does include tracking
> > deviations from VCS to upstream releases, going over upstream changes
> > when possible, and using crypto properly to verify authenticity of
> > upstream commits and tarballs (when available.  When it is not
> > available, educating upstream about it is required).
> 
> Sadly, I think this is more propaganda and wishful thinking than
> reality. And if I'm going to badmouth somebody, I'll badmouth myself.

Well, for all the stuff I've been downstream of, I think I've managed to do
it for everything but hplip.  It really means you have to track upstream VCS
and look at the changes very often, because when they pile up...  for hplip,
I had to do it by skimming the changes and looking for obvious crap, as the
volume was too big and it came as a code dump instead of incremental
changes.  And even just skimming the changes took a few hours, and I had to
just plain ignore any changes to the PPD files or I'd go insane.

Closed development and code dumps are nasty.

Tracking deviations is a matter of instrumenting things properly, and it
adds barely an hour per release after you've got things set up.  Basically,
it requires a good VCS, tracking upstream VCS, and tracking upstream
tarball/whatever releases, and using the VCS diff :p   When there is no
upstream VCS, there are no deviations to track, and likely the most you can
do is to pester upstream to do proper release signatures.

It can get worse.  The worst upstream I have about it so far is Intel's
processor microcode people.  Unsigned releases, absolutely impossible to
contact upstream except indirectly by asking favours of some Intel employees
that can be found on LKML, what looks from the outside to be an absolute
nutjob of a microcode release management...  The best I could do there was
to expose the weirdness as a commented changelog of the timeline of each
microcode[1], track deviations in each microcode (hash every opaque blob
inside the metadata container and track it across every public microcode
release since 2008 -- no deviations found to date), and add some guard time
between upstream releases and Debian releases.

[1] The package has the full changelog, but the relevant portions for each
new release are also in the Debian changelog:

http://packages.debian.org/changelogs/pool/non-free/i/intel-microcode/current/changelog

> So, either I am among Debian's biggest liabilities, or your paragraph
> reflects what we want others to think about us. My packages tend not
> to break, and I think they meet Debian's standards, but they are far
> from audited by me.

You should not limit yourself to just that paragraph when reading what I
wrote.  It is far less about auditing, and far more about doing what is
possible to try to shield the users from trojans added by a third-party to
the release distribution points and public VCS (and not by a rogue upstream
-- that one can be avoided only if you audit everything, and that's often
downright impossible).

Only you can judge whether you could/should/need to do better.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120222135808.ga21...@khazad-dum.debian.net

Re: upstart: please update to latest upstream version

[Stephan Seitz]

On Wed, Feb 22, 2012 at 03:24:47PM +0200, Riku Voipio 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 


I don’t doubt it, but the question is, who cares if the boot process 
takes a little bit longer?
The desktop users I know are fetching their coffee while the system is 
booting.
The modern servers with e.g. RAID controllers are needing much more time 
from power-on to the grub screen than from grub screen to getty prompt.


So while shellscripts may have maintenance issues, I don’t think 
performance issues are a problem.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: nm.debian.org web site not responding

[Paul Wise]

On Wed, Feb 22, 2012 at 9:43 PM, olivier sallou wrote:

> the web site
>
> https://nm.debian.org/nmlist.php
>
> has a forbidden access error for a few days.

There were some security issues so it is down until they are fixed.

> Do you know who we should contact ?

Normally the #debian-newmaint IRC channel or the debian-newmaint mailing list.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6FfkL=98=yg+79djz8bky07gswrj32_xvojedc6yr9...@mail.gmail.com

nm.debian.org web site not responding

[olivier sallou]

Hi,
the web site

https://nm.debian.org/nmlist.php

has a forbidden access error for a few days. Do you know who we should
contact ?

Thanks

Olivier

-- 

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: upstart: please update to latest upstream version

[Riku Voipio]

On Tue, Feb 21, 2012 at 01:12:08PM -0800, Steve Langasek wrote:
> The meme that systemd is better than upstart because it doesn't depend on
> a shell is poppycock.  No one has done any benchmarking to support the claim
> that /bin/sh is a bottleneck for upstart (particularly not on Debian or
> Ubuntu, where /bin/sh is dash, not bash);

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 shell scripts.
The event based architecture however forced much more shell scripting[1]
that made the boot time improvement much less than hoped.

Riku

[1] stuff like this:

-snip-
post-start script
# wait until daemon is ready
timeout=6
while [ ! -e /var/run/cups/cups.sock ]; do 
sleep 0.5
timeout=$((timeout-1))
-snip-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120222132447.ga6...@afflict.kos.to

Re: Multiarch file overlap summary and proposal

[Goswin von Brederlow]

Jonathan Nieder  writes:

> Jonathan Nieder wrote:
>> David Kalnischkies wrote:
>
>>> Why would it be intuitive to add a specific value for the arch attribute 
>>> with
>>> apt-get install foo   # arch |= native
>>> but remove all values of the attribute with
>>> apt-get remove foo# arch &= ~all-architectures
>>> ?
> [...]
>> But I really think this is something anyone can get used to.  In the
>> examples you listed above:
>>
>>  apt-get install foo;# install foo with default arch-list (native)
>>  apt-get remove foo; # remove foo
>>
>> If foo is installed for no architectures, that does not mean it is
>> installed with an empty architecture list.  It means it is simply not
>> installed.
>
> Ok, now I think I figured out the inconsistency you are pointing to.
> If i386 is the native architecture, what would you expect the
> following sequence of commands to do?
>
>   apt-get install linux-image-3.2.0-1-amd64:amd64
>
>   ... wait a few weeks ...
>
>   apt-get install linux-image-3.2.0-1-amd64
>
> I would expect it to install the kernel with 'Architecture: amd64' and
> then to upgrade it.
>
> So the proposed semantics are not quite 'arch |= native'.  They are
> more like 'arch defaults to native for non-installed packages'.
>
> Jonathan

Assuming linux-image-3.2.0-1-amd64:i386 still exists I would expect apt
to install that if it has a equal or greater version than the installed
linux-image-3.2.0-1-amd64:amd64.

Current apt behaviour is a bit strange there though:

mrvn@frosties:~% apt-cache policy acl
acl:
  Installed: 2.2.51-4
  Candidate: 2.2.51-5
  Version table:
 2.2.51-5 0
500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages
 *** 2.2.51-4 0
100 /var/lib/dpkg/status

mrvn@frosties:~% apt-cache policy acl:i386
acl:i386:
  Installed: (none)
  Candidate: 2.2.51-5
  Version table:
 2.2.51-5 0
500 http://ftp.de.debian.org/debian/ sid/main i386 Packages

I would expect something like:

mrvn@frosties:~% apt-cache policy acl
acl:
  Installed: 2.2.51-4 amd64
  Candidate: 2.2.51-5 amd64
  Version table:
 2.2.51-5 0
500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages
499 http://ftp.de.debian.org/debian/ sid/main i386 Packages
 *** 2.2.51-4 0
100 /var/lib/dpkg/status amd64


But it seems my patch to reduce the pin of non-native architectures is
not in current apt and policy doesn't list all archs for M-A:foreign
packages.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4xn4171.fsf@frosties.localnet

Re: upstart: please update to latest upstream version

[Petter Reinholdtsen]

[Thomas Goirand]
> We are wasting a lot of time writing complex init.d scripts when all
> these should be automated to begin with. This is error prone, and
> gets even more complex if you want to support all what's needed: the
> VERBOSE variable, [ -x $DAEMON ] || exit 0, default files holding
> DAEMON_START=1 and other options, dependency to lsb-base, and so
> much more...

I agree.  And I believe it would be perfectly possible to cut down the
init.d scripts to only list the special settings for a given package
and fetch the boilerplate code from a common location.  See metainit
and bug report #651004 for some ideas on how this could be done for
init.d scripts.
-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl8vjvp5au@login1.uio.no

Bug#660842: ITP: python-gnupg -- python wrapper for the gnupg command

[Elena Grandi]

Package: wnpp
Severity: wishlist
Owner: Elena Grandi 

* Package name: python-gnupg
  Version : 0.2.8
  Upstream Author : Vinay Sajip 
* URL : http://code.google.com/p/python-gnupg/
* License : BSD
  Programming Lang: Python
  Description : python wrapper for the gnupg command

python-gnupg is a python module that wraps the gnupg command 
and allows to generate and manage keys, encrypt and decrypt data, 
sign and verify messages in a pythonic way.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120222094005.12009.21921.reportbug@genesis

Re: [Debian-l10n-devel] DDTSS broken

[Michael Bramer]

On 02/22/2012 03:10 AM, Cyril Brulebois wrote:

Martin Eberhard Schauer  (21/02/2012):

As I can't magically fix all this by myself, I think that the only
choice I have is detailing the simple alternative we have:

- revert the change that drop long descriptions from Packages files

- live with the localization effort of packages descriptions being
   broken and several localization teams demotivated

... especially the most active ones until now

The next step after fixing the bug will be cleaning the database
from about 30+K useless entrys.


On ddtp.debian.org should be a database dump from last year...

Maybe we should import this dump... and start a new importer...

Gruss
Michael Bramer

http://www.deb-support.de/
email: m.bra...@deb-support.de
Tel: +49 170 2253865


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f44a472.8030...@deb-support.de

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Tollef Fog Heen]

]] Roger Leigh 

> Just FYI, please see #659451.  I've split the UTC variable into
> /etc/default/hwclock, which means /etc/default/rcS can become a
> regular dpkg conffile (in current git only for now).  This needs
> support in d-i clock-setup (done) and util-linux (pending) before
> upload.

I really wish we could just use /etc/adjtime instead, from hwclock(8):

  The format of the adjtime file is, in ASCII:

[...]

  Line 3: "UTC" or "LOCAL".  Tells whether the Hardware Clock is set to
  Coordinated Universal Time or local time.  You can always override
  this value with options on the hwclock command line.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wr7fjkl2@qurzaw.varnish-software.com

Re: upstart: please update to latest upstream version

[Tollef Fog Heen]

]] Thomas Goirand 

> In what way do we have a choice as a user?
> 1/ upstart Conflicts: with sysvinit.
> 2/ none of our (providing daemon) packages carry an upstart
> script (of course, because if they did, they would depend on
> upstart, which breaks everything because of 1/).

No, they wouldn't need to depend on upstart any more that packages
shipping .service files depend on systemd.

> So our users have basically no choice. It's not only pretty useless,
> to have upstart in Debian, but it breaks everything when it installs!
> I'd even be tempted to fill a bug report with severity critical:
> "makes unrelated software on the system (or the whole system) break"

What breaks if you install upstart?  Sure, sysvinit gets removed, but
upstart installs quite happily and is a fully functional init.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871upnkzao@qurzaw.varnish-software.com

Re: upstart: please update to latest upstream version

[Tollef Fog Heen]

]] Steve Langasek 

> Please tell me why it would be better to implement the attached upstart job
> in C code within pid 1.

Not that the functionality implemented by the upstart job is C code
within pid 1 with systemd either.  (It's C code, but it lives in
/lib/systemd/systemd-update-utmp which is called by the
systemd-update-utmp-runlevel service.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762ezkzg7@qurzaw.varnish-software.com

Re: upstart: please update to latest upstream version

[Mike Hommey]

On Tue, Feb 21, 2012 at 04:25:22PM -0800, Russ Allbery wrote:
> "John D. Hendrickson and Sara Darnell"  writes:
> 
> > I also fail to see how upstart or systemd add anything new while they
> > obscure or delete previous good work (by suggesting init(1) is to be
> > deleted).
> 
> I would like to stop writing the same complex 50-line shell script with
> the same obscure and weird workarounds and strange conventions every time
> I package another piece of software that runs a daemon.  Instead, I'd like
> to just say "run this daemon with these arguments" and dispense with all
> the obnoxious boilerplate.

Arguably, you don't need upstart or systemd for that. See the gentoo
startup scripts for something that's very much less of a burden to
manage.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120222090438.ga29...@glandium.org

Re: upstart: please update to latest upstream version

[Josselin Mouette]

Le mardi 21 février 2012 à 23:37 +0100, John Paul Adrian Glaubitz a
écrit : 
> The biggest disadvantage of systemd is surely that it is Linux-only and
> probably won't work with other kernels in near future, so it's absolutely
> desirable to support several init systems in Debian.

What is the benefit, for our users, to be able to choose between two
implementations?

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1329900751.3297.1189.camel@pi0307572