Bug#1065666: Compiz 0.8.18 appears to be broken in testing

2024-03-08 Thread Colomban Wendling
Hello James, Unfortunately I can't test this for the moment, but: Le 06/03/2024 à 15:03, James Bielefeldt a écrit : This address is listed as a maintainer on the Compiz package search page. 0.8.18 black screens on boot after a recent update when building a iso with livebuild. I have been

Bug#1065666: Compiz 0.8.18 appears to be broken in testing

2024-03-08 Thread Colomban Wendling
Le 06/03/2024 à 16:59, James Bielefeldt a écrit : I am using testing. I create Debian spins that are rolling release based on testing. it's the same package in standard testing and unstable to my knowledge. Unstable recently got 2:0.8.18-5.1 -- yet as Steve said, it should not affect

Bug#1065666: Compiz 0.8.18 appears to be broken in testing

2024-03-08 Thread Colomban Wendling
Le 06/03/2024 à 17:31, Steve Langasek a écrit : On Wed, Mar 06, 2024 at 03:46:41PM +0100, Colomban Wendling wrote: Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they have extra clues. The only change in the NMU was to rename the libdecoration0 package

Bug#997514: ctpl: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

2021-11-06 Thread Colomban Wendling
On Sat, 23 Oct 2021 22:42:41 +0200 Lucas Nussbaum wrote: > […] > > FAIL: tests.sh > > == > > > > ./tests.sh: 35: tempfile: not found Looks like it's breaking because `tempfile` is gone, but that's an easy fix I just committed upstream, see

Bug#986873: librsvg: FTFBS with current rustc in Buster (1.41.1+dfsg1-1~deb10u1)

