Re: Nftables in jessie?

[Arturo Borrero Gonzalez]

On 8 May 2014 19:16, Frank Bauer  wrote:
> Hi,
>
> Jessie currently contains linux 3.13, which includes the successor of
> iptables - nftables.
> Unfortunately, the userspace tools (nftables) are still missing even in
> sid/experimental.
>

As Vincent Bernat said, is in NEW. Has been in NEW for a month or so.

> Is there a general plan to support nftables in jessie? As the release
> managers reminded
> us recently, the freeze will be here in no time. I believe it is essential
> for users to be able
> to test this new technology in jessie before fully switching to it in
> jessie+1.
>

Unfortunately, there isn't a 'general plan'.

I mean, the package will be uploaded and maintained. But no talk
happened about what means having nftables in Debian.

I think the following points may be interesting:
 * in which state/shape is the nftables framework?
 * what about the iptables and the compat layer? The next upstream
release of iptables will, by default, use the nf_tables kernel
subsystem.
 * what about a standard firewall service (like other distros do).
iptables also lacks of it.
 * Some bugs happened in the Debian kernel package, and the kernel
currently in Jessie comes without nf_tables enabled [0].

Thanks for your interest Frank.

I would like to hear suggestions, comments and ideas.

regards.

[0]  #742763 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742763

-- 
Arturo Borrero González


--
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/caoksjbiaqgbrxkxswg0_ky3+iorg-4r3op69joav2jzrhop...@mail.gmail.com

Bug#747481: ITP: backports.ssl-match-hostname -- Backport of the Python 3.2 SSL hostname checking function

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: backports.ssl-match-hostname
  Version : 3.4.0.2
  Upstream Author : Brandon Craig Rhodes
* URL : https://bitbucket.org/brandon/backports.ssl_match_hostname
* License : Python
  Programming Lang: Python
  Description : Backport of the Python 3.2 SSL hostname checking function

 The Secure Sockets layer is only actually secure if you check the
 hostname in the certificate returned by the server to which you are
 connecting, and verify that it matches to hostname that you are trying
 to reach.
 .
 But the matching logic, defined in RFC2818, can be a bit tricky to
 implement on your own. So the ssl package in the Standard Library of
 Python 3.2 and greater now includes a match_hostname() function for
 performing this check instead of requiring every application to
 implement the check separately.
 .
 This package contains a backport of the ssl.match_hostname function for
 Python 2.4 and above.


-- 
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/20140509083409.9292.16377.report...@darboux.home.olasd.eu

Bug#747493: ITP: openjdk-7-jdk-dcevm -- Dynamic Code Evolution VM - Enhanced runtime class redefinition for Java

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: dcevm
  Version : 0.2+7u51-20140430
  Upstream Author : Thomas Wuerthinger 
* URL : https://github.com/dcevm/dcevm
* License : GPL-2 with Classpath exception
  Programming Lang: C++
  Description : Dynamic Code Evolution VM - Enhanced runtime class
redefinition for Java

The Dynamic Code Evolution Virtual Machine (DCE VM) is a modification of
the Java HotSpot VM that allows unlimited redefinition of loaded classes
at runtime. The current hotswapping mechanism of the HotSpot VM allows
only changing method bodies. This enhanced VM allows adding and removing
fields and methods as well as changes to the super types of a class.

This package will extend the openjdk-7-jdk package by copying its
content in the /usr/lib/jvm/java-7-dcevm-amd64 directory and replacing
the HotSpot libraries in the jre/lib/amd64 sub directory. The initial
package will only target the i386 and amd64 architectures.


-- 
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/536c9fa1.9090...@apache.org

Re: systemd-fsck?

[Svante Signell]

On Thu, 2014-05-08 at 18:42 -0700, Russ Allbery wrote:
> Svante Signell  writes:
> 
> > I'm trying to install as little as possible of systemd stuff, and guess
> > what happens: When booting one of the laptops boot starts with:
> > systyemd-fsck 
> 
> > Is systemd taking over everything?? How to reduce the number of
> > systemd-* features.
> 
> It's a small wrapper around fsck that handles status reporting in a way
> that works well with the journal and with systemd boot-time status
> reporting and takes care of some dbus coordination and whatnot.  I believe
> It's basically the equivalent of all the shell logic in checkroot.sh and
> checkfs.sh.  In other words, well within the mandate for anything that
> handles early boot, replacing shell scripts that were previously provided
> by initscripts.
> 
> The actual fsck work is still done by the separate fsck binary, just like
> it always has been.

Well, I've not been asked if I wanted to switch to systemd based boot
when upgrading. I think this is a bug in init system choice and should
be reported. How to go back to sysvinit?

Installed packages:
ii  libpam-systemd:amd64  204-10
ii  libsystemd-daemon0:amd64  204-10
ii  libsystemd-id128-0:amd64  204-10
ii  libsystemd-journal0:amd64 204-10
ii  libsystemd-login0:amd64   204-10
ii  systemd   204-10
ii  systemd-sysv  204-10
ii  sysvinit   2.88dsf-53
ii  initscripts2.88dsf-53
ii  sysv-rc2.88dsf-53

Which ones can I safely remove when going back to sysvinit?


-- 
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/1399631705.2096.16.camel@PackardBell-PC

How to go back to sysvinit (was: Re: systemd-fsck?)

[Ansgar Burchardt]

Hi,

On 05/09/2014 12:35, Svante Signell wrote:
> Well, I've not been asked if I wanted to switch to systemd based boot
> when upgrading. I think this is a bug in init system choice and should
> be reported. How to go back to sysvinit?

Please ask on one of the support mailing lists (CC'ed).

> Installed packages:
> ii  libpam-systemd:amd64  204-10
> ii  libsystemd-daemon0:amd64  204-10
> ii  libsystemd-id128-0:amd64  204-10
> ii  libsystemd-journal0:amd64 204-10
> ii  libsystemd-login0:amd64   204-10
> ii  systemd   204-10
> ii  systemd-sysv  204-10
> ii  sysvinit   2.88dsf-53
> ii  initscripts2.88dsf-53
> ii  sysv-rc2.88dsf-53
> 
> Which ones can I safely remove when going back to sysvinit?

You probably need to replace systemd-sysv with systemd-shim (to satisfy
the dependency libpam-systemd) and install the package shipping
/sbin/init instead (whatever it is called).

Ansgar


-- 
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/536cb764.1090...@debian.org

Re: systemd-fsck?

[Sune Vuorela]

On 2014-05-09, Svante Signell  wrote:
> Well, I've not been asked if I wanted to switch to systemd based boot
> when upgrading. I think this is a bug in init system choice and should
> be reported. How to go back to sysvinit?

I'd expect it to be a bug if I don't get migrated to systemd at some
upgrade.

> ii  systemd-sysv  204-10
>
> Which ones can I safely remove when going back to sysvinit?

That one should bring you back to sysvinit.

/Sune


-- 
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/lkidpm$hrj$1...@ger.gmane.org

Re: systemd-fsck?

[Tollef Fog Heen]

]] Svante Signell 

> On Thu, 2014-05-08 at 18:42 -0700, Russ Allbery wrote:
> > Svante Signell  writes:
> > 
> > > I'm trying to install as little as possible of systemd stuff, and guess
> > > what happens: When booting one of the laptops boot starts with:
> > > systyemd-fsck 
> > 
> > > Is systemd taking over everything?? How to reduce the number of
> > > systemd-* features.
> > 
> > It's a small wrapper around fsck that handles status reporting in a way
> > that works well with the journal and with systemd boot-time status
> > reporting and takes care of some dbus coordination and whatnot.  I believe
> > It's basically the equivalent of all the shell logic in checkroot.sh and
> > checkfs.sh.  In other words, well within the mandate for anything that
> > handles early boot, replacing shell scripts that were previously provided
> > by initscripts.
> > 
> > The actual fsck work is still done by the separate fsck binary, just like
> > it always has been.
> 
> Well, I've not been asked if I wanted to switch to systemd based boot
> when upgrading. I think this is a bug in init system choice and should
> be reported.

The default has changed and you chose to accept the defaults when you
upgraded.

> How to go back to sysvinit?

I think installing sysvinit-core should work, but I at least have never
tested that.

-- 
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/87a9ar9lq0@xoog.err.no

Re: systemd-fsck?

[Andrew Shadura]

Hello,

On 9 May 2014 14:32, Tollef Fog Heen  wrote:
>> Well, I've not been asked if I wanted to switch to systemd based boot
>> when upgrading. I think this is a bug in init system choice and should
>> be reported.

> The default has changed and you chose to accept the defaults when you
> upgraded.

Changes to the default init system should not affect existing setups.

-- 
Cheers,
  Andrew


-- 
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/cacujmdpkryacdfptddqmr+bmy8xtecvipsiof6ic1q+v0uk...@mail.gmail.com

Re: systemd-fsck?

[Tollef Fog Heen]

]] Andrew Shadura 

> Hello,
> 
> On 9 May 2014 14:32, Tollef Fog Heen  wrote:
> >> Well, I've not been asked if I wanted to switch to systemd based boot
> >> when upgrading. I think this is a bug in init system choice and should
> >> be reported.
> 
> > The default has changed and you chose to accept the defaults when you
> > upgraded.
> 
> Changes to the default init system should not affect existing setups.

Were that true, it would be different to how we handle changes in other
defaults.

-- 
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/8761lf9i6m@xoog.err.no

Re: systemd-fsck?

[Thorsten Glaser]

On Fri, 9 May 2014, Andrew Shadura wrote:

> On 9 May 2014 14:32, Tollef Fog Heen  wrote:
> >> Well, I've not been asked if I wanted to switch to systemd based boot
> >> when upgrading. I think this is a bug in init system choice and should
> >> be reported.

ACK.

I noticed this because I have a package “systemd-must-die” which
Conflicts with everything with systemd in its name, except those
libs everyone seems to have been using for a while already.

In my specific case, some *kit (policykit?) was “held back” by
apt-get dist-upgrade, because it introduced a Depends on…

> >> ii  libpam-systemd:amd64  204-10

… which I had prevented using systemd-must-die¹. But it was
safe to just apt-get purge that *kit package.

> >> ii  libsystemd-daemon0:amd64  204-10
> >> ii  libsystemd-id128-0:amd64  204-10
> >> ii  libsystemd-journal0:amd64 204-10
> >> ii  libsystemd-login0:amd64   204-10

Those are safe to keep.

> >> ii  systemd   204-10
> >> ii  systemd-sysv  204-10

You can purge them. Install sysvinit-core at the same time.

Another mistake you likely did is that, after the initial
installation, you did not add
APT::Install-Recommends "0";
to /etc/apt/apt.conf, which is a must-have to be able to
run Debian without something unwanted being run all the time.

> > The default has changed and you chose to accept the defaults when you
> > upgraded.
>
> Changes to the default init system should not affect existing setups.

Strong ACK.

(I was very angry about the lenny → squeeze upgrade changing
GRUB 1 to GRUB 2 in-place, because on 95+% of our VMs at work
this meant them not coming up *at all* anymore. Luckily it was
possible to change sources.list to squeeze then install the
grub-legacy package, then going on with the upgrade normally,
at that time. I fully expect

ⓐ to not have to do this to avoid systemd on upgrades to jessie,

ⓑ to be able to choose to install a jessie system without systemd
  without having to resort to installing wheezy and upgrading;

but especially the first point.)


bye,
//mirabilos
① http://users.unixforge.de/~tglaser/debs/dists/etch/wtf/Pkgs/mirabilos-support/
  is where the systemd-must-die package currently resides, along with
  a couple more… strong suggestions.
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
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/alpine.deb.2.10.1405091600120.3...@tglase.lan.tarent.de

Re: systemd-fsck?

[Thorsten Glaser]

Tollef Fog Heen wrote:

>> Changes to the default init system should not affect existing setups.
>
>Were that true, it would be different to how we handle changes in other
>defaults.

A default is a default because it is only applies when the
sysadmin defaults to it, when the sysadmin defaults making
a decision themselves.

Debian has no distinction between "retain the default because
it is a default" and "keep $foo (which happened to be the default
at some point in time) as conscious decision", which proves that
changes in defaults shall not be applied on upgrades by default
(hah!).

bye,
//mirabilynx


-- 
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/lkinj1$6pr$1...@ger.gmane.org

Re: systemd-fsck?

[Andrew Shadura]

Hello,

On 9 May 2014 15:48, Tollef Fog Heen  wrote:
>> Changes to the default init system should not affect existing setups.

> Were that true, it would be different to how we handle changes in other
> defaults.

No, it wouldn't. If exim4 is a default MTA, and then it changes to
something else, it doesn't mean exim4 is automatically replaced by the
new default.

-- 
Cheers,
  Andrew


-- 
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/CACujMDO9fjaG3wO4NebxnHH7terBPxzvCt=NYm=yq7qt06v...@mail.gmail.com

Re: systemd-fsck?

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/09/2014 09:48 AM, Tollef Fog Heen wrote:

> ]] Andrew Shadura
> 
>> Hello,
>> 
>> On 9 May 2014 14:32, Tollef Fog Heen  wrote:
 Well, I've not been asked if I wanted to switch to systemd
 based boot when upgrading. I think this is a bug in init system
 choice and should be reported.

I would tend to agree that with a change this major, even if there's no
"do you want to switch?" question, there should be a big, honking,
sirens-and-klaxons "you are about to make a major change to one of the
fundamental underpinnings of your system!" alert notification.

>>> The default has changed and you chose to accept the defaults when
>>> you upgraded.
>> 
>> Changes to the default init system should not affect existing
>> setups.
> 
> Were that true, it would be different to how we handle changes in
> other defaults.

If you install Debian with the default desktop environment / window
manager, and then a different default is chosen for the next release,
dist-upgrading to that release will not AFAIK switch you over to the new
default.

I imagine that that's at least in part because which window manager, et
cetera, to use is determined on a per-user basis, whereas the init
system is system-wide. It might still be considered as a potential
counterexample, however.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTbOS4AAoJEASpNY00KDJrkBIP/0N3eZvhtcrtjl1Dz80bLC2e
ohlsnnZiUrTHHziOFQUK4A/gDmFLg30Ir5fh5EU/d/SuOGCaX9sEMIyNxa4vJ8tm
Cv0IYOIA3wgxwrJbyvBI6/iJ3Ox1NpeFtaWXOWC+zGSJkzB5MALzM7OC1kb8EK8x
n48NdPuT77TNRmCKVgRWcBrG+hiNacUF9n+mPVg4W9+A2KrwtXjjixSoQMTMFIMn
434EE6hnP3ZEBx5seeCbq/kWWeMpnzHW1fOkxGRlKHN+5n2z+lTApCJLHdDg/CgW
KgaI6cRkF+znDbwTW0pFzP7js5E15aID2qDSYcOaW5yI6OtHhPbKNT9ni4B2QaPn
6cWqGvY8WvOTaaR3kTBIVHHTm2e389yUbNTsbghdAgBrRQkvmpk8ZfSa3OH22tDS
bk2BQyqylm4+lbw8kY1J12qF2QdQUgvG8e9DyI/hM6vN+v80VvElBOPI4d/Lbbgk
/9bbiEmiNlpF1DnpISv9xn51z8NCkKD8Pe+Lm/q9KJSc/GvxO4LnfQSbcDIejKIc
Oq3upbIkwOitVOiFPkTYLVrmuQ8ZijbF770kO6DnzC8LWXYKPTySjDvhStHs90uD
VpxPgWgaY02aTAcblw/DK7YVZdfUHlY95DEHAXO+4uzCrl4ieReEjWnBy1ZL1lY/
EPvYHLIaPLNktMAg3xkE
=HXXM
-END PGP SIGNATURE-


-- 
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/536ce4b8.1020...@fastmail.fm

Re: systemd-fsck?

[Tollef Fog Heen]

]] Thorsten Glaser 

> Tollef Fog Heen wrote:
> 
> >> Changes to the default init system should not affect existing setups.
> >
> >Were that true, it would be different to how we handle changes in other
> >defaults.
> 
> A default is a default because it is only applies when the
> sysadmin defaults to it, when the sysadmin defaults making
> a decision themselves.

I'm not able to parse that sentence.

> Debian has no distinction between "retain the default because
> it is a default" and "keep $foo (which happened to be the default
> at some point in time) as conscious decision", which proves that
> changes in defaults shall not be applied on upgrades by default
> (hah!).

This is not how defaults in conffiles and other configurations files are
handled, so I dispute that.

In addition, apt (and I assume dselect and cupt) ask you if you want to
accept the proposed solution.  If you don't, well then choose another?

-- 
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/m2lhubj96i@rahvafeir.err.no

Re: Bug #702005: Where can i get more attention on this?

[Didier 'OdyX' Raboud]

Le jeudi, 8 mai 2014, 13.05:52 Ian Jackson a écrit :
> Unfortunately, Luis's mail domain is hosted at Hotmail which hates
> chiark:

Pot calling the kettle black: chiark hates a lot of servers out there 
when it's "Irritated"…

OdyX


--
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/1915138.zsAfhk3TAZ@gyllingar

Re: systemd-fsck?

[Neil Williams]

On Fri, 9 May 2014 16:06:46 +0200
Thorsten Glaser  wrote:

> On Fri, 9 May 2014, Andrew Shadura wrote:
> 
> > Changes to the default init system should not affect existing
> > setups.
> 
> Strong ACK.

That only happens when the default is at the Debian Installer / tasksel
level.

e.g. a change of default desktop for d-i only affects new d-i installs.

A change of default compiler version *regularly* affects any existing
setup which has build-essential installed and this is 100% correct.

Nobody wants their pbuilder / schroot build environments stuck on an
old version of the compiler - nor does anyone actually want to require
manual intervention to go from gcc-4.8 to gcc-4.9 - that's what we have
the gcc package.

Same is true for the default python interpreter or various other
default packages rather than "package selections" via tasksel or d-i.


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: systemd-fsck?

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/09/2014 11:04 AM, Neil Williams wrote:

> On Fri, 9 May 2014 16:06:46 +0200 Thorsten Glaser 
> wrote:
> 
>> On Fri, 9 May 2014, Andrew Shadura wrote:
>> 
>>> Changes to the default init system should not affect existing
>>> setups.
>> 
>> Strong ACK.
> 
> That only happens when the default is at the Debian Installer /
> tasksel level.
> 
> e.g. a change of default desktop for d-i only affects new d-i
> installs.
> 
> A change of default compiler version *regularly* affects any existing
> setup which has build-essential installed and this is 100% correct.
> 
> Nobody wants their pbuilder / schroot build environments stuck on an
> old version of the compiler - nor does anyone actually want to
> require manual intervention to go from gcc-4.8 to gcc-4.9 - that's
> what we have the gcc package.
> 
> Same is true for the default python interpreter or various other
> default packages rather than "package selections" via tasksel or d-i.

