Re: systemd now appears to be only possible init system in testing

[Vincent Bernat]

 ❦ 25 juillet 2014 16:19 -0700, Russ Allbery  :

>> I thought that start-stop-daemon (and status_of_proc) returned the
>> correct codes, and whatever it returns you can relay / let the shell
>> catch? The script is here
>> (https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted to
>> take a look.
>
> It does not, at least not the way that you're calling it.
>
> If you used --oknodo in a few places, it might be closer, but take a look
> at /etc/init.d/skeleton and look at the exit status remapping that it
> does.

Some time ago, /etc/init.d/skeleton has been modified to make use of
init-d-script.
-- 
printk("Entering UltraSMPenguin Mode...\n");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c


signature.asc
Description: PGP signature

can't submit bugs

[Salvo Tomaselli]

Hello,

whenever I try to send a bug with reportbug to sub...@bugs.debian.org, I get a 
failure notification

550 malware detected: Sanesecurity.Junk.3451.UNOFFICIAL: message rejected


So, I can't open bugs.

I don't know who is in charge for that, so I thought I'd write here.

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/6212338.G0RazzDFlK@hal9000

Re: Bug#756082: ITP: librevenge -- base library for writing document import filters

[Scott Kitterman]

On Saturday, July 26, 2014 01:49:06 Mattia Rizzolo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mattia Rizzolo 
> 
> * Package name: librevenge
>   Version : 0.0.1
>   Upstream Author : David Tardon  (and others)
> * URL :
> http://sourceforge.net/p/libwpd/librevenge/ci/master/tree/ * License   
>  : MPL2+/LGPGL2.1
>   Programming Lang: C++
>   Description : base library for writing document import filters
> 
> librevenge is a base library for writing document import filters. It has
> interfaces for text documents, vector graphics, spreadsheets and
> presentations.
> 
> 
> librevenge will be a build-dep of the new release of scribus-ng.
> I plan to start working on it in early 2014 September.

Already packaged:

 librevenge | 0.0.1-1 | experimental | source

Scott K

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

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Russ Allbery (r...@debian.org):
> Cameron Norman  writes:
> 
> > Oh this is easy. The init script calls s-s-d and does not check the return
> > code (so always exits 0). I am just going to use set -e in the init
> > script, only a couple tweaks are needed.
> 
> Please don't use set -e in init scripts.  See Policy 9.3.2:
> 
> Be careful of using set -e in init.d scripts.  Writing correct init.d
> scripts requires accepting various error exit statuses when daemons
> are already running or already stopped without aborting the init.d
> script, and common init.d function libraries are not safe to call with
> set -e in effect.  For init.d scripts, it's often easier to not use
> set -e and instead check the result of each command separately.
> 
> Not mentioned there is another problem, namely that LSB mandates
> particular exit codes for particular conditions in init scripts, and set
> -e will not produce the correct exit codes.

No worries, I've gone a different route - borrowing heavily (and
appreciatively) from the libvirt init scripts.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725233710.GS31507@ubuntumail

Bug#756082: ITP: librevenge -- base library for writing document import filters

[Mattia Rizzolo]

Package: wnpp
Severity: wishlist
Owner: Mattia Rizzolo 

* Package name: librevenge
  Version : 0.0.1
  Upstream Author : David Tardon  (and others)
* URL : http://sourceforge.net/p/libwpd/librevenge/ci/master/tree/
* License : MPL2+/LGPGL2.1
  Programming Lang: C++
  Description : base library for writing document import filters

librevenge is a base library for writing document import filters. It has
interfaces for text documents, vector graphics, spreadsheets and presentations.


librevenge will be a build-dep of the new release of scribus-ng.
I plan to start working on it in early 2014 September.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-25 23:04:55 +0200, Michael Biebl wrote:
> Am 25.07.2014 22:43, schrieb Vincent Lefevre:
> > On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
> >> And we already concluded that you need to logout anyway, even with
> >> systemd-shim. A reboot and relogin isn't that much different from a
> >> users POV.
> > 
> > Screen sessions, SSH sessions and computation processes running in
> > background are lost after a reboot, not after a relogin.
> 
> You are doing a dist-upgrade while there are running computation
> processes? That sounds like a recipe for disaster.

I have a Debian/unstable desktop machine that permanently runs
computation processes, so yes. However I don't really mind if
they are aborted. I'm more annoyed when losing my screen and SSH
sessions (to the machine). Now, if this happens only once every
few months, that's OK.

What I really meant is that a reboot is quite different from a
relogin: I log out / in again quite often, and if I need a more
permanent session, I use screen.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725232526.ga5...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Cameron Norman  writes:

