Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-05 Thread Ian Jackson
Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - 
proposal):
 So, I hereby formally propose the resolution text below.  I intend to
 call for votes some time tomorrow.

Thanks again to Josh for all his careful and constructive
interventions in the discussion.  I'm glad to see that he's now happy
with this proposal.


I hereby call for votes.  There are two options:
  Y (override, swap dependencies, requires 3:1)
  FD

Ian.

===

Rationale (Constitution 6.1(5)):

1. Currently libpam-systemd (which is pulled in by quite a few
   dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'.

2. The effect of this is that installing some packages which depend
   (directly or indirectly) on libpam-systemd can cause a user's init
   system to be switched to systemd, even on systems where a user has
   deliberately chosen not to use the default init system, and even
   when the switch is unnecessary.

3. Swappping the order of these dependencies would avoid that and has
   no harmful effect:

4. In particular, on systems that already have systemd-sysv installed,
   libpam-systemd will still not pull in systemd-shim, thus minimizing
   the risk of breakage on systemd systems.  However, on systems that
   intentionally do not have systemd installed, the installation of
   libpam-systemd will then prefer to pull in systemd-shim and keep
   the installed init system rather than switching to systemd-sysv.

Decision (Constitution 6.1(4)):

5. We therefore overrule the decision of the maintainer of
   libpam-systemd binary package.  The Depends entry
  systemd-sysv | systemd-shim (= 8-2)
   should be replaced by 
  systemd-shim (= 8-2) | systemd-sysv

6. For the avoidance of doubt, we do not intend to set this specific
   syntax in stone.  For example, if in future libpam-systemd needs to
   depend on a later systemd-shim, or needs a versioned rather than
   unversioned dependency on systemd-sysv, that is fine and would not
   contradict our decision.

Release (Constitution 6.1(5)):

7. Our advice is that this change should be in jessie.  If necessary,
   this view should be conveyed to the Release Team, after the change
   is in unstable, by filing an unblock request in the usual way.

===


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



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-05 Thread Josh Triplett
On Wed, 5 Nov 2014 11:49:45 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - 
 proposal):
  So, I hereby formally propose the resolution text below.  I intend to
  call for votes some time tomorrow.
 
 Thanks again to Josh for all his careful and constructive
 interventions in the discussion.  I'm glad to see that he's now happy
 with this proposal.

This proposal doesn't seem to include the change you made in git commit
227f496617929c48bfd20a9c96eead8b91ee69b7 to fix a typo I reported in
item 4:
 4. In particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing
the risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep
the installed init system rather than switching to systemd-sysv.

In your mail with Message-ID
21590.30193.479905.710...@chiark.greenend.org.uk, you said:
Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - 
proposal):
[...]
 s/intentionally do not have systemd/intentionally do not have systemd-sysv/

Fixed in git.  I hereby make that change to my formal proposal.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105155158.GA13254@thin



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-05 Thread Josh Triplett
On Wed, 05 Nov 2014 08:42:07 -0500 Sam Hartman hartm...@debian.org wrote:
 I don't think this matters for the vote, and apologies because there's
 probably a better place to send this advice.  I was thinking last night
 about the apt and debootstrap resolver issues and  was wondering whether
 the following solution might help.
 
 I realize the issue is minor and is more about minimizing packages
 installed than safety of the proposal.
 
 What if libpam-systemd depended on
 systemd-shim-nosysv|systemd-sysv|systemd-shim?
 
 Introduce a new package systemd-shim-nosysv in the systemd-shim package
 that depends on systemd-shim and conflicts with systemd-sysv.
 
 I have not tried this.  It might reduce the probability that
 systemd-shim gets uselessly installed.  however, I don't know whether it
 creates systems where systemd-sysv gets removed.

Seems like a great idea to me; we talked a bit about Conflicts in the
context of cgmanager, but this approach (with an artificial intermediate
package) makes much more sense.  I agree that it needs careful testing,
though; after Christian Seiler's testing of debootstrap and apt, I
really don't know how either would decide to resolve this.  Either or
both might well decide to choose the alternate dependency of the
essential init package rather than the alternate dependency of
libpam-systemd.

 Even if this does end up being a good idea, I don't think the TC
 resolution needs to change.  As I read it, the essential character of
 the resolution is that systemd-shim is preferred to systemd-sysv in
 libpam-systemd.  If we find better technical ways of doing that, more
 power to us all.  If there is a real disagreement about whether we're
 within the spirit of the TC resolution should it pass, we can ask the TC
 again either informally or formally.  I don't want to see us getting
 ultra-picky about the wording of resolutions to constrain or permit
 future innovation.

I agree; when I suggested clarifying in the TC decision that the Depends
shouldn't be hard-coded (what became clause 6 of the current proposal),
I didn't just have versioned dependency changes in mind, but also
package structural changes (on either systemd's or systemd-shim's part).
I think the suggestion you made above fits entirely within the spirit of
the TC resolution.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105155932.GA13240@thin



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread Josh Triplett
On Tue, Nov 04, 2014 at 07:47:05AM +0100, Christian Seiler wrote:
 Am 02.11.2014 06:59, schrieb Josh Triplett:
  Apart from that, I would still request that someone with the ability to
  produce a modified local mirror test the two critical cases mentioned in
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 .  If those
  two cases work, then systemd systems should not end up with systemd-shim
  installed under normal circumstances, making breakage far less likely.
 
 debootstrap 1.0.64 on a current Jessie box with a locally modified
 and otherwise up-to-date (2014-11-04T05:00Z) mirror wants to pull in the
 following packages[1]:
 
[...snip list in favor of diff...]
 [1] debootstrap --print-debs --no-check-gpg \
   --include=libpam-systemd jessie $DIR $MIRROR
 
 PS: Diff of the stuff that is pulled in compared to the same command
 done in the current archive (after sorting the package list):
 @@ -7,6 +7,7 @@
  bash
  bsdmainutils
  bsdutils
 +cgmanager
  coreutils
  cpio
  cron
 @@ -57,6 +58,7 @@
  libcap2-bin
  libcap-ng0
  libc-bin
 +libcgmanager0
  libcomerr2
  libcryptsetup4
  libdb5.3
 @@ -70,6 +72,7 @@
  libgcc1
  libgcrypt20
  libgdbm3
 +libglib2.0-0
  libgmp10
  libgnutls-deb0-28
  libgnutls-openssl27
 @@ -94,6 +97,8 @@
  libnettle4
  libnewt0.52
  libnfnetlink0
 +libnih1
 +libnih-dbus1
  libp11-kit0
  libpam0g
  libpam-modules
 @@ -153,6 +158,7 @@
  sensible-utils
  startpar
  systemd
 +systemd-shim
  systemd-sysv
  sysvinit-utils
  sysv-rc

 I've also tried debootstrap 1.0.62 on a Fedora 19 box with the same
 mirror, with the same results.
 
 Note that systemd-shim together with cgmanager is pulled in.

Thank you very much for the careful testing and analysis!

This result concerns me greatly, and I think the technical committee
should take this into account when considering whether to flip the
dependencies of libpam-systemd around.

I find it odd that debootstrap produced this result, and I've filed a
bug on debootstrap about this, but in any case, with current
debootstrap, flipping the libpam-systemd dependencies around will result
in installing systemd-shim (but not any non-systemd init that needs it)
on systemd systems.  Given past bugs in both systemd-shim and cgmanager
that broke systemd, that seems less than ideal.  (Not utterly
unreasonable, but it introduces an entirely unnecessary additional
source of potential problems.)

This isn't a complete showstopper, since most of the time people seem to
debootstrap a standard system and then install additional packages.
However, it would affect a debootstrap with --include=task-desktop or
--include=gnome or similar.

Does anyone see an obvious way to structure the dependencies to avoid
this result and only install systemd-sysv?  If no way exists, it might
be worth making sure jessie's debootstrap gets fixed in time.

 My guess is that there's some greediness in the dependency resolver in
 debootstrap, and as long as there's no conflict, it won't try to follow
 other alternatives to see if the dependencies have already been met.
 
 Also note that neither --exclude=systemd-shim,cgmanager nor
 --exclude=systemd-shim seem to have no effect whatsoever on
 the list of packages. (Which is probably a bug in debootstrap, because
 it should at least warn you if it can't fulfill the specified --exclude,
 but also in this case it could actually exclude it...)

I've filed a bug on debootstrap for these two issues.

 I haven't tested the upgrade scenario.

I appreciate the test you already ran.  I'd love to see an upgrade test
as well (from a system with sysvinit installed), but this test already
revealed an issue.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141104160726.GA5844@thin



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread Russ Allbery
Josh Triplett j...@joshtriplett.org writes:

 This result concerns me greatly, and I think the technical committee
 should take this into account when considering whether to flip the
 dependencies of libpam-systemd around.

So, this came up before, and I believe that systemd-shim is not supposed
to interfere with systemd with the current version.  In other words, I
think the existence of the package on the system should be a no-op if the
system is booted with systemd.

That makes this a minor bug, but not something that's too serious.

