Re: Upgrade problems from LTS -> LTS+1
Hi Oh, I did not know about bin/lts-needs-forward-port.py. I wonder if I just made something very similar. In any case, here is the script I wrote. http://apt.inguza.net/lts/checkversions.pl Nothing advanced, but it does the job. // Ola On Thu, 20 May 2021 at 19:25, Salvatore Bonaccorso wrote: > Hi, > > On Thu, May 20, 2021 at 08:39:43AM +0200, Ola Lundqvist wrote: > > Hi Salvatore > > > > It is parameterized to check any release update. So it can be used to > check > > any previous version to any later version. > > > > It has the parameters --old, --old-sec, --new and --new-sec to point to > any > > relevant packages files. > > > > It can be improved to add other things like proposed updates as well with > > few modifications. > > Also it can be improved by making --old-sec and --new-sec optional, right > > now they are mandatory. > > > > So I think it can be used by the regular security team too. > > TBH, I do not think we need another script more in the bin folder. For > the relevant suites covered by the security tracker itself we have for > instance the bin/lts-needs-forward-port.py. This covers the situation > where LTS is ahead to the regular support suites (and future LTS). The > script surely could be improved further to filter out what is actually > already pending/planned for the next point release by including > information from the next-point-update.txt files (like tracker.d.o > does as well with the TODO items). > > And for the ELTS -> LTS cases we do not need the script in the regular > security-tracker but rather in ELTS specific toolchests. > > But maybe you could post your draft somewhere, so one can compare the > pros and contras of it? > > I would at least be interested into seeing what you have implemented. > > Regards, > Salvatore > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Upgrade problems from LTS -> LTS+1
Hi, On Thu, May 20, 2021 at 08:39:43AM +0200, Ola Lundqvist wrote: > Hi Salvatore > > It is parameterized to check any release update. So it can be used to check > any previous version to any later version. > > It has the parameters --old, --old-sec, --new and --new-sec to point to any > relevant packages files. > > It can be improved to add other things like proposed updates as well with > few modifications. > Also it can be improved by making --old-sec and --new-sec optional, right > now they are mandatory. > > So I think it can be used by the regular security team too. TBH, I do not think we need another script more in the bin folder. For the relevant suites covered by the security tracker itself we have for instance the bin/lts-needs-forward-port.py. This covers the situation where LTS is ahead to the regular support suites (and future LTS). The script surely could be improved further to filter out what is actually already pending/planned for the next point release by including information from the next-point-update.txt files (like tracker.d.o does as well with the TODO items). And for the ELTS -> LTS cases we do not need the script in the regular security-tracker but rather in ELTS specific toolchests. But maybe you could post your draft somewhere, so one can compare the pros and contras of it? I would at least be interested into seeing what you have implemented. Regards, Salvatore
Re: Upgrade problems from LTS -> LTS+1
Hi Salvatore It is parameterized to check any release update. So it can be used to check any previous version to any later version. It has the parameters --old, --old-sec, --new and --new-sec to point to any relevant packages files. It can be improved to add other things like proposed updates as well with few modifications. Also it can be improved by making --old-sec and --new-sec optional, right now they are mandatory. So I think it can be used by the regular security team too. Cheers // Ola On Thu, 20 May 2021 at 08:23, Salvatore Bonaccorso wrote: > Hi, > > On Thu, May 20, 2021 at 08:14:12AM +0200, Ola Lundqvist wrote: > > Hi > > > > I was thinking more on placing it in the security tracker bin folder for > > easy access. Or do you think we should consider it as a separate tool > with > > its own repo? > > Given (if) it is specific to things fixed in previous LTS (now ELTS) > to LTS, please keep it outside the security-tracker and use it instead > in a (E)LTS specific repository. > > Alternatively if it's parametrised as such that by can cover the > regular supported suites by default (not from "external" ELTS -> LTS) > and report problems from (currently stretch -> buster), and e.g. by an > --lts parameter and a URI from jessie -> stretch -- then I guess we > can discuss indeed having it in the security-tracker bin. But in > general the rule would be not ELTS dependencies in the > security-tracker itself. > > Regards, > Salvatore > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Upgrade problems from LTS -> LTS+1
Hi, On Thu, May 20, 2021 at 08:14:12AM +0200, Ola Lundqvist wrote: > Hi > > I was thinking more on placing it in the security tracker bin folder for > easy access. Or do you think we should consider it as a separate tool with > its own repo? Given (if) it is specific to things fixed in previous LTS (now ELTS) to LTS, please keep it outside the security-tracker and use it instead in a (E)LTS specific repository. Alternatively if it's parametrised as such that by can cover the regular supported suites by default (not from "external" ELTS -> LTS) and report problems from (currently stretch -> buster), and e.g. by an --lts parameter and a URI from jessie -> stretch -- then I guess we can discuss indeed having it in the security-tracker bin. But in general the rule would be not ELTS dependencies in the security-tracker itself. Regards, Salvatore
Re: Upgrade problems from LTS -> LTS+1
Hi I was thinking more on placing it in the security tracker bin folder for easy access. Or do you think we should consider it as a separate tool with its own repo? Cheers // Ola On Wed, 19 May 2021 at 17:46, Raphael Hertzog wrote: > On Mon, 17 May 2021, Utkarsh Gupta wrote: > > > Where do you think I should include this tool and what should I name > it to? > > > > Hm, nice question :P > > Probably here: https://salsa.debian.org/freexian-team? > > I would say https://salsa.debian.org/lts-team/ rather... > > Cheers, > -- > ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ > ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS > > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Upgrade problems from LTS -> LTS+1
On Mon, 17 May 2021, Utkarsh Gupta wrote: > > Where do you think I should include this tool and what should I name it to? > > Hm, nice question :P > Probably here: https://salsa.debian.org/freexian-team? I would say https://salsa.debian.org/lts-team/ rather... Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Upgrade problems from LTS -> LTS+1
Hi Please note that I have not checked proposed updates (pu). It could be so that pu is already in place. // Ola On Mon, 17 May 2021 at 13:36, Holger Levsen wrote: > On Mon, May 17, 2021 at 04:54:39PM +0530, Utkarsh Gupta wrote: > > > debian-security-support: 1:9+2021.01.23 newer than 2020.06.21~deb10u1 > > Holger, can you TAL? > > Gee... I don't know what TAL means... > > That said, I'm aware of this issue and have been waiting for an issue > worth > updating debian-security-support in buster. I don't think the version skew > alone is worth an update, *maybe* as part of a point release it > is. > > > -- > cheers, > Holger > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C > ⠈⠳⣄ > > The upcoming clima apocalypse is the big elephant in every room now. > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Upgrade problems from LTS -> LTS+1
On 17/05/21 04:54 PM, Utkarsh Gupta wrote: > Hello, > > On Mon, May 17, 2021 at 3:08 PM Ola Lundqvist wrote: > > mqtt-client: 1.14-1+deb9u1 newer than 1.14-1 > > Abhijith, can you please take care of this? You need a -pu update > prepared for this. Okay, I will take care of this. Issue is no DSA in buster. So I guess this will be in next point release. --abhijith
Re: Upgrade problems from LTS -> LTS+1
Hello, On Mon, May 17, 2021 at 5:06 PM Holger Levsen wrote: > > Holger, can you TAL? > Gee... I don't know what TAL means... Heh. Take A Look (TAL) :) > That said, I'm aware of this issue and have been waiting for an issue worth > updating debian-security-support in buster. I don't think the version skew > alone is worth an update, *maybe* as part of a point release it > is. Great, as long as you're aware of this issue, it's great! \o/ - u
Re: Upgrade problems from LTS -> LTS+1
On Mon, May 17, 2021 at 04:54:39PM +0530, Utkarsh Gupta wrote: > > debian-security-support: 1:9+2021.01.23 newer than 2020.06.21~deb10u1 > Holger, can you TAL? Gee... I don't know what TAL means... That said, I'm aware of this issue and have been waiting for an issue worth updating debian-security-support in buster. I don't think the version skew alone is worth an update, *maybe* as part of a point release it is. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The upcoming clima apocalypse is the big elephant in every room now. signature.asc Description: PGP signature
Re: Upgrade problems from LTS -> LTS+1
Hello, On Mon, May 17, 2021 at 3:08 PM Ola Lundqvist wrote: > mqtt-client: 1.14-1+deb9u1 newer than 1.14-1 Abhijith, can you please take care of this? You need a -pu update prepared for this. > ruby-websocket-extensions: 0.1.2-1+deb9u1 newer than 0.1.2-1 Already has an opened -pu bug. > velocity: 1.7-5+deb9u1 newer than 1.7-5 Already has an opened -pu bug. > debian-security-support: 1:9+2021.01.23 newer than 2020.06.21~deb10u1 Holger, can you TAL? > Where do you think I should include this tool and what should I name it to? Hm, nice question :P Probably here: https://salsa.debian.org/freexian-team? Naming is your choice :) > Currently it just detects errors, it does not know whether the version error > is > from normal release or security release. This could be added if necessary. I think as long as it detects and reports the actual problem, that won't be necessary. But obviously good to know that we can have it if need be. Thanks for working on this! :) - u
Re: Upgrade problems from LTS -> LTS+1
Hi all
And this is the result:
Fist I instructed apt to download stretch and buster source packages files.
After that I run the command like this:
ola@tigereye:~$ ./checkversions.pl --old
/var/lib/apt/lists/httpredir.debian.org_debian_dists_stretch_main_source_Sources
--old-sec
/var/lib/apt/lists/httpredir.debian.org_debian-security_dists_stretch_updates_main_source_Sources
--new
/var/lib/apt/lists/httpredir.debian.org_debian_dists_buster_main_source_Sources
--new-sec
/var/lib/apt/lists/httpredir.debian.org_debian-security_dists_buster_updates_main_source_Sources
And the output is as follows:
mqtt-client: 1.14-1+deb9u1 newer than 1.14-1
ruby-websocket-extensions: 0.1.2-1+deb9u1 newer than 0.1.2-1
velocity: 1.7-5+deb9u1 newer than 1.7-5
debian-security-support: 1:9+2021.01.23 newer than 2020.06.21~deb10u1
So it looks like we have four packages to fix, that is four packages that
have a higher revision in stretch than in buster. I'm a little surprised
about the debian-security-support package here.
Where do you think I should include this tool and what should I name it to?
Currently it just detects errors, it does not know whether the version
error is from normal release or security release. This could be added if
necessary.
Best regards
// Ola
On Mon, 17 May 2021 at 10:56, Ola Lundqvist wrote:
> Hi
>
> Yes that makes sense. I can write some tool for that too. But now I'm
> focusing on finding already existing problems. The script is almost ready.
> I'm testing it right now.
>
> // Ola
>
> On Mon, 17 May 2021 at 10:49, Utkarsh Gupta wrote:
>
>> Hello,
>>
>> On Mon, May 17, 2021 at 2:05 PM Ola Lundqvist wrote:
>> > 3) Merge the normal release with the security release (takes the latest)
>>
>> Yeah, the goal is to cover all sorts of releases (normal, -pu, security)
>> and
>> get the highest version amongst them.
>>
>> > 4) Compare the two merged sets and check if the later release has any
>> > entry that is lower than the older release. Output those as "package
>> version".
>>
>> I think we shouldn't wait for when the package in the older release
>> has a greater version but check them *before*. That is, those packages
>> having the same version in ELTS & LTS or LTS & LTS+1 should be
>> flagged. This means, if they're added to {ela,dla}-needed, they should
>> either warrant a DSA upload or a -pu upload along with the DLA or ELA.
>> Hope that makes sense?
>>
>>
>>
>> - u
>>
>>
>
> --
> --- Inguza Technology AB --- MSc in Information Technology
> | o...@inguza.como...@debian.org|
> | http://inguza.com/Mobile: +46 (0)70-332 1551 |
> ---
>
>
--
--- Inguza Technology AB --- MSc in Information Technology
| o...@inguza.como...@debian.org|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
---
Re: Upgrade problems from LTS -> LTS+1
Hi
Yes that makes sense. I can write some tool for that too. But now I'm
focusing on finding already existing problems. The script is almost ready.
I'm testing it right now.
// Ola
On Mon, 17 May 2021 at 10:49, Utkarsh Gupta wrote:
> Hello,
>
> On Mon, May 17, 2021 at 2:05 PM Ola Lundqvist wrote:
> > 3) Merge the normal release with the security release (takes the latest)
>
> Yeah, the goal is to cover all sorts of releases (normal, -pu, security)
> and
> get the highest version amongst them.
>
> > 4) Compare the two merged sets and check if the later release has any
> > entry that is lower than the older release. Output those as "package
> version".
>
> I think we shouldn't wait for when the package in the older release
> has a greater version but check them *before*. That is, those packages
> having the same version in ELTS & LTS or LTS & LTS+1 should be
> flagged. This means, if they're added to {ela,dla}-needed, they should
> either warrant a DSA upload or a -pu upload along with the DLA or ELA.
> Hope that makes sense?
>
>
>
> - u
>
>
--
--- Inguza Technology AB --- MSc in Information Technology
| o...@inguza.como...@debian.org|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
---
Re: Upgrade problems from LTS -> LTS+1
On Mon, May 17, 2021 at 2:18 PM Utkarsh Gupta wrote: > I think we shouldn't wait for when the package in the older release > has a greater version but check them *before*. [...] Or well, we could check after as well. But I am much more inclined towards "avoiding" such a problem in the first place, rather than trying to fix it once it has already happened. - u
Re: Upgrade problems from LTS -> LTS+1
Hello,
On Mon, May 17, 2021 at 2:05 PM Ola Lundqvist wrote:
> 3) Merge the normal release with the security release (takes the latest)
Yeah, the goal is to cover all sorts of releases (normal, -pu, security) and
get the highest version amongst them.
> 4) Compare the two merged sets and check if the later release has any
> entry that is lower than the older release. Output those as "package version".
I think we shouldn't wait for when the package in the older release
has a greater version but check them *before*. That is, those packages
having the same version in ELTS & LTS or LTS & LTS+1 should be
flagged. This means, if they're added to {ela,dla}-needed, they should
either warrant a DSA upload or a -pu upload along with the DLA or ELA.
Hope that makes sense?
- u
Re: Upgrade problems from LTS -> LTS+1
Hi These are my thoughts on how the script would work: 1) Run the script with the following inputs: - older release apt packages file - older security release apt packages file - later release apt packages file - later security release apt package file 2) The script will then parse those files (looks for package and version) 3) Merge the normal release with the security release (takes the latest) 4) Compare the two merged sets and check if the later release has any entry that is lower than the older release. Output those as "package version". Best regards // Ola On Mon, 17 May 2021 at 10:05, Holger Levsen wrote: > On Mon, May 17, 2021 at 01:09:10PM +0530, Utkarsh Gupta wrote: > > This shouldn't just run once, it should keep checking once in a while. > > And once especially when we're nearing EOL of the LTS and ELTS releases. > > yes. > > I'd be glad to setup such a script running regularly on jenkins.debian.net > and then to notify #debian-lts on irc and/or this mailing list (or > some other address/). I'd just need this script. ;) > > > -- > cheers, > Holger > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C > ⠈⠳⣄ > > "... the premise [is] that privacy is about hiding a wrong. It's not. > Privacy is an inherent human right, and a requirement for maintaining > the human condition with dignity and respect." (Bruce Schneier) > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Upgrade problems from LTS -> LTS+1
Hi I'll write a script that do the conversion. It should not take that long. // Ola On Mon, 17 May 2021 at 09:39, Utkarsh Gupta wrote: > Hello, > > On Mon, May 17, 2021 at 1:04 PM Ola Lundqvist wrote: > > Should we try to automate the detection of such issues? It should be > fairly easy to do. > > This shouldn't just run once, it should keep checking once in a while. > And once especially when we're nearing EOL of the LTS and ELTS releases. > > > - u > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Upgrade problems from LTS -> LTS+1
On Mon, May 17, 2021 at 01:09:10PM +0530, Utkarsh Gupta wrote: > This shouldn't just run once, it should keep checking once in a while. > And once especially when we're nearing EOL of the LTS and ELTS releases. yes. I'd be glad to setup such a script running regularly on jenkins.debian.net and then to notify #debian-lts on irc and/or this mailing list (or some other address/). I'd just need this script. ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." (Bruce Schneier) signature.asc Description: PGP signature
Re: Upgrade problems from LTS -> LTS+1
Hello, On Mon, May 17, 2021 at 1:04 PM Ola Lundqvist wrote: > Should we try to automate the detection of such issues? It should be fairly > easy to do. This shouldn't just run once, it should keep checking once in a while. And once especially when we're nearing EOL of the LTS and ELTS releases. - u
Re: Upgrade problems from LTS -> LTS+1
On Mon, May 17, 2021 at 09:33:47AM +0200, Ola Lundqvist wrote: > Should we try to automate the detection of such issues? It should be fairly > easy to do. yes, please. > Package renaming complicates the checks but on the other hand if the > package is renamed the issue is not as big anymore. yes, indeed :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ signature.asc Description: PGP signature
Re: Upgrade problems from LTS -> LTS+1
Hi Should we try to automate the detection of such issues? It should be fairly easy to do. Package renaming complicates the checks but on the other hand if the package is renamed the issue is not as big anymore. // Ola On Sun, 16 May 2021 at 10:55, Holger Levsen wrote: > On Sat, May 15, 2021 at 05:53:15PM +0530, Utkarsh Gupta wrote: > > Whilst I'll fix this for stretch (already sponsored the upload for > > buster), there are more such bugs for stretch -> buster (eg: [1] (-> > > fixed already), etc. Maybe we should keep an eye on such issues and > > while we're doing DLAs, we can take care of -pu uploads, at least if > > the versions are the same for LTS and LTS+1 so we don't run into > > these? > > yes, please. > > else (if we break upgrades like this) LTS will start looking at lot less > good :( > > > -- > cheers, > Holger > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C > ⠈⠳⣄ > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: Upgrade problems from LTS -> LTS+1
On Sat, May 15, 2021 at 05:53:15PM +0530, Utkarsh Gupta wrote: > Whilst I'll fix this for stretch (already sponsored the upload for > buster), there are more such bugs for stretch -> buster (eg: [1] (-> > fixed already), etc. Maybe we should keep an eye on such issues and > while we're doing DLAs, we can take care of -pu uploads, at least if > the versions are the same for LTS and LTS+1 so we don't run into > these? yes, please. else (if we break upgrades like this) LTS will start looking at lot less good :( -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ signature.asc Description: PGP signature
Upgrade problems from LTS -> LTS+1
Hello, There's #988289 reported against htmldoc which is the unfortunate result of issuing a DLA when jessie was LTS and was marked as no-dsa for stretch *and* both had the same version. Whilst I'll fix this for stretch (already sponsored the upload for buster), there are more such bugs for stretch -> buster (eg: [1] (-> fixed already), etc. Maybe we should keep an eye on such issues and while we're doing DLAs, we can take care of -pu uploads, at least if the versions are the same for LTS and LTS+1 so we don't run into these? [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964274#15 - u
