similar to: Processed: unblock 718767 with 710650

Processing commands for control at bugs.debian.org: > block 718767 with 710650 Bug #718767 [release.debian.org] transition: ocaml 4.00.1 718767 was not blocked by any bugs. 718767 was not blocking any bugs. Added blocking bug(s) of 718767: 710650 > thanks Stopping processing here. Please contact me if you need assistance. -- 718767: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718767

Processing commands for control at bugs.debian.org: > block 710650 with 713349 Bug #710650 [src:xen-api] xen-api: FTBFS: gcc: error: /home/blank/debian/xen/releases/xen/xen-4.2.1/debian/build/build-utils_amd64/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so: No such file or directory- build ocaml/xapi rrddump.opt 710650 was not blocked by any bugs. 710650 was not blocking any bugs.

Processing commands for control at bugs.debian.org: > user debian-qa at lists.debian.org Setting user to debian-qa at lists.debian.org (was anbe at debian.org). > found 728743 331.20-1 Bug #728743 [libgl1-nvidia-glx] corrupts the signal block mask (SigBlk) breaking unrelated Bug #733816 [libgl1-nvidia-glx] khotkeys launches actions with SIGHUP blocked, leading to unclosable xterms Marked as

Le 24/09/2013 19:00, Thomas Goirand a ?crit : > Please don't think this way. > > I work daily on 79 packages to maintain OpenStack in Debian: > > http://qa.debian.org/developer.php?login=openstack-devel at lists.alioth.debian.org If you go that way, I could say that you're blocking my work on 214 packages in Debian:

On 09/06/2013 02:42 PM, St?phane Glondu wrote: > Le 05/09/2013 23:18, Julien Cristau a ?crit : >> tracker adjusted. xen-api is currently broken though, so you'll need to >> get that fixed before starting. > > I've just fixed a blocking bug (#713349) which was due to the renaming > of an OCaml library (type-conv -> type_conv). Hi, I had a patch from upstream

On 09/24/2013 09:48 PM, St?phane Glondu wrote: > Le 06/09/2013 10:14, Thomas Goirand a ?crit : >> However, as I wrote it, it's going to happen, so please be patient about >> it. IMO, this shouldn't block any transition though. If the release team >> is reading: just let everything transition to testing, and remove the >> old version of XCP 1.3.2 in testing if

Le 06/09/2013 10:14, Thomas Goirand a ?crit : > I wrote it many time to many people. Please don't just read 1.6 as "new > upstream release" for XCP. That's unfortunately not the way it works. > Upstream version for Debian and the one they do for CentOS are > different, and just using upstream 1.6 doesn't cut it. It needs to be > ported to Debian, and that's

Le 06/09/2013 10:14, Thomas Goirand a ?crit : > However, as I wrote it, it's going to happen, so please be patient about > it. IMO, this shouldn't block any transition though. If the release team > is reading: just let everything transition to testing, and remove the > old version of XCP 1.3.2 in testing if that helps, plus add some > blocking bugs so that the rest of Debian

http://bugzilla.mindrot.org/show_bug.cgi?id=271 Summary: SSHD should unblock SIGCHLD - POSIX signal blocks survive exec() Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo:

If SIGTERM is blocked in the main program, then it ends up still being blocked in the subprocess after we fork. This means that we cannot kill qemu by sending SIGTERM to it. This commit fixes the problem by unblocking SIGTERM unconditionally after fork. Thanks: wtfuzz on IRC for reporting and analysis. --- lib/launch-direct.c | 15 +++++++++++++++ lib/launch-uml.c | 11 +++++++++++ 2 files

On 09/10/2013 03:17 PM, St?phane Glondu wrote: > Le 06/09/2013 10:14, Thomas Goirand a ?crit : >> I wrote it many time to many people. Please don't just read 1.6 as "new >> upstream release" for XCP. That's unfortunately not the way it works. >> Upstream version for Debian and the one they do for CentOS are >> different, and just using upstream 1.6

Le 05/09/2013 23:18, Julien Cristau a ?crit : > tracker adjusted. xen-api is currently broken though, so you'll need to > get that fixed before starting. I've just fixed a blocking bug (#713349) which was due to the renaming of an OCaml library (type-conv -> type_conv). Now, xen-api FTBFS because of what looks like an API change in some (C) dependency: > [...] > + gcc -g

Your message dated Sun, 02 Mar 2014 18:42:06 +0000 with message-id <E1WKBKw-0004SD-Mw at franck.debian.org> and subject line Bug#740517: Removed package(s) from unstable has caused the Debian Bug report #710650, regarding xen-api: FTBFS: gcc: error: /home/blank/debian/xen/releases/xen/xen-4.2.1/debian/build/build-utils_amd64/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so: No such

Package: release.debian.org Severity: normal User: release.debian.org at packages.debian.org Usertags: unblock X-Debbugs-Cc: xen at packages.debian.org, team at security.debian.org, maxi at daemonizer.de Control: affects -1 + src:xen Please unblock package xen. [ Reason ] Xen in bookworm is currently affected by CVE-2022-42335 and CVE-2022-42336 (see #1034842 and #1036298). [ Impact ] The

Package: release.debian.org Severity: normal User: release.debian.org at packages.debian.org Usertags: unblock Hi, Please unblock package xen-api. The PAM fix which we did for version 1.3.2-10 wasn't correct, and thanks to the help of Steve Langasek, we have it in a good shape now. The details of the conversation is available in the Ubuntu BTS here:

Hmm, I'm not having much success in replicating the build environment for this - however, I did notice two patches in the ubuntu xen-api package that look relevant. The build failure appears to be related to xenguest, and there is a patch 'xenguest-4.2.patch' which looks worth a test. Also, I noticed another patch 'fix-xen-4.2-paths.patch' that might be relevant. Thomas,

On 10/09/13 14:09, Thomas Goirand wrote: > On 09/10/2013 03:17 PM, St?phane Glondu wrote: >> Le 06/09/2013 10:14, Thomas Goirand a ?crit : >>> I wrote it many time to many people. Please don't just read 1.6 as "new >>> upstream release" for XCP. That's unfortunately not the way it works. >>> Upstream version for Debian and the one they do for

Le 24/09/2013 15:48, St?phane Glondu a ?crit : > If I remove all binary packages of xen-api from testing, the following > new packages are broken: xcp-guest-templates, nova-xcp-plugins, > nova-compute-xen. > > xcp-guest-templates is built by guest-templates which seems to be a leaf > package and could be removed from testing. > > On the other hand, both nova-* packages

Package: release.debian.org Severity: normal User: release.debian.org at packages.debian.org Usertags: unblock Hi, I have uploaded xen-api/1.3.2-13, which corrects 2 things: the hostname change script was designed by CentOS, so I've fixed that, and also, the init script was hanging waiting forever if the xen-api host was a slave node, so I added a test in the init script, thanks to a patch

On 09/24/2013 10:04 PM, St?phane Glondu wrote: > Le 24/09/2013 15:48, St?phane Glondu a ?crit : >> If I remove all binary packages of xen-api from testing, the following >> new packages are broken: xcp-guest-templates, nova-xcp-plugins, >> nova-compute-xen. >> >> xcp-guest-templates is built by guest-templates which seems to be a leaf >> package and could be