gcc: Internal error compiling lilypond on hppa
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gcc-4.0 (Debian) |
Fix Released
|
Unknown
|
|||
gcc-4.0 (Ubuntu) |
Invalid
|
High
|
Matthias Klose |
Bug Description
Automatically imported from Debian bug report #335286 http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#1 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#2 |
retitle 335286 gcc: Internal error compiling lilypond on hppa,arm
thanks
reports the same problem on arm.
It can be confirmed *not* to happen on powerpc and alpha.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#3 |
reassign 335286 lilypond
thanks
On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
> See:
> http::/
> Severity serious because this creates an FTBFS situation for lilypond.
Sorry, this is a known bug in gcc that isn't going to be fixed upstream
until 4.1, and that's still a ways out. As a workaround, please update
lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
doesn't suffer from this particular bug.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#4 |
reassign 335286 gcc-4.0
thanks
Steve Langasek <email address hidden> writes:
> reassign 335286 lilypond
> thanks
>
> On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
>
>> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
>
>> See:
>> http::/
>
>> Severity serious because this creates an FTBFS situation for lilypond.
>
> Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> until 4.1, and that's still a ways out. As a workaround, please update
> lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> doesn't suffer from this particular bug.
How do you know that this is a known bug without knowing what the bug
is? It does not match the other hppa compilation bug reported, which
manifests itself in incorrect code instead of compilation errors, and
which is hppa-specific, while this one appears on arm too.
Can you give me a pointer to your reasons for leaping to the
conclusion that a bug you haven't examined must be a known bug?
Moreover, this bug should remain filed against gcc-4.0, because it is,
in fact, a bug in gcc 4.0. There is a *separate* bug filed against
lilypond referring to this one. This bug should remain open and filed
against gcc-4.0 until a fix is uploaded for Debian.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #5 |
Automatically imported from Debian bug report #335286 http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #6 |
Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 20:49:17 -0700
From: Thomas Bushnell BSG <email address hidden>
To: <email address hidden>
Subject: gcc: Internal error compiling lilypond on hppa
Package: gcc-4.0
Version: 4.0.2-2
Severity: serious
Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
See:
http::/
Severity serious because this creates an FTBFS situation for lilypond.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#7 |
severity 335286 important
merge 335286 323133
thanks
On Sat, Oct 22, 2005 at 09:59:30PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > reassign 335286 lilypond
> > thanks
> > On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
> >> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
> >> See:
> >> http::/
> >> Severity serious because this creates an FTBFS situation for lilypond.
> > Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> > until 4.1, and that's still a ways out. As a workaround, please update
> > lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> > doesn't suffer from this particular bug.
> How do you know that this is a known bug without knowing what the bug
> is? It does not match the other hppa compilation bug reported, which
> manifests itself in incorrect code instead of compilation errors, and
> which is hppa-specific, while this one appears on arm too.
> Can you give me a pointer to your reasons for leaping to the
> conclusion that a bug you haven't examined must be a known bug?
Can you give me a pointer to your reasons for leaping to the conclusion that
I haven't examined the bug?
global-context.cc: In member function 'Moment Global_
global-
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:
This is the single most common build failure on arm, hppa, and m68k right
now, and has affected literally dozens or hundreds of other packages. I
do kinda know it on sight by this point.
> Moreover, this bug should remain filed against gcc-4.0, because it is,
> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> lilypond referring to this one. This bug should remain open and filed
> against gcc-4.0 until a fix is uploaded for Debian.
That's fine; I had reassigned it to lilypond before I received the mail that
you had filed a separate bug there. But this is a duplicate of 323133, so
merging. It also is not a release-critical bug because there is a valid
workaround for all affected packages, and in spite of the sizeable impact
it's non-trivial to fix and has been triaged out of necessity.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #8 |
Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:38:50 -0700
From: Thomas Bushnell BSG <email address hidden>
To: <email address hidden>
Subject: arm too
retitle 335286 gcc: Internal error compiling lilypond on hppa,arm
thanks
reports the same problem on arm.
It can be confirmed *not* to happen on powerpc and alpha.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #9 |
Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:37:15 -0700
From: Thomas Bushnell BSG <email address hidden>
To: <email address hidden>
Subject: block it!
block 335287 by 335286
thanks
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#10 |
Steve Langasek <email address hidden> writes:
> This is the single most common build failure on arm, hppa, and m68k right
> now, and has affected literally dozens or hundreds of other packages. I
> do kinda know it on sight by this point.
>
>> Moreover, this bug should remain filed against gcc-4.0, because it is,
>> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
>> lilypond referring to this one. This bug should remain open and filed
>> against gcc-4.0 until a fix is uploaded for Debian.
>
> That's fine; I had reassigned it to lilypond before I received the mail that
> you had filed a separate bug there. But this is a duplicate of 323133, so
> merging. It also is not a release-critical bug because there is a valid
> workaround for all affected packages, and in spite of the sizeable impact
> it's non-trivial to fix and has been triaged out of necessity.
I find it ludicrous to think that the best solution here is to force a
jillion maintainers to workaround the bug and recompile.
I recall not too recently that you thought hacking version numbers was
an acceptible solution, but I guess that's when your package was the
one that was being asked to have a workaround.
Hrm, seriously though, why not backport the fix (though the upstream
bug record doesn't seem to show one yet, while the Debian bug record
says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
arm, hppa, and m68k?
I see no necessity for "triaging" the bug; this is an excellent reason
simply not to have gcc-4.0 in the archive on the affect archs.
Certainly it should not be in testing!
Surely this is a canonical example of a release-critical toolchain
bug?
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #11 |
Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:53:22 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>, <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reassign 335286 lilypond
thanks
On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
> See:
> http::/
hppa&stamp=
> Severity serious because this creates an FTBFS situation for lilypond.
Sorry, this is a known bug in gcc that isn't going to be fixed upstream
until 4.1, and that's still a ways out. As a workaround, please update
lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
doesn't suffer from this particular bug.
Thanks,
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--LQksG6bCIzRHxTLp
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDWxdCKN6
qziqeCXlhZLZ0fU
=JV6q
-----END PGP SIGNATURE-----
--LQksG6bCIzRHx
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #12 |
Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:59:30 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
reassign 335286 gcc-4.0
thanks
Steve Langasek <email address hidden> writes:
> reassign 335286 lilypond
> thanks
>
> On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
>
>> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
>
>> See:
>> http::/
>
>> Severity serious because this creates an FTBFS situation for lilypond.
>
> Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> until 4.1, and that's still a ways out. As a workaround, please update
> lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> doesn't suffer from this particular bug.
How do you know that this is a known bug without knowing what the bug
is? It does not match the other hppa compilation bug reported, which
manifests itself in incorrect code instead of compilation errors, and
which is hppa-specific, while this one appears on arm too.
Can you give me a pointer to your reasons for leaping to the
conclusion that a bug you haven't examined must be a known bug?
Moreover, this bug should remain filed against gcc-4.0, because it is,
in fact, a bug in gcc 4.0. There is a *separate* bug filed against
lilypond referring to this one. This bug should remain open and filed
against gcc-4.0 until a fix is uploaded for Debian.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#13 |
# Automatically generated email from bts, devscripts version 2.9.8
reassign 335286 g++-4.0
forwarded 335287 http://
block 326224 with 355286
block 335287 with 323133
merge 323133 355286
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#14 |
# Automatically generated email from bts, devscripts version 2.9.8
block 326224 with 335286
merge 323133 335286
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#15 |
# Automatically generated email from bts, devscripts version 2.9.8
forwarded 335286 http://
notforwarded 335287
merge 323133 335286
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #16 |
Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 23:08:52 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
--BwCQnh7xodEAoBMC
Content-Type: text/plain; charset=us-ascii
Content-
Content-
severity 335286 important
merge 335286 323133
thanks
On Sat, Oct 22, 2005 at 09:59:30PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > reassign 335286 lilypond
> > thanks
> > On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
> >> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
> >> See:
> >> http::/
=3Dhppa&
> >> Severity serious because this creates an FTBFS situation for lilypond.
> > Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> > until 4.1, and that's still a ways out. As a workaround, please update
> > lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> > doesn't suffer from this particular bug.
> How do you know that this is a known bug without knowing what the bug
> is? It does not match the other hppa compilation bug reported, which
> manifests itself in incorrect code instead of compilation errors, and
> which is hppa-specific, while this one appears on arm too.
> Can you give me a pointer to your reasons for leaping to the
> conclusion that a bug you haven't examined must be a known bug?
Can you give me a pointer to your reasons for leaping to the conclusion that
I haven't examined the bug?
global-context.cc: In member function 'Moment Global_
4Global_
global-
bjcp-common.c:101
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:
This is the single most common build failure on arm, hppa, and m68k right
now, and has affected literally dozens or hundreds of other packages. I
do kinda know it on sight by this point.
> Moreover, this bug should remain filed against gcc-4.0, because it is,
> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> lilypond referring to this one. This bug should remain open and filed
> against gcc-4.0 until a fix is uploaded for Debian.
That's fine; I had reassigned it to lilypond before I received the mail that
you had filed a separate bug there. But this is a duplicate of 323133, so
merging. It also is not a release-critical bug because there is a valid
workaround for all affected packages, and in spite of the sizeable impact
it's non-trivial to fix and has been triaged out of necessity.
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #17 |
Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 23:18:00 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
Steve Langasek <email address hidden> writes:
> This is the single most common build failure on arm, hppa, and m68k right
> now, and has affected literally dozens or hundreds of other packages. I
> do kinda know it on sight by this point.
>
>> Moreover, this bug should remain filed against gcc-4.0, because it is,
>> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
>> lilypond referring to this one. This bug should remain open and filed
>> against gcc-4.0 until a fix is uploaded for Debian.
>
> That's fine; I had reassigned it to lilypond before I received the mail that
> you had filed a separate bug there. But this is a duplicate of 323133, so
> merging. It also is not a release-critical bug because there is a valid
> workaround for all affected packages, and in spite of the sizeable impact
> it's non-trivial to fix and has been triaged out of necessity.
I find it ludicrous to think that the best solution here is to force a
jillion maintainers to workaround the bug and recompile.
I recall not too recently that you thought hacking version numbers was
an acceptible solution, but I guess that's when your package was the
one that was being asked to have a workaround.
Hrm, seriously though, why not backport the fix (though the upstream
bug record doesn't seem to show one yet, while the Debian bug record
says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
arm, hppa, and m68k?
I see no necessity for "triaging" the bug; this is an excellent reason
simply not to have gcc-4.0 in the archive on the affect archs.
Certainly it should not be in testing!
Surely this is a canonical example of a release-critical toolchain
bug?
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Matt Zimmerman (mdz) wrote : | #18 |
hppa-specific, closing
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#19 |
On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > This is the single most common build failure on arm, hppa, and m68k right
> > now, and has affected literally dozens or hundreds of other packages. I
> > do kinda know it on sight by this point.
> >> Moreover, this bug should remain filed against gcc-4.0, because it is,
> >> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> >> lilypond referring to this one. This bug should remain open and filed
> >> against gcc-4.0 until a fix is uploaded for Debian.
> > That's fine; I had reassigned it to lilypond before I received the mail that
> > you had filed a separate bug there. But this is a duplicate of 323133, so
> > merging. It also is not a release-critical bug because there is a valid
> > workaround for all affected packages, and in spite of the sizeable impact
> > it's non-trivial to fix and has been triaged out of necessity.
> I find it ludicrous to think that the best solution here is to force a
> jillion maintainers to workaround the bug and recompile.
I would be happy to see a patch submitted for g++-4.0 that makes it work
correctly on arm/hppa/m68k so that we can stop having maintainers do
busywork. But the busywork can be distributed across the affected
maintainers, and backporting a gcc patch cannot. If you feel up to the task
of providing a backport to fix this bug, I would certainly be grateful. At
any rate, when the decision was made to start building packages with g++-3.4
on these archs, there was no fix yet upstream for the problem.
> I recall not too recently that you thought hacking version numbers was
> an acceptible solution, but I guess that's when your package was the
> one that was being asked to have a workaround.
I'm sorry, but there's a big difference between have a library package
change its name in a critical transition period for reasons that don't match
today's best practices, and having to make a decision between a number of
unpleasant options in order to keep three of our ports in the game building
packages. I don't consider the solution arrived at for gdk-imlib a
"workaround", I consider it the only viable mode for maintaining the large
number of interconnected library packages we have today.
> Hrm, seriously though, why not backport the fix (though the upstream
> bug record doesn't seem to show one yet, while the Debian bug record
> says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> arm, hppa, and m68k?
If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
the best option, I'm game. One disadvantage is that it wouldn't let us get
feedback about what else might be wrong with g++-4.0 on those architectures,
but we probably already have all the information we're going to get about
the current round of toolchain packages.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #20 |
Message-Id: <email address hidden>
Date: Sun, 23 Oct 2005 00:20:24 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: reassign 335286 to g++-4.0,
bug 335287 is forwarded to http://
# Automatically generated email from bts, devscripts version 2.9.8
reassign 335286 g++-4.0
forwarded 335287 http://
block 326224 with 355286
block 335287 with 323133
merge 323133 355286
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #21 |
Message-Id: <email address hidden>
Date: Sun, 23 Oct 2005 00:41:39 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: block 326224 with 335286, merging 323133 335286
# Automatically generated email from bts, devscripts version 2.9.8
block 326224 with 335286
merge 323133 335286
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #22 |
Message-Id: <email address hidden>
Date: Sun, 23 Oct 2005 00:42:13 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: bug 335286 is forwarded to http://
# Automatically generated email from bts, devscripts version 2.9.8
forwarded 335286 http://
notforwarded 335287
merge 323133 335286
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #23 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 01:39:00 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
--X0cz4bGbQuRbxrVl
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > This is the single most common build failure on arm, hppa, and m68k rig=
ht
> > now, and has affected literally dozens or hundreds of other packages. I
> > do kinda know it on sight by this point.
> >> Moreover, this bug should remain filed against gcc-4.0, because it is,
> >> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> >> lilypond referring to this one. This bug should remain open and filed
> >> against gcc-4.0 until a fix is uploaded for Debian.
> > That's fine; I had reassigned it to lilypond before I received the mail=
that
> > you had filed a separate bug there. But this is a duplicate of 323133,=
so
> > merging. It also is not a release-critical bug because there is a valid
> > workaround for all affected packages, and in spite of the sizeable impa=
ct
> > it's non-trivial to fix and has been triaged out of necessity.
> I find it ludicrous to think that the best solution here is to force a
> jillion maintainers to workaround the bug and recompile.
I would be happy to see a patch submitted for g++-4.0 that makes it work
correctly on arm/hppa/m68k so that we can stop having maintainers do
busywork. But the busywork can be distributed across the affected
maintainers, and backporting a gcc patch cannot. If you feel up to the task
of providing a backport to fix this bug, I would certainly be grateful. At
any rate, when the decision was made to start building packages with g++-3.4
on these archs, there was no fix yet upstream for the problem.
> I recall not too recently that you thought hacking version numbers was
> an acceptible solution, but I guess that's when your package was the
> one that was being asked to have a workaround. =20
I'm sorry, but there's a big difference between have a library package
change its name in a critical transition period for reasons that don't match
today's best practices, and having to make a decision between a number of
unpleasant options in order to keep three of our ports in the game building
packages. I don't consider the solution arrived at for gdk-imlib a
"workaround", I consider it the only viable mode for maintaining the large
number of interconnected library packages we have today.
> Hrm, seriously though, why not backport the fix (though the upstream
> bug record doesn't seem to show one yet, while the Debian bug record
> says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> arm, hppa, and m68k?
If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
the best option, I'm game. One disadvantage is that it wouldn't let us get
feedback about what else might be wrong with g++-4.0 on those architectures,
bu...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#24 |
tags 335286 - fixed-upstream
tags 335286 + help
thanks
Steve Langasek writes:
> On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> > I find it ludicrous to think that the best solution here is to force a
> > jillion maintainers to workaround the bug and recompile.
>
> I would be happy to see a patch submitted for g++-4.0 that makes it work
> correctly on arm/hppa/m68k so that we can stop having maintainers do
> busywork. But the busywork can be distributed across the affected
> maintainers, and backporting a gcc patch cannot. If you feel up to the task
> of providing a backport to fix this bug, I would certainly be grateful. At
> any rate, when the decision was made to start building packages with g++-3.4
> on these archs, there was no fix yet upstream for the problem.
unfortunately this one turned out not to be fixed upstream (or it
reappeared).
> > Hrm, seriously though, why not backport the fix (though the upstream
> > bug record doesn't seem to show one yet, while the Debian bug record
> > says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> > arm, hppa, and m68k?
>
> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.
And we will see other things turning up, which are fixed in 4.0, but
not in 3.4. 3.4 was never really used on any of our
architectures. For the switch to 4.0, all port maintainers were asked
about the new default, so let at least ask them again, if they agree
going back to 3.4 (or forward to 4.1).
Matthias
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #25 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 12:24:08 +0200
From: Matthias Klose <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Cc: Thomas Bushnell BSG <email address hidden>, <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
tags 335286 - fixed-upstream
tags 335286 + help
thanks
Steve Langasek writes:
> On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> > I find it ludicrous to think that the best solution here is to force a
> > jillion maintainers to workaround the bug and recompile.
>
> I would be happy to see a patch submitted for g++-4.0 that makes it work
> correctly on arm/hppa/m68k so that we can stop having maintainers do
> busywork. But the busywork can be distributed across the affected
> maintainers, and backporting a gcc patch cannot. If you feel up to the task
> of providing a backport to fix this bug, I would certainly be grateful. At
> any rate, when the decision was made to start building packages with g++-3.4
> on these archs, there was no fix yet upstream for the problem.
unfortunately this one turned out not to be fixed upstream (or it
reappeared).
> > Hrm, seriously though, why not backport the fix (though the upstream
> > bug record doesn't seem to show one yet, while the Debian bug record
> > says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> > arm, hppa, and m68k?
>
> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.
And we will see other things turning up, which are fixed in 4.0, but
not in 3.4. 3.4 was never really used on any of our
architectures. For the switch to 4.0, all port maintainers were asked
about the new default, so let at least ask them again, if they agree
going back to 3.4 (or forward to 4.1).
Matthias
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#26 |
Steve Langasek <email address hidden> writes:
> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.
The point I'm making is that it's a *release critical* bug. The
relevant gcc should not be in testing on those archs.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#27 |
Thomas Bushnell BSG writes:
> Steve Langasek <email address hidden> writes:
>
> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> > feedback about what else might be wrong with g++-4.0 on those architectures,
> > but we probably already have all the information we're going to get about
> > the current round of toolchain packages.
>
> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs.
ahh, ok. so you did check that defaulting to g++-3.4 on these archs
doesn't reveal another RC bug and we should remove g++-3.4 on these
archs as well?
Matthias
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#28 |
Matthias Klose <email address hidden> writes:
> Thomas Bushnell BSG writes:
>> Steve Langasek <email address hidden> writes:
>>
>> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
>> > the best option, I'm game. One disadvantage is that it wouldn't let us get
>> > feedback about what else might be wrong with g++-4.0 on those architectures,
>> > but we probably already have all the information we're going to get about
>> > the current round of toolchain packages.
>>
>> The point I'm making is that it's a *release critical* bug. The
>> relevant gcc should not be in testing on those archs.
>
> ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> doesn't reveal another RC bug and we should remove g++-3.4 on these
> archs as well?
Nope, did you when you told me to downgrade my package to use g++-3.4?
I mean, you can't simultaneously tell all the developers to use
g++-3.4, and then insist that it's not well enough tested to use.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#29 |
Thomas Bushnell BSG writes:
> Matthias Klose <email address hidden> writes:
>
> > Thomas Bushnell BSG writes:
> >> Steve Langasek <email address hidden> writes:
> >>
> >> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> >> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> >> > feedback about what else might be wrong with g++-4.0 on those architectures,
> >> > but we probably already have all the information we're going to get about
> >> > the current round of toolchain packages.
> >>
> >> The point I'm making is that it's a *release critical* bug. The
> >> relevant gcc should not be in testing on those archs.
> >
> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> > doesn't reveal another RC bug and we should remove g++-3.4 on these
> > archs as well?
>
> Nope, did you when you told me to downgrade my package to use g++-3.4?
>
> I mean, you can't simultaneously tell all the developers to use
> g++-3.4, and then insist that it's not well enough tested to use.
I didn't say that. packages which are affected by this bug should
selectively use g++-3.4.
Matthias
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#30 |
Matthias Klose <email address hidden> writes:
>> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
>> > doesn't reveal another RC bug and we should remove g++-3.4 on these
>> > archs as well?
>>
>> Nope, did you when you told me to downgrade my package to use g++-3.4?
>>
>> I mean, you can't simultaneously tell all the developers to use
>> g++-3.4, and then insist that it's not well enough tested to use.
>
> I didn't say that. packages which are affected by this bug should
> selectively use g++-3.4.
It would suck if both g++-3.4 and g++-4.0 had deal-breaker bugs,
wouldn't it? But if that were so, surely it would be true that both
were, in fact, release critical bugs.
I mean, the bug doesn't stop being release critical against g++-4.0
just because we don't know if some other bugs exist in g++-3.4.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #31 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 12:41:18 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
Steve Langasek <email address hidden> writes:
> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.
The point I'm making is that it's a *release critical* bug. The
relevant gcc should not be in testing on those archs.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #32 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 21:57:37 +0200
From: Matthias Klose <email address hidden>
To: Thomas Bushnell BSG <email address hidden>, <email address hidden>
Cc: Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
Thomas Bushnell BSG writes:
> Steve Langasek <email address hidden> writes:
>
> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> > feedback about what else might be wrong with g++-4.0 on those architectures,
> > but we probably already have all the information we're going to get about
> > the current round of toolchain packages.
>
> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs.
ahh, ok. so you did check that defaulting to g++-3.4 on these archs
doesn't reveal another RC bug and we should remove g++-3.4 on these
archs as well?
Matthias
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #33 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 13:09:57 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
Matthias Klose <email address hidden> writes:
> Thomas Bushnell BSG writes:
>> Steve Langasek <email address hidden> writes:
>>
>> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
>> > the best option, I'm game. One disadvantage is that it wouldn't let us get
>> > feedback about what else might be wrong with g++-4.0 on those architectures,
>> > but we probably already have all the information we're going to get about
>> > the current round of toolchain packages.
>>
>> The point I'm making is that it's a *release critical* bug. The
>> relevant gcc should not be in testing on those archs.
>
> ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> doesn't reveal another RC bug and we should remove g++-3.4 on these
> archs as well?
Nope, did you when you told me to downgrade my package to use g++-3.4?
I mean, you can't simultaneously tell all the developers to use
g++-3.4, and then insist that it's not well enough tested to use.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #34 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 22:13:03 +0200
From: Matthias Klose <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>, Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
Thomas Bushnell BSG writes:
> Matthias Klose <email address hidden> writes:
>
> > Thomas Bushnell BSG writes:
> >> Steve Langasek <email address hidden> writes:
> >>
> >> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> >> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> >> > feedback about what else might be wrong with g++-4.0 on those architectures,
> >> > but we probably already have all the information we're going to get about
> >> > the current round of toolchain packages.
> >>
> >> The point I'm making is that it's a *release critical* bug. The
> >> relevant gcc should not be in testing on those archs.
> >
> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> > doesn't reveal another RC bug and we should remove g++-3.4 on these
> > archs as well?
>
> Nope, did you when you told me to downgrade my package to use g++-3.4?
>
> I mean, you can't simultaneously tell all the developers to use
> g++-3.4, and then insist that it's not well enough tested to use.
I didn't say that. packages which are affected by this bug should
selectively use g++-3.4.
Matthias
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #35 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 13:32:05 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
Matthias Klose <email address hidden> writes:
>> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
>> > doesn't reveal another RC bug and we should remove g++-3.4 on these
>> > archs as well?
>>
>> Nope, did you when you told me to downgrade my package to use g++-3.4?
>>
>> I mean, you can't simultaneously tell all the developers to use
>> g++-3.4, and then insist that it's not well enough tested to use.
>
> I didn't say that. packages which are affected by this bug should
> selectively use g++-3.4.
It would suck if both g++-3.4 and g++-4.0 had deal-breaker bugs,
wouldn't it? But if that were so, surely it would be true that both
were, in fact, release critical bugs.
I mean, the bug doesn't stop being release critical against g++-4.0
just because we don't know if some other bugs exist in g++-3.4.
Thomas
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#36 |
On Sun, Oct 23, 2005 at 12:41:18PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> > feedback about what else might be wrong with g++-4.0 on those architectures,
> > but we probably already have all the information we're going to get about
> > the current round of toolchain packages.
> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs.
It's not. The bug doesn't cause data loss; it's not a security bug; it
doesn't render the package unuseable or mostly so. It renders the package
unuseable for a particular set of affected software, but it is not *mostly*
unuseable because *most* C++ packages still build fine g++-4.0 in spite of
this error. I also doubt that we've ever shipped a toolchain that had *no*
ICEs, and dropping back to g++-3.4 certainly doesn't buy us that either.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #37 |
Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 17:05:18 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa
--Q68bSM7Ycu6FN28Q
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Sun, Oct 23, 2005 at 12:41:18PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > If the gcc maintainers think that pointing g++ at g++-3.4 on these arch=
s is
> > the best option, I'm game. One disadvantage is that it wouldn't let us=
get
> > feedback about what else might be wrong with g++-4.0 on those architect=
ures,
> > but we probably already have all the information we're going to get abo=
ut
> > the current round of toolchain packages.
> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs. =20
It's not. The bug doesn't cause data loss; it's not a security bug; it
doesn't render the package unuseable or mostly so. It renders the package
unuseable for a particular set of affected software, but it is not *mostly*
unuseable because *most* C++ packages still build fine g++-4.0 in spite of
this error. I also doubt that we've ever shipped a toolchain that had *no*
ICEs, and dropping back to g++-3.4 certainly doesn't buy us that either.
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://
--Q68bSM7Ycu6FN28Q
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDXCU+
A+mWNXgQ4R400D2
=9xp5
-----END PGP SIGNATURE-----
--Q68bSM7Ycu6FN
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#38 |
tags 323133 + fixed-upstream
tags 323133 - help
tags 323133 + pending
thanks
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #39 |
Message-ID: <email address hidden>
Date: Tue, 8 Nov 2005 15:34:53 +0100
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: tag gcc report
tags 323133 + fixed-upstream
tags 323133 - help
tags 323133 + pending
thanks
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#40 |
Source: gcc-4.0
Source-Version: 4.0.2-4
We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:
cpp-4.0-
to pool/main/
cpp-4.0_
to pool/main/
fastjar_
to pool/main/
fixincludes_
to pool/main/
g++-4.0_
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0_
to pool/main/
gcc-4.0_4.0.2-4.dsc
to pool/main/
gcc-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gfortran-
to pool/main/
gfortran-
to pool/main/
gij-4.0_
to pool/main/
gnat-4.
to pool/main/
gnat-4.
to pool/main/
gobjc-4.
to pool/main/
lib64gcc1_
to pool/main/
lib64gfortran0_
to pool/main/
lib64objc1_
to pool/main/
lib64stdc+
to pool/main/
lib64stdc+
to pool/main/
libffi4-
to pool/main/
libffi4_
to pool/main/
libgcc1_
to pool/main/
libgcj-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6_
to pool/main/
libgfortran0-
to pool/main/
libgfortran0_
to pool/main/
libgnat-
to pool/main/
libmudflap0-
to pool/main/
lib...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #41 |
Message-Id: <email address hidden>
Date: Wed, 16 Nov 2005 10:32:18 -0800
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Bug#323133: fixed in gcc-4.0 4.0.2-4
Source: gcc-4.0
Source-Version: 4.0.2-4
We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:
cpp-4.0-
to pool/main/
cpp-4.0_
to pool/main/
fastjar_
to pool/main/
fixincludes_
to pool/main/
g++-4.0_
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0_
to pool/main/
gcc-4.0_4.0.2-4.dsc
to pool/main/
gcc-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gfortran-
to pool/main/
gfortran-
to pool/main/
gij-4.0_
to pool/main/
gnat-4.
to pool/main/
gnat-4.
to pool/main/
gobjc-4.
to pool/main/
lib64gcc1_
to pool/main/
lib64gfortran0_
to pool/main/
lib64objc1_
to pool/main/
lib64stdc+
to pool/main/
lib64stdc+
to pool/main/
libffi4-
to pool/main/
libffi4_
to pool/main/
libgcc1_
to pool/main/
libgcj-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6_
to pool/main/
libgfortran0-
to pool/main/
libgfortran0_
to pool/main/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#42 |
# CCed to -release and -qt-kde for informational purpose
found 323133 4.0.2-4
thanks
Hello,
This is about Bug#323133, "ICE on arm & m68k when compiling arts (in
cp_expr_size, at cp/cp-objcp-
g++ 4.0.2-4 does indeed successfully compile (tested on paer) the
sample tests posted in comments 1, 4, and 5 of upstream's PR#21123
[1], but sadly it still fails to compile the sample file included in
the original Debian bug report [2], causing the latest upload of arts,
which uses g++-4.0 in all arches as suggested in Matthias' latest
d-d-a post [3], fail to build in hppa [4].
[1] http://
[2] http://
[3] http://
[4] http://
If possible, we (Qt/KDE Maintainers) would like to know whether it'd
make sense to wait a bit and see if this bug can be promptly
re-solved, or we're better off just re-introducing the use of g++-3.4
in our packages.
Thanks in advance,
--
Adeodato Simó dato at the-barrel.org
Debian Developer adeodato at debian.org
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #43 |
Message-ID: <email address hidden>
Date: Wed, 23 Nov 2005 02:26:13 +0100
From: Adeodato =?utf-8?
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Reopening the arm/m68k/hppa cp_expr_size ICE bug
# CCed to -release and -qt-kde for informational purpose
found 323133 4.0.2-4
thanks
Hello,
This is about Bug#323133, "ICE on arm & m68k when compiling arts (in
cp_expr_size, at cp/cp-objcp-
g++ 4.0.2-4 does indeed successfully compile (tested on paer) the
sample tests posted in comments 1, 4, and 5 of upstream's PR#21123
[1], but sadly it still fails to compile the sample file included in
the original Debian bug report [2], causing the latest upload of arts,
which uses g++-4.0 in all arches as suggested in Matthias' latest
d-d-a post [3], fail to build in hppa [4].
[1] http://
[2] http://
[3] http://
[4] http://
If possible, we (Qt/KDE Maintainers) would like to know whether it'd
make sense to wait a bit and see if this bug can be promptly
re-solved, or we're better off just re-introducing the use of g++-3.4
in our packages.
Thanks in advance,
--
Adeodato Simó dato at the-barrel.org
Debian Developer adeodato at debian.org
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#44 |
found 323133
thanks
02:21 <dato> so uhm, if we have Source A produce binaries A, and B, a bug gets reported against B,
closed by an upload (version e.g., 1.1-1), and one then issues "found nnn 1.1-1", the
bug stays closed.
02:22 <dato> 'cause it's "Found in versions B/1.0-1, B/1.1-1" and "Fixed in version A/1.1-1", see
e.g. #323133
02:24 * dato just does "found 323133" for now: "the list of fixed versions for the bug is cleared"
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The easy way is the wrong way, and the hard way is the stupid way. Pick one.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #45 |
Message-ID: <email address hidden>
Date: Fri, 25 Nov 2005 02:25:34 +0100
From: Adeodato =?utf-8?
To: <email address hidden>
Subject: reopening for real
found 323133
thanks
02:21 <dato> so uhm, if we have Source A produce binaries A, and B, a bug gets reported against B,
closed by an upload (version e.g., 1.1-1), and one then issues "found nnn 1.1-1", the
bug stays closed.
02:22 <dato> 'cause it's "Found in versions B/1.0-1, B/1.1-1" and "Fixed in version A/1.1-1", see
e.g. #323133
02:24 * dato just does "found 323133" for now: "the list of fixed versions for the bug is cleared"
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The easy way is the wrong way, and the hard way is the stupid way. Pick one.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#46 |
Source: gcj-4.0
Source-Version: 4.0.2-5j1
We believe that the bug you reported is fixed in the latest version of
gcj-4.0, which is due to be installed in the Debian FTP archive:
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gij-4.0_
to pool/main/
gij-4.0_
to pool/main/
gij-4.0_
to pool/main/
libgcj-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6_
to pool/main/
libgcj6_
to pool/main/
libgcj6_
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Matthias Klose <email address hidden> (supplier of updated gcj-4.0 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Thu, 1 Dec 2005 22:38:34 +0100
Source: gcj-4.0
Binary: lib64gcj6 gij-4.0 lib32gcj6-dev libgcj6 libgcj6-src libgcj6-awt libgcj6-dev lib32gcj6-dbg libgcj-common libgcj6-common gcj-4.0 libgcj6-dbg lib32gcj6
Architecture: all hppa i386 powerpc source
Version: 4.0.2-5j1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers <debian-gcc@li...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #47 |
Message-Id: <email address hidden>
Date: Fri, 02 Dec 2005 11:32:28 -0800
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Bug#323133: fixed in gcj-4.0 4.0.2-5j1
Source: gcj-4.0
Source-Version: 4.0.2-5j1
We believe that the bug you reported is fixed in the latest version of
gcj-4.0, which is due to be installed in the Debian FTP archive:
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gcj-4.0_
to pool/main/
gij-4.0_
to pool/main/
gij-4.0_
to pool/main/
gij-4.0_
to pool/main/
libgcj-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6-
to pool/main/
libgcj6_
to pool/main/
libgcj6_
to pool/main/
libgcj6_
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Matthias Klose <email address hidden> (supplier of updated gcj-4.0 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Thu, 1 Dec 2005 22:38:34 +0100
Source: gcj-4.0
Binary: lib64gcj6 gij-4.0 lib32gcj6-dev libgcj6 libgcj6-src libgcj6-awt libgcj6-dev lib32gcj6-dbg...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#48 |
Source: gcc-4.0
Source-Version: 4.0.2-5
We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:
cpp-4.0-
to pool/main/
cpp-4.0_
to pool/main/
cpp-4.0_
to pool/main/
fastjar_
to pool/main/
fastjar_
to pool/main/
fixincludes_
to pool/main/
fixincludes_
to pool/main/
g++-4.0_
to pool/main/
g++-4.0_
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0_
to pool/main/
gcc-4.0_4.0.2-5.dsc
to pool/main/
gcc-4.0_
to pool/main/
gcc-4.0_
to pool/main/
gfortran-
to pool/main/
gfortran-
to pool/main/
gfortran-
to pool/main/
gnat-4.
to pool/main/
gnat-4.
to pool/main/
gnat-4.
to pool/main/
gobjc-4.
to pool/main/
gobjc-4.
to pool/main/
lib64gcc1_
to pool/main/
lib64gcc1_
to pool/main/
lib64gfortran0_
to pool/main/
lib64gfortran0_
to pool/main/
lib64objc1_
to pool/main/
lib64objc1_
to pool/main/
lib64stdc+
to pool/main/
lib64stdc+
to pool/main/
lib64stdc+
to pool/main/
lib64stdc+
to pool/main/
libffi4-
to pool/main/
libf...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Debian Bug Importer (debzilla) wrote : | #49 |
Message-Id: <email address hidden>
Date: Fri, 02 Dec 2005 16:32:28 -0800
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Bug#323133: fixed in gcc-4.0 4.0.2-5
Source: gcc-4.0
Source-Version: 4.0.2-5
We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:
cpp-4.0-
to pool/main/
cpp-4.0_
to pool/main/
cpp-4.0_
to pool/main/
fastjar_
to pool/main/
fastjar_
to pool/main/
fixincludes_
to pool/main/
fixincludes_
to pool/main/
g++-4.0_
to pool/main/
g++-4.0_
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0-
to pool/main/
gcc-4.0_
to pool/main/
gcc-4.0_4.0.2-5.dsc
to pool/main/
gcc-4.0_
to pool/main/
gcc-4.0_
to pool/main/
gfortran-
to pool/main/
gfortran-
to pool/main/
gfortran-
to pool/main/
gnat-4.
to pool/main/
gnat-4.
to pool/main/
gnat-4.
to pool/main/
gobjc-4.
to pool/main/
gobjc-4.
to pool/main/
lib64gcc1_
to pool/main/
lib64gcc1_
to pool/main/
lib64gfortran0_
to pool/main/
lib64gfortran0_
to pool/main/
lib64objc1_
to pool/main/
lib64objc1_
to pool/main/
lib64stdc+
to pool/main/
lib64stdc+
to pool/main/
lib64stdc+
to pool/main/
block 335287 by 335286
thanks