Package: src:hsail-tools
Version: 0~20180830-1
Severity: serious
Tags: ftbfs trixie sid
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
debian/rules clean
dh clean
Package: src:libabigail
Version: 2.6-2
Severity: serious
Tags: ftbfs trixie sid
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
debian/rules clean
dh clean --build
[ Matthias, please always Cc me on the bugs I report if you talk to me
in your replies ]
[ Trimming Cc list to just gcc-14-cross for simplicity. Still Cc to
ADA people, I'd love to hear from them ].
building sequentially is nice to have, but not a must
What do you mean by "sequentially"? Whet
Package: src:gcc-13-cross
Version: 15
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs trixie sid
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables ex
Package: src:gcc-12-cross
Version: 19
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs trixie sid
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables ex
Package: src:gcc-14-cross
Version: 7
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs trixie sid
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables exp
Package: src:gcc-11-cross
Version: 21
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs trixie sid
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables ex
Package: src:gcc-14-cross-ports
Version: 8
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables exported
Package: src:gcc-14-cross-mipsen
Version: 3+c1
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables expo
Package: src:gcc-12-cross-ports
Version: 17
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables exporte
Package: src:gcc-13-cross-ports
Version: 19
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables exporte
Package: src:gcc-13-cross-mipsen
Version: 4+c1
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables expo
Package: src:gcc-12-cross-mipsen
Version: 5+c1
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables expo
Package: src:gcc-11-cross-ports
Version: 18
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables exporte
Package: src:gcc-11-cross-mipsen
Version: 6+c1+nmu1
User: debian...@lists.debian.org
Usertags: make-4.4
Severity: important
Tags: ftbfs
Dear Maintainer,
This package fails to build from source with Make 4.4.1, most likely because of
changes in $(shell) environment handling: environment variables
0:28.0 +
+++ gcc-14-14.2.0/debian/changelog 2024-08-25 23:31:00.0 +
@@ -1,3 +1,17 @@
+gcc-14 (14.2.0-3+nmu1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * Add debian/patches/ada-make-lang-fix.diff to fix FTBFS problem
+in gcc-*-cross packages.
+
+ -
Version: 0.183-1
Hello. According to my build logs, this is fixed at least in bullseye,
so I'm closing with this message.
Thanks.
reopen 924325
retitle 924325 gcc-8-cross: FTBFS because of Makefile bug: ../../gnatbind: No
such file or directory
notfixed 924325 33+rm
severity 924325 serious
thanks
I'm reopening this bug because packages in stable *must* build in stable.
While it's true that this bug has not happened in the
Package: src:gcc-9-cross-mipsen
Version: 1+c1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in sid but it failed:
[...]
debian/rules build-indep
gcc: 9.2.1-3 / 9.1.0-10cross1
old gcc
Package: src:gcc-defaults
Version: 1.168
Fixed: 1.181
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in stretch and this is what happened:
[...]
debian/rules build-indep
dh_testdir
rm
Package: gcc-8-cross
Version: 28
Dear Matthias:
I see this in debian/rules:
ifeq ($(JOBS),1)
JOBS := 2
endif
This was made in commit a4c6cdfc25368c1c86dfd215db99669f93f1f096
but the changelog does not say anything about it.
I believe this is related to the Makefile bug I reported in #9
I'm sorry that -j1 did not work for you, but this seems to fail every
time if you try in a single-CPU machine.
You can see it fail in real time here:
https://jenkins-1.reliable-builds.org/job/gcc-8-cross/
If trying in a single-CPU machine is a burden for you, please contact
me privately and I wi
On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> Is this seen with gcc-7-cross and gcc-9-cross as well?
Yes, it happened with gcc-7-cross:
https://people.debian.org/~sanvila/build-logs/gcc-7-cross/
and it also happens with gcc-9-cross:
https://people.debian.org/~sanvila/build-
On Sat, Mar 16, 2019 at 05:59:16PM +0100, Matthias Klose wrote:
> On 11.03.19 18:47, Santiago Vila wrote:
> > On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> >
> >> I have no clue, I have never seen that before, and it seems to work fine
> >>
On Mon, Mar 11, 2019 at 06:34:18PM +0100, Matthias Klose wrote:
> I have no clue, I have never seen that before, and it seems to work fine on
> the
> buildds, and in the cross-toolchain-base* package's autopkg test. Starting
> here
> a build with -j1 to see if it's reproducible.
>
> Is this se
Package: src:gcc-8-cross
Version: 26
Tags: ftbfs
Hello Matthias.
I have been unable to build this package for the last 12 months:
Status: failed gcc-8-cross_4_amd64-20180218T093520Z
Status: failed gcc-8-cross_5_amd64-20180224T160324Z
Status: failed gcc-8-cross_6_amd64-20180321T020
Package: src:gcc-python-plugin
Version: 0.17-1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in buster but it failed:
[...]
debian/rules build-indep
dh_testdir
/usr/bin/make -C docs h
Package: src:gcc-8-cross-mipsen
Version: 2~c1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in buster but it failed:
dpkg-buildpackage
-
dpkg-buildpackage: info: sour
On Wed, May 03, 2017 at 01:40:12AM +0200, Matthias Klose wrote:
> > I tried to build this package in stretch with "dpkg-buildpackage -A"
> > but it failed:
>
> fine, but you should make sure that this occurs in a distro environment as
> well.
I always do these test builds using sbuild in a chro
Package: src:gcc-6-cross
Version: 21
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:
[...]
debian/rules build-indep
gcc: 6.3.0-14 / 6.3.0-12cro
Greetings.
Could anybody tell me is this optimization bug on ARM was finally fixed...
* in gcc-4.9 as released with jessie?
* in gcc-6 as the default compiler in stretch?
I ask because I added this workaround to unzip's debian/rules:
ifeq ($(DEB_HOST_ARCH),armhf)
CFLAGS := DEB_CFLAGS_STRIP=-O
Sorry, did not see the part about internal compiler error in the buld log
itself. Still amazed that you can be so sure that it's hardware related when he
is using virtual machines.
Thanks.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, Dec 03, 2016 at 10:08:33AM +0100, Lucas Nussbaum wrote:
> Just for the record: I can still reproduce this failure.
Then, IMHO, you should reopen the bug.
I bet it's a Makefile bug related to parallel building, because my
autobuilders are single-CPU and I also have this in my .sbuilrc fi
On Wed, Nov 23, 2016 at 12:26:18AM +0100, Matthias Klose wrote:
> > What would be the right package for a bug in one of GCC Makefiles, then?
> >
> > What if Lucas was able to reproduce this in two different machines and
> > the failure and the error message was the same? Would you discard
> > "fi
On Sat, 19 Nov 2016, Matthias Klose wrote:
> > It's unlikely a hardware problem because the build was made in a
> > virtual machine and the build was tried twice. This is written
> > in the bug report itself.
> >
> > This is a lot more likely to be a bug which happens randomly,
> > for example, a
On Sat, 19 Nov 2016, Matthias Klose wrote:
> On 19.11.2016 07:40, Lucas Nussbaum wrote:
> > Source: gcc-5
> > Version: 5.4.1-3
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20161118 qa-ftbfs
> > Justification: FTBFS on amd64
> >
> > Hi,
>
On Thu, 4 Aug 2016, Santiago Vila wrote:
> In particular, the size of "lto1" went from 20 MB to 144 MB.
> Is this really normal/expected?
Hmm, lto1 was stripped in GCC 5 (stretch) and now it's unstripped again
(sid, GCC 6). Is this intended or accidental?
Thanks.
Hello Matthias.
With GCC 6 as the default, the size of a minimal build system has grown
by about 150 MB.
In particular, the size of "lto1" went from 20 MB to 144 MB.
Is this really normal/expected?
While we are at it, this bug is marked as "forwarded". Are there any
news from the upstream mainta
Package: src:gcc-5-cross-ports
Version: 9
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
patching file sr
Package: src:gcc-5-cross
Version: 23
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
patching file src/lto
Thanks a lot, Andreas, for looking at this!
Would you take a look at this one?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818872
It's apparently the "same" bug, so most likely the fix for #818873
would also work for #818872 as well.
Thanks.
On Fri, Apr 22, 2016 at 12:22:33AM +0200, Matthias Klose wrote:
> On 22.04.2016 00:11, Santiago Vila wrote:
> >The problem with that is that it breaks the expectation that testing
> >is in an "always releaseable" state.
> >
> >Sure, the file /etc/debian_versio
On Thu, 30 Apr 2015, Matthias Klose wrote:
> On 04/30/2015 10:43 PM, Daniel Serpell wrote:
> > Currently, gcc-5 packages are really big because the files under
> > /usr/lib/gcc/x86_64-linux-gnu/5 are not stripped, and each one of
> > lto1, cc1 and cc1plus is about 130MB.
> >
> > Please, can those
On Mon, Mar 21, 2016 at 09:02:48AM +, Santiago Vila wrote:
> Package: src:gcc-5-cross-ports
> Version: 7
For the record: Version 3 was ok (in case it helps).
[ I usually build every version as they reach testing, but this package
was excluded on purpose because it was too big. I have
On Mon, Mar 21, 2016 at 08:56:27PM +0100, Matthias Klose wrote:
> Control: tags -1 + help
>
> On 21.03.2016 10:02, Santiago Vila wrote:
> >I tried to build this package with "dpkg-buildpackage -A"
> >(i.e. only architecture-independent packages), and it failed:
&g
Package: src:gcc-5-cross-ports
Version: 7
User: sanv...@debian.org
Usertags: binary-indep
Severity: important
Dear maintainer:
I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:
-
Package: src:gcc-5-cross
Version: 20
User: sanv...@debian.org
Usertags: binary-indep
Severity: important
Dear maintainer:
I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:
--
severity 764732 serious
thanks
On Fri, 10 Oct 2014, Hector Oron wrote:
> Package: gcc-4.9
> Version: 4.9.1-16
> Severity: important
>
> Hello,
>
> Found a FTBFS while trying to build unzip package in Debian/sid on armhf
> host.
>
> [...]
Yesterday, I uploaded unzip 6.0-13 fixing several se
Hello.
Latest m4 FTBFS on several architectures, for different reasons.
On hppa, it seems to trigger a gcc bug:
gcc -std=gnu99 -g -Wall -O2 -o test-fpurge test-fpurge.o libtests.a
../lib/libm4.a libtests.a
collect2: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char
*) &
On Sun, 14 Aug 2005, Marco d'Itri wrote:
> Package: gcc-4.0
> Version: 4.0.0-12
> Severity: important
>
> Compiling tin 1.7.10+20050727 on m68k fails.
>
> gcc -DHAVE_CONFIG_H -I. -I../include -I/usr/include
> -DLOCALEDIR=\"/usr/share/locale\" -I../include -DUSE_CANLOCK -D_GNU_SOURCE
> -g -O
On Wed, 4 May 2005, Michael Banck wrote:
> On Mon, May 02, 2005 at 06:09:04PM +0200, Matthias Klose wrote:
>
> Anyway, back to the gcc-3.4 build log:
>
> > ./xgcc -B./ -B/usr/i586-gnu/bin/ -isystem /usr/i586-gnu/include
> > -isystem /usr/i586-gnu/sys-include
> > -L/build/mbanck/gcc-3.4-3.4.3
retitle 302995 fastjar: postinst does not check for errors
reassign 302995 fastjar
severity 302995 serious
thanks
I hope it works now. See http://bugs.debian.org/302995
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
retitle 302995 fastjar: postinst does not check for errors
reassign 302995 fastjar
severity 302995 serious
thanks
On Mon, 4 Apr 2005, Scott James Remnant wrote:
> On Mon, 2005-04-04 at 02:13 +0200, Santiago Vila wrote:
>
> > On Sun, 3 Apr 2005, Blars Blarson wrote:
> >
>
On Fri, 9 Jan 2004, Matthias Klose wrote:
> reassign 225039 pine
> thanks
>
> It's not a bug. By default it is trying to build 64-bit, so it isn't
> working.
>
> Either prepend "sparc32" to the command, or touch /etc/disable_64_gcc.
I don't fully understand, could you please elaborate?
Why shoul
On 5 Feb 2002, Stephen Zander wrote:
> >>>>> "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:
> Santiago> What about the other java compilers? It is true, for
> Santiago> example, that for each architecture that will be
> Santia
> > For example, would "Build-Depends: gcj" be acceptable?
>
> gcj only works on i386, powerpc, m68k, sparc, s390, alpha and ia64.
Hmm, do you mean it does not work on arm, hppa, mips and mipsel?
Is this considered a release-critical bug?
What about the other java compilers? It is true, for examp
Matthias Klose wrote:
> Santiago Vila writes:
> > Is there any particular reason why gcj does not set up a symlink
> > javac -> gcj using the alternatives mechanism, as jikes used to do before
> > Bug #43730 was reported?
>
> an alternative should only be provided,
Hello.
Is there any particular reason why gcj does not set up a symlink
javac -> gcj using the alternatives mechanism, as jikes used to do before
Bug #43730 was reported?
( The new gettext-0.11 checks for a java compiler named "javac" but it
does not find "gcj". I'm not sure who exactly to blam
58 matches
Mail list logo
