Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
Hi Simon This is embarassing but I found now what was the issue. There is one package that I installed some months ago that was not from Debian repos and for some reason it installs /lib/libusb. It's not even a deb file which is why dpkg-query does not know about it. The package in question is xiAPI, from ximea, a company for microscope cameras https://www.ximea.com/support/wiki/apis/xiAPI . Without the whole working from home thing, I would have never have installed on my computer. I'm very sorry for the noise. Thank you for the help, it was the process of answering your questions, and searching for other libs that dpkg did not know about, that made me remember this. David
Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
On Thu, 22 Oct 2020 at 21:47, Simon McVittie wrote: > > On Thu, 22 Oct 2020 at 19:14:54 +0100, David Miguel Susano Pinto wrote: >> gnome-boxes does not start. Trying from command line, issues this error: >> >> $ gnome-boxes >> gnome-boxes: symbol lookup error: >> /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1: undefined symbol: >> libusb_set_option >> >> Similar issue when starting qemu: >> >> $ qemu-system-x86_64 >> qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined >> symbol: libusb_set_option > > It starts fine on a Debian 10 system for me. According to > /var/lib/dpkg/info/libusb-1.0-0:amd64.symbols, that symbol has been provided > by libusb-1.0-0 since version 2:1.0.22, which you have. > > Do you have an older version of libusb-1.0.so.0 somewhere in the library > search path, perhaps in /usr/local/lib? I checked and other than "/lib/x86_64-linux-gnu/libusb-1.0.so.0" (provided by libusb-1.0-0) I also have "/lib/libusb-1.0.so.0" (which seems to be what is loaded: $ ldd /usr/bin/gnome-boxes | grep usb libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0x7f49d1393000) libusbredirhost.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7f49c88fb000) libusbredirparser.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7f49c88f00 Removing "/lib/libusb-1.0.so*" (and run ldconfig to update the linker cache), makes it load the right libusb: $ ldd /usr/bin/gnome-boxes | grep usb libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x7fc22ff71000) libusbredirhost.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7fc2274b3000) libusbredirparser.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7fc2274a8000) And gnome-boxes now works properly. The thing is, I have no idea where this /lib/libusb came from. I'm pretty sure I didn't install anything other than debs from the official debian repos. dpkg-query also does not know which package installed it: $ dpkg-query -S /lib/libusb-1.0.so.0.1.0 dpkg-query: no path found matching pattern /lib/libusb-1.0.so.0.1.0 I have one other Debian machine which has the same file. Any clues where that file came from and what it may be used for? Thank you David
Bug#971264: Acknowledgement (mediawiki: ParseError after 1.27.7-1~deb9u4 upgrade (blame patch for User::pingLimiter))
On Mon, 28 Sep 2020 08:30:55 -0400, Roberto C. Sánchez wrote: > On Mon, Sep 28, 2020 at 01:24:09PM +0100, carandraug wrote: >> >> Dear Maintainer, >> >> After the update to 1.27.7-1~deb9u4 (from 1.27.7-1~deb9u3), the mediawiki >> site >> errors in all pages with: >> >> Exception encountered, of type "ParseError" >> > Thanks for the report. An update to fix this is being prepared and > should be published later today. I just upgraded to deb9~5 and I can confirm it has fixed the issue. Thank you
Bug#929506: gbrowse FTBFS: tests fail
On Tue, 9 Jul 2019 at 16:56, Andreas Tille wrote: > > Hi Carnė, > > On Tue, Jul 09, 2019 at 04:53:31PM +0100, Carnė Draug wrote: > > On Tue, 9 Jul 2019 at 10:33, Andreas Tille wrote: > > > > > > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gbrowse_2.56+dfsg-4.rbuild.log.gz > > > > I have checked the output from that link and it's getting a lot of > > "Can't locate Bio/DB/SeqFeature/Store.pm in @INC (you may need to > > install the Bio::DB::SeqFeature::Store module)" and another for > > Bio::DB::GFF. > > > > These module used to be part of the BioPerl distribution but has been > > moved out to their own distribution, both of which have already been > > released. > > > > Their distributions are: > > > > Bio-DB-SeqFeature [1,2] > > Bio-DB-GFF [3,4] > > > > [1] https://github.com/bioperl/Bio-DB-SeqFeature/ > > [2] https://metacpan.org/release/Bio-DB-SeqFeature > > [3] https://github.com/bioperl/Bio-DB-GFF/ > > [4] https://metacpan.org/release/Bio-DB-GFF > > Thanks for analysing this issue. Do you volunteer to create these > packages? Hi Andreas I'm sorry but I won't be able to take over those packages. I don't expect there to be anything specially tricky about them though, they're pretty standard perl distributions. Both of them have both perl 5 modules and programs which might need to split into two debian packages. Here's some notes from my side (I helped preparing the bioperl releases): * Bio-DB-SeqFeature is depependent on Bio-DB-GFF (I have this on my personal notes but I'm looking at the code now and I think this is incorrect). * Bio-DB-GFF is dependent on Bio-DB-BioFetch. Bio-DB-BioFetch is also not packaged in Debian. Let me know if there's issues I may be able to help with.
Bug#929506: gbrowse FTBFS: tests fail
On Tue, 9 Jul 2019 at 10:33, Andreas Tille wrote: > > Hi Carnė, > > I have not checked but I could imagine that this issue is somehow > connected to the the new upstream version of bioperl. Since you > intended to to restructure the bioperl packages I think this is a good > point in time. Since you are way more involved in bioperl than I I'd be > more than happy if you do this fully according to your own opinion. > Please let me know if you need any help. > [...] > This is also observed by reproducible builds using pbuilder: > > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gbrowse_2.56+dfsg-4.rbuild.log.gz I have checked the output from that link and it's getting a lot of "Can't locate Bio/DB/SeqFeature/Store.pm in @INC (you may need to install the Bio::DB::SeqFeature::Store module)" and another for Bio::DB::GFF. These module used to be part of the BioPerl distribution but has been moved out to their own distribution, both of which have already been released. Their distributions are: Bio-DB-SeqFeature [1,2] Bio-DB-GFF [3,4] [1] https://github.com/bioperl/Bio-DB-SeqFeature/ [2] https://metacpan.org/release/Bio-DB-SeqFeature [3] https://github.com/bioperl/Bio-DB-GFF/ [4] https://metacpan.org/release/Bio-DB-GFF
Bug#921495: Bioperl 1.7.4 should not migrate to Buster
On Mon, 11 Feb 2019 at 15:47, Andreas Tille wrote: > > On Mon, Feb 11, 2019 at 03:32:47PM +, Carnë Draug wrote: > > > > Well, all those regressions are because they can't install bioperl > > which is their dependency. There is no issue on themselves or in > > upstream bioperl. The issue is that Debian's bioperl claims to have > > recommend dependency on bioperl-run which does not actually exist in > > upstream anymore. > > OK. > > > > Thus I admit I see no real profit in upgrading bioperl-run at this > > > release stage. We could upload to experimental (Carnė, I'm explicitly > > > encouraging you to do so if you have some interest in it). I for > > > myself have currently more important things on my desk since this > > > becomes important for my only after Buster release. > > > > I'm not interested on bioperl-run either. But can you remove the > > current bioperl from sid which is causing all those issues on the > > other packages? > > There is no easy way to remove a package from sid. The only way would > be to upload version 1.7.2 with an epoch (1:1.7.2). Since epochs are > ugly I would like to avoid this. If it hurds anybody to much we might > consider uploading bioperl-run as well. Since it probably needs a > versioned depends ob bioperl 1.7.4 it should not migrate to testing as > well. But since all these regressions are only in sid I see no real > harm (except Ubuntu might fetch from unstable and will end up with > broken bioperl stuff. > > What do you think? All packages that depend on bioperl are being affected by this. The current situation is a bit awkward because packaging and testing in sid fails even though it would be fine in testing. This will cause issues for new releases of such packages and for false positives in Debian's ci. If you do make a new bioperl-run release, you can drop the following dependencies: bowtie bwa maq paml t-coffee but should add this new one (already packaged): libbio-tools-run-alignment-clustalw David
Bug#921495: Bioperl 1.7.4 should not migrate to Buster
On Mon, 11 Feb 2019 at 14:06, Andreas Tille wrote: > > Hi Carnė, > > On Mon, Feb 11, 2019 at 12:59:45PM +, Carnė Draug wrote: > > On Wed, 6 Feb 2019 at 14:06, Andreas Tille wrote: > > > This is what I've though about: Removing the files from bioperl-run > > > (which would be 1.7.2-5 then) > > > > Upstream has released BioPerl-Run 1.7.3 which fixes this conflict > > issue. If someone could prepare that release that would be nice. > > Thanks a lot for this hint. > > > Like BioPerl 1.7.3, this new release of BioPerl-Run removed multiple > > modules and so, probably not suitable for migration to Buster during > > this transition freeze period. > > This is demonstrated very well here: > > https://tracker.debian.org/pkg/bioperl > > Lots of packages (not only bioperl-run) are broken by the new version. Well, all those regressions are because they can't install bioperl which is their dependency. There is no issue on themselves or in upstream bioperl. The issue is that Debian's bioperl claims to have recommend dependency on bioperl-run which does not actually exist in upstream anymore. > Thus I admit I see no real profit in upgrading bioperl-run at this > release stage. We could upload to experimental (Carnė, I'm explicitly > encouraging you to do so if you have some interest in it). I for > myself have currently more important things on my desk since this > becomes important for my only after Buster release. I'm not interested on bioperl-run either. But can you remove the current bioperl from sid which is causing all those issues on the other packages? Thank you David
Bug#921495: libbio-perl-perl: Package not upgradable, file conflicts.
On Wed, 6 Feb 2019 at 14:06, Andreas Tille wrote: > On Wed, Feb 06, 2019 at 01:18:26PM +, Carnė Draug wrote: > > I guess the fix for this is to have in bioperl's d/control: > > > > Breaks: libbio-perl-run-perl (<< 1.7.3) > > > > It would be nice if upstream did a new release of bioperl-run soon > > without those modules. I have prepared the upstream repository and > > have requested them to make a release but I don't know when it will > > happen. > > > > Alternatively, you could remove those files in Debian and have a > > bioperl-run version 1.7.2-4. > > This is what I've though about: Removing the files from bioperl-run > (which would be 1.7.2-5 then) Upstream has released BioPerl-Run 1.7.3 which fixes this conflict issue. If someone could prepare that release that would be nice. Like BioPerl 1.7.3, this new release of BioPerl-Run removed multiple modules and so, probably not suitable for migration to Buster during this transition freeze period.
Bug#917143: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: COREDUMP
On Fri, 1 Feb 2019 at 14:20, Andreas Tille wrote: > > Hi, > > I tried to have a look at the issue caused by t-coffee 12 which became > visible in the smoke test of libbio-tools-run-alignment-tcoffee-perl. > Liubov had checked it before and filed an issue upstream[1] but at my > side the test to reproduce the bug does not fail. The t-coffee tests fail on their own. I don't know why you can't reproduce it. See the results for the latest failure: https://ci.debian.net/data/autopkgtest/unstable/amd64/t/t-coffee/1817091/log.gz of for the previous runs: https://ci.debian.net/packages/t/t-coffee/unstable/amd64/ > I wonder if someone > from the Perl team would be able to iron out the actual t-coffee call > that causes the coredump. If we would have some > >t-coffee options / args > --> COREDUMP > > we could start to run this through gdb. If I do not get any help of > this kind I have no idea to hunt this down. > The results from the last autopkgtests show that it's this command that fails: t_coffee -aln sproteases_small.cw_aln sproteases_small.muscle \ sproteases_small.tc_aln -outfile combined_aln.aln The test script is part of t-coffee: https://salsa.debian.org/med-team/t-coffee/blob/master/debian/tests/run-unit-test If the command on its own does not fail, maybe it needs to be ran in series after the others? Maybe not related, but something odd that I noticed is that the '=' does not appear in the log of the test suite. While the test script has: -outfile=combined_aln.aln The logs only show: -outfile combined_aln.aln
Bug#790196: Rasmol needs severe contribution to stay in Debian
On 3 July 2018 at 14:59, Andreas Tille wrote: > Hi, > > the bug log of #790196[1] shows that rasmol in its current state will > not be distributable with Buster. Upstream is dead so if we want to > keep it in Debian we have the option: > >1) Port it to Gtk+ 3 (see porting guide [2]) >2) Find a Gtk+ 2 replacement for libvte >3) Give up and remove this package from Debian > > Since option 3 would be a shame for a package with quite some users[3] > (at least in the field of scientific software) I'm hereby making some > noise about this. My recent upload updates metadata (Salsa migration), > fixed all other bugs and most of the lintian issues. > > I'd be really happy if someone could spent some time into this > > Andreas. > > > [1] https://bugs.debian.org/790196 > [2] https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html > [3] https://qa.debian.org/popcon.php?package=rasmol Maybe option 3 is not that bad. Debian also packages pymol which is used even more [4] so it's not like rasmol users will be left without an alternative. David [4] https://qa.debian.org/popcon.php?package=pymol
Bug#588798: imagej: fails to find JVM on fresh install
Package: imagej Version: 1.44c-1 Justification: renders package unusable Severity: grave Fresh install of imageJ doesn't start. When started from a terminal returns the error carandr...@altar:~$ imagej /usr/bin/imagej: line 32: /usr/sbin/update-java-alternatives: No such file or directory Open other images in this ImageJ panel as follows: imagej -p 1 image1 [image2 ... imageN] No JVM found to run ImageJ Please apt-get install a JVM to run ImageJ or set JAVA_HOME if it's not a JVM from a Debian Package. Problem is solved after installing openjdk-6-jre. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imagej depends on: ii gcj-4.4-jre [java2-runtime] 4.4.4-6Java runtime environment using GIJ ii gcj-jre [java2-runtime] 4:4.4.4-2 Java runtime environment using GIJ imagej recommends no packages. Versions of packages imagej suggests: ii gcj-jre-headless [java-virtua 4:4.4.4-2 Java runtime environment using GIJ -- no debconf information
