[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: build problems on sarti (was: Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails)

pe, 2005-12-23 kello 17:23 +0100, Frank Küster kirjoitti:

> Hi Lamont, hi Debian admins,
> during the last weeks there were a couple of FTBFS cases on sarti, the
> hppa buildd, which point to severe problems on that machine.  The things
> that happened did only happen on this single buildd, but did in no way
> look as if they were architecture specific.  
> To me it looks as if there were hardware problems.  
> Previously, the bugs were resolved without notifying the maintainers how
> this was achieved (or whether maybe nothing was done at all except
> requeing the FTBFS package), so I can't tell what the real cause was then.


> The script that fails is tetex-base's postinst:
> Setting up tetex-base (3.0-11) ...
> Removing unchanged obsolete conffiles ... done
> /var/lib/dpkg/info/tetex-base.postinst: line 678: update-language: command not found
> dpkg: error processing tetex-base (--configure):
>  subprocess post-installation script returned error exit status 127
> so tex-common (on which tetex-base depends) should be already
> configured and work fine (note that both packages are architecture:
> all).  But the build does not even try to install tex-common, so it
> seems dpkg thinks that it is already installed:
> > http://buildd.debian.org/fetch.php?&pkg=planner&ver=0.13-4&arch=hppa&stamp=1135258214&file=log&as=raw


> In fact this particular command should work even when
> tex-common is only unpacked, but unconfigured, since update-language is
> a simple shell script in /usr/sbin.  If tex-common is unpacked and the
> shell works, it should work, too.
> So it seems something is severely amiss with the debbuild chroot on
> sarti. 
> Regards, Frank
> P.S. I'd like to reassign this bug to "buildd.debian.org" or
> "sarti.debian.org", but such a virtual package doesn't exist...

I'd like to know how things are progressing with this issue. 

My package is still stuck on hppa because of this. It has successfully
built on every other architecture. Even worse, this is the second time
that this situation prevents build-depends from being fulfilled on hppa.

Anyhow, given how hppa is already among the architectures that did not
re-qualify for Etch, I propose that, from now on, hppa be ignored for
deciding whether a package is considered valid for going into Testing.

Martin-Éric Racine

Attachment: signature.asc
Description: Digitaalisesti allekirjoitettu viestin osa

Reply to: