On 06/02/23 12:14, Bastian Blank wrote:
On Mon, Feb 06, 2023 at 11:27:03AM +0100, Gioele Barabucci wrote:
Currently dinstall is run only once every 6 hours. This means that many
operations are blocked for a long time. For instance uploading a -2 version
after a package has cleared the NEW queue.
Can you please show the error you got from the upload?
A -2 version will be REJECTed by mentors.d.n if version -1 is still
being processed:
> Unfortunately your package "bats-file" was rejected
> because of the following reason:
>
> Dsc is invalid
>
> Failed to connect to network resource.
> Url was: https://deb.debian.org/debian/pool/main/....orig.tar.gz
>
> HTTP Error 404: Not Found
But this is just an example.
The bigger picture is: packages are not part of the Debian build
infrastructure (buildd, piuparts, etc) for hours and this blocks many
development activities.
Such long delays tend to ruin the development flow, especially of volunteers
that happen to have just a couple of hours at their disposal. This is a well
known source of frustration [1].
Not sure what you mean. Can you please explain the workflow you are
talking about?
The linked Michale Stapelberg's blog post explains it better than I can:
https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/#old-infrastructure-package-uploads
Given that a dinstall run generally takes only few minutes, it should be
feasible to run dinstall at least hourly.
It takes up to three hours. This process includes the overall updates
to all the mirrors outside of Debian.
Yes, sometimes it can take a long time, but usually it finishes in 30 to
40 minutes [1]. And that time is going to be even shorter if dinstall is
run more frequently and there are thus fewer packages waiting to be
processed.
[1] https://ftp-master.debian.org/stat/dinstall.png
I assume that the already implemented locking mechanism will take care
of the few occasions in which dinstall will take more than the allotted
amount of time.
Regards,
--
Gioele Barabucci
