State of cross compiler packages
marcin.juszkiewicz at linaro.org
Fri Sep 17 17:10:05 BST 2010
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.
JID: hrw at jabber.org
More information about the linaro-toolchain