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#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#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#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#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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-rc-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#771501: 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#771501: 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#771501: 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#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-rc-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#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 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-rc-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
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#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-rc-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#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#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#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#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#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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742822: Bug#713135: startpar-bridge causes rc to hang with a variety of job types and situations
El Sun, 30 de Mar 2014 a las 1:22 PM, Steve Langasek vor...@debian.org escribió: Hi Cameron, On Sun, Mar 30, 2014 at 05:56:01PM -0007, Cameron Norman wrote: Problem probably is in startpar-bridge. Since last mail also samba-ad-dc service/job is affected. Both services upstart starts properly: Upstart starts those jobs properly *according to Upstart*. The problem here is that startpar has a different definition of starting properly, and a lot of different service semantics. But both jobs ends quickly after start what probably causes startpar waits like this: Exactly. binfmt-support is an apparent incompatibility. In Upstart, binfmt-support is a task. It runs once and is considered to be successfully run by Upstart. startpar has something different to say. Although startpar sees that the job has been run, it ignores that part because the job has also been stopped. So it considers the fact that the job is last stopped to mean that services that start after binfmt-support must not be started, when in reality, they can do so easily. I don't think this is accurate. The problem is almost certainly that the startpar-bridge events for binfmt-support are triggering while startpar is not running, causing startpar itself to be unaware that the binfmt-support job has ever started. Can startpar-upstart-inject just wait to inject the event until startpar is running then? Would that override what startpar reads from the Upstart job states when it first starts up? The startpar-bridge exists to pass information to startpar whenever an upstart job starts or stops. But when it starts up, startpar itself reads the current state of the upstart jobs so that it has an accurate view of those jobs that are already started or already stopped. The problem is that, with a 'task' job, already started is indistinguishable from already stopped. And since binfmt-support is 'start on filesystem', at best it races the initialization of startpar; at worst it always completes before startpar because you have network devices that are slow to initialize (holding up rc but not holding up binfmt-support). So the fix is to make the binfmt-support job not a task. binfmt-support is already fixed, but this rips a lot of flexibility away from Upstart jobs, which is honestly very dissatisfying. Another situation is where the daemon detects that it is not enabled and exits early. This is what I think is happening in samba-ad-dc. Although the startpar started init script would do the same thing, startpar ignores the init script's stop because that is just how startpar works! What does startpar do when an init script exits non-zero (indicating that the service did not start successfully)? That's effectively the error condition we're talking about here. If some other init script has a dependency on samba-ad-dc, and samba-ad-dc doesn't start, I think the only correct thing to do is to treat that as a permanent failure to satisfy the dependency and refuse to start any of the services that depend on it. But this doesn't seem to be implemented in startpar. But most scripts do provide for being disabled already, so it is probably better to allow the rest of the scripts to run, instead of halting the boot, and possibly making the system hang before a tty is even up (since rc never stops in these scenarios, the ttys do not ever start). Please note, btw, that startpar-bridge was always intended to be a temporary solution on the path to a full migration to upstart. Given that such a migration is now exceedingly unlikely to happen in Debian, I don't expect to be putting much effort into resolving bugs like this. Yeah, I do not expect much interest from you. This might cause pains for people switching back and forth between Upstart and systemd while Ubuntu transitions, but it is overall irrelevant for your interests. But if someone wanted to do so, the way to go about it would be to first ensure startpar would first do something sensible when a depended-on service doesn't start. (Of course, in practice lots of init scripts undermine this by exiting zero when configured not to start, but at least for upstart we could in principle handle this differently.) Steve, could you give your thoughts on how to go about improving this situation? Furthermore, could you point me to the startpar-upstart-inject source code? I could not find it in Upstart's or sysvinit util's source trees. In unstable, this has been moved to the 'startpar' package. It's also apparently been renamed, without discussion with me, to 'startpar-injector'... Petter, please revert this change of the startpar-bridge name. Upstart systems absolutely *must not* have two versions of the startpar bridge job installed on the system at the same time, this will cause busy loops between the two! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer
