Re: opi2a back! init system variations?
On Mon, Oct 10, 2016 at 06:46:50PM +, Holger Levsen wrote: > and now also been added back to the build network, with 3 new builder > jobs for a total of 60 (running on a total of 20 armhf boards). ^ 22 armhf board is correct :) (+sorry for the noise.) -- cheers, Holger signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: opi2a back! init system variations?
Hey, On Wed, Oct 05, 2016 at 08:42:17PM -0700, Vagrant Cascadian wrote: > opi2a is back! and now also been added back to the build network, with 3 new builder jobs for a total of 60 (running on a total of 20 armhf boards). Not sure how to rearrange build jobs off the top of my > For some reason, systemd wasn't starting consistantly, hanging on > systemd-logind. Oddly, it worked well enough to still run build jobs, > but restarting daemons and upgrading some packages would hang. > > With some effort, I switched to sysvinit from a debug shell, finished > some pending upgrades, of which were several systemd related. After the > upgrade, it's been working consistantly using systemd ever since... So > I don't *really* know why it's working now... but it is. Best guess is > it crashed in the middle of a upgrade (maybe disk full?) at some point > and corrupted some relevent file(s)? hehe, nice workaround! > The whole ordeal did trigger a thought about adding init system > variations to the builds... at least could do systemd and sysvinit at > the moment without a *huge* amount of trouble, unless we're relying on > some init-specific features for the builders? well, we ideally want deterministic (and easy to spot) variations, to ease debugging of unreproducible issues. For the "easy to spot" part, the armhf network is sadly not really suited. With our amd64+i386 nodes (due to their low number) it's trivial to guarantee that exactly one of the two builds will be done on a host with a variation, while the other build is not. On our armhf nodes, it's impossible (for this kind of variation). On Fri, Oct 07, 2016 at 01:59:29PM -0400, Daniel Kahn Gillmor wrote: > fwiw, i imagine that the choice of what is pid 1 (much like the choice > of what is /bin/sh) could be a significant factor in some builds. I'd > be happy to see this variation added to the list of things we'd like to > eventually test. sadly I tend to agree and have added this to our TODO list… -- cheers, Holger signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: opi2a back! init system variations?
On Wed 2016-10-05 23:42:17 -0400, Vagrant Cascadian wrote: > The whole ordeal did trigger a thought about adding init system > variations to the builds... at least could do systemd and sysvinit at > the moment without a *huge* amount of trouble, unless we're relying on > some init-specific features for the builders? fwiw, i imagine that the choice of what is pid 1 (much like the choice of what is /bin/sh) could be a significant factor in some builds. I'd be happy to see this variation added to the list of things we'd like to eventually test. --dkg ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
opi2a back! init system variations?
opi2a is back! Not sure how to rearrange build jobs off the top of my head, but we've got several cores just sittle idle again. :) For some reason, systemd wasn't starting consistantly, hanging on systemd-logind. Oddly, it worked well enough to still run build jobs, but restarting daemons and upgrading some packages would hang. With some effort, I switched to sysvinit from a debug shell, finished some pending upgrades, of which were several systemd related. After the upgrade, it's been working consistantly using systemd ever since... So I don't *really* know why it's working now... but it is. Best guess is it crashed in the middle of a upgrade (maybe disk full?) at some point and corrupted some relevent file(s)? The whole ordeal did trigger a thought about adding init system variations to the builds... at least could do systemd and sysvinit at the moment without a *huge* amount of trouble, unless we're relying on some init-specific features for the builders? live well, vagrant signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
