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
>
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,
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:
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
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,
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
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
-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
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();
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
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
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
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.
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
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
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
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
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*
18 matches
Mail list logo
