Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1200558 > unrolled thread

Bug#1030668: dinstall could run more often (every hour?)

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1030668: dinstall could run more often (every hour?) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-06-11 16:50 +0200
    Bug#1030668: dinstall could run more often (every hour?) Paul Gevers <elbrus@debian.org> - 2024-08-21 07:20 +0200

#1200558 — Bug#1030668: dinstall could run more often (every hour?)

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Mon, 6 Feb 2023 12:45:17 +0100 Bastian Blank <waldi@debian.org> wrote:
> > The bigger picture is: packages are not part of the Debian build
> > infrastructure (buildd, piuparts, etc) for hours and this blocks many
> > development activities.
> 
> They are.  The buildd use incoming.d.o with accepted packages as
> additional source.

maybe let me use this topic to ask a maybe a little bit tangential question.

For a few days I have been involved in fixing the autopkgtest of my package
mmdebstrap to make it work with Helmut's recent merged-/usr uploads of bash,
dash, util-linux and glibc. My workflow is: fix a thing, upload, see if ci.d.n
is happy, fix bug, repeat. This takes multiple dinstalls and thus multiple days
of work for me. This is not a nice experience for me as a contributor because
instead of being able to sit down and fix the thing, I have to spread my work
across multiple days. I'm aware that there are multiple possible fixes to this:

 1. add support for using incoming as a apt source to ci.d.n
 2. set up my own copy of ci.d.n (difficult as i'm on a slow arm cortex a53 system with 3.7 GB ram)
 3. ask far a shell on ci.d.n from elbrus
 4. add support for apt pinning to autopkgtest on salsaci

I must admit I'm not that frustrated by the six hour dinstall time as while it
is not optimal, it is something I find myself having accepted as the way that
Debian just works. So whatever.

But here comes my tangential question: I have my package (mmdebstrap) which
seems to require overall 29 seconds to build on the builds. The buildd queues
are empty. I upload an hour before the next dinstall. Then it takes 20 minutes
for the ACCEPTED mail to arrive after my dput (why this long?) and then it
takes another half an hour before the buildds even register that there is a new
binary package to be built (why this long?), then it builds in 29 seconds, 10
minutes before the next dinstall it's finished. It still misses it.

So my question: for a package that takes 29 seconds to build and empty buildd
queues. How long before the official dinstall times do I have to upload so that
my package makes it? It is very frustrating to upload an hour in advance, plan
my time for the day accordingly, only to then see it fail. This waiting time
and unpredictability is what makes Debian development extremely frustrating for
me. I do not understand why processing such a tiny package is taking a full
hour. Maybe things would be a bit better if I would at least be able to predict
what is going on at a given time. I literally told my family: hey can I have
some free time later to work on Debian and now it's not going to happen. This
is not a problem of only 4 dinstalls per day but it's a problem of not knowing
what is going on and why. Maybe this can be improved?

Thanks!

cheers, josch

[toc] | [next] | [standalone]

#1209315

[Multipart message — attachments visible in raw view] — view raw

Hi josch,

On Tue, 11 Jun 2024 16:45:53 +0200 Johannes Schauer Marin Rodrigues 
<josch@debian.org> wrote:
>  1. add support for using incoming as a apt source to ci.d.n

This already exists. You can schedule tests via the self-service and add 
buildd-unstable to the sources.

Once this was the default, but for reasons I forgot that didn't work in 
some cases that I looked at often (remember I mostly look at failures). 
Maybe following the chain of comment from the commit [1 ]that removed it 
might hint at it.

Paul

https://salsa.debian.org/ci-team/debci/-/commit/cd10d9aade4b367a384c1a148eb49a12d8fc3802

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web