Am I wrong about this?

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq7arjng@hope.eyrie.org



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread Ian Jackson
I've been reading the messages from Josh about cgmanager etc., and
they haven't changed my mind about the need to flip these
dependencies.  If other bugs in systemd-ship or cgmanager turn up,
they should be fixed.  We have time to do that.  And I am not opposed
to further `safety' changes to cgmanager.  Those should be discussed
with the appropriate maintainer.

So, I hereby formally propose the resolution text below.  I intend to
call for votes some time tomorrow.

Thanks,
Ian.

===

Rationale (Constitution 6.1(5)):

1. Currently libpam-systemd (which is pulled in by quite a few
   dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'.

2. The effect of this is that installing some packages which depend
   (directly or indirectly) on libpam-systemd can cause a user's init
   system to be switched to systemd, even on systems where a user has
   deliberately chosen not to use the default init system, and even
   when the switch is unnecessary.

3. Swappping the order of these dependencies would avoid that and has
   no harmful effect:

4. In particular, on systems that already have systemd-sysv installed,
   libpam-systemd will still not pull in systemd-shim, thus minimizing
   the risk of breakage on systemd systems.  However, on systems that
   intentionally do not have systemd installed, the installation of
   libpam-systemd will then prefer to pull in systemd-shim and keep
   the installed init system rather than switching to systemd-sysv.

Decision (Constitution 6.1(4)):

5. We therefore overrule the decision of the maintainer of
   libpam-systemd binary package.  The Depends entry
  systemd-sysv | systemd-shim (= 8-2)
   should be replaced by 
  systemd-shim (= 8-2) | systemd-sysv

6. For the avoidance of doubt, we do not intend to set this specific
   syntax in stone.  For example, if in future libpam-systemd needs to
   depend on a later systemd-shim, or needs a versioned rather than
   unversioned dependency on systemd-sysv, that is fine and would not
   contradict our decision.

Release (Constitution 6.1(5)):

7. Our advice is that this change should be in jessie.  If necessary,
   this view should be conveyed to the Release Team, after the change
   is in unstable, by filing an unblock request in the usual way.

===


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



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread Christian Seiler
Am 04.11.2014 17:07, schrieb Josh Triplett:
 This isn't a complete showstopper, since most of the time people seem to
 debootstrap a standard system and then install additional packages.
 However, it would affect a debootstrap with --include=task-desktop or
 --include=gnome or similar.

Just as a side note: I never use debootstrap to actually include
anything that wouldn't be considered 'base system', just because I've
had the experience that quite a few packages don't work together with
debootstrap (try doing --include=syslog-ng (and --exclude=rsyslog) while
debootstrapping wheezy - the dependency resolution works properly, but
the package won't install, because the preinst or postinst scripts don't
like debootstrap's environment (the rsyslog exclude alone works btw., so
that's what I'm doing if I want something with syslog-ng)). I have some
real doubts that debootstrap is going to be able to set up something
like GNOME or task-desktop or whatever, just because they probably are
going to pull in lots of packages of which at least a couple are going
to have similar problems to the aforementioned one I had with syslog-ng.

Therefore, I always tend to use debootstrap to just install a very, very
basic system and then use apt-get in a chroot to install the rest of the
software, if I decide to install a Debian image like that.

This in mind, looking at apt-cache rdepends libpam-systemd[1], I don't
see anything in there I'd want to include in debootstrap. But maybe
that's just me.

 Does anyone see an obvious way to structure the dependencies to avoid
 this result and only install systemd-sysv?

I don't think that's possible if you want to keep the effect the
switching the dependencies has (i.e. selecting systemd-shim as first
alternative so that systems without systemd as pid1 don't try to install
systemd-sysv when packages depending on logind are installed).

 I haven't tested the upgrade scenario.
 
 I appreciate the test you already ran.  I'd love to see an upgrade test
 as well (from a system with sysvinit installed), but this test already
 revealed an issue.

 - Fresh install of Debian Wheezy (from netinst CD)
 - tasksel: Standard utilities + SSH server
 - aptitude full-upgrade
 - aptitude install --without-recommends gdm3
(package that pulls in libpam-systemd in Jessie, without
 installing too much, although gdm3 itself already pulls in
 quite a lot on wheezy, in hindsight probably should have gone
 with network-manager...)
 - Then edit sources.list, remove everything wheezy-related, add my
   modified mirror, apt-get update

Then this gives the following consequences:

  - apt-get upgrade:
  * doesn't try to upgrade enough packages that you could call
the system jessie, doesn't pull in anything systemd related
other than trying to upgrade libsystemd-login0 (already
installed on wheezy because of a Depends of dbus)
  - apt-get dist-upgrade
  * pulls in systemd-shim
  - aptitude full-upgrade
  * pulls in systemd-shim
  - aptitude upgrade (i.e. safe-upgrade)
  * takes a couple of minutes to resolve deps
(granted, running in a VM, but I have a fast CPU, so
this is really unusual, never seen aptitude working so
long before, but OTOH I've never done a dist-upgrade
with aptitude before, so maybe that's normal?)
  * DOES NOT pull in systemd-shim
  - didn't test any other frontends

(I'm not showing any detailed package lists here because there's just
too much unrelated stuff.)

Christian

[1] Depended on by:
udisks2, policykit-1, network-manager, lightdm*,
gnome-settings-daemon, gnome-bluetooth, gdm3
Recommended by (not relevant for deboostrap IIRC):
xfce4-session, xfce4-power-manager, systemd,
gnome-session-bin, argyll
(* Depends: libpam-systemd | consolekit)

PS: I tested this because I think it's better to have all the relevant
information before deciding an issue, please don't interpret my email as
being critical of the proposed resolution.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54592660.5000...@iwakd.de



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread josh
On Tue, Nov 04, 2014 at 08:17:52PM +0100, Christian Seiler wrote:
 Am 04.11.2014 17:07, schrieb Josh Triplett:
  This isn't a complete showstopper, since most of the time people seem to
  debootstrap a standard system and then install additional packages.
  However, it would affect a debootstrap with --include=task-desktop or
  --include=gnome or similar.
 
 Just as a side note: I never use debootstrap to actually include
 anything that wouldn't be considered 'base system', just because I've
 had the experience that quite a few packages don't work together with
 debootstrap (try doing --include=syslog-ng (and --exclude=rsyslog) while
 debootstrapping wheezy - the dependency resolution works properly, but
 the package won't install, because the preinst or postinst scripts don't
 like debootstrap's environment (the rsyslog exclude alone works btw., so
 that's what I'm doing if I want something with syslog-ng)). I have some
 real doubts that debootstrap is going to be able to set up something
 like GNOME or task-desktop or whatever, just because they probably are
 going to pull in lots of packages of which at least a couple are going
 to have similar problems to the aforementioned one I had with syslog-ng.
 
 Therefore, I always tend to use debootstrap to just install a very, very
 basic system and then use apt-get in a chroot to install the rest of the
 software, if I decide to install a Debian image like that.
 
 This in mind, looking at apt-cache rdepends libpam-systemd[1], I don't
 see anything in there I'd want to include in debootstrap. But maybe
 that's just me.

No, I agree with you; it doesn't seem excessively problematic by itself,
and it may or may not actually be a good argument against the proposed
resolution.

  Does anyone see an obvious way to structure the dependencies to avoid
  this result and only install systemd-sysv?
 
 I don't think that's possible if you want to keep the effect the
 switching the dependencies has (i.e. selecting systemd-shim as first
 alternative so that systems without systemd as pid1 don't try to install
 systemd-sysv when packages depending on logind are installed).

Well, one obvious approach: make either systemd-shim or cgmanager
Conflicts: systemd-sysv.  However, that seems overly harsh, and breaks
the case of booting an alternate init system via the init= command-line
argument.

  I haven't tested the upgrade scenario.
  
  I appreciate the test you already ran.  I'd love to see an upgrade test
  as well (from a system with sysvinit installed), but this test already
  revealed an issue.
 
  - Fresh install of Debian Wheezy (from netinst CD)
  - tasksel: Standard utilities + SSH server
  - aptitude full-upgrade
  - aptitude install --without-recommends gdm3
 (package that pulls in libpam-systemd in Jessie, without
  installing too much, although gdm3 itself already pulls in
  quite a lot on wheezy, in hindsight probably should have gone
  with network-manager...)
  - Then edit sources.list, remove everything wheezy-related, add my
modified mirror, apt-get update
 
 Then this gives the following consequences:
 
   - apt-get upgrade:
   * doesn't try to upgrade enough packages that you could call
 the system jessie, doesn't pull in anything systemd related
 other than trying to upgrade libsystemd-login0 (already
 installed on wheezy because of a Depends of dbus)
   - apt-get dist-upgrade
   * pulls in systemd-shim
   - aptitude full-upgrade
   * pulls in systemd-shim
   - aptitude upgrade (i.e. safe-upgrade)
   * takes a couple of minutes to resolve deps
 (granted, running in a VM, but I have a fast CPU, so
 this is really unusual, never seen aptitude working so
 long before, but OTOH I've never done a dist-upgrade
 with aptitude before, so maybe that's normal?)
   * DOES NOT pull in systemd-shim
   - didn't test any other frontends

Well, ugh.  Bad apt, no biscuit.

This seems much more problematic to me.  I *expected* apt to say well I
need to install the Essential init package, which pulls in systemd-sysv,
which satisfies libpam-systemd.  But apparently apt resolved all the
dependencies simultaneously and ignored alternative dependencies.

(Presumably if you had systemd-sysv installed in wheezy this wouldn't
happen, but that's not an interesting case, nor does it need this kind
of test to confirm that.)

I wouldn't necessarily suggest using this as an argument against the
proposed resolution.  Instead, I'd recommend making sure that cgmanager
is just as harmless under systemd as systemd-shim 8-4 currently is, by
making it not run under systemd.  That would make this change much
safer.

 PS: I tested this because I think it's better to have all the relevant
 information before deciding an issue, please don't interpret my email as
 being critical of the proposed resolution.

Thank you *very* much for your work.

- Josh 

Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread Sam Hartman
 josh == josh  j...@joshtriplett.org writes:

josh I wouldn't necessarily suggest using this as an argument
josh against the proposed resolution.  Instead, I'd recommend
josh making sure that cgmanager is just as harmless under systemd
josh as systemd-shim 8-4 currently is, by making it not run under
josh systemd.  That would make this change much safer.

I think making cgmanager not run by default under systemd seems
reasonable.  However, as we've seen discussed on -vote cgmanager
provides different services than systemd and if you need full semantics
can do things systemd cannot do.

For that reason, I can see people wanting to use it along-side systemd.
I'd discourage the TC from making a ruling about cgmanager and encourage
the cgmanager maintainer to find a way to make it not run by default but
be enabled at administrator request.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslioiu4puz@mit.edu



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-04 Thread Josh Triplett
On Tue, 4 Nov 2014 17:54:53 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 I've been reading the messages from Josh about cgmanager etc., and
[snip]

Actually, I'd like to completely withdraw my concerns there, in light of
some new information.

Quoting Serge Hallyn, maintainer of cgmanager:
 Currently the cgmanager sytemd unit is installed inactive, so by default
 it will not interfere with systemd.  The user needs to specifically
 enable it.

So, both systemd-shim and cgmanager seem entirely harmless on systemd
systems; the former will not run at all under systemd, and the latter
will not run by default under systemd.  Based on that, I no longer have
any concerns about flipping the dependencies around, even though doing
so will likely pull those two packages in on systemd systems per
Christian Seiler's detailed analysis.

I don't see any obvious further steps that need to occur other than
flipping the dependency around.  (It might be a good idea for the
libpam-systemd dependency to bump its versioned dependency on
systemd-shim to (= 8-4), but that's up to the libpam-systemd
maintainers.)

(This is still orthogonal to any discussions regarding switching on
upgrades, or regarding dependencies on systemd.)

- Josh Triplett

 Rationale (Constitution 6.1(5)):
 
 1. Currently libpam-systemd (which is pulled in by quite a few
dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'.
 
 2. The effect of this is that installing some packages which depend
(directly or indirectly) on libpam-systemd can cause a user's init
system to be switched to systemd, even on systems where a user has
deliberately chosen not to use the default init system, and even
when the switch is unnecessary.
 
 3. Swappping the order of these dependencies would avoid that and has
no harmful effect:
 
 4. In particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing
the risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep
the installed init system rather than switching to systemd-sysv.
 
 Decision (Constitution 6.1(4)):
 
 5. We therefore overrule the decision of the maintainer of
libpam-systemd binary package.  The Depends entry
   systemd-sysv | systemd-shim (= 8-2)
should be replaced by 
   systemd-shim (= 8-2) | systemd-sysv
 
 6. For the avoidance of doubt, we do not intend to set this specific
syntax in stone.  For example, if in future libpam-systemd needs to
depend on a later systemd-shim, or needs a versioned rather than
unversioned dependency on systemd-sysv, that is fine and would not
contradict our decision.
 
 Release (Constitution 6.1(5)):
 
 7. Our advice is that this change should be in jessie.  If necessary,
this view should be conveyed to the Release Team, after the change
is in unstable, by filing an unblock request in the usual way.
 
 ===
 
 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105010724.GA11065@jtriplet-mobl1



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-03 Thread Christian Seiler
Am 02.11.2014 06:59, schrieb Josh Triplett:
 Apart from that, I would still request that someone with the ability to
 produce a modified local mirror test the two critical cases mentioned in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 .  If those
 two cases work, then systemd systems should not end up with systemd-shim
 installed under normal circumstances, making breakage far less likely.

debootstrap 1.0.64 on a current Jessie box with a locally modified
and otherwise up-to-date (2014-11-04T05:00Z) mirror wants to pull in the
following packages[1]:

acl adduser base-files base-passwd bash bsdutils coreutils dash debconf
debconf-i18n debianutils diffutils dmsetup dpkg e2fslibs e2fsprogs
findutils gcc-4.8-base gcc-4.9-base grep gzip hostname init
init-system-helpers initscripts insserv libacl1 libattr1 libaudit-common
libaudit1 libblkid1 libbz2-1.0 libc-bin libc6 libcap2 libcap2-bin
libcomerr2 libcryptsetup4 libdb5.3 libdebconfclient0 libdevmapper1.02.1
libgcc1 libgcrypt20 libgdbm3 libgpg-error0 libkmod2
liblocale-gettext-perl liblzma5 libmount1 libncurses5 libncursesw5
libpam-modules libpam-modules-bin libpam-runtime libpam0g libpcre3
libprocps3 libselinux1 libsemanage-common libsemanage1 libsepol1
libslang2 libsmartcols1 libss2 libsystemd0 libtext-charwidth-perl
libtext-iconv-perl libtext-wrapi18n-perl libtinfo5 libudev1
libustr-1.0-1 libuuid1 login lsb-base mawk mount multiarch-support
ncurses-base ncurses-bin passwd perl perl-base perl-modules procps sed
sensible-utils startpar systemd systemd-sysv sysv-rc sysvinit-utils tar
tzdata udev util-linux zlib1g apt apt-utils bsdmainutils cgmanager cpio
cron dbus debian-archive-keyring dmidecode gnupg gpgv groff-base
ifupdown iproute2 iptables iputils-ping isc-dhcp-client isc-dhcp-common
kmod less libapt-inst1.5 libapt-pkg4.12 libboost-iostreams1.55.0
libcap-ng0 libcgmanager0 libdbus-1-3 libdns-export100 libestr0 libexpat1
libffi6 libglib2.0-0 libgmp10 libgnutls-deb0-28 libgnutls-openssl27
libhogweed2 libicu52 libidn11 libirs-export91 libisc-export95
libisccfg-export90 libjson-c2 liblogging-stdlog0 liblognorm1 libmnl0
libnetfilter-acct1 libnettle4 libnewt0.52 libnfnetlink0 libnih-dbus1
libnih1 libp11-kit0 libpam-systemd libpipeline1 libpopt0 libpsl0
libreadline6 libsigc++-2.0-0c2a libssl1.0.0 libstdc++6 libtasn1-6
libusb-0.1-4 libxtables10 logrotate man-db manpages nano net-tools
netbase netcat-traditional nfacct readline-common rsyslog systemd-shim
tasksel tasksel-data traceroute vim-common vim-tiny wget whiptail

I've also tried debootstrap 1.0.62 on a Fedora 19 box with the same
mirror, with the same results.

Note that systemd-shim together with cgmanager is pulled in.

My guess is that there's some greediness in the dependency resolver in
debootstrap, and as long as there's no conflict, it won't try to follow
other alternatives to see if the dependencies have already been met.

Also note that neither --exclude=systemd-shim,cgmanager nor
--exclude=systemd-shim seem to have no effect whatsoever on
the list of packages. (Which is probably a bug in debootstrap, because
it should at least warn you if it can't fulfill the specified --exclude,
but also in this case it could actually exclude it...)

I haven't tested the upgrade scenario.

Christian

[1] debootstrap --print-debs --no-check-gpg \
  --include=libpam-systemd jessie $DIR $MIRROR

PS: Diff of the stuff that is pulled in compared to the same command
done in the current archive (after sorting the package list):
@@ -7,6 +7,7 @@
 bash
 bsdmainutils
 bsdutils
+cgmanager
 coreutils
 cpio
 cron
@@ -57,6 +58,7 @@
 libcap2-bin
 libcap-ng0
 libc-bin
+libcgmanager0
 libcomerr2
 libcryptsetup4
 libdb5.3
@@ -70,6 +72,7 @@
 libgcc1
 libgcrypt20
 libgdbm3
+libglib2.0-0
 libgmp10
 libgnutls-deb0-28
 libgnutls-openssl27
@@ -94,6 +97,8 @@
 libnettle4
 libnewt0.52
 libnfnetlink0
+libnih1
+libnih-dbus1
 libp11-kit0
 libpam0g
 libpam-modules
@@ -153,6 +158,7 @@
 sensible-utils
 startpar
 systemd
+systemd-shim
 systemd-sysv
 sysvinit-utils
 sysv-rc


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54587669.4000...@iwakd.de



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-02 Thread Josh Triplett
On Sat, 1 Nov 2014 18:55:32 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 Rationale (Constitution 6.1(5)):
 
 1. Currently libpam-systemd (which is pulled in by quite a few
dependency chains) Depends on `systemd-sysv | systemd-shim'.

