Acknowledgement sent
to Antoine Beaupre <anarcat@debian.org>:
New Bug report received and forwarded. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>.
(Sat, 29 Jul 2017 20:18:04 GMT) (full text, mbox, link).
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: automatically update schroots
Date: Sat, 29 Jul 2017 16:15:29 -0400
Package: sbuild
Version: 0.73.0-4
Severity: wishlist
Tags: patch
It would be nice if sbuild automatically updated the configured
schroots. As things stand now, a configured schroot will slowly rot
down to a point where new builds will have to download a bunch of base
packages at each run, if sbuild is configured to automatically update
the schroot at build time. And if it's not, the resulting build will
be based on bit-rotten code as well.
I have used the following simple script in /etc/cron.weekly/sbuild:
#!/bin/sh -e
cd /etc/sbuild/chroot/
for chroot in *; do
sbuild-update --update --upgrade --clean --autoclean --autoremove $chroot >/dev/null
done
I don't like it so much: "> /dev/null" is a crude hack, and it should
be possible to silence apt more carefully. But it works and is good
enough for my purpose.
Could that be considered upstream?
Thanks!
A.
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sbuild depends on:
ii adduser 3.115
ii libsbuild-perl 0.73.0-4
ii perl 5.24.1-3+deb9u1
Versions of packages sbuild recommends:
ii autopkgtest 4.4
ii debootstrap 1.0.89
ii schroot 1.6.10-3+b1
Versions of packages sbuild suggests:
pn deborphan <none>
ii kmod 23-2
ii wget 1.18-5
-- no debconf information
Quoting Antoine Beaupre (2017-07-29 22:15:29)
> It would be nice if sbuild automatically updated the configured
> schroots. As things stand now, a configured schroot will slowly rot
> down to a point where new builds will have to download a bunch of base
> packages at each run, if sbuild is configured to automatically update
> the schroot at build time. And if it's not, the resulting build will
> be based on bit-rotten code as well.
>
> I have used the following simple script in /etc/cron.weekly/sbuild:
>
> #!/bin/sh -e
>
> cd /etc/sbuild/chroot/
> for chroot in *; do
> sbuild-update --update --upgrade --clean --autoclean --autoremove $chroot >/dev/null
> done
>
> I don't like it so much: "> /dev/null" is a crude hack, and it should
> be possible to silence apt more carefully. But it works and is good
> enough for my purpose.
>
> Could that be considered upstream?
Do you not find the script in /usr/share/doc/sbuild/examples/sbuild-update-all
sufficient?
Acknowledgement sent
to Antoine Beaupré <anarcat@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>.
(Sun, 30 Jul 2017 14:09:03 GMT) (full text, mbox, link).
On 2017-07-30 08:31:08, Johannes Schauer wrote:
> Quoting Antoine Beaupre (2017-07-29 22:15:29)
>> It would be nice if sbuild automatically updated the configured
>> schroots. As things stand now, a configured schroot will slowly rot
>> down to a point where new builds will have to download a bunch of base
>> packages at each run, if sbuild is configured to automatically update
>> the schroot at build time. And if it's not, the resulting build will
>> be based on bit-rotten code as well.
>>
>> I have used the following simple script in /etc/cron.weekly/sbuild:
>>
>> #!/bin/sh -e
>>
>> cd /etc/sbuild/chroot/
>> for chroot in *; do
>> sbuild-update --update --upgrade --clean --autoclean --autoremove $chroot >/dev/null
>> done
>>
>> I don't like it so much: "> /dev/null" is a crude hack, and it should
>> be possible to silence apt more carefully. But it works and is good
>> enough for my purpose.
>>
>> Could that be considered upstream?
>
> Do you not find the script in /usr/share/doc/sbuild/examples/sbuild-update-all
> sufficient?
s/sufficient// :) I didn't notice that one at all.
How about hooking it straight into cron in some way, or documenting it
somewhere?
Maybe all I need to do is to hook that in the sbuild wiki page?
a.
--
If it's important for you, you'll find a way.
If it's not, you'll find an excuse.
- Unknown
Quoting Antoine Beaupré (2017-07-30 16:05:08)
> On 2017-07-30 08:31:08, Johannes Schauer wrote:
> > Do you not find the script in /usr/share/doc/sbuild/examples/sbuild-update-all
> > sufficient?
>
> s/sufficient// :) I didn't notice that one at all.
>
> How about hooking it straight into cron in some way, or documenting it
> somewhere?
Patches welcome!
> Maybe all I need to do is to hook that in the sbuild wiki page?
Sure. :)
Acknowledgement sent
to Antoine Beaupré <anarcat@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>.
(Sun, 30 Jul 2017 14:27:04 GMT) (full text, mbox, link).
On 2017-07-30 16:06:29, Johannes Schauer wrote:
> Quoting Antoine Beaupré (2017-07-30 16:05:08)
>> On 2017-07-30 08:31:08, Johannes Schauer wrote:
>> > Do you not find the script in /usr/share/doc/sbuild/examples/sbuild-update-all
>> > sufficient?
>>
>> s/sufficient// :) I didn't notice that one at all.
>>
>> How about hooking it straight into cron in some way, or documenting it
>> somewhere?
>
> Patches welcome!
For documenting or for cron?
In fact, how about just installing the script in /usr/sbin?
>> Maybe all I need to do is to hook that in the sbuild wiki page?
>
> Sure. :)
Cool.
A.
--
Freedom is being able to make decisions that affect mainly you. Power
is being able to make decisions that affect others more than you. If
we confuse power with freedom, we will fail to uphold real freedom.
- Richard Stallman
Quoting Antoine Beaupré (2017-07-30 16:26:08)
> On 2017-07-30 16:06:29, Johannes Schauer wrote:
> > Quoting Antoine Beaupré (2017-07-30 16:05:08)
> >> On 2017-07-30 08:31:08, Johannes Schauer wrote:
> >> > Do you not find the script in /usr/share/doc/sbuild/examples/sbuild-update-all
> >> > sufficient?
> >> s/sufficient// :) I didn't notice that one at all.
> >>
> >> How about hooking it straight into cron in some way, or documenting it
> >> somewhere?
> > Patches welcome!
> For documenting or for cron?
For documenting. The cron script already exists. ;)
It even has documentation of how to use it at the top. What's missing is to
somehow tell people that the script exists.
> In fact, how about just installing the script in /usr/sbin?
Since it's not made to be used like a normal script (controlled via environment
variables and redirections for logging) I don't think that would be a good
idea.
Acknowledgement sent
to Antoine Beaupré <anarcat@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>.
(Sun, 30 Jul 2017 14:45:02 GMT) (full text, mbox, link).
On 2017-07-30 16:30:23, Johannes Schauer wrote:
> Quoting Antoine Beaupré (2017-07-30 16:26:08)
>> On 2017-07-30 16:06:29, Johannes Schauer wrote:
>> > Quoting Antoine Beaupré (2017-07-30 16:05:08)
>> >> On 2017-07-30 08:31:08, Johannes Schauer wrote:
>> >> > Do you not find the script in /usr/share/doc/sbuild/examples/sbuild-update-all
>> >> > sufficient?
>> >> s/sufficient// :) I didn't notice that one at all.
>> >>
>> >> How about hooking it straight into cron in some way, or documenting it
>> >> somewhere?
>> > Patches welcome!
>> For documenting or for cron?
>
> For documenting. The cron script already exists. ;)
I mean in /etc/cron.weekly for example.
> It even has documentation of how to use it at the top. What's missing is to
> somehow tell people that the script exists.
Okay, so where can we do this - i suggested the wiki as a starting
point, but I guess adding it to the README file would be good as well?
>> In fact, how about just installing the script in /usr/sbin?
>
> Since it's not made to be used like a normal script (controlled via environment
> variables and redirections for logging) I don't think that would be a good
> idea.
It seems to have sane enough defaults that this shouldn't matter. I
don't see why that would be a problem anyways.
Another advantage in having it in the PATH somewhere is that it could
then have a manpage and be cross-referenced from stuff like
sbuild-update... Autocompletion also does wonder for auto-discovery...
Thanks!
--
Nothing incites to money-crimes like great poverty or great wealth.
- Mark Twain
Quoting Antoine Beaupré (2017-07-30 16:42:29)
> > For documenting. The cron script already exists. ;)
> I mean in /etc/cron.weekly for example.
But putting it there would enable it by default which I'd like to avoid.
> > It even has documentation of how to use it at the top. What's missing is to
> > somehow tell people that the script exists.
>
> Okay, so where can we do this - i suggested the wiki as a starting
> point, but I guess adding it to the README file would be good as well?
README.Debian would be a good place to reference that script.
The wiki is a nice-to-have. All documentation should be inside the package
itself. The wiki should only be a nice extra.
> > Since it's not made to be used like a normal script (controlled via
> > environment variables and redirections for logging) I don't think that
> > would be a good idea.
> It seems to have sane enough defaults that this shouldn't matter. I don't see
> why that would be a problem anyways.
I see the utility of having a script that just does the right thing. Especially
because I guess that most people just run sbuild-update with the same options
(-udcar) all the time anyways.
But schroot is only the default chroot backend of sbuild. If we implement a
method with as much visibility as putting into PATH now, then it should be
future proof to also allow updating other sbuild backends.
> Another advantage in having it in the PATH somewhere is that it could then
> have a manpage and be cross-referenced from stuff like sbuild-update...
> Autocompletion also does wonder for auto-discovery...
sbuild-update could (and probably should) still reference to it even when it
stays in /usr/share/doc
Acknowledgement sent
to Antoine Beaupré <anarcat@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>.
(Sun, 30 Jul 2017 15:48:02 GMT) (full text, mbox, link).
On 2017-07-30 16:47:52, Johannes Schauer wrote:
> Quoting Antoine Beaupré (2017-07-30 16:42:29)
>> > For documenting. The cron script already exists. ;)
>> I mean in /etc/cron.weekly for example.
>
> But putting it there would enable it by default which I'd like to avoid.
>
>> > It even has documentation of how to use it at the top. What's missing is to
>> > somehow tell people that the script exists.
>>
>> Okay, so where can we do this - i suggested the wiki as a starting
>> point, but I guess adding it to the README file would be good as well?
>
> README.Debian would be a good place to reference that script.
ack.
> The wiki is a nice-to-have. All documentation should be inside the package
> itself. The wiki should only be a nice extra.
hmm... there's really a ton of stuff in the wiki that's missing from the
package. how about we merge those somehow?
>> > Since it's not made to be used like a normal script (controlled via
>> > environment variables and redirections for logging) I don't think that
>> > would be a good idea.
>> It seems to have sane enough defaults that this shouldn't matter. I don't see
>> why that would be a problem anyways.
>
> I see the utility of having a script that just does the right thing. Especially
> because I guess that most people just run sbuild-update with the same options
> (-udcar) all the time anyways.
Yep, that's what I found out as well. :)
> But schroot is only the default chroot backend of sbuild. If we implement a
> method with as much visibility as putting into PATH now, then it should be
> future proof to also allow updating other sbuild backends.
... well that's what the BUGS section is for, isn't it? ;)
>> Another advantage in having it in the PATH somewhere is that it could then
>> have a manpage and be cross-referenced from stuff like sbuild-update...
>> Autocompletion also does wonder for auto-discovery...
>
> sbuild-update could (and probably should) still reference to it even when it
> stays in /usr/share/doc
true.
a.
--
Pour marcher au pas d'une musique militaire, il n'y a pas besoin de
cerveau, une moelle épinière suffit.
- Albert Einstein
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.