On Sun, Jul 28, 2024 at 7:47 AM Drew Parsons wrote:
>
> On 2024-07-25 12:35, Drew Parsons wrote:
> > Given the timing of the test failure, my guess is that uid-wrapper is a
> > casuality of the time_64 transition. It looks like something is amiss
> > with the __NR_gettimeofday system calls on 32-
On Thu, Dec 1, 2022 at 1:15 AM Andreas Tille wrote:
>
> Hi,
>
> Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers:
> > Source: r-cran-glmmtmb
> > Version: 1.1.4+dfsg-3
> > Severity: serious
> > Tags: ftbfs
> > Justification: ftbfs
> >
> > Dear maintainer(s),
> >
> > Your package failed
On Tue, Aug 23, 2022 at 4:40 PM Simon McVittie wrote:
>
> Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786623
> Control: affects -1 + src:mozjs102
>
> On Tue, 23 Aug 2022 at 13:23:30 +0100, Simon McVittie wrote:
> > The final link fails with multiple definitions of the vario
Hi Everyone,
The patch to work around the failed compile is located at
https://github.com/weidai11/cryptopp/issues/1094#issuecomment-1035656572
. The patch is against Crypto++ 8.6.
The patch was tested in a Debian Unstable QEMU/Chroot for armel and
armhf. It tested Ok.
The changes in the diff wi
Hi Everyone,
I think this is a GCC or Debian bug. Here is my reasoning.
Developers are responsible to declare the ISA they are using through
options. In our case, we are using armv4 and armv7, so we let the
compiler know via -march=armv7-a. That's where a developer's
responsibility ends. We are n
I opened this for the GCC folks:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455. I'm not sure if
they are aware things no longer work.
Jeff
Hi Everyone,
My apologies for the late reply.
SL > There are various ways to reconcile this incompatibility between
SL > build options, but given this is armhf which is guaranteed to have
SL > floating-point support, I think the simplest may be as in the
SL > attached patch, which adjusts to usin
On Wed, Jan 19, 2022 at 4:08 PM John Paul Adrian Glaubitz
wrote:
>
> Unfortunately, glibc no longer builds with this change on powerpc and ppc64
> and kernel builds still fails on both targets:
>
> > https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=powerpc&ver=2.33-3&stamp=1642542048&raw=
On Sat, Feb 27, 2021 at 1:21 PM Bernhard Übelacker
wrote:
>
> I have retried with the patch in #974828, but it still
> crashed with the test files from this bug, therefore
> I guess #974828 is similar but unrelated.
>
> Then I took another look at the valgrind runs and found
> that these invalid r
On Fri, May 1, 2020 at 3:05 AM Jeffrey Walton wrote:
>
> On Fri, May 1, 2020 at 2:14 AM Andreas Tille wrote:
> >
> > ...
> > ==13209== Process terminating with default action of signal 10 (SIGBUS)
> > ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346
On Fri, May 1, 2020 at 2:14 AM Andreas Tille wrote:
>
> ...
> ==13209== Process terminating with default action of signal 10 (SIGBUS)
> ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
> ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835)
> ==13209==by 0x11A6C4: Align (clu
On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote:
> ...
> So it seems the bus error occures somehow here:
>
>
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346
NewProgress is at
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/prog
On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote:
>
> Control: tags -1 help
>
> 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/test
On Thu, Apr 30, 2020 at 10:33 AM Matthew Fernandez
wrote:
>
> > On Apr 30, 2020, at 00:31, Andreas Tille wrote:
> >
> > On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote:
> >
> >> The other option I suggested was Valgrind, but if you can’t run apt-file
> >> you probably can’t ins
Package: valgrind
Version: 1:3.12.0~svn20160714-1+b1
Severity: serious
Tags: upstream
Justification: 4
Dear Maintainer,
* What led up to the situation?
valgrind ./myprog
* What exactly did you do (or not do) that was effective (or
ineffective)?
Looks like an upstream bu
> Sadly, it turns out armhf fails to build due to one test taking a bit
> too much memory[1], and there is an RC bug open for that: #852959[2].
>
> So now I don't know what to do, except asking for removal of prometheus
> from armhf.
As a stopgap, you might consider adding a small swapfile and set
16 matches
Mail list logo
