State of cross compiler packages

[Marcin Juszkiewicz]

Dnia czwartek, 16 września 2010 o 22:35:30 Steve Langasek napisał(a):
> On Thu, Sep 16, 2010 at 06:19:28PM +0200, Marcin Juszkiewicz wrote:
> > 1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source

> >    I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base
> >    package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have
> >    /usr/share/doc/ directories pointing into gcc-4.5-base one. Need to
> >    fix this symlink by providing those files in libgcc1 package instead.

done in 1.48
 
> I'm not really in favor of pointing at gcc-4.5-base, because I think
> ultimately we want the version number of the binary packages to be able to
> tell us at a glance what version of a-c-t-b they came from, and we want the
> changelogs to give information about changes to the a-c-t-b packaging and
> not just information about the gcc-4.5 source package.  Dropping
> gcc-4.5-arm-linux-gnueabi-base and symlinking to gcc-4.5-base instead moves
> us away from that goal because it leaves us with no place to ship the
> a-c-t-b changelog.
> 
> This isn't a blocker, and if we're doing multiarch next cycle it should go
> away because we don't need libgcc1-cross any more; this is just my soft
> impression.  But ideally, yes, these files would be shipped in the
> libgcc1-armel-cross package instead of pointing at gcc-4.5-base.

1.48 version has it sorted.

> > 2. gcc-4.4-armel-cross is at 1.36 in archive and was built with

> Bug #637454 is a low-priority bug which currently only has the affect on
> armel of pulling in redundant build-dependencies.  We would be fine to not
> fix that in maverick - but if you have the fix available, I'm also happy to
> review that.
> 
> Bug #640298 is a fix that we pretty obviously need in for these packages to
> be useful in maverick.  In cases such as this, please upload directly to
> the freeze queue!  There's no need for review by email for such a
> straightforward and high-priority bugfix.

1.40 ready for upload

> > 3. gcc-4.5-armel-cross is at 1.35 in archive and was built with
> > 
> >    gcc-4.5-source 4.5.1-7ubuntu1 version.  This package provides
> >    compilers and runtime libraries.  But it does not provide
> >    libgcc1(-dbg)-armel-cross and gcc-4.5-arm-linux-gnueabi-base because
> >    they are in a-c-t-base source package.  All resulting packages have
> >    /usr/share/doc/ directories pointing into
> >    gcc-4.5-arm-linux-gnueabi-base one which is policy violation.
> >    
> >    I have 1.37 version ready to upload which fixes #637454 #640298 bugs
> >    and provides gcc-4.5-arm-linux-gnueabi-base package so policy
> >    violation is removed.
> 
> But you're only moving the policy violation from one package to the other:
> you say that the binary packages from a-c-t-b will have to point across
> source packages to gcc-4.5-base, which is the same policy violation in a
> different package.

1.38 has it solved
 
> > Main problem is that packages generated from gcc-4.5-source are split
> > into two packages: armel-cross-toolchain-base
> > (libgcc1(-dbg)-armel-cross) and gcc-4.5-armel-cross (all the rest). 
> > This was required to allow to bootstrap cross compiler but gives
> > problems when one is built with other version of gcc-4.5-source then
> > other - resulting packages are not installable (we have it now in
> > archive).  It is also a thing which Matthias does not like and I
> > understand it.  For now my only solution is to build both with one
> > version of gcc-4.5-source.
> 
> Well, I think this is a red herring anyway.  Pointing at gcc-4.5-base
> should *also* mean uninstallability when you have out-of-sync versions,
> because we should be pointing at the matching version to ensure the
> correct changelog; and more importantly, we need to have all of these
> packages built from the matching version of gcc-4.5-source at release
> time, to ensure we're complying with GPL provisions regarding source code
> availability.  Having out-of-sync packages turn up as uninstallability
> problems every time is inconvenient for the user trying to track the devel
> release, but it's also a very pointed reminder to rebuild the packages - a
> reminder that we won't accidentally overlook.
> 
> I appreciate that Matthias may not like the frequent uninstallability of
> these packages, but license compatibility is a higher concern.  And
> besides, while I am grateful for Matthias's help sponsoring these
> cross-compiler packages into the archive, it's not his responsibility to
> maintain them, it's ours - so if we have to step up our game to keep the
> packages usable in the face of gcc uploads because Matthias isn't going to
> take on this extra load, then that's what we'll do. :)

http://marcin.juszkiewicz.com.pl/download/ubuntu/ has source packages + logs 
from amd64 build in pbuilder. Please sponsor those uploads.

Regards, 
-- 
JID:      hrw at jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz