Bug#795685: [Debian-med-packaging] Bug#795685: biojava4-live: FTBFS: UnknownHostException: eutils.ncbi.nlm.nih.gov
On 08/16/2015 11:28 AM, Chris West (Faux) wrote: > Source: biojava4-live > Version: 4.1.0+dfsg-1 > Severity: serious > Justification: fails to build from source > Tags: sid stretch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build without networking, which we believe is a > policy violation. Ubuntu may have a patch, as they also enforce this: > > [junit] Running > org.biojava.nbio.core.sequence.loader.GenbankProxySequenceReaderTest > [junit] Testsuite: > org.biojava.nbio.core.sequence.loader.GenbankProxySequenceReaderTest > [junit] Tests run: 16, Failures: 0, Errors: 8, Skipped: 0, Time elapsed: > 0.095 sec > [junit] Tests run: 16, Failures: 0, Errors: 8, Skipped: 0, Time elapsed: > 0.095 sec > [junit] - Standard Error - > [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". > [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation > [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for > further details. > [junit] - --- > [junit] > [junit] Testcase: testProteinSequenceFactoring[0] took 0.038 sec > [junit] Caused an ERROR > [junit] eutils.ncbi.nlm.nih.gov > [junit] java.net.UnknownHostException: eutils.ncbi.nlm.nih.gov > [junit] at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:178) > ... > [junit] at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1301) > [junit] at > org.biojava.nbio.core.sequence.loader.GenbankProxySequenceReader.getEutilsInputStream(GenbankProxySequenceReader.java:141) > [junit] at > org.biojava.nbio.core.sequence.loader.GenbankProxySequenceReader.getBufferedInputStream(GenbankProxySequenceReader.java:109) > [junit] at > org.biojava.nbio.core.sequence.loader.GenbankProxySequenceReader.(GenbankProxySequenceReader.java:83) > [junit] at > org.biojava.nbio.core.sequence.loader.GenbankProxySequenceReaderTest.testProteinSequenceFactoring(GenbankProxySequenceReaderTest.java:84) > [junit] > [junit] Testcase: testFeatures[0] took 0 sec > [junit] Testcase: testProteinSequenceFactoring[1] took 0.001 sec > [junit] Caused an ERROR > [junit] eutils.ncbi.nlm.nih.gov > [junit] java.net.UnknownHostException: eutils.ncbi.nlm.nih.gov Thanks for the report. I already disabled some network tests, those ones are certainly new "remote" tests introduced in this release. I gonna patch this soon. > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#795849: [Debian-med-packaging] Bug#795849: biojava4-live: FTBFS: DemoOrientBioAssembly.java:60: error: unmappable character for encoding ASCII
On 08/17/2015 01:57 PM, Chris Lamb wrote: > Source: biojava4-live > Version: 4.1.0+dfsg-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > Thanks for looking at #795685 so quickly. However, biojava4-live still > fails to build from source on unstable/amd64 with a different issue: Thanks, I know this issue and how to fix this, however I do not understand why it does not occur on my computer. I gonna ask java team to avoid getting again the error on other files before uploading. Olivier > > [..] > > compile: > [mkdir] Created dir: > > /tmp/buildd/biojava4-live-4.1.0+dfsg/build/biojava4-structure-gui/classes > [javac] > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/build.xml:76: > warning: 'includeantruntime' was not set, defaulting to > build.sysclasspath=last; set to false for repeatable builds > [javac] Compiling 130 source files to > > /tmp/buildd/biojava4-live-4.1.0+dfsg/build/biojava4-structure-gui/classes > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:60: > error: unmappable character for encoding ASCII > [javac] 4F88 ??? local C8 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:60: > error: unmappable character for encoding ASCII > [javac] 4F88 ??? local C8 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:60: > error: unmappable character for encoding ASCII > [javac] 4F88 ??? local C8 > [javac]^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:61: > error: unmappable character for encoding ASCII > [javac] 1LTI ??? local C5 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:61: > error: unmappable character for encoding ASCII > [javac] 1LTI ??? local C5 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:61: > error: unmappable character for encoding ASCII > [javac] 1LTI ??? local C5 > [javac]^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:62: > error: unmappable character for encoding ASCII > [javac] 2W6E ??? local C3 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:62: > error: unmappable character for encoding ASCII > [javac] 2W6E ??? local C3 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:62: > error: unmappable character for encoding ASCII > [javac] 2W6E ??? local C3 > [javac]^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:63: > error: unmappable character for encoding ASCII > [javac] 2LXC ??? local C2 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:63: > error: unmappable character for encoding ASCII > [javac] 2LXC ??? local C2 > [javac] ^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:63: > error: unmappable character for encoding ASCII > [javac] 2LXC ??? local C2 > [javac]^ > [javac] > > /tmp/buildd/biojava4-live-4.1.0+dfsg/biojava-structure-gui/src/main/java/demo/DemoOrientBioAssembly.java:64: > error: unmappable character for encoding ASCII > [javac] 3OE7 ??? local C3 > [javac]
Bug#689111: upstream modifications
Upstream is responsible of modifying the load.conf file. I gonna try to remove it from package to see if file is necessary or what should be done to avoid this. Regarding password in conf file: - this file is needed by library to access the database (read and write). I gonna change read access to root only. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689111: additional info on password
Password set in "clear" in postinst is only a template with default values set at first-time install. User/Admin must update values to a correct db user to access the database. This is needed because application setup needs a password information. Password echoed at this step is not a security flaw. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679989: ask for lowering severity
Hi, the bug is related to a Prolog issue , fixed in a forthcoming release (related to bug 680116, fixed in experimental). Do you agree to lower the severity of the bug (only impacting build on a few architectures due to compiler issue on those archs) ? I think we could move it to important. Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715225: sa-jdi.jar not found
This should have been fixed in 1.4-1 with classpath related to sa-jdi.jar in debian/patches/fix_classpath_in_build_xml.patch This jar has been added to build path. Build has been tested with pbuilder from sid. This could be related to JAVA_HOME not being set in environment Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769348: [Debian-med-packaging] Bug#769348: biomaj-watcher: Should /var/lib/tomcat8/shared exist?
On 12/14/2014 03:19 PM, Emilien Klein wrote: > TLDR: Please check if the "/var/lib/tomcat8/shared" folder is still used > with Tomcat 8. > > > I have applied the previously attached patch, the package builds fine, > but when installing the .deb the following error occurs: > > Setting up biomaj-watcher (1.2.2-2) ... > Updating Context.xml... > Configuration complete > cp: cannot create regular file ‘/var/lib/tomcat8/shared/biomaj.jar’: No > such file or directory > dpkg: error processing package biomaj-watcher (--configure): > subprocess installed post-installation script returned error exit status 1 > Errors were encountered while processing: > biomaj-watcher > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > The cause of the issue is that there is no "shared" folder in > /var/lib/tomcat8/ Sounds indeed that tomcat shared library folder is not used anymore in Tomcat8. Seems that those libraries should be moved to $CATALINA_HOME/lib now Seems that each version changes this dir.. I think however we could avoid putting lib in such dir with an appropriate context XML file. I gonna try such solution this week and upload fix. > > When creating that folder manually, the package > installation/configuration completes succesfully. I wanted to test if > that folder needed to exist, or if Tomcat 8 even looks at that location. > Unfortunately, when accessing http://localhost:8080/BmajWatcher per > d/README.Debian, I get a Tomcat 404 error message with a description > that "The requested resource is not available." Since I have no > experience with Tomcat, I haven't tried to go deeper in the configuration. > > Maybe you have a quick hint on how to configure Tomcat so that I could > try to go further. > But even if that page worked I'm not sure I could validate that the > "shared" folder is used appropriately. Please validate that. > > +Emilien > > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#796732: cassiopee: library transition needed with GCC 5 as default
On 08/31/2015 09:27 AM, Andreas Tille wrote: > Hi, > > I commited a fix for the library transition to SVN. (Besides this > I also tried to fix some lintian issues but failed with the > wrong-whatis-entry-in-manpage one.) > > Olivier, could you please check and either upload or ping me for > team upload? hi, I gonna upload. I was waiting for further info as GCC5 transition was not clear to me (why renaming to v5, were there other modifications needed). Olivier > > Kind regards > >Andreas, > > On Sun, Aug 23, 2015 at 08:25:22PM +0200, Julien Cristau wrote: >> Source: cassiopee >> Version: 1.0.3+dfsg-2 >> Severity: serious >> Tags: sid stretch >> User: debian-...@lists.debian.org >> Usertags: libstdc++-cxx11 >> >> Hi, >> >> your library exposes std::string or std::list in its public API, and >> therefore the library package needs to be renamed. >> >> Specifically the use of std::list in TreeNode, CassieIndexer and >> CassieSearch is likely to break ABI. >> >> Cheers, >> Julien >> >> The following is a form letter: >> >> Background [1]: libstdc++6 introduces a new ABI to conform to the >> C++11 standard, but keeps the old ABI to not break existing binaries. >> Packages which are built with g++-5 are using the new ABI. Libraries built >> from this source package export some of the new __cxx11 or B5cxx11 symbols, >> and >> dropping other symbols. If these symbols are part of the API of the library, >> then this rebuild with g++-5 will trigger a transition for the library. >> >> What is needed: >> >> - Rebuild the library using g++/g++-5. Note that most likely all C++ >>libraries within the build dependencies need a rebuild too. You can >>find the log for a rebuild in >> https://people.debian.org/~doko/logs/gcc5-20150813/ >>Search for "BEGIN GCC CXX11" in the log. >> >> - Decide if the symbols matching __cxx11 or B5cxx11 are part of the >>library API, and are used by the reverse dependencies of the >>library. >> >> - If there are no symbols matching __cxx11 or B5cxx11 in the symbols >>forming the library API, you should close this issue with a short >>explanation. >> >> - If there are no reverse dependencies, it should be the package >>maintainers decision if a transition is needed. However this might >>break software which is not in the Debian archive, and built >>against these packages. >> >> - If a library transition is needed, please prepare for the change. >>Rename the library package, append "v5" to the name of the package >>(e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you >>have a soversion bump and you upload this version instead of the >>renamed package. Prepare a patch and attach it to this issue (mark >>this issue with patch), so that it is possible to NMU such a >>package. We'll probably have more than hundred transitions >>triggered. Then reassign the issue to release.debian.org and >>properly tag it as a transition issue, by sending an email to >>cont...@bugs.debian.org: >> >> user release.debian@packages.debian.org >> usertag + transition >> block by 790756 >> reassign release.debian.org >> >> - If unsure if a transition is needed, please tag the issue with help >>to ask for feedback from other Debian developers. >> >> The libstdc++6 transition will be a large one, and it will come with a >> lot of pain. Please help it by preparing the follow-up transitions. >> >> [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition >> > > >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#679989: [Debian-med-packaging] Bug#679989: logol: FTBFS on ia64 and sparc with test suite errors
Le 7/2/12 10:01 PM, Aaron M. Ucko a écrit : > Source: logol > Version: 1.5.0-2 > Severity: serious > Justification: fails to build from source > > For some reason, logol's test suite has been failing on ia64 and > sparc. The ia64 log > (https://buildd.debian.org/status/fetch.php?pkg=logol&arch=ia64&ver=1.5.0-2&stamp=1341213925) > reads in part > > [junit] - Standard Error - > [junit] > file:///build/buildd-logol_1.5.0-2-ia64-vS1LA8/logol-1.5.0/./test/tmp/repeat_interspacer.logol.5296211b-63a6-4c35-b8e4-ff2be327902e.1-41.xml; > Line #104; Column #1; XML document structures must start and end within the > same entity. > [junit] > file:///build/buildd-logol_1.5.0-2-ia64-vS1LA8/logol-1.5.0/./test/tmp/repeat_startspacer.logol.38ab2f00-f19e-4c76-baaa-d8bd6837c4ed.1-41.xml; > Line #364; Column #1; XML document structures must start and end within the > same entity. > [junit] > file:///build/buildd-logol_1.5.0-2-ia64-vS1LA8/logol-1.5.0/./test/tmp/anyspacer.logol.70e66617-1bb0-45cb-aecf-462f024b1f2b.1-41.xml; > Line #50; Column #1; XML document structures must start and end within the > same entity. > [junit] > file:///build/buildd-logol_1.5.0-2-ia64-vS1LA8/logol-1.5.0/./test/tmp/anyspacer.lgd.b0b18506-8776-451c-8e22-18da28a389c3.1-41.xml; > Line #50; Column #1; XML document structures must start and end within the > same entity. > [junit] - --- > [junit] Testcase: > testRepeatInterSpacer(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.testRepeatInterSpacer(Unknown > Source) > > (plus similar backtraces for testRepeatStartSpacer, testAnySpacer, and > testModelAnySpacer) and the sparc log > (https://buildd.debian.org/status/fetch.php?pkg=logol&arch=sparc&ver=1.5.0-2&stamp=1341196970) > reports > > BUILD FAILED > /build/buildd-logol_1.5.0-2-sparc-uBf8LC/logol-1.5.0/build.xml:130: Test > org.irisa.genouest.logol.test.GrammarTest failed > > with no obvious indication why or how. > > Could you please investigate these failures? I plan to so, I need to find a IA64 server to do so. > > Thanks! > > > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679989: [Debian-med-packaging] Bug#679989: Bug#679989: logol: FTBFS on ia64 and sparc with test suite errors
After investigation on ia64, repdocuding the error on anyspacer.logol test, there is a segmentation fault in prolog executable. It occurs in the middle of the treatment. WIth logs we see the seg fault occuring at: write(LogolVAR_Before_2),nl,sleep(1),*SEGFAULT HERE* isexact_pos(LogolVAR_Before_2['c','c','c'],LogolVAR_Errors_2,LogolVAR_After_2),LogolVAR_Indel_2=0,LogolVAR_Spacer_2=0)) Output log for debug: search ccc at 24 Segmentation fault A log in isexact_pos is not shown at seg fault time, meaning call to predicate fails. It occurs always at the same time for this test. If we limit the number of result it works because it never reach the seg fault point. It occurs in the middle of the input file, this is not a end of file case. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685351: [Debian-med-packaging] Bug#685351: Help: Please seek for sources of some JS files in GNUmed [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]
Le 9/6/12 9:53 PM, Andreas Tille a écrit : > Hi Sebastian, > > On Mon, Aug 27, 2012 at 08:20:14PM +0200, Sebastian Hilbert wrote: >>> after reading the bug report twice I noticed that the problem is >>> actually not comparable to the issue discussed currently on >>> debian-devel@l.d.o, because the files are actually used in the >>> package and not replaced. So if you want to help Debian Med you >>> can do some research and find the sources of the following files >>> inside the gnumed-doc package: >>> >>> user-manual/rsrc/System/JSTreeContrib/jquery.jstree.js >> http://www.jstree.com/documentation >> MIT or GPL2 Should be available here: https://github.com/vakata/jstree/tree/v.1.0/dist (there are 2 branches available, should check which branch match) >> >>> user-manual/rsrc/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js >> http://foswiki.org/Extensions/JQueryPlugin >> GPL Could be https://github.com/foswiki/JQueryPlugin/tree/master/pub/System/JQueryPlugin/plugins/foswiki (branch should be checked too) ( >> >>> user-manual/rsrc/System/PatternSkin/pattern.js >> http://trac.foswiki.org/browser/trunk/PatternSkin/lib/Foswiki/Contrib/PatternSkin.pm?rev=14650 >> >> part of PatterSkin >> >> GPL > I tried to check these links. I think it needs some clarification: > There is no real doubt that the code is GPL. The main problem is that > we need to have the source code of the files that were used and which > could be used to reproduce the compressed *.js files. I did not found > those very files which we could include as copy into the package. > >>> user-manual/rsrc/System/JavascriptFiles/foswikiForm.js >> http://www.koders.com/javascript/fid7DAA754986238FA7FE093BDE7031C706AB24FBE2.aspx?s=form#L6 >> >> Apache Version 2 >> >>> user-manual/rsrc/System/JavascriptFiles/foswikiString.js >> http://trac.foswiki.org/browser/trunk/core/pub/System/JavascriptFiles/foswikiString_src.js >> >> GPL >> >>> user-manual/rsrc/System/JavascriptFiles/foswikiPref.js >>> >> http://trac.foswiki.org/browser/trunk/core/pub/System/JavascriptFiles/foswikiPref_src.js >> >> GPL >> >> All files stem from a default install of Foswiki > It seems these *.js files could be fetched from VCS and these are OK. > > In short: If we do not find the real source files of the part above > we should probably remove them from the gnumed-client tarball and > drop the gnumed-doc package (which would be a shame IMHO). > > Kind regards > > Andreas. > > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720776: weird results with perl 5.18
I see a test failing in t/Ontology/IO/obo.t line 47 at is
(scalar(@terms), 5), used to work in a previous perl release:
Code of test:
my $parser = Bio::OntologyIO->new(
-format=> "obo",
^I^I -file => test_input_file('so.obo'));
my $ont = $parser->next_ontology();
ok ($ont);
is ($ont->name(), "sequence");
my @roots = $ont->get_root_terms();
is (scalar(@roots), 1);
is ($roots[0]->name(), "Sequence_Ontology");
is ($roots[0]->identifier(), "SO:000");
my @terms = $ont->get_child_terms($roots[0]);
is (scalar(@terms), 5);
According previous tests, root ontology is correctly found in file (and
code did not changed, it is only perl update).
though only 2 child terms are found (test result) while 5 are in the
file. Seems ontology parsing fail with new release. Upstream at CPAN
successfully build on perl 5.18.0.
Could it be a dependency issue? To be investigated.
--
gpg key id: 4096R/326D8438 (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720776: [Debian-med-packaging] Bug#720776: weird results with perl 5.18
Running several times *perl t/Ontology/IO/obo.t* leads to different results We sometimes have 1 or 6 or 7 failing tests -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720776: weird results with perl 5.18
It appears that: (in obo ontology test) my @terms = $ont->get_child_terms($roots[0]); @terms array order is not always the same. As following tests take first element of array, it explains why sometimes it succeed, sometimes it fails Now I don't know why order is different -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720776: weird results with perl 5.18
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/26/2013 08:54 PM, gregor herrmann wrote: > On Mon, 26 Aug 2013 12:56:16 +0200, olivier.sal...@codeless.fr wrote: > >> As following tests take first element of array, it explains why >> sometimes it succeed, sometimes it fails >> >> Now I don't know why order is different > > Hash randomization: > https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod#Hash-randomization > (The root of quite a few build failures with 5.18) After further research I found this hash random reason. I have added to upstream bug this info. I am looking at how to patch the code to fix this but this needs upstream update. Thanks Olivier > > > > Cheers, > gregor > - -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSHu1tAAoJEHjcaNsybYQ4q+kP/3jugUWX4rr96tJhk+cw9kdp myWSff9P0awMcWCy2mXI8DJKYPYyDmlYhfmW4Ij50PkkA8GrxozpD5cBD1vwu1bi bS5s+H+pxXV1XPuXcQlKGfCrSWAm8Pbaz0CjHaGb4Jy9iWlikuSlgQFxAQ8ygNCT O+FdLbI+YVx8kZ6NvPqm7eo41Lkk69wQd+X7RiV3YQuDkWE2k4IJp4twZ3Of6xR7 V0zYyn2+Lt5KzsJomlcVxi4HSBd76rvqzxnqyRP1xpOBKov9hSA03TKWGfaGLHV9 ZhEVo1ZzG6lfnMKHrWtrNjwR+a9ltbee+lvOgRC2DJkue0WVYLtkVPDUdeFH6g7d a38By/CuWIyq/a8wSJeJNCaOk9j+0/ftyrjnkzUu+GJ+l5lUyGW6Dyg4zWAOH4dO YJp3xqICXjPTE3GpdH35GLG3kWqV9iVwaIxjbhdIx6X0r7Ng/CjHvAkQU2FYr4uH vt3p5rIxEbBq0ZgGt/LCpNGdnE+7EG6NCy1/CSRMjvZmunMs/zw2h+TkXixnfunH ZsibUo6YAZQiH1Bc5rmGu8//KJinx8vyeVM7QdZMfr7h38v3390qxTeJljFpFRLH GAjy+fJ30sg3S46DIWXiNpvGpD6NSu786csHaVsMuhgKXvw+1H27nS+e731oI+d/ mW3lo08pI9kAwZVNeGQ9 =Mexk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726801: biomaj: fails to install with Recommends enabled
On 11/10/2013 03:03 AM, Andreas Beckmann wrote: > I can reproduce this problem in pbuilder using the sid tarball as created by > piuparts and the following commands: > > sudo pbuilder login --basetgz /srv/piuparts/slave/basetgz/sid_amd64.tar.gz > > export DEBIAN_FRONTEND=noninteractive > sed -i /mysql/d /usr/sbin/policy-rc.d > sed -i 's/main/main contrib non-free/' /etc/apt/sources.list > apt-get update > apt-get install --install-recommends biomaj-watcher > > The problem obvioulsy depends on the actual set of packages the are being > installed and starting from a different base may yield a different result. > > On 2013-11-07 00:12, Andreas Beckmann wrote: >>> On 11/05/2013 06:08 PM, gregor herrmann wrote: Oh, and I don't find the lines you quoted above in the log in #726801. >> A new log was on the way to the bug, but got stuck somewhere. Just for info, I pushed biomaj 1.2.3-2 to fix the test in d/config for non-interactive mode (but no impact on java test/setup). > trying again ... here is my analysis of the java dependency cycle > > default-jre is configured before biomaj, so dependency fulfilled > > openjdk-7-jre-headless is configured after default-jre, but > > Package: default-jre > Source: java-common (0.49) > Version: 1:1.7-49 > Depends: default-jre-headless (= 1:1.7-49), openjdk-7-jre (>= 7~u3-2.1.1) > > Package: default-jre-headless > Source: java-common (0.49) > Version: 1:1.7-49 > Depends: openjdk-7-jre-headless (>= 7~u3-2.1.1), java-common > > Package: openjdk-7-jre-headless > Source: openjdk-7 > Version: 7u25-2.3.12-4 > Provides: java-runtime-headless, java2-runtime-headless, > java5-runtime-headless, java6-runtime-headless, java7-runtime-headless > Depends: openjdk-7-jre-lib (= 7u25-2.3.12-4), ca-certificates-java, > tzdata-java, java-common (>= 0.28), libcups2 (>= 1.4.0), liblcms2-2, libjpeg8 > (>= 8c), libnss3 (>= 2:3.13.4), libpcsclite1, libc6 (>= 2.14), libfontconfig1 > (>= 2.10.0), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.1.1), libglib2.0-0 (>= > 2.26.0), libstdc++6 (>= 4.1.1), zlib1g (>= 1:1.1.4) > > Package: java-common > Version: 0.49 > Depends: *nothing* > > Package: openjdk-7-jre-lib > Source: openjdk-7 > Version: 7u25-2.3.12-4 > Depends: openjdk-7-jre-headless (>= 7~b130~pre0) > * first cycle * > > Package: ca-certificates-java > Version: 20130815 > Depends: ca-certificates (>= 20121114), openjdk-6-jre-headless (>= > 6b16-1.6.1-2) | java6-runtime-headless, libnss3 (>= 3.12.10-2~) > * second cycle * > > Package: openjdk-7-jre > Source: openjdk-7 > Version: 7u25-2.3.12-4 > Provides: java-runtime, java2-runtime, java5-runtime, java6-runtime, > java7-runtime > Depends: openjdk-7-jre-headless (= 7u25-2.3.12-4), libasound2 (>= 1.0.16), > libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.2.4), libcups2 (>= > 1.4.0), libfontconfig1 (>= 2.10.0), libfreetype6 (>= 2.2.1), > libgdk-pixbuf2.0-0 (>= 2.22.0), libgif4 (>= 4.1.4), libglib2.0-0 (>= 2.16.0), > libgtk2.0-0 (>= 2.8.0), libjpeg8 (>= 8c), libpango-1.0-0 (>= 1.14.0), > libpangocairo-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libpng12-0 > (>= 1.2.13-4), libpulse0 (>= 0.99.1), libx11-6, libxext6, libxi6, > libxrender1, libxtst6, zlib1g (>= 1:1.1.4), libxrandr2, libxinerama1, > libgl1-mesa-glx | libgl1, libatk-wrapper-java-jni (>= 0.30.4-0ubuntu2) > > > There are bugs in > * java stuff for having circular dependencies > * apt or dpkg for bad handling of this cycle: > if a dependency cycle has to be broken, all packages that depend on a > package in the cycle > but are not part of the cycle itself, have to be configured after *all* > packages in the > cycle have been configured Should we in this case push the bug to the Java team ? This means that all packages needing java in a postinst (there may need be many) should fail this test. Olivier > > Andreas > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749303: hard coded dependencies
Hi, could you specify what you mean by hard-coded dependencies ? Those are specified in control file. Do you mean they should be set in shlibs.local file ? Thanks Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752223: [Debian-med-packaging] Bug#752223: [biomaj-watcher] Some sources are not included in your package
Those sources files are not really "source files" , they are added/generated by GWT, used to build the war file. Those files are not used to build the package, and are regenerated/copied by the build process from GWT. As biomaj-watcher is in contrib, this should not be an issue. I will, however, check if an easy repack of upstream tarball to remove those files from source package is possible. Olivier On 06/21/2014 12:10 PM, Bastien ROUCARIES wrote: > Package: src:biomaj-watcher > Version: 1.2.1-1 > user: debian...@lists.debian.org > usertags: source-is-missing > severity: serious > X-Debbugs-CC: ftpmas...@debian.org > > Hi, > > Your package seems to include some files that lack sources > in prefered forms of modification: > > usr/share/biomaj-watcher/src/war/bmajwatcher/bmajwatcher.nocache.js > (may be included elsewhere) > usr/share/biomaj-watcher/src/war/resources/chart/open-flash-chart.swf > usr/share/biomaj-watcher/src/war/resources/flash/swfobject.js > (may be packaed under debian) > usr/share/biomaj-watcher/src/war/bmajwatcher/sc/modules/ISC_DSBrowser.js > usr/share/biomaj-watcher/src/war/bmajwatcher/sc/modules/ISC_EBay.js > usr/share/biomaj-watcher/src/war/bmajwatcher/sc/modules/ISC_History.js > usr/share/biomaj-watcher/src/war/bmajwatcher/sc/modules/ISC_Kapow.js > (no idea about these 4) > > According to Debian Free Software Guidelines [1] (DFSG) #2: > "The program must include source code, and must allow distribution > in source code as well as compiled form.". > > This could also constitute a license violation for some copyleft > licenses such as the GNU GPL. > > In order to solve this problem, you could: > 1. repack the origin tarball adding the missing source to it. > 2 add the source files to "debian/missing-sources" directory > > Both way satisfies the requirement that we ship the source. Second option > might be preferable due to the following reasons [2]: > - Upstream can do it too and you could even supply a patch to them, > thus full filling our social contract [3], see particularly §2. > - If source and non-source are in different locations, ftpmasters may >miss the source and (needlessly) reject the package. > - The source isn't duplicated in every .diff.gz/.debian.tar.* (though >this only really matters for larger sources). > > You could also ask debian...@lists.debian.org or #debian-qa for more > guidance. > > [1] https://www.debian.org/social_contract.en.html#guidelines > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736873#8 > [3] https://www.debian.org/social_contract > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
