Bug#805064: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Johannes Schauer]

Control: reopen -1

On Sat, 26 Dec 2015 17:10:13 +0100 Johannes Schauer  wrote:
> whoops, forgot to close this in the upload of 0.67.0-1

it's a bad idea to close bugs manually. Apparently I never pushed the patch for
this one...


signature.asc
Description: signature

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Luca Falavigna]

Control: retitle -1 Commands for chroot update failed stage
Control: severity -1 wishlist


2015-10-31 8:32 GMT+01:00 Johannes Schauer :
> if you run multiple concurrent sbuild instances, would it not be a better idea
> to always run sbuild with --no-apt-update and instead run "sbuild-update
> -udcar" whenever it is actually needed? I imagine that lots of time is lost by
> "apt-get update" being run on every build even if there is nothing new to
> update.

Unfortunately my use case is a special (and therefore quite uncommon)
one, and everytime a build is scheduled there is always need to update
the APT cache because the local repository changes so often.

Anyway, I think you're right saying update and build-dep phases must
be handled separately because it is possible to install build-deps
without updating the chroot, but it would be nice to have a command
for update failures anyway. If you think this is not worth the burden,
feel free to close the bug, and I'll handle my use case in a different
way :)

-- 
Cheers,
Luca

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Johannes Schauer]

Hi Luca,

Quoting Luca Falavigna (2015-11-01 13:36:24)
> Unfortunately my use case is a special (and therefore quite uncommon) one,
> and everytime a build is scheduled there is always need to update the APT
> cache because the local repository changes so often.
> 
> Anyway, I think you're right saying update and build-dep phases must be
> handled separately because it is possible to install build-deps without
> updating the chroot, but it would be nice to have a command for update
> failures anyway. If you think this is not worth the burden, feel free to
> close the bug, and I'll handle my use case in a different way :)

patches appreciated :)

cheers, josch


signature.asc
Description: signature

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Luca Falavigna]

Hi!

2015-10-30 22:00 GMT+01:00 Johannes Schauer :
> What would the benefit be to have a --apt-get-update-failed-commands hook?
> Which hook would one like to run when "apt-get update" failed?

I have a local repository of built packages linked to my sbuild
instances. Everytime a build is successful, the repository indexes are
updated. In case of multiple builds, it could happen newer concurrent
builds start to update apt cache just in the middle of a
apt-ftparchive run, resulting in a "hash sum mismatch" error.

I would like to implement a simple locking mechanism using plain files
(it's definitely not the best approach, I welcome better ideas ;). I
acquire the lock in the chroot-setup and I should manage the removal
of the lock if something goes wrong in whatever stage. With the
current status, if sbuild fails in apt-get-update the lock is never
deleted because no commands are triggered.

-- 
Cheers,
Luca

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Johannes Schauer]

Hi,

Quoting Luca Falavigna (2015-10-31 08:28:58)
> 2015-10-30 22:00 GMT+01:00 Johannes Schauer :
> > What would the benefit be to have a --apt-get-update-failed-commands hook?
> > Which hook would one like to run when "apt-get update" failed?
> 
> I have a local repository of built packages linked to my sbuild
> instances. Everytime a build is successful, the repository indexes are
> updated. In case of multiple builds, it could happen newer concurrent
> builds start to update apt cache just in the middle of a
> apt-ftparchive run, resulting in a "hash sum mismatch" error.
> 
> I would like to implement a simple locking mechanism using plain files
> (it's definitely not the best approach, I welcome better ideas ;). I
> acquire the lock in the chroot-setup and I should manage the removal
> of the lock if something goes wrong in whatever stage. With the
> current status, if sbuild fails in apt-get-update the lock is never deleted
> because no commands are triggered.

if you run multiple concurrent sbuild instances, would it not be a better idea
to always run sbuild with --no-apt-update and instead run "sbuild-update
-udcar" whenever it is actually needed? I imagine that lots of time is lost by
"apt-get update" being run on every build even if there is nothing new to
update.

cheers, josch


signature.asc
Description: signature

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Johannes Schauer]

Hi,

Quoting Luca Falavigna (2015-10-30 20:43:05)
> sometimes my builds fail because of issues during apt-get-update phase. To
> handle these cases, I would like to use --build-deps-failed-commands (or
> alternatively --anything-failed-commands), but it seems neither of them are
> triggered on apt-get-update failed stage.
> 
> Would it be possible to extend the scope of build-deps-failed-commands to
> address this scenario too? After all, "Run  these  commands  we tried to
> install the dependencies but failed for whatever reason" is somewhat included,
> as build-deps won't be processed at all if update is not completed
> successfully...
> 
> Alternatively, having another command type like --apt-get-update-failed-
> commands would be fine too!

The "apt-get update" step is not part of installing build dependencies.

In fact build-deps can be installed even without the "apt-get update" step.
Just run sbuild with --no-apt-update.

What would the benefit be to have a --apt-get-update-failed-commands hook?
Which hook would one like to run when "apt-get update" failed?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Luca Falavigna]

Source: sbuild
Version: 0.66.0-5
Severity: normal

Dear Maintainer,

sometimes my builds fail because of issues during apt-get-update phase. To
handle these cases, I would like to use --build-deps-failed-commands (or
alternatively --anything-failed-commands), but it seems neither of them are
triggered on apt-get-update failed stage.

Would it be possible to extend the scope of build-deps-failed-commands to
address this scenario too? After all, "Run  these  commands  we tried to
install the dependencies but failed for whatever reason" is somewhat included,
as build-deps won't be processed at all if update is not completed
successfully...

Alternatively, having another command type like --apt-get-update-failed-
commands would be fine too!



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)