> I thought that start-stop-daemon (and status_of_proc) returned the
> correct codes, and whatever it returns you can relay / let the shell
> catch? The script is here
> (https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted to
> take a look.

It does not, at least not the way that you're calling it.

If you used --oknodo in a few places, it might be closer, but take a look
at /etc/init.d/skeleton and look at the exit status remapping that it
does.

-- 
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: https://lists.debian.org/87tx65hvrd@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 19:23, schrieb Steve Langasek:
> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> cgmanager, implementing the new post-v205 interfaces.  libpam-systemd now
> needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.
> 
> Michael Biebl has said on IRC that he will take care of this in the next
> upload of systemd.

Just a quick followup: After testing cgmanager a bit I stumbled over
various issues which should be fixed first before I'm going to re-add
the alternative dependency. I started filing bugs for them.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 3:42 PM, Russ Allbery  
escribió:

Cameron Norman  writes:

 Oh this is easy. The init script calls s-s-d and does not check the 
return

 code (so always exits 0). I am just going to use set -e in the init
 script, only a couple tweaks are needed.


Please don't use set -e in init scripts.  See Policy 9.3.2:

Be careful of using set -e in init.d scripts.  Writing correct 
init.d
scripts requires accepting various error exit statuses when 
daemons

are already running or already stopped without aborting the init.d
script, and common init.d function libraries are not safe to call 
with
set -e in effect.  For init.d scripts, it's often easier to not 
use

set -e and instead check the result of each command separately.

Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and 
set

-e will not produce the correct exit codes.


I thought that start-stop-daemon (and status_of_proc) returned the 
correct codes, and whatever it returns you can relay / let the shell 
catch? The script is here 
(https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted 
to take a look.


Best,
--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:
> On Fri, Jul 25, 2014 at 11:44:43PM +0200, Michael Biebl wrote:

>> Ah perfect. Seems this just hasn't hit the archive yet when I installed
>> cgmanager.

>> Steve, could you please bump the depends on cgmanager in systemd-shim
>> accordingly to ensure a working cgmanager is installed?

> No, I'm not going to reupload the package to declare an incompatibility with
> a version of a dependency that was in unstable less than a day before
> getting fixed.

I concur -- not every bug is worth tightening dependencies.

-- 
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: https://lists.debian.org/87a97xjbz9@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Cameron Norman  writes:

> Oh this is easy. The init script calls s-s-d and does not check the return
> code (so always exits 0). I am just going to use set -e in the init
> script, only a couple tweaks are needed.

Please don't use set -e in init scripts.  See Policy 9.3.2:

Be careful of using set -e in init.d scripts.  Writing correct init.d
scripts requires accepting various error exit statuses when daemons
are already running or already stopped without aborting the init.d
script, and common init.d function libraries are not safe to call with
set -e in effect.  For init.d scripts, it's often easier to not use
set -e and instead check the result of each command separately.

Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and set
-e will not produce the correct exit codes.

-- 
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: https://lists.debian.org/87egx9jc0h@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 11:44:43PM +0200, Michael Biebl wrote:
> Ah perfect. Seems this just hasn't hit the archive yet when I installed
> cgmanager.

> Steve, could you please bump the depends on cgmanager in systemd-shim
> accordingly to ensure a working cgmanager is installed?

No, I'm not going to reupload the package to declare an incompatibility with
a version of a dependency that was in unstable less than a day before
getting fixed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725221426.gd31...@virgil.dodds.net

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 2:50 PM, Steve Langasek 
 escribió:

On Fri, Jul 25, 2014 at 11:10:41PM +0200, Michael Biebl wrote:

 Am 25.07.2014 19:23, schrieb Steve Langasek:
 > systemd-shim 6-4 has now been uploaded to unstable with a 
dependency on
 > cgmanager, implementing the new post-v205 interfaces. 



 I just installed systemd-shim 6-4 and cgmanager 0.28-1.
 Unfortunately the cgmanager package seems to be not quite ready yet.



 The init script fails with



 # service cgmanager start
 [] Starting cgroup management daemon: cgmanagercgmanager: Failed
 mounting memory onto /run/cgmanager/fs/memory: No such file or 
directory

 cgmanager: Failed mounting cgroups
 cgmanager: Failed to set up cgroup mounts
 . ok



 on a default jessie kernel.


I believe this is bug #755990, already fixed by Serge in 0.28-2.


 Interestingly, the return code of the init script was 0.


Hmm, dunno about that.  Serge?


Oh this is easy. The init script calls s-s-d and does not check the 
return code (so always exits 0). I am just going to use set -e in the 
init script, only a couple tweaks are needed. I will get a merge 
request to the github repo in about 15 minutes.


Cheers,
--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Michael Biebl (bi...@debian.org):
> Hi Serge!
> 
> Am 25.07.2014 23:35, schrieb Serge Hallyn:
> > Quoting Michael Biebl (bi...@debian.org):
> >> Am 25.07.2014 19:23, schrieb Steve Langasek:
> >>> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> >>> cgmanager, implementing the new post-v205 interfaces. 
> >>
> >> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> >> Unfortunately the cgmanager package seems to be not quite ready yet.
> >>
> >> The init script fails with
> >>
> >> # service cgmanager start
> >> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> >> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> >> cgmanager: Failed mounting cgroups
> >> cgmanager: Failed to set up cgroup mounts
> >> . ok
> > 
> > That was an upstream bug, should be fixed in 0.28-2.  The default of
> > having memory show up in /proc/cgroups but not be mountable was being
> > mishandled.
> 
> Ah perfect. Seems this just hasn't hit the archive yet when I installed
> cgmanager.
> 
> Steve, could you please bump the depends on cgmanager in systemd-shim
> accordingly to ensure a working cgmanager is installed?
> 
> > There was also mention of having a systemd unit linked to /dev/null to
> > not run cgmanager in systemd.  I assume that's what systemd itself would
> > actually prefer and I'm fine with it, but for the sake of supporting
> > nested containers it would be nicer if we could have it actually run
> > (for now).
> 
> If cgmanager and systemd don't step on each others toes and there is
> value running cgmanager besides systemd, it might make sense to also run
> it under systemd.
> 
> My only concern would be, that most users probably don't need nested
> containers and if cgmanager is pulled in as a depends on systemd-shim,
> they'd have a useless daemon running.
> 
> What about shipping a native .service file for cgmanager, but not enable
> it by default, i.e. the admin would have to run
> systemctl enable cgmanager.service
> if want's to run cgmanager under systemd.
> 
> That means, under sysvinit the service would be running by default and
> under systemd it would have to be enabled explicitly.
> 
> Would that work for you?

Sure - I don't know offhand how this would be done, but I'll look into it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725221022.GO31507@ubuntumail

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Michael Biebl (bi...@debian.org):
> 
> Am 25.07.2014 23:35, schrieb Serge Hallyn:
> > Quoting Michael Biebl (bi...@debian.org):
> >>
> >> The init script fails with
> >>
> >> # service cgmanager start
> >> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> >> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> >> cgmanager: Failed mounting cgroups
> >> cgmanager: Failed to set up cgroup mounts
> >> . ok
> > 
> > 
> >> on a default jessie kernel.
> >>
> >> Interestingly, the return code of the init script was 0.
> 
> Could you please also look into this.
> 
> The init script shouldn't have an exit code of 0 if the daemon failed to
> start.
> 
> Thanks!

D'oh, yup, that's a real bug in the (upstream) sysvinit job.  Thanks.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725220636.GN31507@ubuntumail

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 11:10:41PM +0200, Michael Biebl wrote:
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> > cgmanager, implementing the new post-v205 interfaces. 

> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> Unfortunately the cgmanager package seems to be not quite ready yet.

> The init script fails with

> # service cgmanager start
> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> cgmanager: Failed mounting cgroups
> cgmanager: Failed to set up cgroup mounts
> . ok

> on a default jessie kernel.

I believe this is bug #755990, already fixed by Serge in 0.28-2.

> Interestingly, the return code of the init script was 0.

Hmm, dunno about that.  Serge?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 23:35, schrieb Serge Hallyn:
> Quoting Michael Biebl (bi...@debian.org):
>>
>> The init script fails with
>>
>> # service cgmanager start
>> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
>> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
>> cgmanager: Failed mounting cgroups
>> cgmanager: Failed to set up cgroup mounts
>> . ok
> 
> 
>> on a default jessie kernel.
>>
>> Interestingly, the return code of the init script was 0.

Could you please also look into this.

The init script shouldn't have an exit code of 0 if the daemon failed to
start.

Thanks!


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Hi Serge!

Am 25.07.2014 23:35, schrieb Serge Hallyn:
> Quoting Michael Biebl (bi...@debian.org):
>> Am 25.07.2014 19:23, schrieb Steve Langasek:
>>> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
>>> cgmanager, implementing the new post-v205 interfaces. 
>>
>> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
>> Unfortunately the cgmanager package seems to be not quite ready yet.
>>
>> The init script fails with
>>
>> # service cgmanager start
>> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
>> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
>> cgmanager: Failed mounting cgroups
>> cgmanager: Failed to set up cgroup mounts
>> . ok
> 
> That was an upstream bug, should be fixed in 0.28-2.  The default of
> having memory show up in /proc/cgroups but not be mountable was being
> mishandled.

Ah perfect. Seems this just hasn't hit the archive yet when I installed
cgmanager.

Steve, could you please bump the depends on cgmanager in systemd-shim
accordingly to ensure a working cgmanager is installed?

> There was also mention of having a systemd unit linked to /dev/null to
> not run cgmanager in systemd.  I assume that's what systemd itself would
> actually prefer and I'm fine with it, but for the sake of supporting
> nested containers it would be nicer if we could have it actually run
> (for now).

If cgmanager and systemd don't step on each others toes and there is
value running cgmanager besides systemd, it might make sense to also run
it under systemd.

My only concern would be, that most users probably don't need nested
containers and if cgmanager is pulled in as a depends on systemd-shim,
they'd have a useless daemon running.

What about shipping a native .service file for cgmanager, but not enable
it by default, i.e. the admin would have to run
systemctl enable cgmanager.service
if want's to run cgmanager under systemd.

That means, under sysvinit the service would be running by default and
under systemd it would have to be enabled explicitly.

Would that work for you?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 10:46:45PM +0200, Michael Biebl wrote:
> Am 25.07.2014 20:44, schrieb Steve Langasek:
> > Correct.  But it's well-established that, when you upgrade your system,
> > things may be broken in a currently logged-in desktop session until you
> > log out and log back in.

> The release notes actually mention that the system should *not* be
> upgraded from within an X session

That is a bug in the release notes, dating back to the days when X itself
was unreliable enough that you couldn't be confident that it wouldn't bomb
out leaving dpkg in an unclean state.

Nowadays it is reliable, and a desktop user should never need to see a Linux
console, including during upgrades.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Michael Biebl (bi...@debian.org):
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> > cgmanager, implementing the new post-v205 interfaces. 
> 
> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> Unfortunately the cgmanager package seems to be not quite ready yet.
> 
> The init script fails with
> 
> # service cgmanager start
> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> cgmanager: Failed mounting cgroups
> cgmanager: Failed to set up cgroup mounts
> . ok

That was an upstream bug, should be fixed in 0.28-2.  The default of
having memory show up in /proc/cgroups but not be mountable was being
mishandled.

There was also mention of having a systemd unit linked to /dev/null to
not run cgmanager in systemd.  I assume that's what systemd itself would
actually prefer and I'm fine with it, but for the sake of supporting
nested containers it would be nicer if we could have it actually run
(for now).

> on a default jessie kernel.
> 
> Interestingly, the return code of the init script was 0.
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725213503.GL31507@ubuntumail

Re: systemd now appears to be only possible init system in testing

[Adam D. Barratt]

On Fri, 2014-07-25 at 23:10 +0200, Michael Biebl wrote:
> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> Unfortunately the cgmanager package seems to be not quite ready yet.
> 
> The init script fails with
> 
> # service cgmanager start
> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> cgmanager: Failed mounting cgroups
> cgmanager: Failed to set up cgroup mounts
> . ok

That's #755990, which was fixed a couple of hours ago.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1406323916.16854.3.ca...@jacala.jungle.funky-badger.org

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 19:23, schrieb Steve Langasek:
> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> cgmanager, implementing the new post-v205 interfaces. 

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.

The init script fails with

# service cgmanager start
[] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok

on a default jessie kernel.

Interestingly, the return code of the init script was 0.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 22:43, schrieb Vincent Lefevre:
> On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
>> And we already concluded that you need to logout anyway, even with
>> systemd-shim. A reboot and relogin isn't that much different from a
>> users POV.
> 
> Screen sessions, SSH sessions and computation processes running in
> background are lost after a reboot, not after a relogin.

You are doing a dist-upgrade while there are running computation
processes? That sounds like a recipe for disaster.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 20:44, schrieb Steve Langasek:
> Correct.  But it's well-established that, when you upgrade your system,
> things may be broken in a currently logged-in desktop session until you
> log out and log back in.

The release notes actually mention that the system should *not* be
upgraded from within an X session [1] which renders the point about
broken reboot buttons kinda moot.

The release notes also clearly say, that the system should be rebooted
after a dist-upgrade.



[1]
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-preparations
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
> And we already concluded that you need to logout anyway, even with
> systemd-shim. A reboot and relogin isn't that much different from a
> users POV.

Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725204345.ga15...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 10:00:07PM +0200, Michael Biebl wrote:
> Am 25.07.2014 21:20, schrieb Steve Langasek:
> > I can't imagine how anyone can simultaneously hold the view that Debian
> > should use systemd for improved integration with end-user-targeted desktop
> > environments, and believe that Debian should leave these end users grubbing
> > around on the console to do something as fundamental as rebooting their
> > system after upgrade.

> You can always reboot from your display manager.
> All the major ones in Debian support that.

> So no, that's simply incorrect: users don't need to switch to the
> console to reboot their system after a dist-upgrade.

If that's so, then I stand corrected.  I assumed this would fail from the DM
as well as from the desktop.

AIUI other functions, such as suspending the laptop, still fail with
systemd alone until you reboot.  And we do have the means to address this
now.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 12:50:53PM -0700, Russ Allbery wrote:
> Steve Langasek  writes:

> > I can't imagine how anyone can simultaneously hold the view that Debian
> > should use systemd for improved integration with end-user-targeted
> > desktop environments, and believe that Debian should leave these end
> > users grubbing around on the console to do something as fundamental as
> > rebooting their system after upgrade.

> This confuses me, however.  Surely the difference between a one-time
> disruption and ongoing pain is too obvious to need stating?

consolekit was never an ongoing pain for the end users, it was ongoing pain
for the developers and maintainers.  Shunting the pain from the maintainers
to the users is always a bug.  Not always a fixable bug, but nevertheless
not something we should be sanguine about.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 22:00, schrieb Michael Biebl:
> Am 25.07.2014 21:20, schrieb Steve Langasek:
>> I can't imagine how anyone can simultaneously hold the view that Debian
>> should use systemd for improved integration with end-user-targeted desktop
>> environments, and believe that Debian should leave these end users grubbing
>> around on the console to do something as fundamental as rebooting their
>> system after upgrade.
> 
> You can always reboot from your display manager.

And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users POV.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 21:20, schrieb Steve Langasek:
> I can't imagine how anyone can simultaneously hold the view that Debian
> should use systemd for improved integration with end-user-targeted desktop
> environments, and believe that Debian should leave these end users grubbing
> around on the console to do something as fundamental as rebooting their
> system after upgrade.

You can always reboot from your display manager.
All the major ones in Debian support that.

So no, that's simply incorrect: users don't need to switch to the
console to reboot their system after a dist-upgrade.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:
> On Fri, Jul 25, 2014 at 11:42:16AM -0700, Russ Allbery wrote:

>> I continue to be baffled by people's apparent belief that this
>> happening during a major upgrade is some sort of regression.  Having
>> those buttons not work after a major component upgrade, until the X
>> session was restarted, has been typical behavior for as long as I've
>> been using Debian with a desktop environment.

> The distinction is between having to restart your *session* and having
> to restart your *system*.  The systemd/logind issue introduces a
> requirement for the latter, which /is/ a regression.

Yeah, I just figured that out.  I agree that's a regression.

> I can't imagine how anyone can simultaneously hold the view that Debian
> should use systemd for improved integration with end-user-targeted
> desktop environments, and believe that Debian should leave these end
> users grubbing around on the console to do something as fundamental as
> rebooting their system after upgrade.

This confuses me, however.  Surely the difference between a one-time
disruption and ongoing pain is too obvious to need stating?

-- 
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: https://lists.debian.org/87silpkyjm@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:

> The difference here is that, without systemd-shim, logging out and
> logging back in still does not give the user a working session, you
> would have to completely reboot instead.  I think this is an important
> difference in the quality of the upgrade experience.

Ah, *that's* what you're getting at.  Yes, while we can argue about
severity, I agree that's a regression from the previous state of things.

-- 
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: https://lists.debian.org/87wqb1kyt8@windlord.stanford.edu

Re: How Debian should handle users requests?

[Andrei POPESCU]

On Vi, 25 iul 14, 13:26:30, Ian Jackson wrote:
> Arto Jantunen writes ("Re: How Debian should handle users requests?"):
> > I don't think reportbug should allow filing bugs against general at
> > all. The extremely rare cases when one is needed can be filed manually.
> 
> Indeed. If the user tries to do so, it should direct the user to a
> support forum.
> 
> As a more radical suggestion, perhaps it should divert the usual
> output email to debian-user ?  Probably we should ask the inhabitants
> of debian-user what they think of this idea...

I can't speak for other subscribers of -user, but IMNSHO a reportbug 
generated mail that at least includes *some* information about the 
reporter's system would be a net gain compared to some posts :-/

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 11:42:16AM -0700, Russ Allbery wrote:
> Steve Langasek  writes:

> > For the specific case of a change that makes basic desktop functions
> > unusable between upgrade and reboot (including the "reboot" button
> > itself), the right answer is "until it's ready, and if you want it
> > sooner then help."

> I continue to be baffled by people's apparent belief that this happening
> during a major upgrade is some sort of regression.  Having those buttons
> not work after a major component upgrade, until the X session was
> restarted, has been typical behavior for as long as I've been using Debian
> with a desktop environment.

The distinction is between having to restart your *session* and having to
restart your *system*.  The systemd/logind issue introduces a requirement
for the latter, which /is/ a regression.

I can't imagine how anyone can simultaneously hold the view that Debian
should use systemd for improved integration with end-user-targeted desktop
environments, and believe that Debian should leave these end users grubbing
around on the console to do something as fundamental as rebooting their
system after upgrade.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 08:19:14PM +0200, Michael Biebl wrote:
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
> >> ]] Martin Steigerwald 

> >>> Sure I can go through setting up chroot for that, yet I really think if 
> >>> my 
> >>> work requires changes in other packages and the recent systemd changes do 
> >>> require this kind of work, I *help* with these changes, instead of 
> >>> uploading 
> >>> my changes to unstable *before* the other packages have been fixed.

> >> How long are do you think is reasonable to wait then?

> > For the specific case of a change that makes basic desktop functions
> > unusable between upgrade and reboot (including the "reboot" button itself),

> Well, systemd-shim doesn't solve that problem either.
> The policykit package in wheezy uses ConsoleKit as backend.
> So if you're logged into your wheezy desktop, you only have a CK session
> registered. Installing systemd-shim doesn't magically register an active
> logind session.

Correct.  But it's well-established that, when you upgrade your system,
things may be broken in a currently logged-in desktop session until you
log out and log back in.

The difference here is that, without systemd-shim, logging out and logging
back in still does not give the user a working session, you would have to
completely reboot instead.  I think this is an important difference in the
quality of the upgrade experience.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:

> For the specific case of a change that makes basic desktop functions
> unusable between upgrade and reboot (including the "reboot" button
> itself), the right answer is "until it's ready, and if you want it
> sooner then help."

I continue to be baffled by people's apparent belief that this happening
during a major upgrade is some sort of regression.  Having those buttons
not work after a major component upgrade, until the X session was
restarted, has been typical behavior for as long as I've been using Debian
with a desktop environment.

-- 
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: https://lists.debian.org/877g31mgaf@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 19:23, schrieb Steve Langasek:
> On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
>> ]] Martin Steigerwald 
> 
>>> Sure I can go through setting up chroot for that, yet I really think if my 
>>> work requires changes in other packages and the recent systemd changes do 
>>> require this kind of work, I *help* with these changes, instead of 
>>> uploading 
>>> my changes to unstable *before* the other packages have been fixed.
> 
>> How long are do you think is reasonable to wait then?
> 
> For the specific case of a change that makes basic desktop functions
> unusable between upgrade and reboot (including the "reboot" button itself),

Well, systemd-shim doesn't solve that problem either.
The policykit package in wheezy uses ConsoleKit as backend.
So if you're logged into your wheezy desktop, you only have a CK session
registered. Installing systemd-shim doesn't magically register an active
logind session.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Martin Steigerwald]

Am Freitag, 25. Juli 2014, 10:23:02 schrieb Steve Langasek:
> On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
> > ]] Martin Steigerwald
> > 
> > > Sure I can go through setting up chroot for that, yet I really think if
> > > my
> > > work requires changes in other packages and the recent systemd changes
> > > do
> > > require this kind of work, I *help* with these changes, instead of
> > > uploading my changes to unstable *before* the other packages have been
> > > fixed.> 
> > How long are do you think is reasonable to wait then?
> 
> For the specific case of a change that makes basic desktop functions
> unusable between upgrade and reboot (including the "reboot" button itself),
> the right answer is "until it's ready, and if you want it sooner then help."

That is exactly the point I was trying to make.

> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> cgmanager, implementing the new post-v205 interfaces.  libpam-systemd now
> needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.
> 
> Michael Biebl has said on IRC that he will take care of this in the next
> upload of systemd.

Thank you.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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

Re: Let's shrink Packages.xz

[Gerrit Pape]

On Fri, Jul 25, 2014 at 10:07:25AM -0700, Russ Allbery wrote:
> Ian Jackson  writes:
> > But the problem with lots of small packages is not that the Packages.xz
> > has too many bytes.
> > It's that the packaging tools, UIs (for users and developers), and
> > humans, need to think about too many packages.
> > This makes packaging tools slow, UIs cluttered, and humans confused.
> 
> So we need to figure out how to solve that problem.  But "don't package
> things" is not a good solution to that problem, obviously, and "don't
> package small things" or "don't use a packaging structure that works well
> for our tools" aren't much better.

SCNR
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422139#151

Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140725172802.16488.qm...@22ba4216a2609a.315fe32.mid.smarden.org

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
> ]] Martin Steigerwald 

> > Sure I can go through setting up chroot for that, yet I really think if my 
> > work requires changes in other packages and the recent systemd changes do 
> > require this kind of work, I *help* with these changes, instead of 
> > uploading 
> > my changes to unstable *before* the other packages have been fixed.

> How long are do you think is reasonable to wait then?

For the specific case of a change that makes basic desktop functions
unusable between upgrade and reboot (including the "reboot" button itself),
the right answer is "until it's ready, and if you want it sooner then help."

systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces.  libpam-systemd now
needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.

Michael Biebl has said on IRC that he will take care of this in the next
upload of systemd.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: How Debian should handle users requests?

[Abou Al Montacir]

On Fri, 2014-07-25 at 13:24 +0100, Ian Jackson wrote:
> Abou Al Montacir writes ("Re: How Debian should handle users requests?"):
> > On Sun, 2014-07-20 at 17:01 +0200, Adam Borowski wrote:
> > > Suspend quirks are among worst bugs for a non-hacker to report.
> >
> > I fully understand this, but we can not close bugs just because we
> > assume that the user will not be able to debug this and produce relevant
> > bugs.
> 
> On the contrary, we should definitely close bugs which are very
> unlikely to produce any actionable information.
> 
> Ian.
There are two kinds of those bugs: those we won't fix and those we don't
have the time or the courage to fix. The last one shall stay until maybe
someone can fix them.

Cheers,
Abou Al Montacir


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

Re: importing in git the history of a Debian package

[Marco d'Itri]

On Jul 25, Osamu Aoki  wrote:

> Looks like I got a full history.  Can you elaborate where it failed in your 
> case.
Everything that I tried either failed to create the proper structure of 
merges from upstream to debian or just failed to import some of the 
releases.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Thin provisioning Wheezy

[Michael Ryan]

It's my understanding, please correct me if wrong, that LVM thin
provisioning is disabled in Wheezy due to lack of availability of user
tools (at the time).  I've reconfigured the kernel to include thin
provisioning target support but when creating a thin pool I get: "WARNING:
Unrecognized segment type thin...".
How might I re-enable this feature?
Thank you.

Re: systemd now appears to be only possible init system in testing

[Tollef Fog Heen]

]] Martin Steigerwald 

> Sure I can go through setting up chroot for that, yet I really think if my 
> work requires changes in other packages and the recent systemd changes do 
> require this kind of work, I *help* with these changes, instead of uploading 
> my changes to unstable *before* the other packages have been fixed.

How long are do you think is reasonable to wait then?  Back in the big
discussion during the winter, I said we'd want to update around Easter
time.  That left four-ish months for those who wanted to have a logind
that would work without systemd as pid in.  We ended up updating in
early July, which means we're talking about six months or so of warning.

I think there are other people who have simply failed to act at anything
resembling a reasonable pace and that you are putting the blame in the
wrong place.

We want to make sure this actually works well for the people who use the
default init system, after all, and there's a freeze coming up.

-- 
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: https://lists.debian.org/m24my5nzrt@rahvafeir.err.no

Re: Let's shrink Packages.xz

[Russ Allbery]

Ian Jackson  writes:

> But the problem with lots of small packages is not that the Packages.xz
> has too many bytes.

> It's that the packaging tools, UIs (for users and developers), and
> humans, need to think about too many packages.

> This makes packaging tools slow, UIs cluttered, and humans confused.

So we need to figure out how to solve that problem.  But "don't package
things" is not a good solution to that problem, obviously, and "don't
package small things" or "don't use a packaging structure that works well
for our tools" aren't much better.

I think it's important, when looking at a problem like this, to
distinguish between problems that are fixable via a change in policy
versus problems that are only deferrable.  This is a problem that's
deferrable by changing what and how we package, but not fixable.  The
amount of software in the world is going to continue to grow, and Debian
is hopefully going to continue to grow with it, which means that the
package list is going to get longer regardless of our policies around
packaging small things.  So all those problems are going to happen no
matter what, which means we should find better solutions to them.

Packaging tools need better, faster algorithms.  UIs need better
information hiding: we have a lot of that already with, for example,
shared libraries, which the average user never has to see (since they're
pulled in via other packages the user wants), and therefore doesn't care
how many of them there are in the archive.  Data formats need to deal with
large numbers of packages better.  Because, no matter what, we're going to
have to deal with large numbers of packages.

And, as a bonus, if we solve the underlying problem, we can use a more
natural packaging strategy where an upstream corresponds to a package,
without the complexity of artificial lumping together of packages that are
actually distinct.

-- 
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: https://lists.debian.org/874my5nz8y@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[josh]

On Fri, Jul 25, 2014 at 04:00:31PM -0007, Cameron Norman wrote:
> El Fri, 25 de Jul 2014 a las 8:47 AM, Josh Triplett
>  escribió:
> >Martin Steigerwald wrote:
> >> Sure I can go through setting up chroot for that, yet I really
> >>think if my
> >> work requires changes in other packages and the recent systemd
> >>changes do require this kind of work, I *help* with these
> >>changes, instead of uploading my changes to unstable *before*
> >>the other packages have been fixed.
> >
> >One point of clarification: systemd does not require changes in
> >systemd-shim or cgmanager.  systemd runs just fine with no such
> >changes.
> >Those packages exist for people who for whatever reason don't want to
> >run systemd, and that's not something the systemd folks should be
> >expected to help with (any more than people who don't want to run
> >systemd would be expected to work on systemd).
> >
> >The systemd maintainers already held systemd 204 back in unstable for
> >months waiting for the alternative to become viable.
> >
> >It's not reasonable to expect every systemd upgrade in
> >unstable/testing
> >to wait for an alternative init system to keep up.  If it does
> >keep up,
> >great; there's no fundamental reason to *not* want that alternative to
> >work.  If it doesn't, oh well.
> 
> I agree, but would also add that other packages in Debian should at
> least try to keep support for other init systems by not depending on
> later logind's until systemd-shim is updated. It is clear (I think)
> that there are a number of reasons somebody would prefer to use an
> alternative init system (including a few unresolved bugs so far),
> and packages like GNOME or policykit should support more than just
> systemd-sysv.

That's another "best-effort" case: if those packages don't need features
of new logind or systemd, they certainly shouldn't gratuitously depend
on a newer version than they need.  But if they do, they should properly
express that dependency.

As for "a few unresolved bugs", that's also common in unstable, and I'm
sure they'll get fixed soon enough.  Which ones did you have in mind at
the moment?  Most of them have been fixed already.  The most significant
outstanding ones I know of are 753589 (which has a patch that needs
uploading), 618862 (keyscript support in crypttab), and 738965 (which is
*caused* by a Debian-specific patch).

Long-term, if a non-systemd init remains viable, people running it in
unstable and potentially in testing should likely get used to having to
put large swaths of their system on hold while waiting for updates.
That's a pretty common thing to need to do in unstable.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725163855.GA8713@cloud

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 8:47 AM, Josh Triplett 
 escribió:

Martin Steigerwald wrote:
 Sure I can go through setting up chroot for that, yet I really 
think if my
 work requires changes in other packages and the recent systemd 
changes do require this kind of work, I *help* with these changes, 
instead of uploading my changes to unstable *before* the other 
packages have been fixed.


One point of clarification: systemd does not require changes in
systemd-shim or cgmanager.  systemd runs just fine with no such 
changes.

Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).

The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.

It's not reasonable to expect every systemd upgrade in 
unstable/testing
to wait for an alternative init system to keep up.  If it does keep 
up,

great; there's no fundamental reason to *not* want that alternative to
work.  If it doesn't, oh well.


I agree, but would also add that other packages in Debian should at 
least try to keep support for other init systems by not depending on 
later logind's until systemd-shim is updated. It is clear (I think) 
that there are a number of reasons somebody would prefer to use an 
alternative init system (including a few unresolved bugs so far), and 
packages like GNOME or policykit should support more than just 
systemd-sysv.


--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Josh Triplett]

Martin Steigerwald wrote:
> Sure I can go through setting up chroot for that, yet I really think if my
> work requires changes in other packages and the recent systemd changes do
> require this kind of work, I *help* with these changes, instead of uploading
> my changes to unstable *before* the other packages have been fixed.

One point of clarification: systemd does not require changes in
systemd-shim or cgmanager.  systemd runs just fine with no such changes.
Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).

The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.

It's not reasonable to expect every systemd upgrade in unstable/testing
to wait for an alternative init system to keep up.  If it does keep up,
great; there's no fundamental reason to *not* want that alternative to
work.  If it doesn't, oh well.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725154741.GA2327@thin

Re: systemd now appears to be only possible init system in testing

[Vincent Bernat]

 ❦ 25 juillet 2014 14:22 +0200, Martin Steigerwald  :