There is a considerable difference, however, between automatically
installing the new version of a program (even if in a different package
for whatever reason) and automatically installing a completely different
program from the original, simply because both programs are intended for
the same role.

You could argue that it's appropriate to do anyway - e.g. that it would
be appropriate to automatically switch existing systems from gcc to
clang if the default compiler referenced by build-essential got changed.
It still shouldn't be treated as the same thing as a simple version
upgrade, however.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTbPjoAAoJEASpNY00KDJrs/oP/21HT9rxd69UYOTDoEwILFt7
BSSjj80iNGtUY+zZqPsbs/GvgQqIW50i6sqYjO5tzHUHn9l5RNybHEbs6dqEjV/a
2pwesFVp0XLJ1Qa2q+0X5y5Vf+UzYVGMkBUGxrPA1bQqzOad99AeU+r28RvHaBCf
X6XGpt+TpRbl2l7db8m+zJV5hCPMlK1KFWsRti/JfsaYYs8WE+opnUu76nm8G+dW
ZA/ANm01wNU8NIC+ct6ue1X/3c6OjUILk0yls8cUHvDDBbtA+lPIXfba37KSAoNO
pwGkehKLQXDWAfZp4/nQve8xu/sO/acjsGeYklOMHavg9uXcwurGBDQskoChZtTb
/ALYUSEm95C1aaed79zdxjhVlcN/hIL7dhkFwF+Lnghq8QYJVf+4jcLwU+vix8vX
9YjSsmlbPJDw/CoAQc6hiIKkJA07rUCyzRHxBTW3nDIkQ6mA+5P9iNcgZiz4jkqL
rLKf7vDBAjEXa5kx35wAhATYtj9TAAQGRpn2LTpdaXxb1W9s3I0E5w/3dXh8W7PW
c+MlKEQ3sK3PZkQq1b3CjgH8sAzzxNZrz78QFYQBrOdYpOyYyXsJIjdw4Y9EP6Ev
CQnLu4VRK5azb3PjIqcWpdwWZg1/BDZ9vaL4cAG8pJqKz9rP3Vbhqq5TNQGEUDGl
naym04AwzeGrBKDD4B6V
=eyxN
-END PGP SIGNATURE-


-- 
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/536cf8e8.30...@fastmail.fm

Re: systemd-fsck?

[Russ Allbery]

The Wanderer  writes:

> There is a considerable difference, however, between automatically
> installing the new version of a program (even if in a different package
> for whatever reason) and automatically installing a completely different
> program from the original, simply because both programs are intended for
> the same role.

> You could argue that it's appropriate to do anyway - e.g. that it would
> be appropriate to automatically switch existing systems from gcc to
> clang if the default compiler referenced by build-essential got changed.
> It still shouldn't be treated as the same thing as a simple version
> upgrade, however.

I think we need some sort of critical debconf prompt here for the jessie
release, similar to how we handled the change of /bin/sh to dash and how
we handled the switch to startpar.  Probably in systemd-sysv, which is the
package that forces the conversion.  It's quite surprising to, for
example, install network-manager (which is an application that ca be used
with non-GNOME window managers) and end up with a new init system.

As for the original question, systemd-sysv was probably installed as a
dependency of either gdm3 or network-manager by way of libpam-systemd
(which provides cgroup setup).

-- 
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/8738giyla6@windlord.stanford.edu

Re: systemd-fsck?

[Arturo Borrero Gonzalez]

On 9 May 2014 18:22, Russ Allbery  wrote:
>
> I think we need some sort of critical debconf prompt here for the jessie
> release,  [...]

I fully agree with this.

regards.
-- 
Arturo Borrero González


--
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/caoksjbhtvvtw85b3pkihsna-mn7dcl8e4k3c+stmcjdrom6...@mail.gmail.com

Re: systemd-fsck?

[Michael Biebl]

Am 09.05.2014 18:22, schrieb Russ Allbery:
> I think we need some sort of critical debconf prompt here for the jessie
> release, similar to how we handled the change of /bin/sh to dash and how
> we handled the switch to startpar.  Probably in systemd-sysv, which is the
> package that forces the conversion.  It's quite surprising to, for
> example, install network-manager (which is an application that ca be used
> with non-GNOME window managers) and end up with a new init system.

I'm not opposed to adding such a debconf prompt, but if we add that
debconf prompt to systemd-sysv, we will get this even on new
installations. I don't think we want that.
Or do you see a way how we can add the debconf prompt without triggering
it on new installations?

Michael

-- 
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-fsck?

[Simon McVittie]

On 09/05/14 17:22, Russ Allbery wrote:
> I think we need some sort of critical debconf prompt here for the jessie
> release, similar to how we handled the change of /bin/sh to dash and how
> we handled the switch to startpar.  Probably in systemd-sysv, which is the
> package that forces the conversion.

To be able to do that, I think the packaging of sysvinit and/or
systemd-sysv would have to change. systemd-sysv only seems to contain
symlinks, which are files in the .deb at the moment, but could change to
being shuffled around by maintainer scripts; but sysvinit-core (formerly
sysvinit) contains real files in the .deb, so systemd-sysv Conflicts and
Replaces it.

It might actually be nicer to move the real sysvinit binaries to a
non-conflicting location in sysvinit (or a new non-Essential
sysvinit-bin or something, if it's desirable to keep the Essential
sysvinit package as a metapackage depending on any supported pid 1
implementation), and have both sysvinit-core and systemd-sysv consist
entirely of symlinks. That would let cautious systemd users keep the
sysvinit binaries around, and boot with init=/usr/lib/sysvinit/init if
something went horribly wrong with systemd.

S


-- 
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/536d0d8b.8030...@debian.org

Re: systemd-fsck?

[Cyril Brulebois]

Michael Biebl  (2014-05-09):
> Am 09.05.2014 18:22, schrieb Russ Allbery:
> > I think we need some sort of critical debconf prompt here for the jessie
> > release, similar to how we handled the change of /bin/sh to dash and how
> > we handled the switch to startpar.  Probably in systemd-sysv, which is the
> > package that forces the conversion.  It's quite surprising to, for
> > example, install network-manager (which is an application that ca be used
> > with non-GNOME window managers) and end up with a new init system.
> 
> I'm not opposed to adding such a debconf prompt, but if we add that
> debconf prompt to systemd-sysv, we will get this even on new
> installations. I don't think we want that.
> Or do you see a way how we can add the debconf prompt without triggering
> it on new installations?

