Bug#787731: adds google nameserver without being asked to

Am 09.06.2015 um 13:14 schrieb Marc Haber: > On Sat, Jun 06, 2015 at 09:42:37PM +0200, Michael Biebl wrote: >> This change is imho too invasive for being backported to the stable v215 >> in jessie. The first Debian version carrying that fix is 217-1, so I'm >> closing it for this version. > > How

Bug#783509: me too :)

Hello, just writing to add that I am having the same problem and /tmp silently became mounted on tmpfs with no warnings and no entries on changelogs. This caused a few hard resets, that I could not explain, because I normally download films into /tmp and then watch them. So I think that right

Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Hi, there seem to be a general issue with how .service files should be packaged (in /lib/systemd/system/ and not in /etc/systemd/system/): If a package is shipping a init script as well as a service file (as currently strongly recommend), it's usually the case that the init script is left on the

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Hey Axel, all, thanks for raising that on the list. Axel Beckert [2015-06-10 12:22 +0200]: > 1) Ship the .service file in /etc/systemd/system/ instead of >/lib/systemd/system/ so that it's removed at the same time as the >init script and override the according lintian warning. I don't be

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Am 10.06.2015 um 12:22 schrieb Axel Beckert: > Hi, > > there seem to be a general issue with how .service files should be > packaged (in /lib/systemd/system/ and not in /etc/systemd/system/): > > If a package is shipping a init script as well as a service file (as > currently strongly recommend),

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Michael Biebl [2015-06-10 12:50 +0200]: > To address this, we added code do dh_systemd, to mask the service on > remove. So even if the package is only removed, but not purged, be > remaining sysv init script will not be considered by systemd. > This mask is removed on purge. Oh, thanks for pointi

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Am 10.06.2015 um 12:54 schrieb Martin Pitt: > Michael Biebl [2015-06-10 12:50 +0200]: >> To address this, we added code do dh_systemd, to mask the service on >> remove. So even if the package is only removed, but not purged, be >> remaining sysv init script will not be considered by systemd. >> Thi

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Hi, Michael Biebl wrote: > To address this, we added code do dh_systemd, I assume you mean dh-systemd (the package) as there is no such command. > to mask the service on remove. So even if the package is only > removed, but not purged, be remaining sysv init script will not be > considered by sy

Re: ifup service delay (systemd 220)

Hello Alex, CC'ing the systemd packager list, if you don't mind. Keeping fullquote for that. Alex Mayer [2015-06-07 19:34 +]: > Hey Martin, > > i think two systemd 218-4 changes in /lib/systemd/system/ifup@.service are > the issue. > > > Type=oneshot > When no network available, it causes

cannot extend network-manager unit file by using network-manager.service.d

Hi! This is what I did on Debian jessie... > sudo mkdir /etc/systemd/system/network-manager.service.d > sudo touch /etc/systemd/system/network-manager.service.d/x.conf > sudo systemctl daemon-reload Now, when running... > sudo service network-manager status Systemd keeps saying... > "Warning:

Re: cannot extend network-manager unit file by using network-manager.service.d

Am 10.06.2015 um 15:50 schrieb Patrick Schleizer: > Hi! > > This is what I did on Debian jessie... > >> sudo mkdir /etc/systemd/system/network-manager.service.d >> sudo touch /etc/systemd/system/network-manager.service.d/x.conf >> sudo systemctl daemon-reload > > Now, when running... > >> sudo

Bug#783509: systemd: /tmp purged on every reboot

Hello all, Michael and I just discussed this. Our current patches are shaky at best, and e. g. in the current 220-5 tmp.mount came back by default. I committed another bandaid for that, but it's a disaster waiting to happen. So we agreed on the following: - Stop shipping /lib/systemd/system/tmp

Bug#788193: systemd: lost+found on /tmp-partition deleted during boot

Control: severity -1 important Am 09.06.2015 um 12:06 schrieb Ruediger Oberhage: >* What led up to the situation? > Booting Debian "Jessie". That dam*d "systemd" erases the "lost+found" > directory entry in "/tmp", which obviously is in its own partition. Looking at sysvinit's /lib/init/bootc

Processed: Re: Bug#788193: systemd: lost+found on /tmp-partition deleted during boot

Processing control commands: > severity -1 important Bug #788193 [systemd] systemd: lost+found on /tmp-partition deleted during boot Severity set to 'important' from 'normal' -- 788193: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788193 Debian Bug Tracking System Contact ow...@bugs.debian.o

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Am 10.06.2015 um 13:19 schrieb Axel Beckert: > Michael Biebl wrote: >> To address this, we added code do dh_systemd, .. > After reading the source of > /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm, I assume that > > dh $@ --with=systemd > > suffices. > > Will try that. I just notic

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Hi, Michael Biebl wrote: > Am 10.06.2015 um 13:19 schrieb Axel Beckert: > > Michael Biebl wrote: > >> To address this, we added code do dh_systemd, > > .. > > > After reading the source of > > /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm, I assume that > > > > dh $@ --with=systemd >

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Axel Beckert [2015-06-10 20:00 +0200]: > > So, option 2) might actually be the proper solution for your specific > > case after all. If you create that mask dynamically via postinst, this > > should be done in /etc though, I think. > > I would have expected /lib according to the argumentation in y

Processed: tagging 787542

Processing commands for cont...@bugs.debian.org: > tags 787542 + pending Bug #787542 [libudev1-udeb] libudev1-udeb depends on missing libcap2 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 787542: http://bugs.debian.org/cgi-bin/bugreport.cgi

Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging

Am 10.06.2015 um 20:00 schrieb Axel Beckert: > Michael Biebl wrote: > Ok. I'll revert the previously committed solution (1) and will likely > do the next upload without a fix for LP#1462692. I want to make an > upload of some packaging-only changes soon as there is a new upstream > imminent. The fi

/etc/tmpfiles.d in screen package (was: Re: Packaging issue: .service files are no conffiles ...)

Hi Michael, Michael Biebl wrote: > >> (*) you seem to ship an empty /etc/tmpfiles.d directory for no apparent > >> reason > > > > See https://sources.debian.net/src/screen/4.2.1-3/debian/README.Debian/#L104 > > and the following lines for the reason. Was suggested by Josh and added in > > https:/

Bug#788400: systemd-logind only fires suspend on lid close once even though it sees the event

Package: systemd Version: 220-5 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of t

Re: cannot extend network-manager unit file by using network-manager.service.d

Michael Biebl: > Am 10.06.2015 um 15:50 schrieb Patrick Schleizer: >> Hi! >> >> This is what I did on Debian jessie... >> >>> sudo mkdir /etc/systemd/system/network-manager.service.d >>> sudo touch /etc/systemd/system/network-manager.service.d/x.conf >>> sudo systemctl daemon-reload >> >> Now, when

could you look at http://bugs.debian.org/788380 part of it involves systemd-user

Hi Michael, Could you take a look at http://bugs.debian.org/788380 and see if it could be helped along ? -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.

Bug#788050: systemd-fsck : Check disks at each reboot

Hi A workaround is to boot in maintenance mode. The disks are then correctly checked and next normal boot is ok Regards Ludovic On Mon, 2015-06-08 at 10:26 +0200, Michael Biebl wrote: > Am 08.06.2015 um 08:01 schrieb Ludovic Lebègue: > > > For a few days now each time the computer boots it f