[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)



On 20/02/2020 13:56, Sylvain Beucler wrote:
> Hi,
> 
> On 20/02/2020 13:35, Emilio Pozuelo Monfort wrote:
>> 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.
> I committed DLA-1993-1 manually in the 2019 folder, fixed the date in
> the .data file, but it looks like this wasn't enough, this is 404:
> https://www.debian.org/lts/security/2019/dla-1993
> https://security-tracker.debian.org/tracker/DLA-1993-1
> https://salsa.debian.org/webmaster-team/webwml/commit/2f79c83e9dac20596a24f6b404cfa2ce1954e3d1
> 
> I guess the web build system has a limitation. Do the webmasters need to
> intervene ?

I still see this in 2019/dla-1993.wml:

# do not modify the following line
#include "$(ENGLISHDIR)/lts/security/2020/dla-1993.data"
# $Id: $

Looks like you actually need to modify it :p

Btw if you parse a file with a Date: header, parse-dla.pl will read that and
place the files in the appropriate dir, so you don't need to do any fixups
afterwards.

Cheers,
Emilio


Reply to: