Currently we have a massive base package for the build system that contains everything necessary to bootstrap a system. Although it contains everything needed to easily recreate the build system from scratch, it's very annoying changing individual components in it. As upgrading components is the common use case, and not rebuilding it from scratch, we should consider a redesign. We still need to make sure we can recreate it from scratch though.
Probably done together with bug 4357. Unsure how much the work overlaps. Time est. based on worst case (no overlap).
Time est. turned out to be waaaay wrong. Partly a bit too optimistic, partly because there were a lot of cleanups that were appropriate to do at the same time.
I have something that can build ThinLinc now, so it is just a matter of committing it to svn.
Committed in r29656:29701.
All done and nightly builds are still building successfully. Considering this work finished. Tester should check the documentation and attempt to rebuild things from scratch.
Regarding variants, to choose a variant you should set variant name to 1; rpmbuild ... --define "native 1" However one can only build one variant to build and not multiple variants. It is not clear what happens if several variants are specified. The way it is specified is overcomplicated and it would be more natural to specify the specific variant to build in the following way; rpmbuild ... --define "variant native"
I made the mistake to perform the steps in "Automatic Rebuild" section as root which fails when running the repo/rebuild command. It is required that you run these steps as a user. This needs to be clarified. Also due to the fact that the rebuild needs to be run as a user, one need to make sure to checkout the cenbuild into the home directory, otherwise the build within chroot will fail after a few hours. This should also be mentioned in the documentation. During the rebuild of the build environment the process stops and wants the user to install native dependencies. The dependencies should be documented for a seamless rebuild... flex <- cendio-build-gmp-bootstrap-win32 zlib-devel <- cendio-build-binutils-bootstrap-i386 texinfo <- cendio-build-bootstrap-build-i386 bison <- cendio-build-bash.i386
There are important information vaguely spread in different places. It should be migrated into the top of Automatic rebuild section with information that it affects the utils and bootstrap environment. "1. Note that this package is compiled for the native system. As such, take care where you build it so that you can use the resulting package on all machines." "4. Build the bootstrapping environment. Like the utils package these packages will depend on the native environment so they should be built on an older system."
(In reply to comment #6) > Regarding variants, to choose a variant you should set variant name to 1; > > rpmbuild ... --define "native 1" > > However one can only build one variant to build and not multiple variants. It > is not clear what happens if several variants are specified. The way it is > specified is overcomplicated and it would be more natural to specify the > specific variant to build in the following way; > > rpmbuild ... --define "variant native" Probably, but it makes the spec files more complicated. So the current method is preferred as you rarely build by hand. I've elaborated a bit more on multiple variants in r30296.
(In reply to comment #7) > I made the mistake to perform the steps in "Automatic Rebuild" section as root > which fails when running the repo/rebuild command. It is required that you run > these steps as a user. This needs to be clarified. > Seriously, who runs things as root? Much less builds packages as root? :) Still, the tool will immediately tell you not to run things as root so I don't see how you can miss it. > Also due to the fact that the rebuild needs to be run as a user, one need to > make sure to checkout the cenbuild into the home directory, otherwise the build > within chroot will fail after a few hours. This should also be mentioned in the > documentation. It already is, in the first section on using the build environment. > > During the rebuild of the build environment the process stops and wants the > user to install native dependencies. The dependencies should be documented for > a seamless rebuild... > > flex <- cendio-build-gmp-bootstrap-win32 > zlib-devel <- cendio-build-binutils-bootstrap-i386 > texinfo <- cendio-build-bootstrap-build-i386 > bison <- cendio-build-bash.i386 Maintaining a separate list of this is bound to get out of sync, quickly making it rather useless. I agree it is annoying though. Ideally the rebuild script should walk the dependency list early and check for system dependencies (and internal ones). But that's a lot more work.
(In reply to comment #8) > There are important information vaguely spread in different places. It should > be migrated into the top of Automatic rebuild section with information that it > affects the utils and bootstrap environment. > > "1. > > Note that this package is compiled for the native system. As such, > take care where you build it so that you can use the resulting > package on all machines." > > > "4. Build the bootstrapping environment. Like the utils package these > packages will depend on the native environment so they should be > built on an older system." Fixed in r30297.
Review commit r30297, looks good. Closing.
(In reply to comment #10) > (In reply to comment #6) > > Regarding variants, to choose a variant you should set variant name to 1; > > > > rpmbuild ... --define "native 1" > > > > However one can only build one variant to build and not multiple variants. It > > is not clear what happens if several variants are specified. The way it is > > specified is overcomplicated and it would be more natural to specify the > > specific variant to build in the following way; > > > > rpmbuild ... --define "variant native" > > Probably, but it makes the spec files more complicated. So the current method > is preferred as you rarely build by hand. > > I've elaborated a bit more on multiple variants in r30296. Reviewed 30296, looks good.
libz.so is broken for armel. Somehow the SONAME entry has gone missing, resulting in everything getting NEEDED for the wrong .so file.
This is caused by the horrible triplet used for armel: "arm-linux-gnueabi". It should be grokked as CPU: arm, Vendor: <missing> OS: linux-gnueabi, not CPU: arm, Vendor: linux, OS: gnueabi. But zlib doesn't compensate for that mess and fails to notice that it is building for Linux.
(In reply to comment #16) > This is caused by the horrible triplet used for armel: "arm-linux-gnueabi". It > should be grokked as CPU: arm, Vendor: <missing> OS: linux-gnueabi, not CPU: > arm, Vendor: linux, OS: gnueabi. But zlib doesn't compensate for that mess and > fails to notice that it is building for Linux. Fixed in r30328.
(In reply to comment #17) > (In reply to comment #16) > > This is caused by the horrible triplet used for armel: "arm-linux-gnueabi". It > > should be grokked as CPU: arm, Vendor: <missing> OS: linux-gnueabi, not CPU: > > arm, Vendor: linux, OS: gnueabi. But zlib doesn't compensate for that mess and > > fails to notice that it is building for Linux. > > Fixed in r30328. Works as expected.
