Bug#1070498: marked as pending in libvirt
Control: tag -1 pending Hello, Bug #1070498 in libvirt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libvirt-team/libvirt/-/commit/13f1f61aacf4277b0496049fd2df78352b4c5c30 patches: Add backport/vsh-Don-t-init-history-in-cmdComplete.patch Fixes FTBFS. Closes: #1070498 (this message was generated automatically) -- Greetings https://bugs.debian.org/1070498
Bug#1068203: spectrwm: hard-coded dependency on pre-t64 library
On Tue, Apr 02, 2024 at 12:02:53AM +0200, Sebastian Ramacher wrote:
> On 2024-04-01 23:39:37 +0200, Andrea Bolognani wrote:
> > The problem with it, and the reason why a manual dependency is used
> > in that case, is that ${shlib:Depends} will not pick it up, since
> > it's dlopen()ed rather than linked against.
> >
> > Do you have any suggestions on how to handle this in a way that plays
> > well with the 64-bit time_t transition?
>
> You could derive it from the the dependencies of libxt-dev during the
> build or for the time being simply change the dependency based on the
> rename of the libxt6 -- provided that spectrwm is compatible with the
> new ABI.
I just created [1] which should take care of the issue. It would be
nice if you could take a look.
To be honest, I haven't followed the 64-bit time_t transition very
closely. Do I understand correctly that the SONAME has been changed
without renaming the files on disk at the same time? That feels kinda
weird, but I guess it has the nice side-effect of not breaking [2],
so that's good :)
I also see that libxt6t64 Provides: libxt6, so I'm not sure why the
dependency on the old name would be a problem? Wasn't that introduced
specifically to take care of this sort of things?
[1] https://salsa.debian.org/debian/spectrwm/-/merge_requests/7
[2]
https://salsa.debian.org/debian/spectrwm/-/blob/debian/latest/debian/patches/debian/Adapt-libswmhack.patch#L71-72
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
Bug#1068203: spectrwm: hard-coded dependency on pre-t64 library
On Mon, Apr 01, 2024 at 10:37:03PM +0200, Sebastian Ramacher wrote:
> Source: spectrwm
> Version: 3.5.1-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
>
> spectrwm builds a packages with a hard-coded dependency on a library
> package involved in the time_t 64 transition. This dependency needs to
> be updated.
It would be useful if you could be more specific. I guess you're
talking about the dependency on libxt6?
The problem with it, and the reason why a manual dependency is used
in that case, is that ${shlib:Depends} will not pick it up, since
it's dlopen()ed rather than linked against.
Do you have any suggestions on how to handle this in a way that plays
well with the 64-bit time_t transition?
Thanks.
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
Bug#1023420: marked as pending in libvirt
Control: tag -1 pending Hello, Bug #1023420 in libvirt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libvirt-team/libvirt/-/commit/3f2985672fd96f945e71373e477ca92b3ae2f86c control: Add (build) dependency on mount mount is no longer essential, so we need to explicitly depend on it. We should be able to drop the build dependency later, after patching out the check upstream, but the runtime dependency is here to stay. Closes: #1023420 (this message was generated automatically) -- Greetings https://bugs.debian.org/1023420
Bug#1023420: libvirt FTBFS: missing Build-Depends: mount
On Wed, Nov 16, 2022 at 01:11:51PM +0100, Helmut Grohne wrote: > On Wed, Nov 16, 2022 at 12:34:40PM +0100, Andrea Bolognani wrote: > > Can you please tell me how you created the very minimal chroot in > > which you reproduced the issue? A fresh one created today with > > cowbuilder still contains mount, and even adding > > > > DEBOOTSTRAPOPTS="--variant=minbase" > > > > to pbuilderrc doesn't change this. I just want to make sure there are > > no other commands that need the same treatment. > > I'm using mmdebstrap rather than debootstrap. While debootstrap's > --variant=minbase includes all "Priority: required" packages, you still > have to depend on them according to policy. mmdebstrap provides two > smaller variants "essential", which really is only essential packages > and "apt", which includes the apt package in addition to essential > packages. The apt variant is the one I use most often. It recently got > rid of adduser, which also exhibits bugs here and there. These days, > sbuild can deal with such minimal chroots. Okay, adding DEBOOTSTRAP="mmdebstrap" DEBOOTSTRAPOPTS="--variant=apt" to my pbuilder configuration did the trick. I'm going to make sure that there are no other missing Build-Depends, and address this bug as part of the upcoming 8.9.0-1 upload. Cheers :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1023420: libvirt FTBFS: missing Build-Depends: mount
On Wed, Nov 16, 2022 at 12:34:40PM +0100, Andrea Bolognani wrote: > In the meantime, adding an explicit build time (and runtime!) > dependency on mount will do the trick. If I'm reading the NEWS.Debian file for mount correctly, it hasn't been essential since 2017. So why is this only showing up now? Not questioning the need to add the new dependencies, just trying to fully understand the situation :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1023420: libvirt FTBFS: missing Build-Depends: mount
On Thu, Nov 03, 2022 at 08:12:53PM +0100, Helmut Grohne wrote: > Source: libvirt > Version: 8.5.0-1 > Severity: serious > Tags: ftbfs > > libvirt fails to build from source in unstable on a minimal chroot. > mount is no longer essential nor build-essential, so you must add it to > Build-Depends explicitly. Hi Helmut, thanks for the report! The handling of mount and other similar commands is currently not ideal: none of them should be required to be present at build time, since libvirt is perfectly capable of finding them at runtime. This is, in fact, what we already do for several other programs. I will write a patch fixing this and submit it upstream. In the meantime, adding an explicit build time (and runtime!) dependency on mount will do the trick. Can you please tell me how you created the very minimal chroot in which you reproduced the issue? A fresh one created today with cowbuilder still contains mount, and even adding DEBOOTSTRAPOPTS="--variant=minbase" to pbuilderrc doesn't change this. I just want to make sure there are no other commands that need the same treatment. Cheers. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1014435: libvirt-daemon-system-systemd: virbr0 default fails to connect
On Tue, Jul 05, 2022 at 08:06:44PM -0500, Tim McConnell wrote: > Package: libvirt-daemon-system-systemd > Version: 8.4.0-1 > Severity: grave > Justification: renders package unusable This doesn't feel right. According to [1], "grave" means that the bug makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package The fact that a single libvirt feature (the default network) has been reported as not working by a single person (I just tested it on my machine and it seems okay) doesn't match the description of the severity IMO. I'll lower it to "important", which indicates a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone and seems to describe the actual impact much more accurately. > Virbr0 won't connect to external network.It did once, I was able to install > Debian from a net install image. Now it tells me the Virtual Machine can't > connect. Please be more specific. Does the VM fail to start? If so, what is the exact error message? Or does the VM boot up, but the guest OS is unable to connect to the Internet? Can the guest OS ping the host, or does that not work either? If you try performing another installation, does that work? [1] https://www.debian.org/Bugs/Developer#severities -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1006300: marked as pending in libvirt
Control: tag -1 pending Hello, Bug #1006300 in libvirt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libvirt-team/libvirt/-/commit/a06d5e56fb01acf2765700c9ad2a1bdce0454178 control: Drop i386 from Xen arches Starting with Xen version 4.16, Xen is no longer built on the i386 architecture in Debian. Closes: #1006300 (this message was generated automatically) -- Greetings https://bugs.debian.org/1006300
Bug#981435: libvirt: stops on upgrade: internal error: Failed to load module 'libvirt_driver_qemu.so': libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by libvirt_driver_qemu.so)
On Sun, Jan 31, 2021 at 04:36:21PM +0100, Andrea Bolognani wrote: > I've opened > > https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/98 > > with the proposed patch, and I'm going to use the information you > provided above to give it some testing now. I've added a few extra Depends to make sure everything is really updated in lockstep and tested with unattended-upgrades: the result was much better this time! Log started: 2021-01-31 18:20:43 (Reading database ... 87062 files and directories currently installed.) Preparing to unpack .../00-libnss-libvirt_7.0.0-1_amd64.deb ... Unpacking libnss-libvirt:amd64 (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../01-libvirt-sanlock_7.0.0-1_amd64.deb ... Unpacking libvirt-sanlock (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../02-libvirt-login-shell_7.0.0-1_amd64.deb ... Unpacking libvirt-login-shell (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../03-libvirt-dev_7.0.0-1_amd64.deb ... Unpacking libvirt-dev:amd64 (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../04-libvirt-daemon-config-nwfilter_7.0.0-1_all.deb ... Unpacking libvirt-daemon-config-nwfilter (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../05-libvirt-daemon-config-network_7.0.0-1_all.deb ... Unpacking libvirt-daemon-config-network (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../06-libvirt-daemon-system_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-system (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../07-libvirt-daemon-driver-qemu_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-driver-qemu (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../08-libvirt-clients_7.0.0-1_amd64.deb ... Unpacking libvirt-clients (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../09-libvirt0_7.0.0-1_amd64.deb ... Unpacking libvirt0:amd64 (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../10-libvirt-daemon-driver-xen_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-driver-xen (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../11-libvirt-daemon-driver-vbox_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-driver-vbox (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../12-libvirt-daemon-driver-storage-zfs_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-driver-storage-zfs (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../13-libvirt-daemon-driver-storage-rbd_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-driver-storage-rbd (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../14-libvirt-daemon-driver-storage-gluster_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-driver-storage-gluster (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../15-libvirt-daemon_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../16-libvirt-daemon-driver-lxc_7.0.0-1_amd64.deb ... Unpacking libvirt-daemon-driver-lxc (7.0.0-1) over (6.9.0-4) ... Preparing to unpack .../17-libvirt-daemon-system-systemd_7.0.0-1_all.deb ... Unpacking libvirt-daemon-system-systemd (7.0.0-1) over (6.9.0-4) ... Setting up libvirt-daemon-config-network (7.0.0-1) ... Setting up libvirt-daemon-system-systemd (7.0.0-1) ... Setting up libvirt0:amd64 (7.0.0-1) ... Setting up libvirt-daemon-config-nwfilter (7.0.0-1) ... Setting up libvirt-clients (7.0.0-1) ... Setting up libvirt-dev:amd64 (7.0.0-1) ... Setting up libvirt-sanlock (7.0.0-1) ... Setting up libnss-libvirt:amd64 (7.0.0-1) ... Setting up libvirt-daemon-driver-qemu (7.0.0-1) ... Setting up libvirt-daemon (7.0.0-1) ... Setting up libvirt-daemon-driver-vbox (7.0.0-1) ... Setting up libvirt-daemon-driver-storage-rbd (7.0.0-1) ... Setting up libvirt-daemon-driver-lxc (7.0.0-1) ... Setting up libvirt-login-shell (7.0.0-1) ... Setting up libvirt-daemon-driver-storage-gluster (7.0.0-1) ... Setting up libvirt-daemon-driver-xen (7.0.0-1) ... Setting up libvirt-daemon-driver-storage-zfs (7.0.0-1) ... Setting up libvirt-daemon-system (7.0.0-1) ... Installing new version of config file /etc/apparmor.d/abstractions/libvirt-lxc ... Installing new version of config file /etc/apparmor.d/abstractions/libvirt-qemu ... Installing new version of config file /etc/default/libvirt-guests ... Installing new version of config file /etc/libvirt/qemu.conf ... virtlockd.service is a disabled or a static unit, not starting it. virtlogd.service is a disabled or a static unit, not starting it. Processing triggers for man-db (2.9.3-2) ... Processing triggers for libc-bin (2.31-9) ... Log ended: 2021-01-31 18:20:48 Log started: 2021-01-31 18:20:49 (Reading database ... 87071 files and directories currently installed.) Preparing to unpack .../libvirt-wireshark_7.0.0-1_amd64.deb ... Unpacking libvirt-wireshark (7.0.0-1) over (6.9.0-4) ... Setting up libvirt-wireshark (7.0.0-1) ... Log ended: 2021-01-31 18:20:49 Log started: 2021-01-31 18:20:49 (Reading database ... 87071 files and dir
Bug#981435: libvirt: stops on upgrade: internal error: Failed to load module 'libvirt_driver_qemu.so': libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by libvirt_driver_qemu.so)
On Sun, Jan 31, 2021 at 11:04:13PM +0800, Paul Wise wrote:
> On Sun, 2021-01-31 at 15:34 +0100, Andrea Bolognani wrote:
> > As I've never used unattended-upgrades myself, I'm not familiar with
> > it. Is there any chance you could provide some quick tips on how to
> > set up a reproducer environment? Specifically how to set up the same
> > upgrade strategy you're using, and whether it's possible to manually
> > trigger an unattended-upgrades run? That would help a lot!
>
> You can probably also reproduce it without unattended-upgrades by just
> upgrading libvirt-daemon itself using apt but with unattended-upgrades
> the key is to enable the minimal steps option, but do this overall:
>
> Install a Debian system that has the old libvirt using the Debian
> wayback machine (snapshot.debian.org), install unattended-upgrades and
> add something like the following in /etc/apt/apt.conf.d/99override-u-u.conf
> and then run this command: systemctl start apt-daily{,-upgrade}.service
>
> APT::Periodic::Update-Package-Lists "always";
> APT::Periodic::Download-Upgradeable-Packages "always";
> APT::Periodic::AutocleanInterval "always";
> APT::Periodic::Unattended-Upgrade "always";
> Unattended-Upgrade::Origins-Pattern { "origin=Debian"; };
> Unattended-Upgrade::MinimalSteps "true";
> Unattended-Upgrade::Mail "root";
> Unattended-Upgrade::Remove-Unused-Dependencies "true";
> Unattended-Upgrade::Automatic-Reboot "false";
> // Temporary options for debugging
> //Unattended-Upgrade::Verbose "true";
> //Unattended-Upgrade::Debug "true";
Thanks, I'll try this.
> > As for the issue itself, I think it's caused by some of the
> > dependencies not being strict enough
>
> I'm not sure but I think the issue is caused by the libvirt0 symbol
> file generating incorrect dependencies for the private symbols,
> probably it should be much more restrictive for those.
>
> The missing symbols are pretty concerning, those look like broken ABI?
The exact error is
Failed to load module
'/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so':
/usr/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not
found (required by
/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so)
Note how it's talking about LIBVIRT_PRIVATE_x.y.z rather than
LIBVIRT_x.y.z: the latter contains the public API, while the former
is used for internal symbols that are not exposed publicly and are
only needed by other libvirt components, such as utility functions
that are provided by libvirt.so for use in the various drivers.
This is part of the reason why we want upgrades to happen in
lockstep: for any given version of libvirt, its various components
are really only meant to work with other components when these come
from the very same build.
I've opened
https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/98
with the proposed patch, and I'm going to use the information you
provided above to give it some testing now.
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
Bug#981435: libvirt: stops on upgrade: internal error: Failed to load module 'libvirt_driver_qemu.so': libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by libvirt_driver_qemu.so)
mor_parser"
> Jan 31 17:08:34 audit[1318234]: AVC apparmor="STATUS"
> operation="profile_replace" info="same as current profile, skipping"
> profile="unconfined" name="libvirtd//qemu_bridge_helper" pid=1318234
> comm="apparmor_parser"
> Jan 31 17:08:34 systemd[1]: Reloading.
> Jan 31 17:08:36 systemd[1]: Stopping Virtualization daemon...
> Jan 31 17:08:36 systemd[1]: libvirtd.service: Succeeded.
> Jan 31 17:08:36 systemd[1]: Stopped Virtualization daemon.
> Jan 31 17:08:36 systemd[1]: Starting Virtualization daemon...
> Jan 31 17:08:36 libvirtd[1318287]: libvirt version: 7.0.0, package: 1 (Andrea
> Bolognani Thu, 28 Jan 2021 22:06:43 +0100)
> Jan 31 17:08:36 libvirtd[1318287]: hostname: chianamo
> Jan 31 17:08:36 libvirtd[1318287]: internal error: Failed to load module
> '/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so':
> /usr/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not
> found (required by
> /usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so)
> Jan 31 17:08:36 systemd[1]: libvirtd.service: Main process exited,
> code=exited, status=3/NOTIMPLEMENTED
> Jan 31 17:08:36 systemd[1]: libvirtd.service: Failed with result 'exit-code'.
> Jan 31 17:08:36 systemd[1]: Failed to start Virtualization daemon.
Thanks for your report, Paul!
As I've never used unattended-upgrades myself, I'm not familiar with
it. Is there any chance you could provide some quick tips on how to
set up a reproducer environment? Specifically how to set up the same
upgrade strategy you're using, and whether it's possible to manually
trigger an unattended-upgrades run? That would help a lot!
As for the issue itself, I think it's caused by some of the
dependencies not being strict enough: in particular we have
Package: libvirt-daemon
Depends: libvirt-daemon-driver-qemu
In your case, libvirt-daemon-driver-qemu 6.9.0-4 satisifies the
constraint for libvirt-daemon 7.0.0-1, and so the first upgrade step
only upgrades the latter and leaves the former for later: what I
believe we really want instead is
Package: libvirt-daemon
Depends: libvirt-daemon-driver-qemu (= ${binary:Version})
so that we can be sure that all libvirt packages are upgraded in
lockstep. We already have this for some inter-source-package
dependencies, we're just not entirely consistent about it.
I'll start working on a MR right away.
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
Bug#960762: [Pkg-libvirt-maintainers] Bug#960762: libvirt: random (?) test hangs
On Fri, Jul 03, 2020 at 12:04:16AM +0200, Andrea Bolognani wrote: > On Wed, Jul 01, 2020 at 09:24:00AM +0200, Guido Günther wrote: > > On Tue, Jun 30, 2020 at 09:28:34PM +0200, Andrea Bolognani wrote: > > > Has anyone managed to reproduce this? I've built 6.0.0-7 from source > > > in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder > > > and in a sid:i386 VM, without encountering a single failure. > > > > I tried to reproduce too when this came in and couldn't. > > Okay, let's assume it was a temporary glitch then - at least until > another build fails for the same reason. We've made three uploads in a row now with zero issues on i386, so at this point I would say it's fair to assume this one failure was just a fluke. I vote for closing the bug and unblocking migrations to testing. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#960762: [Pkg-libvirt-maintainers] Bug#960762: libvirt: random (?) test hangs
On Wed, Jul 01, 2020 at 09:24:00AM +0200, Guido Günther wrote: > On Tue, Jun 30, 2020 at 09:28:34PM +0200, Andrea Bolognani wrote: > > Has anyone managed to reproduce this? I've built 6.0.0-7 from source > > in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder > > and in a sid:i386 VM, without encountering a single failure. > > I tried to reproduce too when this came in and couldn't. Okay, let's assume it was a temporary glitch then - at least until another build fails for the same reason. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#960762: libvirt: random (?) test hangs
On Sat, May 16, 2020 at 03:00:46PM +0300, Adrian Bunk wrote: > Source: libvirt > Version: 6.0.0-7 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=libvirt=all=6.0.0-7=1589452859=0 > https://buildd.debian.org/status/fetch.php?pkg=libvirt=i386=6.0.0-7=1589494701=0 > > ... > make check-TESTS > make[4]: Entering directory '/<>/debian/build/tests' > make[5]: Entering directory '/<>/debian/build/tests' > PASS: sockettest > PASS: virbuftest > PASS: virhostcputest [...] > PASS: virsh-vcpupin > PASS: virsh-optparse > PASS: virt-aa-helper-test > E: Build killed with signal TERM after 150 minutes of inactivity Has anyone managed to reproduce this? I've built 6.0.0-7 from source in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder and in a sid:i386 VM, without encountering a single failure. The latest build attempt on i386 also failed: https://buildd.debian.org/status/fetch.php?pkg=libvirt=i386=6.4.0-1=1593097042=0 However, the failure in this case was not limited to i386 and the error was completely different, caused this time by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963704 All I can think of at this point is a temporary glitch of the buildd. In a couple of weeks, when we upload 6.5.0, we'll hopefully see that build fine on all architectures, i386 included... Does anyone have any better theories? Or a way to dig further? -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#952200: libvirt-dbus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
On Tue, Apr 14, 2020 at 08:25:53PM +0300, Adrian Bunk wrote: > On Sun, Mar 29, 2020 at 10:18:05PM +0200, Andrea Bolognani wrote: > >... > > Adrian, I see you tagged the bug as fixed-upstream: can you please > > share any additional information you might have and that convinced > > you the bug is no longer present upstream? Thanks in advance! > > Sorry for failing to include this information, > please see the commit linked above. Thanks Adrian! I had already tracked down the commit myself in the meantime, and I have prepared an updated libvirt-dbus package that's pending review: https://salsa.debian.org/libvirt-team/libvirt-dbus/-/merge_requests/1 Hopefully we'll be able to upload it soon :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#952200: libvirt-dbus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
On Sun, Feb 23, 2020 at 02:09:46PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > test_connect.py F. > > [100%] > > > > === FAILURES > > === > > ___ TestConnect.test_connect_node_device_create_xml > > > > Fixture "node_device_create" called directly. Fixtures are not meant to be > > called directly, > > but are created automatically when test functions request them as > > parameters. > > See https://docs.pytest.org/en/latest/fixture.html for more information > > about fixtures, and > > https://docs.pytest.org/en/latest/deprecations.html#calling-fixtures-directly > > about how to update your code. > > = 1 failed, 33 passed in 3.89 seconds > > == > > FAIL test_connect.py (exit status: 1) > > The full build log is available from: >http://qa-logs.debian.net/2020/02/22/libvirt-dbus_1.3.0-1_unstable.log Lucas, thanks for the report, and sorry for not noticing it earlier! I'll look into it. Adrian, I see you tagged the bug as fixed-upstream: can you please share any additional information you might have and that convinced you the bug is no longer present upstream? Thanks in advance! -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#822407: enscript: FTBFS: error: automatic de-ANSI-fication support has been removed
On Sat, Apr 23, 2016 at 09:10:51PM -0700, Martin Michlmayr wrote:
> Package: enscript
> Version: 1.6.5.90-2
> Severity: serious
>
> This package fails to build in unstable:
>
> > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
> ...
> >debian/rules override_dh_auto_configure
> > make[1]: Entering directory '/<>'
> > AUTOMAKE=automake-1.11 autoreconf -fis
> > Copying file intl/Makefile.in
> > Copying file m4/intldir.m4
> > Copying file po/Makevars.template
> > configure.ac:14: error: automatic de-ANSI-fication support has been removed
> > /usr/share/aclocal-1.15/obsolete.m4:26: AM_C_PROTOTYPES is expanded from...
> > configure.ac:14: the top level
> > autom4te: /usr/bin/m4 failed with exit status: 1
> > aclocal: error: echo failed with exit status: 1
> > autoreconf: aclocal failed with exit status: 1
> > debian/rules:13: recipe for target 'override_dh_auto_configure' failed
> > make[1]: *** [override_dh_auto_configure] Error 1
> > make[1]: Leaving directory '/<>'
> > debian/rules:6: recipe for target 'build' failed
> > make: *** [build] Error 2
The attached patch makes the package build again.
Tested using cowbuilder with an up-to-date sid chroot.
--
Andrea Bolognani <e...@kiyuko.org>
Resistance is futile, you will be garbage collected.
From 453531070fd2b44dbef28c01763ad1836bb51fad Mon Sep 17 00:00:00 2001
From: Andrea Bolognani <e...@kiyuko.org>
Date: Sat, 28 May 2016 17:53:06 +0200
Subject: [PATCH] Force use of aclocal 1.11
debian/rules is set up so that automake 1.11 will
always be used - even on unstable, where the default
version is 1.15. However, the same is not true for
aclocal, which will be always used in its default
version.
The version mismatch between automake 1.11 and
aclocal 1.15 causes a FTBFS.
Fix the issue by forcing the use of aclocal 1.11.
Signed-off-by: Andrea Bolognani <e...@kiyuko.org>
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index c6e729f..a6fa59f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@ override_dh_auto_clean:
find -name Makefile.in -exec rm {} \;
override_dh_auto_configure:
- AUTOMAKE=automake-1.11 autoreconf -fis
+ AUTOMAKE=automake-1.11 ACLOCAL=aclocal-1.11 autoreconf -fis
dh_auto_configure
override_dh_auto_install:
--
2.8.1
signature.asc
Description: PGP signature
Bug#564943: scrotwm: key bindings don't work, can't switch to a VT (was: libswmhack is installed in the wrong location)
Sorry for taking so long to answer, but I apparently got no notice of your reply to the bug report, so I didn't notice until I checked the bug's BTS page. Oh well. So, if the problem occurs even when libswmhack is not present, we can rule out a libswmhack problem, can't we? Unfortunately, it seems like I lack the knowledge to debug this problem, so I will ask upstream to take a look at information you reported and try to figure out where the issue lies. Just one last question: googling the errors around, it seems most of the people who get that kind of error (in other applications) are running on an NVIDIA card, using the NVIDIA binary drivers. If that is also the case with you, could you please try running scrotwm after switching to the free nv driver? Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: scrotwm: key bindings don't work, can't switch to a VT (was: libswmhack is installed in the wrong location)
On Sun, Jan 17, 2010 at 04:53:50PM +0100, Hannes wrote: Since no keys apart from Crtl+Alt+Backspace works after starting ScrotWM, I can only do this while having DWM running. No difference there. Can you spawn applications other than the terminal using Alt+p to summon dmenu? And from a VT? No keys found on the man page work, I tried them all. As I said, I can't switch to a VT anymore after running ScrotWM. What happens if you try to move libswmhack somewhere else, so that it can't be found and loaded? Does it work that way? Unfortunately I don't have an amd64 system so I can't look at this without your help. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: scrotwm: libswmhack is installed in the wrong location
On Sun, Jan 17, 2010 at 11:12:21AM +0100, Hannes wrote: No .scrotwm.conf in my home directory and /etc/scrotwm.conf is the one shipped with the package. Good. From .xsession-errors: Xsession: X session started for standard at Sun Jan 17 11:00:06 CET 2010 Welcome to scrotwm V0.9.20 cvs tag: $scrotwm: scrotwm.c,v 1.277 2009/11/25 17:03:53 marco Exp $ XIO: fatal IO error 11 (Resource temporarily unavailable) on X server :0.0 after 25 requests (24 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server :0.0 after 312 requests (89 known processed) with 0 events remaining. Not sure what these are, but might turn out to be valuable in the future. I'm not sure what you mean about opening a terminal. Trying to run ScrotWM, I can't open a terminal. That's the problem. You can open a terminal by switching to a VT (eg. Ctrl+Alt+F1) and issuing command $ DISPLAY=:0.0 x-terminal-emulator You should now see a terminal when you switch back to X using Ctrl+Alt+F7. Please also try using $ DISPLAY=:0.0 \ LD_PRELOAD=/usr/lib/scrotwm/libswmhack.so.0.0 x-terminal-emulator (wrapped for better readability) and report back if you can see any difference. Can you spawn applications other than the terminal using Alt+p to summon dmenu? And from a VT? Sorry to annoy you with so many questions, but I need some data before I can try to figure out what's not working. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: scrotwm: libswmhack is installed in the wrong location
On Fri, Jan 15, 2010 at 05:00:07PM +0100, hannes.schuel...@gmx.net wrote: Sorry for the delay - I wanted to test some things. You're right indeed - the binary looks for the library in the right place after all. I was too quick to jump to that conclusion. No biggie. I have installed the package on my laptop (i386) and it's working there. On my desktop (which I sent this bug report with), it also works, but only if run as root. As a regular user, the behaviour is as described; i.e. it doesn't do anything at all. Can you see any output it the $HOME/.xsession-error file? What happens when you open an application from a VT, without setting LD_PRELOAD? And with LD_PRELOAD pointing to libswmhack? Do you have a .scrotwm.conf file in your home directory? Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: scrotwm: libswmhack is installed in the wrong location
Are you sure scrotwm looks for the wrong library? The right path is explicitly defined during build. Besides, it works correctly here. Could you please post the output of the following command? $ strings /usr/bin/scrotwm | grep libswmhack Thank you for taking the time to report this bug. Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
