Bug#986619: linux-image-5.10.0-5-amd64: bonding broken on 5.10.0-5 (5.10.26)
Package: src:linux Version: 5.10.26-1 Severity: normal Dear Maintainer, I have a bonding setup as follows: % head -99 /etc/systemd/network/* ==> /etc/systemd/network/bond0.netdev <== [NetDev] Name=bond0 Kind=bond [Bond] Mode=active-backup PrimaryReselectPolicy=always MIIMonitorSec=1s ==> /etc/systemd/network/bond0.network <== [Match] Name=bond0 [Network] DHCP=yes LLMNR=false ==> /etc/systemd/network/wired.network <== [Match] Name=enp* [Link] RequiredForOnline=no [Network] Bond=bond0 PrimarySlave=true ==> /etc/systemd/network/wireless.network <== [Match] Name=wlan* [Link] RequiredForOnline=no [Network] Bond=bond0 on 5.10.0-4, this works fine. On 5.10.0-5, networkd is able to get an IPv4 address from DHCP on bond0, but not v6, and not even ping responses arrive from my gateway. The underlying devices work fine on both kernel versions. I believe this is fixed in 5.10.27 with commit 36478a9ec5afd4efd031527d0371bf8f61e5aa91; see https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.27 Please update to 5.10.27 or backport the patch in question. -- Package-specific info: ** Kernel log: boot messages should be attached -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.10.0-5-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.140 ii kmod28-1 ii linux-base 4.6 Versions of packages linux-image-5.10.0-5-amd64 recommends: ii apparmor 2.13.6-10 ii firmware-linux-free 20200122-1 Versions of packages linux-image-5.10.0-5-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3 ii grub-efi-amd64 2.04-17 pn linux-doc-5.10 Versions of packages linux-image-5.10.0-5-amd64 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20210315-2 pn firmware-libertas pn firmware-linux-nonfree ii firmware-misc-nonfree 20210315-2 pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information -- Lauri Tirkkonen | lotheac @ IRCnet
Bug#986281: bmake: please ship bsd.*.mk symlinks for bmake mk files
Package: bmake Version: 20200710-11 Severity: normal Dear Maintainer, in the current default configuration of the Debian package, upstream bmake files are used, but unlike installation of bmake from source, symlinks from bsd.*.mk to *.mk are not present in the default mk-files directory. My use case is simple programs using bsd.prog.mk, which are meant to succeed building with the same Makefile on different BSDs as well as non-BSD systems with bmake, and those programs don't care much about which brand of mk-files are used as long as the simple use case is supported. Since the symlinks are not present, .include with 'bmake' fails. Please ship the bsd.*.mk symlinks in /usr/share/bmake/mk-bmake. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/32 CPU threads) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bmake depends on: ii libc6 2.31-11 bmake recommends no packages. bmake suggests no packages. -- no debconf information -- Lauri Tirkkonen | lotheac @ IRCnet
Bug#876103: systemd-nspawn: --read-only is broken
Hi, On Sun, Dec 03 2017 13:47:29 +0100, Michael Biebl wrote: > > There is an upstream fix for this in > > https://github.com/systemd/systemd/pull/4693 -- > > acbbf69b718260755a5dff60dd68ba239ac0d61b is the commit that actually > > fixes read-only containers, but it requires two other commits to apply > > cleanly. I applied the following sequence to systemd-container on > > stretch: > > > > https://github.com/systemd/systemd/commit/bdb4e0cb646ff33ecbb1cf4b502870f84bf4016d > > https://github.com/systemd/systemd/commit/4f086aab52812472a24c9b8b627589880a38696e > > https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b > > > > and it solved my problem. Could you backport these patches to stretch? > > > > Those patches looks a bit invasive for a stretch stable upload. > But we do provide updated systemd versions with this fix via > stretch-backports: > https://packages.debian.org/source/stable-backports/systemd > > Would that be sufficient for your case? It turned out that we needed a couple other patches for systemd-container, including one yet to be released, so for our case it's sufficient to do nothing since we now use our own systemd-container package :) However, I don't think the patches I listed are that invasive -- note that they only affect the systemd-nspawn binary. Anyone else having a problem with --read-only can move to the backports package, yes, but we explicitly did not want to upgrade all of systemd just to get a few patches to nspawn.
Bug#876103: systemd-nspawn: --read-only is broken
Package: systemd-container Version: 232-25+deb9u1 Severity: normal Dear Maintainer, on stretch, 'systemd-nspawn --read-only' fails to start the container entirely. Trivial test case: # machinectl pull-tar https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz [ output omitted ] # systemd-nspawn -M xenial-server-cloudimg-amd64-root -- true # systemd-nspawn -M xenial-server-cloudimg-amd64-root --read-only -- true Spawning container xenial-server-cloudimg-amd64-root on /var/lib/machines/xenial-server-cloudimg-amd64-root. Press ^] three times within 1s to kill container. Failed to create directory /var/lib/machines/xenial-server-cloudimg-amd64-root/sys: Read-only file system (the first systemd-nspawn call is there to implicitly create some directories inside the container root that must exist for read-only to work) The expected behavior is that 'true' is executed in container and exit status 0 is returned; however, the container is not started and the exit status is 1. There is an upstream fix for this in https://github.com/systemd/systemd/pull/4693 -- acbbf69b718260755a5dff60dd68ba239ac0d61b is the commit that actually fixes read-only containers, but it requires two other commits to apply cleanly. I applied the following sequence to systemd-container on stretch: https://github.com/systemd/systemd/commit/bdb4e0cb646ff33ecbb1cf4b502870f84bf4016d https://github.com/systemd/systemd/commit/4f086aab52812472a24c9b8b627589880a38696e https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b and it solved my problem. Could you backport these patches to stretch? -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-container depends on: ii dbus 1.10.18-1 ii libacl1 2.2.52-3+b1 ii libblkid12.29.2-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u1 ii libcurl3-gnutls 7.52.1-5 ii libgcrypt20 1.7.6-2+deb9u2 ii libip4tc01.6.0+snapshot20161117-6 ii liblzma5 5.2.2-1.2+b1 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii systemd 232-25+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages systemd-container recommends: ii btrfs-progs4.7.3-1 ii libnss-mymachines 232-25+deb9u1 systemd-container suggests no packages. -- no debconf information
Bug#875602: lxc-execute is broken due to init.lxc.static not being static
Package: lxc Version: 1:2.0.7-2 Severity: normal Dear Maintainer, /usr/sbin/init.lxc.static is not a statically linked executable. So, depending on the the contents of the rootfs of the container being used, it may fail to run. For example, consider a 'wheezy' container running on stretch: # lxc-create -t debian -n wheezy -- -r wheezy [output omitted] # lxc-execute -n wheezy true /init.lxc.static: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory This seems to be an upstream issue that was fixed in https://github.com/lxc/lxc/commit/d04813f9b5d287dd49520f5afa8a9f6ce6378b09 - could you please backport this patch? -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lxc depends on: ii init-system-helpers 1.48 ii libapparmor1 2.11.0-3 ii libc62.24-11+deb9u1 ii libcap2 1:2.25-1 ii libgnutls30 3.5.8-5+deb9u2 ii liblxc1 1:2.0.7-2 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii lsb-base 9.20161125 ii python3 3.5.3-1 ii python3-lxc 1:2.0.7-2 Versions of packages lxc recommends: ii bridge-utils 1.5-13 ii debootstrap 1.0.89 ii dirmngr 2.1.18-6 ii dnsmasq-base 2.76-5+b1 ii gnupg 2.1.18-6 ii iptables 1.6.0+snapshot20161117-6 ii libpam-cgfs 2.0.7-1 ii lxcfs 2.0.7-1 ii openssl 1.1.0f-3 ii rsync 3.1.2-1 ii uidmap1:4.4-4.1 Versions of packages lxc suggests: pn apparmor pn btrfs-tools ii lvm2 2.02.168-2 -- no debconf information
Bug#752501: closed by Craig Small csm...@debian.org (Re: Bug#752501: procps: pgrep -lf no longer prints full command line in jessie)
I'd reply to Alfredo's mail but I don't seem to have received it, I can only see it in the bug tracker. They wrote: Please, read carefully bug report #526355. Previous behaviour is really confusing and poor even if it is Sun Solaris compatible. I have read the report and would instead make the argument that the original documentation was the confusing and poor part, not the behavior. I find the new behavior of -lf - where I potentially cannot find the search string I asked for in the output - very confusing, and I don't think it's a good idea to diverge from every other pgrep implementation here either (at least FreeBSD, Solaris, illumos, OpenBSD). On Tue, Mar 17 2015 11:54:13 +, Debian Bug Tracking System wrote: On Tue, Jun 24, 2014 at 11:18:29AM +0300, Lauri Tirkkonen wrote: 'pgrep -lf' no longer prints the full command line of matching processes. This is a regression since wheezy, and caused by the fix for #526355 (upstream commit f12277c74d591245767d77badb6bb6af91335656) This was intentional. It's still a regression. -- Lauri Tirkkonen | lotheac @ IRCnet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752501: procps: pgrep -lf no longer prints full command line in jessie
Package: procps Version: 1:3.3.9-5 Severity: normal Tags: upstream Dear Maintainer, 'pgrep -lf' no longer prints the full command line of matching processes. This is a regression since wheezy, and caused by the fix for #526355 (upstream commit f12277c74d591245767d77badb6bb6af91335656) Example: given a process with the command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 103:107 The expected behavior, and behavior in wheezy as well as Solaris and its derivatives is: % pgrep -lf ntpd.pid 6272 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 115:122 but in jessie: % pgrep -lf ntpd.pid 1687 ntpd Incidentally, the manual page for pgrep includes the following: STANDARDS pkill and pgrep were introduced in Sun's Solaris 7. This implementation is fully compatible. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages procps depends on: ii initscripts 2.88dsf-53.2 ii libc6 2.19-3 ii libncurses5 5.9+20140118-1 ii libncursesw5 5.9+20140118-1 ii libprocps31:3.3.9-5 ii libtinfo5 5.9+20140118-1 ii lsb-base 4.1+Debian13 Versions of packages procps recommends: ii psmisc 22.21-2 procps suggests no packages. -- no debconf information -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712177: xserver-xorg: crash on joystick input when using InputClass to set joysticks floating
Upon further investigation it appears this problem is not limited to joysticks; if I use MatchIsPointer instead of MatchIsJoystick, moving the mouse will crash X. -- Lauri Tirkkonen | lotheac @ IRCnet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708246: mpd in wheezy built without sidplay support
Package: mpd Version: 0.16.7-2+b1 Severity: normal Dear Maintainer, the mpd package in wheezy archive seems to be built without sidplay support. The build dependency to libsidplay2-dev does exist and I can build a working package (one that is linked against libsidplay2) without modifying the source by just 'apt-get source apt-get build-dep dkpg-buildpackage'. Reproduce: % apt-get install mpd/wheezy % mpd --version | fgrep sidplay Expected output: [sidplay] sid mus str prg P00 Actual output: (nothing) -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mpd depends on: ii adduser 3.113+nmu3 ii libao41.1.0-2 ii libasound21.0.25-4 ii libaudiofile1 0.3.4-2 ii libavahi-client3 0.6.31-2 ii libavahi-common3 0.6.31-2 ii libavahi-glib10.6.31-2 ii libavcodec53 6:0.8.6-1 ii libavformat53 6:0.8.6-1 ii libavutil51 6:0.8.6-1 ii libc6 2.13-38 ii libcurl3-gnutls 7.26.0-1+wheezy2 ii libfaad2 2.7-8 ii libflac8 1.2.1-6 ii libgcc1 1:4.7.2-5 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libid3tag00.15.1b-10 ii libjack0 [libjack-0.116] 1:0.121.3+20120418git75e3e20b-2.1 ii libmad0 0.15.1b-7 ii libmikmod23.1.12-5 ii libmms0 0.6.2-3 ii libmp3lame0 3.99.5+repack1-3 ii libmpcdec62:0.1~r459-4 ii libogg0 1.3.0-4 ii libpulse0 2.0-6.1 ii libsamplerate00.1.8-5 ii libshout3 2.2.2-8 ii libsqlite3-0 3.7.13-1+deb7u1 ii libstdc++64.7.2-5 ii libvorbis0a 1.3.2-1.3 ii libvorbisenc2 1.3.2-1.3 ii libvorbisfile31.3.2-1.3 ii libwavpack1 4.60.1-3 ii lsb-base 4.1+Debian8 ii zlib1g1:1.2.7.dfsg-13 mpd recommends no packages. Versions of packages mpd suggests: ii avahi-daemon 0.6.31-2 pn icecast2 none ii mpc [mpd-client] 0.22-1 ii pulseaudio2.0-6.1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708246: [Pkg-mpd-maintainers] Bug#708246: mpd in wheezy built without sidplay support
On Tue, May 14 2013 23:28:53 +0200, Florian Schlichting wrote: the build log for the wheezy version contains the following lines: checking for main in -lsidplay2... yes checking for main in -lresid-builder... yes checking for main in -lsidutils... no configure: WARNING: libresid-builder or libsidutils not found -- disabling sidplay decoder plugin This is no longer the case from 0.17-1 onwards, but since you say it works just fine for you when recompiling, I'd say it's probably due to a bug in a different package than mpd. On my machine, I had libresid-builder-dev installed, so I see the problem: perhaps the mpd build dependencies are insufficient after all. I don't think it's a bug elsewhere though; either the mpd binary gets built with sidplay support (and linked with libsidplay2) or it doesn't :) So things are fine in testing, but for wheezy, there's little I can do at this point. All I have to offer is a backport of the current testing version to wheezy-backports. Would that be of use to you? Personally I would be happy with this solution, but since mpd in wheezy ships with configuration that has commented-out examples on how to use the builtin sidplay plugin (and indeed has the build-dependency on libsidplay2), I would assume that it's supposed to be built with sidplay support there as well. If that is the case, it might be helpful to require the feature in mpd by adding the --enable-sidplay configure option. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708246: [Pkg-mpd-maintainers] Bug#708246: mpd in wheezy built without sidplay support
On Wed, May 15 2013 02:43:55 +0300, Lauri Tirkkonen wrote: On my machine, I had libresid-builder-dev installed, so I see the problem: perhaps the mpd build dependencies are insufficient after all. Hmm, actually, it seems that when building the test package I mentioned in the original report I had both libresid-builder-dev and libsidutils-dev installed. libsidutils-dev is not listed as a build dependency, so I guess that's the problem; without having it installed I get the same lines in the build log as you quoted. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698373: ifupdown: dhclient stops on error conditions, requiring (local) admin intervention
Package: ifupdown Version: 0.7.5 Severity: important Dear Maintainer, ifupdown runs dhclient with the '-1' option, presumably to block during startup scripts. In the event that configuration is successful, dhclient will daemonize and exit successfully, and ifupdown marks the interface configured. However, dhclient will exit if at any point in the future renewing the lease fails, and an administrator will have to manually ifup the affected interface (actually ifdown first, since ifupdown will still think the interface is up). I believe this is a regression since squeeze, and it looks like #694541 is caused by the same change. Steps to reproduce: /etc/network/interfaces: iface eth0 inet dhcp 1. While the dhcp server is reachable, 'ifup eth0'. The interface will be configured successfully, and dhclient will run in the background 2. Make the dhcp server unreachable (eg. remove cable or otherwise bring the NIC link down on the client, unless you have ifplugd or something else like it running) 3. Wait until the active lease expires 4. Observe that dhclient exits, removing addresses from the interface, and that ifupdown thinks the interface is still up I believe ifupdown assumes that the dhcp client will not exit, but the -1 command line option causes it to exit on any errors. There was a discussion about a very similar problem in bug #253472 (apparently related to a different dhcp client, or at least a different version). As noted in #694541, the change was apparently made to fix #420784, but this is a rather nasty side effect. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (100, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ifupdown depends on: ii dpkg 1.16.9 ii initscripts 2.88dsf-34 ii iproute 20120521-3 ii libc62.13-37 ii lsb-base 4.1+Debian8 ifupdown recommends no packages. Versions of packages ifupdown suggests: ii isc-dhcp-client [dhcp-client] 4.2.2.dfsg.1-5+deb70u2 ii net-tools 1.60-24.2 pn pppnone pn rdnssd none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698373: ifupdown: dhclient stops on error conditions, requiring (local) admin intervention
On Thu, Jan 17, 2013 at 9:17 PM, Andrew Shadura bugzi...@tut.by wrote: Hello, On Thu, 17 Jan 2013 19:18:55 +0200 Lauri Tirkkonen loth...@iki.fi wrote: ifupdown runs dhclient with the '-1' option, presumably to block during startup scripts. Not exactly. It was done to make the ifup process more consistent: if we get an address, we're up, if we don't — we know something's wrong. Okay, makes sense. In the event that configuration is successful, dhclient will daemonize and exit successfully, and ifupdown marks the interface configured. However, dhclient will exit if at any point in the future renewing the lease fails, and an administrator will have to manually ifup the affected interface (actually ifdown first, since ifupdown will still think the interface is up). I believe this is a regression since squeeze, and it looks like #694541 is caused by the same change. I believe this may be a bug in dhclient. At least -1 in my understanding was supposed to affect initial handshake only. Not necessarily, I think -1 might be meant for scenarios where something else is supposed to respawn dhclient if it stops. That's not the case with ifupdown, though. Not sure about this. I'd recommend to use ifplugd together with ifupdown in such a setup, which ensures interfaces are re-configured properly when the link goes down and up. That kind of works, but if the dhcp server is unreachable for some other reason than the client link being down (eg. actually being down :), it doesn't. As noted in #694541, the change was apparently made to fix #420784, but this is a rather nasty side effect. Yes, and I don't currently know how to fix this properly until some core parts of ifupdown are rewritten, which is not going to happen before the release. In the version which is soon to be uploaded if approved by the release team, I've added tryonce option to switch -1 off if needed. Ok, I guess that's an acceptable workaround. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673058: xserver-xorg-core 1.12: XI2 FocusOut events missing parent of focus'd window
Package: xserver-xorg-core Version: 2:1.11.4-1 Severity: normal Dear Maintainer, please apply the patches from https://bugs.freedesktop.org/show_bug.cgi?id=44079 to xserver-xorg-core in wheezy. Newer gtk breaks Xorg without them as per https://mail.gnome.org/archives/gtk-devel-list/2012-March/msg00017.html (should this be reported to the libgtk-3-0 package as well?) -- Package-specific info: Kernel version (/proc/version): --- Linux version 3.2.0-2-amd64 (Debian 3.2.16-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Mon Apr 30 05:20:23 UTC 2012 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xserver-xorg-core depends on: ii keyboard-configuration 1.76 ii libaudit0 1:1.7.18-1.1 ii libc6 2.13-32 ii libdrm2 2.4.33-1 ii libgcrypt11 1.5.0-3 ii libpciaccess0 0.13.1-2 ii libpixman-1-0 0.24.4-1 ii libselinux1 2.1.9-2 ii libudev0175-3.1 ii libxau6 1:1.0.7-1 ii libxdmcp6 1:1.1.1-1 ii libxfont1 1:1.4.5-2 ii udev175-3.1 ii xserver-common 2:1.11.4-1 Versions of packages xserver-xorg-core recommends: ii libgl1-mesa-dri 7.11.2-1 Versions of packages xserver-xorg-core suggests: ii xfonts-100dpi1:1.0.3 ii xfonts-75dpi 1:1.0.3 ii xfonts-scalable 1:1.0.3-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660847: libuser is built without ldap support
Package: libuser Version: 1:0.56.9.dfsg.1-1.2 Severity: normal libuser is packaged without ldap support (libuser_ldap.so is not present). Building requires headers from libldap2-dev and libsasl2-dev packages, and running configure with option '--with-ldap=/usr/include'. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (100, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libuser depends on: ii libc6 2.13-26 ii libglib2.0-0 2.30.2-6 ii libpam0g 1.1.3-7 ii libpopt0 1.16-3 ii libuser1 1:0.56.9.dfsg.1-1.2 libuser recommends no packages. libuser suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660847: libuser is built without ldap support
Package: libuser
Version: 1:0.56.9.dfsg.1-1.2
Followup-For: Bug #660847
The attached patch should solve this issue by building a separate
libuser1-ldap package that contains the desired ldap and sasl modules.
diff -Naur libuser-0.56.9.dfsg.1/debian/control libuser-0.56.9.dfsg.1-ldap/debian/control
--- libuser-0.56.9.dfsg.1/debian/control 2012-02-22 12:11:56.0 +0200
+++ libuser-0.56.9.dfsg.1-ldap/debian/control 2012-02-22 12:00:45.355865316 +0200
@@ -4,7 +4,8 @@
Maintainer: Ghe Rivero g...@debian.org
Build-Depends: debhelper (= 4.0.0), python-all-dev, pkg-config,
libglib2.0-dev, linuxdoc-tools, groff, libpam0g-dev, libpopt-dev,
- dpatch, autotools-dev, python-support (= 0.4), chrpath
+ dpatch, autotools-dev, python-support (= 0.4), chrpath,
+ libldap2-dev, libsasl2-dev
Standards-Version: 3.7.3
Homepage: https://fedorahosted.org/libuser/
@@ -37,6 +38,17 @@
and administering user and group accounts. The library uses pluggable
back-ends to interface to its data sources.
+Package: libuser1-ldap
+Architecture: any
+Depends: ${shlibs:Depends}, libuser1 (= ${binary:Version})
+Section: libs
+Description: user and group account administration library (shared LDAP library)
+ The libuser library implements a standardized interface for manipulating
+ and administering user and group accounts. The library uses pluggable
+ back-ends to interface to its data sources.
+ .
+ This package includes the libuser modules ldap and sasl.
+
Package: python-libuser
Architecture: any
Depends: ${shlibs:Depends}, ${python:Depends}
diff -Naur libuser-0.56.9.dfsg.1/debian/libuser1.install libuser-0.56.9.dfsg.1-ldap/debian/libuser1.install
--- libuser-0.56.9.dfsg.1/debian/libuser1.install 2012-02-22 12:11:56.0 +0200
+++ libuser-0.56.9.dfsg.1-ldap/debian/libuser1.install 2012-02-22 11:55:55.471177047 +0200
@@ -1,2 +1,3 @@
usr/lib/*.so.*
-usr/lib/libuser/*.so
\ No newline at end of file
+usr/lib/libuser/libuser_files.so
+usr/lib/libuser/libuser_shadow.so
diff -Naur libuser-0.56.9.dfsg.1/debian/libuser1-ldap.install libuser-0.56.9.dfsg.1-ldap/debian/libuser1-ldap.install
--- libuser-0.56.9.dfsg.1/debian/libuser1-ldap.install 1970-01-01 02:00:00.0 +0200
+++ libuser-0.56.9.dfsg.1-ldap/debian/libuser1-ldap.install 2012-02-22 12:05:20.316518586 +0200
@@ -0,0 +1,2 @@
+usr/lib/libuser/libuser_ldap.so
+usr/lib/libuser/libuser_sasldb.so
diff -Naur libuser-0.56.9.dfsg.1/debian/rules libuser-0.56.9.dfsg.1-ldap/debian/rules
--- libuser-0.56.9.dfsg.1/debian/rules 2012-02-22 12:11:56.0 +0200
+++ libuser-0.56.9.dfsg.1-ldap/debian/rules 2012-02-22 12:03:46.072294627 +0200
@@ -52,7 +52,7 @@
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info --sysconfdir=/etc\
- --with-python --disable-rpath
+ --with-python --disable-rpath --with-ldap --with-sasl
# build for pythonX.Y
PYTHON=python$* $(MAKE)
@@ -74,6 +74,8 @@
$(CURDIR)/debian/tmp/usr/lib/libuser.so.1.2.0 \
$(CURDIR)/debian/tmp/usr/lib/libuser/libuser_files.so \
$(CURDIR)/debian/tmp/usr/lib/libuser/libuser_shadow.so \
+ $(CURDIR)/debian/tmp/usr/lib/libuser/libuser_ldap.so \
+ $(CURDIR)/debian/tmp/usr/lib/libuser/libuser_sasldb.so \
$(CURDIR)/debian/tmp/usr/lib/python$*/site-packages/libusermodule.so
mkdir -p $(CURDIR)/debian/python-libuser/usr/lib/python$*/site-packages
cp $(CURDIR)/debian/tmp/usr/lib/python$*/site-packages/libusermodule.so \