At first glance, it wouldn't seem too crazy to me to add the needed
bit(s) in d-i so that the prompt is skipped on new installations.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Svante Signell]

On Fri, 2014-05-09 at 19:04 +0200, Arturo Borrero Gonzalez wrote:
> On 9 May 2014 18:22, Russ Allbery  wrote:
> >
> > I think we need some sort of critical debconf prompt here for the jessie
> > release,  [...]
> 
> I fully agree with this.

bug #747535


-- 
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/1399657359.2096.46.camel@PackardBell-PC

Re: systemd-fsck?

[Arturo Borrero Gonzalez]

On 9 May 2014 19:42, Svante Signell  wrote:
> On Fri, 2014-05-09 at 19:04 +0200, Arturo Borrero Gonzalez wrote:
>> On 9 May 2014 18:22, Russ Allbery  wrote:
>> >
>> > I think we need some sort of critical debconf prompt here for the jessie
>> > release,  [...]
>>
>> I fully agree with this.
>
> bug #747535
>

Thanks Svante. I will keep and eye on the bug.

regards.

-- 
Arturo Borrero González


--
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/CAOkSjBhfz81hR3DmoOinPGxC-QP5AKgVrMoT4qTv+3G1x�3...@mail.gmail.com

Re: systemd-fsck?

[Steve Langasek]

On Fri, May 09, 2014 at 02:32:07PM +0200, Tollef Fog Heen wrote:
> ]] Svante Signell 

> > On Thu, 2014-05-08 at 18:42 -0700, Russ Allbery wrote:
> > > Svante Signell  writes:

> > > > I'm trying to install as little as possible of systemd stuff, and guess
> > > > what happens: When booting one of the laptops boot starts with:
> > > > systyemd-fsck 

> > > > Is systemd taking over everything?? How to reduce the number of
> > > > systemd-* features.

> > > It's a small wrapper around fsck that handles status reporting in a way
> > > that works well with the journal and with systemd boot-time status
> > > reporting and takes care of some dbus coordination and whatnot.  I believe
> > > It's basically the equivalent of all the shell logic in checkroot.sh and
> > > checkfs.sh.  In other words, well within the mandate for anything that
> > > handles early boot, replacing shell scripts that were previously provided
> > > by initscripts.

> > > The actual fsck work is still done by the separate fsck binary, just like
> > > it always has been.

> > Well, I've not been asked if I wanted to switch to systemd based boot
> > when upgrading. I think this is a bug in init system choice and should
> > be reported.

> The default has changed and you chose to accept the defaults when you
> upgraded.

The default hasn't changed; sysvinit still lists sysvinit-core as the first
alternative for its pre-dependency on /sbin/init.  What is forcing
systemd-sysv onto users systems in advance of this change?

I don't think systemd integration is in a state today that this is ready to
become the default.

-- 
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-fsck?

[Kevin Chadwick]

previously on this list Simon McVittie contributed:

> That would let cautious systemd users keep the
> sysvinit binaries around, and boot with init=/usr/lib/sysvinit/init if
> something went horribly wrong with systemd.

Not that it would affect me but that would be wise, an upstream bug
caused arch testings pid1 to segfault not long after they switched.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/651368.84881...@smtp114.mail.ir2.yahoo.com

Re: systemd-fsck?

[Michael Biebl]

Am 09.05.2014 19:56, schrieb Steve Langasek:

> I don't think systemd integration is in a state today that this is ready to
> become the default.

What are you missing?

-- 
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-fsck?

[Steve Langasek]

On Fri, May 09, 2014 at 04:06:46PM +0200, Thorsten Glaser wrote:

> In my specific case, some *kit (policykit?) was “held back” by
> apt-get dist-upgrade, because it introduced a Depends on…

> > >> ii  libpam-systemd:amd64  204-10

> … which I had prevented using systemd-must-die¹. But it was
> safe to just apt-get purge that *kit package.
> 
> > >> ii  libsystemd-daemon0:amd64  204-10
> > >> ii  libsystemd-id128-0:amd64  204-10
> > >> ii  libsystemd-journal0:amd64 204-10
> > >> ii  libsystemd-login0:amd64   204-10

> Those are safe to keep.

> > >> ii  systemd   204-10
> > >> ii  systemd-sysv  204-10

> You can purge them. Install sysvinit-core at the same time.

This is unconstructive advice.  The systemd binary package contains logind,
which is the de facto desktop seat manager for jessie and beyond,
irrespective of init system choice.  You may not like the fact that
installing logind pulls the init onto the filesystem (I don't like this,
either); and you may prefer not to use any sort of recent desktop
environment with seat management on your own systems; but advising people to
purge the systemd package from their systems is just wrong.

> Another mistake you likely did is that, after the initial
> installation, you did not add
>   APT::Install-Recommends "0";
> to /etc/apt/apt.conf, which is a must-have to be able to
> run Debian without something unwanted being run all the time.

This is also unconstructive.

-- 
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-fsck?

[Russ Allbery]

Cyril Brulebois  writes:
> Michael Biebl  (2014-05-09):

>> I'm not opposed to adding such a debconf prompt, but if we add that
>> debconf prompt to systemd-sysv, we will get this even on new
>> installations. I don't think we want that.
>> Or do you see a way how we can add the debconf prompt without triggering
>> it on new installations?

> At first glance, it wouldn't seem too crazy to me to add the needed
> bit(s) in d-i so that the prompt is skipped on new installations.

Yeah, that's my thought.  d-i could preseed the answer to the prompt for
new installations.

-- 
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/87sioiwzm2@windlord.stanford.edu

Re: systemd-fsck?

[Russ Allbery]

Simon McVittie  writes:

> It might actually be nicer to move the real sysvinit binaries to a
> non-conflicting location in sysvinit (or a new non-Essential
> sysvinit-bin or something, if it's desirable to keep the Essential
> sysvinit package as a metapackage depending on any supported pid 1
> implementation), and have both sysvinit-core and systemd-sysv consist
> entirely of symlinks. That would let cautious systemd users keep the
> sysvinit binaries around, and boot with init=/usr/lib/sysvinit/init if
> something went horribly wrong with systemd.

Ah, sort of like what you can do if you install the regular systemd
package, but for sysvinit rather than systemd, so that they're both
somewhat parallel in having symlink packages and binary packages?  That
seems like a good idea.

-- 
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/87oaz6wzk0@windlord.stanford.edu

Re: systemd-fsck?

[Christoph Biedl]

Steve Langasek wrote...

> I don't think systemd integration is in a state today that this is ready to
> become the default.

As long as packages like network-manager depends on systemd and that
dependency causes the init system to be changed accordingly, you can
expect the vast majority of desktops will switch, making systemd not
only the default but also without a feasible alternative.

Using something different from systemd will not be impossible but
introduce that many shortcomings few people will take the burden.

Whether you like it or whether you don't.

Christoph


-- 
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/1399662...@msgid.manchmal.in-ulm.de

Re: systemd-fsck?

[Bas Wijnen]

On Fri, May 09, 2014 at 10:56:43AM -0700, Steve Langasek wrote:
> The default hasn't changed; sysvinit still lists sysvinit-core as the first
> alternative for its pre-dependency on /sbin/init.  What is forcing
> systemd-sysv onto users systems in advance of this change?

Also, if the order of dependencies changes, that should not affect existing
installations.

On my system, I see systemd-sysv being pulled in by libpam-systemd, which is
required by network-manager and policykit-1.

libpam-systemd will accept systemd-shim instead of systemd-sysv as well, but
it's listed later, so the user has to manually select it if they want to keep
their init system.  In a long list of "this needs to be changed to make the
upgrade work", it's very easy to miss that it happens at all, and even if a
user does see it, I don't think we can expect them to understand what it means,
and go check if there is an alternative.

I think it would be good for libpam-systemd to list systemd-shim first.  That
way, installations that already have systemd for some other reason (like it
being the default from d-i) will still work, but it won't switch existing
installations to a new init system unexpectedly.

That being said, I don't really care much about the init system; sysv worked
fine for me, and now I apparently have systemd and it doesn't seem to cause
problems either.

Thanks,
Bas


-- 
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/20140509191302.gg10...@fmf.nl

Bug#747547: ITP: pasdoc -- documentation tool for Pascal source code

[Paul Gevers]

Package: wnpp
Severity: wishlist
Owner: Paul Gevers 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: pasdoc
  Version : 0.13.0
  Upstream Author : Michalis Kamburelis 
* URL : http://pasdoc.sipsolutions.net
* License : GPL-2+
  Programming Lang: Pascal
  Description : documentation tool for Pascal source code

Pasdoc generates documentation for Pascal units. It takes descriptions from
comments within the source code. Documentation output formats include HTML and
LaTeX. Object Pascal, FreePascal and Delphi (up to Delphi 2006) specific
features are supported.

The goal is to maintain this package in the Debian Pascal packaging Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJTbTV/AAoJEJxcmesFvXUKiuIH/2x9ox/L8nwELnbnwsZqO4wX
x+CGve4g9crZIgcNZMBqxNINPDbtSQY0wIZtJgrFm+OkSl8GYqWUr7/GvP3BujVJ
aKG590wAvykRgqqfuX4Cy0D4m2niSadtA46zPKkqpODpVu/9+jy2FfYxg8ovdZ3G
YMtBfnzmgT+cd+4XMHPDa6GOtgQem6qRUW+cjb+Zx0+fy1dFbEcIzO9tFzXWceYx
k4sauoBl2PskfyUiDKuEDCwt+EfvhtBqMsChZcR0EqchTnuRSFKSQpGgPfUfSsbT
a6wXVihRHiEG1d156Gwc9ssSrJQxkius+KwOFYFofcmeV3UnLlPmze8ePsZAjfM=
=bcP9
-END PGP SIGNATURE-


-- 
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/20140509200736.26419.50039.report...@wollumbin.marsaxlokk.homelinux.org

Re: systemd-fsck?

[Tollef Fog Heen]

]] Russ Allbery 

> Simon McVittie  writes:
> 
> > It might actually be nicer to move the real sysvinit binaries to a
> > non-conflicting location in sysvinit (or a new non-Essential
> > sysvinit-bin or something, if it's desirable to keep the Essential
> > sysvinit package as a metapackage depending on any supported pid 1
> > implementation), and have both sysvinit-core and systemd-sysv consist
> > entirely of symlinks. That would let cautious systemd users keep the
> > sysvinit binaries around, and boot with init=/usr/lib/sysvinit/init if
> > something went horribly wrong with systemd.
> 
> Ah, sort of like what you can do if you install the regular systemd
> package, but for sysvinit rather than systemd, so that they're both
> somewhat parallel in having symlink packages and binary packages?  That
> seems like a good idea.

Yes, sysvinit should change in that way.  It and upstart (and any other
providers of /sbin/init) should also grow critical debconf warnings if
you install them and you were previously using systemd as your init so
it's symmetric.

-- 
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/871tw2adu8@xoog.err.no

Re: systemd-fsck?

[Bas Wijnen]

On Fri, May 09, 2014 at 10:37:03PM +0200, Tollef Fog Heen wrote:
> It and upstart (and any other providers of /sbin/init) should also grow
> critical debconf warnings if you install them and you were previously using
> systemd as your init so it's symmetric.

Nobody is suggesting that systemd should give you a critical warning when you
try to install it.  The problem people are having, is that it suddenly installs
itself without the user trying.  When sysv init or upstart do that, they should
get critical warnings as well.  But better yet, they shouldn't do it.  And
neither should systemd.

Thanks,
Bas


-- 
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/20140509214721.gh10...@fmf.nl

Re: systemd-fsck?

[Philip Hands]

Russ Allbery  writes:

> Cyril Brulebois  writes:
>> Michael Biebl  (2014-05-09):
>
>>> I'm not opposed to adding such a debconf prompt, but if we add that
>>> debconf prompt to systemd-sysv, we will get this even on new
>>> installations. I don't think we want that.
>>> Or do you see a way how we can add the debconf prompt without triggering
>>> it on new installations?
>
>> At first glance, it wouldn't seem too crazy to me to add the needed
>> bit(s) in d-i so that the prompt is skipped on new installations.
>
> Yeah, that's my thought.  d-i could preseed the answer to the prompt for
> new installations.

Would it not be better to have the package's config script check for the
existence of evidence of a previous installation of sysvinit?

i.e. does /etc/default/rcS exist on a clean jessie install?

If not, then the config script could check for that file, and only
present the warning/question about a change of init system if the file
exists (which would not be the case for a new install).

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://ftp.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpx_Ng0y7f75.pgp
Description: PGP signature

Bug#747556: ITP: libapache2-controller-perl -- fast MVC-style Apache2 handler apps

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: libapache2-controller-perl
  Version : 1.1.0
  Upstream Author : Mark Hedges 
* URL : 
http://search.cpan.org/~markle/Apache2-Controller-v1.1.0/lib/Apache2/Controller.pm
* License : Perl
  Programming Lang: Perl
  Description : fast MVC-style Apache2 handler apps

Your application IS the controller. A2C gets all the abstractions out
from between your controller logic and the Apache2 methods to control
input/output, status etc. You control Apache2 directly, or use a
rendering base like Apache2::Controller::Render::Template which gives a
method to render using Template Toolkit.

For Apache2 config file setup see Apache2::Controller::Dispatch, which
sets a PerlResponseHandler of Apache::Controller, which then creates
your controller object and calls the chosen method for the uri.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJTbVeWAAoJECzXeF7dp7IPNLAP/jMTDZvm5z1p6aLmx90xoVPd
rcpHeqA5snjGIzitnUEEV2Dp5yscTnKUmSwIOQ3SLN5HhHOhm83w2xDYAvKY5k9R
pT3nvxEzxdWHdmJLCp4+k1IK6EdBmwxamJ+QrmwdVH2Vtt8SysipxALeqTmfMtmE
FNW1wL6/4UwzGeTC2L6J/rFeIxsPiATiTLUgmnTpwmIt0m/AmQAU92LV/sWYfQLl
VynpXkZEulVqzzqvT26M/TqY71dHu1DRkAoAB3KyXdszDz60ORIEw7s8c1dO8LRL
y2W3tc5IaiAcwEkX+5kUhyJutl6Pdw4A2Ix7utoDIq0KZ3VOEzummcxCkN0JNbq7
1tVUDgMWcKlrPCeNeu3O4rg6+238hSQ6fS4CCYaOHP5mnrmbOWnKwhVOd6MJC3ga
XLzW6t0f05WU5uycPCrz1L7jYwb2+oeoDCVyXKLDGCrCwc+nUEABy0Nqlz99Tmas
ns6vDEphiG16hkWXfS2tP0AqPoacXi94S+OVPL7BoRFUsJdFoLYeAxAmnjRmFTHk
7QHmXUtKxAo4nSKj0QZa/LKt+nzEd15NcMVKCB57yRK2FN7zJMuyRg5p/QJJ2/ot
bsImn1r3DKHU3bdncZxy/gL+0lOBrcuxA2pZDHHzm9FBobB697xGbfufmKwRUck0
qR8NKJyPUJbMw/RiGlsi
=8KSE
-END PGP SIGNATURE-


-- 
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/20140509223303.1980.57115.report...@miami.connexer.com

Re: systemd-fsck?

[Michael Biebl]

Am 09.05.2014 23:47, schrieb Philip Hands:
> Russ Allbery  writes:
> 
>> Cyril Brulebois  writes:
>>> Michael Biebl  (2014-05-09):
>>
 I'm not opposed to adding such a debconf prompt, but if we add that
 debconf prompt to systemd-sysv, we will get this even on new
 installations. I don't think we want that.
 Or do you see a way how we can add the debconf prompt without triggering
 it on new installations?
>>
>>> At first glance, it wouldn't seem too crazy to me to add the needed
>>> bit(s) in d-i so that the prompt is skipped on new installations.
>>
>> Yeah, that's my thought.  d-i could preseed the answer to the prompt for
>> new installations.
> 
> Would it not be better to have the package's config script check for the
> existence of evidence of a previous installation of sysvinit?
> 
> i.e. does /etc/default/rcS exist on a clean jessie install?

That file is owned by initscripts, so no, that doesn't work.

Michael


-- 
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-fsck?

[Russ Allbery]

Bas Wijnen  writes:
> On Fri, May 09, 2014 at 10:37:03PM +0200, Tollef Fog Heen wrote:

>> It and upstart (and any other providers of /sbin/init) should also grow
>> critical debconf warnings if you install them and you were previously
>> using systemd as your init so it's symmetric.

> Nobody is suggesting that systemd should give you a critical warning
> when you try to install it.  The problem people are having, is that it
> suddenly installs itself without the user trying.  When sysv init or
> upstart do that, they should get critical warnings as well.  But better
> yet, they shouldn't do it.  And neither should systemd.

The same issue that leads to systemd being installed could well lead to
one of the other init systems being installed for the same reason: some
piece of software integrates with only one init system and Depends on it.
If we can avoid that situation, great -- portable software is always
good.  But belt and suspenders: we should also prepare for that situation
and ensure that any switch of an init system via package installation
results in a critical debconf warning so that no one is caught by
surprise.

This has the advantage of future-proofing against any later change of init
system, letting us reuse the mechanisms that we put in place for this one.

-- 
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/87zjiqsh1e@windlord.stanford.edu

Re: systemd-fsck?

[Josh Triplett]

Russ Allbery wrote:
> The Wanderer  writes:
> > There is a considerable difference, however, between automatically
> > installing the new version of a program (even if in a different package
> > for whatever reason) and automatically installing a completely different
> > program from the original, simply because both programs are intended for
> > the same role.
> 
> > You could argue that it's appropriate to do anyway - e.g. that it would
> > be appropriate to automatically switch existing systems from gcc to
> > clang if the default compiler referenced by build-essential got changed.
> > It still shouldn't be treated as the same thing as a simple version
> > upgrade, however.
> 
> I think we need some sort of critical debconf prompt here for the jessie
> release, similar to how we handled the change of /bin/sh to dash and how
> we handled the switch to startpar.  Probably in systemd-sysv, which is the
> package that forces the conversion.  It's quite surprising to, for
> example, install network-manager (which is an application that ca be used
> with non-GNOME window managers) and end up with a new init system.

I strongly disagree: if the maintainers of the various packages have
done their jobs well (which they have), upgrading should be entirely
transparent.  While the people in this discussion certainly hold strong
opinions about init systems, I don't think it's reasonable to inflict a
debconf prompt on every Debian user; we should not assume that because
*we* care, *they're* required to care.  In practice, people will test
the wheezy->jessie upgrade path quite extensively, report any bugs that
occur due to this or any other transition, and we'll hopefully make it
a seamless transition.

