Hi Graham,
I've uploaded a change that (hopefully!) fixes the issue.
On Mon, Mar 01, 2021 at 08:24:09AM +0200, Graham Inggs wrote:
> The recent upload of dh-r causes autopkgtests using pkg-r-autopkgtest
> to fail. See for example the output of r-bioc-affy [1] below.
> Presumably caused by this
Hi,
any update to this bug?
If we do not find a timely solution what do you think about excluding
s390x temporarily from the list of architectures of this package and set
this bug to "important"?
I would not be happy about this but the issue creates some autoremoval
warnings on other packages
Control: tags -1 upstream
Control: forwarded -1 https://github.com/OpenMS/OpenMS/issues/5151
Hi Filippo,
this is extremely unfortunate. However, I guess the alternative would
have been to keep some RC buggy seqan-dev which would not have helped
openms as well. I tried the same as Peter and replaced the
Build-Depends seqan-dev by libseqan2-dev.
I can confirm the observation from Peter
Control: tags -1 upstream
Control: forwarded -1 assafgor...@gmail.com
Control: severity -1 important
Hi Assaf,
as you can read in a recent bug report in Debian[1] datamash fails for
some architectures (namely the Debian release architectures armel, armhf
and mipsel) its build time test in some
Hi folks,
I think this is a consequence of running autopkgtest-pkg-r blindly for all
bioc packages since we are adding
Testsuite: autopkgtest-pkg-r
automatically to all packages. The "manual" test is prevented by simply
renaming the debian/tests/control file to
Hi Joshua,
On Fri, Feb 12, 2021 at 01:03:23PM -0500, Joshua N Pritikin wrote:
> > I submitted a new release to CRAN yesterday. It usually takes a few days
> > to correct any lingering issues and get it approved.
>
> CRAN peeps said that v2.19.1 is accepted. I know the package info page
> isn't
On Sun, Feb 14, 2021 at 11:38:35PM -0500, Yaroslav Halchenko wrote:
> failed to arrive with working minimal patch against that elderly 1.2.1
>
> FWIW built current snapshot which seems to be ok. but I am reluctant to
> upload that one since it has breaking (we have no rev-depends though in
>
Control: severity -1 important
Control: tags -1 moreinfo
Control: tags -1 unreproducible
On Sat, Feb 13, 2021 at 06:12:12PM +0100, Lucas Nussbaum wrote:
> Source: gemma
> Version: 0.98.4+dfsg-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags:
Hi Yaroslav,
could you please have a look. I'm occupied by many other things and will not
care for this one.
Kind regards
Andreas.
- Forwarded message from Debian testing autoremoval watch
-
Date: Sun, 14 Feb 2021 04:39:04 +
From: Debian testing autoremoval watch
To:
Hi Kevin,
On Wed, Feb 10, 2021 at 11:20:38AM -0800, Kevin Ushey wrote:
> Perhaps I'm misunderstanding, but there is a Debian patch for RcppParallel
> here:
>
> https://sources.debian.org/patches/r-cran-rcppparallel/5.0.2+dfsg-3/use_debian_packaged_libtbb.patch/
>
> and all that does is force
Hi Bastian,
On Wed, Feb 10, 2021 at 06:55:57PM +0100, Bastian Blank wrote:
> Control: retitle -2 r-cran-rcppparallel: generates broken load path for
> libtbb and fails on several architectures
Thanks a lot for the bug report including explanation and patch.
> - r-cran-rcppparallel trying to
Control: tags -1 help
Aaron (or whoever might want to check), do you have any idea?
Kind regards
Andreas.
--
http://fam-tille.de
On Mon, Feb 08, 2021 at 10:43:00PM +0200, Adrian Bunk wrote:
> Control: tags -1 patch fixed-upstream
>
> ...
> Attached are the relevant parts from the upstream fix.
Thanks. Uploaded.
> After that, it is worth trying whether this fixed python-cobra.
Python-cobra builds nicely now.
Control: tags -1 help
Hi Pierre,
do you have some idea how to fix this?
Kind regards
- Forwarded message from Adrian Bunk -
Date: Sat, 06 Feb 2021 17:55:20 +0200
From: Adrian Bunk
To: Debian Bug Tracking System
Subject: Bug#982111: r-cran-rcdk: autopkgtest failure
On Sat, Feb 06, 2021 at 01:23:26PM +0100, Étienne Mollier wrote:
> I would be inclined to vote for a removal on that
> architecture.
Fully ACK!
Just go for it. Thanks a lot for caring
Andreas.
--
http://fam-tille.de
Control: tags -1 help
On Thu, Feb 04, 2021 at 12:44:46PM +0200, Adrian Bunk wrote:
> ══ Failed tests
>
> ── Error (test_annotateTargets.R:2:1): (code run outside of `test_that()`)
> ─
> Error: there is no package called
Control: tags -1 help
Hi,
I have updated Git[1] to the latest upstream version to potentially
solve this issue. Unfortunately the build stops with:
...
copying cloud_sptheme/ext/static/auto_redirect.html_t ->
Control: tags -1 upstream
Control: forwarded -1 https://github.com/pyglet/pyglet/issues/346
Hi,
I have opened an issue on Github about this issue. It persists for
the latest upstream version 1.5.14 as well.
Kind regards
Andreas.
--
http://fam-tille.de
Hi Étienne,
On Wed, Jan 27, 2021 at 07:58:51PM +0100, Étienne Mollier wrote:
>
> Your guess is right; setting the PYTHONPATH to the build
> directory allows most tests to run. There were a couple of
> tests which then still failed to execute with the following
> symptom though:
>
>
Control: tags -1 upstream
Control: forwarded -1 Bioconductor Package Maintainer
Hi,
the Debian packaged ShortRead is tested in CI test on different hardware
architectures. On the debci page[1] you can see the matrix for success
and failure which shows that amd64 and i386 are passing the
Control: tags -1 moreinfo, unreproducible
Control: severity -1 important
Hi Lucas,
I've build r-cran-rstan in a clean chroot and it builds nicely as
expected. May be the issue you observed has vanished?
Could you please re-check whether I'm missing something? I've
set severity to important
On Mon, Jan 25, 2021 at 04:51:18PM +0200, Adrian Bunk wrote:
> this bug report is from 24 Dec, so the breakage was not caused by the
> libsbml 5.19 upgrade.
>
> python-cobra seems to have been broken by Python 3.8 -> 3.9
Yes, but it seems cobra 0.20 is broken by libsbml 5.19 which is no
real
Hi Adrian,
On Mon, Jan 25, 2021 at 12:07:27AM +0200, Adrian Bunk wrote:
> > __ ERROR at setup of TestManipulation.test_escape_ids
> > __
> >
> > filename = '/usr/lib/python3/dist-packages/cobra/test/data/textbook.xml.gz'
> > number =
> > f_replace = {'F_GENE': ,
> >
Hi,
thanks to Nilesh and ftpmaster finally the needed dependencies for
q2-feature-classifier are available. Unfortunately when I tried to
build the package there where some test failures in autopkgtest:
...
test session starts ==
platform
Hi Michael,
On Fri, Jan 22, 2021 at 10:32:29AM +0100, Michael R. Crusoe wrote:
> FYI: Seqan 1 is no longer supported upstream, and the only package in Debian
> that uses it is also no longer available/maintained.
if there are no rdepends of seqan1 any more feel free to file a ROM bug.
Kind
Control: severity -1 important
On Thu, Jan 21, 2021 at 10:49:20PM +0100, Étienne Mollier wrote:
> Control: tag -1 moreinfo
> Control: tag -1 unreproducible
> ...
> Anyone else is able to reproduce the problem ?
The package builds nicely in my pbuilder chroot as well. So I'm
setting severity
Hi Graham,
so what is you suggestion? Simply droping the test is possibly
not the best solution. Marking it flaky comes to mind. What
do you think?
Kind regards
Andreas.
On Thu, Jan 21, 2021 at 10:52:49AM +0200, Graham Inggs wrote:
> Source: r-bioc-geoquery
> Version: 2.58.0+dfsg-1
>
Dear Juhani,
On Fri, Jan 15, 2021 at 11:51:05AM +0200, Juhani Numminen wrote:
> >
> > make[3]: Entering directory '/<>/common'
> > libtool --mode=compile -Wdate-time -D_FORTIFY_SOURCE=2 -c
> > src/RcsbPlatform.C -o
Hi,
I was just looking into a rdepends of numba which does not build
currently. Did anybody yet had a look into version 0.52.0 of
numba whether it solves the current issues?
Kind regards
Andreas.
--
http://fam-tille.de
Control: tags -1 help
Control: tags -1 - pending
Hi,
there is a remaining build time test issue which I reported upstream:
https://github.com/lbcb-sci/racon/issues/50
I have no idea how to fix this since gdb does not really give a good
hint about the SIGSEGV that occures.
Kind regards
Control: tags -1 - upstream
Hi,
upstream has released a Python3 version of macsyfinder which I pushed to
Git[1]. When trying to build I get a strange error:
dh_auto_install -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py install --root
Hi Alex,
On Mon, Jan 11, 2021 at 02:48:50PM +0100, Alex Mestiashvili wrote:
>
> No, I didn't correct this specific issue. Just added the new symbols from
> the new release. However a patch or a list of "all" symbols is very welcome.
I'd like to repeat my suggestion to move that package to a
ere you can see what architectures are running the build time test
successfully (and which not):
https://buildd.debian.org/status/package.php?p=parsinsert
Hope this is answering your question.
Kind regards
Andreas.
> On Thu, Jan 7, 2021 at 9:43 AM Andreas Tille wrote:
>
> >
Control: tags -1 upstream
Control: tags -1 help
Control: forwarded -1 David Knox
Hi David,
there is a bug[1] report filed against the Debian packaged version of
ParsInsert. The full build log for ppc64el can be found here[2]. The
problem is also present for other architectures like
Hi Alex,
did you possibly by chance forgot to close #969597 in
your latest upload of libzstd 1.4.8+dfsg-1 ?
Kind regards
Andreas.
--
http://fam-tille.de
Hi Yaroslav,
shouldn't this bug be closed now?
Kind regards
Andreas.
--
http://fam-tille.de
Control: severity -1 important
The failing test is skiped in the latest upload which not really
fixes the bug but enables building and testing the package.
Control: tags -1 upstream
Control: forwarded -1 https://github.com/bioperl/Bio-DB-EMBL/issues/2
Control: tags -1 upstream
Control: forwarded -1
https://github.com/NeurodataWithoutBorders/pynwb/issues/1329
Control: retitle -1 Reactivate test for gdcm which was excluded due to failure
Control: severity -1 important
This single test prevented testing migration of this package and all
its dependencies. Thus the test was deactivated for the moment to
enable building the package. But the issue should
On Fri, Dec 18, 2020 at 04:44:04PM +0100, John Paul Adrian Glaubitz wrote:
> >
> > so it does not fit with our policy: do not hide problems ;)
Well, we do not need to *hide* the problem. We can exclude the test and
*document* the problem - say in a README.Debian on the affected
architecture.
On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote:
> On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> > to:
> >
> > dpkg-shlibdeps: error: cannot find library
On Fri, Dec 18, 2020 at 03:41:58PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/18/20 3:19 PM, Andreas Tille wrote:
> > I wonder whether we could get some help from PowerPC team to solve this
> > issue. If we can not get that test working I see only two options:
>
at 15:53, Andreas Tille wrote:
>
> > Control: tags -1 help
> >
> > Hi,
> >
> > I tried to fix the issue by making dh_shlibdeps work. In
> >
> >
> > https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6
welcome.
Kind regards
Andreas.
- Forwarded message from Matt Newville -
Date: Fri, 18 Dec 2020 05:35:01 -0800
From: Matt Newville
To: lmfit/lmfit-py
Cc: Andreas Tille , Author
Subject: Re: [lmfit/lmfit-py] Test failure on ppc64el (#692)
This is a duplicate of #686. Personally
Control: tags -1 help
Hi,
I tried to fix the issue by making dh_shlibdeps work. In
https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6
I documented what I tried but all failed and I think the key to this bug
is just making it work.
Any idea?
Kind
Control: tags -1 upstream
Control: forwarded -1 https://github.com/lmfit/lmfit-py/issues/692
Hi Joshua,
On Thu, Dec 17, 2020 at 08:59:39AM -0500, Joshua N Pritikin wrote:
> Yeah, that sounds like a good solution. I don't anticipate a lot of
> demand for OpenMx on 32bit arm. I believe we already have 64bit arm
> working. We'll try to get a new release out soon.
That's very helpful.
On Thu, Dec 17, 2020 at 09:45:30AM +, PICCA Frederic-Emmanuel wrote:
> I just built ghmm by removing --with-gsl.
>
> It seems that the gsl implementation of blas conflict with the one provided
> in atlas.
> so --enable-gsl + --enable-atlas seems wrong...
Works, uploaded, thanks a lot,
Hi Joshua,
On Tue, Oct 06, 2020 at 10:59:18AM -0400, Joshua N Pritikin wrote:
> On Tue, Oct 06, 2020 at 04:07:59PM +0200, Andreas Tille wrote:
> > While I could include this as a patch I wonder whether you plan to do a
> > new release featuring this patch in the next
Control: reasign -1 ftp.debian.org
As the bug reporter stated the package is useless and should be
removed from Debian
Kind regards
Andreas.
--
http://fam-tille.de
Control: retitle -1 [ROM] hyantesite: Please remove hyantesite since Uploader
seems not active any more and several attempts to fix FTBFS issues have failed
Control: reassign -1 ftp.debian.org
Hi ftpmasters,
as the bug log shows several people who failed to fix FTBFS issues in
this package have
Hi again,
any more hints how we finally can build ghmm?
Kind regards
Andreas.
On Sat, Dec 05, 2020 at 04:52:14PM +0100, Andreas Tille wrote:
> Hi Dirk,
>
> thanks for the hint but simply using gsl as is was done in this package
> and now it does not build any more. Howe
Hi again,
sorry, I intended to respond to bug #977473 as well which really should
be dealt with,
Kind regards
Andreas.
On Tue, Dec 15, 2020 at 06:09:08PM +0100, Andreas Tille wrote:
> Hi Steve and Gert,
>
> besides bug #977120 which is tagged patch insighttoolkit4 should be
Control: tags -1 moreinfo
Hi Adrian,
On Tue, Dec 08, 2020 at 12:12:31PM +, Debian Bug Tracking System wrote:
> Please contact me if you need assistance.
I think I need assistance. The Auto-Building page[1] shows green for
all, amd64 and arm64 and
Hi Shayan,
did you had some reasons to add this hardcoded dependency?
Kind regards
Andreas.
On Sun, Dec 13, 2020 at 10:15:44PM +0200, Graham Inggs wrote:
> Source: shasta
> Version: 0.6.0-4
> Severity: serious
> Tags: ftbfs
>
> Hi Maintainer
>
> Binary package shasta has a hardcoded
Hi Frédéric
On Fri, Dec 11, 2020 at 09:59:03AM +0100, Frédéric Bonnard wrote:
> Here is a patch based on this :
> https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
>
> Tested on a power machine (where the build failed) and it seems to work.
Thanks a lot
Andreas.
Hi Mathieu,
On Thu, Dec 10, 2020 at 11:10:17AM +0100, Mathieu Malaterre wrote:
> "make -j160"
>
> that would be my guess :)
This sounds pretty likely, thought. Thanks for the hint.
> remove parallel from the dh option, and try again (fixes symptoms)
To cure the real issue rather than the
On Thu, Dec 10, 2020 at 11:58:23AM +0100, Paul Gevers wrote:
> > In the kmc case I'm seriously wondering whether we should restrict
> > the architectures to those that are relevant in practice. It seems
> > to be in line with upstream and I'm tempted to follow Étienne's
> > suggestion to upgrade
Hi Paul,
just a general question: The general overview page like
https://ci.debian.net/packages/k/kmc/
does not seem to be updated while the specific architecture
pages like
https://ci.debian.net/packages/k/kmc/testing/armhf/
shows the issue. I remember I was asking in connection with
Control: tags -1 help
Hi,
I tried to investigate the situation below and my guess is that lex has
somehow problems to create the missing header files. I've found the
files in upstreams .gitignore file so these need to be created but this
does not seem to work on ppc64el (any more - since the
Control: tags -1 confirmed
Control: tags -1 help
Hi,
I can reproduce the issue but unfortunately I have no idea how to
solve this.
Kind regards
Andreas.
--
http://fam-tille.de
Control: forwarded -1 https://github.com/nipy/nipy/issues/466
On Tue, Dec 08, 2020 at 11:11:27PM +0500, Andrey Rahmatullin wrote:
> https://github.com/nipy/nipy/issues/461
As far as I can see that's included into 0.4.3~rc1. Yaroslav, would
you mind commenting on this? It would be great to have some kind of
0.4.3~rc2 to get nipy fixed.
Kind regards
Control: severity -1 important
Control: tags -1 confirmed
> This package only builds Arch:all binary packages. ...
Thus I'm decreasing its severity.
I was able to reproduce the issue on my pinebook64 and will try to
forward the issue upstream.
Kind regards
Andreas.
--
Control: tags -1 pending
Control: tags -1 help
Hi,
I've updated nipy Git[1] to version 0.4.3~rc1 which solves the
originally reported issue. However, there are some remaining failures
in the build time test:
...
==
ERROR:
Control: tags -1 pending
Control: tags -1 help
On Mon, Dec 07, 2020 at 11:24:34PM +0200, Adrian Bunk wrote:
> ...
> #set -e; for v in 3.9; do
> set -e; for v in 3.8; do \
> PATH=$PATH:/<>/debian/mypy/usr/bin/ python$v -m pytest -n
> auto \
> -o testpaths=mypy/test -o
Control: tags -1 help
Control: tags -1 upstream
Control: forwarded https://github.com/hdmf-dev/hdmf/issues/494
Hi,
On Tue, Dec 08, 2020 at 04:21:01AM +0800, Drew Parsons wrote:
> First thing to try would be building against vtk9, which Anton recently
> released for us.
Thanks for the hint but switching to vtk9 leads to cmake errors:
-- The imported target "vtkgdcmsharpglue" references the file
Hi,
vmtk is using Python3 in Git[1], but there are build issues with vtk7:
...
cd /build/vmtk-1.4.0+dfsg/obj-x86_64-linux-gnu/vtkVmtk/ComputationalGeometry &&
/usr/bin/c++ -DITK_IO_FACTORY_REGISTER_MANAGER
-DvtkvmtkComputationalGeometry_EXPORTS -I/build/vmtk-1.4.0+
Control: tags -1 pending
Hi Nilesh,
I've finally fixed shasta in 48e257cd5d5ee64fc095214830e284b016cd83fa
(admittedly I don't like that manual solution bit at least it works
for the default Python3 version now) and that build worked for me
until I pulled your change
Control: tags -1 help
Hi,
I need to admit that I have no idea why this error occures on arm64.
Any hint would be welcome
Andreas.
On Sat, Dec 05, 2020 at 01:21:43PM +0100, Lucas Nussbaum wrote:
> Source: libhmsbeagle
> Version: 3.1.2+dfsg-8
> Severity: serious
> Justification: FTBFS on
Control: tags -1 help
Hi,
I wonder why
static_cast(c) < 256
triggers a "error: comparison is always true due to limited range of data type
[-Werror=type-limits]"
only on arm64 but not on amd64.
Any hint how to fix this bug would be welcome.
Kind regards
Andreas.
On Sat, Dec 05,
Control: tags -1 help
Hi Lucas,
On Sat, Dec 05, 2020 at 01:15:52PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
I admit I have currently no chance to test on arm64 but the package
builds
12:09, Andreas Tille wrote:
> | this issue is something for our advent calendar. Anybody with cblas
> | knowledge?
>
> I am the GNU GSL maintainer, and I at one point also worked a lot with the
> Atlas and other LAPACK/BLAS packages. I think Mo may be wrong here: I did the
> same app
Hi folks,
this issue is something for our advent calendar. Anybody with cblas
knowledge?
Kind regards
Andreas.
On Mon, Jan 27, 2020 at 10:55:25AM +0100, Andreas Tille wrote:
> Hi again,
>
> with my last mail I wanted to express: H, to stupid to turn
> this hint in
Hi Étienne,
On Fri, Dec 04, 2020 at 09:56:20PM +0100, Étienne Mollier wrote:
> I think I'm on a trail with bioperl-run, and could fix a couple
> of issues already. I'm however unsure it might make it for the
> 4th of the advent calendar: fixing the initial issue pulls in
> gradually more tests,
Hi Tony,
On Fri, Dec 04, 2020 at 12:52:07PM -0800, tony mancill wrote:
> Hi Debian-Med, hi Steffen:
>
> I grabbed this bug to fix the QPainterPath include and noticed that
> packaging of 36.0 is underway on the master branch. I have updated the
> debian/patches to apply against this new
Control: tags -1 pending
Control: tags -1 help
Hi,
while the original issue of this bug report is fixed by adding the
missing libfile-sort-perl dependency it has a new build time error
in t/BEDTools.t.
Any help to fix this is welcome
Andreas.
--
http://fam-tille.de
Control: reopen -1
Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 David Knox
Hi David,
as you can see in the Debian bug the Build logs for mips64el[1] and
others[2] the build time tests for parsinsert are failing. From my
naive perspective its basically a matter of
Control: block -1 by 962717
Control: block -1 by 932050
Control: tags -1 help
Hi,
I upgraded q2-quality-filter to the latest upstream version in Git. The
build time tests were disabled as for other QIIME modules that need
registering in QIIME which is not possible at build time. However, also
the autopkgtest fails with:
autopkgtest [13:08:01]:
On Wed, Dec 02, 2020 at 01:50:55PM +0100, Étienne Mollier wrote:
> Synchronizing work on q2-* modules update, I think I'm on a good
> trail for q2cli.
Great! Andreas.
--
http://fam-tille.de
Control: tags -1 help
Hi,
no idea why this was not catched in the usual gcc-10 rebuilds. Any volunteer?
Kind regards
Andreas.
On Wed, Dec 02, 2020 at 12:08:32AM +0100, Andreas Tille wrote:
> Source: rnahybrid
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
>
>
Source: rnahybrid
Severity: serious
Tags: ftbfs
Justification: FTBFS
Hi,
I tried to rebuild the package but the build ends in:
...
gcc -g -O2 -fdebug-prefix-map=/build/rnahybrid-2.1.2=. -fstack-protector-strong
-Wformat -Werror=format-security -g -O2
Control: tags -1 help
Hi,
the build log says:
...
> ==
> FAIL: test_link_h5py_dataset_h5dataio_input
> (tests.unit.test_io_hdf5_h5tools.H5IOTest)
> --
>
Control: retitle -1 [ROM] Please remove predictprotein
Control: reassign -1 ftp.debian.org
Hi ftpmaster,
the code is not maintained upstream any more and relies on a feature of
Perl that was deprecated several versions ago. The Debian Med team
consulted Debian Perl team for help but it has
Control: tags -1 pending
Hi,
upstream of fis-gtm package[1] confirmed that the build needs some root
permissions. Thus I've set
Rules-Requires-Root: yes
When trying to build with pbuilder I get:
dh_testroot
dh_testroot: error: Package needs targeted root but builder has not provided a
t;
> Thanks,
> Amul
>
> -Original Message-
> From: Andreas Tille
> Sent: Monday, November 30, 2020 3:40 PM
> To: 957206-mainto...@bugs.debian.org; Shah, Amul
> Subject: EXTERNAL: Re: Bug#957206: New upstream version available (Was:
> Bug#957206: fis-gtm: f
Hi again Amul,
I updated Git to the next upstream version. It also does not build
successfully. We *really* should fix this *right* now. Otherwise
fis-gtm will be not released with the next stable release.
Kind regards
Andreas.
On Thu, Oct 01, 2020 at 03:52:01PM +0200, Andreas Tille
Control: tags -1 pending
Hi,
since some time falcon[1] in Git builds with some cheating - some test
errors are simply ignored. Also the autopktest is failing. It would be
great if someone would spent time on these two RC bugs in an advent
calendar attempt.
Kind regards
Andreas.
[1]
Control: tag -1 pending
Hello,
Bug #905206 in profnet reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tags -1 help
Hi,
the configure step checks for the existence of opencv and only if
available builds the executable limereg. I found a (hackish) solution
in Git[1] to convince configure that opencv is available. However, the
code tries to include cv.h which is not available any more.
Control: tags 972074 pending
Control: block 972074 by 963392
On Thu, Nov 19, 2020 at 07:53:06AM -0600, Dirk Eddelbuettel wrote:
> |
> | I do not have the slightest idea what this might mean.
>
> ABI/API slippage in the stack. An interface changed but a package didn't
> recompile.
It seems it
Control: tags -1 help
Hi, since version 0.7.0 (uploaded by Dylan Aïssi in CC) the autopkgtest
of r-cran-bayestestr fails with the error mentioned in the bug log. It
has slightly changed with the version I pushed to Git. It is now:
> library(bayestestR)
>
> if
Control: retitle -1 [ROM] Please remove src:biosig4c++ from unstable since it
was replaced by biosig
Control: reassign -1 ftp.debian.org
On Fri, Nov 13, 2020 at 10:21:54AM +0200, Graham Inggs wrote:
> On Fri, 13 Nov 2020 at 09:45, Aurelien Jarno wrote:
> > Version check failed:
> > Your upload
n 11/14/20 11:08 PM, Adrian Bunk wrote:
> > On Sat, Nov 14, 2020 at 09:28:53PM +0100, Andreas Tille wrote:
> > > Control: tags -1 pending
> > > Control: tags 922571 pending
> > >
> > > Hi,
> > >
> > > I have moved sigviewer to Debian Med tea
Control: tags -1 pending
Control: tags 922571 pending
Hi,
I have moved sigviewer to Debian Med team[1], fixed the other bug and
tried to build the new upstream version 0.6.4 but failed:
...
g++ -c -pipe -g -O2 -fdebug-prefix-map=/build/sigviewer-0.6.4=.
-fstack-protector-strong -Wformat
Hi Gianfranco,
thanks a lot for the fix (I had some race condition with another
way to fix it but your's is fine as well) and specifically to also
fix #974570.
I'll upload once my local build has finished.
Kind regards
Andreas.
On Thu, Nov 12, 2020 at 01:23:51PM +0100, Gianfranco
601 - 700 of 2989 matches
Mail list logo
