<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 31, 2017 at 4:24 PM, Johannes Schauer <span dir="ltr"><<a href="mailto:josch@debian.org" target="_blank">josch@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quoting Michael Stapelberg (2017-07-31 14:19:16)<br>
<span class="gmail-">> Unless I’m mistaken, the following is what we’d need to recommend to new<br>
> users:<br>
><br>
> % sudo apt install sbuild apt-cacher-ng lintian<br>
<br>
</span>Why install lintian?<br></blockquote><div><br></div><div>So that it is available to be used, as per the changed default?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> % sudo adduser --quiet -- "$USER" sbuild<br>
<br>
</span>Better:<br>
<br>
sudo sbuild-adduser $USER<br></blockquote><div><br></div><div>sbuild-adduser gives instructions which don’t apply in our case (AFAIR).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> % sudo sbuild-createchroot \<br>
>   --command-prefix=eatmydata \<br>
>   --include=eatmydata \<br>
>   --alias=UNRELEASED \<br>
>   --alias=sid \<br>
>   unstable \<br>
>   /srv/chroot/unstable-amd64-<wbr>sbuild \<br>
>   <a href="http://localhost:3142/deb.debian.org/debian" rel="noreferrer" target="_blank">http://localhost:3142/deb.<wbr>debian.org/debian</a><br>
<br>
</span>That is *if* the machine of the user is amd64.<br></blockquote><div><br></div><div>Substitute $(dpkg --print-architecture).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, this part would be Debian-specific. Downstream distributions would have<br>
to adapt the alias and mirror values.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, didn't you also propose to make the schroot be run in a tmpfs the<br>
default? In that case, eatmydata would be quite pointless, no?<br></blockquote><div><br></div><div>I proposed suggesting to build in tmpfs, not doing it by default. If you think people in general have enough RAM for that to be a good idea, I’ll happily change it and get rid of eatmydata.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> % echo 15 */6 * * * root /usr/share/doc/sbuild/<wbr>examples/sbuild-update-all |<br>
> sudo tee /etc/cron.d/sbuild-update-all<br>
<br>
</span>Every six hours? I find that a bit excessive. This should certainly be<br></blockquote><div><br></div><div>This is the first example from /usr/share/doc/sbuild/examples/sbuild-update-all itself, which I assumed was a recommendation. We could dial it down to once a day.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
configurable. Not everybody is behind an internet connection which is fast<br></blockquote><div><br></div><div>It is configurable, just edit the file afterwards :).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
enough and/or where one doesn't pay per MB.<br></blockquote><div><br></div><div>True, but I’d wager most DMs/DDs (the primary target audience of this endavour) are. We can slap a fat warning on top of the package description to clarify that we’re operating under the assumption.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> % newgrp sbuild<br>
<br>
This would only have an effect on the currently open terminal and would have to<br>
be executed again on every new terminal session until the user *really* logs<br>
out and in again.<br></blockquote><div><br></div><div>Yes. We can tell the user about this fact, but running newgrp seems like a good idea nevertheless.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> That seems quite involved over, say, “apt install sbuild-setup &&<br>
> sbuild-setup unstable”.<br>
><br>
> Hence, I’d definitely appreciate a script which does all the over having to<br>
> refer to a wiki page and copy&paste long commands.<br>
<br>
</span>Except that the sbuild-setup command would need to become quite complex because<br>
it the user has to be able to control:<br>
<br>
 - how to setup schroot (overlayfs? tmpfs?)<br></blockquote><div><br></div><div>The default.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - where to put the chroots<br></blockquote><div><br></div><div>The default.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - which distribution aliases (distribution specific)<br></blockquote><div><br></div><div>sid for Debian. Downstream can change this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - which extra packages to include (like eatmydata)<br></blockquote><div><br></div><div>Only eatmydata.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - whether this is the first run or not (warn if the script is run for a second<br>
   time)<br>
 - how often to update the chroots via cron<br></blockquote><div><br></div><div>Once a day, change the crontab file if you want to change that.</div><div><br></div><div>To summarize: the point of this script is to provide an easy way to get sbuild for people who don’t care. People who do care about any of these details should not use it. I think there is significant value in providing an easy path, if only as a stop-gap until the user gets around to looking into this subject area in more depth, and creating their own preferred setup.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And then we have a script with a complexity which is close to where<br>
sbuild-createchroot already is.<br>
<br>
Or are you actually convinced that it is possible to find a set of defaults<br>
which fits even half the userbase of sbuild?<br>
<br>
Since we are down to two mandatory (and two optional) commands after running<br>
"apt install sbuild", I'd argue that a superior solution would be to improve<br>
the documentation of which commands to run for a "typical" setup. I fear that<br>
trying to create a "one-size-fits-all" script can have many unintended<br>
side-effects (thinking of users behind bad or costly internet, who use schroot<br>
for other purposes, who don't want to install another deamon like<br>
apt-cacher-ng, who are not building for Debian but for downstreams...). I'm not<br>
convinced that the time that the user would invest to *really* understand the<br>
things that an sbuild-setup script is actually doing would not be better spent<br>
in learning how to use the individual tools.<br></blockquote><div><br></div><div>I think the following suggestion takes care of all the concerns you brought up: Let’s name it sbuild-debian-developer-setup, describe that the goal is to provide an sbuild setup which can build packages for Debian unstable, automates maintenance with its daily update cronjob and assumes an un-metered internet connection.</div><div><br></div><div>Does that sound reasonable?</div></div><div><br></div>-- <br><div class="gmail_signature">Best regards,<br>Michael</div>
</div></div>