Re: HPPA and Squeeze
On Sun, Jul 12, 2009 at 10:52 AM, Carlos O'Donellcar...@systemhalted.org wrote: I'm building my own set of patches for debian-glibc, I'll tell you what my results are when I finish today. I had to restart the build last night, and it's building right now. I should have test results within 2 hours. I have trimmed debian-release from the CC. Thanks. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sun, Jun 21, 2009 at 06:55:21PM -0400, Carlos O'Donell wrote: On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarnoaurel...@aurel32.net wrote: On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote: On 06/16/2009 08:25 AM, Lucas Nussbaum wrote: On 15/06/09 at 11:31 -0600, Grant Grundler wrote: PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. In reality it's not (any longer) a hppa specific bug. It's a bug in ruby. Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa. The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable... BTW, Carlos, could you please send me the latest version of your patches, so that we can actually do the switch with version 2.10? The latest patches are now up. Core glibc patch: http://www.parisc-linux.org/~carlos/2009-06-20-glibc-hppa-nptl.diff Ports glibc patch: http://www.parisc-linux.org/~carlos/2009-06-20-glibc-ports-hppa-nptl.diff No regressions in the testsuite for hppa-linux-gnu. I have just included these patches in the eglibc-2.10 branch of our SVN, though currently the linuxthreads version is still built by default. I got the following regressions in the NPTL build compared to the linuxthreads build: | Encountered regressions that don't match expected failures: | tst-cancelx20.out, Error 1 | tst-cancelx21.out, Error 1 | tst-cancelx4.out, Error 1 | tst-cancelx5.out, Error 1 | tst-cleanupx4.out, Error 1 | tst-cputimer1.out, Error 1 | tst-cputimer2.out, Error 1 | tst-cputimer3.out, Error 1 | tst-mqueue3.out, Error 1 | tststatic2.out, Error 1 | tststatic.out, Error 1 | tst-timer4.out, Error 1 | tst-timer5.out, Error 1 | tst-tls9-static.out, Error 1 Is it something expected? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sun, Jul 12, 2009 at 8:30 AM, Aurelien Jarnoaurel...@aurel32.net wrote: I have just included these patches in the eglibc-2.10 branch of our SVN, though currently the linuxthreads version is still built by default. I got the following regressions in the NPTL build compared to the linuxthreads build: | Encountered regressions that don't match expected failures: | tst-cancelx20.out, Error 1 | tst-cancelx21.out, Error 1 | tst-cancelx4.out, Error 1 | tst-cancelx5.out, Error 1 | tst-cleanupx4.out, Error 1 These are expected regressions | tst-cputimer1.out, Error 1 | tst-cputimer2.out, Error 1 | tst-cputimer3.out, Error 1 | tst-mqueue3.out, Error 1 So are these. | tststatic2.out, Error 1 | tststatic.out, Error 1 These are not. | tst-timer4.out, Error 1 | tst-timer5.out, Error 1 These are. | tst-tls9-static.out, Error 1 This is not. I'm building my own set of patches for debian-glibc, I'll tell you what my results are when I finish today. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, Jul 6, 2009 at 10:43 PM, dann frazierda...@dannf.org wrote: da...@penalosa:~$ cat /proc/cpuinfo processor : 0 cpu family : PA-RISC 2.0 cpu : PA8700 (PCX-W2) cpu MHz : 750.00 model : 9000/785/J6700 model name : Duet W2 hversion : 0x5dd0 sversion : 0x0491 I-cache : 768 KB D-cache : 1536 KB (WB, direct mapped) ITLB entries : 240 DTLB entries : 240 - shared with ITLB bogomips : 1495.04 software id : 2001606322 This is very similar to my own box. In frustration I've started installing a buildd on my own a500. I might as well run a buildd to load the machine and see if any of the reported package FTBS crop up. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, 2009-07-06 at 21:47 -0400, John David Anglin wrote: 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. Googling, I see Grant had trouble with RCU_TORTURE_TEST=y. Probably, I should test current kernel to see if the problem is still present. I guess you are referring to this change: http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/ I'm thinking we must be missing a flush... Maybe in clear_user_page as for copy_user_page? Clear user page is very clever and doesn't need a flush. What it does is clear the page through the users cache rather than the kernel's ... what it actually does is place zeros in the cache above the physical page, so the user can only access the zeros ... they eventually get cleaned back to the page as the cache empties. Do the problematic debian buildd machines have pa8800/pa8900 processors? No boxes outside of the cupertino test ring and a few giveaways (you, kyle and t-bone, I think) have pa88/8900 cpus. My sense is that some change (probably to the core memory management code) made the coherence issue worse post 2.6.22.x. So if I characterise the problem you think you're seeing: on mmap of a file at a memory location to be determined by the kernel, a sequential set of reads of the mapped location eventually turns up a zero where there should be data? Yes, it does sound like a caching issue. James -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
So if I characterise the problem you think you're seeing: on mmap of a
file at a memory location to be determined by the kernel, a sequential
set of reads of the mapped location eventually turns up a zero where
there should be data? Yes, it does sound like a caching issue.
Yes. The loop is terminated by a null tag:
while (dyn-d_tag != DT_NULL)
{
...
}
However, the core dump doesn't show a null tag before the STRTAB tag
that caused the segmentation fault.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jul 7, 2009 at 12:21 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
So if I characterise the problem you think you're seeing: on mmap of a
file at a memory location to be determined by the kernel, a sequential
set of reads of the mapped location eventually turns up a zero where
there should be data? Yes, it does sound like a caching issue.
Yes. The loop is terminated by a null tag:
while (dyn-d_tag != DT_NULL)
{
...
}
However, the core dump doesn't show a null tag before the STRTAB tag
that caused the segmentation fault.
Do you mean after the STRTAB tag? I assume the library on-disk has a
DT_NULL, otherwise it would always fail.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jul 7, 2009 at 6:07 PM, John David Anglind...@hiauly1.hia.nrc.ca wrote: I would guess that the loop terminated early because the l_info array is all zeros except for the first NEEDED entry. It appears correct. The loop might have terminated early because of a cache issue, or possibly the value loaded from memory somehow got corrupted. Another possibility would be the mmap operation wasn't complete when the memory was examined by the dynamic loader. When the core dump was done, the operation was complete. I think it's less likely that a cache issue affected the memory used by the dynamic loader (l_info field) as the data before and after in the map seemed reasonable. The fact PA8700 processors are also experiencing similar problems would seem to suggest that this isn't a PA8800 L2 issue unless we have multiple problems. I think we need to try running a recent kernel on gsyprf11 for a while to see if we can capture a similar event. This rang a bell... In glibc/elf/rtld.c we have this: /* Partly clean the `bootstrap_map' structure up. Don't use `memset' since it might not be built in or inlined and we cannot make function calls at this point. Use '__builtin_memset' if we know it is available. We do not have to clear the memory if we do not have to use the temporary bootstrap_map. Global variables are initialized to zero by default. */ #ifndef DONT_USE_BOOTSTRAP_MAP # ifdef HAVE_BUILTIN_MEMSET __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l_info)); # else for (size_t cnt = 0; cnt sizeof (bootstrap_map.l_info) / sizeof (bootstrap_map.l_info[0]); ++cnt) bootstrap_map.l_info[cnt] = 0; # endif On hppa we don't have builtin memset (probably one of the few arches), so we fall back on this weird loop which I always thought was wrong. I was seeing problems with l_info having garbage in it, so I had a local hack which cleared the entire bootstrap_map. Did your l_info come from the bootstrap_map? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jul 7, 2009 at 6:07 PM, John David Anglind...@hiauly1.hia.nrc.ca wrote: I would guess that the loop terminated early because the l_info array is all zeros except for the first NEEDED entry. =A0It appears correct. = =A0The loop might have terminated early because of a cache issue, or possibly the value loaded from memory somehow got corrupted. =A0Another possibilit= y would be the mmap operation wasn't complete when the memory was examined by the dynamic loader. =A0When the core dump was done, the operation was complete. I think it's less likely that a cache issue affected the memory used by the dynamic loader (l_info field) as the data before and after in the map seemed reasonable. The fact PA8700 processors are also experiencing similar problems would seem to suggest that this isn't a PA8800 L2 issue unless we have multiple problems. I think we need to try running a recent kernel on gsyprf11 for a while to see if we can capture a similar event. This rang a bell... In glibc/elf/rtld.c we have this: /* Partly clean the `bootstrap_map' structure up. Don't use `memset' since it might not be built in or inlined and we cannot make function calls at this point. Use '__builtin_memset' if we know it is available. We do not have to clear the memory if we do not have to use the temporary bootstrap_map. Global variables are initialized to zero by default. */ #ifndef DONT_USE_BOOTSTRAP_MAP # ifdef HAVE_BUILTIN_MEMSET __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l_inf= o)); # else for (size_t cnt =3D 0; cnt sizeof (bootstrap_map.l_info) / sizeof (bootstrap_map.l_info[0= ]); ++cnt) bootstrap_map.l_info[cnt] =3D 0; # endif On hppa we don't have builtin memset (probably one of the few arches), so we fall back on this weird loop which I always thought was wrong. I was seeing problems with l_info having garbage in it, so I had a local hack which cleared the entire bootstrap_map. Did your l_info come from the bootstrap_map? No. The l_info fields for the dynamic loader and libncurses.so.5 had already been processed. The segv occurred processing the needed entry for libdl.so.2. The code was processing the needed entries for /bin/sh. The cause of the corruption that you observed is not obvious to me. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
I seem to recall that the kernel mmap implementation on hppa is somewhat unique. I don't recall anything, Kyle? This came up with respect to the GCC PCH implementation for parisc. See comments in host-hpux.h. At the moment, we do have a PCH related bug. See PR 39355. While I know the problem is present in the PCH file, I haven't been able to figure out how wrong data gets in the file. There are some limitations on hppa if a file is both opened for reading (via read()) and written to via a mmap'ed mapping. This came up a few years ago. Does gcc do this? Not that I am aware of. The situation is essentially the reverse of the above. Data is written from a region of memory. Then, in another instance of gcc, it needs to be mmap'ed back to the same location in memory. In theory, it could be brought back to a different location but this would require a fairly complex set of relocations. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, Jul 6, 2009 at 9:28 AM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
Not that I am aware of. The situation is essentially the reverse of
the above. Data is written from a region of memory. Then, in another
instance of gcc, it needs to be mmap'ed back to the same location in
memory. In theory, it could be brought back to a different location
but this would require a fairly complex set of relocations.
GCC does not read() and write to the mmap()'d file.
The dynamic loader uses MAP_DENYWRITE to avoid writing into the mmap()'d memory.
I will reiterate my point here that the dynamic linker the first user
of mmap in a newly started process, and the first program to read and
process data from the mmap'd files. Therefore the dynamic linker is
always the first to suffer if a mapped region of memory is not
correct.
What we need to do here is create a test case.
I tried this:
1. cp /lib/libc.so.6 original.so
2. cp /lib/libc.so.6 map.so
3. gcc -O2 -g -o test-mmap test-mmap.c
4. while true; do ./test-mmap ./original.so ./map.so; done;
The test mmap's a file and compares it to the original, aborting if
the comparison fails. I've yet to see it abort on my a500, and I've
run 20-30 instances of the test simultaneously. Then again I don't see
any serious segv's like others do (2.6.26-1-parisc64-smp).
What might be a better testcase?
Cheers,
Carlos.
#include stdio.h
#include stdlib.h
#include sys/mman.h /* mmap */
#include sys/types.h /* open */
#include sys/stat.h /* open */
#include fcntl.h /* open */
#include unistd.h /* lseek */
#define BMAX 4096
int
main (int argc, char **argv)
{
void *mappref;
int fd, fdc;
off_t maplength, index, j;
char *original = argv[1], *copy = argv[2];
char buf[BMAX], *mbuf;
ssize_t ret;
/* Open original file to compute size. We open the original
file to simulate having the fd open before mmap as the
dynamic loader does. */
fd = open (original, O_RDONLY);
if (fd == -1)
{
perror (open);
abort ();
}
maplength = lseek (fd, 0, SEEK_END);
if (fd == -1)
{
perror (lseek);
abort ();
}
/* Now mmap the open file. */
mappref = mmap ((void *)mappref,
maplength,
PROT_READ | PROT_EXEC,
MAP_PRIVATE | MAP_DENYWRITE | MAP_FILE,
fd,
0);
if (mappref == (void *)-1)
{
perror (mmap);
abort ();
}
mbuf = (char *)mappref;
/* Compare mmap to copy. */
fdc = open (copy, O_RDONLY);
if (fdc == -1)
{
perror (open #2);
abort ();
}
for (index = 0; index maplength; index += BMAX)
{
ret = read (fdc, buf[0], BMAX);
if ((ret != BMAX) (ret == -1))
{
perror (read);
abort ();
}
for (j = 0; ((j BMAX) ((index + j) maplength)); j++)
{
if (mbuf[index + j] != buf[j])
{
fprintf(stderr, Mismatch at %ld, read %d, expected %d\n,
index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
abort ();
}
if (DEBUG)
printf (Match at %ld, read %d, expected %d\n,
index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
}
}
return 0;
}
Re: HPPA and Squeeze
I will reiterate my point here that the dynamic linker the first user of mmap in a newly started process, and the first program to read and process data from the mmap'd files. Therefore the dynamic linker is always the first to suffer if a mapped region of memory is not correct. That is true to a certain extent. However, there are large portions of code and initialized data that it doesn't touch. I don't think that I've ever seen an invalid instruction fault. So, I'm not fully convinced that we understand the cause of these segvs. As far as I can tell, the mmap'd data appears correct (at least as far as what was recorded in the core file). What is wrong is the l_info field in the linker map. Prior to failing on processing libdl.so.2, it had successfully processed itself and libncurses.so.5 (see NEEDED entries for /bin/sh). There isn't a lot that happens between mmap'ing the file and the access to the STRTAB entry in the l_info field. The NEEDED entry at l_info[1] seems ok in the dump. I doubt this is a TLB issue as the data is a long way from page boundaries. Possibly, there is a cache line issue in the mmap'd file, or as I suggested before a race condition and the file isn't fully mapped when the mmap call returns. In any case, the extraction of the dynamic data failed after doing the first NEEDED entry. 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. What we need to do here is create a test case. I tried this: 1. cp /lib/libc.so.6 original.so 2. cp /lib/libc.so.6 map.so 3. gcc -O2 -g -o test-mmap test-mmap.c 4. while true; do ./test-mmap ./original.so ./map.so; done; The test mmap's a file and compares it to the original, aborting if the comparison fails. I've yet to see it abort on my a500, and I've run 20-30 instances of the test simultaneously. Then again I don't see any serious segv's like others do (2.6.26-1-parisc64-smp). What might be a better testcase? I typically run my GCC builds with `make -j 4'. So, there's a mix of other stuff actively running at any time. I'll give the testcase a try tonight. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
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. Googling, I see Grant had trouble with RCU_TORTURE_TEST=y. Probably, I should test current kernel to see if the problem is still present. I guess you are referring to this change: http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/ I'm thinking we must be missing a flush... Maybe in clear_user_page as for copy_user_page? Do the problematic debian buildd machines have pa8800/pa8900 processors? My sense is that some change (probably to the core memory management code) made the coherence issue worse post 2.6.22.x. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, Jul 06, 2009 at 09:47:09PM -0400, John David Anglin wrote: 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. Googling, I see Grant had trouble with RCU_TORTURE_TEST=y. Probably, I should test current kernel to see if the problem is still present. I guess you are referring to this change: http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/ I'm thinking we must be missing a flush... Maybe in clear_user_page as for copy_user_page? Do the problematic debian buildd machines have pa8800/pa8900 processors? da...@penalosa:~$ cat /proc/cpuinfo processor : 0 cpu family: PA-RISC 2.0 cpu : PA8700 (PCX-W2) cpu MHz : 750.00 model : 9000/785/J6700 model name: Duet W2 hversion : 0x5dd0 sversion : 0x0491 I-cache : 768 KB D-cache : 1536 KB (WB, direct mapped) ITLB entries : 240 DTLB entries : 240 - shared with ITLB bogomips : 1495.04 software id : 2001606322 My sense is that some change (probably to the core memory management code) made the coherence issue worse post 2.6.22.x. Dave -- dann frazier -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On 07/05/2009 01:34 AM, John David Anglin wrote: On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote: On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote: Did something change to peri? I'm currently only seeing them on penalosa. UP kernel, maybe? Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I can tell run on identical hardware. I tried a SMP kernel (2.6.30.1 with the patch set posted earlier) on my rp34404. Fired up a GCC build. It didn't take more than a few minutes to trigger a couple of segvs in /bin/sh. On the other hand, I ran a UP version of 2.6.30 for more than a week without any major problems. So, instead of just complaining, wouldn't it be useful if someone with root access would install a UP kernel (and disable nscd) for the time being on the build servers? That way we all would avoid debian build problems and could concentrate on solving the issues with the SMP kernel itself. In the meantime, all (IMHO) major kernel patches have now been included in Linus' 2.6.31-rc2 kernel and I plan to backport and send them to the stable-kernel team for inclusion into 2.6.29 and 2.6.30 stable kernel series. Helge -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sun, Jul 05, 2009 at 11:06:52AM +0200, Helge Deller wrote: On 07/05/2009 01:34 AM, John David Anglin wrote: On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote: On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote: Did something change to peri? I'm currently only seeing them on penalosa. UP kernel, maybe? Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I can tell run on identical hardware. I tried a SMP kernel (2.6.30.1 with the patch set posted earlier) on my rp34404. Fired up a GCC build. It didn't take more than a few minutes to trigger a couple of segvs in /bin/sh. On the other hand, I ran a UP version of 2.6.30 for more than a week without any major problems. So, instead of just complaining, wouldn't it be useful if someone with root access would install a UP kernel (and disable nscd) for the time being on the build servers? That way we all would avoid debian build problems and could concentrate on solving the issues with the SMP kernel itself. In the meantime, all (IMHO) major kernel patches have now been included in Linus' 2.6.31-rc2 kernel and I plan to backport and send them to the stable-kernel team for inclusion into 2.6.29 and 2.6.30 stable kernel series. HPPA folks, can you please convert at least one buildd to a UP configuration? I have another example of extreme buildd flakiness mentioned in bug #529485. Adam C Powell IV hazel...@debian.org writes: That's too bad. I saw 6 attempts to do 3.0.0-X of which two passed the first try and four failed. At that rate (1/3), it would take nine attempts to have a decent chance of passing both rounds (debug static and optimized shared/static). HPPA is the only arch for which petsc failed to build, and currently this blocks petsc transition. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
That way we all would avoid debian build problems and could concentrate on solving the issues with the SMP kernel itself. The problem actually may be present in UP kernels. I had a segv this morning building GCC with a UP 2.6.30.1: ad...@mx3210:~/gnu/gcc/objdir/hppa-linux/libjava$ gdb -c core /bin/sh GNU gdb (GDB) 6.8.50.20090510-cvs Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as hppa-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... (no debugging symbols found) BFD: Warning: /home/dave/gnu/gcc/objdir/hppa-linux/libjava/core is truncated: expected core file size = 196608, found: 118784. Reading symbols from /lib/ld.so.1...Reading symbols from /usr/lib/debug/lib/ld-2.9.so...done. done. Loaded symbols for /lib/ld.so.1 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.9.so...done. done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.9.so...done. done. Loaded symbols for /lib/libc.so.6 Core was generated by `/bin/sh -c /home/dave/gnu/gcc/gcc/mkinstalldirs `dirname gnu/java/locale/Locale'. Program terminated with signal 11, Segmentation fault. #0 _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12, trace_mode=0, open_mode=0) at dl-deps.c:224 224 dl-deps.c: No such file or directory. in dl-deps.c (gdb) bt #0 _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12, trace_mode=0, open_mode=0) at dl-deps.c:224 #1 0x403b9bd4 in dl_main (phdr=0x10034, phnum=value optimized out, user_entry=value optimized out) at rtld.c:1780 #2 0x403cb898 in _dl_sysdep_start (start_argptr=value optimized out, dl_ma...@0x403d7566: 0x403b8fe4 dl_main) at ../elf/dl-sysdep.c:239 #3 0x403b785c in _dl_start_final (arg=0xbfff2020, info=0xbfff2348) at rtld.c:332 #4 0x403b7adc in _dl_start (arg=0xbfff2020) at rtld.c:560 #5 0x403b742c in _start () from /lib/ld.so.1 #6 0x403b742c in _start () from /lib/ld.so.1 #7 0x403b742c in _start () from /lib/ld.so.1 #8 0x403b742c in _start () from /lib/ld.so.1 #9 0x403b742c in _start () from /lib/ld.so.1 #10 0x403b742c in _start () from /lib/ld.so.1 #11 0x403b742c in _start () from /lib/ld.so.1 #12 0x403b742c in _start () from /lib/ld.so.1 #13 0x403b742c in _start () from /lib/ld.so.1 #14 0x403b742c in _start () from /lib/ld.so.1 #15 0x403b742c in _start () from /lib/ld.so.1 #16 0x403b742c in _start () from /lib/ld.so.1 ^CQuit For some reason, gdb does terminate the backtrace. Recent versions of gdb also complain about core file truncation. Think the full stack region is not being dumped. As with most of the segvs that I have debugged in the past, the problem occurs in the dynamic loader. This is the tombstone: Jul 5 04:07:31 mx3210 kernel: Jul 5 04:07:31 mx3210 kernel: do_page_fault() pid=22068 command='sh' type=15 address=0x0004 Jul 5 04:07:31 mx3210 kernel: Jul 5 04:07:31 mx3210 kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI Jul 5 04:07:31 mx3210 kernel: PSW: 0100 Not taintedJul 5 04:07:31 mx3210 kernel: r00-03 0004000f 403d76a0 000 0403c2c23 bfff2ac0 Jul 5 04:07:31 mx3210 kernel: r04-07 403d76a0 000c 000 040001398 403b0dc0 Jul 5 04:07:31 mx3210 kernel: r08-11 0002 000 04e88 bfff2d08 Jul 5 04:07:31 mx3210 kernel: r12-15 4037e4b4 bfff2c48 403d76a0 0004 Jul 5 04:07:31 mx3210 kernel: r16-19 bfff2c08 bfff2bc8 bfff2b88 403d76a0 Jul 5 04:07:31 mx3210 kernel: r20-23 bfff2d0f 40002000 0001 Jul 5 04:07:31 mx3210 kernel: r24-27 000c 40001398 400013a8 000365e8 Jul 5 04:07:31 mx3210 kernel: r28-31 24242424 bfff2e00 403c45c3 Jul 5 04:07:31 mx3210 kernel: sr00-03 e800 e800 e800 Jul 5 04:07:31 mx3210 kernel: sr04-07 e800 e800 e800 e800 Jul 5 04:07:31 mx3210 kernel: Jul 5 04:07:31 mx3210 kernel: VZOUICununcqcqcqcqcqcrmunTDVZOUI Jul 5 04:07:31 mx3210 kernel: FPSR: Jul 5 04:07:31 mx3210 kernel: FPER1: Jul 5 04:07:31 mx3210 kernel: fr00-03 Jul 5 04:07:31 mx3210 kernel: fr04-07 f000 ff9c
Re: HPPA and Squeeze
Register $r10 contains the address of the next link map:
(gdb) p (*preloads)-l_next
$10 = (struct link_map *) 0x4e88
(gdb) p *(*preloads)-l_next
$11 = {l_addr = 1076473856, l_name = 0x4e78 /lib/libdl.so.2,
l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x4bf0,
l_real = 0x4e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0,
0x4029e5fc, 0x0 repeats 74 times}, l_phdr = 0x4029b034,
l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8,
r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0,
l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0,
l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0,
l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0,
l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0,
l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0,
l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0},
l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 /lib,
l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240,
l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4,
l_scope = 0x40001040, l_local_scope = {0x4fe4, 0x0}, l_dev = 536937216,
l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0},
l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0,
l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0,
fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0,
value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0,
l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0,
l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0,
l_serial = 3, l_audit = 0x400010d8}
When I run the command directly under gdb, the info is a different location
and the string table entry is not null:
(gdb) bt
#0 _dl_map_object_deps (map=0x403d8880, preloads=0x40001170, npreloads=12,
trace_mode=0, open_mode=0) at dl-deps.c:224
#1 0x403b9bd4 in dl_main (phdr=0x10034, phnum=value optimized out,
user_entry=value optimized out) at rtld.c:1780
#2 0x403cb898 in _dl_sysdep_start (start_argptr=value optimized out,
dl_ma...@0x403d7566: 0x403b8fe4 dl_main) at ../elf/dl-sysdep.c:239
#3 0x403b785c in _dl_start_final (arg=0xbff01028, info=0xbff01188)
at rtld.c:332
#4 0x403b7adc in _dl_start (arg=0xbff01028) at rtld.c:560
(gdb) p *(*preloads)-l_next
$2 = {l_addr = 1076473856, l_name = 0x4c50 /lib/libdl.so.2,
l_ld = 0x4029e5fc, l_next = 0x4ef0, l_prev = 0x49c8,
l_real = 0x4c60, l_ns = 0, l_libname = 0x4eb4, l_info = {0x0,
0x4029e604, 0x4029e66c, 0x4029e664, 0x4029e634, 0x4029e644, 0x4029e64c,
0x4029e684, 0x4029e68c, 0x4029e694, 0x4029e654, 0x4029e65c, 0x4029e614,
0x4029e61c, 0x4029e60c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4029e674, 0x0, 0x0,
0x4029e67c, 0x0, 0x4029e624, 0x0, 0x4029e62c, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x4029e6b4, 0x4029e6ac, 0x4029e6a4, 0x4029e69c, 0x0, 0x0, 0x4029e6c4,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4029e6bc,
0x0 repeats 25 times, 0x4029e63c}, l_phdr = 0x4029b034,
l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x4eb0,
r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0,
l_nbuckets = 22, l_gnu_bitmask_idxbits = 3, l_gnu_shift = 7,
l_gnu_bitmask = 0x4029b144, {l_gnu_buckets = 0x4029b154,
l_chain = 0x4029b154}, {l_gnu_chain_zero = 0x4029b148,
l_buckets = 0x4029b148}, l_direct_opencount = 0, l_type = lt_library,
l_relocated = 0, l_init_called = 0, l_global = 0, l_reserved = 1,
l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, l_need_tls_init = 0,
l_used = 0, l_auditing = 0, l_audit_any_plt = 0, l_removed = 0,
l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0},
l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x4ed0 /lib,
l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240,
l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4,
l_scope = 0x4e18, l_local_scope = {0x4dbc, 0x0}, l_dev = 536937216,
l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0},
l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0,
l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0,
fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0,
value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0,
l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0,
l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0,
l_serial = 3, l_audit = 0x4eb0}
Dave
--
J. David Anglin
Re: HPPA and Squeeze
(gdb) p *(*preloads)-l_next
$11 = {l_addr = 1076473856, l_name = 0x4e78 /lib/libdl.so.2,
l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x4bf0,
l_real = 0x4e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0,
0x4029e5fc, 0x0 repeats 74 times}, l_phdr = 0x4029b034,
l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8,
r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0,
l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0,
l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0,
l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0,
l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0,
l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0,
l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0},
l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 /lib,
l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240,
l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4,
l_scope = 0x40001040, l_local_scope = {0x4fe4, 0x0}, l_dev = 536937216,
l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0},
l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0,
l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0,
fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0,
value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0,
l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0,
l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0,
l_serial = 3, l_audit = 0x400010d8}
(gdb) p (*preloads)-l_next-l_info
$14 = (Elf32_Dyn *(*)[76]) 0x4ea8
(gdb) p (*preloads)-l_next-l_info
$15 = {0x0, 0x4029e5fc, 0x0 repeats 74 times}
(gdb) p/x 0x4ea8 + 5 * 4
$17 = 0x4ebc
So, the segmentation fault was caused by a 0x0 in the l_info field of
the link map for /lib/libdl.so.2.
After staring at the dynamic loader code for a while, I think the following
mmap call in dl-load.c doesn't correctly map the info data for /lib/libdl.so.2.
/* Remember which part of the address space this object uses. */
l-l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength,
c-prot,
MAP_COPY|MAP_FILE,
fd, c-mapoff);
The info data is near the end of the mapped segment. The l_info field
is initialized by elf_get_dynamic_info from the dynamic data mapped
at l-ld.
I seem to recall that the kernel mmap implementation on hppa is somewhat
unique.
In the above call, mappref is NULL. The kernel selects the map location.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
--
To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sun, Jul 5, 2009 at 7:07 PM, John David Anglind...@hiauly1.hia.nrc.ca wrote: After staring at the dynamic loader code for a while, I think the following mmap call in dl-load.c doesn't correctly map the info data for /lib/libdl.so.2. /* Remember which part of the address space this object uses. */ l-l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength, c-prot, MAP_COPY|MAP_FILE, fd, c-mapoff); The info data is near the end of the mapped segment. The l_info field is initialized by elf_get_dynamic_info from the dynamic data mapped at l-ld. Why do you think this is wrong? I seem to recall that the kernel mmap implementation on hppa is somewhat unique. I don't recall anything, Kyle? In the above call, mappref is NULL. The kernel selects the map location. Yes, that's probably correct, the loader is letting the kernel choose the address, at this point we don't care where the library is loaded. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
The info data is near the end of the mapped segment. =A0The l_info field is initialized by elf_get_dynamic_info from the dynamic data mapped at l-ld. Why do you think this is wrong? I don't know about the specifics. My supposition is that we may not be copying the entire segment depending on where the map is placed. I seem to recall that the kernel mmap implementation on hppa is somewhat unique. I don't recall anything, Kyle? This came up with respect to the GCC PCH implementation for parisc. See comments in host-hpux.h. At the moment, we do have a PCH related bug. See PR 39355. While I know the problem is present in the PCH file, I haven't been able to figure out how wrong data gets in the file. In the above call, mappref is NULL. =A0The kernel selects the map locatio= n. Yes, that's probably correct, the loader is letting the kernel choose the address, at this point we don't care where the library is loaded. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sun, 2009-07-05 at 20:17 -0400, John David Anglin wrote: The info data is near the end of the mapped segment. =A0The l_info field is initialized by elf_get_dynamic_info from the dynamic data mapped at l-ld. Why do you think this is wrong? I don't know about the specifics. My supposition is that we may not be copying the entire segment depending on where the map is placed. Who is supposed to copy the segment? The user or the kernel? As far as I can tell, the kernel is responsible for mapping the segment. Then, elf_get_dynamic_info processes the mapped data to generate the l_info field in the link map. The kernel has control over where the segment is mapped. In as much as the dependencies for /bin/sh are processed many times in a GCC build, I have to think the problem relates to the placement or a random problem with mmap. There is a small possibility that the processing of the data by elf_get_dynamic_info has a problem. I seem to recall that the kernel mmap implementation on hppa is somewhat unique. I don't recall anything, Kyle? This came up with respect to the GCC PCH implementation for parisc. See comments in host-hpux.h. At the moment, we do have a PCH related bug. See PR 39355. While I know the problem is present in the PCH file, I haven't been able to figure out how wrong data gets in the file. Do you have a bugzilla reference so we can take a look ... also, is this likely a tool chain problem or a kernel one? If it's a kernel one could someone provide a description of what they think is going wrong? The bugzilla reference is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355. Many of my comments in the PR are wrong. See comment #47. At this time, I know that the data in the PCH file are wrong but I don't know why. In any case, I should not have mentioned the PCH bug. It's probably a tool chain bug. The main point of the comment was that the hppa mmap implementation differs from other implementations (MAP_PRIVATE is not reliable). So, there may be other issues. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sat, Jul 04, 2009 at 03:52:16PM -0400, John David Anglin wrote: And then there is glob2 that fails with: /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2 /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3 4.3.3-10, or with my own binutils build on two different systems. The above shouldn't happen as the text size of FileManager.o is well below the size where a 17-bit branch can't reach the stub table. Possibly, the stub table is full. On the otherhand, the f9bf_memcpy@@GLIBC_2.2+0 string looks garbled. So, this may be another form of the SMP memory corruption that causes the segvs, particularly if it isn't reproducible on the build system. It actually already failed twice on the same system with the same error. I've just let it retry again, we'll see if it fails again. The log file show this is with: gcc-4.3 4.3.3-13 / 4.3.3-11 binutils 2.19.1-1 Kurt -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sat, Jul 04, 2009 at 11:03:01PM +0200, Kurt Roeckx wrote: On Sat, Jul 04, 2009 at 03:52:16PM -0400, John David Anglin wrote: And then there is glob2 that fails with: /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2 /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3 4.3.3-10, or with my own binutils build on two different systems. The above shouldn't happen as the text size of FileManager.o is well below the size where a 17-bit branch can't reach the stub table. Possibly, the stub table is full. On the otherhand, the f9bf_memcpy@@GLIBC_2.2+0 string looks garbled. So, this may be another form of the SMP memory corruption that causes the segvs, particularly if it isn't reproducible on the build system. It actually already failed twice on the same system with the same error. I've just let it retry again, we'll see if it fails again. And it failed again with the same error, on peri now. Kurt -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jun 19, 2009 at 05:43:24PM +0200, Philipp Kern wrote: On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: Here is a list of packages that failed to build because of instability on the buildds today: package | buildd | error qgit| penalosa | make: *** [install] Segmentation fault acpica-unix | peri | make: *** [install] Segmentation fault I had those random segfaults in make on paer too, until we switched to the UP kernel, at least from what I saw. Did something change to peri? I'm currently only seeing them on penalosa. Failed logs the past few days: Jun 22 | wesnoth| penalosa | quilt segfaults Jun 22 | gitg | penalosa | quilt segfaults Jun 23 | zita-convolver | penalosa | quilt segfaults Jun 25 | autodocksuite | penalosa | make segfaults Jun 26 | mpd| penalosa | find segfaults? Jun 30 | scorched3d | penalosa | make segfaults Jun 30 | libtext-bibtex-perl| penalosa | make segfaults Jun 30 | gnome-chemistry-utils | penalosa | libtool segfaults Jul 01 | openmsx-catapult | penalosa | make segfaults Jul 01 | prima | penalosa | make segfaults Jul 01 | fvwm | penalosa | gcc says as had a segfault Jul 01 | cherokee | penalosa | quilt segfaults Jul 03 | vflib3 | penalosa | make segfaults Jul 03 | rpy2 | penalosa | make segfaults Jul 03 | debian-installer-utils | penalosa | make segfaults On other that looks weird is, all also on penalosa: - scid, seems to have been stuck in a cp. - postgresql-8.3, not sure what the error is - building gnome-system-monitor, openssh-client failed to install in it's postinst script calling update-alternatives And then there is glob2 that fails with: /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2 /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Kurt -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote: On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote: Did something change to peri? I'm currently only seeing them on penalosa. UP kernel, maybe? Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I can tell run on identical hardware. Kurt -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Luk Claes schrieb: Matthias Klose wrote: Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. There are issues with the hppa port where the release team considered dropping it since 2005 communicated to the porter list... hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? I'm not aware of current toolchain issues on sparc and the issues on mips* still seem to be manageable, no? sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests to move to v9 optimization by default, which requires some work in the compiler. I don't plan to update this for upcoming GCC versions, and there's no interest by upstream to help with this kind of setup. You can't buy v8 software for years now, but afaik all our machines run 64bit kernels. Maybe it's time to acknowledge this, remove sparc from the list of release architectures and go on with sparc64? there are currently binutils issues outstanding, reported upstream. plus the non-availability of developer machines seems to be an issue. Sadly we don't have the mips support for squeeze as we had for lenny. there are issues pointed out and not addressed like the -dev / -headers packages built as binary independent packages just to save disk space, which have an impact on slow architectures, and which are not addressed by the release team. would the release team mind addressing these real issues, or should we drop slow architectures as well? Well, this Packages issue is clearly a responsability from the FTP Team and the Release Team would indeed be very happy to have that resolved. So it seems to be ok to ignore an issue, if you can work around it? Fine, then I'll build all compiler front ends from one source again. Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarnoaurel...@aurel32.net wrote: On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote: On 06/16/2009 08:25 AM, Lucas Nussbaum wrote: On 15/06/09 at 11:31 -0600, Grant Grundler wrote: PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. In reality it's not (any longer) a hppa specific bug. It's a bug in ruby. Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa. The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable... BTW, Carlos, could you please send me the latest version of your patches, so that we can actually do the switch with version 2.10? The latest patches are now up. Core glibc patch: http://www.parisc-linux.org/~carlos/2009-06-20-glibc-hppa-nptl.diff Ports glibc patch: http://www.parisc-linux.org/~carlos/2009-06-20-glibc-ports-hppa-nptl.diff No regressions in the testsuite for hppa-linux-gnu. No failures in my custom testsuite for the transition. However, the usability testing in a chroot + vnc is showing that some applications are segfaulting. I've been looking into this today. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: So it's my understanding that the porters have no idea about the problems. So I will start to mail you about problems as soon as I see them and they look like porting issues specific to hppa. netgen fails to built with an internal compiler error since atleast April 2008. Logs are at: https://buildd.debian.org/build.cgi?pkg=netgen;ver=4.4-15;arch=hppa https://buildd.debian.org/build.cgi?pkg=netgen;arch=hppa Kurt -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: So it's my understanding that the porters have no idea about the problems. So I will start to mail you about problems as soon as I see them and they look like porting issues specific to hppa. Ruby1.9 hangs in test_thread.rb and gets killed after 150 minutes of inactivity. I assume NPTL will fix this. Kurt -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: So it's my understanding that the porters have no idea about the problems. So I will start to mail you about problems as soon as I see them and they look like porting issues specific to hppa. netgen fails to built with an internal compiler error since atleast April 2008. Logs are at: https://buildd.debian.org/build.cgi?pkg=netgen;ver=4.4-15;arch=hppa https://buildd.debian.org/build.cgi?pkg=netgen;arch=hppa g++ -c -I. -I../libsrc/interface -Iinclude -O2 -I/usr/include/GL -I/usr/include/tcl8.4 -I/usr/include/tk8.4 -I/usr/X11R6/include -DLINUX -DOPENGL -DNGSOLVE basiclinalg/cholesky.cpp basiclinalg/calcinverse.cpp basiclinalg/vecmat.cpp basiclinalg/bandmatrix.cpp basiclinalg/eigensystem.cpp linalg/basevector.cpp linalg/vvector.cpp linalg/basematrix.cpp linalg/sparsematrix.cpp linalg/special_matrix.cpp linalg/cg.cpp linalg/chebyshev.cpp linalg/eigen.cpp linalg/order.cpp linalg/sparsecholesky.cpp linalg/pardisoinverse.cpp linalg/superluinverse.cpp linalg/jacobi.cpp linalg/blockjacobi.cpp linalg/commutingAMG.cpp ngstd/exception.cpp ngstd/table.cpp ngstd/bitarray.cpp ngstd/flags.cpp ngstd/symboltable.cpp ngstd/blockalloc.cpp ngstd/evalfunc.cpp ngstd/templates.cpp ngstd/localheap.cpp linalg/basematrix.cpp: In member function 'void ngla::S_BaseMatrixstd::complexdouble ::_ZTv0_n72_NK4ngla12S_BaseMatrixISt7complexIdEE12MultTransAddES2_RKNS_10BaseVectorERS4_(ngbla::Complex, const ngla::BaseVector, ngla::BaseVector) const': linalg/basematrix.cpp:208: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6830 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. When an internal compiler error occurs as above, a GCC bug report with the following information should be filed: 1) failing compiler command, 2) details of the compiler (gcc -v), and 3) the preprocessed source for the failing command. You can CC me on hppa bugs (danglin at gcc dot gnu dot org). It takes less than five minutes to generate the above information and file a bug report. The preprocessed source is really important as it is very difficult for others to duplicate the problem otherwise. In this case, it appears the following assert is triggered. /* If the DECL isn't in memory, then the DECL wasn't properly marked TREE_ADDRESSABLE, which will be either a front-end or a tree optimizer bug. */ gcc_assert (MEM_P (result)); There's a fairly high probability that this is a generic bug. If the bug is a compiler regression, then fixes will applied to all active branches when available. Thus, it is useful to know if an earlier compiler version was able to successfully compile the file. As things stand, I file more than 90% of hppa compiler bugs based on what I see in my testing. However, I'm not trying to build and maintain 10,000 packages. So, hopefully, the debian build team can help a bit more with problem reporting. I recognize that not all bugs are easy to classify. However, internal compiler errors are always compiler bugs. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sat, Jun 20, 2009 at 12:02:54PM -0400, John David Anglin wrote: On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: So it's my understanding that the porters have no idea about the problems. So I will start to mail you about problems as soon as I see them and they look like porting issues specific to hppa. netgen fails to built with an internal compiler error since atleast April 2008. Logs are at: When an internal compiler error occurs as above, a GCC bug report with the following information should be filed: 1) failing compiler command, 2) details of the compiler (gcc -v), and 3) the preprocessed source for the failing command. You can CC me on hppa bugs (danglin at gcc dot gnu dot org). I know how to file gcc bugs. I've just filed one. I didn't have time to try and reduce the testcase, and I can't try different versions of g++ yet. I've asked to have different versions installed on paer. The bug report is at: http://gcc.gnu.org/PR40505 It takes less than five minutes to generate the above information and file a bug report. I've never been able to file any (non-automated) bug report in 5 minutes. And if you don't even have direct access to the hardware it takes longer. Kurt -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sat, Jun 20, 2009 at 07:48:38PM +0200, Kurt Roeckx wrote: ... I know how to file gcc bugs. I've just filed one. I didn't have time to try and reduce the testcase, and I can't try different versions of g++ yet. I've asked to have different versions installed on paer. The bug report is at: http://gcc.gnu.org/PR40505 Kurt - thanks for filing the bug. It takes less than five minutes to generate the above information and file a bug report. I've never been able to file any (non-automated) bug report in 5 minutes. And if you don't even have direct access to the hardware it takes longer. I agree. I'm trying to build netgen here too and if the ICE is easy to reproduce, can make that available to danglin and add to the bugreport. thanks again, grant -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
I've never been able to file any (non-automated) bug report in 5 minutes. And if you don't even have direct access to the hardware it takes longer. I agree. I'm trying to build netgen here too and if the ICE is easy to reproduce, can make that available to danglin and add to the bugreport. There's no problem reproducing the ICE. I've pretty much localized the problem. It's a GCC middle-end bug. The problem is in passing a complex double from a thunk. The hppa specification says that values larger than 64 bits are passed by reference in the 32-bit runtime. However, the value is in a pair of registers and not copied to memory. This doesn't happen in calls from normal functions because the value gets copied to a stack slot. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
I take a regular look at various arches why packages are not correctly built. hppa is the most annoying arch for me. If you look at the stats you will notice that it's almost always the lowest in the stats. The reason it more or less keeps up is because I put alot of time in looking at the state of the packages and that packages get retried alot by the buildd maintainer. One of the most annoying things about it is that packages only get uploaded 2 or 3 times a week. This has as effect that alot of packages fail to build because others haven't been uploaded yet. Alot of packages are uninstallable, and are basicly waiting for others to be built/uploaded. With only 2/3 uploads a week this means that packages are uninstallable for _weeks_. By the time the first reason has been fixed, something else already make it uninstallable again. And I guess this is also the reason the release team always needs to take a look at why something is uninstallable on hppa. I can deal with this, but because of this reason, hppa is a low priority port for me. So it's my understanding that the porters have no idea about the problems. So I will start to mail you about problems as soon as I see them and they look like porting issues specific to hppa. Here is a list of packages that failed to build because of instability on the buildds today: package | buildd | error qgit| penalosa | make: *** [install] Segmentation fault acpica-unix | peri | make: *** [install] Segmentation fault This are probabaly porting issues, they atleast seems to only affect hppa: package| error rt-tests | PTHREAD_PRIO_INHERIT undeclared (NPTL support?) insighttoolkit | undefined references axis | #531995: Cannot override the final method from ResourceBundle petsc | petscvariables: No such file or directory Logs can be found at https://buildd.debian.org/build.cgi?arch=hppa;pkg=$package Kurt On Fri, Jun 19, 2009 at 08:05:56AM +0200, Luk Claes wrote: Hmm... It's right that some of my comments are rather harsh, though you must know that I'm not speaking from a personal perspective. Personally (and as Release Manager), I would be very happy to have a good working hppa port for Squeeze and beyond. I made sure that the hppa port was included into Lenny even when the Debian System Administrators (DSA), package maintainers, release team members an others were shouting to drop it. I thought it was unfair to drop the port just before the release. They accepted my decision as long as I would make it clear that it was a *big* exception not to be taken lightly. At the time java support was completely dropped, buildds were crashing every other day and support for other programing languages looked poor and the port was still using linuxthreads as the latest of all ports. After the release of Lenny there were still not much signs of improvement to the reliability of the buildds and the move to ntpl (that was going to solve almost all issues the maintainers had) seemed to not happen and not going to solve everything. The only surprising improvement was the regained java support. It's quite disturbing in my honest opinion that only after us starting a thread like this one that we get to know the status of some of the porting efforts and lots of vocal support, but not many visible improvements. Instead of making sure that there is visibile improvement after that, this pattern seems to repeat itself which is not looking very promising. I'm sorry if my and others' frustration is ventilated in some of the mails. The issues with the buildds are lasting for years already with lots of time spent by DSA and others. I still hope that the hppa porters can prove us wrong, fix the kernel issues (which are the probable cause of the unreliability of the buildds), finalise the ntpl move and stay on top of porting issues in Debian in the future. Please let us now focus on improving the status of the hppa port in general and the buildds in particular! Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: Here is a list of packages that failed to build because of instability on the buildds today: package | buildd | error qgit| penalosa | make: *** [install] Segmentation fault acpica-unix | peri | make: *** [install] Segmentation fault I had those random segfaults in make on paer too, until we switched to the UP kernel, at least from what I saw. Sadly it looks that I forgot the buildd upgrade process on paer some days ago. The buildd will be back building ASAP. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: HPPA and Squeeze
Matthias Klose wrote: Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. There are issues with the hppa port where the release team considered dropping it since 2005 communicated to the porter list... hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? I'm not aware of current toolchain issues on sparc and the issues on mips* still seem to be manageable, no? there are issues pointed out and not addressed like the -dev / -headers packages built as binary independent packages just to save disk space, which have an impact on slow architectures, and which are not addressed by the release team. would the release team mind addressing these real issues, or should we drop slow architectures as well? Well, this Packages issue is clearly a responsability from the FTP Team and the Release Team would indeed be very happy to have that resolved. Cheers Luk -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
John David Anglin wrote: Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: I can understand the desire to trim architectures. However, it's clear the current decision was based on some misinformation, and an unclear rational. There is no desire to trim working architectures. It's very easy to tell there is nothing wrong when you don't have to deal with unreliable build daemons, endless discussions but no visible progress (except for java support) and complaints from DSA, package maintainers and others. Cheers Luk -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Luk, There is no desire to trim working architectures. It's very easy to tell there is nothing wrong when you don't have to deal with unreliable build daemons, endless discussions but no visible progress (except for java support) and complaints from DSA, package maintainers and others. If you looked at https://buildd.debian.org/stats/graph-big.png I think it is obvious hppa is not *that* broken. hppa is 95% built. That is not that bad. Of course, it can be better, but if you looked at this with a historical perspective the port is really in a pretty good shape. If you looked at the status of the toolchain posted to the gcc-testresults page: http://gcc.gnu.org/ml/gcc-testresults/2009-06/ you can see that hppa is one of the better architectures out there. Our results are on par with (if not better than) other supported architectures. IMHO hppa contributed a lot to getting Debian packages (and upstream) properly fixed to build properly across many other architectures and making it easier for new architectures to get incorporated into Debian. It's unfortunate that parisc is no longer a commercially popular platform, but why should not affect whether Debian supports it? It's obvious from the recent exchange that there are still people on the hppa team (and other Debian maintainers) that are willing to work on this architecture to make things better. Also by many metrics it is still very much a working architecture. It's really a shame that Debian's considering dropping support for HPPA in Squeeze. Please reconsider. randolph -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Thu, Jun 18, 2009 at 8:33 AM, Luk Claesl...@debian.org wrote: John David Anglin wrote: Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: I can understand the desire to trim architectures. However, it's clear the current decision was based on some misinformation, and an unclear rational. There is no desire to trim working architectures. It's very easy to tell there is nothing wrong when you don't have to deal with unreliable build daemons, endless discussions but no visible progress (except for java support) and complaints from DSA, package maintainers and others. I'm sorry, but this thread is now over 2 weeks old and we yet have to see a *rationale* motivating the current decision. Not some claims about bugs (which we still haven't been pointed at, except for the ruby one, which we addressed already) affecting the buildds (and that only you experience). Speaking of which, I'm not aware of any problem affecting lafayette... We have given you tangible elements and have answered each and every questions that have been raised in this thread. The release team, on the other hand, failed to answer the single question we've been asking: what's the rationale for dropping parisc? I joined Debian many years ago because it seemed to me that it had proper ethics, in particular because decisions were taken transparently, and were properly - and openly - discussed before anything final was settled. I too have invested time and money into the project. I'm extremely disappointed with the handling of the issue at stake here. Again, I would like to see a comprehensive rationale for this decision, so that we can at least try to address the problems at hands and hope for re-inclusion after squeeze. BTW, can you clarify whether that would be an option? Cheers, T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
It's very easy to tell there is nothing wrong when you don't have to deal with unreliable build daemons, endless discussions but no visible progress (except for java support) and complaints from DSA, package maintainers and others. The problem with the build daemons may be a buggy version of nscd. It causes random problems with uid/gid lookups. This is just a guess based on this report: http://www.nabble.com/Boost-build-failure-on-hppa-td23496708.html I had problems with sshd and dpkg on my c3750 until I disabled nscd. It's now running 2.6.30. It has done a full build and check of GCC several times, and appears to be stable with this kernel. This is with a UP kernel. With SMP kernels, there's still a problem with random segementation faults. These cause application core dumps and are normally logged in /var/log/debug. The frequency of these problems vary with kernel version. I believe that it should be possible to setup a reliable hppa build server running a UP kernel. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Thibaut VARENE wrote: On Thu, Jun 18, 2009 at 8:33 AM, Luk Claesl...@debian.org wrote: John David Anglin wrote: Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: I can understand the desire to trim architectures. However, it's clear the current decision was based on some misinformation, and an unclear rational. There is no desire to trim working architectures. It's very easy to tell there is nothing wrong when you don't have to deal with unreliable build daemons, endless discussions but no visible progress (except for java support) and complaints from DSA, package maintainers and others. I'm sorry, but this thread is now over 2 weeks old and we yet have to see a *rationale* motivating the current decision. Not some claims about bugs (which we still haven't been pointed at, except for the ruby one, which we addressed already) affecting the buildds (and that only you experience). Speaking of which, I'm not aware of any problem affecting lafayette... lafayette is only doing non-sid to make sure we have a buildd that is not heavy loaded and very probable to be able to build all security and stable/oldstable updates... We have given you tangible elements and have answered each and every questions that have been raised in this thread. The release team, on the other hand, failed to answer the single question we've been asking: what's the rationale for dropping parisc? Please read again, it's only in the beginning of the mail... I joined Debian many years ago because it seemed to me that it had proper ethics, in particular because decisions were taken transparently, and were properly - and openly - discussed before anything final was settled. I too have invested time and money into the project. I'm extremely disappointed with the handling of the issue at stake here. I'm very disappointed at the hppa porters attitudes I must say. They talk a lot, they assumingly work a lot behind the scenes, but they don't seem to know what issues there are within the project nor is there any visible progress unless we prod very hard and even then they are more worried about the way we prod than about proving they are worthy to support the port and show some real progress... Again, I would like to see a comprehensive rationale for this decision, so that we can at least try to address the problems at hands and hope for re-inclusion after squeeze. BTW, can you clarify whether that would be an option? It's still an option to stay in squeeze like I told before, but we want a clear sign that the port will be supported throughout the whole release cycle (which honestly looks more and more like it could be the case, though I still fail to see why randomly crashing and segfaulting buildds and decreasing support for programming languages before Lenny was not seen as critical enough). Cheers Luk -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Randolph Chung wrote: Luk, There is no desire to trim working architectures. It's very easy to tell there is nothing wrong when you don't have to deal with unreliable build daemons, endless discussions but no visible progress (except for java support) and complaints from DSA, package maintainers and others. If you looked at https://buildd.debian.org/stats/graph-big.png I think it is obvious hppa is not *that* broken. hppa is 95% built. That is not that bad. Of course, it can be better, but if you looked at this with a historical perspective the port is really in a pretty good shape. As already was explained, the issue is not that builds don't succeed after multiple tries. The issue is that sometimes multiple tries are needed and sometimes the buildds crash. If you looked at the status of the toolchain posted to the gcc-testresults page: http://gcc.gnu.org/ml/gcc-testresults/2009-06/ you can see that hppa is one of the better architectures out there. Our results are on par with (if not better than) other supported architectures. I hope that it will show in the reliability of the buildds and the general improvement of support for the hppa port. Cheers Luk -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarnoaurel...@aurel32.net wrote: On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote: On 06/16/2009 08:25 AM, Lucas Nussbaum wrote: On 15/06/09 at 11:31 -0600, Grant Grundler wrote: PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. In reality it's not (any longer) a hppa specific bug. It's a bug in ruby. Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa. The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable... BTW, Carlos, could you please send me the latest version of your patches, so that we can actually do the switch with version 2.10? I'm in the middle of a build-test cycle with glibc/glibc-ports git head. I'll send you the patches before the end of today. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 16, 2009 at 05:13:44PM -0600, dann frazier wrote: On Wed, Jun 17, 2009 at 12:01:31AM +0100, Stephen Gran wrote: This one time, at band camp, dann frazier said: Are we still having random segfaults on paer? If so - that's be a good one to resolve. Not sure if DSA would be willing to grant (heh) you access to that box, or if we should try running a dummy buildd on another rp2470. We're running paer on a uniprocessor kernel right now, and I believe the segfaults have mostly gone away (although buildd should chime in if I'm not remembering right - they will see more of the machine than I do). That being said, if the porters and buildd people are happy to put the SMP kernel back on and give him access, DSA have no objection. Ah - well if paer is running stably, then maybe a less invasive option would be to setup duplicate hardware and run a buildd that uploads to /dev/null. I have an rp2470 (same hw is paer) we could probably setup for that. I'm all for less invasive/disruptive option and have the HW available. Dann pointed jsw at me and I'll set jsw up with full remote access to the HW. jsw said he would setup a buildd on the HW that I manage. If we can reproduce the problem great. If not, even better and it will be just a matter of getting the same kernel (or equivalent) onto paer or other official hppa buildd machine. thanks! grant -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: +linux-parisc (hppa kernel, compiler and !debian tech forum) Neil, thanks for the summary. I know this is an unpleasant business in general. On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: Hi, As mentioned previously[0], the release team haven't been happy with the state of the HPPA port in Debian. After the release team meeting[1], it has been decided that unfortunatly HPPA will not be supported for Squeeze. This was after careful consideration, and wasn't an easy decision. This means that ftpmasters will be asked to remove HPPA from testing and unstable from the 30th June. It is suggested that HPPA porters may wish to consider using debian-ports.org if they wish to continue with the port. Regards, Neil McGovern [0] http://lists.debian.org/debian-release/2009/04/msg00299.html Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? there are issues pointed out and not addressed like the -dev / -headers packages built as binary independent packages just to save disk space, which have an impact on slow architectures, and which are not addressed by the release team. would the release team mind addressing these real issues, or should we drop slow architectures as well? Matthias -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Grant Grundler schrieb: On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: +linux-parisc (hppa kernel, compiler and !debian tech forum) Neil, thanks for the summary. I know this is an unpleasant business in general. On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: Hi, As mentioned previously[0], the release team haven't been happy with the state of the HPPA port in Debian. After the release team meeting[1], it has been decided that unfortunatly HPPA will not be supported for Squeeze. This was after careful consideration, and wasn't an easy decision. This means that ftpmasters will be asked to remove HPPA from testing and unstable from the 30th June. It is suggested that HPPA porters may wish to consider using debian-ports.org if they wish to continue with the port. Regards, Neil McGovern [0] http://lists.debian.org/debian-release/2009/04/msg00299.html Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. +1. dropping hppa as a release architecture was not communicated by the release team at all. I did spend some time to get gcj / default-jdk working on hppa, and some money (buying a new disk for a hppa machine) to help this port. The time and the money could have spent better, if d-r would have better communicated about their intent. I totally understand your frustration. I have spent thousands of hours supporting hppa. At my current rate, this would be... I believe that intent to drop an architecture should be communicated well in advance of the fact. Not doing so will alienate the developer and user communities. hppa is not in a good shape, but there are other architectures which are not better (sparc, mips*) from a toolchain point of view. what about these? Sparc still exists as a mainframe architecture. If you can afford a high end server, it's probably not that slow. 64 processors, 256 cores, and 512 threads at 2.52 GHz can't be all that bad ;) As you know, it takes a lot of effort to keep a tool chain up to date. If a manufacturer doesn't provide the support that is needed to keep the tool chain going, then the open source support for it will die. It can't be done without access to a variety of hardware, and documentation that may be proprietary. Mips and arm are primarily embedded architectures. Unless one of these manages to achieve market success as a low-end programmable device running linux, the user community is going to be limited to the developers working on products using these devices. The workstation and server market using mips is dead. I was able to build up the tools I need for a Linux arm board in a few days. Thus, I don't really see the need for Debian to try to maintain full blown builds and releases for these architectures. Certainly, there's a lot applications for linux in board products, but it's very product specific. I can understand the desire to trim architectures. However, it's clear the current decision was based on some misinformation, and an unclear rational. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On 15/06/09 at 11:31 -0600, Grant Grundler wrote: I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. It's an extra bad feeling we get that even the people that do respond when there is a request regarding hppa porters don't know what the issues are... Expecting me to know the state of user space components is a bit silly. I'm not a DD. I'm a kernel developer. Specifically IO/Device Drivers. Carlos does know that state (toolchain/glibc) and he just wanted a list of issues that are driving this decision. It's a very reasonable question he asked. [...] I can put one (and maybe two) machines on a public IP. Just ask. The remote console access will remain behind a fire wall. BTW, that firewall was reviewed and approved by Lamont (a pretty well known DD and buildd maintainer). Thibaut Varene (who is a DD) has offered to host HPPA buildd machines as well but hasn't heard any response to that offer either. (Stepping in ; I had some HPPA-related issues in one of my packages - ruby1.9 - so this is based on my experience with that problems) I think that your email summarizes the problem quite well: there are several people willing to offer buildd hosting, help after someone else has investigated the issues, etc. What debian-hppa currently lacks is someone that is willing to proactively detect issues (looking at packages that failed to build, for example), investigate them, and fix them. This can be done cooperating with the package maintainers, but the HPPA side should take the lead. The fact that HPPA people are asking the release team what are the problems you are talking about? clearly shows that this is broken: the HPPA people should be knowing more than the release team about HPPA issues. PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On 06/16/2009 08:25 AM, Lucas Nussbaum wrote: On 15/06/09 at 11:31 -0600, Grant Grundler wrote: PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. In reality it's not (any longer) a hppa specific bug. It's a bug in ruby. Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa. The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable... Helge -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote: On 06/16/2009 08:25 AM, Lucas Nussbaum wrote: On 15/06/09 at 11:31 -0600, Grant Grundler wrote: PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. In reality it's not (any longer) a hppa specific bug. It's a bug in ruby. Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa. The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable... BTW, Carlos, could you please send me the latest version of your patches, so that we can actually do the switch with version 2.10? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 16, 2009 at 08:25:31AM +0200, Lucas Nussbaum wrote: ... BTW, that firewall was reviewed and approved by Lamont (a pretty well known DD and buildd maintainer). Thibaut Varene (who is a DD) has offered to host HPPA buildd machines as well but hasn't heard any response to that offer either. (Stepping in ; I had some HPPA-related issues in one of my packages - ruby1.9 - so this is based on my experience with that problems) I think that your email summarizes the problem quite well: there are several people willing to offer buildd hosting, help after someone else has investigated the issues, etc. What debian-hppa currently lacks is someone that is willing to proactively detect issues (looking at packages that failed to build, for example), investigate them, and fix them. This can be done cooperating with the package maintainers, but the HPPA side should take the lead. Yup - this is definitely true. debian-hppa needed alot of prodding to look at buildd failures. The fact that HPPA people are asking the release team what are the problems you are talking about? clearly shows that this is broken: the HPPA people should be knowing more than the release team about HPPA issues. Generalizing one person's response (mine) to represent the group is wrong. However I agree the release team has no one who cares about HPPA involved. And yes, it's up to the release team to track bugs and determine the viability of a release based on outstanding bugs. As I said before, I'm ok with NOT having a stable HPPA release. If someone disagrees, then they need to participate in the release team and help debian-hppa focus on critical buildd failures. ie generate the nag mail listing the HPPA-specific issues that need to be resolved. PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. This did take a long time to resolve. Helge described the root cause (ruby did not support LinuxThreads implementation correctly) and resolution plan (migrate HPPA to NTPL). No phase of this problem sounds trivial to debug or resolve. Based on this, I can argue the HPPA response is reasonable even if is unsatisfactory and frustrating to you (as package maintainer). Do you have another HPPA specific issue? Or maybe just remind the list how to find those issues? (Teach a man to fish...) thanks, grant -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 16, 2009 at 02:50:27PM -0600, Grant Grundler wrote: On Tue, Jun 16, 2009 at 08:25:31AM +0200, Lucas Nussbaum wrote: ... BTW, that firewall was reviewed and approved by Lamont (a pretty well known DD and buildd maintainer). Thibaut Varene (who is a DD) has offered to host HPPA buildd machines as well but hasn't heard any response to that offer either. (Stepping in ; I had some HPPA-related issues in one of my packages - ruby1.9 - so this is based on my experience with that problems) I think that your email summarizes the problem quite well: there are several people willing to offer buildd hosting, help after someone else has investigated the issues, etc. What debian-hppa currently lacks is someone that is willing to proactively detect issues (looking at packages that failed to build, for example), investigate them, and fix them. This can be done cooperating with the package maintainers, but the HPPA side should take the lead. Yup - this is definitely true. debian-hppa needed alot of prodding to look at buildd failures. The fact that HPPA people are asking the release team what are the problems you are talking about? clearly shows that this is broken: the HPPA people should be knowing more than the release team about HPPA issues. Generalizing one person's response (mine) to represent the group is wrong. However I agree the release team has no one who cares about HPPA involved. And yes, it's up to the release team to track bugs and determine the viability of a release based on outstanding bugs. As I said before, I'm ok with NOT having a stable HPPA release. If someone disagrees, then they need to participate in the release team and help debian-hppa focus on critical buildd failures. ie generate the nag mail listing the HPPA-specific issues that need to be resolved. PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. This did take a long time to resolve. Helge described the root cause (ruby did not support LinuxThreads implementation correctly) and resolution plan (migrate HPPA to NTPL). No phase of this problem sounds trivial to debug or resolve. Based on this, I can argue the HPPA response is reasonable even if is unsatisfactory and frustrating to you (as package maintainer). Do you have another HPPA specific issue? Or maybe just remind the list how to find those issues? (Teach a man to fish...) Are we still having random segfaults on paer? If so - that's be a good one to resolve. Not sure if DSA would be willing to grant (heh) you access to that box, or if we should try running a dummy buildd on another rp2470. -- dann frazier -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
This one time, at band camp, dann frazier said: Are we still having random segfaults on paer? If so - that's be a good one to resolve. Not sure if DSA would be willing to grant (heh) you access to that box, or if we should try running a dummy buildd on another rp2470. We're running paer on a uniprocessor kernel right now, and I believe the segfaults have mostly gone away (although buildd should chime in if I'm not remembering right - they will see more of the machine than I do). That being said, if the porters and buildd people are happy to put the SMP kernel back on and give him access, DSA have no objection. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: HPPA and Squeeze
On Wed, Jun 17, 2009 at 12:01:31AM +0100, Stephen Gran wrote: This one time, at band camp, dann frazier said: Are we still having random segfaults on paer? If so - that's be a good one to resolve. Not sure if DSA would be willing to grant (heh) you access to that box, or if we should try running a dummy buildd on another rp2470. We're running paer on a uniprocessor kernel right now, and I believe the segfaults have mostly gone away (although buildd should chime in if I'm not remembering right - they will see more of the machine than I do). That being said, if the porters and buildd people are happy to put the SMP kernel back on and give him access, DSA have no objection. Ah - well if paer is running stably, then maybe a less invasive option would be to setup duplicate hardware and run a buildd that uploads to /dev/null. I have an rp2470 (same hw is paer) we could probably setup for that. -- dann frazier -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Again, kernel bugs are sometimes hard to find. I still think that http://patchwork.kernel.org/patch/28458/ may fix a few. The only outstanding bug I still know of is that we sometimes face uid/gid issues. This still needs analysis. Helge suggested yesterday that the uid/gid issue might be a bug in nscd. I installed 2.6.30 last night and disabled nscd. I have now run for more than a day without this issue appearing. The machine did a full GCC build and check taking about 24 hours. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, Jun 08, 2009 at 10:26:06PM +0100, Neil McGovern wrote: Firstly, thanks for your mail, apologies that I haven't replied sooner, we've had EU and local elections, so I've been busy runnign around with leaflets, knocking on doors, kissing babies etc. like any politician. No expenses though... No problem. On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote: Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html I'm not sure what replies you'd like... there's certainly been some follow ups to that mail. The following questions haven't been answered in that thread: 1) Is there a list of different porting efforts? 2) What is considered proper java support? GCJ? I've commented on the kernel side and it's looking better. I don't know the status of the HPPA installer. I also never got a response to my offer here: http://lists.debian.org/debian-release/2009/04/msg00339.html Indeed, and that's worrying. I would have expected a HPPA porter (if indeed one still exists) to have replied to that. Or they already have machines. I'm not a DD and don't aspire to be one. So these are in the wild from a Debian point of view. Quite a few serious hppa specific bugs have been fixed upstream over the past 6 months. This is worth revisiting. Is upstream stable enough for a buildd? I don't know since I'm not aware of any attempts to run a buildd with those kernels. Neither do we, we're not HPPA porters :) We did go through this before with newer kernels, and it didn't help FWIW. Is the answer to that question still germane? Ish. We still have the issue that you can't actually buy HPPAs any more, and various bits and pieces from the Arch Requalification list. We can buy HPPA. Just not new ones. There are several resellers of used HPPA gear if someone wants/needs to spend money on it. Can you list the various bits and pieces specifically? I can then prod the folks I know who might be able to do something about if they still feel like it. [change of order by me below] Also, I'd like to ask HPPA debs be kept in testing staging area, just never promoted when the release is cut. This will let people continue using HPPA without having to suffer with the !hppa breakage that lives in unstable. (that's all I personally care about - I don't care about stable releases.) This is one of the major problems for the port. Testing exists to create the next stable release. Essentially, testing *is* the next stable, except that it's a little volatile for a number of months... :) Ok. Can we have the minutes for this meeting? I'm afraid they're not publicly available, but I will be posting a mail to d-d-a real-soon-now(tm), apologies for the delays in this, it was a rather full meeting. Given Debian is non-profit and strives to be transperent in it's operations, this sounds like a digression in that effort. I'm not on d-d-a. Can you please CC affected ports? (TIA) cheers, grant -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote: Grant Grundler wrote: +linux-parisc (hppa kernel, compiler and !debian tech forum) Neil, thanks for the summary. I know this is an unpleasant business in general. On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: Hi, As mentioned previously[0], the release team haven't been happy with the state of the HPPA port in Debian. After the release team meeting[1], it has been decided that unfortunatly HPPA will not be supported for Squeeze. This was after careful consideration, and wasn't an easy decision. This means that ftpmasters will be asked to remove HPPA from testing and unstable from the 30th June. It is suggested that HPPA porters may wish to consider using debian-ports.org if they wish to continue with the port. Regards, Neil McGovern [0] http://lists.debian.org/debian-release/2009/04/msg00299.html Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. I was expecting a summary of specific issues from an organization that claims to operate transperently. The hand waving is easy. But doesn't resolve problems and doesn't meet my expectation of an open organization that I've donated money, time, and materials to. It's an extra bad feeling we get that even the people that do respond when there is a request regarding hppa porters don't know what the issues are... Expecting me to know the state of user space components is a bit silly. I'm not a DD. I'm a kernel developer. Specifically IO/Device Drivers. Carlos does know that state (toolchain/glibc) and he just wanted a list of issues that are driving this decision. It's a very reasonable question he asked. I also never got a response to my offer here: http://lists.debian.org/debian-release/2009/04/msg00339.html There was some discussion with DSA and they didn't seem willing to take the offer as it would be very restricted regarding access and control (too strongly firewalled if I remember correctly) for our administrators. I can put one (and maybe two) machines on a public IP. Just ask. The remote console access will remain behind a fire wall. BTW, that firewall was reviewed and approved by Lamont (a pretty well known DD and buildd maintainer). Thibaut Varene (who is a DD) has offered to host HPPA buildd machines as well but hasn't heard any response to that offer either. It's rather strange that you did not get any feedback in that regard. Agred. Maybe the problems that need to be resolved aren't technical ones. In any case, responding to some of the above with specific concerns should continue this constructive dialog. And my response again to this question posted in [0]: * The machines that host the buildds still seem to have a very unreliable kernel. Is there any update on this? It looks like the amount of random crashes has decreased and the amount of random segfaults has increased, though does not look promising after more than 2 years already of random issues like this. The buildd is seeing issues most other HPPA users (including me) are not seeing. That makes the problems quite a bit harder to resolve. Last time I tried to set up a buildd was rather painful and exceeded the amount of time I was willing to invest (vs contributing to other kernel issues). This was more than 2 years ago and I'm willing to try again IFF someone can tell me what impact that would have on the Debian cabal that seems to be running things. Is upstream stable enough for a buildd? I don't know since I'm not aware of any attempts to run a buildd with those kernels. Rather recent kernels have been tried and like said above seem to behave better, but still very much subpar. Have bugs been filed for those issues that HPPA folks can look at? How can I find them? Is the answer to that question still germane? If so, I'm willing to setup a local buildd and try it. But I will need more time and some commitment that if it works, hppa remain in testing release (that's all I personally care about - I don't care about stable releases.) That's not how it works. testing is the preparation for the next stable release, so staying in testing means fixing any important outstanding porting issue and most importantly the random crashes and segfaults, actively making sure there are no important issues with the hppa port within Debian and committing to support the next stable release. Ok. Sounds like Helge is ok with unstable and I'll try switching to unstable instead of testing. Can we have the minutes for this meeting? No, I didn't even get the chance myself to read them. A summary of the minutes will be posted as usual in the next 'Bits from the
Re: HPPA and Squeeze
On 06/15/2009 06:26 PM, Grant Grundler wrote: On Mon, Jun 08, 2009 at 10:26:06PM +0100, Neil McGovern wrote: Firstly, thanks for your mail, apologies that I haven't replied sooner, we've had EU and local elections, so I've been busy runnign around with leaflets, knocking on doors, kissing babies etc. like any politician. No expenses though... No problem. On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote: Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html I'm not sure what replies you'd like... there's certainly been some follow ups to that mail. The following questions haven't been answered in that thread: 1) Is there a list of different porting efforts? 2) What is considered proper java support? GCJ? I've commented on the kernel side and it's looking better. I don't know the status of the HPPA installer. The HPPA installer should be OK: http://www.mail-archive.com/debian-hppa@lists.debian.org/msg06298.html Helge -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Sun, Jun 14, 2009 at 08:29:14PM +0200, Thibaut VARENE wrote: On Fri, Jun 12, 2009 at 5:35 PM, dann frazierda...@dannf.org wrote: On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote: It seems to be related to what machine you actually have. And the load - buildds for unstable seem to trip over issues that we don't see elsewhere. Workload more to the point. Yes, workload is what I meant. Almost all my parisc boxen have been running BOINC for years and never puked on it. I'm quite convinced the issues buildds are suffering are much less random than people believe. It's more likely that they are very uncommon corner cases. FWIW, afaik lafayette - the autobuilder I recently provided - seems to be running mostly fine. And as far as I (as the local admin) am concerned, I believe my response time to problems (such as when the first hardware that was committed to this autobuilder failed beyond salvation and had to be entirely replaced) is acceptable. Let me know if that weren't true ;-) HTH T-Bone -- dann frazier -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Grant Grundler wrote: +linux-parisc (hppa kernel, compiler and !debian tech forum) Neil, thanks for the summary. I know this is an unpleasant business in general. On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: Hi, As mentioned previously[0], the release team haven't been happy with the state of the HPPA port in Debian. After the release team meeting[1], it has been decided that unfortunatly HPPA will not be supported for Squeeze. This was after careful consideration, and wasn't an easy decision. This means that ftpmasters will be asked to remove HPPA from testing and unstable from the 30th June. It is suggested that HPPA porters may wish to consider using debian-ports.org if they wish to continue with the port. Regards, Neil McGovern [0] http://lists.debian.org/debian-release/2009/04/msg00299.html Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html Note that it's wrong to assume we will come with the answers. It's an extra bad feeling we get that even the people that do respond when there is a request regarding hppa porters don't know what the issues are... I also never got a response to my offer here: http://lists.debian.org/debian-release/2009/04/msg00339.html There was some discussion with DSA and they didn't seem willing to take the offer as it would be very restricted regarding access and control (too strongly firewalled if I remember correctly) for our administrators. It's rather strange that you did not get any feedback in that regard. And my response again to this question posted in [0]: * The machines that host the buildds still seem to have a very unreliable kernel. Is there any update on this? It looks like the amount of random crashes has decreased and the amount of random segfaults has increased, though does not look promising after more than 2 years already of random issues like this. Is upstream stable enough for a buildd? I don't know since I'm not aware of any attempts to run a buildd with those kernels. Rather recent kernels have been tried and like said above seem to behave better, but still very much subpar. Is the answer to that question still germane? If so, I'm willing to setup a local buildd and try it. But I will need more time and some commitment that if it works, hppa remain in testing release (that's all I personally care about - I don't care about stable releases.) That's not how it works. testing is the preparation for the next stable release, so staying in testing means fixing any important outstanding porting issue and most importantly the random crashes and segfaults, actively making sure there are no important issues with the hppa port within Debian and committing to support the next stable release. Can we have the minutes for this meeting? No, I didn't even get the chance myself to read them. A summary of the minutes will be posted as usual in the next 'Bits from the Release Team' though. Also, I'd like to ask HPPA debs be kept in testing staging area, just never promoted when the release is cut. This will let people continue using HPPA without having to suffer with the !hppa breakage that lives in unstable. This will get DSA, maintainers, release team and others keep being frustrated that hppa issues are making their work harder and will only be tolerated if there will finally be a clear commitment from the hppa porters to deal with any present and future important porting issue in a reasonable time frame. The main problem we have with hppa is that important porter issues are not dealt with in a reasonable time frame. The random crashes and segfaults are lasting for years already! Note that we do *NOT* intend to drop hppa from unstable, it being mentioned at all was an unfortunate sign of the deep frustration of some... Cheers Luk Debian Release Manager -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Hello all, Everybody is talking about the 'random crashes' and 'segfaults' in the HPPA version. Over here I'm using the hppa on a small HP-UX workstation, and that has an uptime of 542 days!. So it's not that unstable. I even need to say that I had a lot more crashes with the x86 version then with the hppa version. Just to say that I'm personally not so unhappy with deb hppa, and that not everything is bad. B On Fri, Jun 12, 2009 at 8:49 AM, Luk Claes l...@debian.org wrote: The main problem we have with hppa is that important porter issues are not dealt with in a reasonable time frame. The random crashes and segfaults are lasting for years already! Note that we do *NOT* intend to drop hppa from unstable, it being mentioned at all was an unfortunate sign of the deep frustration of some... -- Schelstraete Bart http://www.schelstraete.org b...@schelstraete.org Sent from Brussels, Brx, Belgium Mae West http://www.brainyquote.com/quotes/authors/m/mae_west.html - I like restraint, if it doesn't go too far.
Re: HPPA and Squeeze
Hello all, Everybody is talking about the 'random crashes' and 'segfaults' in the HPPA version. Over here I'm using the hppa on a small HP-UX workstation, and that has an uptime of 542 days!. So it's not that unstable. I even need to say that I had a lot more crashes with the x86 version then with the hppa version. Just to say that I'm personally not so unhappy with deb hppa, and that not everything is bad. B On Fri, Jun 12, 2009 at 8:49 AM, Luk Claes l...@debian.org wrote: The main problem we have with hppa is that important porter issues are not dealt with in a reasonable time frame. The random crashes and segfaults are lasting for years already! Note that we do *NOT* intend to drop hppa from unstable, it being mentioned at all was an unfortunate sign of the deep frustration of some... -- Schelstraete Bart http://www.schelstraete.org b...@schelstraete.org Sent from Brussels, Brx, Belgium Mae West - I like restraint, if it doesn't go too far. -- Schelstraete Bart http://www.schelstraete.org b...@schelstraete.org Sent from Brussels, Brx, Belgium Erma Bombeck - Never have more children than you have car windows. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Friday 12 June 2009 17:55, Bart Schelstraete wrote: Hello all, Everybody is talking about the 'random crashes' and 'segfaults' in the HPPA version. Over here I'm using the hppa on a small HP-UX workstation, and that has an uptime of 542 days!. So it's not that unstable. I even need to say that I had a lot more crashes with the x86 version then with the hppa version. Just to say that I'm personally not so unhappy with deb hppa, and that not everything is bad. B snipped I agree with Bart. My C3700 is a very reliable HPPA box indeed. Currently it's been up for 21 days, the only thing that usually brings it down is a mains power failure. It is about as reliable as the Mandrake/Celeron box I used up until 18 months ago. Cheers, Geoff. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Fri, 2009-06-12 at 09:55 +0200, Bart Schelstraete wrote: Hello all, Everybody is talking about the 'random crashes' and 'segfaults' in the HPPA version. Over here I'm using the hppa on a small HP-UX workstation, and that has an uptime of 542 days!. So it's not that unstable. I even need to say that I had a lot more crashes with the x86 version then with the hppa version. It seems to be related to what machine you actually have. I run a B180 as my network gateway, handling firewall, web, postfix/postgrey/spamassassin at quite a high volume on a domain. I also used to run it with a PCMCIA wireless card just for chuckles and grins (although I stopped that two years ago when I got a linksys). It runs debian testing and has been completely stable. I only reboot it for updates and in the seven or so years I've been doing this, I haven't had any segfaults or crashes ... have to say I only started using debian kernels on it for the last four or so years, because there used to be big problems with the ones they built. Just to say that I'm personally not so unhappy with deb hppa, and that not everything is bad. I think the main class of problem machines are anything with SMP ... unfortunately, I don't have one, so can't verify. James -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 09, 2009 at 10:29:54AM +0100, Neil McGovern wrote: However, I didn't mean it as a 'you must be able to get these from HP'. You can't find them on ebay (for the three days I looked), and this would indicate that it's unlikely that there's going to be sufficient new porters to make this work. your ebay is broken. A simple search for C3750 (an quite fast parisc workstation) on ebay.de gives me four hits for complete systems. And there are other workstations and servers on ebay. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Neil McGovern wrote: On Tue, Jun 09, 2009 at 01:44:27AM +0200, Thibaut VARENE wrote: Ish. We still have the issue that you can't actually buy HPPAs any more, When did being a marketed platform become a criteria for inclusion? Is Debian the new Ubuntu? :-P Well, back in 2005... http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html However, I didn't mean it as a 'you must be able to get these from HP'. You can't find them on ebay (for the three days I looked), and this would indicate that it's unlikely that there's going to be sufficient new porters to make this work. www.gall.de and some more others Failing this, could we please have a detailed rationale for the decision? It'll be in the d-d-a post, or linked from the post :) Hope this helps, Neil -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Well, back in 2005... http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html However, I didn't mean it as a 'you must be able to get these from HP'. You can't find them on ebay (for the three days I looked), and this would indicate that it's unlikely that there's going to be sufficient new porters to make this work. www.gall.de and some more others And in the US, http://www.cypress-tech.com/ http://www.more-computers.com/ Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Hi Sune, all, Sune Vuorela wrote: On 2009-06-08, Thibaut VARENE vare...@debian.org wrote: Failing this, could we please have a detailed rationale for the decision? I'm not in any way involved with the decision, but I support it. I have in the past had some issues with some of the packages I (co)-maintain in debian on hppa, and I have in the past spent much more time on those packages on hppa than its userbase deserve. And I'm not a hppa porter. Yes, there have been issues. I personally don't mind that we in debian supports many architectures, but it should mainly be the porters who are responsible for fixing architecture weirdnesses, not the package maintainers. Sure. I have really missed this from the hppa porters. It might be that hppa porters don't care for Qt on hppa. It might be that hppa porters don't care for KDE on hppa. I think that's not fair. I'm a big KDE and Qt fan and when you reported the issues, I stepped in. You had problems with the locking functions in Qt. I did sent you fixes for that to fix it in the qt code base. This was one of the threads: http://www.mail-archive.com/debian-hppa@lists.debian.org/msg05888.html I have to admit, that I didn't checked if you integrated them yet, but since I didn't heard back, I expected you did. Then, as a next step we stepped up to fix those Qt locking functions at the place where they really needed to be fixed in the end, which is the gcc as atomic locking builtins. Even this was integrated upstream: http://permalink.gmane.org/gmane.comp.gcc.patches/166978 But. As long as hppa is a release architecture in Debian, we have to have it working. And I have expected more help than I actually got. There has in the past 6-8 month been random segfaults of anything from make over moc to dpkg on the hppa buildds making it hard to get stuff built. It doesn't seem like anyone have actually worked on this, except the buildd admin giving the packages back and next time they succeeded. Sometimes finding kernel bugs isn't easy. I wouldn't be astonished, if this patch fixes those issues: http://patchwork.kernel.org/patch/28458/ It still is on discussion on the hppa-kernel-list. It seems that the buildd's have issues with actually being on line, and it can take 1-3 days for the buildd admins to actually notice this. Up to the lenny release there was the you can crash a hppa machine by building ruby-issue, where the suggested solution was Let's not ship ruby and instead let anyone with a account crash our boxes. The kernel crash was finally fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c61c25eb02757ecf697015ef4ae3675c5e114e2e And in general, I have the impression that random unexplainable failures is just too common for hppa to actually be able to support it in debian. And I also have the impression that the porters think that random unexplainable failures is fully acceptable. No, it's not. Again, kernel bugs are sometimes hard to find. I still think that http://patchwork.kernel.org/patch/28458/ may fix a few. The only outstanding bug I still know of is that we sometimes face uid/gid issues. This still needs analysis. All that said, personally I'm currently really happy about the hppa unstable port. I'm regularly compiling some really big closed-source application on this platform and gcc-3.4 and gij-4.4 are doing a really good thing. Furthermore, the already started migration to NPTL (from linuxthreads) is great, from which I expect even better results. For me hppa unstable is currently in such a good shape in which it hasn't been up to now. So, dropping it now at _this_ _stage_ from unstable would be really sad after such a long (and imho sucessful) way. Best regards, Helge -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
Firstly, thanks for your mail, apologies that I haven't replied sooner, we've had EU and local elections, so I've been busy runnign around with leaflets, knocking on doors, kissing babies etc. like any politician. No expenses though... On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote: Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html I'm not sure what replies you'd like... there's certainly been some follow ups to that mail. I also never got a response to my offer here: http://lists.debian.org/debian-release/2009/04/msg00339.html Indeed, and that's worrying. I would have expected a HPPA porter (if indeed one still exists) to have replied to that. Quite a few serious hppa specific bugs have been fixed upstream over the past 6 months. This is worth revisiting. Is upstream stable enough for a buildd? I don't know since I'm not aware of any attempts to run a buildd with those kernels. Neither do we, we're not HPPA porters :) We did go through this before with newer kernels, and it didn't help FWIW. Is the answer to that question still germane? Ish. We still have the issue that you can't actually buy HPPAs any more, and various bits and pieces from the Arch Requalification list. [change of order by me below] Also, I'd like to ask HPPA debs be kept in testing staging area, just never promoted when the release is cut. This will let people continue using HPPA without having to suffer with the !hppa breakage that lives in unstable. (that's all I personally care about - I don't care about stable releases.) This is one of the major problems for the port. Testing exists to create the next stable release. Essentially, testing *is* the next stable, except that it's a little volatile for a number of months... :) Can we have the minutes for this meeting? I'm afraid they're not publicly available, but I will be posting a mail to d-d-a real-soon-now(tm), apologies for the delays in this, it was a rather full meeting. Hope this helps, Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
+linux-parisc (hppa kernel, compiler and !debian tech forum) Neil, thanks for the summary. I know this is an unpleasant business in general. On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: Hi, As mentioned previously[0], the release team haven't been happy with the state of the HPPA port in Debian. After the release team meeting[1], it has been decided that unfortunatly HPPA will not be supported for Squeeze. This was after careful consideration, and wasn't an easy decision. This means that ftpmasters will be asked to remove HPPA from testing and unstable from the 30th June. It is suggested that HPPA porters may wish to consider using debian-ports.org if they wish to continue with the port. Regards, Neil McGovern [0] http://lists.debian.org/debian-release/2009/04/msg00299.html Carlos O'Donnell asked some questions in response to [0] and I never saw any response. Can an attendee of the above meeting please reply this email from Carlos? http://lists.debian.org/debian-release/2009/04/msg00303.html I also never got a response to my offer here: http://lists.debian.org/debian-release/2009/04/msg00339.html And my response again to this question posted in [0]: * The machines that host the buildds still seem to have a very unreliable kernel. Is there any update on this? Quite a few serious hppa specific bugs have been fixed upstream over the past 6 months. This is worth revisiting. Is upstream stable enough for a buildd? I don't know since I'm not aware of any attempts to run a buildd with those kernels. Is the answer to that question still germane? If so, I'm willing to setup a local buildd and try it. But I will need more time and some commitment that if it works, hppa remain in testing release (that's all I personally care about - I don't care about stable releases.) [1] http://lists.debian.org/debian-project/2009/05/msg00080.html Can we have the minutes for this meeting? Also, I'd like to ask HPPA debs be kept in testing staging area, just never promoted when the release is cut. This will let people continue using HPPA without having to suffer with the !hppa breakage that lives in unstable. thanks, grant -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 2, 2009 at 4:07 PM, Neil McGovern ne...@debian.org wrote: Hi, As mentioned previously[0], the release team haven't been happy with the state of the HPPA port in Debian. After the release team meeting[1], it has been decided that unfortunatly HPPA will not be supported for Squeeze. This was after careful consideration, and wasn't an easy decision. I don't question that. To make things as transparent as they should be, could you elaborate on the grounds for that decision? I think it'd be nice if those were publicly stated so that if people raise eyebrows / want to help, they know exactly what's wrong. Thanks -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote: This means that ftpmasters will be asked to remove HPPA from testing and unstable from the 30th June. It is suggested that HPPA porters may wish to consider using debian-ports.org if they wish to continue with the port. Erk, apologies for a couple of points in the above text which should have been made clearer: * HPPA will be removed from testing at that point. It's up to the FTP Masters to decide what to do with unstable. * s/consider using/consider asking/ - I certainly didn't want to give the impression that I was trying to force anything on the admins! Thanks, Neil -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
