Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote: On 2013-10-29 17:48, Ian Jackson wrote: Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)): [...] As mentioned we are debating whether the 5 DDs requirement still makes sense. Would you say that we should abolish the requirement for DD porters completely? I.e. Even if there are no (soon to be) DDs, we should consider the porter requirements fulfilled as long as they are enough active porters behind the port[0]? I don't have a good feel for the answer to that question. It's just that if it is the case that a problem with ports is the lack of specifically DDs, rather than porter effort in general, then sponsorship is an obvious way to solve that problem. If you feel that that's not really the main problem then a criterion which counts porters of any status would be better. I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. Why would the sponsor need to be involved in getting the porters access to porter boxes? Porter boxes exist so that DDs *not* involved in a port have access to a machine of the architecture and can keep their packages working. I've never heard of a porter who didn't have access to their own box for porting work. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Tue, Nov 16, 2010 at 09:49:08AM +0100, Julien Cristau wrote: On Mon, Nov 15, 2010 at 21:29:07 -0500, Matt Turner wrote: I can't see why you think --as-needed is fundamentally wrong or unnecessary. Check out http://www.gentoo.org/proj/en/qa/asneeded.xml --as-needed has saved tons of time for upgrades like Cairo in Gentoo, where Cairo had been linked to glitz which is now useless and gone. Not a problem, if Cairo was properly exposing the dep. So when people upgraded Cairo, all the software that linked against it (and also unnecessarily linked against glitz) Why did it get linked against glitz? That's where the problem is. I think because -lglitz was in cairo's .pc file. That should be fixed by removing -lglitz from cairo's .pc file, not by passing --as-needed to the linker. I agree with you, -lglitz should never have been listed in the .pc file to begin with. However, *given* that it was there, the default --no-as-needed behavior means that removing libglitz is more painful than it would be otherwise, because instead of just rebuilding cairo itself without glitz, you must rebuild everything above cairo in the stack that used pkg-config for linking. I don't argue that this makes --as-needed *correct* as a default, but I think it's clear how using --as-needed may benefit a distribution in terms of reducing churn when library dependencies change. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116171440.gf30...@virgil.dodds.net
Re: Scheduling linux-2.6 2.6.21-[23]
\On Fri, May 18, 2007 at 05:42:21PM +0200, Bastian Blank wrote: On Fri, May 18, 2007 at 12:18:57PM +0200, Bastian Blank wrote: I'd like to schedule the linux-2.6 2.6.21-[23] upload for today. I'll disable sparc32 and all hppa images. - sparc32: see the other discussion. Ok, this seems to have Jurij's consent at least in principle. But this: - hppa: broken toolchain which makes it impossible to build them and we need linux-libc-dev. What is so urgent about linux-libc-dev that you need to break what wasn't broken before? glibc still depends on l-l-d | l-k-h, and almost all of the buildds still have l-k-h installed rather than l-l-d; but this change to disable hppa image building *ensures* that 2.6.21-2 is not releasable (is not suitable for testing), where 2.6.21-1 might have built just fine once the hppa toolchain was fixed. In the case of alpha, despite my irritation at having to revert this change from the trunk before *beginning* to test 2.6.21 builds, at least there was a kernel bug that needed to be fixed. But hppa's bug is in the toolchain, not in the kernel -- so this is certainly a regression, and once again it doesn't look like the hppa porters were even consulted before the change was made (firing off a notice to debian-hppa 5 hours before uploading is not consultation). -- 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 PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
On Sun, Dec 24, 2006 at 05:19:03AM +, Steve McIntyre wrote: On Fri, Dec 22, 2006 at 03:04:54PM +, Steve McIntyre wrote: I'm looking further to see if it's at all possible to get (e.g.) hppa and alpha to live in the same boot sector, but it's really not likely. Within sector 0: alpha = bytes 000-n : ID string Linux/Alpha aboot for ISO filesystem.. Looks like that could be modified if necessary. 480-487 : length of the boot image 488-495 : location of the boot image 504-511 : checksum of the previous bytes in the boot sector (otherwise blank) hppa bytes 000-008 : magic header 008-011 : location of kernel image 012-015 : length of kernel image 016-019 : location of ramdisk 020-023 : length of ramdisk 024-150 : boot command line 232-235 : location of kernel image 236-239 : length of kernel image 240-243 : location of boot loader image 244-247 : length of boot loader image (otherwise blank) I just couldn't resist... :) I've submitted bug #404986 against genisoimage which includes a patch that lets hppa and alpha boot blocks coexist without clobbering one another. Since the only conflict between these two blocks was a cosmetic one (apparently the ID string from aboot is never displayed at all when booting from SRM so it's hardly even that), this should work just fine. So far, though, I've only tested it on alpha, not on hppa. If anyone would care to give this a whirl and follow up to the bug report, that'd be nice. I have a jigdo set at http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.jigdo and http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.template which is an alpha netinst image, plus the kernel/initrd/bootloader for hppa; this means it's not actually installable on hppa, but it should be bootable if someone wants to give it a try and report back any results. If this checks out and the patch is accepted, it should be trivial to tack in ia64 or i386/amd64 as well, as long as space permits. :) That's probably as many archs as it's realistic to squeeze onto a single image. It would be interesting to know how OpenBSD got sparc and powerpc to coexist though, since Steve's report says that powerpc wants all of the first 12 sectors -- figuring that out might let us stretch this even farther into the realm of the absurd ;) -- 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 PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
On Fri, Dec 29, 2006 at 04:45:28PM -0800, Steve Langasek wrote: I have a jigdo set at http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.jigdo and http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.template which is Correction: that's http://people.debian.org/~vorlon/debian-40-alpha-NETINST-1.jigdo and http://people.debian.org/~vorlon/debian-40-alpha-NETINST-1.template. Sorry for the typo. -- 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 PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
Hi Ryan, On Fri, Dec 29, 2006 at 08:26:33PM -0800, Ryan Bradetich wrote: Matt Taggart pointed me to this thread and I tested the .iso image you provided via jigdo on my j6000. I was able to successfully boot the system and the Debian installer did start. Great, thanks for the feedback. Forwarding this on to the bug report. Cheers, -- 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 PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libgcc2 rdepends on hppa
On Sat, Oct 28, 2006 at 01:05:02PM +0200, Matthias Klose wrote: Packages still depending on libgcc2, without depending on libg2c0 (can't do anything about libg2c0, built from gcc-3.4). ale This one can't be binNMUed on the autobuilders because it's previously been binNMUed using the old version scheme. aqsis aqsis-libs libsimpledb2 These have been scheduled previously and apparently failed to build. tora Ditto; in addition, points to an RC bug in qscintilla, because the -dev package's deps are not binNMU-safe. basilisk2 This one needs built on hppa, not binNMUed; appears to be blocked by bug #309501. libosgcal0 This one also needs built, not rebuilt. Cleared a stale dep-wait on all archs. parrot This one needs built, not rebuilt. Blocked by bug #382147. netgen This one needs built, not rebuilt. FTBFS with ICE; is this a known bug in gcc-4.1? xshisen Needs built, not rebuilt. Cleared a stall dep-wait on hppa. boson-base AIUI this package is obsoleted by boson, and is not in testing. cbedic kfolding ksocrat spectemu-common stella wdq2wav Scheduled. libmyspell3c2 Package doesn't appear to be binNMUable, source and binary package numbers differ. :P -- 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 PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387875: gij-4.1 4.1.1-13: segfault in postinst on hppa and arm
Package: gij-4.1 Version: 4.1.1-13 Severity: grave The gij-4.1 package fails to install on arm and hppa due to a segfault in gcj-dbtool-4.1: Setting up gij-4.1 (4.1.1-13) ... /var/lib/dpkg/info/gij-4.1.postinst: line 20: 8807 Segmentation fault gcj-dbtool-4.1 -n /var/lib/gcj-4.1/classmap.db dpkg: error processing gij-4.1 (--configure): subprocess post-installation script returned error exit status 139 dpkg: dependency problems prevent configuration of gij: gij depends on gij-4.1 (= 4.1.1-2); however: Package gij-4.1 is not configured yet. This of course prevents many packages from being able to build on these architectures; e.g., trang, with build failures shown at http://buildd.debian.org/fetch.php?pkg=trangarch=armver=20030619-5.1%2Bb1stamp=1157940816file=log and http://buildd.debian.org/fetch.php?pkg=trangarch=hppaver=20030619-5.1%2Bb1stamp=1158062398file=log No other architectures have shown these symptoms; X-Debbugs-Cc set to the relevant porter lists. It is particularly important for arm that this be fixed quickly, since arm is very much not keeping up with java-related packages right now and doesn't stand much chance of being included in the etch release without rapid improvement. -- 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 PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel build dependency on gcc-4.0?
On Tue, Sep 05, 2006 at 11:54:11AM +0200, Bastian Blank wrote: On Tue, Sep 05, 2006 at 09:55:09AM +0200, Matthias Klose wrote: Will gcc-4.0 be dropped as a build dependency for etch, or be kept? The alpha maintainer said, gcc-4.1 is not capable to build the linux kernel, the same applies to m68k. Any other architecture can use it. hppa just did not switch on the last abibump of 2.6.17 and we don't plan another. Would you mind dropping gcc-4.0 from etch for some architectures? We need it until we drop 2.6.16 and 2.6.17 from the archive. So for the current 2.6.17 it's still needed for *all* architectures, or could gcc-4.0 still be dropped on some architectures where the kernel is already using gcc-4.1? -- 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 PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: Bug#342545: qt-x11-free FTBFS
On Thu, Aug 24, 2006 at 09:50:23PM -0400, John David Anglin wrote: This might be a nan bug. There is one GCC nan fix that's only installed on the trunk: 2006-05-24 John David Anglin [EMAIL PROTECTED] PR target/27627 * pa/pa-modes.def: Use mips_single_format, mips_double_format and mips_quad_format formats instead of ieee_single_format, ieee_double_format and ieee_quad_format formats, respectively. Just saw your patch. Watch out, there are at least two different representations for nans. In GCC, they are called mips and ieee. However, as far as I can tell, PA-RISC used the mips format before mips. Both formats are complient with the original IEEE standard, so it's also a bit of a misnomer to call the other format the IEEE format. Uh, my patch only attempts to correct for the bad alignment assumptions in the existing code that cause build failures on hppa; invalid assumptions about the byte representations of -NaN on particular platforms can be someone else's problem if and when it becomes an issue. ;) -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#342545: qt-x11-free FTBFS
reassign 342545 qt-x11-free thanks On Wed, Aug 23, 2006 at 07:52:48AM -0400, Kyle McMartin wrote: On Wed, Aug 23, 2006 at 10:39:04AM +0200, Matthias Klose wrote: The qt-x11-free package builds fine with a standard Debian setup. Building with prctl --unaligned=signal makes the bug reproducible. Right. The buildd is set up to deliver SIGBUS on unaligned accesses. This is configurable, and not the default kernel behaviour. It is, however, a Good Thing(tm). Unaligned accesses are quite costly, so catching and fixing them on the buildd is ideal. However, in most cases they are nontrivial to fix and should be rebuilt and uploaded and a bug filed with upstream... When I initially added prctl for parisc, iirc there were three options logging an unaligned access, delivering a SIGBUS, or silently catching it and continuing on. I have a machine that can be used to do these rebuilds, if need be. That would be wonderful if you, or another hppa porter, could track down where the bug lies. libgcc2 is almost certainly the wrong package, since nothing should be *using* libgcc2 in a fresh build of qt-x11-free; it may be a bug in libgcc4 instead, but I think that's yet to be determined. In the meantime, I think it's best to reassign this back to qt-x11-free. 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#364819: gij-4.1: bus error on hppa
On Sun, Jun 04, 2006 at 04:47:31PM +0200, Matthias Klose wrote: Falk Hueffner writes: Steve Langasek [EMAIL PROTECTED] writes: Hi Matthias, works for me. Have you tried building it with prctl --unaligned=signal? This is not the default on hppa, but it's used on the autobuilders because it catches potentially costly programming errors. is this documented somewhere, so that you even have a chance to configure a machine like a buildd? Not that I'm aware of. If you have questions about the buildd setup, you can always ask LaMont. -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA
On Sun, Apr 30, 2006 at 06:53:03PM -0400, John David Anglin wrote: Is this acutally decided? Is it likely to happen soon, or should I build GMP with gcc 3.3 (which doesn't exhibit the problem) in the short term? For now, I suggest that you remove gcc-4.1 from your build system. Then, GMP should build fine with 4.0. You might have to reinstall 4.0. Er, no; we're talking about official Debian packages here, and the libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting in the double libgcc_s problem. So removing gcc-4.1 from his build system isn't an option unless we find a way to do this systemically for Debian. -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#364231: exception catching broken on HPPA
On Sat, Apr 22, 2006 at 10:00:04AM +0200, Matthias Klose wrote: $ ldd a.out libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x40575000) libm.so.6 = /lib/libm.so.6 (0x4046e000) libgcc_s.so.2 = /lib/libgcc_s.so.2 (0x40068000) libc.so.6 = /lib/libc.so.6 (0x4074b000) libgcc_s.so.4 = /lib/libgcc_s.so.4 (0x40015000) /lib/ld.so.1 (0x400e1000) We end up with both libgcc_s.so.2 and libgcc_s.so.4 linked. Is there a solution other than making gcc-4.1/g++-4.1 the default and rebuilding the libstdc++6 dependent packages with binary NMU's? I guess having gcc-4.0 link against libgcc4 is out of the question? -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [parisc-linux] [Fwd: [patch/hppa] Floating point exception handling patch]
On Mon, Jan 16, 2006 at 11:40:50AM -0500, Kyle McMartin wrote: On Sun, Jan 15, 2006 at 11:22:12PM -0700, Grant Grundler wrote: On Mon, Jan 16, 2006 at 07:38:36AM +0800, Randolph Chung wrote: This affects packages that use feholdexcept and fesetenv, such as uic from QT. It's not a very long list. I hacked the following short script to search a local mirror I have access to. Output from this script is appended at the end: [...] Obviously there are some false positives (e.g. lg-issue40 and manpages). Readding debian-hppa to the CC list. This is a pretty short list... Would anyone object to binNMUs of the effected packages on hppa, once a fixed glibc is uploaded? If the bug is in glibc, why would any of these packages need binNMUs? The only reason they would need rebuilt after a glibc bug fix would be if the glibc ABI changed in the process, and that would be Very Badtm. -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [parisc-linux] [Fwd: [patch/hppa] Floating point exception handling patch]
On Mon, Jan 16, 2006 at 03:43:37PM -0700, Grant Grundler wrote: On Mon, Jan 16, 2006 at 09:03:59AM -0800, Steve Langasek wrote: This is a pretty short list... Would anyone object to binNMUs of the effected packages on hppa, once a fixed glibc is uploaded? If the bug is in glibc, why would any of these packages need binNMUs? Only if they were statically linked - I doubt that's the case. But the reason for the list was to make it easier for the buildd maintainer to know which packages with previously failed builds could be requeued. Oh, well... at this point, it's probably just easier to assume all of them. :) -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#344538: hppa dependency problems on build of pdns
On Tue, Jan 10, 2006 at 11:08:14AM +0100, Frank Küster wrote: Steve Langasek [EMAIL PROTECTED] wrote: On Mon, Jan 09, 2006 at 02:37:53PM +0100, Frank Küster wrote: The same happened to the planner package, and has been reported as #344538. It seems that hppa buildd is broken, don't know yet whether the buildd admin (Lamont) or anybody of the debian-admin (responsible for the hardware) is at it. Hasn't the problem on the hppa buildd been fixed for a while? The pdns package (both versions 2.9.19-2 and 2.9.19-3) has built fine on that arch now. It *seems* it has been fixed; but I don't know whether it has just disappeared, or has been fixed by human intervention, and if yes by which. Since the first may be true, it might as well reappear again. sigh No, buildds don't magically go from believing a dependency is satisfied, to believing it's not satisfied, and back again. If the problem has disappeared, it's due to human intervention. or a bug in some maintainer script or other; How a bug in a maintainer script could have the result that installing an arch-all package fails because an other arch-all package is not there, and how this can happen on only one particular machine of one particular architecture, this I fail to see. Then you haven't been looking at buildds for very long. Historically such problems were unpleasantly frequent on buildds due to a combination of buggy postrm scripts, and a bug in dpkg's rollback support when calling dpkg --purge for a package in the installed state. I believe the dpkg bug is fixed now, but a) I could be wrong, and b) there may be other bugs in the world. -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#344538: hppa dependency problems on build of pdns
On Tue, Jan 10, 2006 at 12:24:47PM +0100, Frank Küster wrote: Steve Langasek [EMAIL PROTECTED] wrote: Historically such problems were unpleasantly frequent on buildds due to a combination of buggy postrm scripts, and a bug in dpkg's rollback support when calling dpkg --purge for a package in the installed state. I believe the dpkg bug is fixed now, but a) I could be wrong, and b) there may be other bugs in the world. Ah - can you point me to something to read about this? The dpkg changelog, maybe. How can it be architecture-specific, or host-specific? It almost certainly wouldn't be. But it's quite possible for a different combination of package versions (with different maintainer script bugs) to be used on different autobuilders at a given moment. -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: qt-x11-free build fails
Grant, thank you for your work to date on this bug. (BTW, it would be helpful if you would follow up to bug #342545 on libgcc2, instead of bug #341675 which is filed against just one of the many packages affected by it). Unfortunately, it doesn't seem from the bug log as though much progress is being made towards a resolution. At this point, the KDE transition has been completed in testing for all architectures, with the exception of hppa as a result of this bug. The release team is already moving on to other transitions that need to happen for etch, including another round of dbus-related KDE changes. This is a release-critical bug, and it is impacting hppa's ability to keep up with etch at large, extending even to such core packages as aptitude (build-depends on cppunit; now uninstallable in testing on hppa). Is there progress being made on this bug that's not shown in the bug log, or do we need to consider dropping hppa from the list of etch release archs at this point? 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: qt-x11-free build fails
[cc:ed to the hppa porters individually, as well as to debian-hppa; please let me know if you prefer to get such mail just via the list in the future.] Are the hppa porters aware of bug #342545 in libgcc2, which is affecting builds of most Qt-related packages on hppa today? I had suggested to LaMont that this was a result of the buildd being configured to throw SIGBUS instead of silently doing alignment fixups, but I see that this bug is actually an illegal instruction, *not* a SIGBUS, so this is presumably not as easy to fix as just throwing a kernel switch. This is currently the single largest blocker for KDE completing the c2a ABI transition, and large numbers of missing hppa builds are being ignored in the analysis right now because it's the only way to see what other real package bugs are outstanding. Aurelien has done some good work on pinning down the location of the problem, but an hppa porter is going to need to look at this to tell us what the proper fix is. If this bug isn't fixed by the time the rest of the KDE hint is ready to go in, we'll probably push it in leaving the packages out of date (and possibly uninstallable) for hppa. At that point we would also have to reconsider hppa's status as a release port, so hopefully someone will have a chance to look at this soon. 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: qt-x11-free build fails
reassign 341675 libgcc2 4.0.2-5 thanks On Sun, Dec 18, 2005 at 06:56:34PM +0100, Aurelien Jarno wrote: On Mon, Dec 12, 2005 at 02:41:49AM -0800, Steve Langasek wrote: This is a bug that was believed fixed previously, but it is *not* bug #326581; it's bug #333766, which was fixed in glibc 2.3.5-7. (And it really was fixed, otherwise kdelibs4c2 wouldn't be in testing right now for hppa.) But it's back in 2.3.5-8; could this have to do with the fact that 2.3.5-7 was built (wrongly) with gcc-4.0, and 2.3.5-8 is the first version to build with gcc-3.4? I confirm. Bug #333766 was causing a SIGBUS in uic, when calling feholdexcept. This has been fixed, and now the problem is a SIGILL that occurs a few instructions later when calling __umoddi3 from libgcc_s.so.2. I have tried other version of libgcc2, from version 4.0.1-7 to version 4.1-0exp4, and the problem is always there. So it does not seems related to a recent change in gcc. Maybe this part of code was never called before for some strange reasons. It would be nice if somebody fluent with hppa assembly can tell us if fldw -10(,sp),fr23 is a valid instruction or not. If not, that's probably a miscompilation in gcc, as this code is generated from C code. Ok; reassigning to libgcc2 then. Cheers, -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: boost FTBFS on hppa
Hello, Is anyone looking into this problem with building boost on hppa? As there are quite a few packages which build-depend on boost (including parts of KDE, and aptitude), this is likely to cause hppa to hold up the c2a transition unless some progress is made here. 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: C++ transitions status report
On Fri, Dec 02, 2005 at 12:23:37PM +0100, Domenico Andreoli wrote: On 12/2/05, Nathanael Nerode [EMAIL PROTECTED] wrote: ... *** The following library packages have been renamed for the C++ allocator change but haven't built on all architectures yet. The ones near the top have other problems which must be addressed too. boost -- FTBFS on hppa, bug 341174 it is the same of #334959 which i worked around using gcc 3.4. starting with 3.4.4-10, also gcc 3.4 got broken with the same linker error. as per #334959, i do not know how to manage it. i tried both gcc 4.0 and gcc 3.4 using -O2 but nothing changed. i also opened #334497 against binutils because i thought it was due to binutils, but now i'm starting to doubt about this. i think here is required some toolchain expert. Might be a good idea to ask the hppa list, then. -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 07:26:43PM +0200, Aurelien Jarno wrote: When looking at the assembly code generated with gcc-3.3/gcc-3.4 and with gcc-4.0, I see some differences: source code: __asm__ ( fstd,ma %%fr0,8(%1)\n fstd,ma %%fr1,8(%1)\n fstd,ma %%fr2,8(%1)\n fstd,ma %%fr3,8(%1)\n : =m (*_regs), +r (_regs)); gcc-3.3/gcc-3.4 (code working correctly): 10624: 2e 91 10 23 fldd,ma -8(,r20),fpe6 10628: 2e 91 10 22 fldd,ma -8(,r20),fpe4 1062c: 2e 91 10 21 fldd,ma -8(,r20),fpe2 10630: 2e 91 30 20 fldd,mb -8(,r20),fr0 gcc-4.0 (SIGBUS): 1062c: 2f 91 10 23 fldd,ma -8(,ret0),fpe6 10630: 2f 91 10 22 fldd,ma -8(,ret0),fpe4 10634: 2f 91 10 21 fldd,ma -8(,ret0),fpe2 10638: 2f 91 30 20 fldd,mb -8(,ret0),fr0 I also don't speak hppa assembly, but it is obvious that the code does not use the same registers. Maybe the bug is in gcc which generates wrong code? At least the same source code built with gcc-3.3 and gcc-3.4 is working correctly. No, it isn't: glibc (2.3.5-6.0.1) unstable; urgency=low * On hppa, build using gcc-3.4. -- Matthias Klose [EMAIL PROTECTED] Sat, 17 Sep 2005 10:55:42 + This is the version of libc6 running on the buildd and in paer's unstable chroot where I reproduced the error. So glibc is known to have problems on hppa when built with gcc-4.0, but this doesn't appear to be one of them. -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 11:05:01PM +0100, Stephen Gran wrote: I think you are misunderstanding him, Steve, or I am misunderstanding the whole thing (which is not unlikely). I think Aurelian is saying that the same source code that you supplied builds and runs fine with gcc-3.4, but not with gcc-4.0: Well, while that's true, I don't believe that's what he was saying at the time; the 3.4 vs. 4.0 generated code he cited corresponded to the assembly from libm, not to the test case I provided. [EMAIL PROTECTED]:~$ gcc-3.4 -lm test.c -o test.3.4 [EMAIL PROTECTED]:~$ gcc-4.0 -lm test.c -o test.4 [EMAIL PROTECTED]:~$ ./test.3.4 [EMAIL PROTECTED]:~$ ./test.4 Bus error This certainly smells more like a compiler bug than anything. The same library and the same header files, 2 different compiler versions, 2 results. To say that this is a compiler bug, you would have to show that gcc-4.0 is *wrong* to 32-bit align the fenv_t struct instead of 64-bit aligning it. You'd have to check with the compiler folks to be sure, but I don't think this is a correct assertion for a struct of 32-bit unsigned ints. At any rate, knowing that gcc-3.4 does this alignment differently gives us a viable workaround for qt; since qt is already building with g++-3.4 on hppa (et al.), it's no trouble to also make it build-depend on and use gcc-3.4. On Fri, Oct 14, 2005 at 12:20:50AM +0200, Aurelien Jarno wrote: Well we've discussed a bit of that on IRC with Steve, I think we have two problems (maybe linked): - gcc-3.4 and gcc-4.0 changed the way they align the code. Have a look at your test.c file. There is nothing in it, and moreover gdb show the problem appears in libm, which has been compiled with gcc-3.4. - gcc-4.0 generates wrong code For that see my attached file. It's the file from the glibc, with the code from Steve pasted at the end. It works with gcc-3.4, but fails with gcc-4.0. I suspect that compiling this portion of glibc with gcc-4.0 will give the same behavior: building test.c with gcc-4.0 will fail, building test.c with gcc-3.4 will succeed. Either that, or both will fail if this is one of the cases where gcc-4.0 breaks glibc horribly, but I didn't see any reason to think this was the case. Cheers, -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#321785: fakeroot: segfaults on [hppa]
On Fri, Aug 12, 2005 at 11:51:30AM +0200, Joel Soete wrote: The buildd in question is currently running a 2.4.26-64 kernel. Cool (I didn't thought that there was still systems running 2.4) Well, sarge also shipped as 2.6-only, for hppa; so if the answer is that this problem happens to go away when upgrading to 2.6, that's probably acceptable, since 2.4 kernels will have been unsupported on hppa for a full stable release by the time etch comes out. Cheers, -- 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 PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#321785: fakeroot: segfaults on [hppa]
On Thu, Aug 11, 2005 at 12:49:24PM +0200, Joel Soete wrote: -- Initial header --- From : Randolph Chung [EMAIL PROTECTED] To : John David Anglin [EMAIL PROTECTED] CC : [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],debian-hppa@lists.debian.org,[EMAIL PROTECTED] Date : Wed, 10 Aug 2005 22:53:08 +0800 Subject : Re: Bug#321785: fakeroot: segfaults on [hppa] Confirmed. We are passing a function pointer with a value of -2 into __cffc, which should not happen... Is -2 a special signal number? I don't think so. in any case, others have observed that if they use an older glibc, this problem does not happen. randolph Hello all, Which kernel was it? The buildd in question is currently running a 2.4.26-64 kernel. In fact while simply rebuilding a kernel (as root, without fakeroot), I also observe a segfault with 2.6.8 and 2.6.10 (on c110 and d380) but panicing 2.6.12 (on the same c110 and d380) as well as 2.6.13-rc6 on d380 and b2k. Fwiw with kernel 2.6.11.12, the rebuild runs fine on this same d380 and b2k. Well, there have certainly been various and sundry known kernel issues on hppa, but this seems wholly unrelated to them. That's confusing me: is there actualy a pb in libc or do we need some constraint to install this new libc? glibc seems to be the one thing that's changed; running make manually with a copy of glibc 2.3.2 in the chroot works just fine. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I will move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#306254: axe: FTBFS: Failed to satisfy Build-Depends dependency for axe: libxaw-dev
On Thu, Apr 28, 2005 at 12:21:44PM -0700, H. S. Teoh wrote: On Mon, Apr 25, 2005 at 11:42:50AM +0200, Andreas Jochens wrote: [...] When building 'axe' in a clean 'testing' chroot, I get the following error: Building axe testing main amd64... Reading Package Lists... Building Dependency Tree... Package libxaw-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: libxaw7-dev libxaw6-dev E: Package libxaw-dev has no installation candidate E: Failed to satisfy Build-Depends dependency for axe: libxaw-dev The new version 6.1.2-14 in 'sid' does not have this problem. [...] Yes, I have already fixed this problem in 6.1.2-14, but it is not getting into testing. This package is non-free, and unfortunately that means people aren't very inclined to build it on the various archs for me. Have you asked the porter lists? The last three non-free packages that I asked people to build for RC bugfixes were all brought up-to-date in just a couple of days. Cc:ed to the lists for the archs in question. Also, I don't think this bug should affect the RC bug count for sarge, since it *is* non-free after all. Is there any reason for severity: serious here, other than the fact that the fixed package hasn't made it into testing yet? The only exception policy offers for non-free packages is: 2.2.3. The non-free section --- Packages must be placed in _non-free_ or _non-US/non-free_ if they are not compliant with the DFSG or are encumbered by patents or other legal issues that make their distribution problematic. In addition, the packages in _non-free_ and _non-US/non-free_ * must not be so buggy that we refuse to support them, and * must meet all policy requirements presented in this manual that it is possible for them to meet. [1] [1] It is possible that there are policy requirements which the package is unable to meet, for example, if the source is unavailable. These situations will need to be handled on a case-by-case basis. It is obviously possible for axe to have working build-depends here, therefore this requirement should not be waived. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: RFC and status report: Kernel upgrades for woody-sarge upgrades
Hi Carlos, On Mon, Mar 28, 2005 at 01:19:53PM -0500, Carlos O'Donell wrote: On Thu, Mar 24, 2005 at 02:08:25PM -0800, Steve Langasek wrote: On Thu, Mar 24, 2005 at 01:54:38PM +, Matthew Wilcox wrote: On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. It's all hppa machines, not just hppa64. Then why does the libc6 preinst say that the minimum kernel is 2.4.17 for parisc, and 2.4.19 for parisc64? If this is an error, it will need to be reconciled before release. It is not an error. I submitted the patch. Userspace requires a 32-bit kernel of atleast 2.4.17, and a 64-bit kernel of atleast 2.4.19. The 64-bit code has some orthogonal issues that took time to fix. Both could be made to require 2.4.19, and infact the upstream glibc patch set the requirement to 2.4.19. Well, requiring 2.4.19 for 32-bit would imply a need for additional upgrade testing; so if it's not actually needed, I think we're best off leaving glibc's preinst the way it is. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Please re-queue uw-imap for building
Could someone re-queue uw-imap for building on arm, s390, and hppa? The first build attempt failed on these archs due to a now-fixed bug in po-debconf (214397). Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: porting Mozart to alpha, arm, hppa, mipsel, s390
On Wed, Apr 10, 2002 at 04:25:48PM +0200, Denys Duchier wrote: Petter Reinholdtsen [EMAIL PROTECTED] writes: Part of the problem seem to be that the configure script tests for OS and architecture, not if the needed features are present or not. This of course makes it fail on all new OS/architecture combination, as well as old combinations when the feature set changes over time. This is not exactly the case. We do check for features (if I understand that term correctly), however features are not necessarily as reliable as you'd like and the inferences that you may draw from them vary depending on the platform. Thus we use knowledge about the platform (1) to conditionalize inferences (2) make platform specific inferences and guesses or override inferences that are known not to work. If you're checking for the *right* features, it's possible to guarantee that your code will work on all platforms that are encompassed by your feature checks, because ideally you have a direct mapping between the feature you're checking for in your configure-time script and what your code actually does at run-time. GNU autoconf provides a good framework for this, but using autoconf doesn't guarantee that you're using the right feature checks. I don't know that I can easily reconcile this with your desire to not accidentally support additional platforms; except to say that using autoconf to check for the actual features used by your program will make the job of new porters much easier, as well as making less work for you whenever a supported platform happens to change an interface. While transparently accommodating new OS/architectures is reasonably possible for most software, it is not realistic for a VM with complex memory management (tagged pointers, tagged data, GC), support for concurrent computations, and protocols to support distributed data, distributed computations, and mobile objects. Well, if the VM is fully virtual, it should be relatively easy to support all Linux architectures by generalizing your existing support -- the only major variables are word size and endianness.. HTH, Steve Langasek postmodern programmer pgphs6WBHb0qq.pgp Description: PGP signature
