Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?
On Thursday, 9 January 2020 09:21:23 CET Paul Gevers wrote: > It's a wiki though, you can improve the > text if it's unclear to you. :-) I was not sure to have the right answer.. Now that I've understood, I've updated the wiki. All the best
Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?
Hi Dod, On 09-01-2020 09:17, Dominique Dumont wrote: > https://wiki.debian.org/piuparts/FAQ#Q._Can_I_somehow_tell_piuparts_to_retest_my_package.3F > > The answer mentions that package are not automatically retested. Whether this > applies to package > that passed or failed piupart test is not specified. I assumed the latter. It says: """ Q. Can I somehow tell piuparts to retest my package? A) Not automatically. """ I read that as: *you* can't tell it to retest. I don't read that as: piuparts doesn't do retesting. It's a wiki though, you can improve the text if it's unclear to you. Paul signature.asc Description: OpenPGP digital signature
Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?
On Wednesday, 8 January 2020 20:42:45 CET Andreas Beckmann wrote: > > I checked the piuparts documentation just then [2] and found out that > > unlike ci.d.o or reproducible-build checks, the piuparts test will *not* > > automatically be retried for the same package of the same version (same > > upload). > > Where is that written? Boyuan Yang gave a link to debian wiki: https://wiki.debian.org/piuparts/FAQ#Q._Can_I_somehow_tell_piuparts_to_retest_my_package.3F The answer mentions that package are not automatically retested. Whether this applies to package that passed or failed piupart test is not specified. I assumed the latter. All the best
Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?
On 08/01/2020 19.09, Boyuan Yang wrote:
> 在 2020-01-08三的 16:36 +0530，Pirate Praveen写道：
>>
>> On വ്യാ, Jan 2, 2020 at 21:43, debacle
>> wrote:
>>> On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote:
El jue., 2 ene. 2020 08:28, Julien Cristau
escribió:
> No, it'll eventually get retried and (assuming it passes) the
migration
> block will lift.
And "eventually" is normally how many days?
>>>
>>> If I've learned one thing in Debian, it's patience!
>>
>> Its already 10 days [1] and newly uploaded packages are now getting
>> migrated.
>> So I don't think the packages failed due to bug are getting
>> any priority over the newly uploaded ones.
Correct.
>> I'd have expected them to be
>> retried before new packages. Can this still be done?
Not easily. But I have some ideas for giving priority to
failures that are marked for retesting in the future.
> I checked the piuparts documentation just then [2] and found out that unlike
> ci.d.o or reproducible-build checks, the piuparts test will *not*
> automatically be retried for the same package of the same version (same
> upload).
Where is that written?
> If I understand correctly, it seems that those packages uploaded in
> the period when the piuparts were broken will never migrate to Testing unless
> another upload is made.
That is wrong.
piuparts is chewing on a significant backlog of packages:
jessie2bpo2stretch/ waiting-to-be-tested=1 waiting-for-dependency-to-be-tested=1
bullseye-rcmd/ waiting-to-be-tested=9 waiting-for-dependency-to-be-tested=0
stretch2buster-rcmd/ waiting-to-be-tested=10
waiting-for-dependency-to-be-tested=1
stable2sid/ waiting-to-be-tested=44 waiting-for-dependency-to-be-tested=31
testing2sid/ waiting-to-be-tested=45 waiting-for-dependency-to-be-tested=134
stable22sid/ waiting-to-be-tested=55 waiting-for-dependency-to-be-tested=815
sid-merged-usr/ waiting-to-be-tested=75 waiting-for-dependency-to-be-tested=83
wheezy2jessie-lts/ waiting-to-be-tested=232
waiting-for-dependency-to-be-tested=611
oldstable222sid/ waiting-to-be-tested=5345
waiting-for-dependency-to-be-tested=9246
The processing preferences in piuparts are
1) untested packages
2) packages marked for retesting, starting with failing ones
failed logs get marked for retesting after 2 days
passed logs get marked for retesting after three months
(this process gets throttled if the slaves cannot process them in time)
failed logs expire (i.e. they get deleted) after about a week
(throttled to about 50-100 logs per day)
This expiration process ensures progress in situations like these.
The ~200 failures in sid are all queued for rechecking, but wait
for idle slaves.
Using the expiration process, they should all get retested within a few days.
This does work. E.g. pocl migrated yesterday after being blocked by piuparts
for a few days.
> This is definitely far from ideal. Is it possible to manually trigger a retry
> for each packages hit by this regression? At least asking maintainers to
> search throught britney update excuses [3] and making another upload is really
> not a valid option. BTW, searching "Rejected due to piuparts regression" in
> [3] gives 135 results.
>
> [2]
> https://wiki.debian.org/piuparts/FAQ#Q._Can_I_somehow_tell_piuparts_to_retest_my_package.3F
>
> [3] https://release.debian.org/britney/update_excuses.html
Andreas
PS:
anbe@pejacevic:/srv/piuparts.debian.org/master$ for x in */ ; do grep
waiting-to-be-tested $x/master.log | tail -n 1 | awk "{ print \"$x \" \$6 \"
\" \$7 }" ; done | sort -n -t= -k2
Re: Migration to testing blocked by broken piuparts?
在 2020-01-08三的 16:36 +0530，Pirate Praveen写道： > > On വ്യാ, Jan 2, 2020 at 21:43, debacle > wrote: > > On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote: > > > El jue., 2 ene. 2020 08:28, Julien Cristau > > > escribió: > > > > No, it'll eventually get retried and (assuming it passes) the > > > migration > > > > block will lift. > > > > > > And "eventually" is normally how many days? > > > > If I've learned one thing in Debian, it's patience! > > Its already 10 days [1] and newly uploaded packages are now getting > migrated. So I don't think the packages failed due to bug are getting > any priority over the newly uploaded ones. I'd have expected them to be > retried before new packages. Can this still be done? > > [1] https://tracker.debian.org/pkg/micro I checked the piuparts documentation just then [2] and found out that unlike ci.d.o or reproducible-build checks, the piuparts test will *not* automatically be retried for the same package of the same version (same upload). If I understand correctly, it seems that those packages uploaded in the period when the piuparts were broken will never migrate to Testing unless another upload is made. This is definitely far from ideal. Is it possible to manually trigger a retry for each packages hit by this regression? At least asking maintainers to search throught britney update excuses [3] and making another upload is really not a valid option. BTW, searching "Rejected due to piuparts regression" in [3] gives 135 results. [2] https://wiki.debian.org/piuparts/FAQ#Q._Can_I_somehow_tell_piuparts_to_retest_my_package.3F [3] https://release.debian.org/britney/update_excuses.html -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: Migration to testing blocked by broken piuparts?
On വ്യാ, Jan 2, 2020 at 21:43, debacle wrote: On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote: El jue., 2 ene. 2020 08:28, Julien Cristau escribió: > No, it'll eventually get retried and (assuming it passes) the migration > block will lift. And "eventually" is normally how many days? If I've learned one thing in Debian, it's patience! Its already 10 days [1] and newly uploaded packages are now getting migrated. So I don't think the packages failed due to bug are getting any priority over the newly uploaded ones. I'd have expected them to be retried before new packages. Can this still be done? [1] https://tracker.debian.org/pkg/micro
Re: Migration to testing blocked by broken piuparts?
On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote: > El jue., 2 ene. 2020 08:28, Julien Cristau escribió: > > No, it'll eventually get retried and (assuming it passes) the migration > > block will lift. > > And "eventually" is normally how many days? If I've learned one thing in Debian, it's patience! -- Paciencia... La vida es así. Ninguno es culpable, si es que hay una culpa.
Re: Migration to testing blocked by broken piuparts?
Hi! El jue., 2 ene. 2020 08:28, Julien Cristau escribió: > On Thu, Jan 2, 2020 at 12:03:43 +0100, W. Martin Borgert wrote: > > > Hi, > > > > two packages[ą, ˛] I uploaded are "Rejected due to piuparts > > regression". I learned, that this is due to a bug in piuparts. > > Any solution on its way? Would I need to re-upload later? > > > No, it'll eventually get retried and (assuming it passes) the migration > block will lift. > And "eventually" is normally how many days? >
Re: Migration to testing blocked by broken piuparts?
On Thu, Jan 2, 2020 at 12:03:43 +0100, W. Martin Borgert wrote: > Hi, > > two packages[¹, ²] I uploaded are "Rejected due to piuparts > regression". I learned, that this is due to a bug in piuparts. > Any solution on its way? Would I need to re-upload later? > No, it'll eventually get retried and (assuming it passes) the migration block will lift. Cheers, Julien
Re: Migration to testing blocked by broken piuparts?
Am 02.01.2020 um 12:03 schrieb W. Martin Borgert: > Hi, > > two packages[¹, ²] I uploaded are "Rejected due to piuparts > regression". I learned, that this is due to a bug in piuparts. > Any solution on its way? Would I need to re-upload later? > > TIA & Cheers > > PS: Many thanks for running piuparts anyway. Such bugs happen, > but the extra safety net it provides in the normal case is > appreciated! > > ¹ https://tracker.debian.org/pkg/python-aiohttp-session > ² https://tracker.debian.org/pkg/python-aiohttp-security Same here: https://tracker.debian.org/pkg/mlt -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
Migration to testing blocked by broken piuparts?
Hi, two packages[¹, ²] I uploaded are "Rejected due to piuparts regression". I learned, that this is due to a bug in piuparts. Any solution on its way? Would I need to re-upload later? TIA & Cheers PS: Many thanks for running piuparts anyway. Such bugs happen, but the extra safety net it provides in the normal case is appreciated! ¹ https://tracker.debian.org/pkg/python-aiohttp-session ² https://tracker.debian.org/pkg/python-aiohttp-security