Here, you give the simplified dependency without the version constraint,
while below you give the full Depends with version constraint.  Please
choose one or the other and use it consistently.

 2. The effect of this is that installing certain leaf packages which
depend on libpam-systemd can cause a user's init system to be
switched to systemd, even on systems where a user has deliberately
chosen not to use the default init system, and even when the switch
is unnecessary.

Nit: s/certain leaf//; the packages depending on libpam-systemd are not
actually leaf packages, and in fact various other packages depend on
them.

 3. Swappping the order of these dependencies would avoid that and has
no harmful effect.

I would suggest expanding on what no harmful effect means here: In
particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing the
risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep the
installed init system rather than switching to systemd-sysv.

Stating that explicitly in the rationale, to set expectations, seems
preferable to a vague no harmful effect that does not fully make sense
without reading the full history in the bug.  TC decisions should be
self-contained.

 Decision (Constitution 6.1(4)):
 
 4. We therefore overrule the decision of the maintainer of
libpam-systemd binary package.  The Depends entry
   systemd-sysv | systemd-shim (= 8-2)
should be replaced by 
   systemd-shim (= 8-2) | systemd-sysv

I think this decision needs to explicitly state that it does not require
any particular version numbers in the versioned dependencies, only the
specific order.  In particular, if libpam-systemd needs to increase its
versioned dependency on systemd-shim, or if it ever needs to add a
versioned dependency on systemd-sysv, that change should not violate
this TC decision.

 Release (Constitution  6.1(5)):
 
 5. We request that the Release Team allow this change to into jessie.
