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

Re: Bug#859122: about 500 DLAs missing from the website

Hello all

Holger Levsen merged the generated DLAs and I've worked to create the
/lts tree to show them separated from the DSA. I have moved to this new
/lts folder the DLAs from years 2014, 2015 and 2016 that we had already,
and remove them from the /security tree and removed references to DLAs
in the Makefiles/indexes in /security.

I think it's mostly done, I've closed all the related MR except one, but
there are some small tasks left, that I hope we can solve together:

* I have initially copied the content of /security/ to /lts/security,
removed subfolders that I think are not needed (audit, key-rollover,
oval, undated) and some other files that I think they were not needed
too. Then I did a search and replace DSA -> DLA, dsa- -> dla- in the
scripts, makefiles and indexes, and fixed the paths, and built locally
(with "make) and I couldn't spot errors, but I don't trust every file
that is currently in /lts/security is needed or has been used with my
"make" command, so a review of the folder (comparing it with /security)
done by an LTS or security team member, is welcome.

* The README needs to be reviewed and adapted (I just did the search and
replace dsa -> dla and DSA -> DLA).

* I guess that parse-advisory.pl (and maybe others) can be removed, but
I was not confident to do it without advice.

* I didn't check the results of the generated RSS feeds. If anybody uses
RSS readers, a review is welcome too.

* The /lts/security/YYYY/index.*.html files show the last advisory for
the cases where there are several files with the same beginning (e.g.
for DSA-nnnn and DSA-nnnn-2, both html files are generated, but the
index only points to the -2 file). If this is not the intended
behaviour, changes in index.wml and Makefiles are needed.

* Please review the content (text, links) of these files:


I've tried to be short (for the case translators are fast and then you
decide to heavy rewrite, to not to loose much work).

* Translations have been handled, but I've left the *title* of these
files unchanged:


All those files have title "LTS Security Advisories from YYYY" (being
YYYY the year: 2014, or 2015, or 2016). I guess translators can do a
quick search and replace with the correct sentence and they don't need
to update the commit hash, that's already done. I'll contact translators
and point them to this message.

* This new /lts section of the website is not referenced yet in other
places of the Debian website. I'm not sure if it should be referenced in
/security, in /releases/XXXX, or in both. There is also the temptation
of creating a link in the homepage but there is also the suggestion of
reducing the links in the homepage, so... For now, I'll try to add it to
the sitemap and see how many references to the LTS wiki page we have
currently, to see if any of them can be replaced with link to this
section in the website. But I'll wait some days to do it because it's
not clear for me if you want to populate the section to cover all the
aspects of LTS, or keep it only/mainly for security stuff.

* We still need the Apache redirects, so the people that try the old
URLs (wether directly because they knew, or via the security tracker),
find the files they need. What we need to do is send a patch to


that sets the redirect from
https://www.debian.org/security/any_year/dla-whatever to

* Adaptation in the security tracker so the new URL paths are used from
now on is also needed.

Thanks for reading so long!

Kind regards

El 8/2/19 a las 15:52, Holger Levsen escribió:
> Hi Antoine,
> On Sun, Feb 03, 2019 at 02:08:06PM +0100, Salvatore Bonaccorso wrote:
>> Thanks for working on this.
> indeed!
>> On Fri, Feb 01, 2019 at 01:44:10PM -0500, Antoine Beaupré wrote:
>>> On 2018-12-19 18:05:36, Antoine Beaupré wrote:
>>>> The DLAs are visible here:
>>>> https://www-staging.debian.org/security/2018/dla-1580
> that one is also visible on
> https://www.debian.org/security/2018/dla-1580 now \o/
>>>> One thing that's unclear is how the entries get added to the main list
>>>> in:
>>>> https://www-staging.debian.org/security/2018/
>> IMHO they should not be mixed into the same namespace as the DSAs.
>> https://www.debian.org/security/ is very specific to the
>> debian-security-announce list and contains items for e.g. contacting
>> the Debian security team or referecing the respective FAQ.
> I agree.
> (Thus I think
> https://salsa.debian.org/webmaster-team/webwml/merge_requests/50 should
> be cloded and not merged.)
> OTOH I plan to review
> https://salsa.debian.org/webmaster-team/webwml/merge_requests/53 once
> more and then merge it.)
>> I think having a dedicated https://www.debian.org/lts/ where those can
>> be collected and having further information on LTS would be somehow
>> better.
> Yup.
>> This will need an adjustment to the tracker side as well so that
>> sources filed for Debian LTS DLA's will not link to
>> https://www.debian.org/security/$year/dla-$nr .
> *nods*
>> If a dedicated subpage is not needed and the only purpose is to link
>> to a webversion, and the DLA's do not show up in the overall view then
>> possibly the status quo is still okay.
> I think it's ok for now / the current situation is an improvement over
> what we had before, but we really want/need one a dedicated page like
> https://www.debian.org/lts/ too.
> On Sun, Feb 03, 2019 at 02:38:02PM +0100, Laura Arjona Reina wrote:
>> Note that we already have some DLAs published in
>> www.debian.org/security/YYYY, for the years 2014, 2015 and 2016. See
>> for
>> example:
>> https://www.debian.org/security/2014/index
>> I don't mind to move the already published DLAs to other place if
>> people
>> decides it's better, but I frankly don't know if/where these URLs are
>> used/publicised (in Debian and maybe other places too), and we may
>> need
>> to setup redirectors from the current URLs to the new ones (no problem
>> with that, I say it only to not forget, in case we decide to move all
>> the DLAs to a different place).
> right. we should do that and probably track this with a bug...

Laura Arjona Reina

Reply to: