Hi,
after adding a symbols file to libbpp-core all other architectures are
failing due to different symbols (see below for ppc64el[1]) but others
are failing as well. What is the correct way to fix this?
Kind regards
Andreas.
On Fri, Apr 06, 2018 at 11:04:02AM +0200, Julien Yann Dutheil
Hi,
since yesterday packages using cmake are failing. Example: libbpp-core
has build yesterday according to
https://buildd.debian.org/status/package.php?p=libbpp-core
but it fails if I build today in current pbuilder (just not building the
build target). A very similar package libbpp-seq
Hi Bas,
On Fri, Apr 06, 2018 at 02:18:03PM +0200, Sebastiaan Couwenberg wrote:
> On 04/06/2018 02:08 PM, Andreas Tille wrote:
> > after adding a symbols file to libbpp-core all other architectures are
> > failing due to different symbols (see below for ppc64el[1]) but others
ks Cython related from a first look.
>
> Ghis
>
> Le ven. 29 juin 2018 à 11:17, Andreas Tille a écrit :
>
> > Hi Ghislain,
> >
> > since one of the Debian Med packages seems to be affected I tried to
> > upgrade h5py (see Git repository). Unfortunately it d
Hi Tristan,
On Fri, Jun 29, 2018 at 01:31:31PM +0200, Tristan Seligmann wrote:
> This is a cython bug; cython-dbg fails to ship the StringIOTree extension
> module, so the regular non-debug module is found when doing a debug build
> but fails to load.
Are you refering to #902551?
I'd consider
Hi Tristan,
On Fri, Jun 29, 2018 at 02:26:47PM +0200, Tristan Seligmann wrote:
> On Fri, 29 Jun 2018 at 14:20 Andreas Tille wrote:
>
> > Hi Tristan,
> >
> > On Fri, Jun 29, 2018 at 01:31:31PM +0200, Tristan Seligmann wrote:
> > > This is a cython bug; cython-d
Hi,
I'm trying to build the latest version of jellyfish which I pushed to
Salsa[1]. Unfortunately I'm running into
g++ -DHAVE_CONFIG_H -I. -Wall -Wnon-virtual-dtor -I. -I./include -Wdate-time
-D_FORTIFY_SOURCE=2 -Werror -std=c++11 -g -O2
-fdebug-prefix-map=/build/jellyfish-2.2.10=.
Hi,
I intend to upgrade elastix[1] but I'm running into:
...
[100%] Built target itkMevisDicomTiffImageIOTest
make[2]: Leaving directory '/build/elastix-4.9.0/obj-x86_64-linux-gnu'
/usr/bin/cmake -E cmake_progress_start
/build/elastix-4.9.0/obj-x86_64-linux-gnu/CMakeFiles 0
make[1]: Leaving
Hi,
I try to update minia[1] to its latest upstream version but cmake runs into:
CMake Error at CMakeLists.txt:66 (include):
include could not find load file:
GatbCore
However, the build dependency libgatbcore-dev provides the according
cmake input file:
dpkg -L libgatbcore-dev | grep
On Mon, Jan 21, 2019 at 07:58:29PM -, Sune Vuorela wrote:
> On 2019-01-21, Andreas Tille wrote:
> > Is there any way to make cmake more verbose where it is seeking for files
> > to include?
>
> cmake --trace
>
> at least give you more debugging info than you c
On Tue, Dec 04, 2018 at 12:04:36AM +0500, Andrey Rahmatullin wrote:
> On Mon, Dec 03, 2018 at 07:19:52PM +0100, Andreas Tille wrote:
> > I try to build the latest libsbml[1] in Git but I was running
> > into:
> Why do you think it's a problem? It's not.
Since cmake decided to m
Hi,
I try to build the latest libsbml[1] in Git but I was running
into:
cat /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeError.log
Determining if files check.h exist failed with the following output:
Change Dir: /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp
Run Build
Hi Ferenc,
thanks a lot for your helpful hints which solved at least half of
my problem.
On Mon, Dec 03, 2018 at 07:46:30PM +0100, Ferenc Wágner wrote:
> Andreas Tille writes:
>
> > I explicitly added "Build-Depends: libnewlib-dev" und thus there is
> >
> >
Hi,
I'm busy packaging libbasr[1] and try to use the Debian packaged
libhdf5-dev. I managed to take the configure and compile step but if it
comes to the linker the flag -lhdf5_cpp is missing and all symbols of
the hdf5 library are not found. Is there an easy way to sneak this
into a
Hi Sune,
On Thu, Jan 10, 2019 at 06:27:47PM +, Sune Vuorela wrote:
> ...
> I looked briefly at the code, but I didn't feel like actually trying to
> understand what's going on.
Thanks a lot for this detailed analysis. I'll forward it to bug #907624
and the upstream issue[1]. I admit I also
Hi,
as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
and buster. I've tested in stretch (gcc 6.3) and the code works fine.
I've reported upstream[1] the results of my gdb session where I was able
to find the exact code line[2] where the SIGSEGV is thrown. It turns out
Hi,
On Thu, Jan 10, 2019 at 02:14:14AM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> > to find the exact code line[2] where the SIGSEGV is thrown. It turns out
> > that the elements of a structure are not accessible:
> >
Hi Sergio
On Wed, Sep 19, 2018 at 12:50:37AM -0400, Sergio Durigan Junior wrote:
> On Sunday, September 16 2018, Andreas Tille wrote:
>
> > Hi,
> >
> > in the latest version of maude[1] I get:
> >
> > ...
> > g++ -DHAVE_CONFIG_H -I. -I../.. -I../.
Hi,
in the latest version of maude[1] I get:
...
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../src/Utility -I../../src/Temporal
-I../../src/Interface -I../../src/Core -I../../src/Variable
-I../../src/FullCompiler -I../../src/Higher -I../../src/CUI_Theory
-I../../src/S_Theory -I../../src/NA_Theory
Hi,
I'd like to update cimg[1] but the build fails in an unstable
chroot due to an invalid LaTeX file
...
[26] [27]) [28] (./group__cimg__displays.tex) [29] (./group__cimg__storage.tex)
[30] (./group__cimg__files__io.tex) [31] (./group__cimg__options.tex
! Missing } inserted.
Hi,
On Wed, Feb 27, 2019 at 10:02:32AM +0200, Andrius Merkys wrote:
> Hi Samuel,
>
> On 2019-02-26 18:27, Samuel Flores wrote:
> > I would like some help packaging MacroMoleculeBuilder (MMB) for
> > distribution in Debian or Ubuntu. It is a mature piece of code, used to
> > publish many
p://fam-tille.de
>From b0a8a6a14c391fbc40489ab6df984435efaba1c4 Mon Sep 17 00:00:00 2001
From: Andreas Tille
Date: Tue, 12 Feb 2019 16:02:57 +0100
Subject: [PATCH] Fix watch file
---
debian/changelog | 4
debian/watch | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/
Control: tags -1 help moreinfo
Hi,
I really wonder why gatb-core should be missing. According to
tracker[1] gatb-core is in testing and the build logs[2] are specifying
exactly those architectures as successfully installed that you claim
missing (in agreement with discosnp tracker page[3]
On Thu, Feb 14, 2019 at 03:16:22PM +0100, Dominique Dumont wrote:
> On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote:
> > I'm
> > not sure how to deal with the jquery.js one since this is potentially an
> > issue with lots of dependencies - I remember discussions
Hi,
to upgrade package sitplus I need to package libsitplus[1]. I made some
progress to adjust Build-Depends and some cmake patches but I'm now
running into:
CMake Error at
/usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find OpenCV (missing:
Hi,
since I wanted to track down this issue I tried
t_coffee -aln sproteases_small.cw_aln sproteases_small.muscle
sproteases_small.tc_aln -outfile combined_aln.aln
on my usual testing machine. However, when running on sid I get the
reported error:
On Sun, Feb 03, 2019 at 02:48:38PM +0800, Paul Wise wrote:
> of the repository to git and continue from there. You can also skip
> the conversion and just checkout the latest svn revision and continue
> from there.
May be its easier and in the end more sensible to create a Git archive
via
Hi folks,
I'm using gbp successfully in all my packaging projects and it works
perfectly when building in sid. However since some time (about 1-2
months) always if I try to do a backport to stretch git-buildpackage is
creating a wrong upstream source tarball (wrong size and md5sum). This
*only*
regards
Andreas.
On Thu, May 02, 2019 at 10:44:14AM +0500, Andrey Rahmatullin wrote:
> On Thu, May 02, 2019 at 07:40:56AM +0200, Andreas Tille wrote:
> > Hi folks,
> >
> > I'm using gbp successfully in all my packaging projects and it works
> > perfectly when building
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 ...
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
Hi,
I tried to build sga with Python3 (prepared in Git[1]) but the issue
occures also with currently uploaded sga. The configure step fails
with:
...
In file included from /usr/include/c++/9/utility:70,
from /usr/include/c++/9/algorithm:60,
from
On Fri, Sep 06, 2019 at 03:40:18PM +0300, Dmitry Shachnev wrote:
> That is because resource_stream() returns stream in binary mode, not text:
>
> https://setuptools.readthedocs.io/en/latest/pkg_resources.html#basic-resource-access
>
> Try adding .decode('utf-8'):
>
> fields =
parsehash is detected properly?
Kind regards
Andreas.
On Thu, Sep 05, 2019 at 03:52:28PM +0200, Andreas Tille wrote:
> Control: tags -1 help
>
> Hi,
>
> I prepared a Python3 port in Git[1] using 2to3. Unfortunately I get a
> configuration error which seems to be total
Control: tags -1 pending
Hi,
I wanted to upgrade to the latest upstream version in Git[1] where
upstream has changed the build system. Its a bit irritating to use
meson on top of cmake (at least I have never seen this before) and I
think I have added all needed Build-Depends (locally - not
Hi Dmitry,
On Fri, Sep 06, 2019 at 02:28:48PM +0300, Dmitry Shachnev wrote:
> On Fri, Sep 06, 2019 at 01:18:33PM +0200, Andreas Tille wrote:
> > since upstream is currently inactive I tried my best to do the
> > porting of this package in Git[1]. The Python3 port went quite
>
Control: tags -1 help
Hi,
since upstream is currently inactive I tried my best to do the
porting of this package in Git[1]. The Python3 port went quite
smoothly and I have the feeling I made quite some progress with
Qt5 port. However, when I build HEAD from the packaging Git[1]
install the
Hi Helmut,
On Thu, Aug 01, 2019 at 08:12:34AM +0200, Helmut Grohne wrote:
> aevol fails to cross build from source, because it ships a broken,
> outdated, embedded copy of AX_BOOST_BASE. The actual bug #872256 is
> already fixed for a while in autoconf-archive, but aevol happens to ship
> a copy
On Thu, Aug 01, 2019 at 12:17:12PM +0200, Helmut Grohne wrote:
> On Thu, Aug 01, 2019 at 11:14:05AM +0200, Andreas Tille wrote:
> > I have removed m4/ax_boost* in Git[1]. Unfortunately this leaded to
> > some configure errors. I was able to work around
> >
> > 1
On Thu, Nov 14, 2019 at 10:59:43AM +0100, Gudjon I. Gudjonsson wrote:
> Is /etc/ld.so.conf.d/ changed on your machine?
No.
$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
$ cat /etc/ld.so.conf.d/*
/usr/lib/x86_64-linux-gnu/libfakeroot
# libc default configuration
/usr/local/lib
#
Hi Gudjon,
On Thu, Nov 14, 2019 at 08:25:22PM +0100, Gudjon I. Gudjonsson wrote:
> Please answer to the mailing list if it helps.
>
> What is the full output of
> ldd /usr/lib/phantomjs/phantomjs ?
> and
> ldd /usr/lib/x86_64-linux-gnu/libQt5Core.so ?
>
> ldd /usr/lib/phantomjs/phantomjs
>
Hi Gudjon,
> I have tested on my Buster machine and it works perfectly. Both before
> and after upgrade this morning.
>
> I don't have any ideas left but please try to reinstall
> libc6 because it contains
> /lib64/ld-linux-x86-64.so.2
> but I cannot guarantee it will help.
I can confirm that
On Fri, Dec 06, 2019 at 06:24:49PM +0100, Alf Gaida wrote:
> Am 06.12.2019 um 17:37 schrieb Ole Streicher:
> > How should one handle this?
> >
> > Best regards
> >
> > Ole
> >
> Arch dependend symbols are a pain in the ... :D
However, it can be helpful to detect ABI changes that are not
On Mon, Dec 09, 2019 at 11:38:59AM +0100, Mattia Rizzolo wrote:
>
> Are you explicitly specifying -rfakereoot in your dpkg-buildpackage
> options?
Ahhh, I was actually missing this in my gbp-pbuilder script.
Thanks for the hint, Andreas.
--
http://fam-tille.de
Hi,
if I try to use my usual pbuilder setup with a package that is
specifying
Rules-Requires-Root: no
in d/control this ends up with
...
dpkg-buildpackage: error: fakeroot not found, either install the fakeroot
package, specify a command with the -r option, or run this as root
I: copying
On Mon, Dec 09, 2019 at 12:14:30PM +0100, Mattia Rizzolo wrote:
> Uh, sorry for being imprecise. I meant, that you *should not* set that
> option, and let dpkg decide by itself.
OK, In my case dpkg has no choice to decide since the pbuilder
chroot is just lacking fakeroot. I get
...
I:
On Mon, Dec 09, 2019 at 07:27:12PM +0100, Mattia Rizzolo wrote:
> > OK, In my case dpkg has no choice to decide since the pbuilder
> > chroot is just lacking fakeroot. I get
>
> Which is perfectly fine.
So far I agree.
> I now tried and indeed there is no trace of fakeroot usage, as it
Hi again (after long delay),
On Fri, Sep 13, 2019 at 06:55:05PM +0300, Yavor Doganov wrote:
> Andreas Tille wrote:
> > The configure faulure is rather:
> >
> > checking google/sparse_hash_set usability... no
> > checking google/sparse_hash_set presence... yes
>
Hi mentors,
I also have no clue why python-easydev is not migrating to testing.
Unfortunately I always forget whom to ask about this. :-(
Any hint what to do?
Kind regards
Andreas.
On Tue, Nov 19, 2019 at 09:46:11AM +0100, Olivier Sallou wrote:
> Hi,
>
> I uploaded some time ago
On Tue, Nov 19, 2019 at 10:32:48AM +0100, Bas Couwenberg wrote:
> On 2019-11-19 10:25, Andreas Tille wrote:
> > I also have no clue why python-easydev is not migrating to testing.
> > Unfortunately I always forget whom to ask about this. :-(
> >
> > Any hint what t
Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 https://gitlab.com/german.tischler/libmaus2/issues/30
Hi,
I've tried to build the latest upstream version but it also has issues
for 32bit architectures:
g++ -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2
Control: tags -1 help
Hi,
I wonder if there might be some remaining interest in liblemon. The
Debian Med team who introduced it into Debian does not need it any more
for any of its packages. It seems it us orphaned upstream. I'd be
willing to keep the package alive if someone might provide a
On Thu, Nov 14, 2019 at 09:35:20AM +0100, Leopold Palomo-Avellaneda wrote:
> On 14/11/19 9:26, Andreas Tille wrote:
> > $ phantomjs --version
> > /usr/lib/phantomjs/phantomjs: error while loading shared libraries:
> > libQt5Core.so.5: cannot open shared object file: No s
Hi,
as I reported to BTS[1] phantomjs in Buster is failing:
$ phantomjs --version
/usr/lib/phantomjs/phantomjs: error while loading shared libraries:
libQt5Core.so.5: cannot open shared object file: No such file or directory
$ ldd /usr/lib/phantomjs/phantomjs | grep "not found"
On Sat, Oct 05, 2019 at 04:35:54PM +0200, Gudjon I. Gudjonsson wrote:
> Hi list
>
> Is anyone willing to sponsor an upload of comedilib.
> It is needed for the python2 removal (Closes: #936321)
>
> The package can be found at:
>
t doesn't block wxwidgets anymore. Tomorrow I will ask on the
> electronics
> mailing list if I can change the geda-gaf dependency to lepton-eda. It seems
> like no one
> in Debian is interested in geda anymore.
I admit I have no idea about this.
> On Saturday, 5 October 2019 17:
Ahh, just one more note:
I take the freedom to not sponsor any package which uses
something else than short dh.
Kind regards
Andreas.
On Sun, Oct 06, 2019 at 04:49:39PM +0200, Andreas Tille wrote:
> Hi Gudjon,
>
> On Sun, Oct 06, 2019 at 12:42:39PM +0200, Gudjon I. Gudjons
Hi,
I think I was able to hunt down two of the three C++ issues but I'm
stumbling here:
...
[ 90%] Building CXX object src/CMakeFiles/ccs.dir/main/ccs.cpp.o
cd /build/unanimity-3.4.1+git20180307.02aa264+dfsg/build/src && /usr/bin/c++
-I/build/unanimity-3.4.1+git20180307.02aa264+dfsg/include
On Thu, Dec 19, 2019 at 09:24:38AM +, Phil Wyett wrote:
> Basic build clean in a sid pbuilder created using:
>
> sudo pbuilder create --debootstrapopts --variant=buildd
>
> The only failure(s) I see are the post build tests:
I confirm it builds now also here. No idea what happened.
Fixed
Control: tags -1 help
Hi,
On Thu, Sep 05, 2019 at 06:39:33PM +0200, Matthias Klose wrote:
> cd /build/1st/unanimity-3.3.0+dfsg/build/src && /usr/bin/cmake -E
> cmake_link_script CMakeFiles/gcpp.dir/link.txt --verbose=1
> /build/1st/unanimity-3.3.0+dfsg/src/main/ccs.cpp: In function ‘int
>
Control: tags -1 pending
Hi,
I have a problem with latest version of pbbam[1] where upstream switched
to meson as build system. I get:
...
... 'src/25a6634@@pbbam@sha/ vcf_VcfWriter.cpp.o'
'src/25a6634@@pbbam@sha/pugixml_pugixml.cpp.o' -Wl,--as-needed
-Wl,--no-undefined -shared
Hi Matthew,
thanks a lot for all your hints.
On Sun, Jan 12, 2020 at 02:08:56PM -0800, Matthew Fernandez wrote:
>
> > On Jan 12, 2020, at 12:49, Andreas Tille wrote:
> >
> > Hi,
> >
> > I'm wondering how this bug
> >
> >
> > rk1968/rk19
Control: tags -1 help
On Tue, Jan 14, 2020 at 09:48:10PM +0100, Paul Gevers wrote:
> Did not find CMake 'cmake'
> Found CMake: NO
> Run-time dependency pbbam found: NO
>
> meson.build:54:0: ERROR: Could not generate cargs for pbbam:
> Package pbcopper was not found in the pkg-config search path.
Thanks a lot for the very helpful comments, Andreas.
On Mon, Jan 13, 2020 at 07:20:24AM -0800, Matthew Fernandez wrote:
> > I need to admit that I understand so less from all the gcc issues you
> > tried to explain - I do not even have any idea what C++ attributes are.
> > I simply cared for that
Control: tags -1 help
I have fixed Python2->Python3 migration as well as the FTBFS with
pbseqlib 5.3.3+dfsg-1 issue in Git[1]. Unfortunately there is another
build issue in the C++ code which I have no idea how to fix:
...
g++ -g -O2
Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 Andrei Zavada
Hi,
I'm wondering how this bug
rk1968/rk1968.cc: In lambda function:
rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
237 | auto make_error_return = [] ( const char* fmt, ...)
Control: tags -1 help
Hi,
it might be that the new upstream version is targeting only at amd64
(and by chance builds on x32). If there is a hint from porters how to
fix the build the only idea I have is to restrict it to amd64 (and x32).
Kind regards
Andreas.
On Sun, Dec 29, 2019 at
On Sun, Dec 29, 2019 at 07:00:54PM +0100, Michael Crusoe wrote:
> pbcopper's latest release has slipped in a code copy of libssw which uses
> x86 SIMD intrinsics. I've pushed up a fix along the lines I made to libssw
> to enable cross architecture compilation at
>
Control: tags -1 help
[debian-mentors readers please start reading at this mark @debian-mentors]
Hi Steffen,
I'm working on upgrading the Debian package of pynn. While I assume the
latest upstream version of pynn will fix all Python3 migration issues it
also has the new dependency on
Control: tags -1 help
Control: retitle -1 cannot allocate memory in static TLS block
Hi Paul,
On Fri, Mar 13, 2020 at 11:09:31PM +0100, Paul Gevers wrote:
>
> raise RuntimeError(('Could not find drmaa library. Please specify
> its ' +
> RuntimeError: Could not find drmaa library. Please
Hi Matthew,
On Fri, Apr 17, 2020 at 07:40:54AM -0700, Matthew Fernandez wrote:
>
> As a jumping off point, the attached patch fixes some issues with logging
> calls in the upstream 1.2.4 source release.
Thanks for the patch which I applied to packaging Git. I assume you
want to express that
Hi Matthew,
On Fri, Apr 17, 2020 at 08:18:29AM -0700, Matthew Fernandez wrote:
> > Thanks for the patch which I applied to packaging Git. I assume you
> > want to express that while these fixes are definitely good coding
> > practice the bus error problem is not fixed by it, right?
>
> Thanks,
Hi Matthew,
thanks a lot for your detailed investigation.
On Fri, Apr 17, 2020 at 04:28:23PM -0700, Matthew Fernandez wrote:
> > Program received signal SIGBUS, Bus error.
> > 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30,
> > pairdist_type=, bPercID=, istart=0, iend=3,
> >
Hi,
since I did not got any response from r-pkg team yet I guess nobody has
a clue about this autoconf issue. So I'd like to forward this question
here to finalise a package which is relevant for our COVID-19
Biohackathon.
I injected r-bioc-rgadem[1] but the build ends in:
dh_autoreconf
Hi Jeremy,
On Mon, Apr 06, 2020 at 05:34:23PM +0100, Jeremy Sowden wrote:
> On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote:
> >dh_autoreconf -O--buildsystem=R
> > autoheader: warning: missing template: HAVE_OPENMP
> > autoheader: Use AC_DEFINE([HAVE_OPEN
Hi,
the cran package r-cran-gganimate requires r-cran-gifski to run its test
suite. I've prepared the latter in Git[1]. To build the package a rust
compiler is needed which I provided via Build-Depends: cargo. Unfortunately
there will be some Rust modules needed which the build process tries
Hi Matthew,
many thanks again for your investigation.
On Sat, Apr 18, 2020 at 01:15:49PM -0700, Matthew Fernandez wrote:
> > Upstream is in the row of this investigation. Its quite interesting
> > that the issue could also observed on amd64. So probably this is a real
> > issue which is just
On Mon, Apr 06, 2020 at 08:53:12PM +0100, Jeremy Sowden wrote:
> > Thanks a lot for your help anyway
>
> Patch attached.
Thank you so much again, Andreas.
--
http://fam-tille.de
Control: tags -1 help
Hi,
as it can be seen on the recent build log of clustalo on mips[1] the
build fails with
# Run additional test from python-biopython package to verify that
# this will work as well
src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out
temp_test.dnd -o
Hi,
thanks a lot for these helpful hints.
On Mon, Apr 06, 2020 at 08:51:57PM +0100, jnq...@gmail.com wrote:
>
> without looking at any of the packages, at all, you say you're
> unfamiliar with Rust, so perhaps the following hints will be helpful:
> 1. you can use the Rustc compiler (rustc)
e sequence is
configure
build
test
install
Thanks a lot for your contribution anyway
Andreas.
[1] https://med-team.pages.debian.net/policy/
> Am 12.03.20 um 19:50 schrieb Andreas Tille:
> > Control: tags -1 help
> >
> > [debian-mentors readers p
Hi Faidon,
could you imagine to build jemalloc with --disable-initial-exec-tls
as Sergio suggests below to fix the issue in drmaa (and possibly other
packages)?
Should I open a separate bug report against jemalloc to request this?
Kind regards
Andreas.
On Sat, Mar 14, 2020 at 05:18:49PM
Hi Nilesh,
On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote:
>
> >From the logs, in the last message[2] it looks like an import-error for
> '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> provide) package. When I dug into looking at libsbml, I noticed that the
Control: tags -1 help
Hi,
while Nilesh has fixed the MPI-3.0 issue of mpqc in Git[1] the package
does not build any more due to an autoconf issue:
...
configure.in:1802: error: possibly undefined macro: AC_CHECK_CCA
If this token and others are legitimate, please use m4_pattern_allow.
On Sun, Apr 05, 2020 at 12:34:55PM +0100, Jeremy Sowden wrote:
> > > I've attached the part or the build log that seems to be autoconf
> > > relevant. I admit I'm a bit astonished since I can only see
> > > warnings but no error ...
> >
> > Here's a patch that fixes the autoheader warnings.
>
>
On Sun, Apr 05, 2020 at 03:40:56PM +0530, Nilesh Patra wrote:
> > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> > > provide) package. When I dug into looking at libsbml, I noticed that the
> > > relevant file (libsbml.py) which throws error
> > > is generated with
Hi Jeremy,
On Sun, Apr 05, 2020 at 10:14:58AM +0100, Jeremy Sowden wrote:
> > Any help would be appreciated.
> >
> > [1] https://salsa.debian.org/debichem-team/mpqc
>
> Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it (patch
> attached).
Thanks a lot for the promising patch I have
Hi folks,
I have problems to upgrade diamond-aligner[1] to its latest upstream
version and upstream can't reproduce the issue. Sorry, currently I'm
swamped with COVID-19 issues so I'd like to ask here simply for a patch
which is probably not that hard. In pbuilder I get:
...
-- Looking for
On Fri, Mar 27, 2020 at 10:05:05AM -0500, Ryan Pavlik wrote:
>
> Looks like two of the patches were actually applied upstream and can be
> dropped:
>
> - multi_arch
> https://github.com/bbuchfink/diamond/commit/2248fefb362e931ce1cee4d9292efe8d1499f225
> - fix_i386_and_s390x
>
Hi Alex,
On Sat, Mar 28, 2020 at 11:30:04AM +, Alex Dewar wrote:
> I've stuck in a PR to the upstream OpenCFU repository, which should fix
> this issue: https://github.com/qgeissmann/OpenCFU/pull/26
>
> Let me know if this works (or not) for you.
Thanks a lot for your port in OpenCFU to
Hi Matthew,
On Wed, Apr 29, 2020 at 07:14:30AM -0700, Matthew Fernandez wrote:
>
> To add another data point to this discussion, one other (fruitless) thing I
> tried previously was cross-compiling Clustal Omega. From an amd64 host, it’s
> possible to target mipsel using the GCC
On Thu, Apr 30, 2020 at 07:17:50AM -0700, Matthew Fernandez wrote:
>
> Valgrind, in its default mode, checks for a variety of memory issues
> (use-after-free, write out-of bounds, …). You don’t need any special
> configure/build options, but you probably want to enable debug symbols
> (`export
Hi Jeffrey,
thanks a lot for this analysis. Any chance that somebody could
turn this into a patch I could try?
Kind regards
Andreas.
On Thu, Apr 30, 2020 at 03:40:12PM -0400, Jeffrey Walton wrote:
> On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote:
> > ...
> > So i
Hi Matthew,
On Thu, Apr 30, 2020 at 05:53:29PM -0700, Matthew Fernandez wrote:
>
> Is the priority goal here to simply ship a non-crashing clustalo mipsel
> binary that BioPython can depend on? If so, maybe we can just disable
> compiler optimisation (-O0) and this may avoid provoking the bus
Hi,
On Wed, Apr 29, 2020 at 10:30:35AM +0800, 黄佳文 wrote:
> I am a developer from Loongson company (R & D CPU/mip64el), I've been
> looking at this recently.
Very nice to see mips developers to care for biological software. :-)
> I did two experiments, and I found that when I used Python 3,7 to
Hi Matthew,
On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote:
> > Any more help from debian-mipsel is really appreciated.
>
> Hm yes, “--disable-libsanitizer” is rather ominous. I guess the mipsel GCC
> package has been built without ASan support. Surprising that it fails so
>
Hi Adrian,
thanks a lot for your investigation.
On Sun, May 10, 2020 at 11:19:27AM +0300, Adrian Bunk wrote:
> What does fix the problem is disabling OpenMP.
> I suspect OpenMP is somehow broken in gcc >= 8 on mipsel.
I wonder how we could keep this finding to other packages. I bet it
would
On Sun, May 10, 2020 at 03:51:28PM -0400, Jeffrey Walton wrote:
> > I've now uploaded now with this patch closing the bug - but as I tried to
> > express I'd sleep a bit better if this issue would be recorded somewhere
> > else than in a closed bug.
>
> Maybe GCC? I believe the component is
Hi,
On Sun, May 10, 2020 at 08:10:48PM +0300, Adrian Bunk wrote:
> Control: reassign -1 libpbcopper1.3.0 1.4.0+dfsg-1
> Control: affects -1 src:pbbam
> ...
> $ objdump -p /usr/lib/x86_64-linux-gnu/libpbcopper.so.1.6.0 | grep SONAME
> SONAME libpbcopper.so.1.6.0
>
> With this
Hi Adrian,
On Mon, May 11, 2020 at 10:04:24AM +0300, Adrian Bunk wrote:
> A bug buried somewhere in the Debian bts would not change anything.
Probably that's correct.
> What would have to happen would be a Debian MIPS porter debugging
> this problem and then submitting a minimal testcase to gcc
Hi Faidon,
On Tue, Mar 17, 2020 at 01:29:59PM +0200, Faidon Liambotis wrote:
> Hi Andreas,
>
> Thanks for reaching out. It sounds like this is already reported as
> #951704 (Cc'ed now).
OK.
> I'll need to give this a closer look, but I hope I
> can have an update within the next couple of
801 - 900 of 967 matches
Mail list logo