(This request should be conveyed to the Release Team, after the
change is in unstable, by filing an unblock request in the usual
way.)

Is this point necessary?  The freeze has not yet occurred, and I don't
see any obvious reason why the TC needs to explicitly direct the release
team here.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102054832.GA1167@thin



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-02 Thread Josh Triplett
On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery r...@debian.org wrote:
 So, this is also the last call for anyone to explain what harmful effect
 this could have if they think it would have a harmful effect.  My
 understanding is that all of the possible harmful effects have been fixed
 by various other changes.

systemd-shim 8-4 and newer no longer seem likely to produce harmful
effects, given that systemd-shim now depends on systemd rather than
shipping its own D-Bus policy, and that systemd-shim itself pointedly
does not launch on systemd systems.  Neither of those two properties
seems likely to change or break.

systemd-shim does depend on cgmanager, which seems more prone to
breakage, and in fact has a handful of open bugs on it.  cgmanager has
in the past broken on non-systemd systems.  I personally would like to
see a resolution of 755977 to deal with that.

Apart from that, I would still request that someone with the ability to
produce a modified local mirror test the two critical cases mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 .  If those
two cases work, then systemd systems should not end up with systemd-shim
installed under normal circumstances, making breakage far less likely.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102055908.GA1250@thin



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-02 Thread Josh Triplett
On Sat, 1 Nov 2014 22:59:09 -0700 Josh Triplett j...@joshtriplett.org wrote:
 On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery r...@debian.org wrote:
  So, this is also the last call for anyone to explain what harmful effect
  this could have if they think it would have a harmful effect.  My
  understanding is that all of the possible harmful effects have been fixed
  by various other changes.
 
 systemd-shim 8-4 and newer no longer seem likely to produce harmful
 effects, given that systemd-shim now depends on systemd rather than
 shipping its own D-Bus policy, and that systemd-shim itself pointedly
 does not launch on systemd systems.  Neither of those two properties
 seems likely to change or break.
 
 systemd-shim does depend on cgmanager, which seems more prone to
 breakage, and in fact has a handful of open bugs on it.  cgmanager has
 in the past broken on non-systemd systems.  I personally would like to
 see a resolution of 755977 to deal with that.

