[Gcl-devel] Re: Bug#395135: Please requeue gclcvs_2.7.0-62 on alpha

[Camm Maguire]

Greetings, and thanks you so much for looking into this!

Steve Langasek <address@hidden> writes:

> On Fri, Oct 27, 2006 at 09:48:43AM -0400, Camm Maguire wrote:
> > > FWIW, after tracking down the last header problem on alpha I let the test
> > > build continue on through to see if there were any other problems.  Aside
> > > from taking a long time to build, it now seems to be getting stuck in an
> > > infinite loop running raw_pcl_gcl -- according to strace, trying to call a
> > > syscall #513 which AFAIK does not exist on alpha, which then fails
> > > repeatedly with errno 103 (ECONNABORTED).  I have no idea what any of this
> > > is -- I /could/ give it to the buildd to try, but I really don't have any
> > > reason to believe it will build any better there.
> 
> > > Do you have any idea what this syscall is supposed to be?  Are we looking 
> > > at
> > > a glibc bug here?
> 
> > This is my guess.  If I could get access to a system, I could provide
> > more information.  Any idea of when sid chroots on escher (or other)
> > might become available again?
> 
> No, sorry; though I'm currently working on getting some kernel patches in
> that would let Debian support another class of higher-end alphas, which
> might help us get a faster (and accessible) porter system.
> 
> Does gcl make any syscalls itself?  That would be a significant pointer in
> the direction of glibc if it doesn't.
> 

no explicit syscall().  If a randomized sbrk is detected a la fedora,
there is a call to personality() which requires the syscall.h header,
but even this is not pertinent to Debian.

> > This code built quite recently on alpha.  I'm particularly interested
> > in mips and alpha, as they test new bfd object relocation code put
> > into gcl recently.  I'd like to make sure there is no regression here,
> > though I suspect none.
> 
> > If there were a problem here, you would see it before raw_pcl_gcl.
> > There is noting this binary does but run some very simple
> > initialization code, and then dump its image with unexec.  saved_gcl
> > and saved_mod_gcl, already produced, use the same dumping code, so I
> > don't suspect anything here either.  
> 
> > It appears that some constant specifying the syscall has gotten messed
> > up on alpha.  
> 
> > If I can get access, I'd be happy to test.  Otherwise, here is what
> > needs doing:
> 
> > ./configure --enable-ansi -enable-debug && make
> 
> This just gives me a build failure.
> 

Argh, my apologies!  --disable-statsysbfd --enable-locbfd are also
needed at the configure command line

> gcc -c -g -fsigned-char -pipe -Wall  -g -mieee 
> -I/home/devel/release/gclcvs-2.7.0/o -I../h -I../gcl-tk sfasl.c
> In file included from sfaslbfd.c:175,
>                  from sfasl.c:43:
> sfaslbfd_alpha.c: In function ‘alphaelf_install_patches’:
> sfaslbfd_alpha.c:162: error: assignment of read-only location
> sfaslbfd_alpha.c:168: error: assignment of read-only location
> sfaslbfd_alpha.c:173: error: assignment of read-only location
> sfaslbfd_alpha.c:178: error: assignment of read-only location
> sfaslbfd_alpha.c: In function ‘alphaelf_init_got_info’:
> sfaslbfd_alpha.c:232: error: too few arguments to function 
> ‘bfd_hash_table_init’
> make[1]: *** [sfasl.o] Error 1
> make[1]: Leaving directory `/home/devel/release/gclcvs-2.7.0/o'
> make: *** [unixport/saved_pre_gcl] Error 2
> 
> 
> > Come to think of it, this bug might have just appeared on alpha too:
> 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387498
> 
> No, it's not the same bug; the test case for system() works fine on my alpha
> when compiling with -pg.
> 
> Here's the full cycle from a current strace:
> 
> fork()                                  = ? ERESTARTNOINTR (To be restarted)
> --- SIGPROF (Profiling timer expired) @ 0 (0) ---
> sigreturn()                             = ? (mask now [CHLD])
> syscall_513(0x200006816e8, 0x80000, 0x11f269038, 0x1, 0, 0x1223400f0, 
> 0xfffffc0001aa4000, 0x200005b6a30, 0x8, 0x1fd, 0x20000557c58, 0, 0x7b0a75b, 
> 0x20000689740, 0x11f268fa0, 0, 0x4082904a484b2a29, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> 0x3fe0000000000000, 0x154e, 0x40b54ee660000000, 0x40b54e6660000000, 0, 
> 0x3fe6666660000000 <unfinished ...>
> --- SIGPROF (Profiling timer expired) @ 0 (0) ---
> <... syscall_513 resumed> )             = 0x67
> [repeat ad infinitum]

Good to know!  I'll ask one of the kind respondents on the Debian
alpha list if I can take them up on the offer of an account.  Only
problem is we'd need an uptodate chroot to make the result
meaningful. 

This brings me to a broader question.  I've been a developer for over
10 years, but there appears to exist more than one class of developer,
with several classes endowed with more privileges than are available
to me.  Access to 'restricted' machines, the ability to requeue
packages on only some arches, the ability to make sure by hand uploads
actually migrate into the archive, new package acceptance, testing
migration, etc.  I'd guess no one has all of these privileges, but I
wonder how I might apply for some of them.  Right now, as an
'ordinary' developer, if I need to get a package in shape for release
by a given deadline, my only recourse is to upload a new version to
all the autobuilders at once, which is quite wasteful.  I have a by
hand upload of maxima on ppc for example which has appeared stuck now
somewhere for some time.

Take care,

> 
> Thanks,
> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> address@hidden                                   http://www.debian.org/
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah