On Sun, Jul 30, 2017 at 7:53 PM, Johannes Schauer <jo...@debian.org> wrote:
> Hi, > > Quoting Michael Stapelberg (2017-06-02 18:23:02) > > Thanks for the review. Answers inline: > > sorry for the delay. I'm under a pile of work and this wasn't on the top > of my > todo list. But let me not stall your work: > > > > > # Enable eatmydata: occasionally losing a test build is preferable > over > > > longer > > > > # build times and disk wear. > > > > echo "command-prefix=eatmydata" >> "${tmp}" > > > > > > I don't see sbuild-createchroot mangling with command-prefix at all. So > > > why do > > > you filter it out initially? > > > > > > Would it not be better to add a command line option to > sbuild-createchroot > > > which allows setting a custom command-prefix? Then you would not need > to > > > manually mangle the created config file at all and lots of the > problems I > > > mentioned above and other fragile things would go away. > > Sure. Can you take care of this or do you want me to send a patch? > > Please file a new bug with a patch. > Done: https://bugs.debian.org/870260 > > > > > chmod 644 "${tmp}" > > > > mv "${tmp}" "${config}" > > > > > > > > # Copy a modified example sbuildrc config file > > > > for homedir in $(getent passwd | perl -F: -nlE '$F[2] >= 1000 && > $F[2] > > > <= 59999 && say $F[5]') > > > > do > > > > userconfig="${homedir}/.sbuildrc" > > > > if [ ! -e "${userconfig}" ] > > > > then > > > > (grep -v -E "^(# don't remove this|1;\$)" > /usr/share/doc/sbuild/examples/example.sbuildrc > > > && cat /usr/share/doc/sbuild-debian-setup/sbuildrc) > "${userconfig}" > > > > fi > > > > done > > > > > > Instead of crafting a custom sbuildrc, we can also talk about changing > the > > > existing defaults. > > > > > > For example you set "$build_arch_all = 1;" I can certainly see how it > makes > > > sense to change this default for sbuild but keep it at 0 for buildd. > > Sounds good. Same question: can you take care of this, or should I send a > > patch? > > For personal users of sbuild (users of sbuild and not buildd) they will > probably always want to build arch:all packages. So lets change the > default! > > Again, a short bug with patch is appreciated. > Done: https://bugs.debian.org/870263 > > > > Then you set "$build_source = 1;" but I don't know why you would need > this. > > > Sbuild is not there to build the source package. The source package is > its > > > input not its output. Why would you want sbuild to build it again? > > The wiki page contained some confusing advice, which I now removed. > > Thanks! > > > > Lastly, you set "$run_lintian = 1;" which I also think would be a > sensible > > > thing to change in the defaults. > > Sounds good, see above. > > You can include that in the other bug. > See above. > > > > > if [ ! -e "/etc/schroot/setup.d/04tmpfs" ] > > > > then > > > > echo "" > > > > echo " If you can spare the RAM, you can enable building in > tmpfs > > > using:" > > > > echo "" > > > > echo " sudo ln -s /etc/schroot/setup-available.d > /overlays-in-tmpfs > > > /etc/schroot/setup.d/04tmpfs" > > > > echo "" > > > > fi > > > > > > This will affect *all* schroot sessions and not just those used by > sbuild. > > > As such, this should rather go into documentation for schroot. But > maybe > > > there is a way to make this mounting specific to sbuild schroots? > > I don’t know, you’re the expert :). I think users who know what schroot > is > > (to me it’s “the thing which sbuild uses”) and who use it for anything > but > > sbuild will realize what’s happening here. We could add some wording to > > that extent. > > More docs in this direction would be appreciated. > > > > I think in summary much of what this script does can be achieved by: > > > > > > - improving existing documentation > > I updated the wiki page based on your review. > > Thanks a lot! > > > > - changing configuration defaults to more sensible values > > > - adding more options to existing tools like sbuild-createchroot > > > - using existing tools instead of using creative ways to work around > them > > > (apt-cacher-ng) > > > > > > If we do all that, what is left that a new script should take care of? > > The following things are still left: > > > > • Adding the user(s) to the sbuild group > > That's just one call to sbuild-adduser > > > • Creating the chroot with all the options we discussed > > Yet another single call to sbuild-createchroot > > > • Suggesting to build in tmpfs > > I'd consider that an optional tip that can be listed in the docs somewhere. > > > • Periodically updating the schroots (not strictly speaking part of the > > script itself, but listing it here anyway) > > This can be done using the cron script from > /usr/share/doc/sbuild/examples/sbuild-update-all > > Bug #870102 is about making this cron script more visible by adding better > documentation. > > So all in all, we are down to running two scripts to setup sbuild. One of > that > is only required once after installation while the other can be run > multiple > times to setup multiple chroots. I don't think a wrapper script for these > two > scripts makes much sense. Lets rather better document which two commands > one > needs to run after installing sbuild for the first time. > Unless I’m mistaken, the following is what we’d need to recommend to new users: % sudo apt install sbuild apt-cacher-ng lintian % sudo adduser --quiet -- "$USER" sbuild % sudo sbuild-createchroot \ --command-prefix=eatmydata \ --include=eatmydata \ --alias=UNRELEASED \ --alias=sid \ unstable \ /srv/chroot/unstable-amd64-sbuild \ http://localhost:3142/deb.debian.org/debian % echo 15 */6 * * * root /usr/share/doc/sbuild/examples/sbuild-update-all | sudo tee /etc/cron.d/sbuild-update-all % newgrp sbuild That seems quite involved over, say, “apt install sbuild-setup && sbuild-setup unstable”. Hence, I’d definitely appreciate a script which does all the over having to refer to a wiki page and copy&paste long commands. What do you think? -- Best regards, Michael