build slaves: deb8 + deb9?
We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has also deb9 set as build slave to test. I'd move over to deb9 now and no longer build on deb8. What do you guys think, should we build on both deb8 and deb9? ~N
On 01/11/17 14:48, Neels Hofmeyr wrote:
We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has also deb9 set as build slave to test.
I'd move over to deb9 now and no longer build on deb8. What do you guys think, should we build on both deb8 and deb9?
~N
I'm fine with moving to deb9 only as long as nobody can find an important point against doing so. -- - Pau Espin Pedrol <pespin@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hi Neels, On Wed, Nov 01, 2017 at 02:48:27PM +0100, Neels Hofmeyr wrote:
We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has also deb9 set as build slave to test.
I'd move over to deb9 now and no longer build on deb8. What do you guys think, should we build on both deb8 and deb9?
I don't really care all too much, but I am wondering why we are changing a "known working" system. In the end, we are providing packages for Debian >= 8 and Ubuntu >= 16.04. Debian 8 is officially supported until June 2018, and Debian LTS will support it until April 2020. I would argue that the we provide Debian 8 builds at least until June 2018. That of course doesn't determine where we do the build testing before a patch is merged, but in case we start using features not available on Debian 8, we will then only find out once the nightly packages are built, as opposed to before the patch is merged. OTOTH, there are some more interesting warnings generated by later gcc versions in later distributions. All in all, I don't have a strong opinion one way or another. But I am arguing against change without a clear reason/purpose. For example, if the new Debian 9 build-slaves were automatically generated by ansible or Dockerfiles, then that would be a strong argument to migrate, as we could much more easily scale if later needed with such a setup. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi, On Wed, 1 Nov 2017, Neels Hofmeyr wrote:
We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has also deb9 set as build slave to test.
I'd move over to deb9 now and no longer build on deb8. What do you guys think, should we build on both deb8 and deb9?
is there a reason why you build the packages directly on the host? Wouldn't it be better to build it in a chroot (for example with sbuild like the Debian buildd). Thus you would be independent of the OS version of the host and could build for deb8, deb9, deb10, and whatever you want. Thorsten
Well, they hardly build on a "host" anymore. Lots of them build in a docker image, and on build2, the Debian8 is a lxc container. Our goal is to move more builds to docker, and/or to create the build environment (whether lxc or docker or VM or chroot) automatically. For most builds that's easy, but for manuals, doxygen, coverity and some others it requires special privileges. One way to solve this is to build the special jobs only on very specific build slaves and use the regular (auto-generated) build slaves only for gerrit and non-gerrit buildjobs. -- Sent from a mobile device. Please excuse my brevity.
participants (4)
-
Harald Welte -
Neels Hofmeyr -
Pau Espin Pedrol -
Thorsten Alteholz