> Re: Bug#755989: cfdisk: german help page strangely formatted
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755989#15
>
> (In addition to NFS mounts broken with systemd currently.)
>
>
> Sure I can go through setting up chroot for that, yet I really think if my 
> work requires changes in other packages and the recent systemd changes do 
> require this kind of work, I *help* with these changes, instead of uploading 
> my changes to unstable *before* the other packages have been fixed.

As a DD, you should always use a clean chroot to build everything. It's
not like it's something difficult to do. apt-get install cowbuilder ;
pbuilder create --distribution sid. schroot would be another option.
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: How to build-depend on a C++11-capable compiler?

[Emilio Pozuelo Monfort]

On 25/07/14 16:47, Osamu Aoki wrote:
> Hi,
> 
> I do not know about your case.  
> 
> FYI: I uploaded c++11 depending package as a sponsor since it compiled
> nicely on my amd64.  Than got bug report from arm people.
> 
> On Tue, Jul 22, 2014 at 10:35:17AM +0200, Thibaut Paumard wrote:
>>> Well, since g++-4.9 now c++11 feature complete (with one exception
>>> afair)  the situation is probably a lot better now. 
> 
> As others said, it is experimental.
> 
>> Anyway, I think I'll just go ahead and don't build-depend on a specific
>> compiler, because Gyoto can be built already with Wheezy's default
>> compiler in C++11 mode. Thanks all for your tips.
> 
> Please make sure to be compatible with all cpu.
> 
> Good luck.
> 
> Osamu
> 
> PS: We ended up uploading a package patched with the upstream branch
> marked as old-school to avoid using c++11 :-)

There are problems with std::future on armel, see #727621.

Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d272f5.3060...@debian.org

Re: importing in git the history of a Debian package

[Osamu Aoki]

Hi,

On Fri, Jul 25, 2014 at 03:24:38AM +0200, Marco d'Itri wrote:
> This script shows how to import in git the complete history of a Debian 
> package. It creates a structure of a properly merged upstream tree and 
> Debian changes.
> 
> http://www.linux.it/~md/software/import-inn2.sh

Interesting.
 
> It may not be pretty and is slightly DWIM, but it worked for all of my 
> packages (some of them with very broken stuff in old releases and a mix
> of 1.0, 1.0+DBS, 1.0+quilt and 3.0) while everything else that I tried 
> has failed.

Really? I do this kind of thing with one line:

$ git-import-dscs --debsnap --pristine-tar inn2
gbp:info: Downloading snapshots of 'inn2' to '/tmp/tmp0jUnBM'...
gbp:info: No git repository found, creating one.
gbp:info: Tag upstream/2.2.2.2000.01.31 not found, importing Upstream tarball
pristine-tar: committed inn2_2.2.2.2000.01.31.orig.tar.gz.delta to branch 
pristine-tar
gbp:info: Version '2.2.2.2000.01.31-4.1' imported under 'inn2'
gbp:info: Version '2.2.2.2000.01.31-5' imported under 'inn2'


Looks like I got a full history.  Can you elaborate where it failed in your 
case.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725150150.GC11652@goofy

Re: How to build-depend on a C++11-capable compiler?

[Osamu Aoki]

Hi,

I do not know about your case.  

FYI: I uploaded c++11 depending package as a sponsor since it compiled
nicely on my amd64.  Than got bug report from arm people.

On Tue, Jul 22, 2014 at 10:35:17AM +0200, Thibaut Paumard wrote:
> > Well, since g++-4.9 now c++11 feature complete (with one exception
> > afair)  the situation is probably a lot better now. 

As others said, it is experimental.

> Anyway, I think I'll just go ahead and don't build-depend on a specific
> compiler, because Gyoto can be built already with Wheezy's default
> compiler in C++11 mode. Thanks all for your tips.

Please make sure to be compatible with all cpu.

Good luck.

Osamu

PS: We ended up uploading a package patched with the upstream branch
marked as old-school to avoid using c++11 :-)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725144754.GB11652@goofy

Bug#756022: ITP: apt-transport-s3 -- APT transport for privately held AWS S3 repositories

[Marcin Kulisz (kuLa)]

Package: wnpp
Severity: wishlist
Owner: "Marcin Kulisz (kuLa)" 

* Package name: apt-transport-s3
  Version : 20120426090326git
  Upstream Author : Kyle Shank 
* URL : https://github.com/kyleshank/apt-s3
* License : GPLv3
  Programming Lang: C++
  Description : APT transport for privately held AWS S3 repositories

This package contains the APT AWS S3 transport. It makes possible to fetch
files from repositories privately held on AWS S3.
..
To start using S3 based repo it's enough to add line similar to the below to
apt sources.list (more information in 'man apt-transport-s3'):
deb s3://AWS_ACCESS_ID:[AWS_SECRET_KEY]@s3.amazonaws.com/BUCKETNAME wheezy main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140725140017.22857.17925.report...@bashton004.kulisz.net

Bug#756019: ITP: libmlx5 -- Userspace driver for Mellanox Connect-IB InfiniBand HCAs

[Ana Guerrero]

Package: wnpp
Severity: wishlist
Owner: Ana Guerrero Lopez 

* Package name: libmlx5
  Version : 1.0.1
  Upstream Author : Eli Cohen 
* URL : https://www.openfabrics.org/downloads/mlx5/
* License : To choose between OpenIB.org BSD license or GPL v2
  Programming Lang: C
  Description : Userspace driver for Mellanox Connect-IB InfiniBand HCAs

 libmlx5 is a device-specific driver for Mellanox Connect-IB InfiniBand
 host channel adapters (HCAs) for the libibverbs library.  This allows
 userspace processes to access Mellanox HCA hardware directly with
 low latency and low overhead.

Please, do not confuse with libmlx4 that is for Mellanox ConnectX while
this package, libmlx5, is for Mellanox Connect-IB.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140725134702.15300.6122.report...@gkar.rr44.fr

Re: systemd now appears to be only possible init system in testing

[Martin Steigerwald]

