hppa and squeeze

[Adam D. Barratt]

Hi,

As mentioned in the minutes of our recent IRC meeting[1] we have
reached the conclusion that hppa will not be a release architecture for
the Squeeze release.

Within the next few days, we'll be taking the next step in this process,
and instructing the testing migration scripts to ignore hppa for all
practical purposes; this means that hppa will still be in testing but
unblocked packages may migrate from unstable to testing even if they
have not been successfully built on hppa or if they introduce new
installability problems on hppa.

We won't be removing the architecture from testing for a while yet, to
give you a chance to decide whether you'd like to try and produce an
hppa/squeeze release and, if so, how you'd like to do that (e.g. by
talking to debian-ports or ftp-master).

Regards,

Adam
for the Release Team

[1] http://lists.debian.org/debian-hppa/2010/08/msg00064.html


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1284829439.12215.858.ca...@kaa.jungle.aubergine.my-net-space.net

Re: HPPA and Squeeze

[Carlos O'Donell]

On Sun, Jul 12, 2009 at 8:30 AM, Aurelien Jarno 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Aurelien Jarno]

On Sun, Jun 21, 2009 at 06:55:21PM -0400, Carlos O'Donell wrote:
> On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarno 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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> On Tue, Jul 7, 2009 at 6:07 PM, John David
> Anglin 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jul 7, 2009 at 6:07 PM, John David
Anglin 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

On Tue, 07 Jul 2009, Carlos O'Donell wrote:

> On Tue, Jul 7, 2009 at 12:21 PM, John David
> Anglin 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.

I'm sure that there is a null tag after the STRTAB.  The segmentation
fault occurred because the get operation failed after processing
the first NEEDED tag and before the STRTAB tag.  The loop goes
sequentially through the array of DT objects in the recently mmap'd
data and inserts pointers to these objects into the dynamic loaders
link map for the file (in the l_info field).  There were no null tags
between the NEEDED entry and the STRTAB entry in the mmap'd data in
the core dump.  The DT objects are near the end of the mmap'd data.

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.

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jul 7, 2009 at 12:21 PM, John David
Anglin 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[James Bottomley]

On Mon, 2009-07-06 at 17:43 -0400, Kyle McMartin wrote:
> 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.

The pa8800/8900 are very special systems.  They have an L1/L2 VIPT cache
but an L2 PIPT one.  All other parisc systems have VIPT throughout.

The problem with the VIPT/PIPT combination is that you can get read only
stale alias resolution between the VIPT/PIPT hierarchy ... linux just
doesn't expect this to happen.  We work around this with extra flushes
in kmap to prevent the read only alias resolution from happening.
There's nothing missing in the logic of this, the only problem is that
its operation treats the vast L2 PIPT cache as a useless boat anchor
whose only job is to make life harder for us ... so we're getting
absolutely no benefit from the 25-50MB of cache there.

James



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[James Bottomley]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Mon, Jul 6, 2009 at 10:43 PM, dann frazier 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[dann frazier]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kyle McMartin]

On Mon, Jul 06, 2009 at 02:45:37PM -0400, John David Anglin wrote:
> I have to think that this has something to do with the machine
> being a rp3440 (large memory and cache).  I have never seen this
> on my c3750 with 32-bit UP kernel.  Also, this was with a 64-bit
> UP kernel.
> 

If I remember correctly, there's still some issues with the L2 cache on
pa8800 that we haven't quite bothered to work out yet, since it's "good
enough" for now. James probably knows more. It would be interesting to
see if you could reproduce it with a UP 64-bit kernel on your C3750 to
discount the L2 problems.

regards, Kyle


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Mon, Jul 6, 2009 at 9:28 AM, John David
Anglin 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 
#include 
#include  /* mmap */
#include  /* open */
#include  /* open */
#include  /* open */
#include  /* 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

[John David Anglin]

> > 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Randolph Chung]

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?

randolph


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> On Sun, Jul 5, 2009 at 1:19 PM, John David
> Anglin wrote:
> > Carlos, what do you think?
> 
> I think the dynamic linker is always the first to touch the mmap'd
> file and therefore the most likely to fail if something is wrong in
> our VM layer.

>From the core dump, this is the data supposed processed by
elf_get_dynamic_info:

(gdb) x/64x l->l_ld
0x4029e5fc <.LC11+4>:   0x0001  0x0167  0x0001  
0x0171
0x4029e60c <.LC11+20>:  0x000e  0x0179  0x000c  
0x0c9c
0x4029e61c <.LC11+36>:  0x000d  0x20bc  0x0019  
0x3590
0x4029e62c <.LC11+52>:  0x001b  0x0004  0x0004  
0x2168
0x4029e63c <.LC11+68>:  0x6ef5  0x0134  0x0005  
0x047c
0x4029e64c <.LC11+84>:  0x0006  0x01ec  0x000a  
0x01c8
0x4029e65c <.LC11+100>: 0x000b  0x0010  0x0003  
0x37fc
0x4029e66c <.LC11+116>: 0x0002  0x015c  0x0014  
0x0007
0x4029e67c <.LC11+132>: 0x0017  0x0b40  0x0007  
0x07b0
0x4029e68c <.LC11+148>: 0x0008  0x0390  0x0009  
0x000c
0x4029e69c <.LC11+164>: 0x6ffc  0x0698  0x6ffd  
0x0006

(gdb) p l->l_ld[9]
$15 = {d_tag = 5, d_un = {d_val = 1148, d_ptr = 1148}}
(gdb) p/x 1148
$16 = 0x47c

The numbers seem to match that printed by readelf.  So, maybe Carlos
is right and this is a VM issue.  Is it possible the code saw different
data (e.g., the mmap operation was not complete before the mmap call
returned)?

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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 .

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[James Bottomley]

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?

> > > 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?

James



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> > 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Sun, Jul 5, 2009 at 7:07 PM, John David
Anglin 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Sun, Jul 5, 2009 at 1:19 PM, John David
Anglin wrote:
> Carlos, what do you think?

I think the dynamic linker is always the first to touch the mmap'd
file and therefore the most likely to fail if something is wrong in
our VM layer.

Cheers,
Carlos.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> (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 }, 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 }
> (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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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 }, 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=, 
user_entry=) at rtld.c:1780
#2  0x403cb898 in _dl_sysdep_start (start_argptr=, 
dl_ma...@0x403d7566: 0x403b8fe4 ) 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 , 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  dave.ang...@nrc-cnrc.gc.ca
National Research Council o

Re: HPPA and Squeeze

[John David Anglin]

> 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 
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:
...
(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=, 
user_entry=) at rtld.c:1780
#2  0x403cb898 in _dl_sysdep_start (start_argptr=, 
dl_ma...@0x403d7566: 0x403b8fe4 ) 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 bff0
Jul  5 04:07:31 mx3210 kernel: fr0

Re: HPPA and Squeeze

[Jurij Smakov]

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  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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Helge Deller]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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.

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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.

The suggestion to "recompile with -ffunction-sections" is somewhat
misleading.  While -ffunction-sections may help sometimes, in other
cases it may be necessary to play with the ld --stub-group-size=N
option, or to compile with -mlong-calls.

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Philipp Kern]

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?

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

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Martin]

On Thu, 2009-06-25 at 10:10 +0200, Matthias Klose wrote:
> Mike Hommey schrieb:
> > On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
> >> 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?
> > 
> > Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64,
> > where the pros of the added registers overcome the cons of bigger
> > pointers. In other words, 64 bits code is slower, fatter and more memory
> > hungry than 32 bits code on sparc.
> 
> which of the previous statements did you check?
I don't every recall seeing any general purpose comparisons on this; if
anyone has links to one I'd be most interested.  I have recollections of
seeing it claimed in some of the Sun manuals and has been accepeted
'cannon' for the entire time I've been using SPARC machines.On
specific programs I've tested I've seen a 10-15% slow down moving from
32 to 64 bit code.  The key difference is pointer size and the effect
this has on caching effects; thus the slow down varies program to
program and it is possible that the programs I'm interested in are at
the upper end of the range.

>  E.g. speed comparing the current
> 32bit v8 with 64bit ultrasparc code?
I think V9 vs. V8+ would be a fairer comparison, plus there is a
separate question over the default -mtune options to use.

> and even then I wouldn't care that much if it becomes maintainable.
(I guess I don't fully understand the context of this but ...) while
there is GCC support for V8 / V8+ having the userland 32 / kernel 64
split shouldn't be a big deal, should it?

HTH

Cheers,
 - Martin



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Matthias Klose]

Mike Hommey schrieb:
> On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
>> 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?
> 
> Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64,
> where the pros of the added registers overcome the cons of bigger
> pointers. In other words, 64 bits code is slower, fatter and more memory
> hungry than 32 bits code on sparc.

which of the previous statements did you check? E.g. speed comparing the current
32bit v8 with 64bit ultrasparc code?

and even then I wouldn't care that much if it becomes maintainable.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Mike Hommey]

On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
> 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?

Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64,
where the pros of the added registers overcome the cons of bigger
pointers. In other words, 64 bits code is slower, fatter and more memory
hungry than 32 bits code on sparc.

Mike


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Matthias Klose]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarno 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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> > 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.
> 
> I'm slightly confused about "stack slot". Could the "pass by reference"
> refer to the address in the stack?

The reference can refer to a location on the stack (region allocated
for locals).  However, values larger than 64 bits can't be passed in the
argument slots.

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Grant Grundler]

On Sat, Jun 20, 2009 at 06:25:20PM -0400, John David Anglin wrote:
> > > 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.

Indeed...already failed for me.

> 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.

I'm slightly confused about "stack slot". Could the "pass by reference"
refer to the address in the stack?

Anyway, thanks for quickly tracking this down.

grant

> 
> 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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.

Based on my experience with building GCC, a recent UP kernel (e.g., 2.6.30)
will avoid the random segfault problem.

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> > 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Grant Grundler]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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_BaseMatrix 
>::_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  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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Thibaut VARENE]

On Sat, Jun 20, 2009 at 4:39 PM, Kurt Roeckx 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.
>
> Ruby1.9 hangs in test_thread.rb and gets killed after
> 150 minutes of inactivity.  I assume NPTL will fix this.

yes, it's a ruby bug, it's been explained on this m-l already.
Ruby's implementation cannot handle linuxthreads.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Philipp Kern]

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

[Kurt Roeckx]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

HPPA and Squeeze

[Luk Claes]

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

Re: HPPA and Squeeze

[Luk Claes]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Luk Claes]

Thibaut VARENE wrote:
> On Thu, Jun 18, 2009 at 8:33 AM, Luk Claes 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Thibaut VARENE]

On Thu, Jun 18, 2009 at 8:33 AM, Luk Claes 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Randolph Chung]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Luk Claes]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Luk Claes]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[John David Anglin]

> 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Matthias Klose]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Grant Grundler]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarno 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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[dann frazier]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Stephen Gran]

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

[dann frazier]

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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Grant Grundler]

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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Helge Deller]

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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Aurelien Jarno]

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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Lucas Nussbaum]

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.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Grant Grundler]

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?

Re: HPPA and Squeeze

[Thibaut VARENE]

On Fri, Jun 12, 2009 at 5:35 PM, dann frazier 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. 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

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[dann frazier]

On Sun, Jun 14, 2009 at 08:29:14PM +0200, Thibaut VARENE wrote:
> On Fri, Jun 12, 2009 at 5:35 PM, dann frazier 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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Brian Szymanski]

dann frazier wrote:
> On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
>   
>>>  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.
>> 
>
> We've tried both SMP and non-SMP kernels.
>   

FWIW, I've a j6700, running with an SMP kernel from testing, and it's
been rock solid for me.


-- 
Brian Szymanski
email:  skibrian...@gmail.com

Ex cibus merda. Ex merda humus. Ex humus cibus.

Re: HPPA and Squeeze

[dann frazier]

On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
> 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.

And the load - buildds for unstable seem to trip over issues that we
don't see elsewhere.

>   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.

We've tried both SMP and non-SMP kernels.

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[James Bottomley]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Bart Schelstraete]

 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  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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Bart Schelstraete]

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  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."

Re: HPPA and Squeeze

[Luk Claes]

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-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org