Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Fri, 2018-06-29 at 11:44 +0100, Luke Kenneth Casson Leighton wrote: [...] > On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt > wrote: > > > > what is the reason why that package is not moving forward? > > > > I assume you're referring to the dpkg upload that's in proposed- > > updates > > waiting for the point release in two weeks time? > > i don't know: i'm an outsider who doesn't have the information in > short-term memory, which is why i cc'd the debian-riscv team as they > have current facts and knowledge foremost in their minds. which is > why i included them. It would have been wiser to do so *before* stating that nothing was happening as if it were a fact. > > I'm also getting very tired of the repeated vilification of SRM > > over > > this, and if there were any doubt can assure you that it is not > > increasing at least my inclination to spend my already limited free > > time on Debian activity. > > ah. so what you're saying is, you could really do with some extra > help? I don't think that's ever been in dispute for basically any core team in Debian. That doesn't change the fact that the atmosphere around the change in question has made me feel very uncomfortable and unenthused about SRM work. (I realise that this is somewhat of a self-feeding energy monster.) Regards, Adam
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton wrote: [...] > debian-riscv has been repeatedly asking for a single zero-impact > line > to be included in *one* file in *one* dpkg-related package which > would > allow riscv to stop being a NMU architecture and become part of > debian/unstable (and quickly beyond), for at least six months, now. > cc'ing the debian-riscv list because they will know the details about > this. it's really quite ridiculous that a single one-line change > having absolutely no effect on any other architecture whatsover is > not > being actioned and is holding debian-riscv back because of that. > > what is the reason why that package is not moving forward? I assume you're referring to the dpkg upload that's in proposed-updates waiting for the point release in two weeks time? Please check your facts before ranting, particularly with such a wide cross-posting. Also, ttbomk, the dpkg change landing in stable is not likely to magically lead to the architecture being added to unstable - a decision which is not the release team's to make or block. Again, please ensure you've actually done your research. I'm also getting very tired of the repeated vilification of SRM over this, and if there were any doubt can assure you that it is not increasing at least my inclination to spend my already limited free time on Debian activity. Regards, Adam
Re: Bug#763278: gcc 4.9 wheezy-pu?
On Thu, 2014-10-09 at 23:01 -0400, Michael Gilbert wrote: Note that the window for the next stable update is closing in about a week, so there isn't a lot of time. Actually, the /point release/ is in about a week. The advertised window for getting updates in to it closes this weekend. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412915973.1325.22.ca...@jacala.jungle.funky-badger.org
Bug#724865: gcc-4.8 also affected
On Thu, 2013-10-31 at 19:48 +0100, Matthias Klose wrote: then you do use outdated packages: package: src:gcc-4.8 version: 4.8.1-3 the recent version is 4.8.2-1. 4.8.1-3 is in unstable's Sources index, but as Extra-Source-Only: yes; I guess Johannes's tools need updating to handle that. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1383262969.21988.12.ca...@jacala.jungle.funky-badger.org
Re: Accepted gcc-defaults 1.118 (source all amd64)
On 14.05.2012 09:10, Matthias Klose wrote: On 13.05.2012 21:58, Adam D. Barratt wrote: On 13.05.2012 18:42, Matthias Klose wrote: On 13.05.2012 21:22, Julien Cristau wrote: On Sun, May 13, 2012 at 18:58:42 +0200, Matthias Klose wrote: which ones? are there any reports which are not tagged? I went through the list of Lucas' new batch and tagged the appropriate ones. There were again some more in the last couple days. They should be tagged AFAIK. I am only aware of these usertags: debian...@lists.debian.org / qa-ftbfs-20120508 do you known about a new rebuild? From a trivial look the set from #672397 onwards on the usertagged bug list were all filed in the past three days. looking at 98 and 99 this doesn't seem to be a set. They're a set in that they appear after each other on the usertagged bug list. I didn't say they had sequential bug numbers, but possibly could have chosen a better description. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/baf36c53ef6abca08fb10b839c3c1...@mail.adsl.funky-badger.org
Re: Accepted gcc-defaults 1.118 (source all amd64)
On 13.05.2012 20:22, Julien Cristau wrote: On Sun, May 13, 2012 at 18:58:42 +0200, Matthias Klose wrote: On 13.05.2012 17:45, Philipp Kern wrote: This doesn't mean that we shouldn't have gcc-4.7 in wheezy as an alternative, just that it is highly problematic as the default at this point of the release cycle. +1 on the revert from me, sadly. in summary, these are getting addressed faster than these are submitted. Please lets wait until the end of June if to make this decision or not. Hell no. End of June is when we'll be frozen. Not when we'll keep messing around with big toolchain changes. Ack. June's been announced as the freeze target since, well, June. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/23d6279e34b45aadfde2cdb869932...@mail.adsl.funky-badger.org
Re: Accepted gcc-defaults 1.118 (source all amd64)
On 13.05.2012 18:42, Matthias Klose wrote: On 13.05.2012 21:22, Julien Cristau wrote: On Sun, May 13, 2012 at 18:58:42 +0200, Matthias Klose wrote: which ones? are there any reports which are not tagged? I went through the list of Lucas' new batch and tagged the appropriate ones. There were again some more in the last couple days. They should be tagged AFAIK. I am only aware of these usertags: debian...@lists.debian.org / qa-ftbfs-20120508 do you known about a new rebuild? From a trivial look the set from #672397 onwards on the usertagged bug list were all filed in the past three days. There may well be others which either haven't been diagnosed as gcc-4.7 issues yet or haven't been tagged. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabed6034f5b6672519f9333753e7...@mail.adsl.funky-badger.org
Re: Processed: blocks mksh on armel; also 2 pkgs on armhf which is a release arch now
On Thu, 2011-11-24 at 23:27 +, Debian Bug Tracking System wrote: severity 633479 serious Bug #633479 [gcc-4.6] ICE: gcc-4.6: ICE on armel+armhf with mksh, on armhf with oss4-4.2-build2004-1 Severity set to 'serious' from 'important' For reference, armhf is *not* yet a release architecture. It's not even in testing, which would be a minimal requirement. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1322177462.25930.23.ca...@hathi.jungle.funky-badger.org
Re: Processed: blocks mksh on armel; also 2 pkgs on armhf which is a release arch now
[and now with a CC to the bug *sigh*] On Thu, 2011-11-24 at 23:27 +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: severity 633479 serious Bug #633479 [gcc-4.6] ICE: gcc-4.6: ICE on armel+armhf with mksh, on armhf with oss4-4.2-build2004-1 Severity set to 'serious' from 'important' For reference, armhf is not yet a release architecture. It's not even in testing, which would be a minimal requirement. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1322177605.25930.24.ca...@hathi.jungle.funky-badger.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
On Sun, 2011-11-20 at 15:29 +0100, Matthias Klose wrote:
On 11/19/2011 11:50 PM, Julien Cristau wrote:
On Sat, Nov 19, 2011 at 23:32:48 +0100, Ludovic Brenta wrote:
retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in
get_output_file_with_visibility, at gengtype.c:1998
reassign 649307 src:gcc-4.6
severity 649307 important
forcemerge 649307 637236
thanks
Julien and everyone else, please stop filing FTBFS bugs automatically
against gcc-4.6 or gnat-4.6.
They're not automatic, the package *is* failing to build, and that issue
should be documented.
We monitor the buildds and are aware of
FTBFS, so these bugs are not useful for us and only take away some of
our precious time for triaging. Thanks.
Failures of other packages to build can't be blocked against oh, the
maintainers will know about it. Nor is anyone triaging said failures
going to automatically be aware that you know about the issue, what
progress (if any) has made towards resolving it, whether it's an issue
with GC{C,J} itself or a kernel or glibc issue, ...
In this particular case, it appears that the bug is actually in gcc and
that the gnat failure is a side-effect? In that case, the bug should be
marked as affecting the gnat package, so it shows up in gnat's bug list.
I see Julien already added the affects, but if that had been done when
the bug was reassigned then it would have been visible in gnat-4.6's bug
list before a duplicate was filed and I suspect at least some of the
animosity in this exchange could have been avoided.
They may not be useful to you bug they're useful to everyone else. Why
are you downgrading this bug?
It's a buildd issue, which somebody needs to investigate.
The log of #637236, which Julien's report got merged with, implies that
someone *is* and has been investigating.
As a general note, marking what are otherwise RC bugs as important so
that the package can migrate isn't really appropriate, at least not
without discussion with the release team (at which point we can e.g.
tell britney to ignore the problems for a particular version).
The all port lights
on green attitude by the release team (not only for kfreebsd) doesn't help
with
this either.
If you have specific concerns about the viability of specific ports,
then raise them appropriately (and preferably in a constructive manner).
Making snide remarks and then complaining that nobody's listening to the
issues isn't helpful.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1321807223.23841.44.ca...@hathi.jungle.funky-badger.org
Bug#633754: gcj-4.6: FTBFS on m68k with segfault
severity 633754 important thanks On Wed, 13 Jul 2011 12:30:17 +, Thorsten Glaser wrote: Source: gcj-4.6 Version: 4.6.1-2 Severity: serious Justification: fails to build from source Building (bootstrapping) gcj-4.6 fails after 3/4 days at: [...] (gcj-4.6 was never built on m68k before, but gcj-4.4 worked.) This isn't RC. It's not a regression, and m68k isn't a release architecture in any case. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0df5e6cc921029904aac6cd82e8f3...@adsl.funky-badger.org
Bug#631817: libgcc1: missing link libgccc_s.so - libgcc_s.so.1
On Mon, 2011-06-27 at 17:07 +0200, Ludovic Brenta wrote: Further research indicates that the version of gcc-4.6 currently in testing is not yet multiarch-aware; the first version with multiarch was 4.6.0-12; the latest version is 4.6.0-14. It should have migrated to testing five days ago but hasn't. The reasons are unclear; How are they unclear? The output generated by britney and displayed by the PTS, grep-excuses, etc. indicates precisely why the package hadn't migrated. the PTS says the package is out of date on powerpc but the build succeeded on 2011-06-18. Indeed. However, the result of that build was never uploaded, so the package was still out-of-date in the archive. That's somewhat irrelevant now, however, as a new version of gcc-4.6 (4.6.1-1) was uploaded earlier today, so the migration cycle has been reset. Could someone please allow 4.6.0-14 to migrate? Commenting in bug reports is not a means of contacting the Release Team... Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1309199770.25674.9.ca...@hathi.jungle.funky-badger.org
Re: GCC-4.5 as the default for (at least some) architectures
On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303068791.3489.499.ca...@hathi.jungle.funky-badger.org
Bug#622095: gccgo: uninstallable on armel
Package: gccgo Version: 4:4.6.0-3 Severity: serious Hi, gccgo is uninstallable on armel as it depends on gccgo-4.6, which is only built on amd64 and i386. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1302380314.4931.2948.ca...@hathi.jungle.funky-badger.org
Re: GMP transition: 4.3.2 to 5.0.1?
On Sat, 2011-02-19 at 04:48 -0600, Steve M. Robbins wrote: On Sat, Feb 12, 2011 at 01:39:39PM +, Adam D. Barratt wrote: Have any of the reverse-dependencies been test-built against the new version? Does the move to 5.0.1 imply any source changes being required for reverse-dependencies, or just rebuilds? (I say just as there appear to be around 350 r-dependencies, including at least five from the GCC suite). I haven't done any test-builds. Since the -dev package changed name, I presume that just rebuild won't work; rather, the sources have to edit their build-deps. Out of interest, why is the -dev package versioned? [...] Matthias also responded requesting: I see that both the runtime library and the -dev packages have different package names. But to be able to still use gmp3 for existing GCC versions, please change the source name too, such that gmp3 is still available in unstable after the upload of gmp5. Shall I go ahead and upload the source gmp5? Then both gmp versions will co-exist in the repository and packages can choose to move to gmp5 at their leisure. After some further investigation, it looks like this isn't feasible. Neither gmp 4.3.2 nor 5.0.1 version their symbols and with both versions in the archive simultaneously and co-installable, there's a reasonable risk of a process ending up with both libraries loaded in to its address space, which is generally not a good idea. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298578544.22974.292.ca...@hathi.jungle.funky-badger.org
Re: GMP transition: 4.3.2 to 5.0.1?
On Thu, 2011-02-24 at 22:15 +0100, Matthias Klose wrote: On 24.02.2011 21:15, Adam D. Barratt wrote: [...] Matthias also responded requesting: I see that both the runtime library and the -dev packages have different package names. But to be able to still use gmp3 for existing GCC versions, please change the source name too, such that gmp3 is still available in unstable after the upload of gmp5. Shall I go ahead and upload the source gmp5? Then both gmp versions will co-exist in the repository and packages can choose to move to gmp5 at their leisure. After some further investigation, it looks like this isn't feasible. Neither gmp 4.3.2 nor 5.0.1 version their symbols and with both versions in the archive simultaneously and co-installable, there's a reasonable risk of a process ending up with both libraries loaded in to its address space, which is generally not a good idea. did you check, that all gcc versions do build with the new version on all architectures, and that the gcc testsuite doesn't show regressions with the new version? will gcc continue to work, while re-building mpfr and mpclib with the new gmp? Steve's mail to this thread less than a week ago said he hadn't done any test rebuilds at all; I suspect the chances that he's gone on to build and test multiple GCC versions on multiple architectures in the meantime are small. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298582383.22974.489.ca...@hathi.jungle.funky-badger.org
Re: GMP transition: 4.3.2 to 5.0.1?
On Sun, 2011-02-06 at 12:39 -0600, Steve M. Robbins wrote:
Now that squeeze is out, I'd like to move from GMP 4 to GMP 5. The
latter was released upstream about a year ago and the gmp lists
aren't buzzing with outrageous bugs, so it appears stable enough.
Looking at the package names of the unstable and experimental versions,
it looks like the main change is libgmp3c2 to libgmp3? (There is also
lib{32,64}gmp3 - lib{32,64}gmp10, but those libraries appear to only be
used by gmp itself).
I know GMP is used in gcc itself, so I'd appreciate some guidance
from the gcc team as well, since this is a major version change.
I uploaded GMP 5 to experimental last year and it builds fine with two
exceptions: hppa is BD-Uninstallable (?) and ia64 fails to build with
an ICE. The underlying cause is already known [1] and from reading
the bug report I suspect I may be able to work around this by building
one file with -O2 rather than -O3. Other suggestions welcome.
hppa is in Needs-Build, not BD-Uninstallable; that's expected because
hppa doesn't have any autobuilders for experimental.
Have any of the reverse-dependencies been test-built against the new
version? Does the move to 5.0.1 imply any source changes being required
for reverse-dependencies, or just rebuilds? (I say just as there
appear to be around 350 r-dependencies, including at least five from the
GCC suite).
Main question: should I go ahead and upload the new version when
I get a free moment or do we need more investigation?
At the very least I'd first like to confirm that the suggested change
for ia64 works (rebuilding on the other architectures wouldn't hurt
either) and better understand the scope of the changes, particularly in
relation to e.g. gcc.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1297517979.27877.2727.ca...@hathi.jungle.funky-badger.org
Bug#589389: FTBFS on ia64
clone 589398 -1 reassign -1 src:genius found -1 1.0.9-1 thanks Hi, On Sun, 2010-08-08 at 18:23 +0200, Emilio Pozuelo Monfort wrote: Short summary: genius FTBFS on ia64 (and only there) with this problem: cd ../lib ../src/genius --maxerrors=0 --compile loader.gel temp.cgel mv -f temp.cgel lib.cgel /bin/bash: line 1: 7761 Segmentation fault ../src/genius --maxerrors=0 --compile loader.gel temp.cgel make[4]: *** [lib.cgel] Error 139 I've debugged it on merulo and it builds fine with gcc-4.3 and gcc-snapshot, only fails with gcc-4.4. However with -O0 and -O1 it builds fine with gcc-4.4, only -O2 fails. Thanks for the analysis. As this can be worked around in the genius packages I'm reassigning a clone back there. The upstream changelog for 1.0.9 suggests that it fixes a number of potential crashes and given the amount of testing it's had in unstable (other than on ia64, obviously) it would be good to get that version in to Squeeze. (genius is also one of the last remaining packages using mpfr rather than mpfr4 in testing). Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281888222.29656.1182.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#589337: FTBFS on mips and sparc
On Tue, 2010-08-10 at 09:23 -0700, Steve Langasek wrote: This is a bug in gcj, not in db4.8. It appears to now affect *all* architectures, it just only manifested on sparc and mips because db4.8 was later to build there and got caught by the introduction of this bug. Specifically, this does appear to be another instance of the general problem from #580148. gcc-4.4-base 4.4.4-7 ships /usr/lib/gcc/x86_64-linux-gnu/4.4.4/, 4.4.4-8 ships /usr/lib/gcc/x86_64-linux-gnu/4.4.5/ and the new gcj-4.4-base packages have symlinks pointing to the latter. gcc-4.4-base is already installed in the chroots and often won't be the latest version unless something has forced an upgrade, whereas gcj will be installed each time if the buildd is using lvm snapshot chroots; the end result is that the symlinks end up dangling. afaics, gcj-4.4-jdk's dependency on gcc-4.4 needs to be bumped to = 4.4.4-8. Regards, Adam -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281481513.10386.197.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#456264: retitle 456264 to gcj: non-free man page included ..., user [EMAIL PROTECTED] ...
# Automatically generated email from bts, devscripts version 2.10.15 # Sorry... retitle 456264 gcj: non-free man page included retitle 465264 [debuild] --lintian-opts doesn't work user [EMAIL PROTECTED] usertags 465264 debuild -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412104: Man page for gcc missing on Etch
On Fri, 2007-02-23 at 12:05 -0500, Bob Kline wrote: Package: gcc-4.1 Installing gcc on Etch does not provide a man page. I've never seen a system (including previous versions of Debian) where gcc didn't come with a man page. You want gcc-doc, which is in contrib, and will install the relevant gcc-X.X-doc package from non-free. gcc's man pages and documentation are licensed under a variant of the GFDL that Debian has decided is non-free, hence their removal from main. The gcc packages do Suggest: gcc-doc, which is much as a package in main may do with respect to a package in non-free. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hello,what is the gcc problem? etch gcc 4.1 no stdio.h?
Hi,
On Thu, 2006-10-12 at 05:58 -0400, lantian ai wrote:
grandi:~# cat hello.c
#include stdio.h
int main()
{
printf(hello world\n);
}
grandi:~# gcc -o hello hello.c
hello.c:1:19: error: stdio.h: No such file or directory
hello.c: In function 'main':
hello.c:4: warning: incompatible implicit declaration of built-in
function 'printf'
grandi:~# ls /usr/include/
initreq.h
The problem is that you don't have libc6-dev installed.
Regards,
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390694: [arm] Internal consistency failure while building OpenSER 1.1.0-3
Hi, On Mon, 2006-10-02 at 18:52 +0200, Matthias Klose wrote: Julien BLACHE writes: Package: gcc-4.1 Version: 4.1.1-13 Severity: important Hi, gcc-4.1 bails out with an error while build OpenSER 1.1.0-3 on arm, see http://buildd.debian.org/fetch.php?pkg=openserver=1.1.0-3%2Bb1arch=armstamp=1159765150file=logas=raw you're pointing to a sucessful log. The package built successfully, but one of the files did indeed fail to compile: tree234.c: In function 'delpos234_internal': tree234.c:927: fatal error: internal consistency failure compilation terminated. Preprocessed source stored into /tmp/ccqzWZWz.out file, please attach this to your bugreport. make[2]: *** [tree234.o] Error 1 (In fact, tree234.c fails four times in the log). Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389713: cpp-3.3: gcc package dependency problem
Hi, On Wednesday, September 27, 2006 11:46 AM, Klemens Kasemaa [EMAIL PROTECTED] wrote: Package: cpp-3.3 Version: gcc-3.3-base Erm... that's not a version number of the package cpp-3.3. Severity: important Cannot install gcc because of dependency problem: cpp-3.3: Depends: gcc-3.3-base ( 1:3.3.6) but 1:3.3.6-5 is to be installed [...] Versions of packages cpp-3.3 depends on: ii gcc-3.3-base 1:3.3.6-5 The GNU Compiler Collection (base ii libc6 2.3.2.ds1-22sarge4 GNU C It looks like you've attempted to mix and match packages from stable and testing/unstable. That's not supported. The version of gcc-3.3-base in sarge (stable) is currently 1:3.3.5-13, which satisfies the dependencies. 1:3.3.6-5 isn't in the archive at all at the moment (testing and unstable both have -13). -5 is newer than sarge, but still over 15 months out of date. Downgrade gcc-3.3-base to the sarge version, in line with the rest of your system, and cpp-3.3 will install fine. Closing as this isn't a bug in the package. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: g++ insanity??????
On Friday, December 02, 2005 12:00 PM, Michael Blansfield [EMAIL PROTECTED] wrote: Hello, I am trying to install the g++-3.3 compiler on my linux box. But I need to install all the supporting libraries, which I do fine until I get to libstdc++5-3.3-dev which requires g++! What is this? Endless loop, catch 22, this does not compute, this does not compute... apt is perfectly capable of resolving circular dependencies. apt-get install g++-3.3 will do the right thing. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