Important typo here: I meant cgmanager has in the past broken
systemd systems.  I had bugs like 761389 in mind there.  Hence 755977.

 Apart from that, I would still request that someone with the ability to
 produce a modified local mirror test the two critical cases mentioned in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 .  If those
 two cases work, then systemd systems should not end up with systemd-shim
 installed under normal circumstances, making breakage far less likely.
 
 - Josh Triplett
 
 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102135634.GA1220@thin



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-02 Thread Ian Jackson
Thanks for your review.  I appreciate the attention to detail.

Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - 
proposal):
 Here, you give the simplified dependency without the version constraint,
 while below you give the full Depends with version constraint.  Please
 choose one or the other and use it consistently.

I don't mind changing this.

 On Sat, 1 Nov 2014 18:55:32 + Ian Jackson 
 ijack...@chiark.greenend.org.uk wrote:
  2. The effect of this is that installing certain leaf packages which
 depend on libpam-systemd can cause a user's init system to be
 switched to systemd, even on systems where a user has deliberately
 chosen not to use the default init system, and even when the switch
 is unnecessary.
 
 Nit: s/certain leaf//; the packages depending on libpam-systemd are not
 actually leaf packages, and in fact various other packages depend on
 them.

I will change this to some packages which depend (directly or
indirectly) on libpam-systemd.

  3. Swappping the order of these dependencies would avoid that and has
 no harmful effect.
 
 I would suggest expanding on what no harmful effect means here: In
 particular, on systems that already have systemd-sysv installed,
 libpam-systemd will still not pull in systemd-shim, thus minimizing the
 risk of breakage on systemd systems.  However, on systems that
 intentionally do not have systemd installed, the installation of
 libpam-systemd will then prefer to pull in systemd-shim and keep the
 installed init system rather than switching to systemd-sysv.
 
 Stating that explicitly in the rationale, to set expectations, seems
 preferable to a vague no harmful effect that does not fully make sense
 without reading the full history in the bug.  TC decisions should be
 self-contained.