I do think it makes a lot of sense for sysvinit and other init systems
to do as systemd has done, and make themselves available as a binary
other than /sbin/init, with a single conflicting package for each init
system that installs an /sbin/init symlink.  That would make life
significantly easier for anyone who has to support more than one init
system, or who regularly experiments with init systems and wishes to
have a second system installed as a backup.

I'd suggest, instead, that this notice belongs in the release notes:
"The jessie release changes the default init system from sysvinit to
systemd.  Upgrading to jessie will switch from sysvinit to systemd on
many systems, to satisfy the dependencies of various packages such as
common desktop environments or infrastructure.  You can manually switch
your system from sysvinit to systemd by installing the systemd-sysv
package.  If you prefer another init system, you may wish to install the
systemd-shim package rather than systemd-sysv; systemd-shim provides a
minimal systemd compatibility layer to satisfy some packages depending
on systemd."

- 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/20140510033953.GA8410@thin

Re: systemd-fsck?

[Russ Allbery]

Josh Triplett  writes:
> Russ Allbery wrote:

>> I think we need some sort of critical debconf prompt here for the
>> jessie release, similar to how we handled the change of /bin/sh to dash
>> and how we handled the switch to startpar.  Probably in systemd-sysv,
>> which is the package that forces the conversion.  It's quite surprising
>> to, for example, install network-manager (which is an application that
>> ca be used with non-GNOME window managers) and end up with a new init
>> system.

> I strongly disagree: if the maintainers of the various packages have
> done their jobs well (which they have), upgrading should be entirely
> transparent.  While the people in this discussion certainly hold strong
> opinions about init systems, I don't think it's reasonable to inflict a
> debconf prompt on every Debian user; we should not assume that because
> *we* care, *they're* required to care.  In practice, people will test
> the wheezy->jessie upgrade path quite extensively, report any bugs that
> occur due to this or any other transition, and we'll hopefully make it a
> seamless transition.

I don't agree.

This is not consistent with how we've handled similar transitions in the
past.  Users also shouldn't have to care, and normally don't care, about
what shell they have as /bin/sh or about whether to use dependency-based
boot, but we still made sure they were alerted to those changes during
upgrades since they have a potential to break things or at least change
behavior noticably in some cases where it would otherwise be difficult to
understand what happened to cause the behavior change.  I think it's
important that we make sure this information gets in front of people.
It's at least as important (and probably more comprehensible for the
average user) as the change to using UUIDs for file system mounting, which
forced a similar debconf prompt.

We can, and should, put some effort into making that message accurate and
non-threatening and encourage people to take the default, which is what we
did for dependency-based boot.  But this is not the sort of change that
should happen without some notification, and all the similar sorts of
changes that Debian has done in the past that I can think of *always*
resulted in notification to the user on upgrades.

We should listen to the wisdom of our past decisions here.

> I'd suggest, instead, that this notice belongs in the release notes:
> "The jessie release changes the default init system from sysvinit to
> systemd.  Upgrading to jessie will switch from sysvinit to systemd on
> many systems, to satisfy the dependencies of various packages such as
> common desktop environments or infrastructure.  You can manually switch
> your system from sysvinit to systemd by installing the systemd-sysv
> package.  If you prefer another init system, you may wish to install the
> systemd-shim package rather than systemd-sysv; systemd-shim provides a
> minimal systemd compatibility layer to satisfy some packages depending
> on systemd."

Far fewer people read the release notes.  We should of course put
something there as well, but this is important enough that it needs
something more.

-- 
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/87ppjmqo0z@windlord.stanford.edu

Re: systemd-fsck?

[Norbert Preining]

Hi

On Fri, 09 May 2014, Josh Triplett wrote:
> debconf prompt on every Debian user; we should not assume that because
> *we* care, *they're* required to care.  In practice, people will test

I strongly disagree with this opinion. From personal experience
I know several people who are not developers of Debian, but are
technically interested, and they *do* care a lot.
And they are searching for alternative distributions without systemd.

One of the things that systemd breaks (not checked on Debian, but
on other systems), is that screen session are killed when logging out
of the ssh session.

This is a *fundamental* change in behaviour, and does break a lot
of setups and systems.

So I *strongly* advise to inform *and* ask the users!!

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
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/20140510060622.gj8...@auth.logic.tuwien.ac.at

Re: systemd-fsck?

[Sune Vuorela]

On 2014-05-09, Steve Langasek  wrote:
> I don't think systemd integration is in a state today that this is ready to
> become the default.

I don't think I have an opinion of the exact state today other than
'works for me in most cases', but I do think we are quite late in the
process for making it default. We only have half a year to iron out all
the quirks  -  including the quirks needed for a automatic upgrade from
sysvinit to systemd.

/Sune


-- 
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/lkkfp2$vc1$1...@ger.gmane.org

Re: systemd-fsck?

[Manoj Srivastava]

<#secure method=pgpmime mode=sign>
On Fri, May 09 2014, Russ Allbery wrote:

> Josh Triplett  writes:
>> Russ Allbery wrote:
>
>>> I think we need some sort of critical debconf prompt here for the
>>> jessie release, similar to how we handled the change of /bin/sh to dash
>>> and how we handled the switch to startpar.  Probably in systemd-sysv,
>>> which is the package that forces the conversion.  It's quite surprising
>>> to, for example, install network-manager (which is an application that
>>> ca be used with non-GNOME window managers) and end up with a new init
>>> system.
>
>> I strongly disagree: if the maintainers of the various packages have
>> done their jobs well (which they have), upgrading should be entirely
>> transparent.

When things are working well, of course there is little to worry
 about. I myself got converted and did not notice. But there is more to
 this than the happy lane: What happens  when the init system breaks? I
 am currently very familiar with sysvinit, and am comfortable debugging
 and hacking at shell scripts to get my system back in single user
 mode.

   Am I similarly knowledgeable about recovering a sick systemd
 environment? No, not yet, I am not. I do mean to learn about it at some
 point, perhaps soon. But  by pushing ahead the timetable, I have been
 left with a system I am not at all confident of being able to debug and
 fix. Not asking me has led to a gap in my disaster recovery
 preparedness :P

I do not think silently swapping out a critical piece of
 infrastructure, where the underlying technology is so different,
 without asking is serving our users well.

manoj
-- 
To be able to be caught up into the world of thought--that is being
educated. Edith Hamilton
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
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/87ppjmxib7@glaurung.internal.golden-gryphon.com