Bug#1065666: Compiz 0.8.18 appears to be broken in testing
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 building the xfce-Compiz iso for about 4 months without issue. The xfce (testing amd64) iso is built without errors, but it is unusable with the black screen. Rebuilding the source package does not fix it. Are you sure you're not using unstable? FWIW, there's no recent changes to the Compiz packages in testing, last ones were from about a year ago. However, there's a large transition currently happening in unstable, which affects Compiz as well. Maybe it could have an unknown side effect you're seeing? I cant seem to get any more info with the black screen, ctrl+alt+F(any number) stays a black screen and booting into safe mode also results in a black screen. Xfce images without compiz build and work fine. Maybe you could try SSHing to the machine to gather more data? Or possibly access the logs any other way? It could possibly be fairly unrelated to Compiz itself, but rather something else in the graphic stack (OpenGL? so maybe mesa, the kernel or something?) that affects Compiz more than others? Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they have extra clues. Note that you probably should report a bug, although it's understandably harder with scarce data to reference. Regards, Colomban
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
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 anything. they all have the same version number. The package is also seriously outdated. Compiz is at 9.14 but the package is 8 point something. Well, yes and no. Compiz is a complicated beast, and version 0.9 is a C++ rewrite by Ubuntu, that is now basically unmaintained. Compiz 0.8, also known as "compiz reloaded", is the pre-Ubuntu rewrite and has been continued separately. Effectively nowadays it's 2 different (yet similar) software, and 0.9 is mostly discontinued, and 0.8 is maintained albeit not seeing muhc activity lately. I tried to build it from the Ubuntu sources, but they errored out and are beyond me. My main thing is themeing and polishing the desktop. I do have a live build script if you want it. Just not sure how I'd get it to you. I don't think I'd have the time to dive this deep, and it would help immensely if you could try and gather some more information as to why Compiz is having issues. Logs from the kernel, X and the Xfce sessions are likely the most interesting bits where you might find more information to pinpoint the issue. Failing that, one interesting thing you could possibly attempt is to see whether an image with the exact same set of packages work fine if you don't *run* Compiz. Basically build the Compiz image, and simply adjust the configuration not to run it (but use e.g. xfwm4). You could also try and play with the Compiz plugins and configuration to see if one in particular is at fault, or if it's the core itself. Regards, Colomban
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
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 to libdecoration0t64 for the 64-bit time_t transition. Unless this managed to break the *contents* of that package (i.e. the library has gone missing), this should not have had any effect on the behavior of compiz. So the package has not been rebuilt with different flags or anything? Anyway, I hardly expect this to be an issue, I just wanted to eliminate the only Compiz-side change that happened in the last months. Colomban
Bug#997514: ctpl: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2
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 https://git.tuxfamily.org/ctpl/ctpl.git/commit/?id=932f7767af15592fc36137a868187e45dea80068 Regards, Colomban
Bug#986873: librsvg: FTFBS with current rustc in Buster (1.41.1+dfsg1-1~deb10u1)
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 rayon_core > /home/hypra/librsvg-2.44.10/vendor/rayon-core/src/lib.rs --error-format=json > --json=diagnostic-rendered-ansi,artifacts --crate-type lib > --emit=dep-info,metadata,link -C opt-level=3 -C debuginfo=2 -C > metadata=41ebc87ed575d9b4 -C extra-filename=-41ebc87ed575d9b4 --out-dir > /home/hypra/librsvg-2.44.10/target/release/deps -L > dependency=/home/hypra/librsvg-2.44.10/target/release/deps --extern > crossbeam_deque=/home/hypra/librsvg-2.44.10/target/release/deps/libcrossbeam_deque-5e5e3fad47b2220a.rmeta > --extern > lazy_static=/home/hypra/librsvg-2.44.10/target/release/deps/liblazy_static-db957d0d55571ca1.rmeta > --extern > libc=/home/hypra/librsvg-2.44.10/target/release/deps/liblibc-7e7e12c9f437ada3.rmeta > --extern > num_cpus=/home/hypra/librsvg-2.44.10/target/release/deps/libnum_cpus-a828ef016c5f994d.rmeta > --cap-lints allow` > error[E0502]: cannot borrow `*self` as immutable because it is also borrowed > as mutable >--> /home/hypra/librsvg-2.44.10/vendor/nalgebra/src/base/cg.rs:292:44 > | > 292 | self[(j, i)] += shift[j] * self[(D::dim() - 1, i)]; > | ------ > | | | > | | immutable borrow occurs here > | mutable borrow occurs here > | mutable borrow later used here Which upstream has "fixed": https://gitlab.gnome.org/GNOME/librsvg/-/issues/634 However, if you work around that one, there's at least one more in the cssparser module. I'm not quite sure the solution here is as there are no other rustc version available anymore. But maybe call it quits and provide a buidlable packport of newer version supporting rustc 1.41? FWIW, I was trying to rebuild to fix apply a fix for #939029 (using upstream's https://gitlab.gnome.org/GNOME/librsvg/commit/f5608502581207921b3b9e8adc53be7430945ade). Regards, Colomban -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#971568: geany-plugins: libgit2 1.0 transition
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 https://github.com/geany/geany-plugins/pull/956 Regards, Colomban
Bug#954826: libgcc-8-dev: depends on unavailable version of libgcc-s1
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 some important details, I fail to see why we have to drop gcc-8 because of this? Regards, Colomban
Bug#871563: manpages-fr-extra: French translation of diff(1) is outdated
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 wonder whether Debian's diff(1) was different. `diff --help` showed it was just the manpage, so did a subsequent `man -LC diff`. This is confusing and counter-productive for the user. Please either update this package to provide accurate translations, or drop it to force accurate English on users instead of allowing inaccurate French. Regards, Colomban -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) manpages-fr-extra depends on no packages. Versions of packages manpages-fr-extra recommends: ii manpages-fr 3.65d1p1-1 Versions of packages manpages-fr-extra suggests: ii man-db [man-browser] 2.7.6.1-2 pn manpages-fr-dev -- no debconf information
Bug#823149: libjs-jquery-fancybox doesn't work with current libjs-jquery
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: TypeError: $.browser is undefined (at jquery.fancybox.min.js:1:418) According to https://stackoverflow.com/questions/14344289/fancybox-doesnt-work-with-jquery-v1-9-0-f-browser-is-undefined-cannot-read it's simply that this old version of FancyBox isn't compatible with API changes in newer jQuery. I see three possible fixes for the package, in order of preference: * Update the plugin to its latest version (or at least, newer) which should be compatible. * Patch the packaged version of the plugin to work with current jQuery. * Make the libjs-jquery-fancybox package depend on libjs-jquery < 1.9, but that would effectively make the package uninstallable on testing and newer. Thanks, Colomban [1] $ grep Version: /usr/share/javascript/jquery-fancybox/jquery.fancybox.js -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libjs-jquery-fancybox depends on: ii libjs-jquery 1.12.3-1 ii libjs-jquery-easing 11-1 ii libjs-jquery-mousewheel 11-1 Versions of packages libjs-jquery-fancybox recommends: ii javascript-common 11 libjs-jquery-fancybox suggests no packages. -- no debconf information
Bug#804363: mumble: SSL connection aborts with "unable to allocate SSL_CTX"
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 SSL_CTX > Invalid 'net/sslciphers' config option. Either the cipher string is invalid > or none of the ciphers are available:: "EECDH+AESGCM:AES256-SHA:AES128-SHA" > Abandon I do not have altered the net/sslciphers option, and ciphers look fine: > $ openssl ciphers "EECDH+AESGCM:AES256-SHA:AES128-SHA" > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA Anyway, after digging a lot, it appears that Mumble forgets to call `SSL_library_init()` [1]. Injecting such a call early in the run fixes the issue: > $ gdb mumble > GNU gdb (Debian 7.10-1) 7.10 > [...snip...] > Reading symbols from mumble...Reading symbols from > /usr/lib/debug/.build-id/d7/713cd5f7d3cbaaa65bcdbe9bb1cc45b6478eb1.debug...done. > done. > (gdb) break main > Breakpoint 1 at 0x43eda0: file main.cpp, line 136. > (gdb) run > Starting program: /usr/bin/mumble > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Breakpoint 1, main (argc=1, argv=0x7fffe028) at main.cpp:136 > 136 main.cpp: No such file or directory. > (gdb) call SSL_library_init() > $1 = 1 > (gdb) continue > Continuing. > [...snip...] > OpenSSL Support: 1 (OpenSSL 1.0.2d 9 Jul 2015) > ServerHandler: TLS cipher preference is > "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:AES256-SHA:AES128-SHA" And everything seem to work fine. Without this, not only Mumble aborts trying to connect to servers, but it also fails to check and generate user certificates. This throws the existing user certificate away on each startup, losing some unreproducible and potentially important data. So, please fix the code to properly init LibSSL as required -- or whatever the proper fix is. Regards, Colomban [1] https://wiki.openssl.org/index.php/SSL/TLS_Client#Initialization -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mumble depends on: ii libasound2 1.0.29-1 ii libavahi-client3 0.6.32~rc+dfsg-1 ii libavahi-common3 0.6.32~rc+dfsg-1 ii libavahi-compat-libdnssd1 0.6.32~rc+dfsg-1 ii libc6 2.19-22 ii libg15daemon-client1 1.9.5.3-8.3 ii libgcc11:5.2.1-23 ii libopus0 1.1-2 ii libprotobuf9v5 2.6.1-1.3 ii libpulse0 7.1-2 ii libqt4-dbus4:4.8.7+dfsg-3 ii libqt4-network 4:4.8.7+dfsg-3 ii libqt4-sql 4:4.8.7+dfsg-3 ii libqt4-sql-sqlite 4:4.8.7+dfsg-3 ii libqt4-svg 4:4.8.7+dfsg-3 ii libqt4-xml 4:4.8.7+dfsg-3 ii libqtcore4 4:4.8.7+dfsg-3 ii libqtgui4 4:4.8.7+dfsg-3 ii libsndfile11.0.25-9.1 ii libspeechd20.8-7 ii libspeex1 1.2~rc1.2-1 ii libspeexdsp1 1.2~rc1.2-1 ii libssl1.0.21.0.2d-3 ii libstdc++6 5.2.1-23 ii libx11-6 2:1.6.3-1 ii libxi6 2:1.7.5-1 ii lsb-release9.20150917 mumble recommends no packages. Versions of packages mumble suggests: pn mumble-server ii speech-dispatcher 0.8-7 -- no debconf information
Bug#798870: geany-plugins: FTBFS with libgit2 0.23.1
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 http://git.geany.org/geany-plugins/commit/?id=37aa25a1a4508c3d7559c0a2d00663b9c8d322c6, and it should be trivial and safe to cherry-pick. See also upstream report: https://github.com/geany/geany-plugins/pull/283 Regards, Colomban
Bug#759745: gdm3: Unable to login post-upgrade without systemd-sysv installed
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
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 in this patch, or simply diverging if the author chooses another one. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763050: Re: geany: Does not start, Attempt to unlock mutex that was not locked instead
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 crashes even with the patched GTK+2. Indeed, this is really a bug in the Debugger plugin. I submitted a patch upstream to fix the issue, see https://github.com/geany/geany-plugins/pull/156 As this is marked Grave (quite correctly) and will lead for geany-pludins to be dropped from Jessie altogether if not fixed, I suggest to wait a bit to see what the author answers, and apply a patch to fix this no matter what -- or drop Debugger from geany-plugins, but that would be some kind of a regression, especially as a quick and less intrusive (yet less sensible) fix is possible (see the message in the above link). Regards, Colomban -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707368: geany: FTBFS: tm_tag.c:448:21: error: expected ')' before '__attribute__'
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 build on amd64. [...] This has been fixed upstream in commit http://git.geany.org/geany/commit/?id=1646504a46e4b5af354406fd1f819da0dd6754fa It is released in upstream version 1.23 (March 10, 2013). Regards, Colomban -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677244: xen-utils-common: xen-toolstack fails if either `xm` or `xl` is not found in xen-dir
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 default installation (e.g. following Debian wiki on the subject, namely installing xen-linux-system and xen-tools without any configuration) will NOT be usable as-is because it cannot find an usable toolstack. This is due to a bug in the error handling of the xen-toolstack script when it comes to checking the availability of `xm` and `xl`. Since the script is run with `sh -e` and the return value of `command -v` isn't used, the script aborts. Attached is a tiny patch fixing the issue by using the `command -v` return value. Best regards, Colomban -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-utils-common depends on: ii gawk1:4.0.1+dfsg-2 ii lsb-base4.1+Debian7 ii python 2.7.3~rc2-1 ii ucf 3.0025+nmu3 ii udev175-3.1 ii xenstore-utils 4.1.2-7 xen-utils-common recommends no packages. xen-utils-common suggests no packages. -- no debconf information --- /usr/lib/xen-common/bin/xen-toolstack 2012-05-22 10:52:37.0 +0200 +++ xen-toolstack 2012-06-12 17:40:37.174403052 +0200 @@ -11,7 +11,7 @@ else PATH=$dir/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin fi -command -v $1 +command -v $1 || true } if [ -e $configfile ]; then
Bug#632089: tcc: Fails to find required crt1.o, crti.o and crtn.o, resulting in build failure
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:
$ tcc -L/usr/lib/x86_64-linux-gnu test.c
tcc: file '/usr/lib/crt1.o' not found
tcc: file '/usr/lib/crti.o' not found
tcc: file '/usr/lib/crtn.o' not found
This seems to happen because the paths for these files are hardcoded in TCC to
CONFIG_TCC_CRT_PREFIX CONFIG_SYSROOT /usr/lib
rather than an arch-specific path like
CONFIG_TCC_CRT_PREFIX CONFIG_SYSROOT /usr/lib/x86_64-linux-gnu
Changing the constant to this fixes the problem on my x86_64 system -- but of
course it won't work on a i386 system.
Since TCC's build system can probably know the libdir (it seems to be given to
dh_auto_configure), it should be possible to make it be something like:
CONFIG_TCC_CRT_PREFIX CONFIG_SYSROOT LIBDIR
Note that this bug don't seem to affect programs built and run with the -run
option.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tcc depends on:
ii dpkg 1.16.0.3 Debian package management system
ii install-info 4.13a.dfsg.1-6 Manage installed documentation in
ii libc6 2.13-7 Embedded GNU C Library: Shared lib
Versions of packages tcc recommends:
ii libc6-dev [libc-dev] 2.13-7 Embedded GNU C Library: Developmen
tcc suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504353: virtualbox-ose-modules-2.6.26-1-amd64 version mismatch on Lenny
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 with module version older than program version, then this package is unusable on Lenny for now. The most annoying thing with this package is that if the user build its own module from the sources with module-assistant from virtualbox-ose-source, the generated package's version is 1.6.6-dfsg-2+2.6.26-8 but the Lenny package's version is 2.6.26+1.6.2-dfsg-4; then Aptitude ask for upgrading it from the manually built version to the broken Lenny's version. The result is an infinite cycle of upgrading and need to reinstall the manually built module, etc. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages virtualbox-ose-modules-2.6.26-1-amd64 depends on: ii linux-image-2.6.26-1-amd64 [l 2.6.26-8 Linux 2.6.26 image on AMD64 virtualbox-ose-modules-2.6.26-1-amd64 recommends no packages. virtualbox-ose-modules-2.6.26-1-amd64 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467198: madwifi-source: m-a doesn't install due to dependencies problems (madwifi-tools)
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: Selecting previously deselected package madwifi-modules-2.6.22-3-amd64. (Reading database ... 176935 files and directories currently installed.) Unpacking madwifi-modules-2.6.22-3-amd64 (from .../madwifi-modules-2.6.22-3-amd64_0.9.4~rc2-1+2.6.22-6.lenny1_amd64.deb) ... dpkg: dependency problems prevent configuration of madwifi-modules-2.6.22-3-amd64: madwifi-modules-2.6.22-3-amd64 depends on madwifi-tools (= 1:0.9.4~rc2+dfsg-1); however: Version of madwifi-tools on system is 1:0.9.3+dfsg-3. dpkg: error processing madwifi-modules-2.6.22-3-amd64 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: madwifi-modules-2.6.22-3-amd64 I: Direct installation failed, trying to post-install the dependencies Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages will be REMOVED: madwifi-modules-2.6.22-3-amd64 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 1036kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 176951 files and directories currently installed.) Removing madwifi-modules-2.6.22-3-amd64 ... -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages madwifi-source depends on: ii bzip2 1.0.4-3high-quality block-sorting file co ii debhelper 6.0.5 helper programs for debian/rules ii module-assistant 0.10.11.0 tool to make module package creati madwifi-source recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467198: madwifi-source: m-a doesn't install due to dependencies problems (madwifi-tools)
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 dpendencies problems. After compilation with module-assistant, the instalation reports the following: Selecting previously deselected package madwifi-modules-2.6.22-3-amd64. (Reading database ... 176935 files and directories currently installed.) Unpacking madwifi-modules-2.6.22-3-amd64 (from .../madwifi-modules-2.6.22-3-amd64_0.9.4~rc2-1+2.6.22-6.lenny1_amd64.deb) ... dpkg: dependency problems prevent configuration of madwifi-modules-2.6.22-3-amd64: madwifi-modules-2.6.22-3-amd64 depends on madwifi-tools (= 1:0.9.4~rc2+dfsg-1); however: Version of madwifi-tools on system is 1:0.9.3+dfsg-3. dpkg: error processing madwifi-modules-2.6.22-3-amd64 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: madwifi-modules-2.6.22-3-amd64 I: Direct installation failed, trying to post-install the dependencies Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages will be REMOVED: madwifi-modules-2.6.22-3-amd64 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 1036kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 176951 files and directories currently installed.) Removing madwifi-modules-2.6.22-3-amd64 ... What exact command did you use? What distribution (testing|sid)? Do you have latest madwifi-tools installed? If so what version? What does apt-cache policy madwifi-tools say? Kel. Hi, I'm using Testing. I've build madwifi-source with m-a suite : m-a prepare, build then install As I've done with the previous version. Yes, I've the latest madwifi-tools from testing repositories, I've no updates at this time. My madwifi-tools version is 1:0.9.3+dfsg-3, and it is the latest from testing repositories (as aptitude says after an update). As you see, it doesn't match the madwifi-source version number. You can see the same at packages.debian.org for testing (and sid for mips and mipsel arch). the madwifi-tools policy: $ apt-cache policy madwifi-tools madwifi-tools: Installed: 1:0.9.3+dfsg-3 Candidate: 1:0.9.3+dfsg-3 Version table: *** 1:0.9.3+dfsg-3 0 900 http://ftp.fr.debian.org lenny/contrib Packages 900 http://ftp.fr.debian.org testing/contrib Packages 100 /var/lib/dpkg/status 1:0.9.3+dfsg-1 0 -20 ftp://fr.archive.ubuntu.com gutsy/universe Packages It seems for me that the madwifi-tools package has to be updated in the repositories to match the madwifi-source version, isn't it? Colomban W.