2021-04-13 Thread Colomban Wendling
Source: librsvg Version: 2.44.10-2.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, Probably since the update to rustc 1.41 in Buster, librsvg fails to build. First error is: > Running `rustc --crate-name

Bug#971568: geany-plugins: libgit2 1.0 transition

2020-12-04 Thread Colomban Wendling
Package: geany-plugins Version: 1.37+dfsg-3 Followup-For: Bug #971568 This is actually fixed in version 1.37+dfsg-3 and just missed a reference in the upload. I just verified with a local build of the package with libgit2 from experimental and it builds fine. Upstream fixed this in

Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1

2020-03-26 Thread Colomban Wendling
Hi, Sorry if I'm too far off the tree, but isn't this just an overlook of the dependency switch from libgcc1 (which has an "1" epoch) to the libgcc-s1 (which doesn't have an epoch)? ATM at least clang-9 (which is still the default in unstable) depends on libgcc-8-dev, and while I probably miss

Bug#871563: manpages-fr-extra: French translation of diff(1) is outdated

2018-08-04 Thread Colomban Wendling
Package: manpages-fr-extra Version: 20151231 Followup-For: Bug #871563 I agree, I just wanted to check a diff(1) option, and it wasn't listed in the manpage, leading me to assume diff(1) didn't have it. Next, a search on the Internet showed that diff(1) did indeed have this option, making me

Bug#823149: libjs-jquery-fancybox doesn't work with current libjs-jquery

2016-05-01 Thread Colomban Wendling
Package: libjs-jquery-fancybox Version: 11-1 Severity: grave Justification: renders package unusable Dear Maintainer, The version of libjs-jquery-fancybox packaged (1.3.4 (11/11/2010) [1]) is not compatible with current version of libjs-jquery (1.12.3), and doesn't work at all with it:

Bug#804363: mumble: SSL connection aborts with "unable to allocate SSL_CTX"

2015-11-07 Thread Colomban Wendling
Package: mumble Version: 1.2.10-2+b1 Severity: grave Justification: renders package unusable Dear Maintainer, Since last upgrade (the rebuild, +b1, oddly enough) Mumble aborts trying to connect to any server: > OpenSSL Support: 1 (OpenSSL 1.0.2d 9 Jul 2015) > MumbleSSL: unable to allocate

Bug#798870: geany-plugins: FTBFS with libgit2 0.23.1

2015-09-13 Thread Colomban Wendling
On 13/09/2015 19:23, Andreas Beckmann wrote: > geany-plugins fails to build with the new libgit2 in sid: Indeed. This is due to libgit2 0.23 breaking some API geany-plugins uses. Upstream added support for it in

Bug#759745: gdm3: Unable to login post-upgrade without systemd-sysv installed

2014-10-21 Thread Colomban Wendling
I can also confirm that with current Sid I can again login with Gdm when running sysvinit as PID1. Thanks for the fix. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763050: geany: Does not start, Attempt to unlock mutex that was not locked instead

2014-10-13 Thread Colomban Wendling
Le 13/10/2014 11:30, wrote : [...] It will be faster than waiting for the upstream to release a new version. [...] I wasn't suggesting to wait for a new release, only to wait for the upstream author to approve the patch before importing it in Debian. This might avoid bugs if the author sees one

Bug#763050: Re: geany: Does not start, Attempt to unlock mutex that was not locked instead

2014-10-12 Thread Colomban Wendling
On Thu, 02 Oct 2014 15:17:47 +0400 =?UTF-8?B?VmxhZCBPcmxvdg==?= mon...@inbox.ru wrote: Dammit, this is worse than I thought. It's not fixed by applying a workaround patch [1] to GTK+2 (like it's been fixed in every other app failing with the same attempt to unlock... message). It still

Bug#707368: geany: FTBFS: tm_tag.c:448:21: error: expected ')' before '__attribute__'

2013-05-09 Thread Colomban Wendling
Le 09/05/2013 09:49, Lucas Nussbaum a écrit : Source: geany Version: 1.22+dfsg-2 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20130509 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to

Bug#677244: xen-utils-common: xen-toolstack fails if either `xm` or `xl` is not found in xen-dir

2012-06-12 Thread Colomban Wendling
Package: xen-utils-common Version: 4.1.2-7 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, The script /usr/lib/xen-common/bin/xen-toolstack improperly aborts if *either* `xm` or `xl` cannot be found in the xen-dir (/usr/lib/xen-4.0/bin). This means that a

Bug#632089: tcc: Fails to find required crt1.o, crti.o and crtn.o, resulting in build failure

2011-06-29 Thread Colomban Wendling
Package: tcc Version: 0.9.25-6 Severity: grave Justification: renders package unusable TCC fails to build the most trivial code because it can't find crt1.o, crti.o and crtn.o: test.c: int main () { ; return 0; } tcc call:

Bug#504353: virtualbox-ose-modules-2.6.26-1-amd64 version mismatch on Lenny

2008-11-02 Thread Colomban Wendling
Package: virtualbox-ose-modules-2.6.26-1-amd64 Version: 2.6.26+1.6.2-dfsg-4 Severity: grave Justification: renders package unusable The virtualbox-ose-modules-2.6.26-1-amd64 version in Lenny is 1.6.2 (2.6.26+1.6.2-dfsg-4) but virtualbox-ose version is 1.6.6 (1.6.6-dfsg-2). Virtualbox won't run

Bug#467198: madwifi-source: m-a doesn't install due to dependencies problems (madwifi-tools)

2008-02-23 Thread Colomban Wendling
Package: madwifi-source Version: 1:0.9.4~rc2-1 Severity: grave Justification: renders package unusable The installation of the new version of madwifi-source doesn't work due to madwifi-tools dpendencies problems. After compilation with module-assistant, the instalation reports the following:

Bug#467198: madwifi-source: m-a doesn't install due to dependencies problems (madwifi-tools)

2008-02-23 Thread Colomban Wendling
Kel Modderman a écrit : On Sunday 24 February 2008 03:54:30 Colomban Wendling wrote: Package: madwifi-source Version: 1:0.9.4~rc2-1 Severity: grave Justification: renders package unusable The installation of the new version of madwifi-source doesn't work due to madwifi-tools