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: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