Am Dienstag, 22. Juli 2014, 22:54:55 schrieb Julian Gilbey:
> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
> Answers to this question would also be much appreciated!

I really hope systemd will soon be able to be co-installed with sysvinit-core 
again.

Here is another reason why:

Re: Bug#755989: cfdisk: german help page strangely formatted
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755989#15

(In addition to NFS mounts broken with systemd currently.)


Sure I can go through setting up chroot for that, yet I really think if my 
work requires changes in other packages and the recent systemd changes do 
require this kind of work, I *help* with these changes, instead of uploading 
my changes to unstable *before* the other packages have been fixed.

Especially if its such an disruptive change with all kind of side effects.

I only package some quite easy packages so far and I know its a lot of work to 
do good debian packaging, a lot more so with complex stuff like systemd. I know 
upload has been announced five month ago or so. But still…

I know I will hold back systemd until this is resolved. I am not yet going 
systemd only. By trust in systemd is not deep enough to do this on production 
systems. Yes, unstable is unstable, but… but putting in onto selected 
production systems for testing allows me to test stuff without investing a lot 
of extra time for setting up and using test systems.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/26564292.iuxY1J9fz6@merkaba

Re: Let's shrink Packages.xz

[Matt Zagrabelny]

On Fri, Jul 25, 2014 at 6:50 AM, Ian Jackson
 wrote:

>> Reducing the size of Packages.xz by 11% or 22% would leave room for quite
>> a lot of small packages while not making the problem any worse than it is
>> today.
>
> But the problem with lots of small packages is not that the
> Packages.xz has too many bytes.
>
> It's that the packaging tools, UIs (for users and developers), and
> humans, need to think about too many packages.
>
> This makes packaging tools slow, UIs cluttered, and humans confused.

What is "too many" packages?

It seems that the UI would need to be able to handle an arbitrary
number of packages. There have been many thousands of packages since
Woody/Sarge.

-m


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

Re: How Debian should handle users requests?

[Ian Jackson]

Jonathan Dowland writes ("Re: How Debian should handle users requests?"):
> Or a pseudo-package which *is* meant for user support, to which bugs are
> re-assigned, and for which debian-user is the "maintainer". Making d-u (more)
> useful as well as solving this issue sounds quite attractive to me. (Not sure
> how things would actually get closed, mind you.)

The BTS doesn't have at all the right data model for handling this
kind of thing.  They would simply accumulate.  We don't want BTS
searches to turn up these support requests masquerading as bug
reports.

Ian.


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

Re: How Debian should handle users requests?

[Ian Jackson]

Arto Jantunen writes ("Re: How Debian should handle users requests?"):
> I don't think reportbug should allow filing bugs against general at
> all. The extremely rare cases when one is needed can be filed manually.

Indeed. If the user tries to do so, it should direct the user to a
support forum.

As a more radical suggestion, perhaps it should divert the usual
output email to debian-user ?  Probably we should ask the inhabitants
of debian-user what they think of this idea...

Ian.


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

Re: How Debian should handle users requests?

[Ian Jackson]

Abou Al Montacir writes ("Re: How Debian should handle users requests?"):
> On Sun, 2014-07-20 at 17:01 +0200, Adam Borowski wrote:
> > Suspend quirks are among worst bugs for a non-hacker to report.
>
> I fully understand this, but we can not close bugs just because we
> assume that the user will not be able to debug this and produce relevant
> bugs.

On the contrary, we should definitely close bugs which are very
unlikely to produce any actionable information.

Ian.


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

Re: /usr/lib to /lib symlinks (absolute?)

[Ian Jackson]

Colin Watson writes ("Re: /usr/lib to /lib symlinks (absolute?)"):
> On Fri, Jul 18, 2014 at 10:45:14AM +0200, Josselin Mouette wrote:
> > I think it’s a bad idea to use symbolic links rather than bind mounts
> > for this kind of stuff, but I’m pretty sure we would break some systems
> > if we stopped supporting that, though.
> 
> Yeah, I suspect there are some old-school sysadmins who do "oh, I ran
> out of space, ln -s /space/usr /usr".  I agree with your bad-idea
> intuition, but ...

It's not /usr, but:

chiark:~> ll -d /tmp /var/tmp /var/mail
lrwxrwxrwx 1 root root 12 Aug  3  2007 /tmp -> volatile/tmp/
lrwxrwxrwx 1 root ian  10 Jul 26  2007 /var/mail -> spool/mail/
lrwxrwxrwx 1 root root  4 Jul 26  2007 /var/tmp -> /tmp/
chiark:~>

And in /var/log, the notable directories exim4, httpd and squid
are also symlinks.

Ian.


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

Bug#756003: ITP: r-bioc-snpstats -- BioConductor SnpMatrix and XSnpMatrix classes and methods

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-bioc-snpstats
  Version : 1.14.0
  Upstream Author : David Clayton 
* URL : 
http://bioconductor.org/packages/release/bioc/html/snpStats.html
* License : GPL-3
  Programming Lang: R
  Description : BioConductor SnpMatrix and XSnpMatrix classes and methods
 This BioConductor package provides R functions to work with
 SnpMatrix and XSnpMatrix classes and methods.


Remark: This package is needed to run parts of the testsuite of other 
BioConductor
modules and is packaged to enable proper autopkgtest suite.  It is maintained by
the Debian Med team at

svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-snpstats/trunk/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140725114936.21743.13648.report...@mail.an3as.eu

Re: Let's shrink Packages.xz

[Ian Jackson]

Russ Allbery writes ("Re: Let's shrink Packages.xz"):
> I'm fairly sure Jakub's message was in response to the recent discussion
> about small Node.js packages and the frequent complaints that we should
> not introduce small packages into the archive because it bloats our
> metadata.
> 
> Reducing the size of Packages.xz by 11% or 22% would leave room for quite
> a lot of small packages while not making the problem any worse than it is
> today.

But the problem with lots of small packages is not that the
Packages.xz has too many bytes.

It's that the packaging tools, UIs (for users and developers), and
humans, need to think about too many packages.

This makes packaging tools slow, UIs cluttered, and humans confused.

Ian.


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