Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On 20/02/2020 12:40, Abhijith PA wrote:
> Holger,
>
> On 19/02/20 3:15 pm, Emilio Pozuelo Monfort wrote:
>
>
>> The attached patch allows that script to also print author information when
>> using a local copy of the security-tracker repo with the --list option.
>> Otherwise it should fall back to the status quo. The current output is:
>>
>> ERROR: .data or .wml file missing for DLA 2106-1 (reserved by Roberto C. Sánchez)
>> ERROR: .data or .wml file missing for DLA 2105-1 (reserved by Christoph Berg)
>> ERROR: .data or .wml file missing for DLA 2103-1 (reserved by Holger Levsen)
>> ERROR: .data or .wml file missing for DLA 2101-1 (reserved by Bastian Blank)
>> ERROR: .data or .wml file missing for DLA 2083-1 (reserved by Chris Lamb)
>> ERROR: .data or .wml file missing for DLA 2079-1 (reserved by Abhijith PA)
>> ERROR: .data or .wml file missing for DLA 2053-1 (reserved by Abhijith PA)
>
> DLA 2053-1 pushed to webmaster-team repo a month ago.
>
> https://salsa.debian.org/webmaster-team/webwml/commit/b0a5c59185a4d21906ee3882d8c9004e25c7b13d
data/DLA/list says:
[31 Dec 2019] DLA-2053-1 otrs2 - security update
i.e. this was reserved in 2019. Thus the script that generates this report is
looking in the 2019/ folder of the website, but it is actually living in the
2020/ folder, most likely due to parse-dla.pl placing it there because of the
Date header of your email (which was sent in 2020).
Normally reserving a DLA and sending it a few hours later wouldn't cause
significant trouble (except for out of order announcements), but it did here due
to the year offset and how things are archived in the website. Note how also the
source link in [1] is broken.
[1] https://security-tracker.debian.org/tracker/DLA-2053-1
We have three options here:
- move the files in the website to 2019/, breaking the current link
- change the date in data/DLA/list to Jan 1 2020
- keep the status quo (with the broken link in the tracker) and change the
script to find the files even if they are in another year
Given that commit dafc13ef in the security-tracker hasn't broken anything, I'll
just update the date in data/DLA/list to fix the tracker link and getting that
DLA off the report.
Cheers,
Emilio
Reply to: