Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR
On Mon, 11 Mar 2019 20:51:29 +0100 Andras Korn
wrote:
> On Mon, Mar 11, 2019 at 06:12:06PM +, Dmitry Bogatov wrote:
>
> > > On Fri, Mar 08, 2019 at 02:39:47PM +, Dmitry Bogatov wrote:
> > > > [2019-03-07 12:57] Andras Korn
> > > > > part 1 text/plain 218
> > > > > Sorry, I sent an earlier version of the patch by mistake.
> > > > >
> > > > > I'm attaching the correct one, which I tested and which works for
me.
> > > > > [...]
> > > > > - if (sigc && (stat(STOPIT, ) != -1) && (s.st_mode &
S_IXUSR)) {
> > > > > + if ((sigp) || (sigc && (stat(STOPIT, ) != -1) &&
(s.st_mode & S_IXUSR))) {
> > > >
> > > > As far as I can tell by glance on patch, you want SIGPWR trigger
reboot.
> > > > If so, why don't you create REBOOT file in, say, /etc/rc.local and
make
> > > > lxc controller to send SIGCONT?
> > >
> > > No -- I want SIGPWR to trigger a halt.
> > >
> > > For the purposes of LXC, any signal will do; I just need for a signal
to
> > > trigger a shutdown regardless of the permissions on runit.stopit and
> > > runit.reboot.
> >
> > Halt. Fine. But why can't you pre-provision you container with apporiate
> > `stop.*' file with apporiate permissions?
>
> Because that adds complexity elsewhere -- /etc/runit/1 as shipped creates
> /run/runit.stopit with mode 0, so either all containers would need ot
have a
> custom /etc/runit/1, or run a custom script to chmod 100 /run/runit.stopit
> on every boot, or have an immutable /run/runit.stopit.
>
> It's not just about me; this affects everyone who wants to use runit
inside
> an lxc container.
>
> My goal is to make using runit as hassle-free as possible, without
> sacrificing any of its core values.
>
> > > > By the way, SIGPWR is not in POSIX, according to signal(7).
> > >
> > > You're right; in that case, maybe we can use SIGQUIT?
> >
> > SIGTERM feels better, imho. TERM is graceful termination, while SIGQUIT
> > creates coredump. By default.
>
> SIGPWR would be nice to use as the halt signal because it's the lxc
default,
> so that runit could be a drop-in replacement for sysvinit in LXC
containers.
We should recognize that SIGPWR was chosen in a fairly arbitrary way.
Of course, SIGPWR is in use today by LXC and powerstatd so it is useful to
support.
>
> If we're not going to use SIGPWR it's pretty much all the same which
signal
> we use, because it will need to be configured explicitly in LXC (but
that's
> acceptable -- POSIX is important enough).
>
> > But this naming only matters if you explain to me, how solution not
> > involving changing C code does not suffice. Two lines for convenience in
> > this case, three there -- and we all know where it ends.
>
> I'm sorry, I don't buy the slippery slope argument. I'm not adding a DNS
> resolver, a DHCP client or a QR encoder, merely making the user interface
a
> tiny bit more similar to sysvinit's, to make integration easier. This is
> entirely in line with The Unix Way: making one program a drop-in
replacement
> for another such that other programs interfacing with them don't see a
> difference unless they need to. It's why bzip2 and gzip take most of the
You are taking a previously portable codebase and making it not portable.
As a distribution patch, this might be acceptable. However it is an
unfortunate compromise.
Personally, I elect to replace the runit-init program entirely and only use
the supervision suite.
There is absolutely zero reason for an init system to call reboot(2). It is
simply unnecessary.
I have written a guide to do exactly this. It leverages two small C
programs:
* linit:
* Reaps zombies
* Ignores SIGCHLD, preventing new zombies
* Sets up signal handlers for SIGINT and SIGPWR that spawn hooks
* Spawns a boot hook
* Calls pause()
* lreboot: calls reboot(2)
The rest is simply some scripting to emulate what runit-init does.
Please review the guide and source code for the above C programs:
https://gitlab.com/chinstrap/linit/blob/master/README.runit.md
Regards,
--
Cameron Nemo
Bug#844452: ITA: json-c -- JSON manipulation library
Control: retitle -1 ITA: json-c -- JSON manipulation library I intend to adopt this package. -- Cameron Nemo On Wed, 25 Jul 2018 14:47:50 +0800 Nicolas Braud-Santoni < nico...@braud-santoni.eu> wrote: > Control: reopen -1 > Control: reassign -1 wnpp > Control: retitle -1 O: json-c -- JSON manipulation library > Control: severity -1 normal > > Hi, > > Tobias pointed out that the package now needs a WNPP bug. > I am transmuting the old bug so as to preserve the context. > > Best, > > nicoo > > On Tue, Jul 24, 2018 at 12:00:10AM +, Nicolas Braud-Santoni wrote: > > Source: json-c > > Source-Version: 0.13.1+dfsg-1 > > > > We believe that the bug you reported is fixed in the latest version of > > json-c, which is due to be installed in the Debian FTP archive. > > [...] > >* QA upload. > >* Orphan the package (Closes: 844452) > >* New upstream version (2018-03-05) > > - Remove obsolete patches > > - Bump library SONAME & update symbols file
Bug#826286: ITA: libnih -- NIH Utility Library
Control: retitle -1 ITA: libnih -- NIH Utility Library I intend to adopt this package. -- Cameron Nemo
Bug#872039: why the severity?
On Fri, 12 Jan 2018 03:56:42 +0100 Adam Borowski wrote: > On Wed, Jan 10, 2018 at 08:38:39PM +0100, John Paul Adrian Glaubitz wrote: > > > Please tell me why this would be serious: any filesystem from this millenium > > > can handle unclean shutdown fine -- especially if there's a sync before > > > reboot/poweroff. > > > > That's hardly an argument. There is still very much the possibility that > > this bug causes data-loss, so the severity is definitely justified. > > Technically, yes. If your filesystem is ext2, and there's a process that > hasn't been killed, and continues to write after the final sync. > > But if you use ext2 for anything, you made the decision yourself. > Not necessarily, an admin could just have to use ext2 for internal company policy reasons. Let's not punish people for being stuck in a bad situation. /usr is already mounted ro. Can we not remount other filesystems ro like /var at the same time? > > On the other hand, only a very small minority are still using sysvinit on > > Debian, so this I think it's ok to have the severity set to serious. > > According to my last data, 14% of unstable users; less on stable as those > tend to be non-technical users. Not a "very small minority". Ignore him. He trolls non-systemd inits and actively roots for their exit from Debian. Regards, -- Cameron nemo
Bug#878611: New upstream version available
Package: libnginx-mod-http-dav-ext Vesion: 1.13.1-2 A new version of this module was released recently. https://github.com/arut/nginx-dav-ext-module/releases This version has support for building as a dynamic module, which is currently patched in on Debian. Thanks -- Cameron Norman
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On Wed, Jul 22, 2015 at 2:27 PM, Oxan van Leeuwen o...@oxanvanleeuwen.nl wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package postsrsd * Package name: postsrsd Version : 1.2-1 Upstream Author : Timo Röhling timo.roehl...@gmx.de * URL : https://github.com/roehling/postsrsd * License : GPL-2+ Section : mail It builds those binary packages: postsrsd - Sender Rewriting Scheme (SRS) lookup table for Postfix To access further information about this package, please visit the following URL: http://mentors.debian.net/package/postsrsd Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/postsrsd/postsrsd_1.2-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: postsrsd (1.2-1) unstable; urgency=medium * Initial release (Closes: #757720) -- Oxan van Leeuwen o...@oxanvanleeuwen.nl Fri, 26 Dec 2014 17:35:3 I see the prerm file is empty -- why not just delete it? Also, why do you patch the sysv-redhat init script if you end up using the sysv-lsb one? I think you can drop that part of the patch. Finally, have you actually tested the AppArmor profile works on Debian? Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790700: knot: Do not recommend systemd
Source: knot Severity: normal Please do not recommend any init system in the hopes of changing it. This is massively undesirable. The reason you chose to recommend systemd is addressed by a patch on upstream's bug tracker [1]. Furthermore, the systemd package does not end up installing systemd-sysv, so the dependency is near useless unless changed to systemd-sysv (again please do not do this). [1] https://gitlab.labs.nic.cz/labs/knot/issues/391 Note: the patch at the link above also fixes debbugs #779759 Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789524: upstart: Switching between init systems
On Sun, 21 Jun 2015 13:12:11 -0600 Kyle Amon flesheno...@gmail.com wrote: Package: upstart Version: 1.11-5 Severity: critical Justification: breaks unrelated software Dear Maintainer, Switching between sysvinit and systemd works. Switching from either of them to upstart works. Switching from upstart to either of them fails. This bug was well documented to the debian-users mailing list by Thorsten Holzman thorsten.holz...@gmx.de on 11-21-14. There was one reply saying to file a bug report, but he evidently did not. Please refer to his description at the following URL... https://lists.debian.org/debian-user/2014/11/msg01452.html. I fail to see how Upstart can do much to change this since Upstart's reboot/telinit/shutdown/etc commands are not installed at the point where you invoke reboot. The only way to do it from Upstart's side is to proxy requests from external tools like systemctl or sysvinit's shutdown/telinit commands by: * listening to /dev/initctl like systemd has a special daemon for * taking systemd's name on the system bus so it can accept shutdown/reboot/etc requests The latter conflicts with systemd-shim's operation. It would be nigh impossible to do without doing it in the shim itself... grr. -- Cameron Norman
Bug#788056: fish: add apparmor profile for fishd
On Sun, Jun 28, 2015 at 10:15 PM, David Adam zanc...@ucc.gu.uwa.edu.au wrote: On Sun, 28 Jun 2015, intrigeri wrote: this looks good at first glance, but as usual: asking for a review on the upstream AppArmor mailing-list would possibly highlight issues that I've missed, and in any case it would help sharing this work as a cross-distro effort. May you please do this? Thanks in advance! At the risk of providing too much stop energy, we are about to release a new upstream version (hopefully in the next few days). The new version of fish no longer depends on a fishd component. Assuming this release will be a part of Stretch (which it probably should be..) I would agree there is not much use. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788056: fish: add apparmor profile for fishd
Package: fish
Severity: wishlist
Tags: patch
Hello,
I have attached a patch that will ship an apparmor profile to confine
fishd (but not fish).
I would be very appreciative if you tested and included it.
See the following links for more information:
https://wiki.debian.org/AppArmor
https://wiki.debian.org/AppArmor/Contribute/FirstTimeProfileImport
https://wiki.debian.org/AppArmor/Debug#Testing
Thank you,
--
Cameron Norman
diff --git a/debian/control b/debian/control
index c1f9134..15b1679 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,7 @@ Build-Depends: autoconf,
doxygen,
quilt,
dh-autoreconf,
+ dh-apparmor,
Standards-Version: 3.9.6
Homepage: http://fishshell.com/
Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/fish.git
diff --git a/debian/copyright b/debian/copyright
index 257b54b..fc5864b 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -22,6 +22,10 @@ Copyright: 2005-2009 James Vega james...@jamessan.com
2015 Tristan Seligmann mithra...@debian.org
License: GPL-2
+Files: debian/usr.bin.fishd
+Copyright: 2015 Cameron Norman camerontnor...@gmail.com
+License: GPL-2
+
Files: xdgmime.cpp xdgmime.h xdgmimealias.cpp xdgmimealias.h xdgmimeint.cpp
xdgmimeint.h xdgmimemagic.cpp xdgmimemagic.h xdgmimeparent.cpp
xdgmimeparent.h
diff --git a/debian/fish-common.install b/debian/fish-common.install
index 4ebd1b3..6852ccd 100644
--- a/debian/fish-common.install
+++ b/debian/fish-common.install
@@ -1,3 +1,4 @@
debian/tmp/etc
debian/tmp/usr/share
debian/completions/dupload.fish usr/share/fish/completions
+debian/usr.bin.fishd etc/apparmor.d/
diff --git a/debian/rules b/debian/rules
index 28c6cea..e863831 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,10 @@
%:
dh $@ --with autotools-dev,autoreconf --parallel
+override_dh_install:
+ dh_apparmor --profile-name=usr.bin.fishd -pfish-common
+ dh_install
+
override_dh_strip:
dh_strip --dbg-package=fish-dbg
diff --git a/debian/usr.bin.fishd b/debian/usr.bin.fishd
new file mode 100644
index 000..ca3c0ee
--- /dev/null
+++ b/debian/usr.bin.fishd
@@ -0,0 +1,24 @@
+# --
+#
+#Copyright (C) 2015 Cameron Norman camerontnor...@gmail.com
+#
+#This program is free software; you can redistribute it and/or
+#modify it under the terms of version 2 of the GNU General Public
+#License published by the Free Software Foundation.
+#
+# --
+
+#include tunables/global
+/usr/bin/fishd {
+ #include abstractions/base
+
+ owner @{HOME}/.config/fish/fishd.*rw,
+ owner /{,var/}run/user/*/fishd.{socket,log.*} rw,
+ owner /{,var/}run/user/*/fishd.socket.lock* rwl,
+ owner /tmp/fishd.socket.* rwl,
+ owner /tmp/fish.*/rw,
+ owner /tmp/fish.*/** rwl,
+
+ # Site-specific additions and overrides. See local/README for details.
+ #include local/usr.bin.fishd
+}
Bug#788009: xserver-xorg-input-synaptics: Please add apparmor profile for syndaemon
On Mon, Jun 8, 2015 at 9:28 AM, intrigeri intrig...@debian.org wrote: Control: tag -1 + moreinfo Hi, pkg-apparmor team member hat on the proposed confinement profile looks OK to me at first glance. It's very simple so exceptionally I won't be requesting a review pass on the AppArmor mailing-list :) And, given the profile is brand new, flags=(complain) sounds reasonable as a first step. Was this profile tested with syndaemon run by GNOME and/or by other desktop environments? It was tested both running manually and with gnome-settings-daemon. I looked at debian codesearch for packages that run syndaemon and it yielded (in addition to g-s-d) mate-s-d, cinnamon-s-d, and xfce4-s-d. The former two have the exact same code as g-s-d (they are g-s-d forks) and the xfce4 code has similar options. The main reason I included the flags=(complain) was because syndaemon supports pidfiles in variable locations that I could not possibly guess. No package in Debian makes use of the pidfile option, but users may have custom xinitrc's and whatnot that do use it. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788009: xserver-xorg-input-synaptics: Please add apparmor profile for syndaemon
On Sun, 7 Jun 2015 12:21:31 -0700 Cameron Norman
camerontnor...@gmail.com wrote:
Package: xserver-xorg-input-synaptics
Version: 1.8.2-1
Severity: wishlist
Tags: patch
Dear Maintainer,
Please use the patch attached to add an apparmor profile for
syndaemon
to your package.
I apologize -- I forgot to include the necessary Build-Depends on
dh-apparmor in that patch.
This new one should work correctly.
Cheers,
--
Cameron Norman
diff --git a/debian/control b/debian/control
index 9a4f8b9..0448b7c 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Uploaders: Mattia Dongili malat...@debian.org, maximilian attems maks@debian.
Build-Depends:
debhelper (= 9),
dh-autoreconf,
+ dh-apparmor,
libx11-dev,
libxext-dev,
libxi-dev (= 2:1.2.0),
diff --git a/debian/rules b/debian/rules
index 29f61aa..f759022 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,7 @@ override_dh_auto_install:
# Kill *.la files, and forget no-one:
override_dh_install:
+ dh_apparmor --profile-name=usr.bin.syndaemon -pxserver-xorg-input-synaptics
find debian/tmp -name '*.la' -delete
dh_install --fail-missing
diff --git a/debian/usr.bin.syndaemon b/debian/usr.bin.syndaemon
new file mode 100644
index 000..6e502b8
--- /dev/null
+++ b/debian/usr.bin.syndaemon
@@ -0,0 +1,23 @@
+# vim:syntax=apparmor
+
+# --
+#
+#Copyright (C) 2015 Cameron Norman camerontnor...@gmail.com
+#
+#This program is free software; you can redistribute it and/or
+#modify it under the terms of version 2 of the GNU General Public
+#License published by the Free Software Foundation.
+#
+# --
+
+#include tunables/global
+
+/usr/bin/syndaemon flags=(complain) {
+ #include abstractions/base
+ #include abstractions/X
+
+ owner /{,var/}run/user/*/syndaemon.pid rw,
+
+ # Site-specific additions and overrides. See local/README for details.
+ #include local/usr.bin.syndaemon
+}
diff --git a/debian/xserver-xorg-input-synaptics.install b/debian/xserver-xorg-input-synaptics.install
index 0835787..d5bef51 100644
--- a/debian/xserver-xorg-input-synaptics.install
+++ b/debian/xserver-xorg-input-synaptics.install
@@ -2,3 +2,4 @@ usr/lib/xorg/modules/input/*.so
usr/bin/*
usr/share/man
usr/share/X11
+debian/usr.bin.syndaemon /etc/apparmor.d/
Bug#788009: xserver-xorg-input-synaptics: Please add apparmor profile for syndaemon
Package: xserver-xorg-input-synaptics
Version: 1.8.2-1
Severity: wishlist
Tags: patch
Dear Maintainer,
Please use the patch attached to add an apparmor profile for syndaemon
to your package.
At least for now, the profile is in complain mode, which means that
if syndaemon does something not defined in the profile, it will not be
impeded by apparmor -- only a message in the logs will appear. This
ensures that no permission issues will appear with the addition of
this profile.
Cheers,
--
Cameron Norman
commit 7b4b7db32648c26d7eca22b05285c0d663bdf0d1
Author: Cameron Norman camerontnor...@gmail.com
Date: Sun Jun 7 12:06:40 2015 -0700
Added apparmor profile for syndaemon (in complain mode)
diff --git a/debian/rules b/debian/rules
index 29f61aa..f759022 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,7 @@ override_dh_auto_install:
# Kill *.la files, and forget no-one:
override_dh_install:
+ dh_apparmor --profile-name=usr.bin.syndaemon
-pxserver-xorg-input-synaptics
find debian/tmp -name '*.la' -delete
dh_install --fail-missing
diff --git a/debian/usr.bin.syndaemon b/debian/usr.bin.syndaemon
new file mode 100644
index 000..6e502b8
--- /dev/null
+++ b/debian/usr.bin.syndaemon
@@ -0,0 +1,23 @@
+# vim:syntax=apparmor
+
+# --
+#
+#Copyright (C) 2015 Cameron Norman camerontnor...@gmail.com
+#
+#This program is free software; you can redistribute it and/or
+#modify it under the terms of version 2 of the GNU General Public
+#License published by the Free Software Foundation.
+#
+# --
+
+#include tunables/global
+
+/usr/bin/syndaemon flags=(complain) {
+ #include abstractions/base
+ #include abstractions/X
+
+ owner /{,var/}run/user/*/syndaemon.pid rw,
+
+ # Site-specific additions and overrides. See local/README for details.
+ #include local/usr.bin.syndaemon
+}
diff --git a/debian/xserver-xorg-input-synaptics.install
b/debian/xserver-xorg-input-synaptics.install
index 0835787..d5bef51 100644
--- a/debian/xserver-xorg-input-synaptics.install
+++ b/debian/xserver-xorg-input-synaptics.install
@@ -2,3 +2,4 @@ usr/lib/xorg/modules/input/*.so
usr/bin/*
usr/share/man
usr/share/X11
+debian/usr.bin.syndaemon /etc/apparmor.d/
Bug#784587: network-manager: does not set up resolv.conf
On Thu, 07 May 2015 02:30:16 +0200 Michael Biebl bi...@debian.org wrote: Am 07.05.2015 um 01:55 schrieb Michael Biebl: Am 07.05.2015 um 01:32 schrieb Andrea Capriotti: On Thu, 07 May 2015 01:09:53 +0200 Michael Biebl bi...@debian.org wrote: Control: tags -1 moreinfo Please provide more informatin about your network setup: a/ which interfaces are managed by NM, which are managed elsewhere (ifupdown) b/ please provide a verbose debug log of NetworkManager Same problem here. # grep resolvconf /var/log/syslog May 7 01:16:15 nb-capriotti NetworkManager[13437]: warn could not commit DNS changes: /sbin/resolvconf is not executable I fixed it installing resolvconf. That's not a fix. Please provide the information I requested. Maybe that provides some hint's what's going wrong. Do you have any custom configuration in /etc/NetworManager/NetworkManager.conf? I think I tracked this down. The Debian package builds with resolvconf support, in case users decide to install resolvconf. Due to this commit [1], this makes NM now assume that resolvconf is also available during runtime, which is not the case by default on Debian. That's obviously wrong. NM should fallback to non-resolvconf mode, if the resolvconf binary was not found during runtime. This is consistent with what I am seeing. Also, this may be of interest to you, there is a file /etc/resolv.conf.tmp on my system when resolvconf is not installed: # Generated by NetworkManager nameserver 192.168.1.1 Yet another workaround seems to be to copy this file over to /etc/resolv.conf to get temporary internet access to install resolvconf (if it is not in your apt cache). Best regards, -- Cameron Norman
Bug#784177: ITP: capnet-assist -- captive login detector
Package: wnpp Severity: wishlist Owner: Cameron Norman camerontnor...@gmail.com * Package name: capnet-assist Version : 0.1 Upstream Author : Daniel Fore dan...@elementaryos.org * URL : https://launchpad.net/capnet-assist * License : GPL-2+ Description : captive login detector A small WebKit app that allows a user to log in when a captive portal is detected. . Uses a NetworkManager dispatcher script to detect when the connection is inside a captive portal, and launches a small GTK window to trigger the login page for the captive portal. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782700: [pkg-apparmor] Bug#782700: Please drop $remote_fs init.d dependency to allow running early
On Thu, Apr 16, 2015 at 6:22 AM, Michael Biebl bi...@debian.org wrote: Hi! While we are that topic, I think it would be better to not pull apparmor specifics into ifup@.service and networking.service, but rather have apparmor ship a native .service file and specify the correct orderings, maybe by hooking up in network-pre.target. Then again, I'm not too familiar with AppArmor: Is every service, which wants to be confined by apparmor supposed to declare a After=apparmor.service in its service file? Well what I have seen in Upstart confs is that all profiles that the job uses are loaded before the job is started with the `apparmor load` directive. This prevents any possible race conditions because, for example, cups would load its profile before its start regardless of whether the apparmor job has started. systemd only has an AppArmorProfile= directive, which is equivalent to Upstart's `apparmor switch`. Either systemd should gain a AppArmorLoad= directive or it should load all profiles itself before starting any services (like it does with SELinux policy). The workaround you describe seems to be a good choice ATM, and is similar to how it is done on Upstart with the network-interface-security job: # Since we need these profiles to be loaded before any of the above services # begin running, this service must be a pre-start so that its pre-start # script finishes before the above services' start scripts begin. pre-start script [ -f /run/network-interface-security ] exit 0 # already ran [ -d /rofs/etc/apparmor.d ] exit 0 # do not load on liveCD [ -d /sys/module/apparmor ] || exit 0 # do not load without AppArmor [ -x /sbin/apparmor_parser ] || exit 0 # do not load without parser for link in /etc/apparmor/init/network-interface-security/* ; do [ -L $link ] /sbin/apparmor_parser -r -W $link || true done /run/network-interface-security end script -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782700: [pkg-apparmor] Bug#782700: Please drop $remote_fs init.d dependency to allow running early
On Thu, Apr 16, 2015 at 5:56 AM, Martin Pitt mp...@debian.org wrote: Package: apparmor Version: 2.9.0-3 Hello, apparmor's init.d script currently depends on $remote_fs. This is a rather heavy dependency and means that important processes like dhclient or NFS cannot be covered by apparmor as they need to start before. In the extreme case this also means that network-online.target, NetworkManager.service, dbus.service etc. all need to run during early boot (rcS in the old sysvinit world), which likely leads to dependency cycles. IMHO $local_fs should suffice as during booting the init.d script does not need much from /usr or /var. The exception is the click package hook processing, but this is only really significant for Ubuntu Touch images (which don't use /usr on NFS). The profile cache has been split into /etc/ and /var for this reason, so that on boot you only need the cache in /etc. The one in /var is only being used for click packages as far as I know. I feel like it would be better to split out the click stuff. While it may be ok to ignore the click bits needing the full fs to be mounted in most cases, it would ensure that any future issues are properly avoided. Any objection to it from you? Would I change this in the Ubuntu source package then? Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769076: RFS: bitz-server/0.1.6-1 [ITP]
On Mon, Apr 6, 2015 at 10:24 PM, Jörg Frings-Fürst deb...@jff-webhosting.net wrote: Hello, I have refresh the package bitz-server[1]. Please can someone review it? I am not a DD, but I will try to do my best to review this. It includes a library in its sources, https://github.com/uditha-atukorala/socket-library This library also creates a strange unknown author in the debian/copyright file. I am not sure if either of those are acceptable, however I am sure the first one is at least discouraged (in favor of packaging the library separately and listing it in the build depends). Also, I have attached an Upstart job for you to include if you would like. Just place it at the path debian/bitz-server.upstart and it will be automatically shipped with the package. It is not necessary to include this to get bitz-server packaged, it is just something extra. Good luck, -- Cameron Norman bitz-server.conf Description: Binary data
Bug#769076: RFS: bitz-server/0.1.6-1 [ITP]
On Tue, Apr 7, 2015 at 1:23 PM, Jörg Frings-Fürst deb...@jff-webhosting.net wrote: It includes a library in its sources, https://github.com/uditha-atukorala/socket-library This library also creates a strange unknown author in the debian/copyright file. I am not sure if either of those are acceptable, however I am sure the first one is at least discouraged (in favor of packaging the library separately and listing it in the build depends). The unknown author is the first one from the source files. And I think that the this line must include into d/copyright. Oh yes the line is better there than not, however I was trying to say that you may want to look at who that is, and provide any info if possible (I would ask the upstream author of bitz-server if he has any info). Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780155: ITP: baculum -- Baculum WebGUI tool for Bacula Community program
On Mon, Mar 9, 2015 at 2:13 PM, gani marcin.h...@bacula.pl wrote: Package: wnpp Severity: wishlist Owner: Marcin Haba marcin.h...@bacula.pl * Package name: baculum Version : 7.0+git20150208 Upstream Author : Marcin Haba marcin.h...@bacula.pl * URL : http://www.bacula.org/ * License : AGPLv3 Programming Lang: PHP Description : Baculum WebGUI tool for Bacula Community program I see you linked to the bacula.org homepage for this package. Am I correct in saying that what you are packaging can be found here: http://www.bacula.org/git/cgit.cgi/bacula/tree/gui if so there seems to already be packaging (outside of Debian) that uses the bweb name for the package. If not, would you mind clarifying which GUI tool for Bacula this is with a link to a homepage and / or git repo? - is it a dependency for another package? Yes, it is. Baculum uses external toolset - PRADO Framework. Additionally Baculum uses external JavaScript libraries. Actually those are the dependencies of this project. The question is if this package is a dependency of another package (in the same way PRADO is a dependency of this package). - how do you plan to maintain it? After each Bacula and Baculum release I plan to build Baculum deb and rpm packages for community. From deb packages I am going to build also for Debian. - inside a packaging team? I am not sure about packaging team. I have never been packages maintainer. You should probably maintain it inside the Debian Bacula Team. This will make it easier to find a sponsor (which I will get to) and help if need be. - do you need a sponsor? No. I do not. You mentioned that you have never made Debian packages before. Thus, you are not a Debian developer and need a debian developer to review and then upload the packages for you. This is what a sponsor is. You need a sponsor. -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776483: python-imaging: no smooth upgrade path from wheezy due to python-imaging-tk becoming a virtual package
I have prepared an NMU with the transitional package that Andreas recommended. diff -Nru pillow-2.6.1/debian/changelog pillow-2.6.1/debian/changelog --- pillow-2.6.1/debian/changelog 2014-10-13 11:31:22.0 -0700 +++ pillow-2.6.1/debian/changelog 2015-03-06 18:39:18.0 -0800 @@ -1,3 +1,10 @@ +pillow (2.6.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add python-imaging-tk transitional package. Closes: #776483. + + -- Cameron Norman camerontnor...@gmail.com Fri, 06 Mar 2015 18:37:54 -0800 + pillow (2.6.1-1) unstable; urgency=medium * Pillow 2.6.1 release. diff -Nru pillow-2.6.1/debian/control pillow-2.6.1/debian/control --- pillow-2.6.1/debian/control 2014-10-13 11:31:43.0 -0700 +++ pillow-2.6.1/debian/control 2015-03-06 18:49:47.0 -0800 @@ -94,6 +94,12 @@ . This package contains the extension built for the Python debug interpreter. +Package: python-imaging-tk +Architecture: all +Depends: python-pil.imagetk +Description: transitional dummy package for smooth upgrades to python-pil.imagetk + This package can be safely removed. + Package: python-sane Architecture: any Multi-Arch: same
Bug#777583: Incorrect debian/copyright for smartmontools
On Sat, 14 Feb 2015 20:21:32 -0500 Mark H Weaver m...@netris.org wrote: retitle 777583 incorrect debian/copyright for smartmontools violates Debian policy severity 777583 serious thanks Giuseppe Iuculano iucul...@debian.org writes: The README file says: == COPYING == Copyright (C) 2002-9 Bruce Allen smartmontools-supp...@lists.sourceforge.net Copyright (C) 2004-14 Christian Franke smartmontools-supp...@lists.sourceforge.net This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. And in contrast, debian/copyright has this: License: You are free to distribute this software under the terms of the GNU General Public License Version 2. The full text of this license can be found in the file /usr/share/common-licenses/GPL-2 Section 12.5 of Debian policy states: Every package must be accompanied by a verbatim copy of its copyright information and distribution license in the file /usr/share/doc/package/copyright. Now, compare the README to debian/copyright. Does that look like a verbatim copy to you? If so, perhaps you should look up verbatim in a dictionary, e.g. https://en.wiktionary.org/wiki/verbatim There seems to be no problem: # apt-get source smartmontools # diff smartmontools-6.3+svn4002/COPYING /usr/share/common-licenses/GPL-2 outputs no difference. The upstream copyright and the full license referenced are **exactly the same**. Verbatim. Word for word. -- Cameron Norman
Bug#767028: ovirt-guest-agent: fails to install
Hello, I have attached a debdiff that should fix #767028 and #774437. It does so by using invoke-rc.d to reload the udev rules, and checking that the necessary filesystems are mounted before using the trigger and settle. It also eliminates the hard coded uid/gid values. Please take a look, László. Thank you, -- Cameron Norman diff -Nru ovirt-guest-agent-1.0.10.2.dfsg/debian/changelog ovirt-guest-agent-1.0.10.2.dfsg/debian/changelog --- ovirt-guest-agent-1.0.10.2.dfsg/debian/changelog 2014-10-20 12:00:09.0 -0700 +++ ovirt-guest-agent-1.0.10.2.dfsg/debian/changelog 2015-02-13 17:43:40.0 -0800 @@ -1,3 +1,11 @@ +ovirt-guest-agent (1.0.10.2.dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Do not hardcode UID/GID values (closes: #774437). + * Do not use udevadm in chroot (closes: #767028). + + -- Cameron Norman camerontnor...@gmail.com Fri, 13 Feb 2015 17:39:51 -0800 + ovirt-guest-agent (1.0.10.2.dfsg-1) unstable; urgency=low * New upstream release. diff -Nru ovirt-guest-agent-1.0.10.2.dfsg/debian/postinst ovirt-guest-agent-1.0.10.2.dfsg/debian/postinst --- ovirt-guest-agent-1.0.10.2.dfsg/debian/postinst 2014-08-10 09:49:46.0 -0700 +++ ovirt-guest-agent-1.0.10.2.dfsg/debian/postinst 2015-02-13 18:44:39.0 -0800 @@ -1,8 +1,15 @@ #!/bin/sh set -e -udevadm control --reload-rules -udevadm trigger --subsystem-match=virtio-ports --attr-match=name=com.redhat.rhevm.vdsm -udevadm settle +if test -x /usr/sbin/invoke-rc.d ; then + invoke-rc.d udev reload /dev/null 21 || true +fi + +if test -d /sys/class \ + test -e /proc/filesystems \ + ! ischroot; then + udevadm trigger --subsystem-match=virtio-ports --attr-match=name=com.redhat.rhevm.vdsm + udevadm settle +fi #DEBHELPER# diff -Nru ovirt-guest-agent-1.0.10.2.dfsg/debian/preinst ovirt-guest-agent-1.0.10.2.dfsg/debian/preinst --- ovirt-guest-agent-1.0.10.2.dfsg/debian/preinst 2014-08-10 09:50:12.0 -0700 +++ ovirt-guest-agent-1.0.10.2.dfsg/debian/preinst 2015-02-13 17:55:45.0 -0800 @@ -2,7 +2,7 @@ set -e -getent group ovirtagent /dev/null || groupadd -r -g 175 ovirtagent -getent passwd ovirtagent /dev/null || useradd -u 175 -g 175 -o -r ovirtagent -c oVirt Guest Agent -d /usr/share/ovirt-guest-agent -s /sbin/nologin +getent group ovirtagent /dev/null || groupadd -r ovirtagent +getent passwd ovirtagent /dev/null || useradd -r ovirtagent -g ovirtagent -c oVirt Guest Agent -d /usr/share/ovirt-guest-agent -s /sbin/nologin #DEBHELPER#
Bug#775795: Patch to use /usr/sbin/service in Debian service provider
On Fri, 06 Feb 2015 15:49:17 +0200 Faidon Liambotis parav...@debian.org wrote: reopen 775795 thanks On 02/01/15 01:03, Gaudenz Steinlin wrote: I created a patch to use /usr/sbin/service as suggested earlier in this report to start/stop/status/restart services on Debian. I'm a bit reluctant to just NMU puppet and would prefer if one of the maintainers and/or Faidon could have a look at my patch first. If you approve I can then do the NMU if you are short on time. I tested the patch locally and as far as I can see it works fine with systemd and does call the right command. I don't have a system with system V handy to test on. Apologies, it seems like I didn't review this on time... This seems like a nice approach for status/start/stop/restart but unfortunately doesn't address enabled?/enable/disable at all. For starters, puppet seems to call update-rc.d with defaults, not enable. Even enable, though, does not seem to be sufficient for systemd-only service files :( Try this: # cp /etc/systemd/system/ssh.service /etc/systemd/system/test.service # systemctl daemon-reload # update-rc.d -f test defaults update-rc.d: error: initscript does not exist: /etc/init.d/test # update-rc.d -f test enable update-rc.d: error: cannot find a LSB script for test While an error is shown, is enable actually enabling the systemd service or no? enabled? is similarly broken: it calls invoke-rc.d --query, which returns 105 for test.service and puppet handles 105 by proceeding to check for symlinks under /etc/rc*.d/... Finally, self.instances is also broken, as it just lists /etc/init.d init files. The systemd provider calls systemctl list-unit-files --type service --full --all instead. Are there any packages that only have systemd services? Cheers, -- Cameron Norman
Bug#777064: ITA: surf -- Simple web browser by suckless community
Hello, On Wed, 4 Feb 2015 21:43:20 +0530 Vasudev Kamath kamathvasu...@gmail.com wrote: Package: wnpp Severity: normal As I don't have enough time to take care of this package, I request an adopter for the surf package. The package description is: surf is a simple web browser based on WebKit/GTK+. It is able to display websites and follow links. It supports the XEmbed protocol which makes it possible to embed it in another application. Furthermore, one can point surf to another URI by setting its XProperties. I would be happy to adopt the surf package. It seems to be a fairly simple little C program. Best regards, -- Cameron Norman
Bug#774437: ovirt-guest-agent: fails in preinst due to hardcoded uid and gid values
On Sat, Jan 31, 2015 at 5:08 AM, László Böszörményi (GCS) g...@debian.org wrote: On Fri, Jan 16, 2015 at 11:18 PM, Cameron Norman camerontnor...@gmail.com wrote: On Fri, 9 Jan 2015 12:47:28 -0800 Cameron Norman camerontnor...@gmail.com wrote: I actually did not experience #767028 on a system that does have /proc mounted, so it is likely. Again, I will double check later today. I said I would check but I never followed up on that :). I already deleted the group so I could not see who it was. I could not umount /proc in a container, and I ended up getting too lazy to set up a chroot (yes I know it is pretty easy, I am just kind of busy and tired). That said your hypothesis that it is a udevadm failure seems extremely likely. OK. Do you have ovirt-guest-agent installed, ie if I update it, would you test it on your system? Yes I can do that. -- Cameron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776012: RFS: shadowd/1.0.0 [ITP: #775998]
El jue, 22 de ene 2015 a las 9:33 , Hendrik Buchwald h...@zecure.org
escribió:
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package shadowd.
* Package name: shadowd
Version : 1.0.0
Upstream Author : Hendrik Buchwald h...@zecure.org
* URL : https://shadowd.zecure.org/
* License : GPL
Programming Lang: C++
Description : Shadow Daemon web application firewall server
shadowd is the main component of the web application firewall Shadow
Daemon.
Currently it is possible to use Shadow Daemon to protect PHP, Perl
and Python
web applications by detecting and removing malicious user input. The
firewall
intercepts requests and uses a combination of white- and blacklisting
to detect
attacks. More detailed information can be found on the homepage. A
new, fancier
homepage is in the works and will be released shortly. The
development of all
components is public and takes place at https://github.com/zecure.
The Debian packages and files are hosted at
https://shadowd.zecure.org/files/debian/.
I would be grateful if someone is interested in sponsoring me,
because I think
better web application security is of great importance :)
Unfortunately I am not a DD, so I can not sponsor, however I do have a
few comments:
In prerm, you manually stop shadowd. You do not have to do that;
dh_installinit already does it itself (you can check the generated
prerm in the .deb).
In postrm, you manually delete the config file and config directory on
purge. You do not have to do that, because they will be automatically
be deleted because they are owned by the shadowd package.
In control, you explicitly list the libraries it depends on (e.g.
libcrypto++9). Why did you add that? Were ${shlibs:Depends} and
${misc:Depends} not adding all the libraries that you listed in the
build depends field / the libraries shadowd linked to?
This one I am not 100% on, so you may want to look at other packages
for reference or ask on debian-mentors if that does not help. Anyway, I
believe that users and groups are supposed to be left around, even
after a package is purged. Otherwise a new package would inherit the
same UID and with it access to potentially security sensitive files. So
it is best to remove the entire postrm.
Also, I have written an Upstart job that I would appreciate you
including in the package. (Just put it into the debian/ directory under
the filename `shadowd.upstart`).
Lastly, you may want to put your package on mentors.debian.org so that
people can look at the lintian results at a glance.
Good luck!
--
Cameron Norman
description Shadow Daemon Web Application Firewall
start on runlevel [2345]
stop on runlevel [016] or unmounting-filesystem
exec /usr/bin/shadowd -c /etc/shadowd/shadowd.ini -U shadowd -G shadowd
Bug#761815: installation adds entries for USB media to /etc/fstab which confuse udisks
On Sat, 17 Jan 2015 10:44:18 + Steve McIntyre st...@einval.com wrote: On Thu, Dec 04, 2014 at 09:38:05PM +0100, Ansgar Burchardt wrote: My personal opinion is that the right thing is to not add entries to /etc/fstab for removable devices at all (where removable means that the device itself can be removed, not just devices with removable media): I think there is no guarantee that the entry added to /etc/fstab actually matches the right device later. Plus the problems with udisks. 100% agreed. My patch currently only prohibits adding of USB device entries. Should this be extended to floppies and CD-ROMs? What about kfreebsd and hurd? I'm not sure about CD-ROM/floppies or other devices with removable media. I also don't know about kFreeBSD or Hurd. IMO this should be fixed before the release as it causes unexpected and inconsistent behavior. Agreed. I've personally at least encountered 3 people having problems with using USB media under desktop environments (KDE or GNOME) due to these entries in /etc/fstab. I'm thinking the best way to go with this is to simply drop this misc USB device support altogether from partman-target. Any objections? As someone hit by this, yes please. I like to start from a fairly minimal debian install, so when I add udisks post-install, I could still be hit by it if the other previously mentioned patch is used. Just removing that removable media handling support would be ideal. Thank you. -- Cameron Norman
Bug#774437: ovirt-guest-agent: fails in preinst due to hardcoded uid and gid values
On Fri, 9 Jan 2015 12:47:28 -0800 Cameron Norman camerontnor...@gmail.com wrote: On Fri, Jan 9, 2015 at 12:03 PM, László Böszörményi (GCS) g...@debian.org wrote: On Fri, Jan 2, 2015 at 8:33 PM, Cameron Norman camerontnor...@gmail.com wrote: It hardcodes them as 175. The uid was not taken, but the gid was so the package installation failed. Funnily enough, I was trying to fix #767028 at the time. Can you confirm that #767028 happens due to udevadm failure because /proc is not mounted? What has gid 175 on your system? Not at my comp (will get back to you when I am), but I am pretty sure it was radicale. I actually did not experience #767028 on a system that does have /proc mounted, so it is likely. Again, I will double check later today. I said I would check but I never followed up on that :). I already deleted the group so I could not see who it was. I could not umount /proc in a container, and I ended up getting too lazy to set up a chroot (yes I know it is pretty easy, I am just kind of busy and tired). That said your hypothesis that it is a udevadm failure seems extremely likely. Best regards, -- Cameron Norman
Bug#774437: ovirt-guest-agent: fails in preinst due to hardcoded uid and gid values
On Fri, Jan 9, 2015 at 12:03 PM, László Böszörményi (GCS) g...@debian.org wrote: On Fri, Jan 2, 2015 at 8:33 PM, Cameron Norman camerontnor...@gmail.com wrote: It hardcodes them as 175. The uid was not taken, but the gid was so the package installation failed. Funnily enough, I was trying to fix #767028 at the time. Can you confirm that #767028 happens due to udevadm failure because /proc is not mounted? What has gid 175 on your system? Not at my comp (will get back to you when I am), but I am pretty sure it was radicale. I actually did not experience #767028 on a system that does have /proc mounted, so it is likely. Again, I will double check later today. -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774328: ctdb: Failed to start ctdb.service: Unit ctdb.service failed to load: No such file or directory.
On Thu, 1 Jan 2015 09:16:16 +1100 Martin Schwenke mar...@meltin.net wrote: Package: ctdb Version: 2.5.4+debian0-3 Severity: grave Justification: renders package unusable Dear Maintainer, # systemctl start ctdb Failed to start ctdb.service: Unit ctdb.service failed to load: No such file or directory. # ls -l /lib/systemd/system/ctdb.service -rw-r--r--. 1 root root 306 Dec 15 04:30 /lib/systemd/system/ctdb.service This is after a fresh install of the ctdb package. I can't find anything useful logged anywhere. Perhaps I need to reboot to get systemd into a useful state? Did you try running `systemctl daemon-reload` then trying to start ctdb? Thanks, -- Cameron Norman
Bug#774437: ovirt-guest-agent: fails in preinst due to hardcoded uid and gid values
Package: ovirt-guest-agent Version: 1.0.10.2.dfsg-1 Severity: serious It hardcodes them as 175. The uid was not taken, but the gid was so the package installation failed. Funnily enough, I was trying to fix #767028 at the time. Best regards, -- Cameron Norman
Bug#771887: nut-client: Does not install cleanly
On Wed, 03 Dec 2014 08:52:39 +0100 Matthias Urlichs matth...@urlichs.de wrote: Package: nut-client Version: 2.7.2-1+b3 Severity: serious Justification: 10.7.3 An unconfigured package is expected to not fail installation. Setting up nut-client (2.7.2-1+b3) ... Job for nut-monitor.service failed. See systemctl status nut-monitor.service and journalctl -xe for details. invoke-rc.d: initscript nut-client, action start failed. dpkg: error processing package nut-client (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: nut-client Press Return to continue. This is probably because you need to configure nut before it is able to start successfully. The systemd services nut ships do not take into account /etc/nut/nut.conf (which by default is set to none, which is supposed to disable all the services). Not exactly sure how to go about adding these types of checks to the systemd service... perhaps it would be easier to just remove the systemd services and leave the init scripts, at least for now. -- Cameron Norman
Bug#768827: systemd: issues with systemd in a lxc container
El vie, 12 de dic 2014 a las 12:25 , Michael Biebl bi...@debian.org escribió: Hi, Am 12.12.2014 um 07:26 schrieb Cameron Norman: On Sun, 09 Nov 2014 16:22:36 +0100 Michael Biebl bi...@debian.org wrote: not not systemd. That said, if there is something we can do in the systemd package, to make it work (better) in lxc, please let us know. There are a few things. Linking sigpwr.target to halt.target would make lxc-stop work *cleanly* OOTB. Why is that necessary to stop lxc containers cleanly? That sounds odd. Because lxc needs to signal the init to shutdown cleanly, and you do not want to use a normal signal (e.g. SIGTERM) because all init systems block those. So SIGPWR is used. After SIGPWR is sent and a timeout lapses, lxc-stop just SIGKILLs the cgroup. So to avoid the timeout and an unclean shutdown occuring, systemd needs to respond to SIGPWR. Alternatively, we could make LXC signal that one special systemd clean shutdown signal (it is documented on the container interface I think), but that would require changing the container's configuration to make it incompatible with Upstart and sysvinit (well the inittab is modified to respond to sigpwr for sysvinit, not something supported locally). The big one would be to pop up a prompt on first install of systemd-sysv while in an lxc container (similar to the /etc/inittab checking and associated message that is planned I think) telling the user that the host's version of LXC must be 0.8 or greater (available in squeeze-backports and wheezy), and the configuration for the container (a file on the host) needs to contain the lines `lxc.kmsg = 0` and `lxc.autodev = 1`. If lxc in wheezy is recent enough, tbh I wouldn't worry too much about squeeze users running jessie containers. I think documenting that fact is sufficient. Fair enough, it is just that Wheezy does not use those options by default so the user still has to intervene in that case and add them him/herself. Jessie uses those options by default. I suppose we could backport that little patch (it is just a little two liner), so no biggy. And the only HUGE problem is if the user of the container does not have access to the host, but I do not think there are many (if any) of those setups. Also apparently udev should not run in containers. Do you think we should have something with ConditionVirtualization!=container or whatever in the udev service file? The systemd-udevd service already has ConditionPathIsReadWrite=/sys which I thought was there to make sure udevd is not started in a container. Does lxc (bind)-mount /sys writable into the containers? If so, maybe it should change that. Upstream, /sys and /proc are mounted read-write, but apparently the Debian maintainer has patched the common debian config to mount /sys ro. Still, that is only on Jessie (and will probably not reach Ubuntu). If it does not hurt, it would help for Wheezy hosts where /sys is still rw to add that virt related line. Thank you for the quick response! -- Cameron
Bug#768827: systemd: issues with systemd in a lxc container
Hello Michael, On Sun, 09 Nov 2014 16:22:36 +0100 Michael Biebl bi...@debian.org wrote: Control: retitle -1 issues with systemd in a lxc container Am 09.11.2014 um 16:11 schrieb Ritesh Raj Sarraf: If I switch the init sysvinit-core in the LXC container, then the problem goes away. Therefore I've come to the conclusion that the bug lies with systemd. I don't think the lxc maintainers currently support systemd in a container [1]. Afair, this is something which needs to be addressed in lxc, though, and not not systemd. That said, if there is something we can do in the systemd package, to make it work (better) in lxc, please let us know. There are a few things. Linking sigpwr.target to halt.target would make lxc-stop work *cleanly* OOTB. Also the patch to getty@.service shown here would help: https://wiki.archlinux.org/index.php/Linux_Containers#lxc-console_does_not_provide_a_login_prompt The big one would be to pop up a prompt on first install of systemd-sysv while in an lxc container (similar to the /etc/inittab checking and associated message that is planned I think) telling the user that the host's version of LXC must be 0.8 or greater (available in squeeze-backports and wheezy), and the configuration for the container (a file on the host) needs to contain the lines `lxc.kmsg = 0` and `lxc.autodev = 1`. That last one is difficult because the host may not support those options (older than 0.8 LXC version), we can not adjust them ourselves from inside the container, and the container becomes unbootable if they are not set correctly (I think journald uses 100% CPU if lxc.kmsg is 1 instead of 0). Also apparently udev should not run in containers. Do you think we should have something with ConditionVirtualization!=container or whatever in the udev service file? The lxc debian template tries to do all of this (including masking udev.service and systemd-udev.service), but it can only act on newly created containers so upgraded ones are left high and dry. Cheers, -- Cameron
Bug#670437: pygopherd: diff for NMU version 2.0.18.3+nmu4
On Mon, Dec 8, 2014 at 11:55 PM, gregor herrmann gre...@debian.org wrote: On Mon, 08 Dec 2014 17:49:27 -0800, Cameron Norman wrote: I have supplied a more minimal NMU to fix #771501 that does not mess with the gophermap file other than installing it if it was not there before. Where is this new patch? It seems that I don't see it right now :) Doh! Attached now :) Cheers, -- Cameron pygopherd-nodocusage.2.debdiff Description: Binary data
Bug#670437: pygopherd: diff for NMU version 2.0.18.3+nmu4
On Sun, 7 Dec 2014 15:48:28 +0100 gregor herrmann gre...@debian.org wrote: Control: tags 670437 + pending Control: tags 771501 + pending Dear maintainer, Cameron Norman has prepared an NMU for pygopherd (versioned as 2.0.18.3+nmu4) and I've uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Unfortunately I have discovered there is an issue in this set of changes. The gophermap file is modified by the admin in basically all cases of pygopherd being actually used to serve a gopher site. Overwriting it (on installation/upgrade) or deleting it (on removal/purge), which this NMU does, is deleting the data of the site. I have supplied a more minimal NMU to fix #771501 that does not mess with the gophermap file other than installing it if it was not there before. I will hopefully address the unowned file issue (#670437) in a later set of changes. Thanks for sponsoring the first upload, Gregor. Best regards, -- Cameron Norman
Bug#766216: jessie+systemd support patch is in lxc upstream
On Fri, 28 Nov 2014 14:50:22 -0200 Antonio Terceiro terce...@debian.org wrote: Now sending to the correct bug ... Hey Daniel, Just a friendly ping to say that the patch to templates/lxc-debian.in that makes systemd containers work properly was aready merged upstream. https://github.com/lxc/lxc/commit/a9bf60bab547013a9873a3fb9efe61155e8694b8 According to feedback in the upstream mailing list, the template itself will now add the necessary configuration bits (autodev, kmsg) when the rootfs has systemd as PID 1, so you could probably drop debian/patches/0012-lxc-debian-systemd.patch (I think we don't want those config entries for non-systemd containers) ... While the autodev option is negative because it means we do not get unpriveleged containers, there is a different common config for debian-userns anyway so it does not matter. The presence of the kmsg option is fairly asthetic, no real harm having it there. I think it would be best to keep both of those options so that if someone creates a Wheezy container (i.e. with sysvinit) then upgrades the container to Jessie it mostly works. You just do not get gettys or clean shutdown, but that is not critical because you can use `lxc-attach -n container` to resolve those issues. And with my changes to your patch, we actually do get clean shutdown so the gettys are the only issue left (unless we reverse the 0012-lxc-debian-systemd patch, in which case we could have journald using 100% CPU and/or systemd's /sbin/init getting mad about /dev not being exactly what was expected). So please keep that patch. Thank you, -- Cameron Norman
Bug#771978: [pkg-apparmor] Bug#771978: Patch: apparmor profile for ps
Hello, On Fri, Dec 5, 2014 at 3:45 PM, Craig Small csm...@debian.org wrote: On Fri, Dec 05, 2014 at 04:42:02PM +0100, intrigeri wrote: * reviewed by someone who's knowledgeable about AppArmor, to make sure it actually offers some protection and respects various best Could someone on the list look at that for me? The patch is in the bug report. * tested by someone who's knowledgeable about the program that is being confined by the proposed profile, to make sure the OK, I'll go find myself a VM. I've got kvm here already so its pretty simple to get something going. You may want to make sure there is not duplication of work with this guy: https://lists.ubuntu.com/archives/apparmor/2014-December/006896.html We've had dh-apparmor for a while :) Ever had one of those days where: You can't find X You email I can't find X Then, the very next thing, you find X I had one of those days. You aren't allowed to have those days /sarcasm :) Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771978: [pkg-apparmor] Bug#771978: Patch: apparmor profile for ps
On Fri, Dec 5, 2014 at 4:38 PM, Craig Small csm...@debian.org wrote: On Fri, Dec 05, 2014 at 04:20:24PM -0800, Cameron Norman wrote: You may want to make sure there is not duplication of work with this guy: https://lists.ubuntu.com/archives/apparmor/2014-December/006896.html He's the bug submitter. So no duplication. Oh I had not even noticed, I came across this discussion via pkg-apparmor-team. -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670437: pygopherd: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/pygopherd/examples/gophermap
On Sun, 30 Nov 2014 10:29:40 +0100 Andreas Beckmann a...@debian.org
wrote:
Package: pygopherd
Version: 2.0.18.3+nmu3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
a test with piuparts revealed that your package uses files from
/usr/share/doc in its maintainer scripts which is a violation of
Policy 12.3: Packages must not require the existence of any files in
/usr/share/doc/ in order to function.
https://www.debian.org/doc/debian-policy/ch-docs.html#s12.3
These files must be moved to /usr/share/$PACKAGE and may be symlinked
from /usr/share/doc/$PACKAGE.
This piuparts test prevents the installation of (most) files into
/usr/share/doc with 'dpkg --path-exclude=...'.
From the attached log (scroll to the bottom...):
Selecting previously unselected package pygopherd.
(Reading database ... 8452 files and directories currently
installed.)
Preparing to unpack .../pygopherd_2.0.18.3+nmu3_all.deb ...
Unpacking pygopherd (2.0.18.3+nmu3) ...
Setting up pygopherd (2.0.18.3+nmu3) ...
Adding system user `gopher' (UID 150) ...
Adding new group `gopher' (GID 151) ...
Adding new user `gopher' (UID 150) with group `gopher' ...
Creating home directory `/var/gopher' ...
cp: cannot stat '/usr/share/doc/pygopherd/examples/gophermap': No
such file or directory
dpkg: error processing package pygopherd (--configure):
subprocess installed post-installation script returned error exit
status 1
Errors were encountered while processing:
pygopherd
I have attached a patch to fix this issue. The patch has the side
effect of also fixing #670437.
Best regards,
--
Cameron Norman
diff -Nru pygopherd-2.0.18.3+nmu3/debian/changelog pygopherd-2.0.18.3+nmu4/debian/changelog
--- pygopherd-2.0.18.3+nmu3/debian/changelog 2013-06-30 05:30:23.0 -0700
+++ pygopherd-2.0.18.3+nmu4/debian/changelog 2014-12-05 21:24:42.0 -0800
@@ -1,3 +1,11 @@
+pygopherd (2.0.18.3+nmu4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Install gophermap in rules from upstream source, not from
+/usr/share/doc in postinst (Closes: #771501, #670437)
+
+ -- Cameron Norman camerontnor...@gmail.com Fri, 05 Dec 2014 20:51:00 -0800
+
pygopherd (2.0.18.3+nmu3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru pygopherd-2.0.18.3+nmu3/debian/postinst pygopherd-2.0.18.3+nmu4/debian/postinst
--- pygopherd-2.0.18.3+nmu3/debian/postinst 2008-04-10 06:56:55.0 -0700
+++ pygopherd-2.0.18.3+nmu4/debian/postinst 2014-12-05 21:22:48.0 -0800
@@ -31,13 +31,10 @@
set +e
UNAME=gopher
-HOMEDIR=/var/gopher
-if test -d $HOMEDIR; then HOMEDIREXISTS=yes; else HOMEDIREXISTS=no; fi
-
-if ! grep -q ^${UNAME}:.*${HOMEDIR} /etc/passwd
+if ! grep -q ^${UNAME}: /etc/passwd
then
- adduser --system --home $HOMEDIR --group $UNAME
+ adduser --system --home /nonexistent --no-create-home --group $UNAME
else
echo Gopher account already in place; not modifying.
fi
@@ -62,14 +59,8 @@
chsh -s /bin/sh gopher
fi
-
-if [ $HOMEDIREXISTS = no ]; then
- if ! test -d $HOMEDIR; then
-mkdir $HOMEDIR
- fi
- cp /usr/share/doc/pygopherd/examples/gophermap $HOMEDIR/gophermap
- chown -R gopher.gopher $HOMEDIR
-fi
+# fix permissions on /var/gopher, since the gopher u/gid is now present
+chown -R gopher.gopher /var/gopher
;;
diff -Nru pygopherd-2.0.18.3+nmu3/debian/rules pygopherd-2.0.18.3+nmu4/debian/rules
--- pygopherd-2.0.18.3+nmu3/debian/rules 2013-06-30 05:30:23.0 -0700
+++ pygopherd-2.0.18.3+nmu4/debian/rules 2014-12-05 21:13:53.0 -0800
@@ -75,6 +75,7 @@
mv debian/pygopherd/usr/bin/pygopherd \
debian/pygopherd/usr/sbin/pygopherd
rm debian/pygopherd/etc/pygopherd/mime.types
+ install -D examples/gophermap debian/pygopherd/var/gopher/gophermap
cp pygfarm/*.pyg debian/pygfarm/usr/share/pygfarm
chown root.root debian/pygfarm/usr/share/pygfarm/*
chmod 0755 debian/pygfarm/usr/share/pygfarm/*
Bug#772188: avis: bashism in /bin/sh script
On Sat, 06 Dec 2014 01:14:12 +0100 Raphael Geissert
geiss...@debian.org wrote:
Package: avis
Severity: serious
Version: 1.2.2-3
User: debian-rele...@lists.debian.org
Usertags: goal-dash
Hi,
I've ran checkbashisms (from the 'devscripts' package) over the whole
archive and I found that your package has a /bin/sh script that uses
a
bashism.
checkbashisms' output:
possible bashism in ./usr/sbin/avisd line 24 ($'...' should be
$(printf
'...')):
local NL=$'\x0a'
Not using bash (or a Debian Policy compliant shell interpreter that
doesn't
provide such an extra feature) as /bin/sh is likely to lead to
errors or
unexpected behaviours. Please be aware that dash is the default
/bin/sh.
Please closely examine the above output and the script, and determine
what the proper severity of the bug is, and adjust it accordingly. If
it's important or greater please hurry to get this fixed for jessie.
Hints about how to fix bashisms can be found at:
https://wiki.ubuntu.com/DashAsBinSh
I have attached a patch which avoids this bashism. Please apply it to
fix this RC bug. It is very non-intrusive.
Gratzie,
--
Cameron Norman
diff --git a/server/bin/avisd b/server/bin/avisd
index 0b76fdb..02bdfd2 100755
--- a/server/bin/avisd
+++ b/server/bin/avisd
@@ -20,20 +20,18 @@ fi
usage ()
{
- local NL=$'\x0a'
- local help=\
- Usage: $0 [-h] [-v] [-vv] [-p port] [-c file] $NL\
-[-daemon] [-pidfile file] [-logfile file] $NL\
+ cat EOF
+ Usage: $0 [-h] [-v] [-vv] [-p port] [-c file]
+[-daemon] [-pidfile file] [-logfile file]
- -h : This text$NL\
- -v and -vv : Increase verbosity$NL\
- -p port : Set port to listen on$NL\
- -c file : Load config from file$NL\
- -daemon : Run as daemon$NL\
- -pidfile file: Output process ID to file$NL\
- -logfile file: Log output to file (only with -daemon)$NL
-
- echo $help 2
+ -h : This text
+ -v and -vv : Increase verbosity
+ -p port : Set port to listen on
+ -c file : Load config from file
+ -daemon : Run as daemon
+ -pidfile file: Output process ID to file
+ -logfile file: Log output to file (only with -daemon)
+EOF
}
while [ $# -gt 0 ]; do
Bug#770776: lxc: can't access console or stop a jessie container running systemd as PID 1
Hello Daniel, On Mon, 24 Nov 2014 09:10:46 +0100 Daniel Baumann daniel.baum...@progress-technologies.net wrote: first of all, systemd works fine in privileged systemd containers. second, i normally wait a couple of days until upstream had a chance to reply (here, specifically to Antonions patch). usually, if they haven't answered in a couple of days, the bug/patch will not get picket up in any reasonable time and it's fine to cherry pick it (this is because i have been asked to not patch lxc-debian at all in order to preserv the same good or bad user experience across different distributions). once that is cherry-picked, third: the only thing that needs to go into the release-notes is a note that *iff* debian has an automatic upgrade of wheezy-with-sysvinit to jessie-with-systemd (which i welcome), *then* the release notes should say that existing containers need to adjust their getty units to accomodate for that. Do we not also want them to link sigpwr.target to halt.target to make sure lxc-stop does not end up SIGKILL'ing systemd? And disabling udev would probably be a good idea as well (although it is usually a no-op IME in containers). Also, would you kindly consider also picking this related patch [0] and the one preceding it? [0] https://github.com/lxc/lxc/commit/4de03d375b49e7749605c8a45abc898317833f3f Thank you, -- Cameron Norman
Bug#762194: Alternative proposal for init switch on upgrades.
On Sat, Nov 29, 2014 at 11:15 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Cameron Norman On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl wrote: On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: I would like to propose a different one. [...] So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. I'm afraid this doesn't allow partial upgrades from wheezy to use systemd-sysv, as sysvinit is an essential package there, and apt considers packages to be essential if they're present in any source. I take it you mean that the user will have to remove an essential package to install systemd-sysv, not that the package will not be installable, correct? That seems reasonable to me. If the user has packages from Wheezy installed, those packages could reasonably depend on sysvinit as PID 1 without expressing that dependency. No. They could reasonably depend on sysvinit being installed. We ship alternative inits in wheezy, some of which does not require sysvinit to be uninstalled (systemd and runit comes to mind, I would not be surprised if there are more). However, in the tradition of Essential packages, nowhere is it well-defined which of sysvinits interfaces were part of the essentialness and which are not. I kinda wish we'd fix that at some point, to make it easier to swap out (or get rid of) Essential packages. Would systemd-sysv having a `Provides: sysvinit` fix this issue? I think if the pre-installation /etc/inittab checking that has been discussed is implemented then systemd could reasonably be considered to provide sysvinit's interfaces (especially with the /dev/initctl compatibility). Thank you, -- Cameron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762194: Alternative proposal for init switch on upgrades.
On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl wrote: On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: I would like to propose a different one. [...] So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. I'm afraid this doesn't allow partial upgrades from wheezy to use systemd-sysv, as sysvinit is an essential package there, and apt considers packages to be essential if they're present in any source. I take it you mean that the user will have to remove an essential package to install systemd-sysv, not that the package will not be installable, correct? That seems reasonable to me. If the user has packages from Wheezy installed, those packages could reasonably depend on sysvinit as PID 1 without expressing that dependency. It would be a bug, IMO, if sysvinit was not PID 1 while Wheezy packages were installed and the user had not expressed that he or she understood the implications of removing sysvinit. Thus, I maintain that my proposal is an appropiate approach. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765870: systemd-logind brings system to knees with RAM consumption
On Sat, Nov 29, 2014 at 2:57 PM, John Goerzen jgoer...@complete.org wrote: I have not yet had the chance to migrate this system to boot with systemd. The problem is also not yet resolved. However, the logind processes now consume far less RAM: [snip] So you did reboot and the problem persisted? What kernel version are you running (IIRC someone reported problems with 3.14 and systemd-shim, however that was not definite)? And what does `loginctl show-sessions` output? Thank you, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768758: upstart: FTBFS in jessie: dh_auto_test: make -j10 check returned exit code 2
On Thu, 13 Nov 2014 18:41:20 -0800 Cameron Norman camerontnor...@gmail.com wrote: On Sun, 09 Nov 2014 16:11:27 -0800 Cameron Norman camerontnor...@gmail.com wrote: Hello, Lucas Nussbaum wrote: [Huge snip] FAIL: test_conf_preload.sh [Small snip] That script uses the libtool command, which is provided by libtool-bin in Jessie (whereas in Wheezy it was libtool). So I think you just need a build dependency on libtool-bin. There could be more; I had like 5 tests fail on me. Don't know what that is all about... Tried in a proper jessie chroot; same situation. The test still fails with libtool-bin (along with four others), but it gets farther along than without it installed. Attached a patch to fix the missing build dependency on libtool-bin. Regardless of whether it fixes this test failure (which I am fairly confident it does), it is still something that needs to be done. Thank you, -- Cameron Norman
Bug#762194: a technical proposal
Hello, On Sat, Nov 22, 2014 at 5:21 AM, Adam Borowski kilob...@angband.pl wrote: Hi! As Ansgar requests technical solutions, here's one: just like systemd-shim|systemd-sysv, switch the init package from Pre-Depends: systemd-sysv | sysvinit-core | upstart to Pre-Depends: sysvinit-core | systemd-sysv | upstart The set of packages installed by d-i / debootstrap is steered by hard-coded scripts, thus new systems can default to whatever is set there. On the other hand, during upgrades, the init system is driven by apt's resolution of the above pre-dependency. If systemd-sysv or upstart were already installed, no change is done; if none of these three packages is present, apt would install sysvinit-core, preserving existing init system. One of Steve Langasek's criticisms of not switching by default was the pain of having systems still running sysvinit for many years to come, which makes the distribution more difficult to support. If there was an intention to do so, how would we go about switching systems over to systemd in the next release, if we use the solution displayed here in Jessie? Thanks, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762194: a technical proposal
On Sat, Nov 22, 2014 at 9:01 AM, Cameron Norman camerontnor...@gmail.com wrote: Hello, On Sat, Nov 22, 2014 at 5:21 AM, Adam Borowski kilob...@angband.pl wrote: Hi! As Ansgar requests technical solutions, here's one: just like systemd-shim|systemd-sysv, switch the init package from Pre-Depends: systemd-sysv | sysvinit-core | upstart to Pre-Depends: sysvinit-core | systemd-sysv | upstart The set of packages installed by d-i / debootstrap is steered by hard-coded scripts, thus new systems can default to whatever is set there. On the other hand, during upgrades, the init system is driven by apt's resolution of the above pre-dependency. If systemd-sysv or upstart were already installed, no change is done; if none of these three packages is present, apt would install sysvinit-core, preserving existing init system. One of Steve Langasek's criticisms of not switching by default was the pain of having systems still running sysvinit for many years to come, which makes the distribution more difficult to support. Here is the message which I am referencing. Please see the footnote. I hope I did not misrepresent you, Steve, please correct me if so. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#66 -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762194: Alternative proposal for init switch on upgrades.
Hello everyone, Since I myself and some others had some criticisms and/or doubts of Adam Borowski's proposal, I would like to propose a different one. With this I hope to: * make new installations use systemd-sysv (with no reliance on undefined or inconsistent behavior from the various ways of setting up a Debian install or chroot) * make current installations that have sysvinit stick with it * allow for the automatic switch from sysvinit to systemd-sysv in stretch, buster, or another later release So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. If an automatic switch is something that the project wants, but after Jessie, then then the init dependency would be changed to systemd-sysv | sysvinit-core | upstart. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767671: ekeyd: fails to remove: subprocess installed post-removal script fails when udev is not running
Hello, I have attached a patch which addresses this issue. Please include it quickly so that this bug can be fixed. Thank you, -- Cameron Norman diff --git a/debian/ekeyd.postrm b/../ekeyd-767671/debian/ekeyd.postrm index 484db5c..4efc368 100644 --- a/debian/ekeyd.postrm +++ b/../ekeyd-767671/debian/ekeyd.postrm @@ -1,9 +1,5 @@ #!/bin/sh -e -if test -x /sbin/udevcontrol; then -udevcontrol --reload_rules 2/dev/null || udevcontrol reload_rules 2/dev/null -elif test -x /sbin/udevadm; then -udevadm control --reload-rules 2/dev/null || udevadm control --reload_rules 2/dev/null -fi +invoke-rc.d --quiet udev reload || true #DEBHELPER#
Bug#767671: ekeyd: fails to remove: subprocess installed post-removal script fails when udev is not running
On Sat, Nov 15, 2014 at 7:00 PM, Cameron Norman camerontnor...@gmail.com wrote: On Sat, Nov 15, 2014 at 6:45 PM, Cameron Norman camerontnor...@gmail.com wrote: Hello, I have attached a patch which addresses this issue. Please include it quickly so that this bug can be fixed. I apologize, this patch was not easily applied. I have attached a new one that can be applied by simply running `patch debian/ekeyd.postrm ekeyd-udev-reload.2.patch` in the source directory. Darn it forgot to attach. -- Cameron Norman diff --git a/debian/ekeyd.postrm b/debian/ekeyd.postrm index 484db5c..4efc368 100644 --- a/debian/ekeyd.postrm +++ b/debian/ekeyd.postrm @@ -1,9 +1,5 @@ #!/bin/sh -e -if test -x /sbin/udevcontrol; then -udevcontrol --reload_rules 2/dev/null || udevcontrol reload_rules 2/dev/null -elif test -x /sbin/udevadm; then -udevadm control --reload-rules 2/dev/null || udevadm control --reload_rules 2/dev/null -fi +invoke-rc.d --quiet udev reload || true #DEBHELPER#
Bug#767671: ekeyd: fails to remove: subprocess installed post-removal script fails when udev is not running
On Sat, Nov 15, 2014 at 6:45 PM, Cameron Norman camerontnor...@gmail.com wrote: Hello, I have attached a patch which addresses this issue. Please include it quickly so that this bug can be fixed. I apologize, this patch was not easily applied. I have attached a new one that can be applied by simply running `patch debian/ekeyd.postrm ekeyd-udev-reload.2.patch` in the source directory. Thanks, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767194: trivial fix
On Wed, 29 Oct 2014 13:32:18 -0400 Joey Hess jo...@debian.org wrote: There is no reason for fstrim to be run by a systemd timer in Debian. We have cron.weekly. So, fixing #732054 will fix this bug too. I have attached a patch that provides a minimal cron job, based on the systemd timer and service. I would appreciate if this was included in the next upload to fix these two bugs. Thank you, -- Cameron Norman diff --git a/debian/util-linux.fstrim.cron b/debian/util-linux.fstrim.cron new file mode 100755 index 000..7f17eb8 --- /dev/null +++ b/debian/util-linux.fstrim.cron @@ -0,0 +1,3 @@ +#!/bin/sh + +exec fstrim -a diff --git a/debian/util-linux.install b/debian/util-linux.install index 6e27066..a5a136c 100755 --- a/debian/util-linux.install +++ b/debian/util-linux.install @@ -10,8 +10,7 @@ debian/tmp/usr/bin/rename = /usr/bin/rename.ul [linux-any] sbin/mkswap [!linux-any] debian/tmp/sbin/mkswap = /sbin/mkswap.linux # weekly fstrim only available on linux -[linux-any] lib/systemd/system/fstrim.timer -[linux-any] lib/systemd/system/fstrim.service +[linux-any] debian/util-linux.fstrim.cron = /etc/cron.weekly/fstrim bin/more sbin/agetty sbin/blkid
Bug#768758: upstart: FTBFS in jessie: dh_auto_test: make -j10 check returned exit code 2
On Sun, 09 Nov 2014 16:11:27 -0800 Cameron Norman camerontnor...@gmail.com wrote: Hello, Lucas Nussbaum wrote: [Huge snip] FAIL: test_conf_preload.sh [Small snip] That script uses the libtool command, which is provided by libtool-bin in Jessie (whereas in Wheezy it was libtool). So I think you just need a build dependency on libtool-bin. There could be more; I had like 5 tests fail on me. Don't know what that is all about... Tried in a proper jessie chroot; same situation. The test still fails with libtool-bin (along with four others), but it gets farther along than without it installed. -- Cameron
Bug#769446: certmonger: Failed to issue method call: Unit dbus.socket failed to load: No such file or directory.
On Thu, 13 Nov 2014 17:59:51 +0100 Benjamin Drung benjamin.dr...@profitbricks.com wrote: Package: certmonger Version: 0.75.14-2 Severity: grave The installation fails: Setting up certmonger (0.75.14-2) ... Failed to issue method call: Unit dbus.socket failed to load: No such file or directory. invoke-rc.d: initscript certmonger, action start failed. dpkg: error processing package certmonger (--configure): subprocess installed post-installation script returned error exit status 6 [...] certmonger should probably depend on dbus. Please do not do that. Both the Upstart job and init script work just fine without D-Bus installed. Instead, I think that the certmonger systemd service should change its type from dbus to forking and remove the `-n` option. Alternatively, it could use Type=simple and keep the `-n` option but then you do not get readiness. Not sure if that is critical. I think you can still keep dbus based activation without Type=dbus and a without a dependency on dbus, but you should ask the systemd maintainers about that. Thank you, -- Cameron Norman
Bug#766943: systemd: server no longer gets networking after switching to systemd
El mié, 12 de nov 2014 a las 6:30 , Michael Biebl bi...@debian.org escribió: Am 12.11.2014 um 05:04 schrieb Cameron Norman: On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl bi...@debian.org wrote: Am 11.11.2014 um 20:01 schrieb Michael Biebl: Attached is a patch against /etc/init.d/networking. While we discussed yesterday, to only run udevadm settle if there are any auto interfaces, I changed it, to also cover allow-hotplug. I also changed the init script to handle allow-hotplug interfaces. [..] Please test and report back. Grr, the attached patch had a typo, please try this v2. So with this change, $network and network.target mean that all interfaces marked auto or allow-hotplug have been configured, or hotplug events have been settled and as many interfaces as could be brought up have been, correct? And if an auto interface is never brought up, that is ignored after udev settles? Are you sure that is desired behavior, seeing as allow-hotplug is the only configuration that explicitly references hotplug devices/events? I'm not quite sure what problem you're referring too, please elaborate. If you are using auto for an interface which is plugged in after /etc/init.d/networking start has been run, then yeah, it won't be configured. But the patch doesn't change that. But will services depending on network.target be started then? Or will they be prevented from starting in the case of an auto interface not being configured? Thank you, -- Cameron Norman
Bug#766943: systemd: server no longer gets networking after switching to systemd
On Wed, Nov 12, 2014 at 3:35 PM, Michael Biebl bi...@debian.org wrote: Am 12.11.2014 um 23:59 schrieb Cameron Norman: But will services depending on network.target be started then? Or will they be prevented from starting in the case of an auto interface not being configured? How is that relevant for this patch? For some reason I thought that that particular behavior was changing. Upon re-reading, it is not. Sorry for the bother. Thank you, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766943: systemd: server no longer gets networking after switching to systemd
On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl bi...@debian.org wrote: Am 11.11.2014 um 20:01 schrieb Michael Biebl: Attached is a patch against /etc/init.d/networking. While we discussed yesterday, to only run udevadm settle if there are any auto interfaces, I changed it, to also cover allow-hotplug. I also changed the init script to handle allow-hotplug interfaces. [..] Please test and report back. Grr, the attached patch had a typo, please try this v2. So with this change, $network and network.target mean that all interfaces marked auto or allow-hotplug have been configured, or hotplug events have been settled and as many interfaces as could be brought up have been, correct? And if an auto interface is never brought up, that is ignored after udev settles? Are you sure that is desired behavior, seeing as allow-hotplug is the only configuration that explicitly references hotplug devices/events? Thanks, -- Cameron Norman
Bug#768758: upstart: FTBFS in jessie: dh_auto_test: make -j10 check returned exit code 2
Hello, Lucas Nussbaum wrote: [Huge snip] FAIL: test_conf_preload.sh [Small snip] That script uses the libtool command, which is provided by libtool-bin in Jessie (whereas in Wheezy it was libtool). So I think you just need a build dependency on libtool-bin. There could be more; I had like 5 tests fail on me. Don't know what that is all about... Best regards, -- Cameron Norman
Bug#741930: reportbug: add current init system information
On Wed, Nov 5, 2014 at 3:10 AM, Sandro Tosi mo...@debian.org wrote: Hello, On Wed, Nov 5, 2014 at 1:09 AM, Cameron Norman camerontnor...@gmail.com wrote: A few notes I have: 1. With Jessie and on, with sysvinit /sbin/init //will// be a link, not the true init file. This would lead to unknowns when the init was actually sysv. care to explain a bit better? I just upgraded a Wheezy VM to testing and (except some issues) once I replaced systemd with sysvinit-core /sbin/init *is* a regular file: You are correct. I thought that the sysvinit-core package just installed a link to the sysvinit package's /lib/sysvinit/init, but that was not correct. 2. With Upstart, /sbin/init is not a link, so that third test would give a false positive for sysvinit when it was actually Upstart (assuming the Upstart check gave a false negative). it should not be a false negative, do you have a situation in mind where it might happen? No, but if the Upstart check is a false negative you should give an unknown reading, not sysvinit. This is a minor issue, probably will never occur. 3. Maybe you should embed the check for Upstart, so that you do not have to source all of the init functions, and if that file is ever not available you still get the correct check. lsb init functions are part of lsb-base, a required package Yeah, you are right. Best wishes, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767671: ekeyd: fails to remove: subprocess installed post-removal script fails when udev is not running
Looks like a repeat of 624211. The fix is to just use invoke-rc.d --quiet udev reload || true instead of the whole udev rule reloading spiel in ekeyd.postrm. Best wishes, -- Cameron Norman
Bug#768248: ITP: gnome-shell-extension-redshift -- gnome shell extension for controlling redshift
On Wed, Nov 5, 2014 at 7:48 PM, Eric Dorland e...@debian.org wrote: Package: wnpp Severity: wishlist Owner: Eric Dorland e...@debian.org * Package name: gnome-shell-extension-redshift Version : 8a57273af00f413afd47d2b31d2cd50c6f8d8b6d Upstream Author : Thomas Liebetraut tho...@tommie-lie.de * URL : https://github.com/tommie-lie/gnome-shell-extension-redshift * License : GPLv3 Programming Lang: Javascript Description : redshift extension for GNOME Shell redshift integration for GNOME Shell. Very cool! You'll probably want to ensure that [this bug][1] gets resolved, as the version of GNOME shell in Jessie and Sid is 3.14. [1] https://github.com/tommie-lie/gnome-shell-extension-redshift/issues/6 Best wishes, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746578: libpam-systemd to flip dependencies - proposal
On Tue, Nov 4, 2014 at 1:28 PM, Sam Hartman hartm...@debian.org wrote:
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.
I thought Michael Biebl helped Serge Hallyn to provide a systemd
service for cgmanager (disabled by default), thus doing exactly what
you describe above. The package's files include
/lib/systemd/system/cg{manager,proxy}.service; is there anything wrong
with how those service definitions are being installed that allows
cgmanager to run on systemd without the user explicitly enabling it?
Best wishes,
--
Cameron Norman
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741930: reportbug: add current init system information
On Tue, Nov 4, 2014 at 5:35 AM, Sandro Tosi mo...@debian.org wrote: Hi Michael et al, On Mon, Nov 3, 2014 at 1:19 PM, Michael Biebl bi...@debian.org wrote: provided above one requires to check a dir existence and the checking a command and then execute it to parse its output. it seems a bit fragile, and maybe only upstart check really the running processes The systemd system runtime directory is only created when systemd is the active PID 1. Could you elaborate why you think this approach is fragile? If those two tests (for systemd and upstart) would be brittle, we'd have a problem, since they are used all over the place. well, mkdir can create it too :) but ok, those checks are so embedded that i can ignore if the reportbug check if fooled to thing theres another systems (there will be bigger problems indeed) so I will just mimik their logic in the code; I changed the sample scripts, attached, and it would be nice if you all could give it another round (thanks to everyone who already did!) in particular to those having an upstart init system. A few notes I have: 1. With Jessie and on, with sysvinit /sbin/init //will// be a link, not the true init file. This would lead to unknowns when the init was actually sysv. 2. With Upstart, /sbin/init is not a link, so that third test would give a false positive for sysvinit when it was actually Upstart (assuming the Upstart check gave a false negative). 3. Maybe you should embed the check for Upstart, so that you do not have to source all of the init functions, and if that file is ever not available you still get the correct check. 4. There is a tiny typo in the Upstart check. It needs an extra right parenthese at the end of the message. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote: Josh == Josh Triplett j...@joshtriplett.org writes: Josh - It can't check for generated lines for serial consoles or Josh similar; finish-install can generate various additional Josh inittab lines, which the check should include. Since when did systemd actually handle these correctly? I've generally found that systemd will give me a serial console only if the kernel console is that serial console. I've found that if I manually enable a serial console but have the kernel console go somewhere else, I end up with a system I cannot log into when I upgrade to systemd. This has been no end of frustration and I hope that your check correctly prompts in this case even when the line I generate is exactly the same as a line generated by the installer. If it's gotten better and I'd actually get a console in that case, that's of course fine too. It should either let me know I'm about to hurt myself or work:-) Either behavior is fine. TTBOMK, you'll automatically get a console on a serial port in a few cases: - If the kernel console points there (console=ttyS0); note that this works even if you change that console. - If the console is identified as a default system console (works for virtual machine serial ports, and for systems with unusually named standard console serial ports). See systemd-getty-generator. In other cases, you have to manually systemctl enable serial-getty@ttyX.service. I wonder if it might make sense to do a one-time migration that parses /etc/inittab, looks for serial console getty lines, and enables serial-getty@.service for any consoles it finds gettys for? If you are going to the work of parsing it all, would it not make sense to make a systemd generator out of it? -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
to be taken on their own. -- Tollef Fog Heen, on behalf of the systemd team UNIX is user friendly, it's just picky about who its friends are Thanks, -- Cameron Norman
Bug#766237: [systemd-shim] Version property from org.freedesktop.systemd1.Manager
On Tue, 21 Oct 2014 20:49:19 +0300 =?UTF-8?B?VMO2csO2ayBFZHdpbg==?= ed...@etorok.net wrote: Package: systemd-shim Version: 8-3 Severity: normal --- Please enter the report below this line. --- systemd-shim doesn't provide the Version property from org.freedesktop.systemd1.Manager. According to the documentation[0] applications shouldn't parse this property, but powerdevil from KDE does and hides the Sleep/Hibernate buttons [1]. I've patched[2] systemd-shim to implement the Version property and Sleep from KDE works now, but I don't think its the proper way forward (given that doc says apps shouldn't use it). Nevertheless I opened this bugreport to inform you about this issue. FWIW the powerdevil code also has a fallback check for Upstart if systemd version cannot be found, is there a dbus interface specific to systemd-shim they could check for? Thanks a ton for tracking this down. It explains why some KDE users have not seen their situation improve from the recent cgmanager fixes. That said, systemd-shim is really not the place to fix this. Instead, implement a have_logind function to replace the version check for 195. For the v198 check, I do not know what to do, but it should definitely be done on the KDE side of this. Best wishes, -- Cameron Norman
Bug#747821: systemd-logind doesn't create session for users logged in via GDM
Do systemd-shim 8-3 and cgmanager 0.33-2 fix this issue? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765803: tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie
On Sat, Oct 18, 2014 at 3:56 PM, Vincent Bernat ber...@debian.org wrote: ❦ 18 octobre 2014 13:32 +0200, Svante Signell svante.sign...@gmail.com : In summary, the CTTE is asked to make a decision on debconf warnings on: 1) Changing init system on upgrades (including sid) 2) Inform about alternate init systems for new installations 2 is quite far-fetched. Why not a debconf warning to tell there are alternatives to nano? And another one to tell there are alternatives to bash? The installation will take several hours to let the user know there are alternatives to almost any component. Well one good reason is that when you install nano or bash, vi/vim/emacs and zsh/fish are not uninstalled. Furthermore, these components are not necessary to boot your system into a stage where you can login, have internet capabilities, and can install or remove packages. The exception to this is when you remove bash, and you get a loud warning at that point. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759745: gdm3: Unable to login post-upgrade without systemd-sysv installed
Hello, A bug was recently fixed in cgmanager that may have caused the issue you are describing. Does upgrading your cgmanager and systemd-shim versions to those in Sid (0.33-2 and 8-3, respectively) solve this issue? If you are unable to upgrade those packages, you can try to add `cgroup_enable=memory` to the kernel command line and see if that fixes the issue. Thanks for taking the time, -- Cameron Norman
Bug#757348: [systemd-shim] Re: systemd: with SysV init, can no longer suspend and shutdown from lightdm
El dom, 12 de oct 2014 a las 9:49 , Marcin Szewczyk marcin.szewc...@wodny.org escribió: On Sun, Oct 12, 2014 at 06:09:46PM +0200, Marcin Szewczyk wrote: On Sun, Oct 12, 2014 at 05:25:43PM +0200, Marcin Szewczyk wrote: cgmanager: DEBUG per_ctrl_move_pid_main: 31385, memory - user.slice/user-1000.slice/session-c13.scope That means that when systemd-shim calls cgmanager to MovePid/MovePidAbs it uses a special controller name all. But it seems all doesn't include some controllers -- for example name=systemd. Questions are: 1) Should cgmanager move pid to name=systemd when called with all controller? So, I think it should and it would. I omitted very important line from my previous log: cgmanager: DEBUG per_ctrl_move_pid_main: 31385, memory - user.slice/user-1000.slice/session-c13.scope cgmanager: Found no cgroup entry for pid 31388 controller memory The thing is -- cgmanager jumps out from the all loop after some problem with the memory controller. I do not know what to do with it yet. I have applied a patch (attached) to cgmanager and everything seems to work now. I will send it to cgmanager maintainer and upstream to ask if it makes sense. Oh gosh, I figured out why I am unaffected. This is in my kernel command line: cgroup_enable=memory It was there all along! Thanks for figuring this out. Perhaps another good idea is to continue moving things and not just break out with a failure right away, then report failure once everything that can be moved is moved, you know? Relevant code for that can be found here: https://github.com/cgmanager/cgmanager/blob/bfca08381096d1be6a952a520d9207d04a3d88cc/cgmanager.c#L215 Best regards, -- Cameron Norman
Bug#757348: [systemd-shim] Re: systemd: with SysV init, can no longer suspend and shutdown from lightdm
On Sun, 12 Oct 2014 18:49:32 +0200 Marcin Szewczyk marcin.szewc...@wodny.org wrote: On Sun, Oct 12, 2014 at 06:09:46PM +0200, Marcin Szewczyk wrote: On Sun, Oct 12, 2014 at 05:25:43PM +0200, Marcin Szewczyk wrote: cgmanager: DEBUG per_ctrl_move_pid_main: 31385, memory - user.slice/user-1000.slice/session-c13.scope That means that when systemd-shim calls cgmanager to MovePid/MovePidAbs it uses a special controller name all. But it seems all doesn't include some controllers -- for example name=systemd. Questions are: 1) Should cgmanager move pid to name=systemd when called with all controller? So, I think it should and it would. I omitted very important line from my previous log: cgmanager: DEBUG per_ctrl_move_pid_main: 31385, memory - user.slice/user-1000.slice/session-c13.scope cgmanager: Found no cgroup entry for pid 31388 controller memory The thing is -- cgmanager jumps out from the all loop after some problem with the memory controller. I do not know what to do with it yet. I have applied a patch (attached) to cgmanager and everything seems to work now. I will send it to cgmanager maintainer and upstream to ask if it makes sense. Serge Hallyn is really good about quickly packaging up his new releases (he is maintainer upstream and in Debian (co-maintainer) and Ubuntu), so best bet is to just email him with the patch, or make a pull request on GitHub, whichever you prefer. Also, can you review this additional fixup: https://github.com/cgmanager/cgmanager/pull/16 ? Best regards, -- Cameron Norman
Bug#754850: Refer to #757348 for why this applies to cgmanager
There was some mixup, and the conversation about this bug is quite scattered unfortunately. Please refer to the discussion at the end of BTS#757348 for why this is a cgmanager bug. Thanks, -- Cameron Norman
Bug#757698: policykit permissions not applied with logind and systemd-shim
tags 757698 moreinfo tags 760281 moreinfo stop Hey, can you tell me if adding cgroup_enable=memory to the kernel command line fixes this problem? Also, please try out the patch to cgmanager on this message: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757348#125 These things have solved similar problems for others. Best wishes, -- Cameron Norman
Bug#764471: [systemd-shim] RE: [systemd] logind DBus GetSessionByPID() and GetUserByPID() fail
tags 764471 moreinfo stop On Thu, 09 Oct 2014 23:09:22 +0100 OmegaPhil omegap...@startmail.com wrote: Package: systemd-shim Version: 8-2 Have just noticed this bug - I've done some investigation under #757348, sounds like you're further along in a different direction: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757348#95 Yes, it looks like he found the issue (with memory controller not being enabled). Can you verify this by applying his provided patch or enabling memory controller (by adding cgroup_enable=memory to kernel command line)? Thanks, -- Cameron Norman
Bug#757348: [systemd-shim] Re: systemd: with SysV init, can no longer suspend and shutdown from lightdm
On Fri, 10 Oct 2014 16:19:51 +0200 Marcin Szewczyk
marcin.szewc...@wodny.org wrote:
I have done almost exactly the same research yesterday evening.
On Thu, Oct 09, 2014 at 09:16:07PM +0100, OmegaPhil wrote:
It looks like polkit has a hard dependency on systemd as init
currently
- the 'session' being sought goes through
src/polkit/polkit/polkitunixsession-systemd.c:polkit_unix_session_initable_init,
which then calls into sd_pid_get_session from the libsystemd0
package.
This uses the PID of the pkcheck-calling process to read the proc
file
'/proc/pid/cgroup' - it looks for a line containing 'systemd',
and
then extracts the 'path', the bit at the end, to get at the
session.
It bothers me a bit. As I see this logind has its internal list of
sessions in its memory. On the other hand there is a hierarchy in
/sys/fs/cgroup/systemd which (using some specially formatted names)
codes session names. What happens if they desynchronize (for example
when the logind daemon dies)?
There is also /run/systemd/{seats,users,sessions}. I suspect these
directories are to allow internal state to be recovered in case of a
crash, you know? Not sure though.
On my current session, every single process has '/' as this path -
in
libsystemd0/systemd-215/src/shared/cgroup-util.c:cg_path_get_session
line 1320, this path is explicitly rejected - its checked for and
'-ENOENT' is returned.
Same here.
Are you sure you have cgmanager running? Maybe the sysvinit script has
some problems; I am using Upstart al momento so maybe that is it.
Under a systemd-as-init system, a valid example of a path would be
'/user.slice/user-1000.slice/session-1.scope'.
I have done an experiment:
/sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-1.scope
echo SHELLPID
/sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-1.scope/tasks
Calls to polkit from that shell started working again.
After adding all the gvfs processes to that cgroup (using pgrep and
echo
to tasks) I was able to mount a USB drive.
So far I haven't seen logind factor in here.
The question is: who is responsible for adding my X11 process during
its
startup to that specially named cgroup?
There are so many actors. pid eins, cgmanager, logind, lightdm, X11
scripts in /etc/X11, polkit, consolekit and PAM session modules (for
both consolekit and systemd).
On sysvinit and Upstart, PID1 has nothing to do with this situation. On
systemd, systemd puts the session init process into a cgroup.
systemd-shim offers systemd's D-Bus interface and implements the
cgroups bits (which logind is concerned with) through cgmanager. Can
you tell me what your cgmanager version is?
Basically the flow is:
PAM module for logind calls the logind CreateSession() method
logind calls the systemd cgroup slice creation methods (delivered to
systemd-shim)
systemd-shim calls the cgmanager cgroup methods, and the session init
process is then put into the appropiate cgroup
I have this stuff working, and my /proc/$$/cgroup looks like so:
11:name=systemd:/user.slice/user-1000.slice/session-1.scope
10:perf_event:/user.slice/user-1000.slice/session-1.scope
9:net_prio:/user.slice/user-1000.slice/session-1.scope
8:net_cls:/user.slice/user-1000.slice/session-1.scope
7:memory:/user.slice/user-1000.slice/session-1.scope
6:freezer:/user.slice/user-1000.slice/session-1.scope
5:devices:/user.slice/user-1000.slice/session-1.scope
4:cpuset:/user.slice/user-1000.slice/session-1.scope
3:cpuacct:/user.slice/user-1000.slice/session-1.scope
2:cpu:/user.slice/user-1000.slice/session-1.scope
1:blkio:/user.slice/user-1000.slice/session-1.scope
[snip]
Can you tell me what your systemd-shim and cgmanager versions are?
Thanks a ton,
--
Cameron Norman
Bug#763954: apt: Mention when removing a package would cause another package's Recommends: to not be satisfied
Package: apt Severity: wishlist Hello, I recently came across a situation where I wanted to use a Recommends: instead of a Depends: for some specific use cases (the recommended package had a lot of deps), but wanted to be extremely sure that the recommended package did not unwittingly removed (causing annoying bug reports because of partially degraded functionality). It would be great if users were told when a package is not just some randomly installed package with no dependencies, but instead something that another package uses, you know? Basically along side the These packages will be REMOVED type lists, something along the lines of These packages will not have their recommendations satisfied with the list of packages. Is this something that would be good UX-wise in your opinion? If it is an appropiate feature, any tips on where to look first to get it implemented? Thanks a ton, -- Cameron Norman
Bug#757348: systemd-shim: Re: Raise severity of bugs as requested.
On Thu, 18 Sep 2014 22:31:34 +0200 Andreas Henriksson andr...@fatal.se wrote: Control: severity 757348 grave I would disagree that this particular bug (CanSuspend, CanShutdown, CanHibernate, etc. being reported as false) is of a grave severity. These are my reasons: 1) I can not reproduce it. This means that the package is not affecting every (or even a majority) of users, and is not completely useless. 2) There is absolutely no chance of data loss here. 3) There is no security issues here (unlike the other bug you raised the priority of). The only item above that is questionable would be (1) I think. I am not perfect on what bug severities' qualifications are, so if the makes the package in question unusable bit is satisfied by it being unusable for only one or a few users, then I retract my disagreement. Otherwise, if you agree Andreas, please lower this back down to important. Thank you, -- Cameron Norman
Bug#757348: systemd-shim: logind sessions not being registered with lightdm
Hello guys, There is some info that may be helpful: 1) If you login on a console, is that session registered (use the bare `loginctl` command to list all registered sessions, or the last few lines of `dmesg`)? 2) What display managers are you using? Have you tried with any others and gotten different results? 3) Is your DE session also not registered with logind (again, use logind/dmesg to see)? 4) Can you paste the output of `grep pam_systemd /var/log/auth.log`? 5) Are there any error messages from logind in dmesg? Of course, versions of libpam-systemd, systemd, and systemd-shim are useful. For reference, the only errors that logind reports to me are that the user@ service was not started successfully, and the only issues I have are with the sessions not being cleared up when I log out. I have used gdm3, lightdm, and gnome to suspend/shutdown successfully. My systemd-shim version is 8-2, and systemd/libpam-systemd is 215-4. Thank you, -- Cameron
Bug#756076: Acknowledgement (does not cleanup sessions when user logs out: No such interface 'org.freedesktop.systemd1.Scope')
On Thu, 11 Sep 2014 02:42:52 +0200 Michael Biebl bi...@debian.org wrote: reopen 756076 thanks While the error message is gone, the actual cleanup doesn't seem to work properly. When logging out, the logind session persists and remains in state closing: While this is true, it seems that device permissions are actually removed correctly. I determined this by: Logging in on tty6. Successfully using the sound card (with aplay, if that matters). Logging out from tty6. Logging in with the same user via ssh. Unsuccessfully using the sound card (aplay errors, saying that it can not find the card). Using start-stop-daemon to change to the user in question (does not go through PAM) Same error as with ssh I did not log in with that user at all before that time, and no open sessions existed on the system for that user except for those specified. Is there anything wrong with that method, and can you reproduce my results Michael? So what other risks are there if it is stuck in this closing state (assuming that I did not make a mistake in my above determination)? On the subject of fixing the issue, my only guess is that since the user@.service start failed, it might be getting hung up on shutdown, you know? I can not come up with anything better, since nothing stuck out on a short peruse of systemd/src/login/, and logind is not emitting any other error messages for me (are you getting anything else, Michael). So again, I would appreciate if we determined for sure if this bug is causing security issues or other large concerns. Thanks a ton, -- Cameron
Bug#739605: pm-utils: sudo pm-hibernate does hibernate but when trying to wake it reboots
On Thu, 20 Feb 2014 08:37:26 -0300 Mariano Ignacio Baragiola mari...@baragiola.com.ar wrote: Package: pm-utils Version: 1.4.1-13 Severity: grave Justification: causes non-serious data loss When trying to pm-hibernate being root, there's no problem. But when you sudo it, it hibernates; but then when trying to wake it crashes and reboots. Is there any sort of error message? What size swap do you have, how much RAM, and do you use a swap file or swap partition? Best regards, -- Cameron Norman
Bug#746578: Reasons to keep systemd-sysv as the first alternative
On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote: I'm pulling a quote from the bottom of Steve's mail to the top, to call attention to a new and critical point that I didn't see raised anywhere in the debian-devel discussion: On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek vor...@debian.org wrote: If we decide that init *should* be automatically changed on upgrade, then (Which I'm assuming from your footnote [1] that you *are* in favor of?) the ordering of the dependencies on libpam-systemd is immaterial except in the specific case that someone has upgraded to (or newly installed) jessie, selected an init system other than the default, and subsequently installed a desktop environment on a system that didn't initially have one. In this case, installing the DE *definitely* should not override the user's explicit selection of init system. *This* is a point that I haven't seen raised in the entire previous discussion on debian-devel, and I think it's a completely valid point. Personally, in this case, I'd argue that the desirable dependency (which we can't easily express) would be sysvinit-core ? systemd-shim : systemd-sysv. To be more precise, it would be !systemd-sysv ? systemd-shim : systemd-sysv so that other alternate inits are treated equally. As you hopefully can see, this can be condensed to systemd-sysv ? systemd-sysv : systemd-shim AKA systemd-shim | systemd-sysv :) One question: if `init` and `libpam-systemd` (with the inversed dependency) are installed simultaneously on a system with only sysvinit installed (i.e. Wheezy), apt would know that systemd-sysv is going to be installed (to satisfy init package's dependency) and would not install systemd-shim, correct? Although, according to Steve that would be simply an aesthetic issue, as systemd-shim does not impede operation of systemd as init. Best regards, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746578: More systemd fallout :-/
On Thu, Sep 18, 2014 at 11:59 AM, Josh Triplett j...@joshtriplett.org wrote: On Wed, 17 Sep 2014 15:34:48 +0100 Ian Jackson ijack...@chiark.greenend.org.uk wrote: In #746578, a user requests that the dependency from libpam-systemd to systemd be changed from systemd-sysv | systemd-shim to systemd-shim | systemd-sysv The maintainers of libpam-systemd have rejected this change. I would like the TC to set out the applicable principle(s), and overrule the maintainer in this case. As I understand it from reading the threads in the bug and on debian-devel, the effect of this would be: * New jessie installations would still get systemd. * squeeze-jessie upgrades which are not already using systemd would not be switched silently to systemd but would use systemd-shim instead. * Attempts to upgrade non-systemd systems in some other circumstances would no longer switch silently to systemd. The latter two points are not actually accurate. I just tested this by installing a wheezy minbase chroot using debootstrap and upgrading it to jessie. The list of packages installed as part of the wheezy minbase chroot: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts insserv libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libdb5.1 libgcc1 liblocale-gettext-perl liblzma5 libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libtinfo5 libusb-0.1-4 libustr-1.0-1 libuuid1 login lsb-base mawk mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux xz-utils zlib1g The upgrade: /# apt-get --no-install-recommends dist-upgrade Reading package lists... Done Building dependency tree... Done Calculating upgrade... Done The following NEW packages will be installed: acl adduser dmsetup gcc-4.9-base init libaudit-common libaudit1 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libgcrypt11 libgcrypt20 libgpg-error0 libkmod2 libncursesw5 libpcre3 libprocps3 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libwrap0 procps startpar systemd systemd-sysv udev The following packages will be upgraded: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libgcc1 liblocale-gettext-perl libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo5 libusb-0.1-4 libuuid1 login lsb-base mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux zlib1g 70 upgraded, 31 newly installed, 0 to remove and 0 not upgraded. Need to get 33.7 MB of archives. After this operation, 27.5 MB of additional disk space will be used. (Including recommends would install a few additional packages, including libpam-systemd because systemd Recommends it, but I used --no-install-recommends to prove that libpam-systemd was *not* the driver of the transition, nor was it involved in the upgrade.) This transition is driven not by libpam-systemd as suggested in this bug report, but by the sysvinit transitional package (which depends on init) and by moving the Essential: yes bit from sysvinit to init. Note that that transition was coordinated between the sysvinit, systemd, and upstart maintainers, and that the init package also supports sysvinit and upstart. If the transition is already happening, why have the dependency be like it is anyway? User's systems will be switched regardless, so there is no use in having a second pass at changing the init. Also, although the squeeze/wheezy - jessie bit Ian wrote seems to be incorrect, his last point still stands: on a jessie minbase (with init shifted to !systemd-sysv), if you install libpam-systemd, your init is changed back to systemd. So the systemd-sysv | systemd-shim bit is either pointless and redundant (upgrading to Jessie) or actively disruptive (installation of libpam-systemd on jessie+ systems). Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759833: calf: FTBFS: ./.libs/calf.so: undefined reference to `cairo_set_line_width'
Hey, so I figured out the problem I think. The calf.so plugin eventually calls cairo functions, but the depenendency is not properly defined in src/Makefile.am, as you can see from this line: calf_la_LIBADD = $(FLUIDSYNTH_DEPS_LIBS) $(GLIB_DEPS_LIBS) $(FFTW3_DEPS_LIBS) -lfftw3f which can be changed like so to make the build succeed: calf_la_LIBADD = $(GUI_DEPS_LIBS) $(FLUIDSYNTH_DEPS_LIBS) $(GLIB_DEPS_LIBS) $(FFTW3_DEPS_LIBS) -lfftw3f I do not think that those GUI dependencies are meant to be unconditionally required by the plugin, however, so perhaps something needs to be done to not make those calls to the cairo functions? Best regards, -- Cameron Norman
Bug#759833: calf: FTBFS: ./.libs/calf.so: undefined reference to `cairo_set_line_width'
Looks like this has been fixed in the current code, so a new upload should fix this: https://sourceforge.net/p/calf/bugs/65/ On Sat, Sep 13, 2014 at 12:26 PM, Cameron Norman camerontnor...@gmail.com wrote: Hey, so I figured out the problem I think. The calf.so plugin eventually calls cairo functions, but the depenendency is not properly defined in src/Makefile.am, as you can see from this line: calf_la_LIBADD = $(FLUIDSYNTH_DEPS_LIBS) $(GLIB_DEPS_LIBS) $(FFTW3_DEPS_LIBS) -lfftw3f which can be changed like so to make the build succeed: calf_la_LIBADD = $(GUI_DEPS_LIBS) $(FLUIDSYNTH_DEPS_LIBS) $(GLIB_DEPS_LIBS) $(FFTW3_DEPS_LIBS) -lfftw3f I do not think that those GUI dependencies are meant to be unconditionally required by the plugin, however, so perhaps something needs to be done to not make those calls to the cairo functions? Best regards, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756903: systemd: Boot hangs if filesystems unavailable
On Sun, 03 Aug 2014 22:08:59 +0200 Michael Biebl bi...@debian.org wrote: Control: -1 important Am 03.08.2014 12:21, schrieb Tony Green: Since my machine recently updated to using systemd, I have experienced a number of occasions when it would just hang at a blank screen when booting. After some searching I managed to work out how to get back to having verbose output during the boot process, which showed me that the system was refusing to initialise because filesystems specified in /etc/fstab were not available (either NFS filesystems, when my network was playing up, or a USB external drive which had not spun up fast enough). It seems that systemd regards ANY missing filesystem as being a fatal error, whether or not that filesystem is actually essential to the boot process. Although this is certainly valid if vital partitions such as / or /usr can't be mounted, it's unhelpful for NFS or external partitions. [snip] As a workaround, I have been able to ensure my system boots OK if any of these filesystems can't be mounted by adding noauto to /etc/fstab and then mounting the filesystems via /etc/rc.local instead. The better alternative in your case (i.e. mount if available but don't fail otherwise) is to mark the file systems as nofail. See man fstab. With mountall/Upstart, there is a nobootwait option supported. I believe the behavior is similar to nofail, except that mountall will emit the filesystem event before finishing mounting the filesystem as well as not GAF about success/failure. Do you know if systemd supports this? To implement this in systemd I believe you would make the generator for mount units from fstab not add Before=local-fs.target or Before=remote-fs.target if the nobootwait option is used. This solves the problem that systemd does not know which filesystems are essential or not. Best wishes, -- Cameron Norman
Bug#756903: systemd: Boot hangs if filesystems unavailable
El dom, 3 de ago 2014 a las 3:44 , Marco d'Itri m...@linux.it escribió: On Aug 04, Cameron Norman camerontnor...@gmail.com wrote: With mountall/Upstart, there is a nobootwait option supported. I believe the behavior is similar to nofail, except that mountall will emit the filesystem event before finishing mounting the filesystem as well as not GAF about success/failure. Do you know if systemd supports this? To implement this in systemd I believe you would make the generator for mount units from fstab not add Before=local-fs.target or Before=remote-fs.target if the nobootwait option is used. This solves the problem that systemd does not know which filesystems are essential or not. Such an option would not be the default, and if you can change your configuration to use it then you can more easily fix your fstab as well. What do you mean by fix your fstab? Adding this option is even beneficial if there is nothing wrong with the fstab, as services can be started before non-essential fs's are up. Thanks, -- Cameron
Bug#754793: RFS: mosquitto/1.2.1-2 RC
El vie, 1 de ago 2014 a las 10:32 , Eriberto Mota eribe...@debian.org escribió: 6. There is a .conf in /etc/init. What is this? That would be an Upstart job. Best, -- Cameron Norman
Bug#755950: postgresql-common: Add Upstart jobs
Package: postgresql-common Version: 159 Severity: wishlist Tags: patch Dear Maintainer, I just saw an update that gave me some systemd services. As I had trouble converting the init scripts to Upstart jobs in the past, I was interested and took a look. The new option in pg_ctlcluster, --stdlog, has allowed me to complete my Upstart jobs, which are attached. I would greatly appreciate if you included them in the next upload of your package. Best wishes, -- Cameron Norman -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postgresql-common depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii lsb-base 4.1+Debian13 ii postgresql-client-common 159 ii procps 1:3.3.9-7 ii ssl-cert 1.0.34 ii ucf 3.0030 Versions of packages postgresql-common recommends: ii logrotate 3.8.7-1 postgresql-common suggests no packages. -- Configuration Files: /etc/postgresql-common/createcluster.conf changed [not included] -- debconf information excluded description PostgreSQL - RDBMS server (cluster) author Cameron Norman camerontnor...@gmail.com usage VERSION - version of postgres, \ CLUSTER - cluster within the version. instance $VERSION-$CLUSTER export VERSION export CLUSTER stop on (stop-postgresql-clusters VERSION=$VERSION or deconfiguring-networking or unmounting-filesystem or runlevel [016]) pre-start exec rm -f /var/run/postgresql/$VERSION-$CLUSTER.pid normal exit 0 TERM INT respawn exec /usr/bin/pg_ctlcluster --foreground --stdlog $VERSION $CLUSTER start post-start script for t in $(seq 1 60); do sleep 0.25 test -e /var/run/postgresql/$VERSION-$CLUSTER.pid exit 0 done # None of the status calls succeeded echo Postgres cluster failed to start. stop; exit 1 end script kill timeout 15 pre-stop exec /usr/bin/pg_ctlcluster -m fast $VERSION $CLUSTER stop description PostgreSQL - RDBMS server start on runlevel [2345] stop on runlevel [!2345] pre-start script [ -r /usr/share/postgresql-common/init.d-functions ] || exit 0 . /usr/share/postgresql-common/init.d-functions get_versions # create socket directory if [ -d /var/run/postgresql ]; then chmod 2775 /var/run/postgresql else install -d -m 2775 -o postgres -g postgres /var/run/postgresql [ -x /sbin/restorecon ] restorecon -R /var/run/postgresql || true fi # Start version instances ret=0 for v in $versions; do initctl start postgresql-version VERSION=$v || ret=$? done exit $ret end script post-stop exec initctl emit stop-postgresql-versions description PostgreSQL - RDBMS server (version) author Cameron Norman camerontnor...@gmail.com stop on (stop-postgresql-versions or deconfiguring-networking or unmounting-filesystem or runlevel [016]) instance $VERSION usage VERSION - version of PostgreSQL with corresponding config and binary export VERSION pre-start script [ -d /etc/postgresql/$VERSION ] || exit 0 [ $(ls /etc/postgresql/$VERSION) ] || exit 0 [ -x /usr/lib/postgresql/$VERSION/bin/postmaster ] || exit 0 ret=0 for c in /etc/postgresql/$VERSION/*; do [ -e $c/postgresql.conf ] || continue name=$(basename $c) # evaluate start.conf if [ -e $c/start.conf ]; then start=$(sed 's/#.*$//; /^[[:space:]]*$/d; s/^\s*//; s/\s*$//' $c/start.conf) else start=auto fi [ $start = auto ] || continue initctl start postgresql-cluster VERSION=$VERSION CLUSTER=$name || ret=$? done exit $ret end script post-stop exec initctl emit stop-postgresql-clusters VERSION=$VERSION
Bug#755960: postfix: separate configure_instance function in init script to a libexec helper
Package: postfix
Severity: wishlist
This would make the systemd conversion (as well as any other init
system or process supervisor) a lot easier. I have attached a file,
configure-instance.sh, that can be shipped in /usr/lib/postfix, and an
init script diff that takes advantage of the configure-instance script
instead of its own internal function.
Thanks,
--
Cameron Norman
26,30d25
# Defaults - don't touch, edit /etc/default/postfix
SYNC_CHROOT=y
test -f /etc/default/postfix . /etc/default/postfix
59,182d53
configure_instance() {
INSTANCE=$1
if [ X$INSTANCE = X ]; then
POSTCONF=postconf
else
POSTCONF=postmulti -i $INSTANCE -x postconf
fi
# if you set myorigin to 'ubuntu.com' or 'debian.org', it's wrong, and annoys the admins of
# those domains. See also sender_canonical_maps.
MYORIGIN=$($POSTCONF -h myorigin | tr 'A-Z' 'a-z')
if [ X${MYORIGIN#/} != X${MYORIGIN} ]; then
MYORIGIN=$(tr 'A-Z' 'a-z' $MYORIGIN)
fi
if [ X$MYORIGIN = Xubuntu.com ] || [ X$MYORIGIN = Xdebian.org ]; then
log_failure_msg Invalid \$myorigin ($MYORIGIN), refusing to start
log_end_msg 1
exit 1
fi
config_dir=$($POSTCONF -h config_directory)
# see if anything is running chrooted.
NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}' ${config_dir}/master.cf)
if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
# Make sure that the chroot environment is set up correctly.
oldumask=$(umask)
umask 022
queue_dir=$($POSTCONF -h queue_directory)
cd $queue_dir
# copy the CA path if specified
ca_path=$($POSTCONF -h smtp_tls_CApath)
case $ca_path in
'') :;; # no ca_path
$queue_dir/*) :;; # skip stuff already in chroot, (and to make vim syntax happy: */)
*)
if test -d $ca_path; then
dest_dir=$queue_dir/${ca_path#/}
# strip any/all trailing /
while [ ${dest_dir%/} != ${dest_dir} ]; do
dest_dir=${dest_dir%/}
done
new=0
if test -d $dest_dir; then
# write to a new directory ...
dest_dir=${dest_dir}.NEW
new=1
fi
mkdir --parent ${dest_dir}
# handle files in subdirectories
(cd $ca_path find . -name '*.pem' -print0 | cpio -0pdL --quiet $dest_dir) 2/dev/null ||
(log_failure_msg failure copying certificates; exit 1)
c_rehash $dest_dir /dev/null 21
if [ $new = 1 ]; then
# and replace the old directory
rm -rf ${dest_dir%.NEW}
mv $dest_dir ${dest_dir%.NEW}
fi
fi
;;
esac
# if there is a CA file, copy it
ca_file=$($POSTCONF -h smtp_tls_CAfile)
case $ca_file in
$queue_dir/*) :;; # skip stuff already in chroot
'') # no ca_file
# or copy the bundle to preserve functionality
ca_bundle=/etc/ssl/certs/ca-certificates.crt
if [ -f $ca_bundle ]; then
mkdir --parent $queue_dir/${ca_bundle%/*}
cp -L $ca_bundle $queue_dir/${ca_bundle%/*}
fi
;;
*)
if test -f $ca_file; then
dest_dir=$queue_dir/${ca_path#/}
mkdir --parent $dest_dir
cp -L $ca_file $dest_dir
fi
;;
esac
# if we're using unix:passwd.byname, then we need to add etc/passwd.
local_maps=$($POSTCONF -h local_recipient_maps)
if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ]; then
sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
chmod a+r etc/passwd
fi
fi
FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
etc/host.conf etc/nsswitch.conf etc/nss_mdns.config
for file in $FILES; do
[ -d ${file%/*} ] || mkdir -p ${file%/*}
if [ -f /${file} ]; then rm -f ${file} cp /${file} ${file}; fi
if [ -f ${file} ]; then chmod a+rX ${file}; fi
done
# ldaps needs this. debian bug 572841
(echo /dev/random; echo /dev/urandom) | cpio -pdL --quiet . 2/dev/null || true
rm -f usr/lib/zoneinfo/localtime
mkdir -p usr/lib/zoneinfo
ln -sf /etc/localtime usr/lib/zoneinfo/localtime
LIBLIST=$(for name in gcc_s nss resolv; do
for f in /lib/*/lib${name}*.so* /lib/lib${name}*.so*; do
if [ -f $f ]; then echo ${f#/}; fi;
done;
done)
if [ -n $LIBLIST ]; then
for f in $LIBLIST; do
rm -f $f
done
tar cf - -C / $LIBLIST 2/dev/null |tar xf -
fi
umask $oldumask
fi
}
191c62
configure_instance $INSTANCE
---
/usr/lib/postfix/configure-instance.sh $INSTANCE
configure-instance.sh
Description: application/shellscript
Bug#715188: systemd service files (new and improved :)
Hola, I have attached a couple new systemd service files. These are different in that: they implement reload correctly, they are instanced, they conflict with exim4.service (not exim.service), and they use /usr/lib/postfix/configure-instance.sh (and thus depend on BTS #755960). Hopefully they can now be included (after #755960 of course). Cheers, -- Cameron Norman
Bug#715188: Actually attaching the systemd service files :)
I always do this...
[Unit]
Description=Postfix Mail Transport Agent
After=network.target
Conflicts=sendmail.service exim4.service
ConditionPathExists=/etc/postfix/main.cf
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c for i in $(postmulti -l -a | awk '($3==y) { print
$1}'); do systemctl start postfix@$i.service; done
ExecReload=/usr/sbin/postfix quiet-reload
[Install]
WantedBy=multi-user.target
[Unit]
Description=Postfix Mail Transport Agent (instance %i)
PartOf=postfix.service
[Service]
Type=forking
GuessMainPID=no
ExecStartPre=/usr/lib/postfix/configure-instance.sh
ExecStart=/usr/sbin/postmulti -i %i -x /usr/sbin/postfix quiet-quick-start
ExecStop=/usr/sbin/postmulti -i %i -x /usr/sbin/postfix quiet-stop
[Install]
WantedBy=multi-user.target
Bug#741573: Two menu systems
On Thursday, June 26, 2014, Colin Watson cjwat...@debian.org wrote: On Thu, Jun 26, 2014 at 05:50:38PM +0100, Ian Jackson wrote: I see Keith has committed a draft to git. As discussed, I disagree with this approach. This amounts to nonconsensually abolishing someone's work when it is still being maintained, and the global cost is minimal. My feelings on this draft are mixed. On the one hand, I happen to agree with the position that the categorisation system in .desktop files (and X-Show-In etc.) should be able to cover the bulk of the practical requirements of the trad menu system: * There's no reason that has a .desktop file should imply shows up in modern desktop environments, and so I think that the question of coverage is to some extent a red herring; the systems have different coverage because they've always had different coverage, not because the .desktop format is inherently unable to meet the needs of trad menu consumers. * We might have to look into the presentation of menu item names, although Name / GenericName offers some support for the different names that people are likely to want, and if all else fails the .desktop file format does have extension mechanisms. I would be very happy to see additional .desktop files being added to packages with suitable categorisation such that they don't need to interfere with how the maintainers of modern DEs want to present their desktops, so that menu-xdg (or similar) can supplant the current menu system with negligible loss of functionality for users of trad menus. I think this would make a great project for people interested in unifying the two worlds a bit more, which doesn't even have to step on anyone's toes. Perhaps for instance it would be a good project for Debian's Google Summer of Code efforts. On the other hand, Keith's draft seems highly aspirational to me. While it seems to me to be broadly the right kind of long-term technical direction, there is an awful lot of work in there for people who want something like trad menus which is being glossed over. So, I prefer Ian's position in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the purposes of how the policy text should remain for the time being, and in terms of the philosophy of not ripping out work from under people's feet. I disagree with its argument that it follows directly from the two sets of competing requirements that we must have these two file formats. I prefer Keith's position as a long-term direction, but agree with Ian that it is lacking an awful lot of transitional thought, and feel that it has a lot of things-should-be-done without it being clear who will do them. Thirdly, IMO the resolution needs to acknowledge (in the whereas section) that consuming a trad Debian menu entry is simpler and easier than consuming a .desktop file. I think this is really overstated. .desktop files are in a long-standing and popular basic file format for which plenty of parsing libraries in various languages exist, so you can get to the point of having a parsed data structure trivially. In contrast the menu entry format is a bespoke thing. While the .desktop file format has more bells and whistles, many of them can be ignored if you don't support whatever it is. I don't think it's worth emphasising ease of consumption either way. I believe the major aspect of .desktop files that makes them harder is the icon handling. Perhaps debian policy should instruct that a certain icon size must always be available in a particular format (e.g. 32x32 png) so that WMs do not have to handle so many corner cases in that area. Best, -- Cameron Norman
Bug#749384: gutenprint: No Epson Stylus Photo R220 or R200 drivers
Package: printer-driver-gutenprint Version: 5.2.10~pre2-2 The gutenprint website says that they still support these two models, but the package only ships drivers for the R240 and up. Is this a regression, or purposeful? Thank you, -- Cameron Norman
Bug#749400: dh_installinit: disable init scripts on removal of package
Package: debhelper Greetings, It would be much cleaner to disable init scripts when the package is uninstalled, so that a bunch of shell scripts that just run [ -x $DAEMON ] || exit 0 are not slowing down the boot. Additionally, this causes problems for Upstart, as the starting event is emitted before the job can tell if its daemon is installed or not. It also poses a problem for socket activation with Upstart, as the upstart-socket-bridge will create the socket for the job even if the daemon is not installed. I think it would just be overall cleaner to disable the init configuration on removal of the package with a update-rc.d disable $daemon. Thank you, -- Cameron Norman
Bug#749400: Acknowledgement (dh_installinit: disable init scripts on removal of package)
I have attached a diff for this that performs the action in postrm. Another problem I have come across with leaving them enabled is that packages with identical binary names do not play nice if you have not purged one or the other. Both init scripts are run and try to execute the daemon in different ways. One example is nscd and unscd. Best, -- Cameron Norman diff --git a/autoscripts/postrm-init b/autoscripts/postrm-init index 6f5bb09..b5cecb8 100644 --- a/autoscripts/postrm-init +++ b/autoscripts/postrm-init @@ -1,3 +1,5 @@ +update-rc.d #SCRIPT# disable /dev/null + if [ $1 = purge ] ; then update-rc.d #SCRIPT# remove /dev/null fi
Bug#749400: [debhelper-devel] Bug#749400: Acknowledgement (dh_installinit: disable init scripts on removal of package)
El Mon, 26 de May 2014 a las 3:22 PM, Joey Hess jo...@debian.org escribió: Cameron Norman wrote: diff --git a/autoscripts/postrm-init b/autoscripts/postrm-init index 6f5bb09..b5cecb8 100644 --- a/autoscripts/postrm-init +++ b/autoscripts/postrm-init @@ -1,3 +1,5 @@ +update-rc.d #SCRIPT# disable /dev/null + if [ $1 = purge ] ; then update-rc.d #SCRIPT# remove /dev/null fi This would leave a daemon's links disabled while a package was being upgraded. Which could result in it not starting if the system were rebooted at that point. It would also remain disabled if the upgrade failed. Would the package's binary also not be installed in those situations, or am I mistaken? Perhaps there is only a small window where this can cause problems, if the upgrade failed in the postinst step before dh_installinit. debhelper is simply copying from policy 9.3.3.1 here. I am very unlikely to make a change away from what policy says to do. I see. I will have to go through that process then. Thanks for the quick reply, -- Cameron
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Tue, 6 de May 2014 a las 7:54 PM, Russ Allbery r...@debian.org escribió: Faidon Liambotis parav...@debian.org writes: I haven't gotten any such bug reports, so this is still theoretical, but I think I'd simply reject anything more complicated than simply adding a debian/foo.upstart file to the tree, including adding (and maintaining) hacks or modifying existing SysV init scripts. I certainly won't work on adding an upstart job to my packages myself. The hacks we're talking about here are pretty minimal: just three lines in the init script that we're mentioning. I think it's pretty straightforward and think that maintainers should just add that support. In addition, as has been mentioned, they will soon be unnecessary, as Dimitri Ledkov is working to put the functionality into a init-functions.d hook. [snippity snip] 3 Hope that stuff clears up! Stress is very stressful, and that is never good. I do not know your taste in music, but maybe you will like this: https://www.youtube.com/watch?v=tNygDLi9gb4. Top of the day, -- Cameron Norman
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Tue, 6 de May 2014 a las 8:41 PM, Bdale Garbee bd...@gag.com escribió: Russ Allbery r...@debian.org writes: I can see your point that the future of upstart is possibly unclear, but my feeling is that if anyone filed a bug against a package requesting upstart support, that's sufficient indication of interest to merge upstart support patches, including this sort of minor modification of the init script. I agree. From your other message I was under the impression that you thought it was ok to remove Upstart support, but now you agree that if there was interest, then it should be kept (as long as it does not cause issues). Is the maintainer supposed to accept the support then remove it a few months later :) ? Are those interested in Upstart support supposed to hawk over packages and never get a wink of sleep? I do not think that is what you want, but the wording of your other message (that you would not be surprised if upstart support was removed) seems like it is. Would you mind clarifying a little? Thanks y buenos noches, -- Cameron Norman
