Bug#344538: build problems on sarti (was: Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails)
On 1/6/06, Martin-Éric Racine <[EMAIL PROTECTED]> wrote: > pe, 2006-01-06 kello 11:51 -0500, Kyle McMartin kirjoitti: > Well, this is the second time that installation of tetex fails on hppa. > According to the tetex maintainer, everything is kosher on his side, so > this brings the question why installation of tetex repeatedly fails and > only on hppa. Repeated occurrences of installation failure on a single > architecture is a highly suspicious matter. Granted, Planner is not an > essential package, but the situation is still bad omen. there is no such thing as a situation, as I see it: -rw-r--r-- 1 root root 39954 Jan 6 20:47 planner-dev_0.13-4_hppa.deb -rw-r--r-- 1 root root 801 Jan 6 20:47 planner_0.13-4_hppa.changes -rw-r--r-- 1 root root 2167556 Jan 6 20:47 planner_0.13-4_hppa.deb I built it just fine in a local sid chroot. Just wait for buildd to tackle the build again, that's all. A couple of weeks delay for a low priority upload isn't a *situation*. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/
Bug#344538: build problems on sarti (was: Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails)
pe, 2006-01-06 kello 11:51 -0500, Kyle McMartin kirjoitti: > On Fri, Jan 06, 2006 at 02:18:38PM +0200, Martin-?ric Racine wrote: > > 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. > > Uhm. You're wrong? > > http://release.debian.org/etch_arch_qualify.html Ah. It seems I was. My mistake. Sorry! > In any case, might as well ignore it. Well, this is the second time that installation of tetex fails on hppa. According to the tetex maintainer, everything is kosher on his side, so this brings the question why installation of tetex repeatedly fails and only on hppa. Repeated occurrences of installation failure on a single architecture is a highly suspicious matter. Granted, Planner is not an essential package, but the situation is still bad omen. -- Martin-Éric Racine http://q-funk.iki.fi signature.asc Description: Digitaalisesti allekirjoitettu viestin osa
Bug#344538: build problems on sarti (was: Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails)
On Fri, Jan 06, 2006 at 02:18:38PM +0200, Martin-?ric Racine wrote: > 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. > Uhm. You're wrong? http://release.debian.org/etch_arch_qualify.html In any case, might as well ignore it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344538: build problems on sarti (was: Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails)
On 1/6/06, Martin-Éric Racine <[EMAIL PROTECTED]> wrote: [...] > 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. I believe that you are mistaken. hppa *is* Release Candidate for Etch (see http://release.debian.org/etch_arch_qualify.html) I don't know what's up with your particular build problem but it will not be overlooked, please be patient, this is not the only issue we're dealing with. T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/
Bug#344538: 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 http://q-funk.iki.fi signature.asc Description: Digitaalisesti allekirjoitettu viestin osa
Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails
On 23.12.05 Martin-Éric Racine ([EMAIL PROTECTED]) wrote: Hi, > texte-base installation fails because it needs to execute > update-language (from tex-common), which is not yet unpacked or > configured during a fresh install. This in turn breaks installation > of jadetex and other TeX bits, which prevents building of packages > Build-Depends on TeX components. > > http://buildd.debian.org/fetch.php?&pkg=planner&ver=0.13-4&arch=hppa&stamp=1135258214&file=log&as=raw > > The cure would be to move tex-comon to Pre-Depends. > I don't understand. The error message is: /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 However that file must exist, when tex-common has been been unpacked. Further the package builds fine on all other archs. H. -- sigmentation fault pgpQQC1RAawvI.pgp Description: PGP signature
Bug#344538: build problems on sarti (was: Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails)
severity 344538 important thanks 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. See for example this new bug: Martin-Éric Racine <[EMAIL PROTECTED]> wrote: > Package: tetex-base > Version: 3.0-11 > Severity: grave > Justification: renders package unusable > > texte-base installation fails because it needs to execute update-language > (from tex-common), which is not yet unpacked or configured during a fresh > install. This analysis is not correct. 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 > > The cure would be to move tex-comon to Pre-Depends. No, for sure not. 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... -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails
Package: tetex-base Version: 3.0-11 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 texte-base installation fails because it needs to execute update-language (from tex-common), which is not yet unpacked or configured during a fresh install. This in turn breaks installation of jadetex and other TeX bits, which prevents building of packages Build-Depends on TeX components. http://buildd.debian.org/fetch.php?&pkg=planner&ver=0.13-4&arch=hppa&stamp=1135258214&file=log&as=raw The cure would be to move tex-comon to Pre-Depends. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDrBq/eXr56x4Muc0RAuXbAJ4nRhpoSN6dzLpfv6xXoDhJFPCdMQCfZL7p XmQTRzVEOUsKpDyNYtPbvZ4= =UkaJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
