Bug#1064126: libvirt: install NSS modules into /usr
On Thu, May 30, 2024 at 08:05:34PM +0200, Chris Hofstaedtler wrote: > Hi, > > please make sure the usrmerge changes land in trixie well before the > transition freeze. > Now would be a great time. I have been making slow but steady progress over the past months. I hope to have something suitable for initial review in a few weeks. > On Tue, Feb 27, 2024 at 10:53:12PM +0100, Andrea Bolognani wrote: > > Suppose that I made the usr-merge upload today, and the package > > restructure upload in a month. At that point, dumat would detect that > > file loss could occur, report it and... What then? > > Then you get to fix them manually in various maintainer scripts, > hoping they can be fixed. That doesn't sound very appealing. The libvirt package is already fairly complex, I'd rather not make things even worse if it can be avoided. This further convinces me that it would be better to perform all file moves as part of a single upload to experimental, lowering the chances that broken packages make their way to unstable and testing. > > Have reliable mitigations been developed for all possible file loss > > scenarios? Is it guaranteed that such mitigations, when applied, > > will protect from file loss not just the people running stable, but > > also those running testing and unstable? > > No. The mitigations are fragile; bugs in dpkg and/or policy have > been discovered. Extensive testing is required for all scenarios you > can envision. > Even then, some things are just not fixable in a reliable manner. Not exactly confidence-inducing :) Hopefully moving a few files in what is a relatively leaf package is among the easiest and most tested scenarios. > > My instincts tell me that it would be much easier to reason about > > this if the two transitions happened at the same time rather than > > potentially months apart. This is my main concern with applying the > > usr-merge changes when we still don't have a clear picture of what > > the final state of the package will look like. > > The best is to have as few file moves as possible in trixie. In > forky, moving files becomes easier again. forky is ~3 years away though... That's a long time to deliver changes that are, realistically speaking, already overdue. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1069955: nautilus: Incomplete Italian translation
Package: nautilus Version: 43.2-1 Severity: minor Hi, some fairly prominent actions (e.g. New Folder, Open With) show up in English when running with an Italian locale. I would like to see that addressed in a future bookworm update. Actually translating the labels will be fairly quick, but I'm not sure what the process around getting updated translation into the Debian package looks like. Maybe the translations have already been added upstream, and it's just a matter of backporting the relevant changes? Or they have to be contributed there first. If you could provide some pointers, I'll look into it. Thanks in advance. -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, 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 nautilus depends on: ii bubblewrap 0.8.0-2 ii desktop-file-utils 0.26-1 ii gsettings-desktop-schemas 43.0-1 ii gvfs1.50.3-1 ii libadwaita-1-0 1.2.2-1 ii libc6 2.36-9+deb12u6 ii libcairo2 1.16.0-7 ii libcloudproviders0 0.3.1-2 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgexiv2-2 0.14.0-1+b1 ii libglib2.0-02.74.6-2 ii libglib2.0-data 2.74.6-2 ii libgnome-autoar-0-0 0.4.3-1 ii libgnome-desktop-4-243.2-2 ii libgstreamer-plugins-base1.0-0 1.22.0-3+deb12u1 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-4-1 4.8.3+ds-2+deb12u1 ii libnautilus-extension4 43.2-1 ii libpango-1.0-0 1.50.12+ds-1 ii libportal-gtk4-10.6-4 ii libportal1 0.6-4 ii libselinux1 3.4-1+b6 ii libtracker-sparql-3.0-0 3.4.2-1 ii nautilus-data 43.2-1 ii shared-mime-info2.2-1 ii tracker 3.4.2-1 ii tracker-extract 3.4.3-1 ii tracker-miner-fs3.4.3-1 Versions of packages nautilus recommends: ii gnome-sushi 43.0-2 ii gvfs-backends 1.50.3-1 ii libgdk-pixbuf2.0-bin 2.42.10+dfsg-1+b1 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 Versions of packages nautilus suggests: ii eog 43.2-1 ii evince [pdf-viewer] 43.1-2+b1 pn nautilus-extension-brasero pn nautilus-sendto ii totem 43.0-2 ii xdg-user-dirs 0.18-1 -- no debconf information -- 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 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#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles
On Wed, Mar 06, 2024 at 08:34:59AM +0100, Mikhail Morfikov wrote: > Take a look for example at the thunderbird email client package. They ship > the apparmor profile for the app in the thunderbird package (I also asked them > to do the move, but no one cared, see #949649 from 23 Jan 2020 -- no one ever > answered). That bug report looks identical to the one you've filed against libvirt, so it doesn't provide any additional information. > So I use thunderbird and I have my own separate profile for this app because > I have different rules, aiming different security policy. Each time the > thunderbird package is updated, the apparmor profile is also installed, and > I have no option to forbid that. So the apparmor policy is rewritten, which > requires me to manually remove the newly installed thunderbird profile (the > physical file), remove non exising profiles from apparmor (aa-remove-unknown), > reload my own profile, update initramfs (since I load the apparmor policy > during > initramfs phase). That does indeed sound very annoying. I wonder why you have to go through that whole process though. The AppArmor configuration is in /etc, so everything is marked as conffiles. If you make local customizations, shouldn't you at worst be prompted to confirm whether you want your changes to be preserved or overwritten? > Most of people don't even use apparmor, so they don't care whether the > profile is > in the core package, or in some app-apparmor-profile package. I don't think this is a fair assessment: AppArmor is enabled by default in Debian and has been for several releases, so people *are* in fact using AppArmor unless they go out of their way to disable it. > The all issues/problems call for a separate apparmor profile packages, but > someone > has to make that move first, so others would follow. 4 years has passed and > no one > did this, because no one care, and no one really use apparmor. And I bet no > one will > make that first step and in the next 4 years the problems will still persist. Have you raised the topic on a project-wide forum, such as debian-devel? That would IMO be the best way forward. Convince the project that AppArmor profiles should be packaged separately, and make that into a (mini-)policy that is officially adopted. Opening bug reports against individual packages when no project-wide consensus has been reached is unlikely to result in much progress. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1031802: fuse3: inaccurate information in symbols file (was: Re: libvirt-daemon-driver-lxc: Incorrect dependencies)
On Wed, Mar 13, 2024 at 11:06:03AM +, Simon McVittie wrote: > On Sat, 18 Mar 2023 at 14:46:47 +0100, Andrea Bolognani wrote: > > In other words, upstream developers have retroactively added symbols > > (fuse_new_31) to existing symbol groups (FUSE_3.1). > ... > > really this looks like an upstream > > bug in my opinion: even if the function was present in the source > > code all the way back in 3.1, it's only publicly exported starting > > with 3.13, and so exposing it as fuse_new_31@FUSE_3.13 would have > > been the correct way to go about it IMO. > > I agree that this was incorrect, but now that several released libfuse > versions have had this bug, it is part of the ABI. In the absence of a > time machine, upstream cannot go back and correct it. > > > I believe it should be possible to work around this in Debian by > > adding an entry like > > > > fuse_new_31@FUSE_3.1 3.13.0 > > > > to debian/libfuse3-3.symbols > > Since we don't have a time machine, I think this would be the > correct answer to this bug. That would result in packages like > libvirt-daemon-driver-lxc generating correct dependencies next time they > are rebuilt. > > On Wed, 13 Mar 2024 at 01:05:40 +0100, Bernd Schubert wrote: > > Would it help to move that symbol to FUSE_3.13 in the version script > > (for example in libfuse-3.17?)? > > No, please don't do that: that would make the library as shipped by > Debian permanently incompatible with one built from upstream source. Just for the record, I agree with everything Simon has written. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles
On Sun, Jul 19, 2020 at 08:08:15PM +0200, Mikhail Morfikov wrote: > Dear Maintainer, > > Currently when the package is installed, it also installs files under > /etc/apparmor.d/ . There are two issues with this: > > 1) some people want to use their own profile (the local profile under > /etc/apparmor.d/local/ may not be an option for many reasons), > 2) some of the names of the files are path based, and some users could use > just > the exec/binary name (or whatever) for the profile/file name, which leads to > having two different sets of rules (two different apparmor profiles loaded at > the same time confining the same app). > > The only way to fix this is to manually remove the provided apparmor profile > files after each package update, which is a little bit annoying. > > Please reconsider creating a separate package for the apparmor profile files > (something similar to package_name-apparmor-profile), and just > suggest/recommend it in deps of the main package, so the user could decide > whether he wants the profiles to be installed in his system or not. Hi Mikhail, I am currently working on a big refactoring of the libvirt package, which I thought could be the perfect opportunity to implement the split that you're suggesting here. However, looking at the contents of the archive, it seems that the practice of shipping AppArmor profiles as separate package from the software that they're intended for is far from widespread: $ apt-cache search -n apparmor apparmor - user-space parser utility for AppArmor apparmor-notify - AppArmor notification system apparmor-profiles - experimental profiles for AppArmor security policies apparmor-utils - utilities for controlling AppArmor dh-apparmor - AppArmor debhelper routines libapache2-mod-apparmor - changehat AppArmor library as an Apache module libapparmor-dev - AppArmor development libraries and header files libapparmor1 - changehat AppArmor library libpam-apparmor - changehat AppArmor library as a PAM module python3-apparmor - AppArmor Python3 utility library python3-libapparmor - AppArmor library Python3 bindings apparmor-profiles-extra - Extra profiles for AppArmor Security policies fwknop-apparmor-profile - FireWall KNock OPerator - Apparmor profile uwsgi-plugin-apparmor - apparmor plugin for uwsgi If we exclude apparmor-profiles(-extra), which by definition don't count as they are maintained separately from the corresponding applications, the only example I can see is fwknop. This gives me pause, and makes me not particularly keen on going down such a lonesome path. I'd like to understand your use case better though. Can you please provide concrete examples of the problematic scenarios you've mentioned in your original message, along with the steps that you currently have to perform to work around them? Thanks in advance! -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1064126: libvirt: install NSS modules into /usr
On Mon, Feb 26, 2024 at 11:38:58AM +0100, Michael Biebl wrote: > > > Am 25.02.24 um 19:30 schrieb Andrea Bolognani: > > Right there with you. I just don't want to rush things, especially > > since AFAIK some really problematic scenarios can be triggered when > > paths are canonicalized at the same time as they are moved across > > binary packages. > > This is correct. Moving files between packages and from / to /usr at the > same time corresponds to the file loss scenario described at > https://subdivi.de/~helmut/dep17.html as P1. > See also > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org=dep17p1 Note that "at the same time" can mean two things in this context: 1) when upgrading from bookworm to trixie; 2) when upgrading testing/unstable. I'm sure that 1) can be handled correctly, but the prospect of causing file loss for 2) by accident is not particularly appealing and I'd like to avoid it if at all possible. > > Going forward, I will focus all the time I can spend on Debian on > > reorganizing the libvirt package to enable modular daemons. I hope to > > have at least a rough implementation ready within a few weeks. > > I don't think postponing the usr-merge changes helps mitigating any issues > since those need to happen for trixie in one way or another. > > My recommendation is to upload the current patch in this bug report soon, > and do the package re-organisation later via an upload to experimental. > dumat will then pick up any potential issues. > See the recommendations in https://wiki.debian.org/UsrMerge As I've explained we want to preserve backportability as much as possible, which pretty much rules out the current patch. At the very least we'd have to use dh_movetousr instead. What I still fail to understand, and please bear with me because the issue is most likely on my side, is how the fallout from a "bad" file move would be dealt with. Suppose that I made the usr-merge upload today, and the package restructure upload in a month. At that point, dumat would detect that file loss could occur, report it and... What then? Have reliable mitigations been developed for all possible file loss scenarios? Is it guaranteed that such mitigations, when applied, will protect from file loss not just the people running stable, but also those running testing and unstable? My instincts tell me that it would be much easier to reason about this if the two transitions happened at the same time rather than potentially months apart. This is my main concern with applying the usr-merge changes when we still don't have a clear picture of what the final state of the package will look like. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1064126: libvirt: install NSS modules into /usr
On Sun, Feb 25, 2024 at 08:05:36PM +0100, Michael Biebl wrote: > Am 25.02.24 um 19:30 schrieb Andrea Bolognani: > > So what I'm wondering right now is, how much does libvirt shipping > > these files outside of /usr for a while longer negatively impact the > > overall transition plans? I'd be happy to get out of your way as soon > > as possible, but at the same time I'm wary of potentially introducing > > issues due to the unforeseen interactions between these changes. > > It depends on what you understand with "a while longer". > A couple more weeks/months/years/Debian releases? Definitely not a couple of years or releases! My aim is to make modular daemons available in trixie. > Obviously I think the sooner we get the usrmerge transition finished in > trixie, the better, to be able to iron out any unforeseen issues. Right there with you. I just don't want to rush things, especially since AFAIK some really problematic scenarios can be triggered when paths are canonicalized at the same time as they are moved across binary packages. Going forward, I will focus all the time I can spend on Debian on reorganizing the libvirt package to enable modular daemons. I hope to have at least a rough implementation ready within a few weeks. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1064126: libvirt: install NSS modules into /usr
Hi Michael, thanks for the tentative patch. The aim is indeed to reorganize the libvirt package further before trixie, specifically to finally enable the modular daemons that have been the upstream default for a while now. I haven't started this work in earnest yet, but I'm planning to do so over the spring/summer. Additionally, we're generally trying to avoid changes that would get in the way of (automated) backports to fairly old releases of Ubuntu. The reorganization I've mentioned above might be the straw that breaks the camel's back in that regard, but it's still something that we try to accomodate as much as possible. So what I'm wondering right now is, how much does libvirt shipping these files outside of /usr for a while longer negatively impact the overall transition plans? I'd be happy to get out of your way as soon as possible, but at the same time I'm wary of potentially introducing issues due to the unforeseen interactions between these changes. Cheers. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Sun, Jan 14, 2024 at 05:01:43PM +0100, Andrea Bolognani wrote: > On Tue, Jan 09, 2024 at 11:25:50PM +0100, Andrea Bolognani wrote: > > On Tue, Jan 09, 2024 at 10:55:38AM +, Simon McVittie wrote: > > > It's up to you whether to upstream this part. I would personally say > > > that any reason we give for wanting this change in Debian is probably > > > equally valid as a reason for wanting this change upstream. The line > > > I've been drawing for whether to open bugs like this one is that if a > > > window manager installs into /usr/share/xsessions/, then it's declaring > > > itself to be a (very small) desktop environment, therefore it should do > > > "desktop environment" things like expressing a preference for an > > > xdg-desktop-portal backend. > > > > I'll think about it. Upstream might be reticent to accept such a > > change, so I'll definitely start with the DesktopNames part, which > > shouldn't be controversial, and then possibly follow up with the > > portal part. > > Patches for the DesktopNames part submitted upstream. > > https://github.com/conformal/spectrwm/pull/556 This has been merged upstream. The portals part, which I've kept downstream-only at least for now, is https://salsa.debian.org/debian/spectrwm/-/merge_requests/6 So all that's left is waiting for 3.6 to be released. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Tue, Jan 09, 2024 at 11:25:50PM +0100, Andrea Bolognani wrote: > On Tue, Jan 09, 2024 at 10:55:38AM +, Simon McVittie wrote: > > It's up to you whether to upstream this part. I would personally say > > that any reason we give for wanting this change in Debian is probably > > equally valid as a reason for wanting this change upstream. The line > > I've been drawing for whether to open bugs like this one is that if a > > window manager installs into /usr/share/xsessions/, then it's declaring > > itself to be a (very small) desktop environment, therefore it should do > > "desktop environment" things like expressing a preference for an > > xdg-desktop-portal backend. > > I'll think about it. Upstream might be reticent to accept such a > change, so I'll definitely start with the DesktopNames part, which > shouldn't be controversial, and then possibly follow up with the > portal part. Patches for the DesktopNames part submitted upstream. https://github.com/conformal/spectrwm/pull/556 -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Tue, Jan 09, 2024 at 10:55:38AM +, Simon McVittie wrote: > On Tue, 09 Jan 2024 at 00:27:41 +0100, Andrea Bolognani wrote: > > Just out of curiosity, is there any advantage to having the trailing > > semicolon in this case? We only have a single item in the list after > > all. > > Yes but only a very small advantage. DesktopNames is a value of type > "strings" (string list) and in the .desktop specification, those are > canonically a list of semicolon-terminated items (unlike e.g. PATH, > which is colon-separated rather than colon-terminated, therefore does > not normally have a trailing colon). My reading of the spec is that > implementations are required to tolerate a missing trailing semicolon, > and a trailing semicolon is only mandatory if the last item is an empty > string, which is not true here; but it seemed best to use a > canonical/consistent representation when giving you a recommendation. Okay, trailing semicolon it is. > > Gtk is probably the most reasonable choice: not only it matches the > > existing default, but it's also somewhat more lightweight in that it > > doesn't drag in a dozen libraries like the KDE implementation does. > > > > Honestly, neither quite fits with spectrwm's aesthetic... We'd > > probably want an old school, unthemed Gtk 2 implementation or > > something like that. Shame it doesn't seem to exist. Oh well :) > > Please don't introduce new GTK 2 software into Debian, even if it's > aesthetically appealing: GTK 2 is dead and will not receive any new > upstream releases, even for critical/security bugs. To be clear, I had no intention of doing that in the first place! I was just wondering out loud which hypothetical implementation would feel the least out of place within spectrwm :) > Apply a flat, > hard-edged, right-angle-cornered theme to a maintained toolkit like > GTK 3 or 4, or a similarly new branch of Qt, if you are looking for a > retrocomputing aesthetic :-) Not a bad suggestion, I might try this just for kicks :) > It's up to you whether to upstream this part. I would personally say > that any reason we give for wanting this change in Debian is probably > equally valid as a reason for wanting this change upstream. The line > I've been drawing for whether to open bugs like this one is that if a > window manager installs into /usr/share/xsessions/, then it's declaring > itself to be a (very small) desktop environment, therefore it should do > "desktop environment" things like expressing a preference for an > xdg-desktop-portal backend. I'll think about it. Upstream might be reticent to accept such a change, so I'll definitely start with the DesktopNames part, which shouldn't be controversial, and then possibly follow up with the portal part. > > I have configured spectrwm to prefer Gtk and > > WindowMaker to prefer KDE, and after using one of the two, logging > > out and switching to the other one doesn't seems to be enough to get > > the other implementation to run: I have to reboot the machine, or at > > the very least kill all user processes even remotely related to the > > desktop portal. > > That's undesired, but also hard to fix. > [...] > > The result is that xdg-desktop-portal continues to run, and its execution > environment still contains the XDG_CURRENT_DESKTOP from the first desktop > environment that you logged into, so as far as it is concerned, nothing has > changed and you still want the first desktop environment's portal backend. Understood. I imagined something along these lines when I noticed that processes would stick around even after closing the session. > Most Debian users choose one desktop environment (per uid) and stick to it, > so this isn't generally a significant problem in practice. Agreed. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1051018: spectrwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
On Fri, Sep 01, 2023 at 12:06:40PM +0100, Simon McVittie wrote: > Package: spectrwm > Version: 3.4.1-3 > Severity: normal > User: xdg-desktop-por...@packages.debian.org > Usertags: portals.conf Hi Simon, apologies for taking a while to get back to you. I'm actively looking into this now. > Suggested fix > = > > Add a sequence of semicolon-separated desktop environment names to > /usr/share/xsessions/spectrwm.desktop, most likely just "spectrwm": > > DesktopNames=spectrwm; This makes perfect sense, and would also be totally suitable for upstream, where spectrwm.desktop already lives. I'll prepare a patch and propose it there. Just out of curiosity, is there any advantage to having the trailing semicolon in this case? We only have a single item in the list after all. > And then create a /usr/share/xdg-desktop-portal/spectrwm-portals.conf > with whatever portal backends are desired for a spectrwm session, > for example perhaps this: > > [preferred] > default=gtk; This feels more suitable for a downstream patch, would you agree? Gtk is probably the most reasonable choice: not only it matches the existing default, but it's also somewhat more lightweight in that it doesn't drag in a dozen libraries like the KDE implementation does. Honestly, neither quite fits with spectrwm's aesthetic... We'd probably want an old school, unthemed Gtk 2 implementation or something like that. Shame it doesn't seem to exist. Oh well :) By the way, while playing around with this to understand how the various pieces fit together I noticed that there seems to be a significant amount of caching going on. By this I mean that I have configured spectrwm to prefer Gtk and WindowMaker to prefer KDE, and after using one of the two, logging out and switching to the other one doesn't seems to be enough to get the other implementation to run: I have to reboot the machine, or at the very least kill all user processes even remotely related to the desktop portal. Is this expected? It certainly took me a bit to wrap my head around it, but I guess it's fine as long as users don't constantly hop between different sessions... -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1042429: libvirt-daemon-system: VM running but virt-manager not connecting
On Fri, Jul 28, 2023 at 09:21:42AM +0200, Andreas Guenther wrote: > After starting, the Virt-manager window remains empty and > instead shows the message "QEMU/KVM - Not Connected". > > * What led up to the situation? > > System upgrade from Debian 11 to Debian 12 > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > Copy the file > /var/lib/polkit-1/localauthority/10-vendor.d/60-libvirt.pkla > from the package of the same name in Buster to the same place > on the Bookworm installation. Restart libvirtd. > > * What was the outcome of this action? > > The virt-manager works as usual again This is surprising, as the version of polkit that comes with Debian 12 is capable of using JavaScript rules. For libvirt that's /usr/share/polkit-1/rules.d/60-libvirt.rules, which implements the same logic as the pkla rules did in previous releases, namely that members of the "libvirt" group should be allowed to manage the system instance of libvirtd. I have tried just now with a fresh installation of Debian 12 and everything seems to work as intended. > -- System Information: > Debian Release: 12.1 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) This doesn't look right for Debian 12, you should be running 6.1.0. Is it possible that you haven't rebooted the machine after performing the upgrade? The new version of polkit, which can read the JavaScript rules, will only take over at that point, so if you haven't rebooted yet it would make sense that the pkla rules disappearing would cause the currently running version of polkit to no longer grant you access to libvirt. > Versions of packages libvirt-daemon-system depends on: > ii polkitd 122-3 This version of polkit should be perfectly able to process the JavaScript version of the rules. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1036453: unblock: libvirt/9.0.0-4
Control: tags -1 - moreinfo On Tue, May 23, 2023 at 06:53:06PM +0200, Paul Gevers wrote: > Please go ahead. And please remove the moreinfo tag once the upload > happened. Done, thanks :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1036453: unblock: libvirt/9.0.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: libv...@packages.debian.org Control: affects -1 + src:libvirt Please unblock package libvirt [ Reason ] Fix CVE-2023-2700. [ Impact ] Fix CVE-2023-2700. [ Tests ] I haven't found tests covering this specific functionality. However, the change is part of libvirt 9.3.0, which is already in Debian experimental as well as other distributions such as Fedora, and to the best of my knowledge no issues with it have been reported. [ Risks ] The change has already been reviewed and accepted upstream. The function being patched hasn't changed between 9.0.0 and 9.3.0, so the backport was a clean one. I have reviewed the changes again in the context of the Debian package. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] N/A unblock libvirt/9.0.0-4 diff -Nru libvirt-9.0.0/debian/changelog libvirt-9.0.0/debian/changelog --- libvirt-9.0.0/debian/changelog 2023-04-15 18:27:51.0 +0200 +++ libvirt-9.0.0/debian/changelog 2023-05-21 11:31:31.0 +0200 @@ -1,3 +1,11 @@ +libvirt (9.0.0-4) unstable; urgency=medium + + * [79f6669] patches: Add backports +- backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch + - Fixes CVE-2023-2700 (Closes: #1036297) + + -- Andrea Bolognani Sun, 21 May 2023 11:31:31 +0200 + libvirt (9.0.0-3) unstable; urgency=medium * [56bee71] patches: Add backports diff -Nru libvirt-9.0.0/debian/patches/backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch libvirt-9.0.0/debian/patches/backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch --- libvirt-9.0.0/debian/patches/backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch 1970-01-01 01:00:00.0 +0100 +++ libvirt-9.0.0/debian/patches/backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch 2023-05-21 11:31:31.0 +0200 @@ -0,0 +1,53 @@ +From: Tim Shearer +Date: Mon, 1 May 2023 13:15:48 + +Subject: virpci: Resolve leak in virPCIVirtualFunctionList cleanup +MIME-Version: 1.0 +Content-Type: text/plain; charset="utf-8" +Content-Transfer-Encoding: 8bit + +Repeatedly querying an SR-IOV PCI device's capabilities exposes a +memory leak caused by a failure to free the virPCIVirtualFunction +array within the parent struct's g_autoptr cleanup. + +Valgrind output after getting a single interface's XML description +1000 times: + +==325982== 256,000 bytes in 1,000 blocks are definitely lost in loss record 2,634 of 2,635 +==325982==at 0x4C3C096: realloc (vg_replace_malloc.c:1437) +==325982==by 0x59D952D: g_realloc (in /usr/lib64/libglib-2.0.so.0.5600.4) +==325982==by 0x4EE1F52: virReallocN (viralloc.c:52) +==325982==by 0x4EE1FB7: virExpandN (viralloc.c:78) +==325982==by 0x4EE219A: virInsertElementInternal (viralloc.c:183) +==325982==by 0x4EE23B2: virAppendElement (viralloc.c:288) +==325982==by 0x4F65D85: virPCIGetVirtualFunctionsFull (virpci.c:2389) +==325982==by 0x4F65753: virPCIGetVirtualFunctions (virpci.c:2256) +==325982==by 0x505CB75: virNodeDeviceGetPCISRIOVCaps (node_device_conf.c:2969) +==325982==by 0x505D181: virNodeDeviceGetPCIDynamicCaps (node_device_conf.c:3099) +==325982==by 0x505BC4E: virNodeDeviceUpdateCaps (node_device_conf.c:2677) +==325982==by 0x260FCBB2: nodeDeviceGetXMLDesc (node_device_driver.c:355) + +Signed-off-by: Tim Shearer +Reviewed-by: Ján Tomko +(cherry picked from commit 6425a311b8ad19d6f9c0b315bf1d722551ea3585) + +https://bugs.debian.org/1036297 +https://security-tracker.debian.org/tracker/CVE-2023-2700 + +Forwarded: not-needed +Origin: https://gitlab.com/libvirt/libvirt/-/commit/6425a311b8ad19d6f9c0b315bf1d722551ea3585 +--- + src/util/virpci.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/util/virpci.c b/src/util/virpci.c +index 7800966..a44f70f 100644 +--- a/src/util/virpci.c b/src/util/virpci.c +@@ -2253,6 +2253,7 @@ virPCIVirtualFunctionListFree(virPCIVirtualFunctionList *list) + g_free(list->functions[i].ifname); + } + ++g_free(list->functions); + g_free(list); + } + diff -Nru libvirt-9.0.0/debian/patches/series libvirt-9.0.0/debian/patches/series --- libvirt-9.0.0/debian/patches/series 2023-04-15 18:27:51.0 +0200 +++ libvirt-9.0.0/debian/patches/series 2023-05-21 11:31:31.0 +0200 @@ -9,6 +9,7 @@ backport/rpc-client-Don-t-check-return-value-of-virNetMessageNew.patch backport/rpc-Don-t-warn-about-max_client_requests-in-single-thread.patch backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch +backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch forward/Skip-vircgrouptest.patch forward/Reduce-udevadm-settle-timeout-to-10-seconds.pat
Bug#953997: obsolete conffiles after upgrade
On Sat, May 13, 2023 at 06:09:22PM +0200, Christoph Anton Mitterer wrote: > On Sat, 2023-05-13 at 12:09 +0200, Andrea Bolognani wrote: > As said in my message #10 in this bug,... I don't think it's necessary > that the conffiles are cleaned up exactly the version after they have > been dropped. > > AFAIU, you'd simply replace the rm_conffile with a version right before > that of the next upload. It's a bit more complicated than that, because the logic in dpkg-maintscript-helper looks at things such as whether the conffile is still considered part of the original package and is marked as an obsolete conffile... With multiple Debian release having happened in the meantime, I'm not sure what dpkg will report for these conffiles on systemd and sysvinit hosts. > The only thing I'm not sure about: > You still want the files to be conffiles (just in another package)... > with rm_conffile you can specify the package,... not sure if dpkg is > smart enough to keep the file as is (and you could just skip the whole > copying stuff) if it sees that the file is a conffile for another > package. Transferring conffiles between packages is trickier than dropping conffiles. We've done so in libvirt in the past, and it required some custom logic. In this case, we'd have to be even more careful. Anyway, I wouldn't do anything about these files right now, knowing that their state is most likely going to change again during the trixie cycle. When I start working on that, I'll try to keep in mind this half-completed migration and handle it in the best possible way. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#953997: obsolete conffiles after upgrade
On Fri, May 12, 2023 at 04:36:14PM +0200, Christoph Anton Mitterer wrote: > On Fri, 2023-05-12 at 14:27 +0200, Andrea Bolognani wrote: > > I think at this point we can assume that most people who have hit the > > issue on upgrade will have cleaned things up manually by now, so I'd > > be inclined to close the bug and move on. > > > > Any objections? > > Well not a strong objection from my side, but I think typically most > people will rather simply not even notice that they have leftover > files, so they'll stay there forever unless cleaned up properly. I understand that, and ideally I would love to keep things tidy. However, I'm afraid we might have missed our chance. At this point, nobody is going to be upgrading from 5.6.0-3, but from a more recent version of libvirt-daemon-system where the conffiles in question are already not considered part of the package. Note that these conffiles are not actually gone, they've just been migrated to the libvirt-daemon-system-sysv. So we can't simply delete them from the system without a version check, otherwise we'd break all sysvinit users. I can't think of a simple, reliable way to handle cleaning up under our current circumstances. Another thing to keep in mind is that we're likely going to move these conffiles *back* for trixie[1], or possibly move them to some newly-introduced packages. That's going to be tricky (ah!) already, and I'd rather not complicate things further by layering that work on top of some late cleanup code. [1] https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/169 -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#953997: obsolete conffiles after upgrade
So, this affected upgrades from buster (libvirt 5.0.0) to bullseye (libvirt 7.0.0). We're now about to release bookworm (libvirt 9.0.0) and the rm_conffile snippet is not even present in the package anymore. I think at this point we can assume that most people who have hit the issue on upgrade will have cleaned things up manually by now, so I'd be inclined to close the bug and move on. Any objections? -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1024504: libvirt FTCBFS: misdetects linux/kvm.h
[sending again in a form that will be visible on the bug's page] On Sun, Nov 20, 2022 at 06:01:13PM +0100, Helmut Grohne wrote: > libvirt fails to cross build from source when building on amd64 for > armhf or armel. It uses meson's has_header to figure out whether > linux/kvm.h exists and due to linux-libc-dev:amd64 being installed, > /usr/include/linux/kvm.h exists. has_header is able to figure this out > without actually including it. When libvirt actually #includes it, > asm/kvm.h is missing as that's a multiarch headers. Thus linux headers > should be tested with check_header, which actually #includes it. While > has_header may seem relatively useless at this point, it is far quicker > than check_header. Thus I'm proposing to only employ check_header for > linux headers. I'm attaching a patch for your convenience. Thanks for the report and tentative patch, Helmut! I've decided to go for a slightly different approach when submitting the change upstream [1]; after verifying that the overhead caused by just using check_header() all the time is negligible, we ultimately went for that approach [2][3]. The fix is going to be part of libvirt 9.3.0, which will be released next week. [1] https://listman.redhat.com/archives/libvir-list/2023-April/239672.html [2] https://listman.redhat.com/archives/libvir-list/2023-April/239679.html [3] https://gitlab.com/libvirt/libvirt/-/commit/0324adb647885932efc97eefcfe08f6a8db60ae1 -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1034710: dpkg-gensymbols: Add higher check level for unnecessary entries in symbols file
Package: dpkg-dev Version: 1.21.21 Severity: wishlist When building libvirt, dpkg-gensymbols currently produces the following output: dpkg-gensymbols: warning: debian/libvirt0/DEBIAN/symbols doesn't match completely debian/libvirt0.symbols --- debian/libvirt0.symbols (libvirt0_9.2.0-2_amd64) +++ dpkg-gensymbolsFLVUCu 2023-04-22 11:43:15.646242440 +0200 @@ -1,5 +1,5 @@ libvirt-admin.so.0 libvirt0 #MINVER# - (symver|optional)LIBVIRT_ADMIN_1.3.0 1.2.18 +#MISSING: 9.2.0-2# (symver|optional)LIBVIRT_ADMIN_1.3.0 1.2.18 (symver|optional)LIBVIRT_ADMIN_2.0.0 2.0.0~rc1 (symver|optional)LIBVIRT_ADMIN_3.0.0 3.0.0 (symver|optional)LIBVIRT_ADMIN_8.6.0 8.9.0 This is because debian/libvirt0.symbols contains libvirt-admin.so.0 libvirt0 #MINVER# *@LIBVIRT_ADMIN_1.3.0 1.2.18 even though no LIBVIRT_ADMIN_1.3.0 symbol was ever added to the library. It would be nice if such a mistake on the maintainer's part could be reported in a way that can't be easily missed or ignored, i.e. a build failure. After the maintainer has explicitly opted into this behavior by setting DPKG_GENSYMBOLS_CHECK_LEVEL, of course :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1034470: unblock: libvirt/9.0.0-3
On Sun, Apr 16, 2023 at 10:52:55AM +0200, Andrea Bolognani wrote:
> [ Checklist ]
> [x] all changes are documented in the d/changelog
> [x] I reviewed all changes and I approve them
> [x] attach debdiff against the package in testing
Of course I had to embarrass myself further by forgetting to actually
attach the debdiff :)
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
diff -Nru libvirt-9.0.0/debian/changelog libvirt-9.0.0/debian/changelog
--- libvirt-9.0.0/debian/changelog 2023-02-26 18:18:30.0 +0100
+++ libvirt-9.0.0/debian/changelog 2023-04-15 18:27:51.0 +0200
@@ -1,3 +1,16 @@
+libvirt (9.0.0-3) unstable; urgency=medium
+
+ * [56bee71] patches: Add backports
+- backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch
+ * [4cdee74] debconf: Add Spanish translation
+- Thanks to Jonathan Bustillos (Closes: #986773)
+ * [1e520e5] debconf: Add Italian translation
+- Thanks to Ceppo (Closes: #1019161)
+ * [12619ec] debconf: Add Romanian translation
+- Thanks to Remus-Gabriel Chelu (Closes: #1032335)
+
+ -- Andrea Bolognani Sat, 15 Apr 2023 18:27:51 +0200
+
libvirt (9.0.0-2) unstable; urgency=medium
* [de81410] patches: Add backports
diff -Nru
libvirt-9.0.0/debian/patches/backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch
libvirt-9.0.0/debian/patches/backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch
---
libvirt-9.0.0/debian/patches/backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch
1970-01-01 01:00:00.0 +0100
+++
libvirt-9.0.0/debian/patches/backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch
2023-04-15 18:27:51.0 +0200
@@ -0,0 +1,216 @@
+From: Andrea Bolognani
+Date: Tue, 11 Apr 2023 17:56:45 +0200
+Subject: conf: Fix migration in some firmware autoselection scenarios
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Introduce a small kludge in the parser to avoid unnecessarily
+blocking incoming migration from a range of recent libvirt
+releases.
+
+https://bugzilla.redhat.com/show_bug.cgi?id=2184966
+
+Signed-off-by: Andrea Bolognani
+Reviewed-by: Ján Tomko
+(cherry picked from commit f9ad3023355bcbfc692bbe4997fdfa774866a980)
+
+Conflicts:
+
+ * tests/qemuxml2argvtest.c
+ * tests/qemuxml2xmltest.c
+- missing unrelated changes in the surrounding tests
+
+ * tests/qemuxml2argvdata/firmware-manual-efi-features.x86_64-latest.args
+ * tests/qemuxml2xmloutdata/firmware-manual-efi-features.x86_64-latest.xml
+- had to be regenerated due to missing changes in
+ the test program
+
+Forwarded: not-needed
+Origin:
https://gitlab.com/libvirt/libvirt/-/commit/f9ad3023355bcbfc692bbe4997fdfa774866a980
+---
+ src/conf/domain_conf.c | 39 --
+ ...firmware-manual-efi-features.x86_64-latest.args | 35 +++
+ tests/qemuxml2argvtest.c | 6 +++-
+ .../firmware-manual-efi-features.x86_64-latest.xml | 32 ++
+ tests/qemuxml2xmltest.c| 1 +
+ 5 files changed, 110 insertions(+), 3 deletions(-)
+ create mode 100644
tests/qemuxml2argvdata/firmware-manual-efi-features.x86_64-latest.args
+ create mode 100644
tests/qemuxml2xmloutdata/firmware-manual-efi-features.x86_64-latest.xml
+
+diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
+index 45965fa..3179558 100644
+--- a/src/conf/domain_conf.c
b/src/conf/domain_conf.c
+@@ -17021,11 +17021,13 @@ virDomainDefParseBootKernelOptions(virDomainDef *def,
+
+ static int
+ virDomainDefParseBootFirmwareOptions(virDomainDef *def,
+- xmlXPathContextPtr ctxt)
++ xmlXPathContextPtr ctxt,
++ unsigned int flags)
+ {
+ g_autofree char *firmware = virXPathString("string(./os/@firmware)",
ctxt);
+ g_autofree xmlNodePtr *nodes = NULL;
+ g_autofree int *features = NULL;
++bool abiUpdate = !!(flags & VIR_DOMAIN_DEF_PARSE_ABI_UPDATE);
+ int fw = 0;
+ int n = 0;
+ size_t i;
+@@ -17033,6 +17035,39 @@ virDomainDefParseBootFirmwareOptions(virDomainDef
*def,
+ if ((n = virXPathNodeSet("./os/firmware/feature", ctxt, )) < 0)
+ return -1;
+
++/* Migration compatibility kludge.
++ *
++ * Between 8.6.0 and 9.1.0 (extremes included), the migratable
++ * XML produced when feature-based firmware autoselection was
++ * enabled looked like
++ *
++ *
++ *
++ *
++ *
++ * Notice how there's no firmware='foo' attribute for the
++ * element, meaning that firmware autoselection is disabled, and
++ * yet some elements, which are used to control the
++ * firmware autoselection process, are present. We don't consider
Bug#1034470: unblock: libvirt/9.0.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: libv...@packages.debian.org Control: affects -1 + src:libvirt Please unblock package libvirt Let me apologize for not filing the unblock request *before* uploading 9.0.0-3 to unstable. I had not realized that libvirt was considered a key package, so I didn't think it would be necessary for me to do so. [ Reason ] This version contains 3 new debconf translations and a single fix backported from upstream. [ Impact ] The version of libvirt currently in testing, 9.0.0-2, will reject incoming migrations when the VM uses feature-based firmware autoselection. While this feature is not necessarily widely used at this point, upstream is pushing pretty hard for its adoption by users and management applications, so I expect that it will become a lot more prevalent over the lifetime of bookworm. Note that this affects live migration both from bullseye hosts to bookworm hosts *and* between bookworm hosts. [ Tests ] The changes were tested manually to confirm that a VM that would previously not be able to migrate would now successfully do so. libvirt's unit tests, which are run at package build time, provide additional confidence that the changes won't have any impact beyond what's expected and desired. [ Risks ] The code change itself is quite small (3 additional lines), but it appears to be significantly bigger due to the extensive documentation and its impact on the test suite. Its impact is important, but limited in scope to a single part of libvirt (the code responsible to parsing VM configurations) and the specific scenario described above. The patch is a backport, so the upstream community has already reviewed the changes and considered them suitable for inclusion. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock libvirt/9.0.0-3
Bug#1031802: fuse3: inaccurate information in symbols file (was: Re: libvirt-daemon-driver-lxc: Incorrect dependencies)
s present in the source code all the way back in 3.1, it's only publicly exported starting with 3.13, and so exposing it as fuse_new_31@FUSE_3.13 would have been the correct way to go about it IMO. Either way, this is for the fuse3 maintainer and upstream to decide, and there's nothing libvirt can do. I'm going to reassing the bug accordingly. -- 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 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#1000478: dh-sysuser: User removal is never invoked (and the implementation is buggy)
Package: dh-sysuser
Version: 1.3.5.1
Severity: important
X-Debbugs-CC: e...@kiyuko.org
Contrary to intention, users created by dh-sysuser are not actually
deleted when the package is purged.
Using the libvirt-dbus package, which I maintain, as an example:
$ grep libvirtdbus /etc/passwd /etc/group
$ sudo apt-get install -y libvirt-dbus
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
libvirt-dbus
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/61.2 kB of archives.
After this operation, 337 kB of additional disk space will be used.
Selecting previously unselected package libvirt-dbus.
(Reading database ... 226040 files and directories currently installed.)
Preparing to unpack .../libvirt-dbus_1.4.0-2_amd64.deb ...
Unpacking libvirt-dbus (1.4.0-2) ...
Setting up libvirt-dbus (1.4.0-2) ...
Processing triggers for dbus (1.12.20-3) ...
Processing triggers for man-db (2.9.4-2) ...
$ grep libvirtdbus /etc/passwd /etc/group
/etc/passwd:libvirtdbus:x:998:998:Created by dh-sysuser for
libvirt-dbus:/nonexistent:/usr/sbin/nologin
/etc/group:libvirtdbus:x:998:
$ sudo apt-get remove --purge -y libvirt-dbus
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
libvirt-dbus*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 337 kB disk space will be freed.
(Reading database ... 226061 files and directories currently installed.)
Removing libvirt-dbus (1.4.0-2) ...
Processing triggers for dbus (1.12.20-3) ...
Processing triggers for man-db (2.9.4-2) ...
$ grep libvirtdbus /etc/passwd /etc/group
/etc/passwd:libvirtdbus:x:998:998:Created by dh-sysuser for
libvirt-dbus:/nonexistent:/usr/sbin/nologin
/etc/group:libvirtdbus:x:998:
$
Looking at the code for sysuser-helper, the reason for this behavior
is pretty obvious:
command="${1}" ; shift
case "${command}" in
prerm)
case ${1:-} in
purge|abort-install)
rmdir --ignore-fail-on-non-empty "${CONF_HOME}"
if ! [ -d "${CONF_HOME}" ] ; then
if ! userdel --force "${CONF_USERNAME}" ; then
echo >&2 "warning: failed to remove ${CONF_USERNAME}. Proceeding
anyway."
fi
fi
esac
esac
So users are deleted when sysuser-helper is called from prerm and the
operation is purge or abort-install. But deb-prerm(5) lists all
possible ways in which prerm can be invoked, and neither of the above
can happen. The result is that users created via dh-sysuser are never
deleted.
Additionally, the call to rmdir needs to be guarded by a check for
the /nonexistent scenario, just like the use of --create-home is for
the postinst part, because it will result in a script failure
otherwise:
$ sudo rmdir --ignore-fail-on-non-empty /nonexistent
rmdir: failed to remove '/nonexistent': No such file or directory
$ echo $?
1
$
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
Bug#994061: [Pkg-libvirt-maintainers] Bug#994061: libvirt: new upstream version available
On Fri, Oct 22, 2021 at 09:10:26AM +0200, Guido Günther wrote: > On Fri, Sep 10, 2021 at 09:25:06PM +0200, Salvatore Bonaccorso wrote: > > Source: libvirt > > Version: 7.6.0-1 > > Severity: wishlist > > X-Debbugs-Cc: car...@debian.org > > > > Hi > > > > When feasible, there is a new upstream version 7.7.0 available. Would > > it be possible to push it to unstable? > > Would be great. I keeps slipping here. Maybe Andrea has it on the list > already? Right. I've been trying to stay on top of upstream releases and import them into Debian quickly, but unfortunately real life keeps getting in the way :( 7.9.0 is set to be released in about a week, so spending time on older releases at this point feels like a waste of time. I'll try to package 7.9.0 shorty after it's out. -- 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)
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#980334: libvirt FTCBFS: uses the build architecture compiler via dtrace
On Sun, Jan 17, 2021 at 10:58:39PM +0100, Helmut Grohne wrote:
> Source: libvirt
> Version: 6.9.0-1
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> We're getting closer to making libvirt cross buildable. A lot of
> libvirt's dependencies have been fixed. One aspect that resides in
> libvirt is dtrace. dtrace runs a compiler and defaults to the build
> architecture compiler. As such it'll fail finding host architecture
> headers and that happens to break the build. When running dtrace, one
> must export the CC variable with a suitable value. Implementing this
> with meson is not entirely trivial due to
> https://github.com/mesonbuild/meson/issues/266. The attached patch
> therefore implements the suggested workaround. Please consider applying
> it to bring libvirt one step closer to being cross buildable.
Hi Helmut,
I was initially surprised by your report of FTCBFS, since the libvirt
project performs cross-builds on Debian as part of the regular
upstream CI pipelines.
After looking more closely, however, I realized that we're not
installing the foreign systemtap-sdt-dev package in the environments
used for cross-builds, whereas it's listed among Build-Depends in
Debian. So that explains why the upstream pipelines never caught
this issue.
This is a pretty obvious gap in upstream CI coverage, and we should
take the opportunity to address it. When I do, the result is
https://gitlab.com/abologna/libvirt/-/pipelines/243473913
https://gitlab.com/abologna/libvirt/-/commit/f6184ca2629776b935e37f4f6e1acee4564b7843
just as one would expect based on your report; applying your patch on
top results in
https://gitlab.com/abologna/libvirt/-/pipelines/243475989
https://gitlab.com/abologna/libvirt/-/commit/dd0cc0ab8c42e78be56f2939415b096f916e3e77
which is much better :)
Your patch looks reasonable and appears to work, but I'd rather have
it go through upstream, with the additional eyeballs that entails,
and then cherry-pick it into Debian instead of the other way around.
Are you okay with me submitting the patch upstream on your behalf? I
will of course make sure that authorship information are preserved
and that you get sole credit for your contribution.
The patch, as I intend to submit it upstream, is attached. Please let
me know if I can go ahead, and thank you for not only reporting this
issue but going the extra mile and providing a patch that fixes it :)
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
From f83a95084e975ded6306ff8869ad18b7a8df3b70 Mon Sep 17 00:00:00 2001
From: Helmut Grohne
Date: Tue, 19 Jan 2021 00:08:23 +0100
Subject: [libvirt PATCH] meson: Fix cross-building of dtrace probes
dtrace invokes the C compiler, so when cross-building we need
to make sure that $CC is set in the environment and that it
points to the cross-compiler rather than the native one.
Until https://github.com/mesonbuild/meson/issues/266
is addressed, the workaround is to call dtrace via env(1).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980334
Signed-off-by: Helmut Grohne
---
meson.build | 1 +
src/meson.build | 4 ++--
src/qemu/meson.build | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/meson.build b/meson.build
index b5277b4cba..84a7c524e8 100644
--- a/meson.build
+++ b/meson.build
@@ -2029,6 +2029,7 @@ if host_machine.system() == 'linux'
if dtrace_prog.found()
conf.set('WITH_DTRACE_PROBES', 1)
endif
+ dtrace_command = [ 'env', 'CC=' + ' '.join(meson.get_compiler('c').cmd_array()), dtrace_prog ]
endif
if not get_option('host_validate').disabled() and host_machine.system() != 'windows'
diff --git a/src/meson.build b/src/meson.build
index 7c478219d6..56e71f4456 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -60,14 +60,14 @@ if conf.has('WITH_DTRACE_PROBES')
out_h,
input: infile,
output: out_h,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
)
dtrace_gen_objects += custom_target(
out_o,
input: infile,
output: out_o,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-G', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-G', '-s', '@INPUT@' ],
)
custom_target(
diff --git a/src/qemu/meson.build b/src/qemu/meson.build
index 90640b03c6..e3065c3507 100644
--- a/src/qemu/meson.build
+++ b/src/qemu/meson.build
@@ -56,14 +56,14 @@ if conf.has('WITH_DTRACE_PROBES')
out_h,
input: infile,
output: out_h,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-h', '-s', '@INPUT@' ],
)
qemu_dtrace_gen_objects += custom_target(
out_o,
input: infile,
output: out_o,
-command: [ dtrace_prog, '-o', '@OUTPUT@', '-G', '-s', '@INPUT@' ],
+command: dtrace_command + [ '-o', '@OUTPUT@', '-G', '-s
Bug#973489: libvirt-daemon-system: upgrade overwrites generated file /etc/libvirt/qemu/networks/default.xml
On Tue, Nov 10, 2020 at 12:20:13AM +0100, Andrea Bolognani wrote:
> I agree that it should probably not be in /etc; in fact, the upstream
> spec file deals with it pretty much how Thorsten suggested above:
>
> %install
>
> install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/
> cp $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml \
> $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/default.xml
> chmod 0600 $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml
>
> %post daemon-config-network
>
> if test $1 -eq 1 && test ! -f
> %{_sysconfdir}/libvirt/qemu/networks/default.xml; then
> UUID=`/usr/bin/uuidgen`
> sed -e "s/${orig_sub}/${sub}/g" \
> -e "s,,\n $UUID," \
> < %{_datadir}/libvirt/networks/default.xml \
> > %{_sysconfdir}/libvirt/qemu/networks/default.xml
> ln -s ../default.xml
> %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
> chmod 0600 %{_sysconfdir}/libvirt/qemu/networks/default.xml
> fi
>
> We should do something similar in Debian as well, possibly including
> shipping the default network configuration in a separate binary
> package. I'll look into it over the next few days :)
I've taken a stab at addressing this:
https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/78
Thorsten, I would appreciate if you could take a look, especially
since you seem to have some familiarity with this sort of situation
already.
--
Andrea Bolognani
Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
Bug#973489: libvirt-daemon-system: upgrade overwrites generated file /etc/libvirt/qemu/networks/default.xml
On Fri, Nov 06, 2020 at 11:35:06AM +0100, Guido Günther wrote:
> On Sat, Oct 31, 2020 at 05:50:23PM +0100, Thorsten Glaser wrote:
> > I suspect this file should not have been a conffile, i.e. not
> > shipped in /etc (but somewhere under /usr and copied to /etc
> > during postinst).
> >
> > NOTE: Migrating to _that_ setup is dangerous as well, see #971683
> > for what can happen when done naïvely.
>
> Hmmm...it used to be in /etc since it was *not* autogenerated. Andrea
> do you know if anything changed in that regard?
As far as I can tell, the file has had at least some part of its
contents autogenerated since
https://gitlab.com/libvirt/libvirt/-/commit/5d09c314952b23a303aa40a0d7b9854dd0ae86dd
I agree that it should probably not be in /etc; in fact, the upstream
spec file deals with it pretty much how Thorsten suggested above:
%install
install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/
cp $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml \
$RPM_BUILD_ROOT%{_datadir}/libvirt/networks/default.xml
chmod 0600 $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml
%post daemon-config-network
if test $1 -eq 1 && test ! -f
%{_sysconfdir}/libvirt/qemu/networks/default.xml; then
UUID=`/usr/bin/uuidgen`
sed -e "s/${orig_sub}/${sub}/g" \
-e "s,,\n $UUID," \
< %{_datadir}/libvirt/networks/default.xml \
> %{_sysconfdir}/libvirt/qemu/networks/default.xml
ln -s ../default.xml
%{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
chmod 0600 %{_sysconfdir}/libvirt/qemu/networks/default.xml
fi
We should do something similar in Debian as well, possibly including
shipping the default network configuration in a separate binary
package. I'll look into it over the next few days :)
--
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#962354: pristine-tar: pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz
Package: pristine-tar Version: 1.47 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I ran into this issue while trying to import the latest upstream version for libvirt: $ gbp import-orig --verbose --no-rollback --debian-branch debian/experimental ../libvirt_6.4.0.orig.tar.xz gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest'] gbp:debug: ['git', 'status', '--porcelain'] gbp:debug: Signature ../libvirt_6.4.0.orig.tar.xz found for ../libvirt_6.4.0.orig.tar.xz.asc What is the upstream version? [6.4.0] gbp:debug: ['git', 'tag', '-l', 'upstream/6.4.0'] gbp:debug: tar ['-C', '../tmp8pliau55', '-a', '-xf', '../libvirt_6.4.0.orig.tar.xz'] [] gbp:debug: Unpacked '../libvirt_6.4.0.orig.tar.xz' to '../tmp8pliau55/libvirt-6.4.0' gbp:info: Importing '../libvirt_6.4.0.orig.tar.xz' to branch 'upstream/latest'... gbp:info: Source package is libvirt gbp:info: Upstream version is 6.4.0 gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest'] gbp:debug: ['git', 'add', '-f', '.'] gbp:debug: ['git', 'write-tree'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest'] gbp:debug: ['git', 'commit-tree', '5d1f17e4035e01548d006d598922650408f56703', '-p', '1b6982f1b5d95a81eef1a112d0b1b228d7f910b2'] gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 6.4.0', 'refs/heads/upstream/latest', '46f45a63850c420af231a5c4186c5f9187c6b9b4', '1b6982f1b5d95a81eef1a112d0b1b228d7f910b2'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar'] gbp:debug: ['git', 'ls-tree', '-z', 'upstream/latest', '--'] gbp:debug: ['git', 'mktree', '-z'] gbp:debug: pristine-tar [] ['--help'] gbp:debug: pristine-tar [] ['commit', '../libvirt_6.4.0.orig.tar.xz', '5d1f17e4035e01548d006d598922650408f56703', '-s', '../libvirt_6.4.0.orig.tar.xz.asc'] gbp:error: Import of ../libvirt_6.4.0.orig.tar.xz failed: Couldn't commit to 'pristine-tar' with upstream '5d1f17e4035e01548d006d598922650408f56703': pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz (Please file a bug report.) pristine-tar: failed to generate delta gbp:debug: rm ['-rf', '../tmp8pliau55'] [] Running pristine-tar again manually, to gather more information: $ pristine-tar --verbose --debug commit ../libvirt_6.4.0.orig.tar.xz 5d1f17e4035e01548d006d598922650408f56703 -s ../libvirt_6.4.0.orig.tar.xz.asc pristine-tar: git archive --format=tar 5d1f17e4035e01548d006d598922650408f56703 | (cd '/tmp/pristine-tar.zknL0MQpcM' && tar x) pristine-tar: set subdir to libvirt-6.4.0 pristine-tar: subdir is libvirt-6.4.0 pristine-tar: mkdir /tmp/pristine-tar.R46gh49xSl/workdir pristine-tar: mv /tmp/pristine-tar.zknL0MQpcM /tmp/pristine-tar.R46gh49xSl/workdir/libvirt-6.4.0 pristine-tar: tar cf /tmp/pristine-tar.R46gh49xSl/recreatetarball --owner 0 --group 0 --numeric-owner -C /tmp/pristine-tar.R46gh49xSl/workdir --no-recursion --mode 0644 --verbatim-files-from --files-from /tmp/pristine-tar.R46gh49xSl/manifest pristine-tar: pristine-xz -v -d --no-keep gendelta ../libvirt_6.4.0.orig.tar.xz /tmp/pristine-tar.bXsstH80WF/wrapper pristine-xz: pixz -d < ../libvirt_6.4.0.orig.tar.xz > /tmp/pristine-tar.ULPnMKQoAx/test pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz (Please file a bug report.) pristine-tar: failed to generate delta Downgrading pristine-tar to 1.46 from buster makes it possible to run gbp import-orig successfully, at which point both 1.46 and 1.47 are able to regenerate the tarball from the git branch. The Debian repository for libvirt is https://salsa.debian.org/libvirt-team/libvirt/ and the commits the various branches were pointing to when I encountered the issue are pristine-tar9964e57257 pristine-tar data for libvirt_6.2.0.orig.tar.xz upstream/latest 1b6982f1b5 New upstream version 6.2.0 debian/experimental 51d88f1e6f Document changes and release 6.2.0-1 The tarball I was trying to import is https://libvirt.org/sources/libvirt-6.4.0.tar.xz but I tried libvirt 6.3.0 as well and got the same results. A couple of months ago, when I imported libvirt 6.2.0, and indeed all the many times I used gbp import-orig before now, everything worked smoothly. In fact, I might
Bug#564943: Closing
On Sat, Apr 18, 2020 at 12:58:41PM +0200, Andrea Bolognani wrote: > This bug has been lingering, unsolved, for literally a decade now. > > In the intervening years, scrotwm has been renamed to spectrwm and > has moved from xlib to xcb among many, many other changes: at this > point, I would say it's unlikely that there is a significant chunk > of it that hasn't been rewritten at least a couple of times over > since 2010. > > It is thus my intention to close this bug report. I'll do so next > week, unless someone speaks up; of course, even after that has > happened, it will still be possible for anyone who disagrees with > this course of action to simply reopen it. Closing. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#602372: Intention to close
I have tried again today, and I can no longer reproduce the issue with spectrwm 3.3.0-1. Accordingly, I will mark this bug as resolved next week, unless someone gets back to me reporting that they are still hitting it. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#564943: Intention to close
This bug has been lingering, unsolved, for literally a decade now. In the intervening years, scrotwm has been renamed to spectrwm and has moved from xlib to xcb among many, many other changes: at this point, I would say it's unlikely that there is a significant chunk of it that hasn't been rewritten at least a couple of times over since 2010. It is thus my intention to close this bug report. I'll do so next week, unless someone speaks up; of course, even after that has happened, it will still be possible for anyone who disagrees with this course of action to simply reopen it. -- 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#928902: spectrwm FTCBFS: uses build architecture build tools
On Mon, Mar 23, 2020 at 10:56:34PM +0100, Andrea Bolognani wrote: > I have written a commit message and prepared a git-compatible patch, > which you can find attached. Of course I've retained full authorship. > Are you okay with me submitting it upstream? Since you have provided the patch in the first place and you haven't voiced your disagreement with my plan, I've gone ahead and submitted it upstream as https://github.com/conformal/spectrwm/pull/296 I'll upload a Debian package that contains it, along with the other changes necessary to fix this bug, shortly. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#928902: spectrwm FTCBFS: uses build architecture build tools
On Sun, May 26, 2019 at 03:03:13PM +0200, Helmut Grohne wrote: > On Sun, May 26, 2019 at 10:00:46AM +0200, Andrea Bolognani wrote: > > Can you please provide instructions I can use to reproduce the build > > failure? The way you tackled it looks sensible enough, but I'd like > > to play around a bit myself :) > > sbuild¹: Pass --host=somearch. > pbuilder: Pass --host-arch somearch > dpkg-buildpackage: DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --build=any > --host-arch somearch --profiles cross,nocheck Hi Helmut, it's been an embarrassingly long time, I know :( Anyway, I'm updating the spectrwm package and wanted to make sure cross-building works fine once the new version hits the archive. I have already both reproduced the issue you reported, and verified that your changes address it. I am still polishing debian/rules, for which I've landed on a slighly different solution than you had, but in the meantime I would like to submit the linux/Makefile changes for consideration upstream, as they are in no way Debian-specific. I have written a commit message and prepared a git-compatible patch, which you can find attached. Of course I've retained full authorship. Are you okay with me submitting it upstream? Thank you for your patches, and your patience :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. From a6fdbde54a42c190218066ac28de11b3c7995cae Mon Sep 17 00:00:00 2001 From: Helmut Grohne Date: Sun, 12 May 2019 19:59:22 +0200 Subject: [PATCH] linux: Accept user-provided pkg-config command When cross-building, it's necessary to use versions of the various toolchain commands that have been built specifically to target the desired architecture, and that are named accordingly. In practice, the make invocation will look something like $ make CC=aarch64-linux-gnu-gcc \ PKG_CONFIG=aarch64-linux-gnu-pkg-config However, whereas $(CC) is a built-in make variable and so it behaves correctly out of the box, for $(PKG_CONFIG) we have to do some work ourselves. --- linux/Makefile | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/linux/Makefile b/linux/Makefile index 4016c2b..105f0f0 100644 --- a/linux/Makefile +++ b/linux/Makefile @@ -6,6 +6,7 @@ DATAROOTDIR ?= $(PREFIX)/share MANDIR ?= $(DATAROOTDIR)/man DOCDIR ?= $(DATAROOTDIR)/doc/spectrwm XSESSIONSDIR ?= $(DATAROOTDIR)/xsessions +PKG_CONFIG ?= pkg-config BUILDVERSION= $(shell sh $(CURDIR)/../buildver.sh) LIBVERSION = $(shell . $(CURDIR)/../lib/shlib_version; echo $$major.$$minor) @@ -21,12 +22,12 @@ endif BIN_CFLAGS = -fPIE BIN_LDFLAGS = -fPIE -pie -BIN_CPPFLAGS = $(shell pkg-config --cflags x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft) -BIN_LDLIBS = $(shell pkg-config --libs x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft) +BIN_CPPFLAGS = $(shell $(PKG_CONFIG) --cflags x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft) +BIN_LDLIBS = $(shell $(PKG_CONFIG) --libs x11 x11-xcb xcb-icccm xcb-keysyms xcb-randr xcb-util xcb-xinput xcb-xtest xcursor xft) LIB_CFLAGS = -fPIC LIB_LDFLAGS = -fPIC -shared -LIB_CPPFLAGS = $(shell pkg-config --cflags x11) -LIB_LDLIBS = $(shell pkg-config --libs x11) -ldl +LIB_CPPFLAGS = $(shell $(PKG_CONFIG) --cflags x11) +LIB_LDLIBS = $(shell $(PKG_CONFIG) --libs x11) -ldl all: spectrwm libswmhack.so.$(LIBVERSION) -- 2.25.1 signature.asc Description: PGP signature
Bug#952526: pkgconf: Missing Depends on dpkg-dev
Package: pkgconf Version: 1.6.3-4 Severity: normal Tags: patch The pkg-config-crosswrapper script uses dpkg-architecture (part of dpkg-dev) internally; if that package is not installed, the script will not fail explicitly, but happily report incorrect information instead. For example, on an x86_64 machine that is set up to cross-compile for aarch64 $ dpkg -l libglib2.0-dev:arm64 | tail -1 ii libglib2.0-dev:arm64 2.58.3-2+deb10u2 arm64Development files for the GLib library $ when dpkg-dev is installed pkgconf behaves as expected $ aarch64-linux-gnu-pkg-config --path glib-2.0 /usr/lib/aarch64-linux-gnu/pkgconfig/glib-2.0.pc $ whereas uninstalling dpkg-dev results in $ aarch64-linux-gnu-pkg-config --path glib-2.0 $ I'll open a MR on Salsa in a minute. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pkgconf depends on: ii libc6 2.29-10 ii libdpkg-perl 1.19.7 ii perl 5.30.0-9 pkgconf recommends no packages. pkgconf suggests no packages. -- no debconf information
Bug#928902: spectrwm FTCBFS: uses build architecture build tools
On Sun, May 12, 2019 at 08:07:20PM +0200, Helmut Grohne wrote: > spectrwm fails to cross build from source, because it does not pass > cross tools to make. The easiest way of fixing that - using > dh_auto_build - is insufficient here. The relevant Makefile also hard > codes pkg-config. The attached patch fixes both and makes spectrwm cross > buildable. Please consider applying it. Hi, thanks for reporting this issue. Can you please provide instructions I can use to reproduce the build failure? The way you tackled it looks sensible enough, but I'd like to play around a bit myself :) Thanks. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#829709: libxcb-randr0-dev: Should use Requires.private in pkg-config file
Looks like the issue was addressed at some point during the past two years: $ grep xcb-render /usr/lib/x86_64-linux-gnu/pkgconfig/xcb-randr.pc Requires.private: xcb xcb-render $ And accordingly: $ pkg-config --libs xcb-randr -lxcb-randr $ I believe the bug can be closed now. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#901733: ITP: libvirt-dbus -- libvirt D-Bus API bindings
Package: wnpp Severity: wishlist Owner: Andrea Bolognani * Package name: libvirt-dbus Version : 1.0.0 Upstream Author : various * URL : https://libvirt.org/ * License : LGPL-2+ Programming Lang: C Description : libvirt D-Bus API bindings Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). The library aims at providing a long term stable C API for different virtualization mechanisms. It currently supports QEMU, KVM, XEN, OpenVZ, LXC, and VirtualBox. . This package provides access to the libvirt API through D-Bus. The plan is to eventually maintain this under the Libvirt Packaging Team umbrella. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#884785: lintian: False positives for timewarp-standards-version
Package: lintian Severity: normal The timewarp-standards-version check is apparently not dealing correctly with the corner case of a package being released the same day as the Debian Policy it complies with. From a quick look at the corresponding report[1], I've found a small number of false positives: deepin-shortcut-viewer 1.3.3-1 * (2017-11-30 < 2017-11-30) liberasurecode 1.5.0-1 * (2017-08-06 < 2017-08-06) libio-all-lwp-perl 0.14-1 * (2009-06-16 < 2009-06-16) libwx-perl-datawalker-perl 0.02-1 * (2009-06-16 < 2009-06-16) spectrwm 3.1.0-1 * (2017-11-30 < 2017-11-30) Sorry, I don't speak Perl, so I'm unable to come up with anything resembling a reasonable patch :) [1] https://lintian.debian.org/tags/timewarp-standards-version.html -- Andrea Bolognani <e...@kiyuko.org> Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#684174: spectrwm: Some key bindings (M-j, M-k) don't work.
Hi Anthony, I tried to reproduce this issue with spectrwm 3.0.2, which has been available in testing for a couple of weeks now. I configured spectrwm with modkey = Mod4 to match your setup and started unclutter -idle 1 from a terminal window. The mouse cursor disappears after one second of inactivity, as expected. Moreover all keyboard shorcuts I've tested, notably M-j, M-k and M-m, work reliably. I think it's fair to assume the bug has been fixed in the meantime. Would you mind giving 3.0.2 a try and see if you're still hitting it? Thanks :) -- Andrea Bolognani <e...@kiyuko.org> Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#829709: libxcb-randr0-dev: Should use Requires.private in pkg-config file
Package: libxcb-randr0-dev Version: 1.11.1-1 Severity: normal The pkg-config file for xcb-randr contains Requires: xcb xcb-render which in turn results in $ pkg-config --libs xcb-randr -lxcb-randr -lxcb-render -lxcb Applications using xcb-randr don't need to link against xcb-render unless they're using some of xcb-render's symbols; the fact that xcb-randr itself uses xcb-render internally is irrelevant to the application, and in fact 1) dpkg-shlibdeps will raise a warning about this during package build 2) passing --as-needed to the linker will strip the direct dependency on xcb-render from the binary Some of xcb-randr's functions use types defined by xcb-render as arguments, but that again doesn't create a requirement for the application to link against xcb-render, it just means it will have to include the appropriate headers. The pkg-config file should be changed to look like Requires: xcb Requires.private: xcb-render Well, xcb should be moved to Requires.private as well, and the same should be done for all xcb-* pkg-config files. But applications linking against any of the xcb-* libraries are pretty much guaranteed to link agains xcb as well, so it's not as critical. But it should still be done :) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libxcb-randr0-dev depends on: ii libxcb-randr0 1.11.1-1 ii libxcb-render0-dev 1.11.1-1 ii libxcb1-dev 1.11.1-1 libxcb-randr0-dev recommends no packages. libxcb-randr0-dev suggests no packages. -- no debconf information -- Andrea Bolognani <e...@kiyuko.org> 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#772431: spectrwm: fix FTBFS with ld --as-needed
On Sat, Dec 06, 2014 at 06:15:52PM -0500, Logan Rosen wrote: Even though Debian doesn't use ld --as-needed by default, it is a good idea to make this change so that (1) we don't have to maintain a delta and (2) you don't need to change anything in case Debian makes this default in the future. Hi Logan, both are sensible points and I'm definitely going to look at this after Jessie is out of the door. I'm not familiar with the compiler flag we're discussing, though, so if you'd kindly point to some documentation on the subject, that'd be much appreciated :) Have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#768885: Performance has plummeted compared to 'wheezy'
On Wed, Nov 19, 2014 at 07:58:50AM +, Robert de Bath wrote: [...] this list is also endless. It certainly is, and I'm not interested in implementing all of these suggestions. Some look very promising though, so I'll definitely try to integrate them in Cattle. I look forward to your next version, but, seriously, this version should be withdrawn until it's performance is better. I'd accept sort of okay, after all it'd be a lot better than now. I'm sorry Beef doesn't fit your use case anymore. That said, at this point in the release schedule there's not much I can do about it. How about a little starter ... with the rather appropriate/inappropriate name of 'deadbeef' https://gist.github.com/rdebath/a12653a3c167cf93ab6a That looks great! Why don't you get it packaged? Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#768885: Performance has plummeted compared to 'wheezy'
On Sun, Nov 09, 2014 at 09:49:59PM +, Robert de Bath wrote: The performace of the 1.0.1 version has dropped by about 98% compared to version 0.0.6 in wheezy. It now runs far slower than a naïve implementation such as the 22 line 'microbf' program and clocks in at around 2 times slower than the fastest implementations. The 0.0.6 version was already one of the slower C based interpreters around but the version 1.0.1 performance is well below the norm and in the range normally occupied by interpreters written in intepreted languages. There is obviously a serious problem here. Hi Robert, Beef's focus is on flexibilty rather than performance: as you noticed, previous versions were not among the fastest Brainfuck interpreters either. The latest version is a complete rewrite on top of Cattle, a GObject-based library, which of course introduces some overhead. That said, I agree with you that performance is not as good as it could, and should, be. In fact, now that the rewrite is complete, my main focus will be making it faster, but of course that will have to wait until jessie+1. Thank you for your interest in Beef. Have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#689226: Backport to wheezy
On Mon, Sep 15, 2014 at 10:23:21AM +0200, Ondřej Grover wrote: as I've said earlier, this package can also be easily backported to stable Wheezy. Should I open a new bug for that? Hi, the package, as uploaded to unstable, can in fact be compiled and run on Wheezy without changes. I'm not familiar with backports, but by quickly reading the Contribute page[1] I get the impression maintaining a backport is additional ongoing work. Do you think it would be worth it, seeing as we're supposedly just a few months away from the next stable release? Cheers. [1] http://backports.debian.org/Contribute/ -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#689226: 2.6.0 imported and built successfully
On Mon, Aug 25, 2014 at 01:37:56PM +0200, Ondřej Grover wrote: thank you for the instructions Andrea, it turned out that I found the clone URL on the page linked in Vcs-Browser field from the `apt-cache showsrc spectrwm` output, but I should have used the one in the Vcs-Git field.Should I file a bug at Alioth about this? The data returned by that command is outdated. I've updated the value of Vcs-Browser so that it points to the correct URL. I have no idea why there seems to be a gitweb instance returning stale data while Alioth has switched to cgit. Feel free to investingate further if you feel like it :) To give back I decided to test importing the 2.6.0 version and it worked: The repository now contains 2.6.0 as well. By the way, it's great seeing Debian patches being adopted by upstream, just the way distributions should collaborate with upstream IMHO. Having a minimal delta with respect to upstream has always been one of my goals. In the past getting patches merged upstream has been difficult but lately, thanks I guess to the increased number of people with commit rights and to the switch to git and GitHub, it's been really quite easy. Have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#689226: Great to see ongoing development
On Sat, Aug 23, 2014 at 05:02:37PM +0200, Ondřej Grover wrote: I just want to say that I'm glad to see that there is a lot going on in the package git VCS https://alioth.debitan.org/anonscm/git/collab-maint/spectrwm.git I cloned the repo, but it doesn't seem to be in shape for git-buildpackage to work. Can I be of any assistance in some way? Hi, there seem to have been some changes on Alioth since the repository URL was published, please clone git://anonscm.debian.org/collab-maint/spectrwm.git instead. I tried running git-buildpackage from a fresh clone, after moving my ~/.gbp.conf out of the way and I got a succesful build. Please let me know if you still have issues after cloning from the new URL. In the debianized source I noticed that Xcursor references were removed, but after installing libxscursor-dev the vanilla package compiles and works fine, as does the debianized one. So I'm wondering what is the reason for removing that library dependency. The build dependency on libxcursor-dev is still there. I routinely build the package using pbuilder to make sure no build dependency is missing, so this too is probably caused by the fact that you have been cloning from the wrong URL. This is on wheezy, so I think spectrwm could be easily backported, which would be much appreciated. I'm doing all the packaging work on wheezy and I can confirm that spectrwm works perfectly fine there. By the way, 2.6.0 was just released. Thanks for the heads up. Have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#689226: spectrwm: please package the latest version
On Sun, Apr 07, 2013 at 06:24:54PM +0200, Yuri D'Elia wrote: Is there any news on the repackaging? I'm running spectrwm 2.2.0 (hand-build) and there are *many* fixed issues that I couldn't work with. Hi Yuri, real life kinda took over, and with the freeze already underway I figured there was no need to hurry. I tend to forget plenty of people are willing to pin packages from experimental ;) AFAIR 2.0.0 was pretty far along, and shaping up nicely. I'll definitely try to channel more of my spare time into this. Thank you for your interest in spectrwm. Have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#695502: beef: Add support for EsoAPI
On Sun, Dec 09, 2012 at 11:16:38PM +1300, Hugh Davenport wrote: Hi! Sorry for the late reply. There is an extension to Brainfuck (as well as other esoterical languages) called EsoAPI (mentioned http://esolangs.org/wiki/EsoAPI, defined http://kidsquid. 99k .org/programs/esoapi/esoapi.html, example implemention http://esolangs.org/wiki/User:JayCampbell/weave.rb). Didn't know about it. I like the fact that, unlike most specifications, this one is so tiny one can actually understand it :) I've attached a patch to add support for this API to the beef source. I haven't yet done it for the version in experimental (1.0.0) yet. I have taken a quick look at your patch and it seems completely reasonable. Unfortunately the standalone version of Beef is now considered legacy, and no further development is supposed to happen there: all new features have to be added to Cattle, where the Brainfuck runtime used by Beef is actually implemented. You can test via the attache esoapi-hello.bf. Before the patch it will print EsoAPI required\n, and after the patch will print Hello World!\n Hello World aside, can you point out an actual use for this feature? I'm having a hard time coming up with one myself ;) Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#692863: ITP: heimdall -- tool for flashing firmware on Samsung Galaxy S devices
On Fri, Nov 09, 2012 at 01:43:35PM -0800, Steve Langasek wrote: The naming of this tool is entirely logical from the upstream's perspective, given that there are other related pieces of software called Odin and Loke. However, there's an unfortunate namespace collision here with the Kerberos implementation Heimdal. Suggestions welcome on how to qualify the source package name so that the packages are more than one letter off from one another... samsung-heimdall seems like an obvious choice to me. Don’t know whether using the word “Samsung” in the package name could cause legal troble down the line, though. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#689226: spectrwm: please package the latest version
On Sun, Sep 30, 2012 at 04:47:24PM +0200, david wrote: Dear Maintainer, spectrwm version 2.0 was released last month. it provides alot of new and exciting features (quoted from https://opensource.conformal.com/fluxbb/viewtopic.php?id=540): * complete rewrite using xcb * 100% backwards compatible * way more responsive and snappy * Tons of warts fixed * cygwin works again * xft fonts i hope this lands in debian soon :) Hello David, thanks for your interest in spectrwm. Work on packaging spectrwm 2.0.0 (and beyond, 2.0.2 has been released too) is already underway. As you can imagine, being a major release, it will take a little more effort than your average update, so please bear with us! Have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#684174: solved
On Tue, Aug 07, 2012 at 11:27:51PM +0100, Anthony Campbell wrote: OK, I found the problem: I was running unclutter and for some reason this was stopping some key presses from working. After killing it everything worked as it should. Hi, glad you found a way to work around the problem. Still, given Spectrwm’s target audience, I’d say upstream might be interested in having it play nice with unclutter. Moreover, this might turn out to be a legitimate bug in unclutter for all we know. Let’s notify upstream of the issue and see what comes out of it. Happy hacking! -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2
On Mon, Jun 18, 2012 at 09:12:40AM +0200, Jakub Wilk wrote: Have you forwarded these patches upstream? I planned to forward them as soon as the package was accepted into Debian, but as it’s apparently going to take very long I have done it yesterday. You changed priority from extra to option, but this is not documented in the changelog. I have updated the changelog to briefly explain the rationale behind the priority bump. The updated package is available from mentors.d.n, if anyone is interested. Thank you for taking a look at it! -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Hi everybody, this is just to remind you that Rhinote is still looking for a sponsor. As the changes for this revision are mostly patches to the software itself, which is written in Python, I'm CCing the python-apps Team hoping that someone will consider picking it up. Cheers. On Thu, Mar 08, 2012 at 10:58:50PM +0100, Andrea Bolognani wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rhinote * Package name: rhinote Version : 0.7.4-2 Upstream Author : Marv Boyes greysp...@tuxfamily.org * URL : http://rhinote.tuxfamily.org/ * License : GPL-2+ Section : x11 It builds those binary packages: rhinote- virtual sticky-notes for your desktop To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhinote Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc More information about rhinote can be obtained from http://rhinote.tuxfamily.org/ . Changes since the last upload: * 001-simplify-imports.diff: - improve the way modules are imported. * 002-use-secure-printfile.diff: - avoid potential symlink attacks and cluttering the user's home. * 003-test-for-external-commands.diff: - ensure external commands are available before calling them. * 004-use-popen.diff: - replace os.system() with the more secure subprocess.Popen(). * 005-support-lp.diff: - add support for the lp command in addition to lpr. * 006-set-print-job-name.diff: - provide a descriptive name for the print job. * 007-set-class-name.diff: - set application name for use by window managers. * Simplify Depends: to cups-client | lpr. * Bump Standards-Version to 3.9.3 (no changes needed). The software has been heavily patched after Paul Wise has reviewed it[1] and found a bunch of issues with upstream’s code. He later took a look at the patches[2] and found them to be okay. [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673549: RFS: beef/1.0.0-1
Nobody? Beef is currently the only Brainfuck interpreter available in Debian, and the package that's going to be included in Wheezy, if nobody steps up for an upload, is FIVE years old – as opposed to this one, which is only a year old ;) Please consider taking a look at Beef, and also at Cattle (ITP #673550), which is a dependency for Beef. Thank you. On Sat, May 19, 2012 at 05:14:22PM +0200, Andrea Bolognani wrote: I am looking for a sponsor for my package beef * Package name: beef Version : 1.0.0-1 Upstream Author : Andrea Bolognani e...@kiyuko.org * URL : http://kiyuko.org/software/beef * License : GPL-2+ Section : devel It builds these binary packages: beef - flexible Brainfuck interpreter To access further information about this package, please visit the following URL: http://mentors.debian.net/package/beef Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/beef/beef_1.0.0-1.dsc Changes in this release: * New upstream release. (Closes: #639247) * Fix watch file. (Closes: #529748) * U01-fix-whatis-entry.diff: - use the conventional format for the NAME section of the man page, so that programs such as whatis and apropos can parse it. * D01-skip-documentation-files.diff: - don't install duplicated documentation files. * D02-leave-changelog-alone.diff: - don't overwrite upstream changelog. * Switch to 3.0 (quilt) source format. * Switch to compat level 9. * Update Debian copyright file to DEP5 candidate version. * Add Vcs-* control fields. * Bump Standards-Version to 3.9.3 (no changes needed). -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673549: RFS: beef/1.0.0-1 -- flexible Brainfuck interpreter
Any takers? On Sat, May 19, 2012 at 05:14:22PM +0200, Andrea Bolognani wrote: Dear mentors, I am looking for a sponsor for my package beef * Package name: beef Version : 1.0.0-1 Upstream Author : Andrea Bolognani e...@kiyuko.org * URL : http://kiyuko.org/software/beef * License : GPL-2+ Section : devel It builds these binary packages: beef - flexible Brainfuck interpreter To access further information about this package, please visit the following URL: http://mentors.debian.net/package/beef Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/beef/beef_1.0.0-1.dsc Changes in this release: * New upstream release. (Closes: #639247) * Fix watch file. (Closes: #529748) * U01-fix-whatis-entry.diff: - use the conventional format for the NAME section of the man page, so that programs such as whatis and apropos can parse it. * D01-skip-documentation-files.diff: - don't install duplicated documentation files. * D02-leave-changelog-alone.diff: - don't overwrite upstream changelog. * Switch to 3.0 (quilt) source format. * Switch to compat level 9. * Update Debian copyright file to DEP5 candidate version. * Add Vcs-* control fields. * Bump Standards-Version to 3.9.3 (no changes needed). I would be glad if someone could upload this package for me. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673550: RFS: cattle-1.0/1.0.1-1 [ITP] -- Brainfuck language toolkit
Any takers? On Sat, May 19, 2012 at 05:23:10PM +0200, Andrea Bolognani wrote: Dear mentors, I am looking for a sponsor for my package cattle-1.0 * Package name: cattle-1.0 Version : 1.0.1-1 Upstream Author : Andrea Bolognani e...@kiyuko.org * URL : http://kiyuko.org/software/cattle * License : GPL-2+ Section : libs It builds these binary packages: libcattle-1.0-0 - Brainfuck language toolkit gir1.2-cattle-1.0 - Brainfuck language toolkit (introspection files) libcattle-1.0-dev - Brainfuck language toolkit (development files) libcattle-1.0-doc - Brainfuck language toolkit (API reference) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cattle-1.0 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cattle-1.0/cattle-1.0_1.0.1-1.dsc Changes in this release: * Initial release. (Closes: #617304) * D01-tweak-build-system.diff: - avoid building example programs to speed up compilation. Cattle is a dependency for the latest release of Beef, which is already in Debian and for which I've filed a separate RFS as #673549. I would be glad if someone could upload this package for me. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Dear mentors, Rhinote is still looking for a sponsor, and it’s been a while so I think it’s a good time to bump the thread. As you can see from the full bug report for this RFS (#663151) this updated packages contains code tweaks that make Rhinote much better overall, and that Rhinote users would certainly appreciate having in a stable release. Please consider taking a look at the package and sponsoring it. Thank you. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673549: RFS: beef/1.0.0-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package beef * Package name: beef Version : 1.0.0-1 Upstream Author : Andrea Bolognani e...@kiyuko.org * URL : http://kiyuko.org/software/beef * License : GPL-2+ Section : devel It builds these binary packages: beef - flexible Brainfuck interpreter To access further information about this package, please visit the following URL: http://mentors.debian.net/package/beef Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/beef/beef_1.0.0-1.dsc Changes in this release: * New upstream release. (Closes: #639247) * Fix watch file. (Closes: #529748) * U01-fix-whatis-entry.diff: - use the conventional format for the NAME section of the man page, so that programs such as whatis and apropos can parse it. * D01-skip-documentation-files.diff: - don't install duplicated documentation files. * D02-leave-changelog-alone.diff: - don't overwrite upstream changelog. * Switch to 3.0 (quilt) source format. * Switch to compat level 9. * Update Debian copyright file to DEP5 candidate version. * Add Vcs-* control fields. * Bump Standards-Version to 3.9.3 (no changes needed). I would be glad if someone could upload this package for me. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#673550: RFS: cattle-1.0/1.0.1-1 [ITP] -- Brainfuck language toolkit
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package cattle-1.0 * Package name: cattle-1.0 Version : 1.0.1-1 Upstream Author : Andrea Bolognani e...@kiyuko.org * URL : http://kiyuko.org/software/cattle * License : GPL-2+ Section : libs It builds these binary packages: libcattle-1.0-0 - Brainfuck language toolkit gir1.2-cattle-1.0 - Brainfuck language toolkit (introspection files) libcattle-1.0-dev - Brainfuck language toolkit (development files) libcattle-1.0-doc - Brainfuck language toolkit (API reference) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cattle-1.0 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cattle-1.0/cattle-1.0_1.0.1-1.dsc Changes in this release: * Initial release. (Closes: #617304) * D01-tweak-build-system.diff: - avoid building example programs to speed up compilation. Cattle is a dependency for the latest release of Beef, which is already in Debian and for which I've filed a separate RFS as #673549. I would be glad if someone could upload this package for me. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2 -- virtual sticky-notes for your desktop
Dear mentors, please consider reviewing and sponsoring this new Rhinote upload. As you can see from the changelog entry reported below, the updated package contains several improvements that would make using Rhinote much better; moreover, a Debian member has already reviewed the patches and found them to be okay. Thank you for your time. On Thu, Mar 08, 2012 at 10:58:50PM +0100, Andrea Bolognani wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rhinote * Package name: rhinote Version : 0.7.4-2 Upstream Author : Marv Boyes greysp...@tuxfamily.org * URL : http://rhinote.tuxfamily.org/ * License : GPL-2+ Section : x11 It builds those binary packages: rhinote- virtual sticky-notes for your desktop To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhinote Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc More information about rhinote can be obtained from http://rhinote.tuxfamily.org/ . Changes since the last upload: * 001-simplify-imports.diff: - improve the way modules are imported. * 002-use-secure-printfile.diff: - avoid potential symlink attacks and cluttering the user's home. * 003-test-for-external-commands.diff: - ensure external commands are available before calling them. * 004-use-popen.diff: - replace os.system() with the more secure subprocess.Popen(). * 005-support-lp.diff: - add support for the lp command in addition to lpr. * 006-set-print-job-name.diff: - provide a descriptive name for the print job. * 007-set-class-name.diff: - set application name for use by window managers. * Simplify Depends: to cups-client | lpr. * Bump Standards-Version to 3.9.3 (no changes needed). The software has been heavily patched after Paul Wise has reviewed it[1] and found a bunch of issues with upstream’s code. He later took a look at the patches[2] and found them to be okay. [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#664682: spectrwm: debian menu entry
On Tue, Mar 20, 2012 at 08:24:19AM +1100, Kevin Ryde wrote: It'd be good if spectrwm was in the debian window managers menu to switch to it from another window manager. Hi Kevin, I agree with you, having such an entry would probably be a good idea. In the coming days I’ll be sure to check out your proposed patch, make sure it complies with all relevant Debian standards, test it and, once everything is in order, prepare a new spectrwm upload including it. Thank you for your interest in spectrwm, and have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#664674: override: scrotmw:oldlibs/extra
Package: ftp.debian.org Severity: normal Owner: e...@kiyuko.org Hi, scrotwm has recently been renamed to spectrwm upstream; as a consequence of this change, as of version 1.0.0-1 the scrotwm binary package is a dummy package meant to ease transitions. Having the scrotwm binary package in section oldlibs with priority extra helps package managers see that it’s in fact a transitional package, so please update the override files. Thank you. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#664675: RM: scrotwm -- ROM; renamed to spectrwm
Package: ftp.debian.org Severity: normal Hi, scrotwm has been renamed upstream to spectrwm. As the recently uploaded spectrwm source package builds a transitional binary package which provides a smooth upgrade path, the scrotwm source package can safely be removed from the archive. Thank you. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#663151: RFS: rhinote/0.7.4-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rhinote * Package name: rhinote Version : 0.7.4-2 Upstream Author : Marv Boyes greysp...@tuxfamily.org * URL : http://rhinote.tuxfamily.org/ * License : GPL-2+ Section : x11 It builds those binary packages: rhinote- virtual sticky-notes for your desktop To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhinote Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-2.dsc More information about rhinote can be obtained from http://rhinote.tuxfamily.org/ . Changes since the last upload: * 001-simplify-imports.diff: - improve the way modules are imported. * 002-use-secure-printfile.diff: - avoid potential symlink attacks and cluttering the user's home. * 003-test-for-external-commands.diff: - ensure external commands are available before calling them. * 004-use-popen.diff: - replace os.system() with the more secure subprocess.Popen(). * 005-support-lp.diff: - add support for the lp command in addition to lpr. * 006-set-print-job-name.diff: - provide a descriptive name for the print job. * 007-set-class-name.diff: - set application name for use by window managers. * Simplify Depends: to cups-client | lpr. * Bump Standards-Version to 3.9.3 (no changes needed). The software has been heavily patched after Paul Wise has reviewed it[1] and found a bunch of issues with upstream’s code. He later took a look at the patches[2] and found them to be okay. [1] http://lists.debian.org/debian-mentors/2012/01/msg00579.html [2] http://lists.debian.org/debian-mentors/2012/02/msg00077.html -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#649033: [PATCH] tpm_tis: add delay after aborting command
On Mon, Feb 27, 2012 at 12:56:45AM -0600, Jonathan Nieder wrote: Andrea Bolognani wrote: Is this patch (or a similar one) enabled in Debian’s 3.2 kernels? Yes, the patch was part of upstream 3.2.3. As the top of [1] says: Found in versions 3.1.6-1, 3.1.8-2, 3.2.1-2 Fixed in version 3.2.4-1 From /usr/share/doc/linux-image-3.2.0-1-amd64/changelog.Debian.gz: linux-2.6 (3.2.4-1) unstable; urgency=low * New upstream stable update: http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.3 http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.4 [...] - tpm_tis: add delay after aborting command (Closes: #649033) Thanks for your interest, and hope that helps. I guess I should have checked that ;) For what it’s worth, I can confirm the patch does indeed fix the issue on my system. Thank you for your work! -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#649033: [PATCH] tpm_tis: add delay after aborting command
On Fri, Jan 20, 2012 at 04:30:27PM -0600, Jonathan Nieder wrote: Stefan Berger wrote: On 01/20/2012 11:18 AM, Uwe Kleine-König wrote: (probe_itpm was introduced to drivers/char/tpm/tpm_tis.c in 9519de3f (tpm_tis: Probing function for Intel iTPM bug) . That is it hit mainline for v3.1-rc1.) I take it's not a problem in a Debian 3.0 kernel (since the culprit patch only appeared in 3.1-rc1). We will submit the relevant patch(es) to the 3.2.x stable kernel. Perfect. Thanks, Stefan! Is this patch (or a similar one) enabled in Debian’s 3.2 kernels? I’ve been running 3.2 since it hit testing (I’m on 3.2.4-1 now) and the boot has not hanged once so far. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#657698: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
On Thu, Feb 02, 2012 at 03:14:56PM +0100, Stefan Esser wrote: BTW: You should really really look into the history of PHP security and check for each of the last 8 years how many features were in Suhosin and later merged into PHP because of some nasty security problem. You will see that at least 2 features of Suhosin per year were merged into PHP. If that’s the case, then you have nothing to worry about. As more and more Suoshin features are merged into mainline PHP, Debian’s PHP package will get more and more secure. That’s the way it happens for many other packages, I fail to see why PHP should be treated differently. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
I’m seeing this too on my ThinkPad X201i. The kernel I’m running is linux-image-3.1.0-1-686-pae version 3.1.1-1. It happens quite frequently, most often when first booting in the morning; forcing a shutdown and trying booting again usually results in a normal boot. If there’s some debug output I can can collect to help track this down, please let me know. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#639247: beef: New major upstream version
On Thu, Aug 25, 2011 at 03:30:38PM +0300, Alexander Sedov wrote: beef author, Andrea Bolognani, had released a new version of beef, beef 1.0.0, in April, 9th. http://kiyuko.org/software/beef/releases Hi Alexander, thanks for your bug report. However, being both Debian maintainer *and* upstream developer for Beef, I already knew that ;) 1.0.0 is not a trivial upgrade from 0.0.6, even more so considering that it depends on Cattle, another software I’ve written and that requires packaging before Beef can be upgraded. I will certainly update the package, I just havent’t gotten around to do the work yet. Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#630001: gnome-shell: Network menu doesn’t work anymore
Package: gnome-shell Version: 3.0.2-1 Severity: important Hi, since I’ve updated to gnome-shell 3.0.2 yesterday, the network menu has stopped working. The network icon is displayed, with a red mark on the bottom right, and clicking on it opens a menu consisting of a single entry, “Network Settings”, which opens the System Settings application. NetworkManager still connects to my favourite networks, and notifications for network–related events are displayed as usual. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-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 gnome-shell depends on: ii dconf-gsettings-backend [gs 0.7.5-2 simple configuration storage syste ii gconf2 2.32.3-2 GNOME configuration database syste ii gir1.2-atk-1.0 2.0.0-1 The ATK accessibility toolkit (GOb ii gir1.2-clutter-1.0 1.6.14-1 GObject introspection data for the ii gir1.2-freedesktop 0.10.8-1 Introspection data for some FreeDe ii gir1.2-gconf-2.02.32.3-2 GNOME configuration database syste ii gir1.2-gdkpixbuf-2.02.23.3-3 GDK Pixbuf library - GObject-Intro ii gir1.2-gkbd-3.0 2.91.91-2GObject introspection data for the ii gir1.2-glib-2.0 0.10.8-1 Introspection data for GLib, GObje ii gir1.2-gnomebluetooth-1.0 3.0.0-1 Introspection data for GnomeBlueto ii gir1.2-gtk-3.0 3.0.10-1 GTK+ graphical user interface libr ii gir1.2-json-glib-1.00.13.2-1 GLib JSON manipulation library (in ii gir1.2-mutter-3.0 3.0.0-2 GObject introspection data for Mut ii gir1.2-networkmanager-1.0 0.8.998-1GObject introspection data for Net ii gir1.2-pango-1.01.28.3-6 Layout and rendering of internatio ii gir1.2-polkit-1.0 0.101-4 GObject introspection data for Pol ii gir1.2-telepathyglib-0.12 0.15.1-1 GLib Telepathy connection manager ii gir1.2-telepathylogger-0.2 0.2.10-1 Telepathy logger service - introsp ii gir1.2-upowerglib-1.0 0.9.11-1+b1 GObject introspection data for upo ii gjs 0.7.13-2 Mozilla-based javascript bindings ii gnome-bluetooth 3.0.0-1 GNOME Bluetooth tools ii gnome-icon-theme-symbolic 3.0.0-1 GNOME Desktop icon theme (symbolic ii gnome-settings-daemon 3.0.0.1-1daemon handling the GNOME session ii gsettings-desktop-schemas 3.0.1-1 GSettings deskop-wide schemas ii libatk1.0-0 2.0.0-1 The ATK accessibility toolkit ii libc6 2.13-6 Embedded GNU C Library: Shared lib ii libcairo-gobject2 1.10.2-6 The Cairo 2D vector graphics libra ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libcamel1.2-19 2.32.3-1 Evolution MIME message handling li ii libcanberra00.28-1 a simple abstract interface for pl ii libclutter-1.0-01.6.14-1 Open GL based interactive canvas l ii libcroco3 0.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.4.10-2 simple interprocess messaging syst ii libdbus-glib-1-20.94-2 simple interprocess messaging syst ii libdconf0 0.7.5-2 simple configuration storage syste ii libdrm2 2.4.25-3 Userspace interface to kernel DRM ii libebook1.2-10 3.0.0-1 Client library for evolution addre ii libecal1.2-83.0.0-1 Client library for evolution calen ii libedataserver1.2-143.0.0-1 Utility library for evolution data ii libedataserverui-3.0-0 3.0.0-1 GUI utility library for evolution ii libffi5 3.0.9-4 Foreign Function Interface library ii libfontconfig1 2.8.0-2.2generic font configuration library ii libfreetype62.4.4-1 FreeType 2 font engine, shared lib ii libgconf2-4 2.32.3-2 GNOME configuration database syste ii libgdk-pixbuf2.0-0 2.23.3-3 GDK Pixbuf library ii libgirepository-1.0-1 0.10.8-1 Library for handling GObject intro ii libgjs0b0.7.13-2 Mozilla-based javascript bindings ii libgl1-mesa-glx [libgl1]7.10.2-3 free implementation of the OpenGL ii libglib2.0-02.28.6-1 The GLib library of C routines ii libgnome-desktop-3-03.0.2-2 Utility library for loading .deskt ii libgnome-menu2 2.30.3-2+b1 an implementation of the freedeskt ii libgstreamer0.10-0 0.10.34-1Core GStreamer
Bug#630001: gnome-shell: Network menu doesn’t work anymore
On Fri, Jun 10, 2011 at 10:49:38AM -0300, Gustavo Noronha Silva wrote: Have you restarted/relogged in since then? I’ve rebooted several times. Anyway, I’ve just figured out what went wrong: I had updated gnome-shell, network-manager and network-manager-gnome, but gir1.2-networkmanager-1.0 was outdated. Upgrading it to 0.8.9997-1 from experimental and restarting the shell made the problem go away. So the bug here is that the dependency on gir1.2-networkmanager-1.0 is not versioned, while it probably should be, since apparentely gnome-shell requires a recent enough version. The same might be true for other introspection packages as well. Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#617304: ITP: cattle-1.0 -- Brainfuck language toolkit
Package: wnpp Severity: wishlist Owner: Andrea Bolognani e...@kiyuko.org * Package name: cattle-1.0 Version : 1.0.0 Upstream Author : Andrea Bolognani e...@kiyuko.org * URL : http://kiyuko.org/software/cattle * License : GPL-2+ Programming Lang: C Description : Brainfuck language toolkit Cattle is a toolkit for the Brainfuck programming language. . It can be embedded in any application to give it the ability to inspect and run Brainfuck programs; to make the interaction between the hosting application and the Brainfuck interpreter completely transparent, Cattle can be configured to use a custom set of I/O routines instead of the default ones. NOTE: Cattle will be a dependency for future versions of Beef. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602372: scrotwm: Dialogue windows appearing on wrong tag
On Thu, Nov 04, 2010 at 10:24:26AM +0100, Hannes Schueller wrote: This happens with GTK applications. Could be the same with other 'graphical' (i.e. X-based) programs, but I have no way of checking. Steps to reproduce: - open an application on tag 1 - send the applicaton to another tag - have the application open a dialogue window (e.g. file open dialogue) - the dialogue window appears on tag 1 instead of the current one It is not a problem of an individual application, I tested it with many different ones. I’ve seen this behaviour in all versions of scrotwm, too. The reason why this happens is that, when an application is spawned inside scrotwm, the libswmhack library that is LD_PRELOADed intercepts the call to XCreateWindow, reads the _SWM_WS environment variable, and stores that value in a window property; that window property is then used by scrotwm to decide which workspace the window belongs to. The fact is, the _SWM_WS environment variable doesn’t change over the lifetime of a window: if you spawn a terminal on workspace 1, the terminal environment contains _SWM_WS=0, and that environment is inherited by any program spawned from within that terminal; moving the terminal to, say, workspace 5 doesn’t alter the value of the _SWM_WS environment variable, so any program spawned from that terminal will always be associated to workspace 1. To test this out, you can spawn a terminal in workspace 1 and the execute $ _SWM_WS=5 someprogram you’ll see that someprogram is spawned on workspace 4. I’m personally not sure how useful libswmhack is, and not LD_PRELOADing it fixes this bug, but may cause other problems. I’ve CCed Marco to see what he thinks of it. Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: potential fix in cvs
On Sat, Oct 23, 2010 at 10:42:14PM +0400, Dmitry Derjavin wrote: Tried the package from http://alioth.debian.org/~ab-guest/ The bug did not go away. sleep still helps. Thank you for taking the time to check it out. I guess the specific bug you’re hitting has not been ironed out yet. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: potential fix in cvs
On Sat, Oct 23, 2010 at 10:33:45AM -0500, Marco Peereboom wrote: Fwiw debian's package is really old and has some real issues. 0.9.27 has no known crashes etc. I know, but Squeeze is under deep freeze and the rules are clear: no new version of a package can be uploaded unless it fixes a bug of RC severity, that is, so grave that it renders the package unusable. If you can find a bug with such gravity that is present in 0.9.20 and not present in 0.9.27, then we can maybe get a freeze exception and upload the newest version for inclusion in Squeeze. Otherwise, the newest version will be uploaded after Squeeze has been released. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: potential fix in cvs
On Sun, Oct 24, 2010 at 04:02:08PM +0200, Hannes Schüller wrote: The i386 package seems to work on my laptop (only a very brief test so far, though). That’s great news! To use it on amd64, I just take the original source, apply the Debian specific patches and then compile? You need to have build-essential and dpkg-dev installed, plus the Build-Depends for scrotwm (apt-get build-dep scrotwm to install them). Then use `dpkg-source -x scrotwm_0.9.27-1.dsc' to unpack the source package (patches are applied automatically), enter the scrotwm-0.9.27 directory, and run `dpkg-buildpackage' to obtain a binary package. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: potential fix in cvs
On Fri, Oct 15, 2010 at 02:56:38PM +0200, Andrea Bolognani wrote: It’s usually preferred to only package released tarballs, so once you have published a new snapshot, drop me a line so I can update the package. Once an updated package is ready, I’ll need to have Dmitry and Hannes test it and confirm whether the bug is gone. If that is the case, we might be able to get a freeze exception. In fact, the package in Debian is so outdated only because squeeze froze just a few days before my sponsor had a chance to upload 0.9.25. Marco has released 0.9.27, and I have updated the Debian packaging. Dmitry and Hannes, please test this release and let me know if it fixes the bug for you. I have prepared a binary package for i386[1], and of course the source package[2] is available as well. I am unable to build amd64 packages since I don’t own any 64–bit machine yet. Unfortunately, I see now that the unblock policy has been recently made more strict[3], and new versions are allowed only if the package has RC severity, so this release will be targeted at Squeeze+1 in any case. [1] http://alioth.debian.org/~ab-guest/scrotwm_0.9.27.orig.tar.gz [2] http://alioth.debian.org/~ab-guest/scrotwm_0.9.27-1.dsc [3] http://lists.debian.org/debian-devel-announce/2010/10/msg2.html -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: potential fix in cvs
On Thu, Oct 14, 2010 at 08:25:07PM -0500, Marco Peereboom wrote: I committed a fix that I think fixes this. The debian package is way old and contains all kinds of issues, you guys really should update to the latest cvs version. I'll roll a new snapshot in a few days. It’s usually preferred to only package released tarballs, so once you have published a new snapshot, drop me a line so I can update the package. Once an updated package is ready, I’ll need to have Dmitry and Hannes test it and confirm whether the bug is gone. If that is the case, we might be able to get a freeze exception. In fact, the package in Debian is so outdated only because squeeze froze just a few days before my sponsor had a chance to upload 0.9.25. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#592955: linux-image-2.6.35-trunk-686: Can’t see mouse pointer in X
Package: linux-2.6 Version: 2.6.35-1~experimental.1 Severity: important Hi, when I run the 2.6.35 kernel, I can’t see the mouse pointer under X on my ThinkPad X40. The mouse pointer works fine: I can right–click to get context menus and select any of the menu items to activate it. Focus–follows–mouse also works fine, only I can’t see where the pointer is located. The problem goes away as soon as I boot using the 2.6.34 kernel, installed a while ago from experimental. -- Package-specific info: ** Version: Linux version 2.6.35-trunk-686 (Debian 2.6.35-1~experimental.1) (m...@debian.org) (gcc version 4.4.4 (Debian 4.4.4-7) ) #1 SMP Fri Aug 6 14:49:07 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.35-trunk-686 root=/dev/mapper/lagann-root ro quiet ** Not tainted ** Kernel log: [2.796297] ata1.00: 31522816 sectors, multi 1: LBA48 [2.804207] ata1.00: configured for UDMA/100 [2.804359] scsi 0:0:0:0: Direct-Access ATA KingSpec KSD-PA1 0908 PQ: 0 ANSI: 5 [3.278886] e1000 :02:01.0: eth0: (PCI:33MHz:32-bit) 00:0a:e4:2d:dc:07 [3.278895] e1000 :02:01.0: eth0: Intel(R) PRO/1000 Network Connection [3.278923] sdhci-pci :02:00.1: SDHCI controller found [1180:0822] (rev 13) [3.278943] sdhci-pci :02:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [3.279967] sdhci-pci :02:00.1: Will use DMA mode even though HW doesn't fully claim to support it. [3.281080] Registered led device: mmc0:: [3.282149] mmc0: SDHCI controller on PCI [:02:00.1] using DMA [3.914628] Console: switching to colour frame buffer device 128x48 [3.921072] fb0: inteldrmfb frame buffer device [3.921075] drm: registered panic notifier [3.921093] Slow work thread pool: Starting up [3.921147] Slow work thread pool: Ready [3.921158] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [3.941738] sd 0:0:0:0: [sda] 31522816 512-byte logical blocks: (16.1 GB/15.0 GiB) [3.941813] sd 0:0:0:0: [sda] Write Protect is off [3.941818] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [3.941849] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [3.942046] sda: sda1 sda2 [3.943039] sd 0:0:0:0: [sda] Attached SCSI disk [4.027696] device-mapper: uevent: version 1.0.3 [4.028499] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-de...@redhat.com [ 10.472711] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [ 11.122465] udev: starting version 160 [ 11.587872] Non-volatile memory driver v1.3 [ 11.618020] ACPI: AC Adapter [AC] (on-line) [ 11.622128] input: PC Speaker as /devices/platform/pcspkr/input/input5 [ 11.644139] ACPI: Battery Slot [BAT0] (battery absent) [ 11.709962] intel_rng: FWH not detected [ 11.740606] ACPI: acpi_idle registered with cpuidle [ 11.742293] Marking TSC unstable due to TSC halts in idle [ 11.758574] i801_smbus :00:1f.3: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 11.762284] Switching to clocksource acpi_pm [ 11.787659] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 11.828803] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 11.866687] NET: Registered protocol family 23 [ 11.886617] nsc-ircc 00:09: activated [ 11.886647] nsc-ircc, chip-init [ 11.886658] nsc-ircc, Found chip at base=0x164e [ 11.886682] nsc-ircc, driver loaded (Dag Brattli) [ 11.897864] IrDA: Registered device irda0 [ 11.897870] nsc-ircc, Using dongle: IBM31T1100 or Temic TFDS6000/TFDS6500 [ 12.023410] yenta_cardbus :02:00.0: CardBus bridge found [1014:0555] [ 12.149151] yenta_cardbus :02:00.0: ISA IRQ mask 0x0cb0, PCI irq 16 [ 12.149158] yenta_cardbus :02:00.0: Socket status: 3006 [ 12.149170] yenta_cardbus :02:00.0: pcmcia: parent PCI bridge window: [io 0x3000-0x7fff] [ 12.149177] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3000-0x7fff: excluding 0x3000-0x30ff 0x3400-0x34ff 0x7000-0x703f [ 12.190494] yenta_cardbus :02:00.0: pcmcia: parent PCI bridge window: [mem 0xd020-0xdfff] [ 12.190502] pcmcia_socket pcmcia_socket0: cs: memory probe 0xd020-0xdfff: excluding 0xd020-0xd09f 0xd3a0-0xd81f 0xdfa0-0xe01f [ 12.190542] yenta_cardbus :02:00.0: pcmcia: parent PCI bridge window: [mem 0xf000-0xf7ff pref] [ 12.190548] pcmcia_socket pcmcia_socket0: cs: memory probe 0xf000-0xf7ff: excluding 0xf000-0xf7ff [ 12.191184] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [ 12.191188] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 12.191191] thinkpad_acpi: ThinkPad BIOS 1UETD3WW (2.08 ), EC 1UHTB2WW-1.62 [ 12.191196] thinkpad_acpi: IBM ThinkPad X40, model 23717JG [ 12.193556] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 12.208297] Registered led device: tpacpi::thinklight [ 12.208616] Registered led device: tpacpi::power [ 12.208899] Registered led device: tpacpi::standby [
Bug#590933: transmission-gtk: Creates incomplete-dir even if incomplete-dir-enabled is set to false
Package: transmission-gtk Version: 2.01-1 Severity: normal It’s like #554903 all over again. This time the default is ~/Downlads, but the behaviour is the same. I guess the fix will be similar, as well. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.34-1-686 (SMP w/1 CPU core) 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 transmission-gtk depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.0-1 Multi-protocol file transfer libra ii libdbus-glib-1-20.86-1 simple interprocess messaging syst ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libglib2.0-02.24.1-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libnotify1 [libnotify1- 0.5.0-2 sends desktop notifications to a n ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libssl0.9.8 0.9.8o-1 SSL shared libraries ii transmission-common 2.01-1 lightweight BitTorrent client (com ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages transmission-gtk recommends: ii xdg-utils1.0.2+cvs20100307-1 desktop integration utilities from transmission-gtk 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#564943: scrotwm key bindings
On Thu, Mar 18, 2010 at 01:06:45PM +0100, Hannes wrote: Sorry for my long silence. Since first reporting the problem, I've done regular updates from the testing branch, of course. When I tried things out again after reading Dimitry's suggestions today, this lead to some interesting new developments: When I put scrotwm in my .xsession file and run startx, it works. Regularly, I'm using the Slim login manager for authentication and session selection. Starting ScrotWM from there resulted in the behaviour described earlier before. Now today, using the Slim login, it still seemed the same way (no keybindings working), but I could switch to a VT. This was not possible a few weeks ago. Switching back to X (even without doing anything on the VT, not even logging in), ScrotWM keybindings suddenly work as intended! So I assume part of the issue was simply caused by some temporary freak bug in an underlying X package which has been fixed by now. What remains is the weird behaviour when being run through a graphical login manager. I use xdm to manage my graphical logins, and I’ve encountered no problems so far; I’ve also tried starting a scrotwm session from GDM, both using the same .xsession file I use with xdm and selecting the appropriate session from the menu, and everything was still working. I will try starting scrotwm with startx and Slim too, just to be sure. It would be nice if you could try starting a scrotwm session from xdm, and also try the method outlined by Dimitry. Figuring out where the root of the problem lies isn’t easy, especially since I can’t reproduce the bug and Dimitry has outdated libraries on his box. Testing various configurations is just about the only thing to do, except for banging one’s head against the nearest wall. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#554903: transmission-gtk: creates watch-dir even if directory watching is disabled
Package: transmission-gtk Version: 1.75-1 Severity: normal At startup, Transmission creates the directory pointed to by the watch-dir option if it doesn't exist, even when watch-dir-enabled is set to false. This, combined with the default watch-dir being ~/Desktop, makes it quite annoying for people not using a desktop environment. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core) 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 transmission-gtk depends on: ii libc6 2.9-25GNU C Library: Shared libraries ii libcurl3-gnutls7.19.5-1.1Multi-protocol file transfer libra ii libdbus-glib-1-2 0.82-2simple interprocess messaging syst ii libevent-1.4-2 1.4.12-stable-1 An asynchronous event notification ii libglib2.0-0 2.22.2-2 The GLib library of C routines ii libgtk2.0-02.18.3-1 The GTK+ graphical user interface ii libnotify1 [libnotify1 0.4.5-1 sends desktop notifications to a n ii libpango1.0-0 1.26.0-1 Layout and rendering of internatio ii libssl0.9.80.9.8k-5 SSL shared libraries ii transmission-common1.75-1lightweight BitTorrent client (com ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime Versions of packages transmission-gtk recommends: pn xdg-utils none (no description available) transmission-gtk 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#551981: bzr-builddeb: --result option is documented as --result-dir
Package: bzr-builddeb Version: 0.95 Severity: minor Tags: patch Hi, the documentation obtained using `bzr help builddeb' contains the following text: $ bzr help builddeb [...] for use in merge mode, defaults to ../tarballs. --result-dir specifies where the resulting package files should be placed, defaults to whatever is used for the build directory. --result-dir will have problems if you use a build command that places the results in a different directory. [...] However, $ bzr builddeb --orig-dir ../../../tarballs/ \ --result-dir ../../../build-area/ bzr: ERROR: no such option: --result-dir $ while $ bzr builddeb --orig-dir ../../../tarballs/ \ --result ../../../build-area/ [builds just fine] $ The attached patch (modify_documentation.diff) fixes the problem by syncing the inline documentation with the actual option name. It's a simple two-line patch which doesn't touch the code, so no harm can possibly be done by applying it. However, since having that option named --result instead of --result-dir is not coherent with the other options (--orig-dir and --build-dir), I've made a second patch (modify_behavior.diff), which changes the code to reflect the documentation. This is not a simple name change, since I've modified the behavior as well, to make it orthogonal with the behavior of the other two options. I feel pretty confident the patch is harmless, but I can offer no guarantee. By the way, I feel a --dir-prefix or similar option would be nice to have, so that you will be able to replace $ bzr builddeb --orig-dir ../../../tarballs \ --build-dir ../../../build-area \ --result-dir ../../../build-area with just $ bzr builddeb --dir-prefix ../../../ to save some typing when you're building from a branch deep into a shared repository. But I'll file a separate, wishlist bug about that another day. Cheers. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core) 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 bzr-builddeb depends on: ii bzr 2.0.1-1easy to use distributed version co ii bzrtools 2.0.1-1Collection of tools for bzr ii devscripts2.10.55scripts to make the life of a Debi ii dpkg-dev 1.15.3.1 Debian package development tools ii fakeroot 1.14 Gives a fake root environment ii patchutils0.3.1-2Utilities to work with patches ii python2.5.4-2An interactive high-level object-o ii python-apt0.7.13.3 Python interface to libapt-pkg ii python-central0.6.11 register and build utility for Pyt ii python-debian 0.1.14 Python modules to work with Debian bzr-builddeb recommends no packages. Versions of packages bzr-builddeb suggests: pn bzr-svn none (no description available) -- no debconf information diff -Naru builddeb.orig/__init__.py builddeb/__init__.py --- builddeb.orig/__init__.py 2009-10-22 09:07:16.0 +0200 +++ builddeb/__init__.py 2009-10-22 10:24:12.0 +0200 @@ -110,9 +110,9 @@ You can also specify directories to use for different things. --build-dir is the directory to build the packages beneath, defaults to ../build-area. --orig-dir specifies the directory that contains the .orig.tar.gz files - for use in merge mode, defaults to ../tarballs. --result-dir specifies where + for use in merge mode, defaults to ../tarballs. --result specifies where the resulting package files should be placed, defaults to whatever is - used for the build directory. --result-dir will have problems if you use a + used for the build directory. --result will have problems if you use a build command that places the results in a different directory. The --reuse option will be useful if you are in merge mode, and the upstream diff -Naru builddeb.orig/builder.py builddeb/builder.py --- builddeb.orig/builder.py 2009-10-22 10:02:59.0 +0200 +++ builddeb/builder.py 2009-10-22 10:05:16.0 +0200 @@ -314,6 +314,10 @@ The files are found by reading the changes file. +if result == self._properties.build_dir(): + info(Not moving result, build dir and result dir are the same) + return + info(Placing result in %s, result) package = self._properties.package() version = self._properties.full_version() diff -Naru builddeb.orig/__init__.py builddeb/__init__.py --- builddeb.orig/__init__.py 2009-10-22 09:07:16.0 +0200 +++ builddeb/__init__.py 2009-10-22
Bug#531826: scrotwm: doesn't play well with hidden windows
Hi,
I have a new tentative patch, which seems to be working correctly. Would you
mind dropping it in debian/patches and checking whether the bug still applies?
Be aware that the patch is against the recently-released 0.9.6 version of
scrotwm; you can grab the source tree for an updated Debian package from the
usual location on bzr.debian.org.
Let me know how it goes.
--
Andrea Bolognani e...@kiyuko.org
Resistance is futile, you will be garbage collected.
Index: scrotwm/scrotwm.c
===
--- scrotwm.orig/scrotwm.c 2009-09-21 22:02:06.0 +0200
+++ scrotwm/scrotwm.c 2009-09-21 23:27:37.0 +0200
@@ -787,6 +787,36 @@
XSendEvent(display, win-id, False, StructureNotifyMask, (XEvent *)ce);
}
+void
+set_win_state(Window w, long state)
+{
+ long data[] = {state, None};
+
+ DNPRINTF(SWM_D_EVENT, set_win_state: window: %lu\n, w);
+
+ XChangeProperty(display, w, astate, astate, 32, PropModeReplace,
+ (unsigned char *)data, 2);
+}
+
+long
+get_win_state(Window w)
+{
+ int format, status;
+ long result = -1;
+ unsigned char *p = NULL;
+ unsigned long n, extra;
+ Atom real;
+
+ status = XGetWindowProperty(display, w, astate, 0L, 2L, False, astate,
+ real, format, n, extra, (unsigned char **)p);
+ if (status != Success)
+ return (-1);
+ if (n != 0)
+ result = *((long *)p);
+ XFree(p);
+ return (result);
+}
+
int
count_win(struct workspace *ws, int count_transient)
{
@@ -1527,6 +1557,7 @@
adjust_font(win);
mask = CWX | CWY | CWWidth | CWHeight | CWBorderWidth;
XConfigureWindow(display, win-id, mask, wc);
+ set_win_state(win-id, NormalState);
XMapRaised(display, win-id);
last_h = win_g.h;
@@ -1541,6 +1572,7 @@
continue;
stack_floater(win, ws-r);
+ set_win_state(win-id, NormalState);
XMapRaised(display, win-id);
}
@@ -1679,8 +1711,10 @@
if (win == ws-focus) {
XMapRaised(display, win-id);
- } else
+ } else {
+set_win_state(win-id, IconicState);
XUnmapWindow(display, win-id);
+ }
}
}
@@ -2628,17 +2662,6 @@
buttons[i].func(win, buttons[i].args);
}
-void
-set_win_state(struct ws_win *win, long state)
-{
- long data[] = {state, None};
-
- DNPRINTF(SWM_D_EVENT, set_win_state: window: %lu\n, win-id);
-
- XChangeProperty(display, win-id, astate, astate, 32, PropModeReplace,
- (unsigned char *)data, 2);
-}
-
const char *quirkname[] = {
NONE, /* config string for no value */
FLOAT,
@@ -3139,7 +3162,7 @@
XSelectInput(display, id, EnterWindowMask | FocusChangeMask |
PropertyChangeMask | StructureNotifyMask);
- set_win_state(win, NormalState);
+ set_win_state(win-id, NormalState);
/* floaters need to be mapped if they are in the current workspace */
if (win-floating (ws-idx == r-ws-idx))
@@ -3180,7 +3203,7 @@
ws-focus_prev = NULL;
TAILQ_REMOVE(win-ws-winlist, win, entry);
- set_win_state(win, WithdrawnState);
+ set_win_state(win-id, WithdrawnState);
if (win-ch.res_class)
XFree(win-ch.res_class);
if (win-ch.res_name)
@@ -3353,6 +3376,7 @@
return;
if (wa.override_redirect)
return;
+ set_win_state(e-xmaprequest.window, NormalState);
manage_window(e-xmaprequest.window);
stack();
@@ -3402,8 +3426,10 @@
DNPRINTF(SWM_D_EVENT, unmapnotify: window: %lu\n, e-xunmap.window);
if ((win = find_window(ev-window)) != NULL)
- if (win-transient)
+ if (get_win_state(win-id) != IconicState)
unmanage_window(win);
+
+ stack();
}
void
@@ -3453,25 +3479,6 @@
return (0);
}
-long
-getstate(Window w)
-{
- int format, status;
- long result = -1;
- unsigned char *p = NULL;
- unsigned long n, extra;
- Atom real;
-
- status = XGetWindowProperty(display, w, astate, 0L, 2L, False, astate,
- real, format, n, extra, (unsigned char **)p);
- if (status != Success)
- return (-1);
- if (n != 0)
- result = *((long *)p);
- XFree(p);
- return (result);
-}
-
void
new_region(struct swm_screen *s, int x, int y, int w, int h)
{
@@ -3709,7 +3716,7 @@
continue;
if (wa.map_state == IsViewable ||
- getstate(wins[j]) == NormalState)
+ get_win_state(wins[j]) == NormalState)
manage_window(wins[j]);
}
/* transient windows */
@@ -3718,7 +3725,7 @@
continue;
if (XGetTransientForHint(display, wins[j], d1)
- (wa.map_state == IsViewable || getstate(wins[j]) ==
+ (wa.map_state == IsViewable || get_win_state(wins[j]) ==
NormalState))
manage_window(wins[j]);
}
signature.asc
Description: Digital signature
