Re: HPPA and Squeeze
On Mon, Jul 06, 2009 at 02:45:37PM -0400, John David Anglin wrote: I have to think that this has something to do with the machine being a rp3440 (large memory and cache). I have never seen this on my c3750 with 32-bit UP kernel. Also, this was with a 64-bit UP kernel. If I remember correctly, there's still some issues with the L2 cache on pa8800 that we haven't quite bothered to work out yet, since it's good enough for now. James probably knows more. It would be interesting to see if you could reproduce it with a UP 64-bit kernel on your C3750 to discount the L2 problems. regards, Kyle -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
On Wed, Apr 29, 2009 at 09:56:12AM -0600, dann frazier wrote: Unpacking busybox-udeb (from udebs/busybox-udeb.udeb) ... dpkg: error processing udebs/cdebconf-newt-terminal.udeb (--unpack): subprocess dpkg-split killed by signal (Segmentation fault) Errors were encountered while processing: udebs/cdebconf-newt-terminal.udeb make[2]: *** [stamps/tree-unpack-miniiso-stamp] Error 1 make[1]: *** [_build] Error 2 make: *** [build_miniiso] Error 2 Can you give me a recipe to build this by hand so I can try to reproduce on my two local boxes? I tried to reproduce on one of my machines last night, and didn't have any problems. Perhaps its an issue with the machine that does the daily build? Kyle: is this still your box? AFAIK, this is being done on a buildd box now, fjp messaged me on irc saying something to that effect, so I disabled the build on fattire. cheers, Kyle -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Tue, Dec 23, 2008 at 11:23:57AM +0100, Peter Palfrader wrote: Helge Deller schrieb am Dienstag, dem 23. Dezember 2008: Patch in parisc git tree: http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607 So just using an SMP kernel should also work? Yes, although there may be other problems with that... Anyway, my C3750 has been surviving building ruby-1.9 in a make make clean loop for the last 10 hours now on a uniprocessor kernel. regards. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Fri, Dec 19, 2008 at 05:19:46PM +0100, Peter Palfrader wrote: I know very little about hppa, but from what I read in this thread - which was surprisingly helpful so far - it's the kernel that makes stuff break on newer, faster hardware. And if we want to provide a stable and useful port to our users then that needs to get fixed. Not only so that we can build packages, but also so that users get a stable system. The ironic thing being on the very fastest machines, due to a fix in place to sort out some coherency issues, we don't see it at all, which is why it has taken so long to get fixed. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: irqbalance update in etch?
On Wed, Oct 01, 2008 at 03:12:38PM +0200, Peter Palfrader wrote: + * Non maintainer upload. + * irqbalance would segfault on startup when /proc/interrupts contains +an interrupt with a number of 256 or larger, since internally it +stored data in a fixed-length array. Newer versions (say 0.55) have +replaced the data structure with a list so this is fixed there. For +now we just skip interrupts with such high numbers, since it's the +least invasive approach during the stable cycle. + The patch looks fine to me. I mean, the machines with higher interrupts were crashing anyway, so simply chugging along ignoring them seems like an improvement. regards, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HPPA kernel issues (was: please push ruby1.9 1.9.0.2-4 to testing)
On Mon, Jul 21, 2008 at 05:17:02PM +0200, Frank Lichtenheld wrote: On Mon, Jul 21, 2008 at 03:37:06PM +0200, Peter Palfrader wrote: On Fri, 18 Jul 2008, Lucas Nussbaum wrote: Ruby 1.9 is still the development version of Ruby, but it will become the stable version in december. It's not really cutting-edge stuff anymore, and works very well everywhere else. I'm a bit annoyed by this issue: the problem seems to be a kernel problem, but nobody on the hppa side seems to have the time to work on it. I got access to Thibault Varene's farm, but when I tried, other hppa kernel problems were present. These kernel issues currently kill the two HPPA build daemons quite often - they are currently running 2.6.24-etchnhalf.1-parisc #2 Wed Jun 11 19:04:04 UTC 2008. Last week I had to reset them more often than I can count with my fingers without resorting to binary. Unless this gets fixed I don't see much of a future for peri and penalosa, at least not as DSA/debian.org systems. FWIW, the hppa experimental buildds both run 2.6.22 kernels and seem to do fine. Probably not a very good situation security-wise, though. I didn't manage to get any recent kernel to boot, yet... I seem to recall volunteering to admin these boxes, since it was pretty obvious that no one was giving them any love, but it fell on deaf ears. r, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
On Sun, Jun 08, 2008 at 09:46:17PM +0200, Andreas Barth wrote: Hi, I've waited a while to weigh in on this. Anyway, I don't particularly much care for stable releases. I have no problems with HPPA being punted from lenny and existing only as sid, as long as people still take patches to fix the issues without the release-critical bug burden over their heads. Holding up Debian because of a minority of people with a small amount of time to work on things doesn't seem entirely fair. I would encourage anyone who disagrees to step up and put actions before mails. regards, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Approval to upload gcc-defaults 1.70?
On Sun, Apr 20, 2008 at 08:23:42AM +0200, Martin Michlmayr wrote: * Grant Grundler [EMAIL PROTECTED] [2008-04-19 19:08]: This is a good idea - switch to gcc-4.3 for everything but the kernel. I didnt think this would be possible but I'm not sure why I thought that. We use gcc-4.1 for the kernel anyway, rather than the default compiler. fwiw, i'm comfortable with switching the kernel to gcc-4.2. i've been using it for kernels on all my boxes since around christmas, i believe (when i found problems with gcc-3.4 that made me move.) i haven't tried it on any older boxes (pa1.1 based) but it seems to be working well enough both 32-bit and 64-bit on my newer machines. cheers, kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Approval to upload gcc-defaults 1.70?
On Thu, Apr 17, 2008 at 12:33:08AM -0600, Grant Grundler wrote: On Wed, Apr 16, 2008 at 02:48:09PM +0200, Matthias Klose wrote: Grant Grundler writes: ... Has anyone built a kernel with this version of gcc-4.3 and tried it? Can I apt-get install -t sid gcc-4.3 on my hybrid system and get the right version? gcc-4.3 and gcc-4.3-hppa64 are both available in the same version in testing and unstable. This is what I tested the 2.6.25-rc6 kernel with: j6k:~# gcc-4.3 -v Using built-in specs. Target: hppa-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080309 (prerelease) (Debian 4.3.0-1) j6k:~# And during update (currently running), I pulled: Get:11 http://mirror.anl.gov testing/main gcc-4.3-hppa64 4.3.0-3 [3113kB] Get:12 http://mirror.anl.gov testing/main gcc-4.3-base 4.3.0-3 [105kB] So I'll rebuild a kernel with that tomorrow and report back if no one else can test that sooner. It's still broken, I tried today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#342545: qt-x11-free FTBFS
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. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] [Fwd: [patch/hppa] Floating point exception handling patch]
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? I can queue them on my private buildds... shouldn't take more than an afternoon. Cheers, Kyle pool/contrib/x/xmovie/xmovie_1.9.orig.tar.gz pool/main/f/fpc/fpc_1.9.4.orig.tar.gz pool/main/f/fpc/fpc_2.0.0.orig.tar.gz pool/main/g/gccchecker/gccchecker_0.9.9.1.20011205.orig.tar.gz pool/main/g/gnulib/gnulib_0.0.20051110.orig.tar.gz pool/main/h/helpviewer.app/helpviewer.app_0.3.orig.tar.gz pool/main/h/hercules/hercules_3.0.2.orig.tar.gz pool/main/h/hercules/hercules_3.03.1.orig.tar.gz pool/main/l/lg-issue40/lg-issue40_1.orig.tar.gz pool/main/l/lg-issue40/lg-issue40_2.orig.tar.gz pool/main/l/lsbappchk/lsbappchk_1.3.4.orig.tar.gz pool/main/m/manpages/manpages_1.39.orig.tar.gz pool/main/m/manpages/manpages_1.70.orig.tar.gz pool/main/m/manpages/manpages_2.17.orig.tar.gz pool/main/m/manpages-es/manpages-es_1.55.orig.tar.gz pool/main/m/manpages-fr/manpages-fr_0.9.3.orig.tar.gz pool/main/m/manpages-fr/manpages-fr_1.58.1.orig.tar.gz pool/main/m/manpages-fr/manpages-fr_1.67.0.orig.tar.gz pool/main/m/manpages-ja/manpages-ja_0.4.0.0.20020315.orig.tar.gz pool/main/m/manpages-ja/manpages-ja_0.5.0.0.20050315.orig.tar.gz pool/main/m/manpages-ja/manpages-ja_0.5.0.0.20051115.orig.tar.gz pool/main/m/manpages-pl/manpages-pl_20020406.orig.tar.gz pool/main/m/manpages-pl/manpages-pl_20051117.orig.tar.gz pool/main/m/manpages-pl/manpages-pl_20050320.orig.tar.gz pool/main/o/openmcl/openmcl_0.10.1.orig.tar.gz pool/main/o/openmcl/openmcl_0.14.2.p1.o.tar.gz pool/main/p/pspp/pspp_0.3.0.orig.tar.gz pool/main/p/pspp/pspp_0.4.0.orig.tar.gz pool/main/p/portmidi/portmidi_20041117.orig.tar.gz pool/main/q/qt-x11-free/qt-x11-free_3.3.4.orig.tar.gz pool/main/q/qt-x11-free/qt-x11-free_3.3.5.orig.tar.gz pool/main/q/qt4-x11/qt4-x11_4.1.0.orig.tar.gz pool/main/q/qt4-x11/qt4-x11_4.0.1.orig.tar.gz pool/main/t/tcc/tcc_0.9.23.orig.tar.gz pool/main/u/uclibc/uclibc_0.9.27.orig.tar.gz pool/non-free/m/manpages-posix/manpages-posix_1.67-3.tar.gz pool/non-free/m/manpages-posix/manpages-posix_2.16-1.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] [Fwd: [patch/hppa] Floating point exception handling patch]
On Mon, Jan 16, 2006 at 09:03:59AM -0800, Steve Langasek wrote: 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. You are, of course, correct. I'm clearly on drugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
3) an effort seems to be happening inside the upstream kernel to use the request_firmware infrastructure which allows to load firmware code from userland through an hotplug mechanism. There seem to be more and more drivers going this way, since there aare more in current git than in 2.6.15 which was released a week ago, qla2xxx being among them. And this seems like a good thing; for starters it makes it easier to test different firmware versions without having to do irrelevant recompiles of kernel code. The question is: when you remove the firmware from the driver, and all it is, is a file sitting in /lib/firmware/; and it's contents are just non-executable hex, with no C-code structure, is it just a BSD-licensed (in the qla2xxx case) data file, or is it still regarded as a piece of code. This, to me, is no different from a BSD licensed JPEG. I would argue it's the former. I can see the argument when it's a part of the source code, but not when it's a completely seperate entity. Of course, firmwares where the license has not been clarified by the copyright holder/IP owner would still be a problem; or where something is clearly unredistributable (ie: Intel IPW firmwares.) Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
