On Mon, Sep 11, 2006 at 09:48:55PM +0200, Denis Barbier wrote: > On Sun, Sep 10, 2006 at 07:52:39PM -0300, Damián Viano wrote: > > Hi, I've done this already, and also filled bugs (with some patches) for > > the FTBFS I've found. > > > > I'm uploading my results here http://lug.fi.uba.ar/~des/gettext_0.15/ > > > > There you will find: > > > > - rdep: list of packages rebuilt > > - results: results for the first run (0 success, other failure) > > - results_rebuilt: results for the re-run > > - buildlogs/package.log: package build log > > - buildlogs/package_rebuild.log: package re-run build log > > - gtt15.tar.bz2: tarball with all the above > > > > All the packages where built on *the same* pbuilder environment, so it > > was not-so-clean, but I guess that it represent a decent build > > environment. > > Thanks, but there are several problems: > * Your pbuilder environment is not clean, so you were not able > to build packages which Build-Conflicts any flavour of automake, > like gtoaster.
Yes, this is in fact an issue, I've tested, some of those failures on
clean pbuilders, but didn't save a log :-/ gtoaster, in particular
builded fine.
I didn't considered this very harmful, since IIUC buildd don't have a full
clean environment when building, so if a package need a particular version of
automake is should use the versioned commands and depend on the versioned
version of automake, am I wrong in this?
> * Due to this unclean environment, bugs are somewhat hidden because
> the aclocal command is the one you selected by alternatives, and
> may be different from the one specified in Build-Depends{,-Indep};
> for instance I do not see how your patch in #386072 can work, since
> you modify lines after aclocal is called, and this is this command
> which fails.
Yes, I should have mentioned this, sorry. I've used automake1.9 for
automake, I see now that this effectively hided some bugs. However this
might not be too grave, since the bugs triggered by the automake1.4 vs
automake1.9 (see #386487 and [1]) are a regression in gettext and should
be fixed there AFAIU.
> * You did not rebuild packages which Build-Depends-Indep: gettext
Really? I certainly thought I did... why do you think I didn't?
> It would IMO be nice to rebuild packages in a clean environment; I put
> the list of packages at http://people.debian.org/~barbier/tmp/gettext.list
> if someone can rebuild these packages.
Hmm... in fact, this list seems the same I used
http://lug.fi.uba.ar/~des/gettext_0.15/rdep
> > The bugs I've seen from this rebuilt are mostly 3:
> > - #386487: FTBFS: aclocal: macro `AM_PROG_MKDIR_P' required but not
> > defined
> > - #385235: gettext 0.15 causes build failures in multiple packages
> > - some about @MKINSTALLDIRS@ failures, which was previously being
> > defined in AM_GNU_GETTEXT and now it's not
>
> Yes it seems that there are very few bugs, this is good news.
> Did you file bugs for all the failures you found?
I did, at least for those I considered that weren't created by my environment
Note that some other FTBFS have been spawning here(#386261) and there(#386437)
on packages not depending on gettext, but that seems to be from this transition
also... I haven't checked them thoroughly though, only a search for
MKINSTALLDIRS in bts.turmzimmer.net.
Hope to help,
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386487;msg=11
--
Damián Viano(Des) ¯ ¯ - _ _ - ¯ ¯
GPG: 0x6EB95A6F Debian ¯-_GNU_-¯ Linux
Web: http://damianv.com.ar/ ¯-¯
signature.asc
Description: Digital signature