Thanks for that helpful text, which I have adopted.

  4. We therefore overrule the decision of the maintainer of
 libpam-systemd binary package.  The Depends entry
systemd-sysv | systemd-shim (= 8-2)
 should be replaced by 
systemd-shim (= 8-2) | systemd-sysv
 
 I think this decision needs to explicitly state that it does not require
 any particular version numbers in the versioned dependencies, only the
 specific order.  In particular, if libpam-systemd needs to increase its
 versioned dependency on systemd-shim, or if it ever needs to add a
 versioned dependency on systemd-sysv, that change should not violate
 this TC decision.

I am happy to clarify this.  I have added:

  6. For the avoidance of doubt, we do not intend to set this specific
 syntax in stone.  For example, if in future libpam-systemd needs to
 depend on a later systemd-shim, or needs a versioned rather than
 unversioned dependency on systemd-sysv, that is fine and would not
 contradict our decision.

  Release (Constitution  6.1(5)):
  
  5. We request that the Release Team allow this change to into jessie.
 (This request should be conveyed to the Release Team, after the
 change is in unstable, by filing an unblock request in the usual
 way.)
 
 Is this point necessary?  The freeze has not yet occurred, and I don't
 see any obvious reason why the TC needs to explicitly direct the release
 team here.

Unless my understanding of the release schedule is confused, I think
that a change to the systemd source package, uploaded now, would not
make it into jessie without a freeze exception.

But I'm happy to make this contingent.  How about:

  7. Our advice is that this change should be in jessie.  If necessary,
 this view should be conveyed to the Release Team, after the change
 is in unstable, by filing an unblock request in the usual way.

Ian.


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



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-02 Thread Ian Jackson
Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - 
proposal):
 Here is my draft, just committed to git.  I'm open to suggestions for
 changes.  If we can't agree on the rationale I guess we could leave it
 out.

Josh Triplette produced a helpful detailed review.  Here is the
revised draft.

Ian.

Rationale (Constitution 6.1(5)):

1. Currently libpam-systemd (which is pulled in by quite a few
   dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'.

2. The effect of this is that installing some packages which depend
   (directly or indirectly) on libpam-systemd can cause a user's init
   system to be switched to systemd, even on systems where a user has
   deliberately chosen not to use the default init system, and even
   when the switch is unnecessary.

3. Swappping the order of these dependencies would avoid that and has
   no harmful effect:

4. In particular, on systems that already have systemd-sysv installed,
   libpam-systemd will still not pull in systemd-shim, thus minimizing
   the risk of breakage on systemd systems.  However, on systems that
   intentionally do not have systemd installed, the installation of
   libpam-systemd will then prefer to pull in systemd-shim and keep
   the installed init system rather than switching to systemd-sysv.

Decision (Constitution 6.1(4)):

5. We therefore overrule the decision of the maintainer of
   libpam-systemd binary package.  The Depends entry
  systemd-sysv | systemd-shim (= 8-2)
   should be replaced by 
  systemd-shim (= 8-2) | systemd-sysv

6. For the avoidance of doubt, we do not intend to set this specific
   syntax in stone.  For example, if in future libpam-systemd needs to
   depend on a later systemd-shim, or needs a versioned rather than
   unversioned dependency on systemd-sysv, that is fine and would not
   contradict our decision.

Release (Constitution 6.1(5)):

7. Our advice is that this change should be in jessie.  If necessary,
   this view should be conveyed to the Release Team, after the change
   is in unstable, by filing an unblock request in the usual way.


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



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-02 Thread Josh Triplett
On Sun, 2 Nov 2014 14:19:45 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - 
 proposal):
  Here is my draft, just committed to git.  I'm open to suggestions for
  changes.  If we can't agree on the rationale I guess we could leave it
  out.
 
 Josh Triplette produced a helpful detailed review.  Here is the
 revised draft.

s/Triplette/Triplett/ :)

And thank you for the update.

One minor (but semantically significant) issue below, caused by a typo
in my original suggestion.

 Rationale (Constitution 6.1(5)):
 
 1. Currently libpam-systemd (which is pulled in by quite a few
dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'.
 
 2. The effect of this is that installing some packages which depend
(directly or indirectly) on libpam-systemd can cause a user's init
system to be switched to systemd, even on systems where a user has
deliberately chosen not to use the default init system, and even
when the switch is unnecessary.
 
 3. Swappping the order of these dependencies would avoid that and has
no harmful effect:
 
 4. In particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing
the risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep
the installed init system rather than switching to systemd-sysv.

s/intentionally do not have systemd/intentionally do not have systemd-sysv/

- Josh Triplett

 Decision (Constitution 6.1(4)):
 
 5. We therefore overrule the decision of the maintainer of
libpam-systemd binary package.  The Depends entry
   systemd-sysv | systemd-shim (= 8-2)
should be replaced by 
   systemd-shim (= 8-2) | systemd-sysv
 
 6. For the avoidance of doubt, we do not intend to set this specific
syntax in stone.  For example, if in future libpam-systemd needs to
depend on a later systemd-shim, or needs a versioned rather than
unversioned dependency on systemd-sysv, that is fine and would not
contradict our decision.
 
 Release (Constitution 6.1(5)):
 
 7. Our advice is that this change should be in jessie.  If necessary,
this view should be conveyed to the Release Team, after the change
is in unstable, by filing an unblock request in the usual way.
 
 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102171044.GA6632@thin



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-02 Thread Ian Jackson
Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - 
proposal):
 On Sun, 2 Nov 2014 14:19:45 + Ian Jackson 
 ijack...@chiark.greenend.org.uk wrote:
  Josh Triplette produced a helpful detailed review.  Here is the
  revised draft.
 
 s/Triplette/Triplett/ :)

Glerk.  Sorry!  I got your name right _most_ of the times...

 One minor (but semantically significant) issue below, caused by a typo
 in my original suggestion.
...
  4. In particular, on systems that already have systemd-sysv installed,
 libpam-systemd will still not pull in systemd-shim, thus minimizing
 the risk of breakage on systemd systems.  However, on systems that
 intentionally do not have systemd installed, the installation of
 libpam-systemd will then prefer to pull in systemd-shim and keep
 the installed init system rather than switching to systemd-sysv.
 
 s/intentionally do not have systemd/intentionally do not have systemd-sysv/

Fixed in git.  I hereby make that change to my formal proposal.

Thanks,
Ian.


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



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-01 Thread Ian Jackson
Here is my draft, just committed to git.  I'm open to suggestions for
changes.  If we can't agree on the rationale I guess we could leave it
out.

Ian.



Rationale (Constitution 6.1(5)):

1. Currently libpam-systemd (which is pulled in by quite a few
   dependency chains) Depends on `systemd-sysv | systemd-shim'.

2. The effect of this is that installing certain leaf packages which
   depend on libpam-systemd can cause a user's init system to be
   switched to systemd, even on systems where a user has deliberately
   chosen not to use the default init system, and even when the switch
   is unnecessary.

3. Swappping the order of these dependencies would avoid that and has
   no harmful effect.

Decision (Constitution 6.1(4)):

4. We therefore overrule the decision of the maintainer of
   libpam-systemd binary package.  The Depends entry
  systemd-sysv | systemd-shim (= 8-2)
   should be replaced by 
  systemd-shim (= 8-2) | systemd-sysv

Release (Constitution  6.1(5)):

5. We request that the Release Team allow this change to into jessie.
   (This request should be conveyed to the Release Team, after the
   change is in unstable, by filing an unblock request in the usual
   way.)

-- 


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



Bug#746578: libpam-systemd to flip dependencies - proposal

2014-11-01 Thread Russ Allbery
Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Rationale (Constitution 6.1(5)):

 1. Currently libpam-systemd (which is pulled in by quite a few
dependency chains) Depends on `systemd-sysv | systemd-shim'.

 2. The effect of this is that installing certain leaf packages which
depend on libpam-systemd can cause a user's init system to be
switched to systemd, even on systems where a user has deliberately
chosen not to use the default init system, and even when the switch
is unnecessary.

 3. Swappping the order of these dependencies would avoid that and has
no harmful effect.

 Decision (Constitution 6.1(4)):

 4. We therefore overrule the decision of the maintainer of
libpam-systemd binary package.  The Depends entry
   systemd-sysv | systemd-shim (= 8-2)
should be replaced by 
   systemd-shim (= 8-2) | systemd-sysv

 Release (Constitution  6.1(5)):

 5. We request that the Release Team allow this change to into jessie.
(This request should be conveyed to the Release Team, after the
change is in unstable, by filing an unblock request in the usual
way.)

This looks fine to me.

So, this is also the last call for anyone to explain what harmful effect
this could have if they think it would have a harmful effect.  My
understanding is that all of the possible harmful effects have been fixed
by various other changes.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877fzesox5@hope.eyrie.org