Bug#1040566: let logol be removed
Le mer. 19 juil. 2023, 06:58, Andreas Tille a écrit : > Hi Olivier, > > Am Mon, Jul 17, 2023 at 12:13:30PM +0200 schrieb olivier sallou: > > logol is not maintained anymore for quite some time now > > > > effort to keep in line with swi-prolog updates (need to recompile on each > > ABI break of swi-prolog) AND biojava requires frequent work for an old > > software with low usage. > > > > I would let it be removed > > You introduced the package so you know its usage best. I think any > removal should be announced on debian-med@l.d.o which I'm doing hereby. > > IMHO if the fix would be "simple" (in terms of needs only less than > 10min) keeping it might be worth it. Otherwise its a good time in the > beginning of the release process to remove packages that just drain > developer resources and do not serve a mentionable amount of users. > It would require analysis and many updates, so quite some efforts for unmaintained software and targetting low number of users (sure of that), so i am for removal. Olivier > > Kind regards > Andreas. > > -- > http://fam-tille.de > >
Bug#1040566: biojava not shipping biojava.jar anymore
seems biojava now ships several jar files (core, biosql, ...) and not a bundle anymore, used by logol, see list of jar files available: https://packages.debian.org/sid/all/libbiojava1.9-java/filelist would need to patch logol to import/load expected jar files (and find which ones are needed...) in command line tools
Bug#1040566: let it be removed
logol is not maintained anymore for quite some time now effort to keep in line with swi-prolog updates (need to recompile on each ABI break of swi-prolog) AND biojava requires frequent work for an old software with low usage. I would let it be removed -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1039562: package install error is "fine"
Installation shows an "error" because it tries to connect to database with configuration defaults (will fail at first install if default user/password does not exists in database, and this is fine). In case of "failure" using found configuration (/usr/share/gmod/chado/conf/gmod-chado.conf) , it explains the expected setup steps to user and exists with code 0. So "error" is not a real error , but just an install setup test to check if user need to configure database access, and exit as expected with error code 0 (and package is installed as expected). -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
On Wed, 2022-12-21 at 19:39 +0530, Nilesh Patra wrote: > On Wed, 21 Dec 2022 12:32:25 +0100 olivier sallou > wrote: > > On Wed, 2022-12-21 at 11:02 +0100, olivier sallou wrote: > > > looks like a python3 issue (though was already adapter to py3...) > > > > > > will have a look and reproduce > > > > I could reproduce and found an issue with demo_checker.py handling > > with > > python3 > > > > I have a patch. will test it and upload > > I wrote a patch as well, and was going to upload, but you beat me to > it, hah :/ sorry, I did not set me as bug owner but sent comments anyway so that others are aware I was on issue and this package is so long to build. > My patch is quite similar to yours, though. > I fixed py2 / py3 bytes error in 2 places and skipped mason2 tests as described in patch and previous message Just uploaded fixed package Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
upstream, in develop branch has disabled mason2 testing for gcc > 10 , don't know why, but let's do the same as it is the one failing now with indeed superior gcc I am adapting the patch and testing again. gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
I pushed a patch d/patches/fix_python3_tests whic fixes almost all test issues(python3 related) BUT remains a failing test with mason2 which is not related to py3 issue (no bytes-like error) after build, can be reproduced with in a temp dir: python3 /<>/apps/mason2/tests/run_tests.py /opt/debian/build-area/seqan2-2.4.0+dfsg /<>/obj-x86_64- linux-gnu/ it basically compare some generated files with some comparison files and for mason2 they are different, and program itself raise no error but result not as expected. Seems that many sequences output result are shifted by 1 character -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
On Wed, 2022-12-21 at 11:02 +0100, olivier sallou wrote: > looks like a python3 issue (though was already adapter to py3...) > > will have a look and reproduce I could reproduce and found an issue with demo_checker.py handling with python3 I have a patch. will test it and upload > > Olivier > > -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
looks like a python3 issue (though was already adapter to py3...) will have a look and reproduce Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026056: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
after investigation, logol does not find anymore libswipl.so.8, need version providing .so.9 compiled program link to .so.x versions, forcing package recompilation Le mar. 13 déc. 2022 à 22:03, Paul Gevers a écrit : > Source: swi-prolog, logol > Control: found -1 swi-prolog/9.0.2+dfsg-1 > Control: found -1 logol/1.7.9+dfsg-5 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of swi-prolog the autopkgtest of logol fails in > testing when that autopkgtest is run with the binary packages of > swi-prolog from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > swi-prolog from testing9.0.2+dfsg-1 > logol from testing1.7.9+dfsg-5 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. The issue > *looks* similar to bug 1022253, but now on all architectures. > > Currently this regression is blocking the migration of swi-prolog to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found > on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=swi-prolog > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/29303003/log.gz > > calling logol with parameters -g 1799.logol -s 1799.fasta -dna > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied) > at java.base/java.io.FileOutputStream.open0(Native Method) > at java.base/java.io > .FileOutputStream.open(FileOutputStream.java:293) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:235) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:155) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > at > org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) > at > > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) > at > > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) > at > > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) > at > > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) > at org.apache.log4j.LogManager.(LogManager.java:127) > at org.apache.log4j.Logger.getLogger(Logger.java:117) > at org.irisa.genouest.logol.Logol.(Unknown Source) > For help, use option -h > INFO org.irisa.genouest.logol.Logol - Using configuration file: > /usr/share/logol/prolog/logol.properties > INFO org.irisa.genouest.logol.Logol - option g called with 1799.logol > INFO org.irisa.genouest.logol.Logol - option s called with 1799.fasta > INFO org.irisa.genouest.logol.Logol - No maximum solutions defined, > using defaults > INFO org.irisa.genouest.logol.Logol - option dna called > INFO org.irisa.genouest.logol.Logol - Start analyse to create grammar > analyser > Executing prolog for pre-analyse > java.io.FileNotFoundException: > /tmp/1799.logol.38da5a9d-c2ac-4a7d-8eb3-8c05b42f5c04.pre.res (No such > file or directory) > at java.base/java.io.FileInputStream.open0(Native Method) > at java.base/java.io > .FileInputStream.open(FileInputStream.java:216) > at java.base/java.io > .FileInputStream.(FileInputStream.java:157) > at java.base/java.io.FileReader.(FileReader.java:75) > at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown > Source) > at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown > Source) > at org.irisa.genouest.logol.Logol.analyse(Unknown Source) > at org.irisa.genouest.logol.Logol.execute(Unknown Source) > at org.irisa.genouest.logol.Logol.main(Unknown Source) > INFO org.irisa.genouest.logol.Logol - Analyse in progress.. > WARN org.irisa.genouest.logol.SequenceAnalyser - Path to suffix search > tool is not set in system environment. Will try to execute directly but > may fail if not in PATH of current user > Exception in thread "main"
Bug#1026056: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Tests need to be run as root, or use a specific config file and use non root writable directories. Will try to change tests to do so. Regarding issue itself, programs compiled by swi prolog usually require recompilation on swi prolog updates. Will try to rebuild and check Le mar. 13 déc. 2022, 22:03, Paul Gevers a écrit : > Source: swi-prolog, logol > Control: found -1 swi-prolog/9.0.2+dfsg-1 > Control: found -1 logol/1.7.9+dfsg-5 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of swi-prolog the autopkgtest of logol fails in > testing when that autopkgtest is run with the binary packages of > swi-prolog from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > swi-prolog from testing9.0.2+dfsg-1 > logol from testing1.7.9+dfsg-5 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. The issue > *looks* similar to bug 1022253, but now on all architectures. > > Currently this regression is blocking the migration of swi-prolog to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found > on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=swi-prolog > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/29303003/log.gz > > calling logol with parameters -g 1799.logol -s 1799.fasta -dna > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied) > at java.base/java.io.FileOutputStream.open0(Native Method) > at java.base/java.io > .FileOutputStream.open(FileOutputStream.java:293) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:235) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:155) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > at > org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) > at > > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) > at > > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) > at > > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) > at > > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) > at org.apache.log4j.LogManager.(LogManager.java:127) > at org.apache.log4j.Logger.getLogger(Logger.java:117) > at org.irisa.genouest.logol.Logol.(Unknown Source) > For help, use option -h > INFO org.irisa.genouest.logol.Logol - Using configuration file: > /usr/share/logol/prolog/logol.properties > INFO org.irisa.genouest.logol.Logol - option g called with 1799.logol > INFO org.irisa.genouest.logol.Logol - option s called with 1799.fasta > INFO org.irisa.genouest.logol.Logol - No maximum solutions defined, > using defaults > INFO org.irisa.genouest.logol.Logol - option dna called > INFO org.irisa.genouest.logol.Logol - Start analyse to create grammar > analyser > Executing prolog for pre-analyse > java.io.FileNotFoundException: > /tmp/1799.logol.38da5a9d-c2ac-4a7d-8eb3-8c05b42f5c04.pre.res (No such > file or directory) > at java.base/java.io.FileInputStream.open0(Native Method) > at java.base/java.io > .FileInputStream.open(FileInputStream.java:216) > at java.base/java.io > .FileInputStream.(FileInputStream.java:157) > at java.base/java.io.FileReader.(FileReader.java:75) > at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown > Source) > at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown > Source) > at org.irisa.genouest.logol.Logol.analyse(Unknown Source) > at org.irisa.genouest.logol.Logol.execute(Unknown Source) > at org.irisa.genouest.logol.Logol.main(Unknown Source) > INFO org.irisa.genouest.logol.Logol - Analyse in progress.. > WARN org.irisa.genouest.logol.SequenceAnalyser - Path to suffix search > tool is not set in system environment. Will try to execute directly
Bug#1022253: swi-prolog breaks logol autopkgtest on s390x
Le dim. 23 oct. 2022, 19:21, Lev Lamberov a écrit : > Hi Paul, > > Вс 23 окт 2022 @ 10:10 Paul Gevers : > > > Hi Lev, > > > > On 23-10-2022 09:40, Lev Lamberov wrote: > >> I'm not sure it is the solution, it needs testing. The change in > >> swi-prolog concerns pre-compiled prolog source code, when there is no > >> pre-complied prolog code rebuilt is not needed. SWI-Prolog supports > >> three different kinds of pre-compilation, at least one of them was > >> affected and another was not. The mentioned endiannes bug can be found > >> in BTS, #1006818 [bts]. > > > > I just ran the autopkgtest with a rebuild logol on s390x, see below. > > Does that help? > > > > @logol maintainers, those ERRORs look scary if the test passes with it. > > Is that just noise, or are real problems ignored? > Errors are "permission denied" related. Default package config expects to write in different dirs (temp and results dir), owned by root. If logol is to be executed as non root, a different config file should be used, specifying user writable directories. > Given the answer from Étienne looks like it *is* the solution. Thanks > for your work on it! > > Cheers! > Lev > >
Bug#1014797: FTBFS: test failures with new libgd3
Le ven. 30 sept. 2022 à 07:20, Andreas Tille a écrit :
> Am Fri, Sep 30, 2022 at 02:20:26AM +0200 schrieb olivier sallou:
> > Will try to have a look, but i have no perl knowledge and software is
> quite
> > old now...
>
I have a patch. With this patch, tests are ok, but I have no way to know if
it works as expected (don't know how to test it on real case)
Basically it removes gd2 format usage to use png, see patch below. But it
could have impacts on real display.
Patch:
--- a/lib/Bio/Graphics/Browser2/CachedTrack.pm
+++ b/lib/Bio/Graphics/Browser2/CachedTrack.pm
@@ -151,7 +151,7 @@
sub put_data {
my $self = shift;
my ($gd,$map,$titles) = @_;
-$self->{data}{gd} = $gd->can('gd2') ? $gd->gd2 : $gd;
+$self->{data}{gd} = $gd->png;
$self->{data}{map}= $map;
$self->{data}{titles} = $titles;
my $datafile = $self->datafile;
@@ -191,7 +191,7 @@
my $gd = (ref($data->{gd})
&& ref($data->{gd})=~/^GD/)
? $data->{gd}
-: GD::Image->newFromGd2Data($data->{gd});
+: GD::Image->newFromPngData($data->{gd});
return $gd;
}
--- a/lib/Bio/Graphics/Browser2/Render/Slave.pm
+++ b/lib/Bio/Graphics/Browser2/Render/Slave.pm
@@ -488,7 +488,7 @@
titles=> $titles,
width => $width,
height=> $height,
-imagedata => eval{$imagedata->gd2}};
+imagedata => eval{$imagedata->png}};
}
my $content = nfreeze \%results;
return $content;
Olivier
>
> Alternatively we might consider removal.
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>
Bug#1014797: FTBFS: test failures with new libgd3
Will try to have a look, but i have no perl knowledge and software is quite old now... Le jeu. 29 sept. 2022, 19:44, Andreas Tille a écrit : > Control: tags -1 help > > Hi Aaron and Olivier, > > do you have some idea how to fix this bug? > > Kind regards > > Andreas. > > -- > http://fam-tille.de >
Bug#1013577: [Debian-med-packaging] Bug#1013577: picard-tools: FTBFS: PicardHelpDocWorkUnitHandler.java:6: error: cannot find symbol
faultTaskExecutionPlan.executeWith > > Task(DefaultTaskExecutionPlan.java:581) > > at > > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutor > > Worker.run(DefaultTaskPlanExecutor.java:98) > > at > > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailure > > s.onExecute(ExecutorPolicy.java:63) > > at > > org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExe > > cutorImpl.java:46) > > at > > org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunna > > ble.run(ThreadFactoryImpl.java:55) > > Caused by: > > org.gradle.api.internal.tasks.compile.CompilationFailedException: > > Compilation failed; see the compiler error output for details. > > at > > org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJa > > vaCompiler.java:50) > > at > > org.gradle.api.internal.tasks.compile.JdkJavaCompiler.execute(JdkJa > > vaCompiler.java:35) > > at > > org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.deleg > > ateAndHandleErrors(NormalizingJavaCompiler.java:98) > > at > > org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execu > > te(NormalizingJavaCompiler.java:51) > > at > > org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execu > > te(NormalizingJavaCompiler.java:37) > > at > > org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.e > > xecute(CleaningJavaCompilerSupport.java:35) > > at > > org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.e > > xecute(CleaningJavaCompilerSupport.java:25) > > at > > org.gradle.api.tasks.compile.JavaCompile.performCompilation(JavaCom > > pile.java:207) > > at > > org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:1 > > 92) > > at > > org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:1 > > 24) > > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Nat > > ive Method) > > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Nati > > veMethodAccessorImpl.java:62) > > at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke( > > DelegatingMethodAccessorImpl.java:43) > > at > > org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73) > > at > > org.gradle.api.internal.project.taskfactory.IncrementalTaskAction.d > > oExecute(IncrementalTaskAction.java:46) > > at > > org.gradle.api.internal.project.taskfactory.StandardTaskAction.exec > > ute(StandardTaskAction.java:39) > > at > > org.gradle.api.internal.project.taskfactory.StandardTaskAction.exec > > ute(StandardTaskAction.java:26) > > at > > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$ > > 1.run(ExecuteActionsTaskExecuter.java:121) > > at > > org.gradle.internal.progress.DefaultBuildOperationExecutor$Runnable > > BuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336 > > ) > > at > > org.gradle.internal.progress.DefaultBuildOperationExecutor$Runnable > > BuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328 > > ) > > at > > org.gradle.internal.progress.DefaultBuildOperationExecutor.execute( > > DefaultBuildOperationExecutor.java:199) > > at > > org.gradle.internal.progress.DefaultBuildOperationExecutor.run(Defa > > ultBuildOperationExecutor.java:110) > > at > > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter. > > executeAction(ExecuteActionsTaskExecuter.java:110) > > at > > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter. > > executeActions(ExecuteActionsTaskExecuter.java:92) > > ... 29 more > > > > > > * Get more help at https://help.gradle.org > > > > BUILD FAILED in 9s > > 1 actionable task: 1 executed > > dh_auto_build: error: gradle --info --console plain --offline -- > > stacktrace --no-daemon --refresh-dependencies --gradle-user-home > > .gradle -Duser.home=. -Duser.name=debian -Ddebian.package=picard- > > tools -Dfile.encoding=UTF-8 --parallel --max-workers=8 jar javadoc > > returned exit code 1 > > make[1]: *** [debian/rules:18: override_dh_auto_build] Error 25 > > > The full build log is available from: > http://qa-logs.debian.net/2022/06/24/picard-tools_2.27.1+dfsg-1_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220624;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220624=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available > at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to > contribute! > > If you reassign this bug to another package, please marking it as > 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it > with mine > so that we can identify if something relevant changed in the > meantime. > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Le jeu. 3 mars 2022, 20:51, Paul Gevers a écrit : > Hi Lev, > > On 03-03-2022 08:46, dogs...@riseup.net wrote: > > swi-prolog package (namely, swi-prolog-core) provides an easy way to > > require some particular ABI since 8.2.0+dfsg-2 uploaded on Jun 9, 2020. > > Specifically, in this case logol requires version 67 of binary ABI > > (pre-compiled Prolog code), where the version of swi-prolog in unstable > > is at version 68. In case of logol, its fixed version needs to depend on > > swi-prolog-binary-68 (again, provided by swi-prolog-core). In this case > > it will be easier to track problems with ABI changes. > > > > There are more ABI stuff in swi-prolog which can be tracked the same > > way. > > It is documented in d/Debian.NEWS and d/README.Debian and there are > > references to SWI-Prolog upstream reference guide. More specifically, > > swi-prolog provides 5 virtual packages, each of them containing (a part) > > of some specific ABI version claimed by the current swi-prolog version. > > All these components are extensively documented in SWI-Prolog upstream > > reference guide. > > > > These virtual packages were introduced to prevent the same > > ABI-incompatibility problems with another Debian package, eye. > > Do you confirm that this ABI change doesn't effect the other reverse > build dependencies of src:swi-prolog? If that's the case I'm fine with > removing the block. But I'm afraid (without checking from my side) that > the other package don't have the right virtual ABI package in their > dependencies. If they do, wouldn't they need a rebuild too? > > Also, if logol is already doing the right thing, shouldn't you as the > uploader of swi-prolog request a binNMU for logol to enable your package > to migrate at all? I mean, I would expect the migration to become > blocked by uninstallability of logol in testing without a rebuild. > Hi, i have rebuilt and pushed logol in sid recompiled with the new abi. However, with lev info, i should add for later updates the swi-prolog-binary-68 dependency. Swi prolog needs to move to testing before updated logol. Olivier > Paul > > >
Bug#1006384: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Le lun. 28 févr. 2022 à 06:37, a écrit : > Dear Olivier, > > sorry for the delay with my message and thanks for your input. > > olivier sallou писал 2022-02-25 12:12: > > ok, > > after a quick look, issue is Logol is compiled against swi-prolog, and > > there is an ABI issue I think, getting error: > > > > incompatible version (file: 67, Prolog: 68)] > > > > Recompiling logol in sid against swi-prolog 8.4.2+dfsg-2 results in > > correct execution/tests. > > > > So, 2 things: > > > > * As swi-prolog is only a debian update (-1 to -2), I wonder why we > > have this break now > > * Possible fix is to rebuild logol package against this version in > > sid, with a dep requirement on swi-prolog>=8.4.2+dfsg-2. But I don't > > know how this should be managed (logol in testing will still prevent > > swi-prolog to go, and logol in sid won't either go to testing because > > will need swi-prolog version from sid...) > > It is not just Debian update. I've uploaded new upstream version of > SWI-Prolog on Feb 15 (upgrade from 8.2.4 to 8.4.2). It is a new major > update of stable branch of SWI-Prolog, and it breaks compatibility. As > I can see logol tests failed already with 8.4.2+dfsg-1. There was an > issue with ODBC support for SWI-Prolog on 32-bit platforms, so I > uploaded > 8.4.2+dfsg-2 fixing this issue. > > I think swi-prolog and (updated) logol may migrate simultaneously as it > is the case for swi-prolog and eye (another package depending on > swi-prolog). Otherwise, we could ask someone from Debian Release team to > trigger the migration for the involved packages. > ok, I uploaded logol 1.7.9+dfsg-2 built against swi-prolog 8.4.2 and closing the issue with upload. Let's see what happens for migration. Olivier > > Cheers! > Lev > > > Le jeu. 24 févr. 2022 à 19:36, Paul Gevers a > > écrit : > > > >> Source: swi-prolog, logol > >> Control: found -1 swi-prolog/8.4.2+dfsg-2 > >> Control: found -1 logol/1.7.9+dfsg-1 > >> Severity: serious > >> Tags: sid bookworm > >> X-Debbugs-CC: debian...@lists.debian.org > >> User: debian...@lists.debian.org > >> Usertags: breaks needs-update > >> > >> Dear maintainer(s), > >> > >> With a recent upload of swi-prolog the autopkgtest of logol fails in > >> > >> testing when that autopkgtest is run with the binary packages of > >> swi-prolog from unstable. It passes when run with only packages from > >> > >> testing. In tabular form: > >> > >> passfail > >> swi-prolog from testing8.4.2+dfsg-2 > >> logol from testing1.7.9+dfsg-1 > >> all others from testingfrom testing > >> > >> I copied some of the output at the bottom of this report. > >> > >> Currently this regression is blocking the migration of swi-prolog to > >> > >> testing [1]. Due to the nature of this issue, I filed this bug > >> report > >> against both packages. Can you please investigate the situation and > >> reassign the bug to the right package? > >> > >> More information about this bug and the reason for filing it can be > >> found on > >> > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > >> > >> Paul > >> > >> [1] https://qa.debian.org/excuses.php?package=swi-prolog > >> > >> > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/19529867/log.gz > >> > >> calling logol with parameters -g 1799.logol -s 1799.fasta -dna > >> log4j:ERROR setFile(null,true) call failed. > >> java.io.FileNotFoundException: /var/log/logol/logol.log (Permission > >> denied) > >> at java.base/java.io [1].FileOutputStream.open0(Native > >> Method) > >> at java.base/java.io > >> [1].FileOutputStream.open(FileOutputStream.java:298) > >> at java.base/java.io > >> [1].FileOutputStream.(FileOutputStream.java:237) > >> at java.base/java.io > >> [1].FileOutputStream.(FileOutputStream.java:158) > >> at > >> org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > >> at > >> org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > >> at > >> > > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > >> at > >> > > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > >> at > >>
Bug#1006384: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
ok, after a quick look, issue is Logol is compiled against swi-prolog, and there is an ABI issue I think, getting error: incompatible version (file: 67, Prolog: 68)] Recompiling logol in sid against swi-prolog 8.4.2+dfsg-2 results in correct execution/tests. So, 2 things: * As swi-prolog is only a debian update (-1 to -2), I wonder why we have this break now * Possible fix is to rebuild logol package against this version in sid, with a dep requirement on swi-prolog>=8.4.2+dfsg-2. But I don't know how this should be managed (logol in testing will still prevent swi-prolog to go, and logol in sid won't either go to testing because will need swi-prolog version from sid...) Olivier Le jeu. 24 févr. 2022 à 19:36, Paul Gevers a écrit : > Source: swi-prolog, logol > Control: found -1 swi-prolog/8.4.2+dfsg-2 > Control: found -1 logol/1.7.9+dfsg-1 > Severity: serious > Tags: sid bookworm > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of swi-prolog the autopkgtest of logol fails in > testing when that autopkgtest is run with the binary packages of > swi-prolog from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > swi-prolog from testing8.4.2+dfsg-2 > logol from testing1.7.9+dfsg-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of swi-prolog to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found > on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=swi-prolog > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/19529867/log.gz > > calling logol with parameters -g 1799.logol -s 1799.fasta -dna > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied) > at java.base/java.io.FileOutputStream.open0(Native Method) > at java.base/java.io > .FileOutputStream.open(FileOutputStream.java:298) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:237) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:158) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > at > org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) > at > > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) > at > > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) > at > > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) > at > > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) > at org.apache.log4j.LogManager.(LogManager.java:127) > at org.apache.log4j.Logger.getLogger(Logger.java:117) > at org.irisa.genouest.logol.Logol.(Unknown Source) > For help, use option -h > INFO org.irisa.genouest.logol.Logol - Using configuration file: > /usr/share/logol/prolog/logol.properties > INFO org.irisa.genouest.logol.Logol - option g called with 1799.logol > INFO org.irisa.genouest.logol.Logol - option s called with 1799.fasta > INFO org.irisa.genouest.logol.Logol - No maximum solutions defined, > using defaults > INFO org.irisa.genouest.logol.Logol - option dna called > INFO org.irisa.genouest.logol.Logol - Start analyse to create grammar > analyser > Executing prolog for pre-analyse > java.io.FileNotFoundException: > /tmp/1799.logol.be129f0a-eeb3-4c10-a744-e5ccabb1087e.pre.res (No such > file or directory) > at java.base/java.io.FileInputStream.open0(Native Method) > at java.base/java.io > .FileInputStream.open(FileInputStream.java:219) > at java.base/java.io > .FileInputStream.(FileInputStream.java:157) > at java.base/java.io.FileReader.(FileReader.java:75) > at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown > Source) > at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown > Source) > at
Bug#1006384: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Hi, Logol is not maintained for quite a long time now, i will try to have a look, but i am ok to get logol removed from testing to avoid blocking swi prolog Olivier Le jeu. 24 févr. 2022, 19:36, Paul Gevers a écrit : > Source: swi-prolog, logol > Control: found -1 swi-prolog/8.4.2+dfsg-2 > Control: found -1 logol/1.7.9+dfsg-1 > Severity: serious > Tags: sid bookworm > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of swi-prolog the autopkgtest of logol fails in > testing when that autopkgtest is run with the binary packages of > swi-prolog from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > swi-prolog from testing8.4.2+dfsg-2 > logol from testing1.7.9+dfsg-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of swi-prolog to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found > on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=swi-prolog > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/19529867/log.gz > > calling logol with parameters -g 1799.logol -s 1799.fasta -dna > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied) > at java.base/java.io.FileOutputStream.open0(Native Method) > at java.base/java.io > .FileOutputStream.open(FileOutputStream.java:298) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:237) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:158) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > at > org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) > at > > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) > at > > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) > at > > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) > at > > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) > at org.apache.log4j.LogManager.(LogManager.java:127) > at org.apache.log4j.Logger.getLogger(Logger.java:117) > at org.irisa.genouest.logol.Logol.(Unknown Source) > For help, use option -h > INFO org.irisa.genouest.logol.Logol - Using configuration file: > /usr/share/logol/prolog/logol.properties > INFO org.irisa.genouest.logol.Logol - option g called with 1799.logol > INFO org.irisa.genouest.logol.Logol - option s called with 1799.fasta > INFO org.irisa.genouest.logol.Logol - No maximum solutions defined, > using defaults > INFO org.irisa.genouest.logol.Logol - option dna called > INFO org.irisa.genouest.logol.Logol - Start analyse to create grammar > analyser > Executing prolog for pre-analyse > java.io.FileNotFoundException: > /tmp/1799.logol.be129f0a-eeb3-4c10-a744-e5ccabb1087e.pre.res (No such > file or directory) > at java.base/java.io.FileInputStream.open0(Native Method) > at java.base/java.io > .FileInputStream.open(FileInputStream.java:219) > at java.base/java.io > .FileInputStream.(FileInputStream.java:157) > at java.base/java.io.FileReader.(FileReader.java:75) > at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown > Source) > at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown > Source) > at org.irisa.genouest.logol.Logol.analyse(Unknown Source) > at org.irisa.genouest.logol.Logol.execute(Unknown Source) > at org.irisa.genouest.logol.Logol.main(Unknown Source) > INFO org.irisa.genouest.logol.Logol - Analyse in progress.. > WARN org.irisa.genouest.logol.SequenceAnalyser - Path to suffix search > tool is not set in system environment. Will try to execute directly but > may fail if not in PATH of current user > ERROR org.irisa.genouest.logol.SequenceAnalyser - Program exited with > wrong status code:
Bug#1005457: biomaj3-download: FTBFS: ValueError: Error while parsing stop condition: stop_after_attempt(3) doesn't yield a stop condition
Seems that a dependency (tenacity) has been changed with broken api
Need to change code to use new tenacity version
Le dim. 13 févr. 2022, 08:21, Lucas Nussbaum a écrit :
> Source: biomaj3-download
> Version: 3.2.4-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220212 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > nosetests3 -a !network
> > EEE
> > ==
> > ERROR: test_local_download (biomaj_tests.TestBiomajLocalDownload)
> > --
> > Traceback (most recent call last):
> > File "/<>/biomaj_download/download/interface.py", line
> 272, in _set_retryer
> > s(tenacity.compat.make_retry_state(0, 0))
> > AttributeError: module 'tenacity' has no attribute 'compat'
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/<>/biomaj_download/download/interface.py", line
> 274, in _set_retryer
> > raise ValueError(stop_condition + " doesn't yield a stop condition")
> > ValueError: stop_after_attempt(3) doesn't yield a stop condition
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/<>/tests/biomaj_tests.py", line 256, in
> test_local_download
> > locald = LocalDownload(self.examples)
> > File "/<>/biomaj_download/download/localcopy.py", line
> 24, in __init__
> > DownloadInterface.__init__(self)
> > File "/<>/biomaj_download/download/interface.py", line
> 171, in __init__
> > self._set_retryer(
> > File "/<>/biomaj_download/download/interface.py", line
> 276, in _set_retryer
> > raise ValueError("Error while parsing stop condition: %s" % e)
> > ValueError: Error while parsing stop condition: stop_after_attempt(3)
> doesn't yield a stop condition
> >
> > ==
> > ERROR: Test download with hardlinks: we download a file from conf/ to
> data_dir.
> > --
> > Traceback (most recent call last):
> > File "/<>/biomaj_download/download/interface.py", line
> 272, in _set_retryer
> > s(tenacity.compat.make_retry_state(0, 0))
> > AttributeError: module 'tenacity' has no attribute 'compat'
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/<>/biomaj_download/download/interface.py", line
> 274, in _set_retryer
> > raise ValueError(stop_condition + " doesn't yield a stop condition")
> > ValueError: stop_after_attempt(3) doesn't yield a stop condition
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/<>/tests/biomaj_tests.py", line 278, in
> test_local_download_hardlinks
> > locald = LocalDownload(self.utils.test_dir, use_hardlinks=True)
> > File "/<>/biomaj_download/download/localcopy.py", line
> 24, in __init__
> > DownloadInterface.__init__(self)
> > File "/<>/biomaj_download/download/interface.py", line
> 171, in __init__
> > self._set_retryer(
> > File "/<>/biomaj_download/download/interface.py", line
> 276, in _set_retryer
> > raise ValueError("Error while parsing stop condition: %s" % e)
> > ValueError: Error while parsing stop condition: stop_after_attempt(3)
> doesn't yield a stop condition
> >
> > ==
> > ERROR: test_local_download_in_subdir
> (biomaj_tests.TestBiomajLocalDownload)
> > --
> > Traceback (most recent call last):
> > File "/<>/biomaj_download/download/interface.py", line
> 272, in _set_retryer
> > s(tenacity.compat.make_retry_state(0, 0))
> > AttributeError: module 'tenacity' has no attribute 'compat'
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/<>/biomaj_download/download/interface.py", line
> 274, in _set_retryer
> > raise ValueError(stop_condition + " doesn't yield a stop condition")
> > ValueError: stop_after_attempt(3) doesn't yield a stop condition
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/<>/tests/biomaj_tests.py", line 264, in
> test_local_download_in_subdir
> > locald = LocalDownload(self.curdir+'/')
> > File "/<>/biomaj_download/download/localcopy.py", line
> 24, in __init__
> > DownloadInterface.__init__(self)
> > File "/<>/biomaj_download/download/interface.py", line
> 171, in __init__
> > self._set_retryer(
>
Bug#1005279: ncbi-plus+ uses "phone home" to send reports by default
Package: ncbi-blast+ Version: 2.12.0+ds-2 By default, software sends over internet some usage reports. It uses optout strategy (sends data unless you specify by config the contrary) Should use optin strategy (user accepts to send report)
Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar
It appears than xalan2 (requires)-> xerces2 (requires)-> libxml-commons-external-java explicitly removes versioned jar in its build (debian/libxml-commons-external-java.poms) debian/xml-apis.xml --java-lib --usj-name=xml-apis --artifact=xml-apis.jar --no-usj-versionless Don't know why but it breaks logol. Fix would be to symlink to versioned jar, but will break on next libxml-commons-external-java update. Could certainly be scripted to get related version and link to this version file. Olivier Le lun. 17 mai 2021 à 14:05, Andreas Tille a écrit : > Hi, > > I'd like to forward this to Debian Java list for comments. > > Kind regards > > Andreas. > > On Mon, May 17, 2021 at 01:50:01PM +0200, olivier sallou wrote: > > Issue seems to be related to xml-apis.jar not being symlinked itself > > > > /usr/share/java# ls *xml-api* > > xml-apis-1.4.01.jar xml-apis-ext-1.4.01.jar xml-apis-ext.jar > > > > Usually, java libs have a versioned file and an unversionned file which > is > > a symlink to versioned one (see above). > > xml-apis here is not available as unversioned (breaks previous versions) > > > > Logo requires xalan2 and xerces2, must be a sub-dependency, should -ext > be > > used? > > > > Le lun. 17 mai 2021 à 13:33, Andreas Beckmann a écrit > : > > > > > Package: logol > > > Version: 1.7.9-2 > > > Severity: serious > > > User: debian...@lists.debian.org > > > Usertags: piuparts > > > > > > Hi, > > > > > > during a test with piuparts I noticed your package ships (or creates) > > > a broken symlink. > > > > > > From the attached log (scroll to the bottom...): > > > > > > 1m53.8s ERROR: FAIL: Broken symlinks: > > > /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol) > > > > > > Is logol missing a dependency on libjaxp1.3-java ? > > > > > > > > > cheers, > > > > > > Andreas > > > > > > ___ > > Debian-med-packaging mailing list > > debian-med-packag...@alioth-lists.debian.net > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > > -- > http://fam-tille.de > -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar
Issue seems to be related to xml-apis.jar not being symlinked itself /usr/share/java# ls *xml-api* xml-apis-1.4.01.jar xml-apis-ext-1.4.01.jar xml-apis-ext.jar Usually, java libs have a versioned file and an unversionned file which is a symlink to versioned one (see above). xml-apis here is not available as unversioned (breaks previous versions) Logo requires xalan2 and xerces2, must be a sub-dependency, should -ext be used? Le lun. 17 mai 2021 à 13:33, Andreas Beckmann a écrit : > Package: logol > Version: 1.7.9-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > From the attached log (scroll to the bottom...): > > 1m53.8s ERROR: FAIL: Broken symlinks: > /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol) > > Is logol missing a dependency on libjaxp1.3-java ? > > > cheers, > > Andreas >
Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar
need to check, but I suppose referenced lib changed its path or name in dependencies... Le lun. 17 mai 2021 à 13:33, Andreas Beckmann a écrit : > Package: logol > Version: 1.7.9-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > > From the attached log (scroll to the bottom...): > > 1m53.8s ERROR: FAIL: Broken symlinks: > /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol) > > Is logol missing a dependency on libjaxp1.3-java ? > > > cheers, > > Andreas >
Bug#976174: Made an itp
Le mer. 23 déc. 2020 à 10:37, Devops PK Carlisle LLC a écrit : > Thanks for responding. This is the first software I have ever submitted > for Debian, so please forgive any amateur misunderstandings regarding > the process. > > - The email (below) which retitles the software notes "stopping > processing here". Should I attempt to repackage papershaper as a .deb or > is the .git sufficient? I have never compiled a .deb before. > There are plenty of tutorials but also debian policies file to read ;-) If pure python, as a first step if not already done, you could package for python and upload to pypi. > - The entire install "process" is to > * place the contents into a folder called ~/com.pkcarlisle/papershaper > in the user home directory. There are no additions to or changes to > system level files > Deb packages do not install anything in user home (you may be on a multi user system), but place files in usr, var, etc etc * check for and/or resolve dependencies for Python 3 and lynx > Dependencies must all resolve on debian side with debian packages. So script must not install any dep by itself (defined in control file of deb package) * (optionally) add a start up command as > python3 ~/com.pkcarlisle/papershaper/papershaper.py > Would be placed in usr/bin > > If the wishlist is waiting for me to compile papershaper into a .deb I > can give it a try, but I do not want the wishlist to be waiting for > something and for me not to know about the next steps. > If you create an ITP then people are waiting for you to do the job. Then you only need a sponsor to upload final reviewed package If you create an RFP then you ask "someone" to package it for you. But all depends on volunteers. > On 12/22/20 3:27 PM, Debian Bug Tracking System wrote: > > Processing commands for cont...@bugs.debian.org: > > > >> retitle 976174 ITP: papershaper -- automagic wallpaper swapper > > Bug #976174 [wnpp] ITP:papershaper--automagic wallpaper swapper > > Changed Bug title to 'ITP: papershaper -- automagic wallpaper swapper' > from 'ITP:papershaper--automagic wallpaper swapper'. > >> thanks > > Stopping processing here. > > > > Please contact me if you need assistance. > > On 12/22/20 2:30 PM, Devops PK Carlisle LLC wrote: > > Thanks for responding. > > > > If I understand the definitions correctly, I should resubmit this as an > > RFP since it has never been included in a Debian (or other Linux) > release? > > > > Being kind of careful about the definition of a package here... > > > > The software is here as a git > > > > https://github.com/pkcarlislellc/git-papershaper > > > > here as a tarball: > > > > https://sourceforge.net/projects/papershaper/ > > > > It is open source licensed, and does not download anything as part of > > the install process. It has two dependencies: Python and the lynx > > browser. Python 2 and 3 versions are included in the tarball but it is > > presumed that the preferred Python version is now Python 3, so that is > > the default. > > > > It does optionally download images, but only on execution. > > > > > > On 12/22/20 1:54 PM, olivier sallou wrote: > >> You created an itp so an intent to package. > >> If not willing to propose a apckage should be an rfp request for > package. > >> Ideally you package your app and propose it for review and upload. > >> Requirements are an open source license and package install should not > >> download anything. > >> Only its execution can download remote stuff. > >> > >> Olivier >
Bug#976174: Made an itp
You created an itp so an intent to package. If not willing to propose a apckage should be an rfp request for package. Ideally you package your app and propose it for review and upload. Requirements are an open source license and package install should not download anything. Only its execution can download remote stuff. Olivier
Bug#972250: vienna-rna binaries upload
Hi, andreas, thanks for binaries upload, but I do not see on tracker any upload/change, is it expected? Graham, if binaries have been uploaded why do you set bug level back to serious? Should not be an issue anymore (but my action to allow for autobuild for further uploads) thanks Olivier
Bug#972250: autobuild request sent
I just asked to allow for package autobuild, waiting for answer If accepted will check for builds, else upload with binaries Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#973070: [Debian-med-packaging] Bug#973070: Help needed: Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 exc
On Wed, 2020-10-28 at 09:05 +0100, Andreas Tille wrote: > Hi, > > On Tue, Oct 27, 2020 at 10:55:43PM +0100, Markus Koschany wrote: > > This appears to be caused by the recent upgrade of Apache commons- > > io to > > version 2.8.0 (we had 2.6), see also #973135. In version 2.7 they > > removed a throws IOException in the method isSymlink() > > > > https://issues.apache.org/jira/browse/IO-610 > > > > Could it be related to this change? It is probably necessary to > > update > > the testcase or disable it for a quick workaround. > > I tried to implement this workaroung in this patch > > > https://salsa.debian.org/med-team/libsis-base-java/-/blob/master/debian/patches/skip_testGetLinkInfoSymLinkDanglingLink.patch > > but unfortunately the test is executed anyway: *dumb* patch would be to simply remove those tests from code... > > ... > Running testTouchSymLinkAndFile > Running testGetLinkInfoSymLinkDanglingLink > Running testGetLinkInfoNonExistent > Could not delete the directory targets/unit-test- > wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 exceptions: > [java.io.IOException: Unable to delete file: targets/unit-test- > wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink] > Could not delete the directory targets/unit-test- > wd/ch.systemsx.cisd.base.unix.UnixTests in second try because: 1 > exceptions: [java.io.IOException: Unable to delete file: > targets/unit-test- > wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink] > Exception in thread "main" org.apache.commons.io.IOExceptionList: 1 > exceptions: [java.io.IOException: Unable to delete file: > targets/unit-test- > wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink] > ... > > > Am I missing something? > > Kind regards > >Andreas. > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#673724: Relicensing done by upstream
Good news, upstream license has been modified after some rewriting (see issue closed https://github.com/jshint/jshint/issues/1234), so should fit for debian now
Bug#963430: Any volunteer to spent some time on the new version of artemis (Was: Bug#963430: artemis: FTBFS: /bin/sh: 1: /usr/share/java/j2ssh-core.jar: Permission denied)
On Mon, 2020-06-22 at 10:57 -0300, Emmanuel Arias wrote: > Hi Andreas, > > I would be happy to help on artemis. Obviously I will need > a more experienced developer helping me. :) do not hesitate to ask for help on mailing list, I'll keep an eye on it. I have very few spare time to manage this for now but will gladly help if possible. Olivier > > Cheers! > Emmanuel > > > > > > Cheers, > Arias Emmanuel > @eamanu > yaerobi.com > > > On Mon, Jun 22, 2020 at 9:17 AM Andreas Tille > wrote: > > Hi, > > > > we are lagging several upstream versions behind due to new > > dependencies > > and other build issues. I wonder whether somebody might volunteer > > to > > update artemis. It would be great to get the latest version at > > least > > before the freeze starts. While this takes some time I guess > > having > > latest artemis is time consuming as well - thus I'm asking here. > > > > Any takers? Despite I'm the only remaining Uploader this exceeds > > my > > current time capacity. > > > > Kind regards > > > > Andreas. > > > > On Sun, Jun 21, 2020 at 10:26:05PM +0200, Lucas Nussbaum wrote: > > > Source: artemis > > > Version: 17.0.1+dfsg-2 > > > Severity: serious > > > Justification: FTBFS on amd64 > > > Tags: bullseye sid ftbfs > > > Usertags: ftbfs-20200620 ftbfs-bullseye > > > > > > Hi, > > > > > > During a rebuild of all packages in sid, your package failed to > > build > > > on amd64. > > > > > > Relevant part (hopefully): > > > > debian/rules build > > > > dh build --with javahelper > > > >dh_update_autotools_config > > > >dh_autoreconf > > > >dh_auto_configure > > > >jh_linkjars > > > >debian/rules override_dh_auto_build > > > > make[1]: Entering directory '/<>' > > > > dh_auto_build -- jar > > > > make -j4 "INSTALL=install --strip-program=true" jar > > > > make[2]: Entering directory '/<>' > > > > CLASSPATH=/usr/share/java/biojava.jar /usr/share/java/j2ssh- > > core.jar /usr/share/java/ibatis.jar /usr/share/java/log4j-1.2.jar > > /usr/share/java/postgresql-jdbc3.jar /usr/share/java/picard.jar > > /usr/share/java/htsjdk.jar /usr/share/java/commons-net.jar > > /usr/share/java/commons-lang3.jar /usr/share/java/batik-all.jar > > /usr/share/java/batik-awt-util.jar /usr/share/java/batik-dom.jar > > /usr/share/java/batik-ext.jar /usr/share/java/batik-svggen.jar > > /usr/share/java/batik-util.jar /usr/share/java/batik-xml.jar > > /usr/share/EMBOSS/jemboss/lib/jemboss.jar /<>: javac > > -source 1.8 -target 1.8 uk/ac/sanger/artemis/Action.java > > > > CLASSPATH=/usr/share/java/biojava.jar /usr/share/java/j2ssh- > > core.jar /usr/share/java/ibatis.jar /usr/share/java/log4j-1.2.jar > > /usr/share/java/postgresql-jdbc3.jar /usr/share/java/picard.jar > > /usr/share/java/htsjdk.jar /usr/share/java/commons-net.jar > > /usr/share/java/commons-lang3.jar /usr/share/java/batik-all.jar > > /usr/share/java/batik-awt-util.jar /usr/share/java/batik-dom.jar > > /usr/share/java/batik-ext.jar /usr/share/java/batik-svggen.jar > > /usr/share/java/batik-util.jar /usr/share/java/batik-xml.jar > > /usr/share/EMBOSS/jemboss/lib/jemboss.jar /<>: javac > > -source 1.8 -target 1.8 > > uk/ac/sanger/artemis/ActionController.java > > > > /bin/sh: 1: /usr/share/java/j2ssh-core.jar: Permission denied > > > > make[2]: *** [Makefile:48: uk/ac/sanger/artemis/Action.class] > > Error 126 > > > > > > The full build log is available from: > > > > > http://qa-logs.debian.net/2020/06/20/artemis_17.0.1+dfsg-2_unstable.log > > > > > > A list of current common problems and possible solutions is > > available at > > > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to > > contribute! > > > > > > About the archive rebuild: The rebuild was done on EC2 VM > > instances from > > > Amazon Web Services, using a clean, minimal and up-to-date > > chroot. Every > > > failed build was retried once to eliminate random failures. > > > > > > ___ > > > Debian-med-packaging mailing list > > > debian-med-packag...@alioth-lists.debian.net > > > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#960756: [Debian-med-packaging] Bug#960756: python-biopython FTBFS on 32bit: test_NCBI_BLAST_tools.BlastDB failures
Le mar. 9 juin 2020 à 16:47, Aaron M. Ucko a écrit : > Andreas Tille writes: > > > On Tue, Jun 09, 2020 at 02:25:58PM +0200, Étienne Mollier wrote: > >> My current impression is that makeblastdb is unable to work > >> properly on most 32 bits machines, because the amount of memory > >> needing to be addressed by the process looks like it might > >> exceed too easily 32 bits architectural limits. > > That's entirely plausible; upstream tends to assume 64-bit systems > nowadays. Explicitly supplying -blastdb_version 4 (the default prior to > BLAST+ 2.10.x) may help. > options: * simply remove 32bit package from Debian (though should work on *small* datasets). more and more systems are going to 64bit only, and we don't have the task force to fix 32bits issues on such software (too much effort) OR * ignore issue as it is related to memory management but will work on relatively *small* jobs, so software is ~OK 'till a certain point. Olivier > > Thanks for calling this report to my attention! > > -- > Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) > http://www.mit.edu/~amu/ | > http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu > -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#961700: picard-tools build depends on the removed libguava-java-doc
Le jeu. 28 mai 2020 à 13:00, Andreas Tille a écrit : > Hi Olivier and Vincent > > On Thu, May 28, 2020 at 09:47:37AM +0300, Adrian Bunk wrote: > > > > picard-tools build depends on libguava-java-doc, > > which is no longer built by src:guava-libraries. > Hi andreas, looking at issue, where did you find that libguava-java-doc is no longer built ? I looked at https://packages.debian.org/source/sid/guava-libraries and still see -doc package Olivier > > I've tried to simply leave out libguava-java-doc but either this breaks > a test or the package is failing its build time test for some other > reason: > > > * Exception is: > org.gradle.api.tasks.TaskExecutionException: Execution failed for task > ':barclayTest'. > at > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100) > at > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70) > at > org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51) > at > org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62) > at > org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54) > at > org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60) > at > org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97) > at > org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87) > at > org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52) > at > org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) > at > org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54) > at > org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) > at > org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98) > at > org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626) > at > org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) > at > org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) > at > org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55) > Caused by: org.gradle.api.GradleException: There were failing tests. See > the report at: > file:///build/picard-tools-2.18.25+dfsg/build/reports/tests/barclayTest/index.html > at > org.gradle.api.tasks.testing.AbstractTestTask.handleTestFailures(AbstractTestTask.java:547) > at >
Bug#961700: picard-tools build depends on the removed libguava-java-doc
Le jeu. 28 mai 2020 à 13:00, Andreas Tille a écrit : > Hi Olivier and Vincent > > On Thu, May 28, 2020 at 09:47:37AM +0300, Adrian Bunk wrote: > > > > picard-tools build depends on libguava-java-doc, > > which is no longer built by src:guava-libraries. > > I've tried to simply leave out libguava-java-doc but either this breaks > a test or the package is failing its build time test for some other > reason: > will try to have a look, but -doc removal should not create issues in test, so maybe it is an other dependency update that creates the issue. Will try to upgrade, but indeed, it is always quite hard to do so.. Olivier > > > * Exception is: > org.gradle.api.tasks.TaskExecutionException: Execution failed for task > ':barclayTest'. > at > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100) > at > org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70) > at > org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51) > at > org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62) > at > org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54) > at > org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60) > at > org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97) > at > org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87) > at > org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52) > at > org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) > at > org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54) > at > org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) > at > org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199) > at > org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241) > at > org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98) > at > org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626) > at > org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581) > at > org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) > at > org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) > at > org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55) > Caused by: org.gradle.api.GradleException: There were failing tests. See > the report at: > file:///build/picard-tools-2.18.25+dfsg/build/reports/tests/barclayTest/index.html > at > org.gradle.api.tasks.testing.AbstractTestTask.handleTestFailures(AbstractTestTask.java:547) > at >
Bug#961013: [Debian-med-packaging] Bug#961013: diamond-aligner: Diamond faill with the error: Assertion `index >= 0 && index < size()' failed.
On Tue, 2020-05-19 at 08:19 -0300, Marcelo Luiz de Laia wrote: > Package: diamond-aligner > Version: 0.9.32-2 > Severity: important > > Dear Maintainer, > > I run diamond like this: > > diamond blastx --threads 2 --outfmt 5 --max-target-seqs 5 --evalue > 1e-5 --db > /home/marcelo/Diamond_DB/nr --query /home/marcelo/Google\ > Drive/Mlaia/NoISeq/ExonID_GDE.fa -o /home/marcelo/Google\ > Drive/Mlaia/Blastn/blastx.exons.diamond.xml > > And I got this error: did not tried with blastx but debian has some autotests on blastp (and tried on a fresh install with example files) and faced no issue with diamond. example: diamond blastp --threads 1 --db 'M.faa.diamond' --query 'L.faa' --out L.faa.vs.M.faa.diamond -e 1e-05 --outfmt 6 --sensitive diamond has no dependency on other debian libs, so it cannot be an issue with an external lib being too old (or recent). as package is built based on git release tag, code should be the same, so is very difficult to debug (without knowing code itself). compilation issue? Olivier > > marcelo@marcelo:~/Google Drive/Mlaia/Blastn$ diamond blastx --outfmt > 5 --max- > target-seqs 5 --evalue 1e-5 --db /media/marcelo/Seagate\ Expansion\ > Drive/NCBI_DB/Diamond/nr --query /home/marcelo/Google\ > Drive/Mlaia/NoISeq/ExonID_GDE.fa -o /home/marcelo/Google\ > Drive/Mlaia/Blastn/blastx.exons.diamond.xml > diamond v0.9.32.133 (C) Max Planck Society for the Advancement of > Science > Documentation, support and updates available at > http://www.diamondsearch.org > > #CPU threads: 4 > Scoring parameters: (Matrix=BLOSUM62 Lambda=0.267 K=0.041 > Penalties=11/1) > Temporary directory: /home/marcelo/Google Drive/Mlaia/Blastn > Opening the database... [0s] > #Target sequences to report alignments for: 5 > Reference = /media/marcelo/Seagate Expansion > Drive/NCBI_DB/Diamond/nr.dmnd > Sequences = 282858011 > Letters = 101765175729 > Block size = 20 > Opening the input file... [0s] > Opening the output file... [0s] > Loading query sequences... [0.046s] > Masking queries... diamond: /build/diamond-aligner-jUHUMq/diamond- > aligner-0.9.32/src/lib/Eigen/src/Core/DenseCoeffsBase.h:408: > Eigen::DenseCoeffsBase::Scalar& > Eigen::DenseCoeffsBase 1>::operator[](Eigen::Index) [with Derived = Eigen::Array 1>; > Eigen::DenseCoeffsBase::Scalar = float; Eigen::Index = > long int]: > Assertion `index >= 0 && index < size()' failed. > diamond: /build/diamond-aligner-jUHUMq/diamond- > aligner-0.9.32/src/lib/Eigen/src/Core/DenseCoeffsBase.h:408: > Eigen::DenseCoeffsBase::Scalar& > Eigen::DenseCoeffsBase 1>::operator[](Eigen::Index) [with Derived = Eigen::Array 1>; > Eigen::DenseCoeffsBase::Scalar = float; Eigen::Index = > long int]: > Assertion `index >= 0 && index < size()' failed. > Abortado > marcelo@marcelo:~/Google Drive/Mlaia/Blastn$ > > I opened a issue on diamond support forum at > https://github.com/bbuchfink/diamond/issues/351 > > Please, could you see that thread? May be this bug is only in the > Debian > version, because I run the github version 0.32 and it worked out of > the box. > > Thank you. > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'stable'), (250, 'unstable'), > (50, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), > LANGUAGE=pt_BR:pt:en (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages diamond-aligner depends on: > ii libc6 2.30-7 > ii libgcc-s1 10.1.0-1 > ii libstdc++6 10.1.0-1 > ii zlib1g 1:1.2.11.dfsg-2 > > Versions of packages diamond-aligner recommends: > ii med-config 3.5.1 > > diamond-aligner suggests no packages. > > -- no debconf information > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#960654: [Debian-med-packaging] Bug#960654: src:biojava4-live: Please add support to build against libjson-simple-java >= 3
Hi, thanks for the patch. However, if json-simple API/ABI is broken, I think that package should be kinda libjson-simple3-java to keep compatibility with existing packages using old versions and allow transition of packages to new release if needed and possible. Anyway, gonna add your patch Olivier On Fri, 2020-05-15 at 09:41 +0200, Gilles Filippini wrote: > Package: src:biojava4-live > Version: 4.2.12+dfsg-2 > Severity: normal > Tags: patch > > Hi, > > I'd like to transition json-simple 3.1.1 to unstable, but biojava4- > live is a blocker since it builds against libjson-simple-java << 3 > only. > > The json-simple classes used by biojava4-live were deprecated in > version 2.0.0 [1]. There were removed in versions 3.x [2]. > > [1] > https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt > [2] > https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG > > Please find attached a patch proposal to use the current json-simple > classes. I've tested that the package builds correctly against > libjson-simple-java version 2.3.0-1 from unstable and version 3.1.1- > 1~exp2 currently in experimental, and the build time test cases > report no errors. > > Thanks in advance for considering. > > _g. > > -- System Information: > Debian Release: buster/sid > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.6.0-1-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 /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#937177: obitools: Python2 removal in sid/bullseye
Le sam. 7 mars 2020 à 06:12, Sergio Durigan Junior a
écrit :
> On Sunday, January 12 2020, Andreas Tille wrote:
>
> > On Sun, Jan 12, 2020 at 07:27:59AM -0500, Scott Kitterman wrote:
> >> On Fri, 30 Aug 2019 07:28:59 + Matthias Klose
> wrote:
> >> This
> >> package is blocking several others. Would it be best to remove it? It
> can
> >> always be re-introduced if a python3 port appears.
> >
> > Since some time I've pushed a 2to3 based port to Git. I've now fixed
> > some issues of this and I wonder whether we might give it a try to do
> > the port inside Debian. For the moment I'm running into the following
> > issue:
> >
> >dh_auto_test -O--buildsystem=pybuild
> > I: pybuild base:217: cd
> /build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build; python3.7
> -m unittest discover -v
> > obitools (unittest.loader._FailedTest) ... ERROR
> >
> > ==
> > ERROR: obitools (unittest.loader._FailedTest)
> > --
> > ImportError: Failed to import test module: obitools
> > Traceback (most recent call last):
> > File "/usr/lib/python3.7/unittest/loader.py", line 470, in
> _find_test_path
> > package = self._get_module_from_name(name)
> > File "/usr/lib/python3.7/unittest/loader.py", line 377, in
> _get_module_from_name
> > __import__(name)
> > File
> "/build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build/obitools/__init__.py",
> line 23, in
> > from _obitools import BioSequence,NucSequence,AASequence, \
> > ModuleNotFoundError: No module named '_obitools'
> >
> >
> > --
> > Ran 1 test in 0.000s
>
> Hey Andreas,
>
> I cannot reproduce this bug when building inside a clean schroot
> (unstable). I don't know if the reason is because I don't have
> python3.7 installed in the schroot anymore (it was removed recently, and
> python3.8 is the default), or because there's something else different.
>
I pushed in february during our sprint some updates in git fixing the
issue. However it implied lots of modification that may impact software as
it implied to do some choices on types (bytes vs str for example with c
binding), without really knowing the impact
We may push the package but other packages using might be broken
On other side, package will be removed.
So either we push an update, knowing that it may not be fully fonctional,
or let it go.
Olivier
> > FAILED (errors=1)
> > E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1:
> cd /build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build;
> python3.7 -m unittest discover -v
> > dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit
> code 13
> > make: *** [debian/rules:15: build] Error 255
> > dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
> > I: copying local configuration
> > E: Failed autobuilding of package
> > I: user script
> /var/cache/pbuilder/build/cow.1543005/tmp/hooks/C99_failed_build starting
> > Installing convenience apps: mc less bash-completion
> > root@energija:/# cd build/obitools-1.2.13+dfsg/
> > root@energija:/build/obitools-1.2.13+dfsg# find . -name "*.so"
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/options/_
> options.cpython-37m-x86_64-linux-gnu.so
>=
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/options/_
> bioseqfilter.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/profile/_
> profile.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/utils/_
> utils.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/_
> obitools.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/tools/_
> solexapairend.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/fasta/_
> fasta.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> upperbond.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> rassemble.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> freeendgapfm.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> nwsdnabyprot.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> assemble.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> freeendgap.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> qsrassemble.cpython-37m-x86_64-linux-gnu.so
> > ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_
> gprofilenws.cpython-37m-x86_64-linux-gnu.so
> >
Bug#952208: python-ftputil
Le mer. 4 mars 2020 à 16:38, eamanu a écrit : > Hi olivier, > > On 04/03/2020 12:13, olivier sallou wrote: > > Hi, > > I saw you started some work on python-ftputil to fix #952208. > > > > I just pushed to git repo a fix for that. > > I am a little confused, you just added description to the patch? > No, I added a patch "debian/patches/fix_tests_future.patch" as explained in d/changelog > > Why do you douplicate on d/changelog the (Closes #bugnumber) sentence? > [0] > was temporary, just referring what my patch impacts and will close this issue. The skip you made in your patch does not fix all issues, only workaround them. > > > > > Will you push new patch release soon? Or should I do? > > I'm DM and I will need sponsorhip. > I am DD, so I can upload it if you think it is "over" for you. > > > > I wonder however why you pushed a gbp.conf (not really expected usually) > > setting branch as debian/master , which does not exists and default > > being master. > > I push gbp.conf and set debian/master as default branch to be the > repository according to the DPMT policy recommendation [1] and DEP-14 [2] > ooh ok, I see a "new" debian/master branch, which did not exists on my local clone So I pushed to master branch instead of debian/master. that's reason why we do not "see" everything... I have updated debian/master branch accordingly I pushed my patch and disabled your patch to skip the tests from d/patches/series A gbp buildpackage works with all tests now. Maybe master branch should be removed to avoid this kind of confusion Olivier > [0] > > https://salsa.debian.org/python-team/modules/python-ftputil/-/commit/a52fad2009b720882fed9bbed366b5e70e9154ae > [1] > > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#branch-names > [2] https://dep-team.pages.debian.net/deps/dep14/ > > Cheers! > > -- > Emmanuel Arias > @eamanu > yaerobi.com >
Bug#952208: python-ftputil
Hi, I saw you started some work on python-ftputil to fix #952208. I just pushed to git repo a fix for that. Will you push new patch release soon? Or should I do? I wonder however why you pushed a gbp.conf (not really expected usually) setting branch as debian/master , which does not exists and default being master. Olivier
Bug#925797: pushed patch to git
I pushed to git a patch that seems to fix the undefined ref to InitGoogle... Still need to test full build (very long...) Olivier
Bug#936797: cannot find way to use pbcommand API
pbcommand in debian (latest from github) provide a different API, but pbcommand doc and README all show previous API example and show usage of get_pbparser function, but this method is not present anymore. It is not possible to *guess* what should be used instead. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#936797: depends on pbcommand with a different api
Tried to look at python3 port. However it depends on pbcommand, and pbcommand api is different from expected by kinetictools (means py2 version is broken). Trying to see how to use current pbcommand api, but looks quite different. Olivier
Bug#937258: ported and uploaded
py3 fix sent and uploaded, by introduces new py3 packages, so in NEW queue for the moment
Bug#950914: python3-biomaj3: Depends on python-influxdb wich ftbs, patch to remove dependency
Package: python3-biomaj3 Version: 3.1.14-1 Severity: minor Due to #950063 "influxdb-python FTBFS with pandas 0.25.3", biomaj3 cannot use influxdb. Patch software to remove influxdb python dependency waiting for fix of package.
Bug#939832: chado-utils: installation error
On 12/4/19 12:37 PM, Andreas Tille wrote: > Control: tags -1 moreinfo > Control: tags -1 unreproducible > > Hi Olivier, > > chado-utils installs nicely on my testing system. Does the > issue persist on your side or can we close this bug? reproducible in docker container (buster or sid). Seems in fact related to libchado-perl, not chado-utils (but libchado-perl is a dependency, reason why it failed). Issue is with (I think) $USER being not set in containers. postinstall script (Makefile.PL) expects CHADO_DB_USERNAME or USER env vars. Not yet clear to me if CHADO_DB_USERNAME is required anyway. So I think we could "move" bug to libchado-perl (do you know if there is a way to move a bug to an other package?) , a patch would be set to set: exportCHADO_DB_USERNAME=chado in libchado-perl postinst next to export CHADO_DB_NAME I will do the patch Olivier > > Kind regards > > Andreas. > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#939832: chado-utils: installation error
On 12/4/19 12:37 PM, Andreas Tille wrote: > Control: tags -1 moreinfo > Control: tags -1 unreproducible > > Hi Olivier, > > chado-utils installs nicely on my testing system. Does the > issue persist on your side or can we close this bug? I could reproduce in a docker container on buster (and sid) after an apt update and upgrade apt/sources.list: /# more /etc/apt/sources.list # deb http://snapshot.debian.org/archive/debian/20190910T00Z buster main deb http://deb.debian.org/debian buster main # deb http://snapshot.debian.org/archive/debian-security/20190910T00Z buster/updates main deb http://security.debian.org/debian-security buster/updates main # deb http://snapshot.debian.org/archive/debian/20190910T00Z buster-updates main deb http://deb.debian.org/debian buster-updates main An apt-get install chado-utils ends with: dpkg: error processing package libchado-perl (--configure): installed libchado-perl package post-installation script subprocess returned error exit status 2 Setting up libxmlrpc-lite-perl (0.717-2) ... dpkg: dependency problems prevent configuration of chado-utils: chado-utils depends on libchado-perl; however: Package libchado-perl is not configured yet. . . Errors were encountered while processing: libchado-perl chado-utils E: Sub-process /usr/bin/dpkg returned an error code (1) The error occurs in fact at libchado-perl: Setting up libchado-perl (1.31-5) ...^M dpkg: error processing package libchado-perl (--configure):^M installed libchado-perl package post-installation script subprocess returned error exit status 2^M Setting up libxmlrpc-lite-perl (0.717-2) ...^M dpkg: dependency problems prevent configuration of chado-utils:^M chado-utils depends on libchado-perl; however:^M Package libchado-perl is not configured yet.^M ^M dpkg: error processing package chado-utils (--configure):^M dependency problems - leaving unconfigured^M If I run manually the postinstall script, it "works", an exit code of 102 is executed (which is fine and trapped by script). If I rerun it I get an exitcode = 2 on line 47 (perl Makefile.PL update ) This is my issue during apt install . It seems that it expects in env vars either: CHADO_DB_USERNAME or USER In container "world" , $USER is not set, so neither is available. So in postinst, I think we should add export CHADO_DB_USERNAME=chado next to export CHADO_DB_NAME > > Kind regards > > Andreas. > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#938521: Issues to build latest spades
On 11/12/19 7:59 PM, Andreas Tille wrote: > Hi, > > I've updated unicycler in Git. When running the autopkgtest I get > an issue with spades. So I went on to spades trying hard to build > its latest version but I was running into: > > ... > == Running assembler: K21 > > 'dict' object has no attribute 'iteritems' > Traceback (most recent call last): > File "/build/spades-3.13.1/install_spades/bin/spades.py", line 901, in main > used_K = spades_logic.run_spades(tmp_configs_dir, bin_home, spades_cfg, > dataset_data, ext_python_modules_home, log) > File > "/build/spades-3.13.1/install_spades/../../share/spades/spades_pipeline/spades_logic.py", > line 334, in run_spades > run_iteration(configs_dir, execution_home, cfg, log, K, None, False) > File > "/build/spades-3.13.1/install_spades/../../share/spades/spades_pipeline/spades_logic.py", > line 217, in run_iteration > for src, target in list(replacements.iteritems()): > AttributeError: 'dict' object has no attribute 'iteritems' in python3, there is no more iteritems, should use .items() Olivier > > > == Error == exception caught: > > In case you have troubles running SPAdes, you can write to > spades.supp...@cab.spbu.ru > or report an issue on our GitHub repository github.com/ablab/spades > Please provide us with params.txt and spades.log files from the output > directory. > /build/spades-3.13.1/install_spades/bin/spades.py:872: YAMLLoadWarning: > calling yaml.load() without Loader=... is deprecated, as the default Loader > is unsafe. Please read https://msg.pyyaml.org/load for full details. > dataset_data = pyyaml.load(open(corrected_dataset_yaml_filename, 'r')) > make[1]: *** [debian/rules:61: override_dh_auto_test] Error 1 > > > > Please note: In commit 54bc9d00e8638f0ab350c620e9b5446f776340e7 > I tried to address exactly this issue but failed obviously. > > Any help would be really appreciated. > > Kind regards > > Andreas. > > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#937059: Removing mobyle from Debian? (Was: mobyle: Python2 removal in sid/bullseye)
- Mail original - > De: "andreas" > À: 937...@bugs.debian.org, "debian-med" , > "Olivier Sallou" > Envoyé: Vendredi 8 Novembre 2019 14:07:32 > Objet: Removing mobyle from Debian? (Was: mobyle: Python2 removal in > sid/bullseye) > Hi, > > mobyle homepage[1] says: > > The Mobyle project is now considered a legacy project and the code, although > still available, will no longer maintained after december 31st, 2016. > > So I guess we are on our own with a Python3 port. I'd suggest to > turn this bug into a ROM and remove mobyle from the archive. Software is not maintained anymore and won't have further release. Port to py3 would be huge job, and software has low use now in favor of Galaxy. So it is fine for a ROM Olivier > > Am I missing anything? > > Kind regards > > Andreas. > > > [1] https://projets.pasteur.fr/projects/mobyle > > -- > http://fam-tille.de
Bug#942404: discosnp: flaky autopkgtest: discoRes_k_31_c_auto_D_100_P_1_b_0_coherent.fa: No such file or directory
Just did a test on sid up-to-date, and tests were fine. Will be difficult to forward upstream with bug occuring "sometimes" and not really reproducible. On 10/15/19 9:35 PM, Paul Gevers wrote: > Source: discosnp > Version: 2.3.0-2 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > With a recent upload of python-defaults to unstable, the autopkgtest of > discosnp failed in testing when that autopkgtest was run with the binary > packages of python-defaults from unstable. However, as we check for > regression, the reference was retried and failed as well, without > further changes. I looked into the history of your autopkgtest and it > fails very often. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. Please either fix the test to be more robust, or or use the > "flaky" restriction for the offending test until a solution has been found. > > I copied the output at the bottom of this report. All the failing tests > that I inspected look like it. > > I'll have the migration software ignore the results of your autopkgtest > until this bug is fixed. > > Paul > > https://ci.debian.net/data/autopkgtest/unstable/amd64/d/discosnp/3153055/log.gz > > autopkgtest [08:02:13]: test run-unit-test: [--- > use read set: fof.txt > Running discoSnp++ 2.3.X, in directory /usr with following parameters: >read_sets=fof.txt >prefix=discoRes_k_31_c_auto >c=auto >C=2147483647 >k=31 >b=0 >d=1 >D=100 >starting date=Mon Oct 14 08:02:14 UTC 2019 > > > GRAPH CREATION ### > > /usr/bin/dbgh5 -in > fof.txt_discoRes_k_31_c_auto_D_100_P_1_b_0_removemeplease -out > discoRes_k_31_c_auto -kmer-size 31 -abundance-min auto -abundance-max > 2147483647 -solidity-kind one -verbose 1 -skip-bcalm -skip-bglue -no-mphf > > [DSK: counting kmers ] 0% elapsed: 0 min 0 > sec remaining: 0 min 0 sec cpu: -1.0 % mem: [ 14, 14, > 36] MB > [DSK: Pass 1/1, Step 1: partitioning ] 0% elapsed: 0 min 0 > sec remaining: 0 min 0 sec cpu: -1.0 % mem: [ 46, 46, > 46] MB > EXCEPTION: Pool allocation failed for 128 bytes (kmers alloc), > mainbuffer is null?. Current usage is 144 and capacity is 5242881056 > Pool allocation failed for 1288 bytes (kmers alloc), mainbuffer is > null?. Current usage is 1448 and capacity is 5242881056 > > there was a problem with graph construction > diff: discoRes_k_31_c_auto_D_100_P_1_b_0_coherent.fa: No such file or > directory > *** Test: FAILURE on diff .fa > autopkgtest [08:02:15]: test run-unit-test: -------] > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: OpenPGP digital signature
Bug#905206: [Debian-med-packaging] Bug#905206: Seems to crash in fortran lib
On 10/4/19 3:07 PM, Andreas Tille wrote: > Hi Olivier, > > On Fri, Oct 04, 2019 at 02:14:02PM +0200, olivier sallou wrote: >>> Program received signal SIGSEGV: Segmentation fault - invalid memory >>> reference. >> I really do not see what error could be. Maybe a fortran issue after an >> upgrade (something that was working but not done the same way now) >> Sorry, I have no skill to fix this kind of issue. Should be reported >> upstream > Since Laszlo changed his job we do not have real upstream contact. > >> I see on their web site that it was superseeded by snap2 in 2015. So maybe >> time to let it go > Fine for me. Where exactly did you found this? On https://rostlab.org/owiki/index.php/Snapfun: """ 2015-07-23 : The Snapfun (SNAPweb service) has been superseded by an improved version of SNAP, named SNAP2. Requests for the SNAPweb service now point to SNAP2. If for some reason, you require the original SNAPweb service, please contact he...@rostlab.org. More information about SNAP2 is available here. """ Snap2 links: https://rostlab.org/owiki/index.php/Snap2 https://github.com/Rostlab/SNAP2 > I only found a snap^2 > web interface. What about the reverse depends of profnet? this is indeed an issue, but if "old" release is not maintained anymore and if we don't have local skills on this This kind of issue goes beyond "maintainer" packaging, need skills in language and software itself. > > Kind regards > > Andreas. > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#941805: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: hmmpgmd_ga] ... FAILED [crash!]
- Mail original - > De: "Olivier Sallou" > À: "941805" <941...@bugs.debian.org> > Envoyé: Lundi 7 Octobre 2019 17:09:50 > Objet: Re: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: > hmmpgmd_ga] ... FAILED [crash!] > - Mail original - >> De: "Olivier Sallou" >> À: "941805" <941...@bugs.debian.org> >> Envoyé: Lundi 7 Octobre 2019 17:00:13 >> Objet: Re: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: >> hmmpgmd_ga] ... FAILED [crash!] > >> After a quick look, seems test is looking for hmmc2 executable, that I do not >> found in binaries > > > Indeed, generated package does not contain binary hmmc2, used by test-suite. > Though binary is created and used with tests during package build. > Don't know yet why binary is not included Hi Mickael, I see some pending changes in hmmer you made in git one week ago. testsuite using your updates work (hmmc2 found by testsuite) and could close this issue. Do you plan an upload? You would only have to add a close for this issue. Olivier > >> >> - Mail original - >>> De: "Paul Gevers" >>> À: "submit" >>> Envoyé: Samedi 5 Octobre 2019 22:01:21 >>> Objet: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: >>> hmmpgmd_ga] ... FAILED [crash!] >> >>> Source: hmmer >>> Version: 3.2.1+dfsg-2 >>> X-Debbugs-CC: debian...@lists.debian.org >>> User: debian...@lists.debian.org >>> Usertags: regression >>> >>> Dear maintainers, >>> >>> With a recent upload of hmmer the autopkgtest of hmmer fails in testing >>> when that autopkgtest is run with the binary packages of hmmer from >>> unstable. It passes when run with only packages from testing. In tabular >>> form: >>> passfail >>> hmmer from testing3.2.1+dfsg-2 >>> all others from testingfrom testing >>> >>> I copied some of the output at the bottom of this report. >>> >>> Currently this regression is blocking the migration to testing [1]. Can >>> you please investigate the situation and fix it? >>> >>> More information about this bug and the reason for filing it can be found on >>> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation >>> >>> Paul >>> >>> [1] https://qa.debian.org/excuses.php?package=hmmer >>> >>> https://ci.debian.net/data/autopkgtest/testing/amd64/h/hmmer/3078564/log.gz >>> >>>exercise 292 [ hmmpgmd_ga] ... FAILED [crash!] >>>exercise 293 [ rewind] ... ok. >>>exercise 294 [ brute-itest] ... ok. >>>exercise 295 [ hmmpress-itest] ... ok. >>>exercise 296 [ h39] ... ok. >>>exercise 297 [ h45] ... ok. >>>exercise 298 [ h50] ... ok. >>>exercise 299 [ h82] ... ok. >>> >>> 1 of 299 exercises at level <= 2 FAILED. >>> >>> >>> ___ >>> Debian-med-packaging mailing list >>> debian-med-packag...@alioth-lists.debian.net > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#941805: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: hmmpgmd_ga] ... FAILED [crash!]
After a quick look, seems test is looking for hmmc2 executable, that I do not found in binaries - Mail original - > De: "Paul Gevers" > À: "submit" > Envoyé: Samedi 5 Octobre 2019 22:01:21 > Objet: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: > hmmpgmd_ga] ... FAILED [crash!] > Source: hmmer > Version: 3.2.1+dfsg-2 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainers, > > With a recent upload of hmmer the autopkgtest of hmmer fails in testing > when that autopkgtest is run with the binary packages of hmmer from > unstable. It passes when run with only packages from testing. In tabular > form: > passfail > hmmer from testing3.2.1+dfsg-2 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=hmmer > > https://ci.debian.net/data/autopkgtest/testing/amd64/h/hmmer/3078564/log.gz > >exercise 292 [ hmmpgmd_ga] ... FAILED [crash!] >exercise 293 [ rewind] ... ok. >exercise 294 [ brute-itest] ... ok. >exercise 295 [ hmmpress-itest] ... ok. >exercise 296 [ h39] ... ok. >exercise 297 [ h45] ... ok. >exercise 298 [ h50] ... ok. >exercise 299 [ h82] ... ok. > > 1 of 299 exercises at level <= 2 FAILED. > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#941805: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: hmmpgmd_ga] ... FAILED [crash!]
- Mail original - > De: "Olivier Sallou" > À: "941805" <941...@bugs.debian.org> > Envoyé: Lundi 7 Octobre 2019 17:00:13 > Objet: Re: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: > hmmpgmd_ga] ... FAILED [crash!] > After a quick look, seems test is looking for hmmc2 executable, that I do not > found in binaries Indeed, generated package does not contain binary hmmc2, used by test-suite. Though binary is created and used with tests during package build. Don't know yet why binary is not included > > - Mail original - >> De: "Paul Gevers" >> À: "submit" >> Envoyé: Samedi 5 Octobre 2019 22:01:21 >> Objet: [Debian-med-packaging] Bug#941805: hmmer: autopkgtest regression: >> hmmpgmd_ga] ... FAILED [crash!] > >> Source: hmmer >> Version: 3.2.1+dfsg-2 >> X-Debbugs-CC: debian...@lists.debian.org >> User: debian...@lists.debian.org >> Usertags: regression >> >> Dear maintainers, >> >> With a recent upload of hmmer the autopkgtest of hmmer fails in testing >> when that autopkgtest is run with the binary packages of hmmer from >> unstable. It passes when run with only packages from testing. In tabular >> form: >> passfail >> hmmer from testing3.2.1+dfsg-2 >> all others from testingfrom testing >> >> I copied some of the output at the bottom of this report. >> >> Currently this regression is blocking the migration to testing [1]. Can >> you please investigate the situation and fix it? >> >> More information about this bug and the reason for filing it can be found on >> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation >> >> Paul >> >> [1] https://qa.debian.org/excuses.php?package=hmmer >> >> https://ci.debian.net/data/autopkgtest/testing/amd64/h/hmmer/3078564/log.gz >> >>exercise 292 [ hmmpgmd_ga] ... FAILED [crash!] >>exercise 293 [ rewind] ... ok. >>exercise 294 [ brute-itest] ... ok. >>exercise 295 [ hmmpress-itest] ... ok. >>exercise 296 [ h39] ... ok. >>exercise 297 [ h45] ... ok. >>exercise 298 [ h50] ... ok. >>exercise 299 [ h82] ... ok. >> >> 1 of 299 exercises at level <= 2 FAILED. >> >> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#905206: Seems to crash in fortran lib
Le jeu. 3 oct. 2019 à 12:58, Michael Crusoe a écrit : > Here is the crash with debug symbols (courtesy libc6-dbg libgfortran5-dbg > and a locally created profnet-snapfun-dbgym) > > root@mrc-tux:/tmp# profnet_snapfun switch 385 55 10 46 100 PROFin.dat > PROFacc_tst.jct none > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > I really do not see what error could be. Maybe a fortran issue after an upgrade (something that was working but not done the same way now) Sorry, I have no skill to fix this kind of issue. Should be reported upstream I see on their web site that it was superseeded by snap2 in 2015. So maybe time to let it go > > Backtrace for this error: > #0 0x7faaf117e0ff in ??? > at > /build/glibc-sPWrSm/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 > #1 0x7faaf1680018 in formatted_transfer_scalar_read > at ../../../src/libgfortran/io/transfer.c:1649 > #2 0x7faaf1681803 in formatted_transfer > at ../../../src/libgfortran/io/transfer.c:2326 > #3 0x55a7ca3a63c6 in rdjct_jct2_ > at ./snapfun_dir/prof.f:1042 > #4 0x55a7ca3a7c64 in rdjct_ > at ./snapfun_dir/prof.f:876 > #5 0x55a7ca3b0967 in prof > at ./snapfun_dir/prof.f:108 > #6 0x55a7ca39f25e in main > at ./snapfun_dir/prof.f:179 > Segmentation fault (core dumped) > > On Thu, Oct 3, 2019 at 12:35 PM olivier sallou wrote: > >> >> >> Le jeu. 3 oct. 2019 à 12:08, Michael Crusoe a >> écrit : >> >>> On Sat, 9 Mar 2019 17:44:02 +0100 olivier sallou >>> wrote: >>> > Looking at core generated file and using gdb we see that it fails in >>> > fortran lib. >>> > >>> > Either program tries something wrong in a fortran updated lib version, >>> > either the fortran lib is itself buggy. >>> > >>> > I have no fortran knowledge to debug this however. And it lacks debug >>> info >>> > to find calling line in profnet. >>> >>> The debug symbols exists for non-amd64 archs: >>> https://packages.debian.org/sid/profnet-snapfun-dbgsym >>> >> >> Fun to see it in different arch but not amd64... Will give a try when >> possible. >> >> >>> So you can make your own debug symbols locally by rebuilding the >>> package, or someone could upload a new source package as it has been almost >>> a year. I made some cosmetic cleanups to the Debian packaging if that is a >>> good enough excuse (though snapfun still segfaults for me) >>> >>> > >>> > Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct >>> > none dbg >>> > >>> > Gdb result: >>> > >>> > Core was generated by `profnet_snapfun switch 385 55 10 46 100 >>> PROFin.dat >>> > PROFacc_tst.jct none dbg'. >>> >>> -- >>> Michael >>> >> > > -- > Michael R. Crusoe > Co-founder & Lead, Common Workflow Language project > <http://www.commonwl.org/> > https://orcid.org/-0002-2961-9670 > <https://impactstory.org/u/-0002-2961-9670> > m...@commonwl.org > +1 480 627 9108 >
Bug#905206: Seems to crash in fortran lib
Le jeu. 3 oct. 2019 à 12:08, Michael Crusoe a écrit : > On Sat, 9 Mar 2019 17:44:02 +0100 olivier sallou > wrote: > > Looking at core generated file and using gdb we see that it fails in > > fortran lib. > > > > Either program tries something wrong in a fortran updated lib version, > > either the fortran lib is itself buggy. > > > > I have no fortran knowledge to debug this however. And it lacks debug > info > > to find calling line in profnet. > > The debug symbols exists for non-amd64 archs: > https://packages.debian.org/sid/profnet-snapfun-dbgsym > Fun to see it in different arch but not amd64... Will give a try when possible. > So you can make your own debug symbols locally by rebuilding the package, > or someone could upload a new source package as it has been almost a year. > I made some cosmetic cleanups to the Debian packaging if that is a good > enough excuse (though snapfun still segfaults for me) > > > > > Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct > > none dbg > > > > Gdb result: > > > > Core was generated by `profnet_snapfun switch 385 55 10 46 100 PROFin.dat > > PROFacc_tst.jct none dbg'. > > -- > Michael >
Bug#925745: Bug#925745: [Help] libgtextutils: ftbfs with GCC-9
On 9/25/19 1:22 PM, Andreas Tille wrote:
> Hi again,
>
> On Wed, Sep 11, 2019 at 02:16:04PM +0200, Andreas Tille wrote:
>>> commenting in text_line_reader.h:
>>>
>>> // operator const std::string& () const { return
>>> line_string() ; }
>>>
>>> do the job and test pass
>>>
>>>
>>> but I would prefer a c++ friend to acknowledge this It works but I
>>> do not if there are side effects
>> Any news about this?
> Were you able to contact your c++ friend?
have non :-(
was expecting something from debian mentors which was in cc...
>
> Kind regards
>
> Andreas.
>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#923731: [Debian-med-packaging] Bug#923731: Any volunteer to fix the "usual" issues when upgrading to new version of igv?
If I try to remove "module" related stuff as debian required libs do not
seem to declare libs as modules:
dependencies {
compile fileTree(dir: 'lib', include: '*.jar')
compile "commons-io:commons-io:debian"
compile "org.apache.ant:ant:debian";
compile "org.apache.commons:commons-math:debian";
compile "com.google.code.gson:gson:debian";
compile "com.github.samtools:htsjdk:debian";
compile "log4j:log4j:1.2.x";
compile "org.apache.logging.log4j:log4j:debian";
compile "org.apache.logging.log4j:log4j-core:debian";
compile "org.apache.logging.log4j:log4j-api:debian";
compile "org.swinglabs:swing-layout:debian";
compile "com.google.guava:guava:debian";
compile "org.apache.xmlgraphics:batik-all:debian";
testCompile fileTree(dir: 'test/lib', include: '*.jar')
}
It ends with other errors:
...
All input files are considered out-of-date for incremental task
':compileJava'.
Compiling with JDK Java compiler API.
error: the unnamed module reads package org.w3c.dom.svg from both
xml.apis.ext.debian and xml.apis.debian
error: the unnamed module reads package org.w3c.dom.smil from both
xml.apis.ext.debian and xml.apis.debian
error: the unnamed module reads package org.w3c.css.sac.helpers from
both xml.apis.ext.debian and xml.apis.debian
error: the unnamed module reads package org.w3c.css.sac from both
xml.apis.ext.debian and xml.apis.debian
error: the unnamed module reads package javax.xml from both
xml.apis.debian and java.xml
error: the unnamed module reads package javax.xml.datatype from both
xml.apis.debian and java.xml
Seems related to a mix of module use and unnamed modules but don't
know how to fix that
Bug#923731: [Debian-med-packaging] Bug#923731: Any volunteer to fix the "usual" issues when upgrading to new version of igv?
On 9/13/19 3:43 PM, Andreas Tille wrote: > Hi, > > I upgraded the igv packaging Git[1] to the latest upstream version. I > never experienced a smooth upgrade to any igv version - but I always > experienced help from a Java expert here on the list. May be it is time > again to fix: I had a quick look, but no idea here. Related Java 11 module loading. Should ask debian Java team I think on hjow to handle this. Dependencies are in maven-repo, but gradle does not seem to find them as "modules" or related jar files are not seen as modules. Olivier > > > All input files are considered out-of-date for incremental task > ':compileJava'. > Compiling with JDK Java compiler API. > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:7: error: module not > found: ant > requires ant; > ^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:8: error: module not > found: com.google.common > requires com.google.common; >^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:9: error: module not > found: commons.io > requires commons.io; > ^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:10: error: module not > found: commons.math > requires commons.math; > ^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:12: error: module not > found: gson > requires gson; > ^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:13: error: module not > found: htsjdk > requires htsjdk; > ^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:22: error: module not > found: log4j > requires log4j; > ^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:23: error: module not > found: org.apache.logging.log4j > requires org.apache.logging.log4j; >^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:24: error: module not > found: org.apache.logging.log4j.core > requires org.apache.logging.log4j.core; > ^ > /build/igv-2.6.3+dfsg/src/main/java11/module-info.java:25: error: module not > found: swing.layout > requires swing.layout; > ^ > 10 errors > :compileJava FAILED > :compileJava (Thread[Task worker for ':',5,main]) completed. Took 4.782 secs. > > FAILURE: Build failed with an exception. > > > The failures are looking like missing Build-Depends at first look but these > should be OK. Any volunteer? > > Kind regards > >Andreas. > > > [1] https://salsa.debian.org/med-team/igv > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#939894: Minia is lacking symbol from gatb-core (Was: Bug#939894: minia: autopkgtest regression: X.contigs.fa: No such file or directory)
On 9/12/19 10:11 AM, Andreas Tille wrote: > On Mon, Sep 09, 2019 at 09:59:09PM +0200, Paul Gevers wrote: >> Run simple_test.sh >> Traceback (most recent call last): >> File "compare_fasta.py", line 21, in >> s2 = read_seqs(fasta2) >> File "compare_fasta.py", line 15, in read_seqs >> for line in open(fasta): >> IOError: [Errno 2] No such file or directory: 'X.contigs.fa' > The actual problem is: > >$ /usr/bin/minia > /usr/bin/minia: symbol lookup error: /usr/bin/minia: undefined symbol: > _ZN4gatb4core8debruijn4impl9link_tigsILm128EEEvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiRmb > > I suspect minia needs a different / newer version of libgatbcore2. > > @Olivier: You once said you have contact to gatb-core upstream and their > downstream projects. Would you be able to teach them about a sensible > release strategy with some API the depending projects could rely on? As > far as I can see the depending projects rely on Git submodules with a > specific commit which is not really helpful. unfortunatly, there is nobody left in my lab related to this software... :-( > > Kind regards > > Andreas. > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#939832: chado-utils: installation error
Package: chado-utils Version: 1.31-5 Severity: important Dear Maintainer, installation fails with error at postinstall step dpkg: error processing package libchado-perl (--configure): installed libchado-perl package post-installation script subprocess returned error exit status 2 dpkg: dependency problems prevent configuration of chado-utils: chado-utils depends on libchado-perl; however: Package libchado-perl is not configured yet. Same issue on buster-backports -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.11-100.fc29.x86_64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages chado-utils depends on: ih libchado-perl 1.31-5 ii perl 5.28.1-6 Versions of packages chado-utils recommends: ii xsltproc 1.1.32-2.1 chado-utils suggests no packages.
Bug#920545: python-intervaltree breaks python-intervaltree-bio autopkgtest
Le mer. 21 août 2019 à 15:21, Andreas Tille a écrit : > Control: tags -1 help > > Hi, > > I removed Python2 support from this package in Git[1]. Unfortunately the > autopkgtest failure is for Python3. Graham, I understood your > mail that you've found a solution - but I do not understand what > this might be. > > Any hint / patch / team upload that would fix the package (preferably) > based on the latest status in Git[1] would be really welcome. > I took latest from git and tried python3 autopkgtest and everything worked fine on my side. autopkgtest -B python3-intervaltree-bio_1.0.1-5_all.deb python-intervaltree-bio_1.0.1-5.dsc -- null => autopkgtest [13:30:21]: version 5.10 autopkgtest [13:30:21]: host beeaeaffa84e; command line: /usr/bin/autopkgtest -B python3-intervaltree-bio_1.0.1-5_all.deb python-intervaltree-bio_1.0.1-5.dsc -- null autopkgtest [13:30:21]: testbed dpkg architecture: amd64 autopkgtest [13:30:21]: testbed running kernel: Linux 5.2.7-100.fc29.x86_64 #1 SMP Thu Aug 8 05:30:19 UTC 2019 autopkgtest [13:30:25]: test command1: python3 -m pytest --ignore=.pc --verbose --datadir debian/data autopkgtest [13:30:25]: test command1: [--- ... 4 passed, 2 warnings in 44.85 seconds = Olivier > > Kind regards > > Andreas. > > [1] https://salsa.debian.org/med-team/python-intervaltree-bio > > -- > http://fam-tille.de >
Bug#935287: uglu patch proposal
Here is a patch proposal that fix the build issue. However, I feel this
patch quite ugly with many tricks to support build.
I disable all sphinx related doc generation (due to some auto
setup/install). The setup script is too complex.
I also disable the clean step, as setup script do some stuff not
supported and clean step is ran before patches
So feel free to use this patch, but I do not really like it :-(
From 4b07d43ce328690fac4965aafc4d3252c72b95ec Mon Sep 17 00:00:00 2001
From: Olivier Sallou
Date: Wed, 21 Aug 2019 12:03:31 +
Subject: [PATCH] remove sphinx related doc
---
debian/obitools.install| 2 +-
debian/obitools.manpages | 2 +-
debian/patches/use_debian_libs | 118 -
debian/rules | 7 +-
4 files changed, 122 insertions(+), 7 deletions(-)
diff --git a/debian/obitools.install b/debian/obitools.install
index 167aea6..b5ac709 100644
--- a/debian/obitools.install
+++ b/debian/obitools.install
@@ -1 +1 @@
-build/sphinx/html usr/share/doc/obitools
+#build/sphinx/html usr/share/doc/obitools
diff --git a/debian/obitools.manpages b/debian/obitools.manpages
index 90766e9..6516bb4 100644
--- a/debian/obitools.manpages
+++ b/debian/obitools.manpages
@@ -1 +1 @@
-build/sphinx/man/*.1
+#build/sphinx/man/*.1
diff --git a/debian/patches/use_debian_libs b/debian/patches/use_debian_libs
index 2010e15..5d6d75e 100644
--- a/debian/patches/use_debian_libs
+++ b/debian/patches/use_debian_libs
@@ -7,7 +7,7 @@ Last-Updated: 2015-04-30
Forwarded: no
--- a/distutils.ext/obidistutils/serenity/__init__.py
+++ b/distutils.ext/obidistutils/serenity/__init__.py
-@@ -63,7 +63,7 @@ def serenity_snake(envname,package,versi
+@@ -63,7 +63,7 @@
log.info("%s will be installed with python : %s" % (package,virtualpython))
@@ -18,7 +18,7 @@ Forwarded: no
--- a/distutils.ext/obidistutils/serenity/checkpackage.py
+++ b/distutils.ext/obidistutils/serenity/checkpackage.py
-@@ -15,48 +15,7 @@ from distutils import log
+@@ -15,48 +15,7 @@
from obidistutils.serenity.checkpip import get_a_pip_module
def is_installed(requirement,pip=None):
@@ -68,9 +68,83 @@ Forwarded: no
def get_requirements(pip=None):
+@@ -77,52 +36,13 @@
+
+ def install_requirements(skip_virtualenv=True,pip=None):
+
+-if pip is None:
+-pip = get_a_pip_module()
+-
+ install_something=False
+-try:
+-requirements = open('requirements.txt').readlines()
+-requirements = [x.strip() for x in requirements]
+-requirements = [x for x in requirements if x[0]!='-']
+-
+-log.info("Required packages for the installation :")
+-for x in requirements:
+-if not skip_virtualenv or x[0:10]!='virtualenv':
+-ok = is_installed(x,pip)
+-if not ok:
+-log.info(" Installing requirement : %s" % x)
+-pip_install_package(x,pip=pip)
+-install_something=True
+-
+-except IOError:
+-pass
+
+ return install_something
+
+
+ def check_requirements(skip_virtualenv=True,pip=None):
+-
+-if pip is None:
+-pip = get_a_pip_module()
+-
+-
+-try:
+-requirements = open('requirements.txt').readlines()
+-requirements = [x.strip() for x in requirements]
+-requirements = [x for x in requirements if x[0]!='-']
+-
+-log.info("Required packages for the installation :")
+-for x in requirements:
+-if not skip_virtualenv or x[0:10]!='virtualenv':
+-ok = is_installed(x,pip)
+-if not ok:
+-log.error(" Missing requirement : %s -- Package installation stopped" % x)
+-sys.exit(0)
+-
+-except IOError:
+-pass
+-
++pass
+
+
+ def parse_package_requirement(requirement):
+@@ -146,18 +66,7 @@
+
+
+ def get_package_requirement(package,pip=None):
+-if pip is None:
+-pip = get_a_pip_module()
+-
+-requirements = get_requirements(pip)
+-req = [x for x in requirements
+- if x[0:len(package)]==package
+- ]
+-
+-if len(req)==1:
+-return req[0]
+-else:
+-return None
++return None
+
+
+ def pip_install_package(package,directory=None,pip=None):
--- a/setup.py
+++ b/setup.py
-@@ -66,5 +66,5 @@ if __name__=="__main__":
+@@ -66,5 +66,5 @@
license=LICENSE,
url=URL,
python_src=SRC,
@@ -78,3 +152,41 @@ Forwarded: no
- serenity=serenity)
+ sse='sse2')
+ #serenity=serenity)
+--- a/distutils.ext/obidistutils/core.py
b/distutils.ext/obidistutils/core.py
+@@ -24,13 +24,11 @@
+ from obidistutils.command.build import build
+ from obidistutils.command.littlebigma
Bug#935287: [Debian-med-packaging] Bug#935287: obitools: FTBFS on amd64
Oneof the issue here is clean is called at the begin of the package build, before applying patches This result in failure due to the particular setup script used here that tries to install requirements etc One solution is to override clean and do nothing, but this will result in last build step with a no cleanup Olivier On 8/21/19 1:07 PM, Ivo De Decker wrote: > package: src:obitools > version: 1.2.13+dfsg-1 > severity: serious > tags: ftbfs > > Hi, > > A binnmu of obitools in unstable fails on amd64: > > https://buildd.debian.org/status/package.php?p=obitools > > Cheers, > > Ivo > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#925745: [Debian-med-packaging] Bug#925745: [Help] libgtextutils: ftbfs with GCC-9
On 8/20/19 3:41 PM, Andreas Tille wrote:
> Hi Olivier,
>
> I'm just forwarding this to Debian Mentors list to get a wider audience.
> I'd prefer a fix over simply removing the test ...
commenting in text_line_reader.h:
// operator const std::string& () const { return
line_string() ; }
do the job and test pass
but I would prefer a c++ friend to acknowledge this It works but I
do not if there are side effects
Olivier
>
> Thanks for your analysis anyway
>
> Andreas.
>
> On Tue, Aug 20, 2019 at 03:36:48PM +0200, Olivier Sallou wrote:
>> On 8/20/19 1:24 PM, Andreas Tille wrote:
>>> Control: tags -1 help
>>>
>>> Hi,
>>>
>>> any hint how to deal with
>>
>> this is a test file. In test, there is explicit conversion to string:
>>
>> line = reader.line_string() ; //first line - with explicit method to get
>> the string
>>
>> which works fine as expected
>>
>> In gcc 9 bug, it is implicit conversion that fails. Seems due some c++
>> 11 updates on operators, but I am not an expert on this kind of stuff.
>>
>> As this is only a test, and there is a way to get the result as a string
>> (as first test above test with explicit method), I wonder if we could
>> not simply patch to remove those lines:
>>
>>
>> line = reader ; //second line - with implicit conversion to
>> std::string
>> ASSERT( line == "second line" ) ;
>>
>> Further test may also complain (using implicit too):
>>
>> istream ( reader ) ; // fourth line - with implicit
>> conversion to std::istream
>>
>>
>> However, as it is a library, implicit conversion may fail on other tools
>> linking with this lib Best of course would be to get a fix for this
>> assignement operator
>>
>> Olivier
>>
>>>
>>> ...
>>> g++ -DHAVE_CONFIG_H -I. -I.. -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g
>>> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
>>> -Werror=format-security -Wall -Wextra -Wformat-nonliteral -Wformat-security
>>> -Wswitch-default -Wswitch-enum -Wunused-parameter -Wfloat-equal -Werror
>>> -DDEBUG -g -O1 -DDEBUG -g -O1 -c -o test_text_reader.o test_text_reader.cpp
>>> test_text_reader.cpp: In function 'int main()':
>>> test_text_reader.cpp:48:9: error: ambiguous overload for 'operator='
>>> (operand types are 'std::string' {aka 'std::__cxx11::basic_string'}
>>> and 'TextLineReader')
>>>48 | line = reader ; //second line - with implicit conversion to
>>> std::string
>>> | ^~
>>> In file included from /usr/include/c++/9/string:55,
>>> from /usr/include/c++/9/bits/locale_classes.h:40,
>>> from /usr/include/c++/9/bits/ios_base.h:41,
>>> from /usr/include/c++/9/ios:42,
>>> from /usr/include/c++/9/ostream:38,
>>> from /usr/include/c++/9/iostream:39,
>>> from test_text_reader.cpp:19:
>>> /usr/include/c++/9/bits/basic_string.h:665:7: note: candidate:
>>> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
>>> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
>>> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
>>> _Traits = std::char_traits; _Alloc = std::allocator]'
>>> 665 | operator=(const basic_string& __str)
>>> | ^~~~
>>> /usr/include/c++/9/bits/basic_string.h:732:7: note: candidate:
>>> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
>>> std::__cxx11::basic_string<_CharT, _Traits,
>>> _Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&)
>>> [with _CharT = char; _Traits = std::char_traits; _Alloc =
>>> std::allocator]'
>>> 732 | operator=(basic_string&& __str)
>>> | ^~~~
>>> make[3]: *** [Makefile:781: test_text_reader.o] Error 1
>>>
>>>
>>> Kind regards
>>>
>>> Andreas.
>>>
>>>
>> --
>> Olivier Sallou
>> Univ Rennes, Inria, CNRS, IRISA
>> Irisa, Campus de Beaulieu
>> F-35042 RENNES - FRANCE
>> Tel: 02.99.84.71.95
>>
>> gpg key id: 4096R/326D8438 (keyring.debian.org)
>> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
>>
>>
>>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#925745: [Debian-med-packaging] Bug#925745: [Help] libgtextutils: ftbfs with GCC-9
On 8/20/19 1:24 PM, Andreas Tille wrote:
> Control: tags -1 help
>
> Hi,
>
> any hint how to deal with
this is a test file. In test, there is explicit conversion to string:
line = reader.line_string() ; //first line - with explicit method to get
the string
which works fine as expected
In gcc 9 bug, it is implicit conversion that fails. Seems due some c++
11 updates on operators, but I am not an expert on this kind of stuff.
As this is only a test, and there is a way to get the result as a string
(as first test above test with explicit method), I wonder if we could
not simply patch to remove those lines:
line = reader ; //second line - with implicit conversion to
std::string
ASSERT( line == "second line" ) ;
Further test may also complain (using implicit too):
istream ( reader ) ; // fourth line - with implicit
conversion to std::istream
However, as it is a library, implicit conversion may fail on other tools
linking with this lib Best of course would be to get a fix for this
assignement operator
Olivier
>
>
> ...
> g++ -DHAVE_CONFIG_H -I. -I.. -I../src -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -Wextra -Wformat-nonliteral -Wformat-security
> -Wswitch-default -Wswitch-enum -Wunused-parameter -Wfloat-equal -Werror
> -DDEBUG -g -O1 -DDEBUG -g -O1 -c -o test_text_reader.o test_text_reader.cpp
> test_text_reader.cpp: In function 'int main()':
> test_text_reader.cpp:48:9: error: ambiguous overload for 'operator=' (operand
> types are 'std::string' {aka 'std::__cxx11::basic_string'} and
> 'TextLineReader')
>48 | line = reader ; //second line - with implicit conversion to
> std::string
> | ^~
> In file included from /usr/include/c++/9/string:55,
> from /usr/include/c++/9/bits/locale_classes.h:40,
> from /usr/include/c++/9/bits/ios_base.h:41,
> from /usr/include/c++/9/ios:42,
> from /usr/include/c++/9/ostream:38,
> from /usr/include/c++/9/iostream:39,
> from test_text_reader.cpp:19:
> /usr/include/c++/9/bits/basic_string.h:665:7: note: candidate:
> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
> _Traits = std::char_traits; _Alloc = std::allocator]'
> 665 | operator=(const basic_string& __str)
> | ^~~~
> /usr/include/c++/9/bits/basic_string.h:732:7: note: candidate:
> 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
> std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&)
> [with _CharT = char; _Traits = std::char_traits; _Alloc =
> std::allocator]'
> 732 | operator=(basic_string&& __str)
> | ^~~~
> make[3]: *** [Makefile:781: test_text_reader.o] Error 1
>
>
> Kind regards
>
> Andreas.
>
>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#933390: ITP: python-ftputil -- high level library for python ftp
Package: wnpp Severity: wishlist Owner: Olivier Sallou X-Debbugs-Cc: debian-de...@lists.debian.org, python-modules-t...@lists.alioth.debian.org * Package name: python-ftputil Version : 3.4 Upstream Author : Stefan Schwarzer * URL : https://ftputil.sschwarzer.net/trac * License : BSD Programming Lang: Python Description : high level library for python ftp ftputil is a high-level FTP client library for the Python programming language. ftputil implements a virtual file system for accessing FTP servers, that is, it can generate file-like objects for remote files. The library supports many functions similar to those in the os, os.path and shutil modules. ftputil has convenience functions for conditional uploads and downloads, and handles FTP clients and servers in different timezones. Needed by next release of biomaj package. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#925902: unblock: cnvkit/0.9.5-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: debian-...@lists.debian.org
This upload fixes bug #925568 about build reproducibility (failing). It
simply add a small patch to fix the issue adds a metadata entry.
Waiting for a *go* to upload package to unstable.
Thanks
Olivier
debdiff result =>
debian@ccf6b68dd723:/opt/debian/build-area$ debdiff cnvkit_0.9.5-2.dsc
cnvkit_0.9.5-3.dsc
dpkg-source: warning: extracting unsigned source package
(/opt/debian/build-area/cnvkit_0.9.5-3.dsc)
diff -Nru cnvkit-0.9.5/debian/changelog cnvkit-0.9.5/debian/changelog
--- cnvkit-0.9.5/debian/changelog 2019-01-06 12:12:46.0 +
+++ cnvkit-0.9.5/debian/changelog 2019-03-27 08:00:39.0 +
@@ -1,3 +1,10 @@
+cnvkit (0.9.5-3) unstable; urgency=medium
+
+ * Fix buster rebuilds (Closes: #925568)
+d/patches/controldir.patch
+
+ -- Olivier Sallou Wed, 27 Mar 2019 08:00:39 +
+
cnvkit (0.9.5-2) unstable; urgency=medium
[ Jelmer Vernooij ]
diff -Nru cnvkit-0.9.5/debian/patches/controldir
cnvkit-0.9.5/debian/patches/controldir
--- cnvkit-0.9.5/debian/patches/controldir 1970-01-01 00:00:00.0
+
+++ cnvkit-0.9.5/debian/patches/controldir 2019-03-27 08:00:39.0
+
@@ -0,0 +1,21 @@
+Subject: do not create dir if it exists
+Description: command tries to create an output dir during tests, even if it
+ already exists, raising an error. Skip creation if already present
+Author: Olivier Sallou
+Bug: 925568
+Forwaded: no
+Last-Updated: 2019-03-27
+--- a/cnvlib/commands.py
b/cnvlib/commands.py
+@@ -1365,8 +1365,9 @@
+ 'anti' if 'antitarget' in fname else ''))
+ if args.output_dir:
+ if not os.path.isdir(args.output_dir):
+-os.mkdir(args.output_dir)
+-logging.info("Created directory %s", args.output_dir)
++if not os.path.exists(args.output_dir):
++os.mkdir(args.output_dir)
++logging.info("Created directory %s", args.output_dir)
+ outfname = os.path.join(args.output_dir, outfname)
+ tabio.write(garr, outfname)
+
diff -Nru cnvkit-0.9.5/debian/patches/series
cnvkit-0.9.5/debian/patches/series
--- cnvkit-0.9.5/debian/patches/series 2019-01-06 09:41:24.0 +
+++ cnvkit-0.9.5/debian/patches/series 2019-03-27 08:00:39.0 +
@@ -1,3 +1,4 @@
no-py-ext
python3compat.patch
spelling
+controldir
diff -Nru cnvkit-0.9.5/debian/upstream/metadata
cnvkit-0.9.5/debian/upstream/metadata
--- cnvkit-0.9.5/debian/upstream/metadata 2018-06-19 21:48:37.0
+
+++ cnvkit-0.9.5/debian/upstream/metadata 2019-03-27 08:00:39.0
+
@@ -19,6 +19,6 @@
- Name: OMICtools
Entry: OMICS_11538
- Name: bio.tools
- Entry: NA
- - Name: bio.tools
+ Entry: cnvkit
+ - Name: SciCrunch
Entry: NA
--
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#925568: [Debian-med-packaging] Bug#925568: cnvkit: FTBFS: FileExistsError: [Errno 17] File exists: 'build/'
On 3/26/19 9:46 PM, Lucas Nussbaum wrote: > Source: cnvkit > Version: 0.9.5-2 > Severity: serious > Tags: buster sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20190325 qa-ftbfs > Justification: FTBFS in buster on amd64 > > Hi, > > During a rebuild of all packages in buster (in a buster chroot, not a > sid chroot), your package failed to build on amd64. I just did a try on buster. It succeeded first time, not on a second rebuild (with same error). I fixed and tested on buster with new patch d/patches/controldir. Git is up-to-date and in UNRELEASED state. As we are in freeze, should we ask release team to unblock transition and then push to unstable? Though not a bug issue, bug could be forwarded upstream as it raises an error to use an existing dir. Olivier > > Relevant part (hopefully): >> make[2]: Entering directory '/<>/test' >> python3 ../cnvkit.py import-picard picard/p2-5_5.targetcoverage.csv >> picard/p2-5_5.antitargetcoverage.csv picard/p2-9_5.targetcoverage.csv >> picard/p2-9_5.antitargetcoverage.csv picard/p2-20_5.targetcoverage.csv >> picard/p2-20_5.antitargetcoverage.csv -d build/ >> python3 ../cnvkit.py import-picard picard/p2-5_5.targetcoverage.csv -d build/ >> python3 ../cnvkit.py import-picard picard/p2-5_5.antitargetcoverage.csv -d >> build/ >> python3 ../cnvkit.py import-picard picard/p2-9_2.targetcoverage.csv -d build/ >> WARNING: Ambiguous gene name 'TERT|TERT Promoter'; using 'TERT Promoter' >> WARNING: Ambiguous gene name 'TERT|TERT Promoter'; using 'TERT Promoter' >> WARNING: Ambiguous gene name 'TERT|TERT Promoter'; using 'TERT Promoter' >> Created directory build/ >> Traceback (most recent call last): >> File "../cnvkit.py", line 13, in >> args.func(args) >> File "/<>/cnvlib/commands.py", line 1368, in >> _cmd_import_picard >> os.mkdir(args.output_dir) >> FileExistsError: [Errno 17] File exists: 'build/' >> Wrote build/p2-5_5.targetcoverage.cnn with 6646 regions >> Wrote build/p2-9_2.targetcoverage.cnn with 6646 regions >> make[2]: *** [Makefile:58: build/p2-5_5.targetcoverage.cnn] Error 1 > The full build log is available from: >http://qa-logs.debian.net/2019/03/25/cnvkit_0.9.5-2_testing.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#923637: [Debian-med-packaging] Bug#923637: 923637 is pending
- Mail original - > De: "Andrius Merkys" > À: 923...@bugs.debian.org > Envoyé: Samedi 9 Mars 2019 16:50:28 > Objet: [Debian-med-packaging] Bug#923637: 923637 is pending > control: tags -1 + pending > > Hello, > > the patch is applied in the VCS and the fixed version of the package is > ready to be uploaded. Could someone with upload permissions do it? I do Olivier > > Best, > Andrius > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#923637: [Debian-med-packaging] Bug#923637: 923637 is pending
there is a remaining warning: W: libffindex0: package-name-doesnt-match-sonames libffindex2.0.2 so this not a big issue by itself, but why packgae is named libffindex0 while lib version is 2.x ? Olivier
Bug#905206: Seems to crash in fortran lib
Looking at core generated file and using gdb we see that it fails in fortran lib. Either program tries something wrong in a fortran updated lib version, either the fortran lib is itself buggy. I have no fortran knowledge to debug this however. And it lacks debug info to find calling line in profnet. Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct none dbg Gdb result: Core was generated by `profnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct none dbg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fcc9b08e2fa in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5 (gdb) where #0 0x7fcc9b08e2fa in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5 #1 0x7fcc9b08f49d in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5 #2 0x7fcc9b092611 in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5 #3 0x7fcc9b093bad in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5 #4 0x7fcc9b090d49 in _gfortran_transfer_array () from /lib/x86_64-linux-gnu/libgfortran.so.5 #5 0x55ccaf6513fe in ?? () #6 0x55ccaf652c65 in ?? () #7 0x55ccaf65ba8e in ?? () #8 0x55ccaf64a25f in ?? () --Type for more, q to quit, c to continue without paging-- #9 0x7fcc9ab0009b in __libc_start_main (main=0x55ccaf64a240, argc=11, argv=0x7fff2520e418, init=, fini=, rtld_fini=, stack_end=0x7fff2520e408) at ../csu/libc-start.c:308 #10 0x55ccaf64a29a in ?? ()
Bug#920545: Fixed in git repo
Hi, I have pushed a fix to get autopkgtests done in python-intervaltree-bio I have not uploaded package, as we are in freeze transition, so patch is in git only Commit: 4f67ea8b607fa47520b553ce8776a37cf62a1713 Link: https://salsa.debian.org/med-team/python-intervaltree-bio/commit/4f67ea8b607fa47520b553ce8776a37cf62a1713 I ran locally autopkgtest with this patch and everything was fine autopkgtest -B python-intervaltree-bio_1.0.1-4_all.deb python-intervaltree-bio_1.0.1-4.dsc -- null Olivier
Bug#924086: ITP: python-irodsclient -- python3 API module for iRODS
Package: wnpp Severity: wishlist Owner: Olivier Sallou X-CC: python-modules-t...@lists.alioth.debian.org * Package name: python-irodsclient Version : 0.8.1 Upstream Author : The University of North Carolina at Chapel Hill * URL : https://github.com/irods/python-irodsclient * License : BSD-3 Programming Lang: Python Description : python3 API module for iRODS iRODS is an open source distributed data management system. This is a client API implemented in Python.
Bug#923756: [Debian-med-packaging] Bug#923756: libhac-java: FTBFS in buster/sid
- Andreas Tille a écrit : > Hi Debian Java team, > > On Tue, Mar 05, 2019 at 12:19:40AM +, Santiago Vila wrote: > > jh_build -J hac.jar src > > find src -name *.java -and -type f -print0 | xargs -s 512000 -0 > > /usr/lib/jvm/default-java/bin/javac -g -cp :debian/_jh_build.hac -d > > debian/_jh_build.hac -source 1.7 -target 1.7 -encoding ISO8859-1 > > warning: [options] bootstrap class path not set in conjunction with -source > > 7 > > 1 warning > > find src -name *.java -and -type f -print0 | xargs -s 512000 -0 > > /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link > > /usr/share/doc/default-jdk-doc/api -link > > /usr/share/doc/default-jre-headless/api -classpath :debian/_jh_build.hac -d > > debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp > > -source 1.7 > > Creating destination directory: "debian/_jh_build.javadoc/api/" > > javadoc: error - The code being documented uses packages in the unnamed > > module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are > > in named modules. > > javadoc: error - The code being documented uses packages in the unnamed > > module, but the packages defined in > > /usr/share/doc/default-jre-headless/api/ are in named modules. > > 2 errors > > make[1]: *** [debian/rules:9: override_dh_auto_build] Error 123 > > Any idea how to fix this? Short term workaround would be to disable javadoc generation and related package Found many related bugs but no quick resolution and patching code may be a long task Olivier > > Kind regards > > Andreas. > > -- > http://fam-tille.de > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#923731: [Debian-med-packaging] Bug#923731: igv depends on packages which were removed in picard-tools
- Mail original - > De: "Matthias Klose" > À: "submit" > Envoyé: Lundi 4 Mars 2019 17:40:08 > Objet: [Debian-med-packaging] Bug#923731: igv depends on packages which were > removed in picard-tools > Package: src:igv,src:picard-tools > Severity: serious > Tags: sid buster > > Another round of debian-med QA ;p > > igv depends on packages which were removed in picard-tools. The binaries > built > from picard-tools were made arch:amd64 instead of arch:all, this was set on purpose after a bug request (#921185), as picard-tools depends on other packages only available on amd64. igv could indeed also be set on supported arch only. however I do not feel really cool at specifying some specific arch destinations because of dependencies limitations. If dependency changes to support more archs, it will not be reflected on packages. As long as package itself has no specific requirement, I would prefer to keep it built for all archs, even if it fails due to dependency. Olivier now the igv binaries > probably should be removed on all other architectures, however I cannot find a > ftp removal bug either. > > Migrates after: jhdf > 32 days old (10 needed) > igv/arm64 unsatisfiable Depends: libpicard-java > igv/armel unsatisfiable Depends: libpicard-java > igv/armhf unsatisfiable Depends: libpicard-java > igv/i386 unsatisfiable Depends: libpicard-java > igv/mips unsatisfiable Depends: libpicard-java > igv/mips64el unsatisfiable Depends: libpicard-java > igv/mipsel unsatisfiable Depends: libpicard-java > igv/ppc64el unsatisfiable Depends: libpicard-java > igv/s390x unsatisfiable Depends: libpicard-java > Cannot be tested by piuparts (not a blocker) - (no link yet) > Checking build-dependency on amd64 > Not touching package due to block request by freeze (please contact > debian-release if update is needed) > Not considered > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#919559: picard-tools: autopkgtest regression
- Andreas Tille a écrit : > On Thu, Jan 17, 2019 at 06:49:14PM +0100, Olivier Sallou wrote: > > > > > > I tested against a local build of the package though local build (which > > runs tests) works fine. (both are run on the same machine)! > > > > autopkgtest does not keep the tempory directory used, so I cannot look > > at test report (testng) to find failing tests. > > Why not uncommenting line > > trap "rm -rf $ADTTMP" 0 INT QUIT ABRT PIPE TERM I had not seen this, thanks, will try! > > and may be also add > > set -x > > for debugging? > > Kind regards > > Andreas. > > -- > http://fam-tille.de >
Bug#919559: picard-tools: autopkgtest regression
On 1/17/19 1:24 PM, Paul Gevers wrote: > Hi Olivier, > > On 17-01-2019 12:12, Olivier Sallou wrote: >> I tested in buster with updated libbarclay-java (2.1.0-3 pushed today to >> allow migration to testing) and could rebuild picard-tools from source >> (with tests) with no issue. >> >> >> I tried again with libbarclay-java 2.1.0-2 and faced no issue either. > The autopkgtest also fails in unstable. If you are only testing builds, > and not actually running autopkgtest, than it may be that you have a > build dependency that you miss during the tests, because you didn't add > it to the test dependencies. I fixed picard-tools (git only) to fix the classpath in jar manifest and bin PicardCommandLine. running autopkgtest with test removes the ClassNotFound error, however it results in failure of 2 tests. I tested against a local build of the package though local build (which runs tests) works fine. (both are run on the same machine)! autopkgtest does not keep the tempory directory used, so I cannot look at test report (testng) to find failing tests. The autopkgtest report is too verbose and I cannot find failing tests in this log file. I don't understand why some tests fail with autopkgtest and not with gbp buildpackage on the same server. > > Paul > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: OpenPGP digital signature
Bug#919559: picard-tools: autopkgtest regression
On 1/17/19 1:24 PM, Paul Gevers wrote: > Hi Olivier, > > On 17-01-2019 12:12, Olivier Sallou wrote: >> I tested in buster with updated libbarclay-java (2.1.0-3 pushed today to >> allow migration to testing) and could rebuild picard-tools from source >> (with tests) with no issue. >> >> >> I tried again with libbarclay-java 2.1.0-2 and faced no issue either. > The autopkgtest also fails in unstable. If you are only testing builds, > and not actually running autopkgtest, than it may be that you have a > build dependency that you miss during the tests, because you didn't add > it to the test dependencies. ok, I think I found the issue. the manifest of jar file does not include defined classpath. As a result, called binary in scripts does not find the dependencies at runtime. At build/test time, classpath is correctly defined. I gonna have a look. > > Paul > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: OpenPGP digital signature
Bug#919559: picard-tools: autopkgtest regression
On 1/17/19 10:07 AM, Paul Gevers wrote: > Hi Olivier, > > On 17-01-2019 09:38, Olivier Sallou wrote: >> On 1/17/19 9:25 AM, Paul Gevers wrote: >>> autopkgtest [04:38:35]: test run-unit-test: [--- >>> Error: Unable to initialize main class picard.cmdline.PicardCommandLine >>> Caused by: java.lang.NoClassDefFoundError: >>> org/broadinstitute/barclay/argparser/CommandLineProgramProperties >>> autopkgtest [04:38:36]: test run-unit-test: ---] >> picard-tools depends on libbarclay-java. I see that it is has been >> removed from testing, this is why it fails. I wonder however >> >> Previous picard-tools in testing did not depend on this library. >> Migration of picard-tools is currently blocked by this libbarclay-java >> bug (#906973) > libbarclay-java is installed in the test, so that can't explain the failure: > Setting up libbarclay-java (2.1.0-2) ... I tested in buster with updated libbarclay-java (2.1.0-3 pushed today to allow migration to testing) and could rebuild picard-tools from source (with tests) with no issue. I tried again with libbarclay-java 2.1.0-2 and faced no issue either. Olivier > > Paul > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: OpenPGP digital signature
Bug#919559: picard-tools: autopkgtest regression
On 1/17/19 9:25 AM, Paul Gevers wrote: > Source: picard-tools > Version: 2.18.23+dfsg-1 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainers, > > With a recent upload of picard-tools the autopkgtest of picard-tools > fails in testing when that autopkgtest is run with the binary packages > of picard-tools from unstable. It passes when run with only packages > from testing. In tabular form: >passfail > picard-tools from testing2.18.23+dfsg-1 > versioned deps [0] from testingfrom unstable > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? If needed, please > change the bug's severity. > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [0] You can see what packages were added from the second line of the log > file quoted below. The migration software adds source package from > unstable to the list if they are needed to install packages from > picard-tools/2.18.23+dfsg-1. I.e. due to versioned dependencies or > breaks/conflicts. > [1] https://qa.debian.org/excuses.php?package=picard-tools > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/picard-tools/1717365/log.gz > > autopkgtest [04:38:35]: test run-unit-test: [--- > Error: Unable to initialize main class picard.cmdline.PicardCommandLine > Caused by: java.lang.NoClassDefFoundError: > org/broadinstitute/barclay/argparser/CommandLineProgramProperties > autopkgtest [04:38:36]: test run-unit-test: ---] Hi, picard-tools depends on libbarclay-java. I see that it is has been removed from testing, this is why it fails. I wonder however Previous picard-tools in testing did not depend on this library. Migration of picard-tools is currently blocked by this libbarclay-java bug (#906973) Olivier > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: OpenPGP digital signature
Bug#916942: additional info
I tried to recompile from scratch on Debian this release, and I face the same issue with provided example. So issue seems related to this dev version itself, not package related. I opened a discussion on swi-prolog google group to try to find the issue [0] [0] https://groups.google.com/forum/#!topic/swi-prolog/PJTBwNMGmo8 Le ven. 21 déc. 2018 à 07:53, olivier sallou a écrit : > By the way, > I see that version 7.7 is the development version. > Stable version is still the 7.6 version. > > See http://www.swi-prolog.org/ChangeLog?branch=development and > http://www.swi-prolog.org/ChangeLog?branch=stable > > Should development version really be packaged ? > > Le ven. 21 déc. 2018 à 07:41, olivier sallou a > écrit : > >> I could reproduce with simple code example from swi-prolog >> >> Running following on attached example raise the error: >> >> swipl-ld -o test.exe test.c test.pl >> ./test.exe pi/2 >> >> Running the same on an Ubuntu with swi-prolog 7.6.4 works. >> >> >> Le jeu. 20 déc. 2018 à 19:26, olivier sallou >> a écrit : >> >>> Executing cmd directly seems to work: >>> >>> swipl >>> Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.25) >>> SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software. >>> Please run ?- license. for legal details. >>> >>> For online help and background, visit http://www.swi-prolog.org >>> For built-in help, use ?- help(Topic). or ?- apropos(Word). >>> >>> ?- use_foreign_library(foreign(process)). >>> true. >>> >>> >>> Logol program is compiled with swipl-ld , so problem seems to occur with >>> compiled version only. >>> Older compilations/tests (with older swipl version?) used to work. >>> >>> -- >>> >>> gpg key id: 4096R/326D8438 (keyring.debian.org) >>> >>> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 >>> >>> >> >> -- >> >> gpg key id: 4096R/326D8438 (keyring.debian.org) >> >> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 >> >> > > -- > > gpg key id: 4096R/326D8438 (keyring.debian.org) > > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 > > -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#916942: additional info
By the way, I see that version 7.7 is the development version. Stable version is still the 7.6 version. See http://www.swi-prolog.org/ChangeLog?branch=development and http://www.swi-prolog.org/ChangeLog?branch=stable Should development version really be packaged ? Le ven. 21 déc. 2018 à 07:41, olivier sallou a écrit : > I could reproduce with simple code example from swi-prolog > > Running following on attached example raise the error: > > swipl-ld -o test.exe test.c test.pl > ./test.exe pi/2 > > Running the same on an Ubuntu with swi-prolog 7.6.4 works. > > > Le jeu. 20 déc. 2018 à 19:26, olivier sallou a > écrit : > >> Executing cmd directly seems to work: >> >> swipl >> Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.25) >> SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software. >> Please run ?- license. for legal details. >> >> For online help and background, visit http://www.swi-prolog.org >> For built-in help, use ?- help(Topic). or ?- apropos(Word). >> >> ?- use_foreign_library(foreign(process)). >> true. >> >> >> Logol program is compiled with swipl-ld , so problem seems to occur with >> compiled version only. >> Older compilations/tests (with older swipl version?) used to work. >> >> -- >> >> gpg key id: 4096R/326D8438 (keyring.debian.org) >> >> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 >> >> > > -- > > gpg key id: 4096R/326D8438 (keyring.debian.org) > > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 > > -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#916942: additional info
I could reproduce with simple code example from swi-prolog
Running following on attached example raise the error:
swipl-ld -o test.exe test.c test.pl
./test.exe pi/2
Running the same on an Ubuntu with swi-prolog 7.6.4 works.
Le jeu. 20 déc. 2018 à 19:26, olivier sallou a
écrit :
> Executing cmd directly seems to work:
>
> swipl
> Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.25)
> SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
> Please run ?- license. for legal details.
>
> For online help and background, visit http://www.swi-prolog.org
> For built-in help, use ?- help(Topic). or ?- apropos(Word).
>
> ?- use_foreign_library(foreign(process)).
> true.
>
>
> Logol program is compiled with swipl-ld , so problem seems to occur with
> compiled version only.
> Older compilations/tests (with older swipl version?) used to work.
>
> --
>
> gpg key id: 4096R/326D8438 (keyring.debian.org)
>
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
>
>
--
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
test.pl
Description: Perl program
#include
#include
#define MAXLINE 1024
int
main(int argc, char **argv)
{ char expression[MAXLINE];
char *e = expression;
char *program = argv[0];
char *plav[2];
int n;
/* combine all the arguments in a single string */
for(n=1; n
Bug#916953: logol FTBFS with swi-prolog 7.7.25+dfsg-2
Hi, I am aware of the issue. I discovered issue yesterday while trying to update package with latest version. I was about to add info in changelog this morning... I created an issue in swi-prolog. This dependency update seems to introduce the error, failing to load a library. Related issue is #916942: swi-prolog: fails to load process library Will investigate if i can understand why it fails in the meanwhile as a workaround Le jeu. 20 déc. 2018 à 21:33, Andreas Tille a écrit : > Hi Olivier, > > since upstream has just released a new upstream version some hours ago > my hope was that this might cover the issue and injected the new version > into Git. Unfortunately I'm running into some similar looking test > suite errors when building in pbuilder. > > I need to give up here and hope you can take over. > > Kind regards > > Andreas. > > > On Thu, Dec 20, 2018 at 09:44:44PM +0200, Adrian Bunk wrote: > > Source: logol > > Version: 1.7.8-3 > > Severity: serious > > Tags: ftbfs > > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/logol.html > > > > ... > > [junit] - --- > > [junit] Testcase: > testAmbiguous(org.irisa.genouest.logol.test.GrammarTest):SKIPPED: got: > , expected: is > > [junit] Testcase: > testRepeatOverlap(org.irisa.genouest.logol.test.GrammarTest): FAILED > > [junit] null > > [junit] junit.framework.AssertionFailedError > > [junit] at > org.irisa.genouest.logol.test.GrammarTest.checkResult(Unknown Source) > > [junit] at > org.irisa.genouest.logol.test.GrammarTest.testRepeatOverlap(Unknown Source) > > [junit] at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > [junit] at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > [junit] at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > [junit] > > [junit] > > ... > > > > ___ > > Debian-med-packaging mailing list > > debian-med-packag...@alioth-lists.debian.net > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > -- > http://fam-tille.de > >
Bug#916942: additional info
Executing cmd directly seems to work: swipl Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.25) SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software. Please run ?- license. for legal details. For online help and background, visit http://www.swi-prolog.org For built-in help, use ?- help(Topic). or ?- apropos(Word). ?- use_foreign_library(foreign(process)). true. Logol program is compiled with swipl-ld , so problem seems to occur with compiled version only. Older compilations/tests (with older swipl version?) used to work. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#916942: swi-prolog: fails to load process library
Package: swi-prolog Version: 7.7.25+dfsg-2 Severity: normal Dear Maintainer, Trying to recompile logol package, tests are failing with error: /usr/lib/swi-prolog/library/process.pl:57: Initialization goal raised In process.pl this is related to : :-use_foreign_library(foreign(process))." Stack error: process: cannot open shared object file: No such file or directory In: [stderr] ERROR: [18] throw(error(shared_object(open,'process: cannot open shared object file: No such file or directory'),context(...,_918))) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-42-generic (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages swi-prolog depends on: ii swi-prolog-nox 7.7.25+dfsg-2 ii swi-prolog-x7.7.25+dfsg-2 swi-prolog recommends no packages. swi-prolog suggests no packages. -- no debconf information
Bug#893409: pixelmed FTBFS with openjdk-9
On 12/19/18 11:46 AM, Andreas Tille wrote:
> Hi,
>
> On Wed, Dec 19, 2018 at 10:39:55AM +0100, Olivier Sallou wrote:
>>> The missing class is in libjaxb-api-java. Just make sure it's on the
>>> CLASSPATH.
>> yeap, an other issue at java migration to openjdk 10/11
>>
>> Adding this lib to deps should fix the pb
- I have fixed the problem, updating patch (lib needed to be added to
other Makefile)
- There were some other issues with an old jdk package moved to an other
location, from JDK 9 in 2016, which is not exported [0]. Surprisingly it
compiles anyway, but does it work as expected?? It seems there is a
new API (java.lang.ref.Cleaner) but I'm not sure it could be replaced as
easily (and without knowing side effects), it should be updated by upstream
In the meanwhile I renamed the related package in patch.
- vecmath needed to be added as well in Makefile (done)
- javadoc generation classpath needed to be updated as well (done)
- I think that vecmath and jaxb-api jars will need to be added in
runtime classpath (debian/DicomXX etc..) as well (NOT done)
- 4 tests are failing (surprisingly, packaging continues)
- lintian: some errors, documentation is not in correct directory
(libpixelmed-java-doc expects files in
/usr/share/doc/libpixelmed-java-doc but doc is in
/usr/share/doc/libpixelmed-java) (NOT fixed)
I have pushed my updates to git (file not found , certainly a result not
generated, but no additional info)
[0] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8148117
Olivier
> Thanks for the quick help. I tried:
>
>
> diff --git a/debian/control b/debian/control
> index e0548ee..3f8b86c 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -14,7 +14,8 @@ Build-Depends-Indep: default-jdk,
> libjmdns-java,
> libvecmath-java,
> libpixelmed-codec-java,
> - libjsonp-java
> + libjsonp-java,
> + libjaxb-api-java
> Standards-Version: 4.2.1
> Vcs-Browser: https://salsa.debian.org/med-team/pixelmed
> Vcs-Git: https://salsa.debian.org/med-team/pixelmed.git
> diff --git a/debian/patches/fixdoc.patch b/debian/patches/fixdoc.patch
> index 752b78c..1737f5f 100644
> --- a/debian/patches/fixdoc.patch
> +++ b/debian/patches/fixdoc.patch
> @@ -11,7 +11,7 @@ Index: pixelmed-20140326/Makefile
> rm -rf docs/javadoc
> javadoc \
> - -classpath
> .:lib/additional/excalibur-bzip2-1.0.jar:lib/additional/hsqldb.jar:lib/additional/vecmath1.2-1.14.jar:lib/additional/commons-codec-1.3.jar:lib/additional/commons-net2.jar:lib/additional/jmdns.jar:lib/additional/jpedalSTD.jar:lib/junit/junit-4.8.1.jar
> \
> -+ -classpath
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar
> \
> ++ -classpath
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar:/usr/share/java/jaxb-api.jar
> \
> -link http://download.oracle.com/javase/1.5.0/docs/api/ \
> -link http://jpedal.org/javadoc/ \
> -link http://www.hsqldb.org/doc/src/ \
> diff --git a/debian/patches/jaxb-api.patch b/debian/patches/jaxb-api.patch
> new file mode 100644
> index 000..85760dd
> --- /dev/null
> +++ b/debian/patches/jaxb-api.patch
> @@ -0,0 +1,16 @@
> +Description: For OpenJDK 11 jaxb needs to be in classpath
> +Bug-Debian: https://bugs.debian.org/893409
> +Author: Andreas Tille
> +Last-Update: Wed, 19 Dec 2018 08:53:43 +0100
> +
> +--- a/Makefile.common.mk
> b/Makefile.common.mk
> +@@ -65,7 +65,7 @@ JAVACOPTIONS = -O ${JAVACTARGETOPTIONS}
> +
> + .java.class:
> + export JAVAVERSIONTARGETJARFILE=${JAVA_HOME}/jre/lib/rt.jar; javac
> ${JAVACOPTIONS} \
> +- -classpath
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}
> \
> ++ -classpath
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}:/usr/share/java/jaxb-api.jar
> \
> + -sourcepath ${PATHTOROOT} $<
> +
> + .png.ico:
> diff --git a/debian/patches/series b/debian/patches/series
> index 10286d4..6abfc45 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -16,3 +16,4 @@ set_java_home.patch
> imageio.patch
> no_Xdiags_verbose.patch
> do_not_set_bootclasspath.
Bug#893409: pixelmed FTBFS with openjdk-9
On 12/19/18 11:46 AM, Andreas Tille wrote:
> Hi,
>
> On Wed, Dec 19, 2018 at 10:39:55AM +0100, Olivier Sallou wrote:
>>> The missing class is in libjaxb-api-java. Just make sure it's on the
>>> CLASSPATH.
>> yeap, an other issue at java migration to openjdk 10/11
>>
>> Adding this lib to deps should fix the pb
> Thanks for the quick help. I tried:
>
>
> diff --git a/debian/control b/debian/control
> index e0548ee..3f8b86c 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -14,7 +14,8 @@ Build-Depends-Indep: default-jdk,
> libjmdns-java,
> libvecmath-java,
> libpixelmed-codec-java,
> - libjsonp-java
> + libjsonp-java,
> + libjaxb-api-java
> Standards-Version: 4.2.1
> Vcs-Browser: https://salsa.debian.org/med-team/pixelmed
> Vcs-Git: https://salsa.debian.org/med-team/pixelmed.git
> diff --git a/debian/patches/fixdoc.patch b/debian/patches/fixdoc.patch
> index 752b78c..1737f5f 100644
> --- a/debian/patches/fixdoc.patch
> +++ b/debian/patches/fixdoc.patch
> @@ -11,7 +11,7 @@ Index: pixelmed-20140326/Makefile
> rm -rf docs/javadoc
> javadoc \
> - -classpath
> .:lib/additional/excalibur-bzip2-1.0.jar:lib/additional/hsqldb.jar:lib/additional/vecmath1.2-1.14.jar:lib/additional/commons-codec-1.3.jar:lib/additional/commons-net2.jar:lib/additional/jmdns.jar:lib/additional/jpedalSTD.jar:lib/junit/junit-4.8.1.jar
> \
> -+ -classpath
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar
> \
> ++ -classpath
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar:/usr/share/java/jaxb-api.jar
> \
> -link http://download.oracle.com/javase/1.5.0/docs/api/ \
> -link http://jpedal.org/javadoc/ \
> -link http://www.hsqldb.org/doc/src/ \
> diff --git a/debian/patches/jaxb-api.patch b/debian/patches/jaxb-api.patch
> new file mode 100644
> index 000..85760dd
> --- /dev/null
> +++ b/debian/patches/jaxb-api.patch
> @@ -0,0 +1,16 @@
> +Description: For OpenJDK 11 jaxb needs to be in classpath
> +Bug-Debian: https://bugs.debian.org/893409
> +Author: Andreas Tille
> +Last-Update: Wed, 19 Dec 2018 08:53:43 +0100
> +
> +--- a/Makefile.common.mk
> b/Makefile.common.mk
> +@@ -65,7 +65,7 @@ JAVACOPTIONS = -O ${JAVACTARGETOPTIONS}
> +
> + .java.class:
> + export JAVAVERSIONTARGETJARFILE=${JAVA_HOME}/jre/lib/rt.jar; javac
> ${JAVACOPTIONS} \
> +- -classpath
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}
> \
> ++ -classpath
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}:/usr/share/java/jaxb-api.jar
> \
> + -sourcepath ${PATHTOROOT} $<
> +
> + .png.ico:
> diff --git a/debian/patches/series b/debian/patches/series
> index 10286d4..6abfc45 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -16,3 +16,4 @@ set_java_home.patch
> imageio.patch
> no_Xdiags_verbose.patch
> do_not_set_bootclasspath.patch
> +jaxb-api.patch
>
>
>
> I've pushed these changes but unfortunately it does not help. :-(
I'm looking at the issue
>
> Any further hints?
>
> Kind regards
>
> Andreas.
>
>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#893409: pixelmed FTBFS with openjdk-9
On 12/19/18 10:03 AM, Markus Koschany wrote: > Hi, > > Am 19.12.18 um 09:58 schrieb Andreas Tille: > [...] >> Any hint how to fix this? > The missing class is in libjaxb-api-java. Just make sure it's on the > CLASSPATH. yeap, an other issue at java migration to openjdk 10/11 Adding this lib to deps should fix the pb > Regards, > > Markus > > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: OpenPGP digital signature
Bug#906371: [Debian-med-packaging] Bug#906371: Changes in alter-sequence-alignment break build of jmodeltest (Was: Bug#906371: jmodeltest: FTBFS in buster/sid)
On 12/17/18 11:07 AM, Andreas Tille wrote: > Hi, > > after I tried to follow the initial hint of Emmanuel I admit I was not > successful to finally build the package: > > On Wed, Oct 17, 2018 at 10:32:58AM +0200, Andreas Tille wrote: >>> Good catch. The latest upstream version of alter-sequence-alignment has >>> split these to an additional alter-lib.jar and the time of the build >>> failure of jmodeltest correlates with the upload of >>> alter-sequence-alignment 1.3.4-1. But now the question is: How to >>> teach the jmodeltest build system to use alter-lib.jar. I think adding >>> it to debian/manifest[1] is needed to *run* jmodeltest but it surely >>> does not help at build time. I have not found any place where the >>> build system specifies the needed jars. :-( >> I tried to add alter-lib.jar to build.xml[1]. Unfortunately this does >> not help to fix the issue >> >> [javac] >> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:28: >> error: package parser does not exist >> [javac] import parser.ParseException; >> [javac] ^ >> [javac] >> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:29: >> error: package converter does not exist >> [javac] import converter.Converter; >> [javac] ^ >> [javac] >> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:30: >> error: package converter does not exist >> [javac] import converter.DefaultFactory; >> [javac] ^ >> [javac] >> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:31: >> error: package converter does not exist >> [javac] import converter.Factory; >> >> Any hint how to get the classes in alter-lib.jar found? I fixed the issue and pushed to git my patch d/patches/fix_alter-lib.patch The lib was used but the package name in alter-lib.jar is different. ModelTestService is patched to use correct package name >> Moreover I get lots of >> >> [javac] >> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/exe/Distributor.java:23: >> warning: [deprecation] Observable in java.util has been deprecated >> [javac] import java.util.Observable; >> [javac] ^ > Any more hints? > > Kind regards > >Andreas. > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#916000: [Debian-med-packaging] Bug#916000: ncbi-blast+: FTBFS - Makefile.flat: No such file or directory
On 12/9/18 5:11 PM, Aaron M. Ucko wrote: > Andreas Metzler writes: > >> ncbi-blast+ FTBFS on current sid: > Thanks for the report! It looks like ncbi-blast+ needs another round of > formal patches for compatibility with current Boost. The following > upstream changes should collectively take care of it: > > https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=79910 > https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=79926 > https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=79928 > https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=79929 > > Olivier, will you have time to integrate these changes, or should I? no time for the moment, if you can do it, I would appreciate thanks Olivier > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#913839: not internet access
issue is not related to an internet access. it tries to get local host name or address : java.net.InetAddress.getLocalHost(..) and result in java.net.UnknownHostException: profitbricks-build15-amd64: profitbricks-build15-amd64: Temporary failure in name resolution According to Java: This is achieved by retrieving the name of the host from the system, then resolving that name into an InetAddress. So issue looks related to test server host/ip resolution. not an external access requirement. Anyway, I guess that test could be disable via a patch. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#895765: [Debian-med-packaging] Bug#895765: IGV FTBFS with Java 11
additional remark: igv will in this case need to depend on java >= 11 as this modification for build and runtime will work only for jdk11 and above this jdk module/deprecation transition is quite a pain and make it difficult to get packages work for different jdk versions - Mail original - > De: "Markus Koschany" > À: 895...@bugs.debian.org > Envoyé: Vendredi 9 Novembre 2018 16:33:33 > Objet: [Debian-med-packaging] Bug#895765: IGV FTBFS with Java 11 > Hi, > > igv also FTBFS with Java 11 now. However the fix is trivial. The package > must build-depend on libjaxb-api-java because those classes were removed > from the JDK. Then you need to remove the > > --add-modules', 'java.xml.bind' > > line in fix_gradle.patch. > > Please find attached a patch that makes the necessary changes to the > Debian packaging without using a patch. > > Markus > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#912235: activation and corba removed from jdk
the problem is those packages are deprecated and cannot be used with jdk 11. Forcing use of a previous jdk will work will this jdk is available in debian. the problemis to get something working both for "old" jdk and "new" jdks I think upstream focused on older versions (installed in more locations) but indeed should be forwarded as an issue, and last upstream version is from 2016 javax.activation should be "replaced" by JAF standalone version i suppose but 1) it is not in Debian 2) seems to be named now java.activation (so needs patching to rename calls) for Corba related stuff, don't know for any replacement. Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#912385: rdp-classifier FTBFS with OpenJDK 11
- Mail original - > De: "andreas" > À: 912...@bugs.debian.org, "Debian Java List" > Envoyé: Mercredi 31 Octobre 2018 07:07:36 > Objet: Re: Bug#912385: rdp-classifier FTBFS with OpenJDK 11 > Control: tags -1 help > > Hi, > > I'm afraid I need help for this bug from the Debian Java team. > > Kind regards > > Andreas. > > On Wed, Oct 31, 2018 at 04:56:52AM +0200, Adrian Bunk wrote: >> Source: rdp-classifier >> Version: 2.10.2-3 >> Severity: serious >> Tags: ftbfs >> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rdp-classifier.html >> >> ... >> junit: >> [javac] /build/1st/rdp-classifier-2.10.2/tmp-junit.xml:13: warning: >> 'includeantruntime' was not set, defaulting to build.sysclasspath=last; >> set to >> false for repeatable builds >> [javac] Compiling 18 source files >> [javac] warning: [options] bootstrap class path not set in conjunction >> with >> -source 8 >> [javac] Note: Some input files use unchecked or unsafe operations. >> [javac] Note: Recompile with -Xlint:unchecked for details. >> [javac] 1 warning >> [echo] Using java version 11.0.1 >> [junit] Error occurred during initialization of boot layer >> [junit] java.lang.module.FindException: Module java.se.ee not found think this needs to be forwarded to upstream (if any...) According to javadoc [0] @Deprecated(since="9", forRemoval=true) Module java.se.ee Deprecated, for removal: This API element is subject to removal in a future version. In the meanwhile, adding --add-module java.se.ee should do the job Some module that were removed from jdk and need the --add-module option: java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services Metadata) java.xml.bind (JAXB) java.activation (JAF) java.xml.ws.annotation (Common Annotations) java.corba (CORBA) java.transaction (JTA) Related modules in Java SE 9 are also deprecated for removal: java.se.ee (Aggregator module for the six modules above) jdk.xml.ws (Tools for JAX-WS) jdk.xml.bind (Tools for JAXB) [0] https://docs.oracle.com/javase/9/docs/api/java.se.ee-summary.html >> [junit] Running edu.msu.cme.rdp.classifier.rrnaclassifier.ClassifierTest >> [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: >> 0 sec >> >> BUILD FAILED >> /build/1st/rdp-classifier-2.10.2/tmp-junit.xml:31: Test >> edu.msu.cme.rdp.classifier.rrnaclassifier.ClassifierTest failed (crashed) >> >> Total time: 3 seconds >> make[1]: *** [debian/rules:26: override_dh_auto_test] Error 1 >> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > -- > http://fam-tille.de
Bug#912386: [Debian-med-packaging] Bug#912386: rdp-readseq FTBFS with OpenJDK 11
- Mail original - > De: "andreas" > À: 912...@bugs.debian.org > Envoyé: Mercredi 31 Octobre 2018 07:10:01 > Objet: [Debian-med-packaging] Bug#912386: rdp-readseq FTBFS with OpenJDK 11 > Control: tags -1 help > > Hi, > > I'm afraid I need help for this bug from the Debian Java team. > > Kind regards > > Andreas. > > On Wed, Oct 31, 2018 at 04:58:09AM +0200, Adrian Bunk wrote: >> Source: rdp-readseq >> Version: 2.0.2-4 >> Severity: serious >> Tags: ftbfs >> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rdp-readseq.html >> >> ... >>debian/rules override_dh_auto_build >> make[1]: Entering directory '/build/1st/rdp-readseq-2.0.2' >> jh_build --javacopts="-encoding UTF8" rdp-readseq.jar src >> find src -name *.java -and -type f -print0 | xargs -s 512000 -0 >> /usr/lib/jvm/default-java/bin/javac -g -cp >> /usr/share/java/commons-cli.jar:/usr/share/java/commons-lang.jar:/usr/share/java/commons-io.jar:debian/_jh_build.rdp-readseq >> -d debian/_jh_build.rdp-readseq -source 1.7 -target 1.7 -encoding UTF8 >> warning: [options] bootstrap class path not set in conjunction with -source 7 >> src/edu/msu/cme/rdp/readseq/readers/Sequence.java:11: error: package >> javax.xml.bind.annotation does not exist >> import javax.xml.bind.annotation.XmlAttribute; java xml has been removed from "core" jdk with Java 9 ou 10. Commands (javac, java , ...) needs to add javax.xml module with --add-module option (not sure of syntax). We have other packages where we added such option with java upgrades. I am on travel, cannot fix this now but I can have a look later on. But adding option should do the job (if there is a shell that calls java cmd line, it should also be added) Olivier >> ^ >> src/edu/msu/cme/rdp/readseq/readers/Sequence.java:12: error: package >> javax.xml.bind.annotation does not exist >> import javax.xml.bind.annotation.XmlElement; >> ^ >> src/edu/msu/cme/rdp/readseq/readers/Sequence.java:19: error: cannot find >> symbol >> @XmlAttribute >> ^ >> symbol: class XmlAttribute >> location: class Sequence >> src/edu/msu/cme/rdp/readseq/readers/Sequence.java:21: error: cannot find >> symbol >> @XmlAttribute >> ^ >> symbol: class XmlAttribute >> location: class Sequence >> src/edu/msu/cme/rdp/readseq/readers/Sequence.java:23: error: cannot find >> symbol >> @XmlElement >> ^ >> symbol: class XmlElement >> location: class Sequence >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> 5 errors >> 1 warning >> make[1]: *** [debian/rules:27: override_dh_auto_build] Error 123 >> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > -- > http://fam-tille.de > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#895765: IGV
On 10/18/2018 08:25 PM, Andreas Tille wrote: > Hi Olivier, > > On Thu, Oct 18, 2018 at 06:18:58PM +0200, Olivier Sallou wrote: >> testing with your removals, you only need to add to build gradle file >> the ref to htsjdk > I've now pushed the freshly stripped upstream version since we > both agree that a competing htsjdk is not a good idea. > >> I pushed the update on patch (but your copyright patch is not yet there) >> >> With this compile "com.github.samtools:htsjdk:debian" and htsjdk jar >> removed from upstream source, it compiles fine for me. > I confirm it compiles fine now. However: > > > $ LC_ALL=C igv > Error: Unable to initialize main class org.broad.igv.ui.Main > Caused by: java.lang.NoClassDefFoundError: > htsjdk/samtools/seekablestream/ISeekableStreamFactory I just pulled from git, rebuilt and tried with new deb, and got no issue, GUI started as expected. This kind of error suggest that it did not found in igv classpath the htsjdk.jar (not installed or not in in command classpath). > > > Sorry to admit that we seem to need another iteration to get igv out. > > Thanks a lot for your effort > > Andreas. > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#895765: IGV
On 10/18/2018 04:06 PM, Andreas Tille wrote:
> Hi Olivier,
>
> On Thu, Oct 18, 2018 at 01:05:12PM +0200, Olivier Sallou wrote:
>>> I tried a patch to use Debian htsjdk, and pushed it. IGV ui starts, but
>>> fails with other X11 errors
>>>
>>> 2018-10-18 10:13:25 ERROR DefaultExceptionHandler:49 - Unhandled exception
>>> java.lang.IllegalArgumentException: Window must not be zero
>>> at java.desktop/sun.awt.X11.XAtom.checkWindow(XAtom.java:774)
>>> at java.desktop/sun.awt.X11.XAtom.getAtomData(XAtom.java:465)
>>> ..
>>>
>>> this is above my knowledge of gui system in java
>> in fact it seems to work. X11 error occurs when having multiple screens
>> and seems to relate to an openjdk bug [0].
>> With a single screen I could open and manipulate the GUI
>>
>> I have pushed the patch update to manage current hstjdk debian version
> Sounds good. Unfortunately I made an unfortunate observation: If I
> apply the following patch:
>
> diff --git a/debian/copyright b/debian/copyright
> index defa779..5305639 100644
> --- a/debian/copyright
> +++ b/debian/copyright
> @@ -1,31 +1,21 @@
> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Source: http://www.broadinstitute.org/igv/projects/downloads
> Files-Excluded:
> -igv.jar
> -batik-codec.jar
> -igv.bat
> -igv.command
> -lib/Jama-*
> lib/batik*
> lib/commons*
> -lib/concurrent*
> lib/guava*
> -lib/jargs*
> +*/htsjdk*.jar
> lib/jcommon*
> lib/jfreechart*
> -lib/junit-*
> +*/junit-*.jar
> lib/log4j-*
> -lib/sam-*
> +*/picard-*.jar
> +*/snappy-java-*.jar
> lib/swing-layout-*
> -lib/xml-apis-*
> -lib/bcprov*
> -lib/jgrapht*
> lib/jide-oss-*
> -lib/cofoja*
> -lib/mysql-connector*
> lib/gson*
> -test/lib/ant.jar
> -test/lib/fest-assert*.jar
> +*/ant.jar
> +*/fest-Assert*.jar
> test/lib/fest-util*.jar
> test/lib/fest-reflect*.jar
> Disclaimer: This package is not part of the Debian operating system.
testing with your removals, you only need to add to build gradle file
the ref to htsjdk
diff --git a/debian/patches/fix_gradle.patch
b/debian/patches/fix_gradle.patch
index 421a147..b2a0ac4 100644
--- a/debian/patches/fix_gradle.patch
+++ b/debian/patches/fix_gradle.patch
@@ -34,7 +34,7 @@ Forwarded: no
sourceSets {
main {
java {
-@@ -45,6 +54,27 @@
+@@ -45,6 +54,28 @@
dependencies {
// Use the newer JIDE lib for Java 9 builds
compile fileTree(dir: 'lib', include: '*.jar', exclude:
'jide-oss-3.5.5.jar') + fileTree(dir: 'lib_java9', include: '*.jar')
@@ -59,10 +59,11 @@ Forwarded: no
+ compile "org.apache.logging.log4j:log4j-1.2-api:debian"
+ compile "org.apache.logging.log4j:log4j-core:debian"
+ compile "org.swinglabs:swing-layout:debian"
++ compile "com.github.samtools:htsjdk:debian"
testCompile fileTree(dir: 'test/lib', include: '*.jar')
}
-@@ -93,12 +123,13 @@
+@@ -93,12 +124,13 @@
}
compileJava {
I pushed the update on patch (but your copyright patch is not yet there)
With this compile "com.github.samtools:htsjdk:debian" and htsjdk jar
removed from upstream source, it compiles fine for me.
Olivier
>
>
> which does not mention not existing jars but more importantly removes
> those jars we **think** we don't need - specifically */htsjdk*.jar -
> recreate the tarball and try to build ... the build fails again. :-( Its
> also some htsjdk related error and I think there are more issues in this
> approach. It seems for whatever reason the build is done against the
> internal copy but the result tries somehow to take the Debian installed
> version. I'm hesitating to push my changes since than we have a broken
> IGV again.
>
> What do you suggest as next step? I might create a branch to let others
> have a look.
>
> Kind regards
>
>Andreas.
>
>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#895765: IGV
On 10/18/2018 04:06 PM, Andreas Tille wrote: > Hi Olivier, > > On Thu, Oct 18, 2018 at 01:05:12PM +0200, Olivier Sallou wrote: >>> I tried a patch to use Debian htsjdk, and pushed it. IGV ui starts, but >>> fails with other X11 errors >>> >>> 2018-10-18 10:13:25 ERROR DefaultExceptionHandler:49 - Unhandled exception >>> java.lang.IllegalArgumentException: Window must not be zero >>> at java.desktop/sun.awt.X11.XAtom.checkWindow(XAtom.java:774) >>> at java.desktop/sun.awt.X11.XAtom.getAtomData(XAtom.java:465) >>> .. >>> >>> this is above my knowledge of gui system in java >> in fact it seems to work. X11 error occurs when having multiple screens >> and seems to relate to an openjdk bug [0]. >> With a single screen I could open and manipulate the GUI >> >> I have pushed the patch update to manage current hstjdk debian version > Sounds good. Unfortunately I made an unfortunate observation: If I > apply the following patch: > > diff --git a/debian/copyright b/debian/copyright > index defa779..5305639 100644 > --- a/debian/copyright > +++ b/debian/copyright > @@ -1,31 +1,21 @@ > Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > Source: http://www.broadinstitute.org/igv/projects/downloads > Files-Excluded: > -igv.jar > -batik-codec.jar > -igv.bat > -igv.command > -lib/Jama-* > lib/batik* > lib/commons* > -lib/concurrent* > lib/guava* > -lib/jargs* > +*/htsjdk*.jar oohhh, I did not see that htsjdk was part of package, though it had been removed. Explains a few things I gonna take your updates and test > lib/jcommon* > lib/jfreechart* > -lib/junit-* > +*/junit-*.jar > lib/log4j-* > -lib/sam-* > +*/picard-*.jar > +*/snappy-java-*.jar > lib/swing-layout-* > -lib/xml-apis-* > -lib/bcprov* > -lib/jgrapht* > lib/jide-oss-* > -lib/cofoja* > -lib/mysql-connector* > lib/gson* > -test/lib/ant.jar > -test/lib/fest-assert*.jar > +*/ant.jar > +*/fest-Assert*.jar > test/lib/fest-util*.jar > test/lib/fest-reflect*.jar > Disclaimer: This package is not part of the Debian operating system. > > > which does not mention not existing jars but more importantly removes > those jars we **think** we don't need - specifically */htsjdk*.jar - > recreate the tarball and try to build ... the build fails again. :-( Its > also some htsjdk related error and I think there are more issues in this > approach. It seems for whatever reason the build is done against the > internal copy but the result tries somehow to take the Debian installed > version. I'm hesitating to push my changes since than we have a broken > IGV again. > > What do you suggest as next step? I might create a branch to let others > have a look. > > Kind regards > >Andreas. > > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#895765: IGV
On 10/18/2018 12:15 PM, Olivier Sallou wrote:
>
> On 10/18/2018 12:03 PM, Olivier Sallou wrote:
>> On 10/18/2018 11:42 AM, Andreas Tille wrote:
>>> Hi Olivier,
>>>
>>> On Thu, Oct 18, 2018 at 11:13:31AM +0200, Olivier Sallou wrote:
>>>>> Unfortunately if I start the package I get the following output:
>>>>>
>>>>> $ igv
>>>>>
>>>>>
>>>>> log4j: reset attribute= "false".
>>>>> log4j: Threshold ="null".
>>>>> log4j: Retreiving an instance of org.apache.log4j.Logger.
>>>>> log4j: Setting [org.broad.igv] additivity to [true].
>>>>> log4j: Level value for org.broad.igv is [INFO].
>>>>> log4j: org.broad.igv level set to INFO
>>>>> log4j: Class name: [org.apache.log4j.ConsoleAppender]
>>>>> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
>>>>> log4j: Setting property [conversionPattern] to [%d{-MM-dd HH:mm:ss}
>>>>> %-5p %c{1}:%L - %m%n].
>>>>> log4j: Adding appender named [console] to category [org.broad.igv].
>>>>> 2018-10-17 14:37:58 INFO DirectoryManager:179 - IGV Directory:
>>>>> /home/andreas/igv
>>>>> 2018-10-17 14:37:59 INFO Main:155 - Startup IGV Version user not_set
>>>>> 2018-10-17 14:37:59 INFO Main:156 - Java 10.0.2
>>>>> 2018-10-17 14:37:59 INFO DirectoryManager:84 - Fetching user directory...
>>>>> 2018-10-17 14:37:59 INFO Main:157 - Default User Directory: /home/andreas
>>>>> 2018-10-17 14:38:00 INFO Main:158 - OS: Linux
>>>>>
>>>>>
>>>>> 2018-10-17 14:38:00 INFO Main:208 - Unknown version: user
>>>>> 2018-10-17 14:38:00 ERROR DefaultExceptionHandler:49 - Unhandled exception
>>>>> java.lang.VerifyError: class
>>>>> org.broad.igv.util.stream.IGVSeekableBufferedStream overrides final
>>>>> method htsjdk.samtools.seekablestream.SeekableStream.mark(I)V
>>>> could be an htsjdk version issue versus what expects igv.
>>>> or getting 2 different definitions of
>>>> htsjdk.samtools.seekablestream.SeekableStream in classpath
>>> I admit I had the same idea.
>
> I tried a patch to use Debian htsjdk, and pushed it. IGV ui starts, but
> fails with other X11 errors
>
> 2018-10-18 10:13:25 ERROR DefaultExceptionHandler:49 - Unhandled exception
> java.lang.IllegalArgumentException: Window must not be zero
> at java.desktop/sun.awt.X11.XAtom.checkWindow(XAtom.java:774)
> at java.desktop/sun.awt.X11.XAtom.getAtomData(XAtom.java:465)
> ..
>
> this is above my knowledge of gui system in java
in fact it seems to work. X11 error occurs when having multiple screens
and seems to relate to an openjdk bug [0].
With a single screen I could open and manipulate the GUI
I have pushed the patch update to manage current hstjdk debian version
[0] https://bugs.openjdk.java.net/browse/JDK-8204646
Olivier
>>> ...
>>>>> libhtsjdk-java - 2.16.1+dfsg-1
>>> while igv includes
>>>
>>> htsjdk-2.12.0-18-g20ee53e-SNAPSHOT.jar
>> the problem is org.broad.igv.util.stream.IGVSeekableBufferedStream
>> extends a class from htsjdk but redefines a method declared as final,
>> this is forbidden.
>> Don't understand however why it compiles.
>> Recent htsjdk (as we have), includes those methods and cannot be
>> overriden. Version 2.12 did not have those methods.
>>
>> Using internal has the issue we don't have the source code for it
>> (though should match a commit). To get it work, we should simply remove
>> htsjdk related "compile" directive in build gradle file (added via our
>> patch)
>>
>>> I just realised that the Files-Excluded rules do not even remove this.
>>> I assumed this would be excluded - so what about using the internal
>>> code copy? (Unfortunately I have no idea what to change to let this
>>> happen.)
>>>
>>> Kind regards
>>>
>>> Andreas.
>>>
--
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
