Bug #1862305 “[BPO] distro-info/0.18ubuntu0.18.04.1 from bionic” : Bugs : distro-info package : Ubuntu

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-02-07:

#1

I subscribed Laney as I see his name on the backport upload.
I beg your pardon if you are not really involved in this.

Stefano Rivera (stefanor) on 2021-09-30

Changed in distro-info (Ubuntu):
status:	New → Invalid

Revision history for this message

Dan Streetman (ddstreet) wrote on 2021-11-16:

#2

Hello,

the backports process has recently been updated, please see the new documentation:
https://wiki.ubuntu.com/UbuntuBackports

I'm closing this bug, but please feel free to open a new bug (or reopen this bug) using the new process, if appropriate.

Changed in xenial-backports:
status:	New → Won't Fix

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-09-26:

#3

Sadly we see more fallout due to that still being broken.
And the efforts around the new backport process dried out.

TBH Removing distro-info from backports seems right (as it is dysfunctional) but not helpful to anyone already having it installed.

The next option that comes to mind is update distro-info in xenial-backports to be compatible to the new distro-info-data | 0.28ubuntu0.18 | xenial-updates
For example we could replace it with the Ubuntu version from 0.18ubuntu0.18.04.1 bionic.

But is the xenial-backports pocket is closed, as it is over the initial 5 years?
@teward WDYT - Could we even still accept that to xenial-backports or would you prefer anything else?

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-09-27:

#4

Download full text (6.7 KiB)

Making the great discussion on #ubuntu-devel discoverable later by moving it here as well:

[16:27] <cpaelzer> teward: if I might ask what do you think of https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1862305 ?
[16:41] <teward> cpaelzer: i'll have to play catchup but email <email address hidden> with the request for our review / input. backport team meeting is tomorrow so all three of us in backporters can chime in
[16:42] <cpaelzer> teward: my question is more, would you still take anything for xenial? before I prepare and it is wasted effort
[17:50] <mapreri> cpaelzer: well, wasn't that the fault of whoever thought that adding columns to the csv in a stable update was a good idea? That had to be fixed in a distro-info SRU long ago, not in bpo now....
[17:50] <mapreri> I don't even know if that helps anybody really. /cc teward
[18:23] <cpaelzer> mapreri: it was fixed in a distro-info sru, just the backport is left behind
[18:28] <teward> cpaelzer: then i would purge the backport. if it's already been SRU-fixed then the SRU should be 'superior' to the backport.
[18:28] <teward> (this is why i wanted to play catchup)
[18:29] <teward> mapreri: i don't think adding a newer version to backports would solve tis if the SRU has already fixed the problem. In which case I should just poke AAs for removal.
[18:30] <teward> but that will require anyone using the backports version to do a manual downgrade
[18:30] <teward> since apt is picky about that
[18:33] <teward> cpaelzer: ^^ the only way to fix it if we remove backports version which is having this problem is that manual downgrade to what's in xenial-updates. if there's no objection to that then we can poke the AAs for removal of the backport
[18:37] <mapreri> cpaelzer: ah, I see, I missed this part.
[18:37] <mapreri> teward: that would not fix systems that are currently running that.
[18:38] <teward> mapreri: correct. but does it make sense to continue to do this in backports if SRU is already ahead? Because Xenial is beyond standard support cycle this sounds like something that *should* be solved in ESM/pro
[18:38] <mapreri> cpaelzer: I think I would be fine, in this case, to backport what is currently in bionic-updates.
[18:38] <mapreri> which seems to be a bugfix-only update on top of what is currently in xenial-backports
[18:39] <teward> that's also an option
[18:39] <mapreri> all of this is assuming cpaelzer would prepare the update, of course :3
[18:39] <teward> :P
[18:39] <teward> and then we should probably *freeze* Xenial officially for that in -updates, etc. and any more Xenial updates need to go via pro/esm
[18:40] <teward> (my opinion)
[18:40] <mapreri> teward: In my mind, xenial is already in that state, this is already an exception handling to me.
[18:40] <teward> mapreri: then is there a reason we don't do this 'backport' of the higher version in Pro/ESM which would override -backports entirely?
[18:41] <teward> anyone still using Xenial without pro/esm is "frozen" then if we adopt this logic
[18:41] <mapreri> teward: how do I check what's in ESM? LP in xenial is only showing lower versions.
[18:41] <teward> granted then we need Canonical to do the upload a...

Making the great discussion on #ubuntu-devel discoverable later by moving it here as well:

[16:27] <cpaelzer> teward: if I might ask what do you think of https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1862305 ?
[16:41] <teward> cpaelzer: i'll have to play catchup but email ubuntu-backports@lists.u.c with the request for our review / input.  backport team meeting is tomorrow so all three of us in backporters can chime in
[16:42] <cpaelzer> teward: my question is more, would you still take anything for xenial? before I prepare and it is wasted effort
[17:50] <mapreri> cpaelzer: well, wasn't that the fault of whoever thought that adding columns to the csv in a stable update was a good idea?  That had to be fixed in a distro-info SRU long ago, not in bpo now....
[17:50] <mapreri> I don't even know if that helps anybody really.  /cc teward
[18:23] <cpaelzer> mapreri: it was fixed in a distro-info sru, just the backport is left behind
[18:28] <teward> cpaelzer: then i would purge the backport.  if it's already been SRU-fixed then the SRU should be 'superior' to the backport.
[18:28] <teward> (this is why i wanted to play catchup)
[18:29] <teward> mapreri: i don't think adding a newer version to backports would solve tis if the SRU has already fixed the problem.  In which case I should just poke AAs for removal.
[18:30] <teward> but that will require anyone using the backports version to do a manual downgrade
[18:30] <teward> since apt is picky about that
[18:33] <teward> cpaelzer: ^^ the only way to fix it if we remove backports version which is having this problem is that manual downgrade to what's in xenial-updates.  if there's no objection to that then we can poke the AAs for removal of the backport
[18:37] <mapreri> cpaelzer: ah, I see, I missed this part.
[18:37] <mapreri> teward: that would not fix systems that are currently running that.
[18:38] <teward> mapreri: correct.  but does it make sense to continue to do this in backports if SRU is already ahead?  Because Xenial is beyond standard support cycle this sounds like something that *should* be solved in ESM/pro
[18:38] <mapreri> cpaelzer: I think I would be fine, in this case, to backport what is currently in bionic-updates.
[18:38] <mapreri> which seems to be a bugfix-only update on top of what is currently in xenial-backports
[18:39] <teward> that's also an option
[18:39] <mapreri> all of this is assuming cpaelzer would prepare the update, of course :3
[18:39] <teward> :P
[18:39] <teward> and then we should probably *freeze* Xenial officially for that in -updates, etc. and any more Xenial updates need to go via pro/esm
[18:40] <teward> (my opinion)
[18:40] <mapreri> teward: In my mind, xenial is already in that state, this is already an exception handling to me.
[18:40] <teward> mapreri: then is there a reason we don't do this 'backport' of the higher version in Pro/ESM which would override -backports entirely?
[18:41] <teward> anyone still using Xenial without pro/esm is "frozen" then if we adopt this logic
[18:41] <mapreri> teward: how do I check what's in ESM?  LP in xenial is only showing lower versions.
[18:41] <teward> granted then we need Canonical to do the upload and intervene but still
[18:41] <teward> *burps a xenial box into existence*
[18:42] <mapreri> ah, wait, I understand what you mean now.
[18:42] <teward> yeah standard uploaders don't have access to ESM/Pro, but Canonical engineers do
[18:42] <mapreri> but I don't see why.  it seems quite low effort to fix this in the regular xenial-backports to me (assuming lp allows for uploads still)
[18:42] <mapreri> and I don't see any benefits of hiding such trivial update behind a paywall…
[18:42] <teward> mapreri: does LP still allow such uploads?  I mean, I could prepare it (I need to exercise my upload privs more anyways) and test but
[18:43] <mapreri> just upload and see :P  but fwiw the xenial queue does have stuff in there from august this year, so it still might work.
[18:43] <teward> coffee reup first.
[18:43] <teward> *obtains more coffee from the unlimited coffee source aka the Keurig*
[18:49] <teward> gotta make sure this builds first so... *does a thing in local devel boxes*
[18:50] <teward> arraybolt3: nah, that goes into the coffee IV bags to go into my bloodstream :p
[18:51] <teward> *rebuilt a Xenial chroot for sbuild to build things*
[18:51] <teward> cpaelzer: i'm nominating you to handle this, we also need to backport distro-info-data as well for this to work and alter the debhelper versioning in all the backported packages
[18:52] <teward> YOU can tell me if it uploads or not :p
[18:52] <arraybolt3> Eickmeyer: I still peek at what's going on :P Might come back around the beginning of the N cycle depending on how things go.
[18:56] <mapreri> teward: why the -data?  it should be fine regardless.   (and yes, also according to 0.18~ubuntu16.04.1 they had to reduce dh)
[18:57] <teward> mapreri: because i'm too lazy to alter the package :p
[18:57] <teward> i'll do that and see if i can make it work
[18:57] <teward> mapreri: though, it build-deps on the higher version
[19:08] <teward> mapreri: got it to compile.  Obvious lintian explodes but.
[19:09] <teward> fun discovery: "Unsupported release: xenial" according to dput-ng
[19:09] <teward> that uses distro-info though so
[19:18] <teward> uploaded but lets see if it rejects
[19:20] <teward> mapreri: cpaelzer: looks like LP accepted xenial-backports and waits for approval.  I test-built against non-backports environment to make sure the file works as is so we can probably ACK it from the queue and let it build and see what happens and fix any unexpected FTBFS or such that comes up
[19:20] <teward> mapreri: i'll let you ACK it here or just go in and approve yourself from the queue
[19:20] <teward> (if you ACK here and OK the upload I'll just handwave it in)
[23:06] <teward> ddstreet: mapreri: distro-info backport in the queue for one of you to accept, unless you just want me to handwave it through
[23:06] <teward> (xenial-backports)
[06:40] <cpaelzer> teward: mapreri: thanks for all the content let me read the backlog ...
[06:41] <cpaelzer> teward: mapreri: btw line wrapping made misread and send the mail to backports@ instead of ubuntu-backports@, but given the amount of answers I see that mail might not have been required
[06:49] <cpaelzer> teward: mapreri: read the backlog, thanks already - I'll have a look at https://launchpadlibrarian.net/689166277/distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_source.changes as well to give you this ack
[06:51] <cpaelzer> teward: mapreri: you already ruled it out, but to fill in the gaps why serving this via pro would make even less sense ... broken distro-info from backports affects the pro client, which depends on it, in negative ways. I don't know how bad, but it would make consuming the fix via that even less practical

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2023-09-27:

#5

xenial-updates:
ii distro-info 0.14ubuntu0.2
ii distro-info-data 0.28ubuntu0.18

root@x-bpotest:~# distro-info --supported-esm
xenial
bionic
focal
root@x-bpotest:~# distro-info --lts
focal

Going to the bad version in backports

$ apt install distro-info/xenial-backports

As expected it doesn't know about --supported-esm

# distro-info --supported-esm
ubuntu-distro-info: unrecognized option `--supported-esm'

But even --lts fails due to the data format change.

Update to the build from xenial-unapproved
=> https://launchpadlibrarian.net/689166277/distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_source.changes
Build in sbuild against xenial-backports fine, just the expected non fatal Lintian warnings.

# apt install ./distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'distro-info' instead of './distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb'
The following packages were automatically installed and are no longer required:
  gettext-base libasprintf0v5 libfreetype6 libpng12-0
Use 'apt autoremove' to remove them.
Suggested packages:
  shunit2
The following packages will be upgraded:
  distro-info
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/20.3 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /root/distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb distro-info amd64 0.18ubuntu0.18.04.1~bpo18.04.1 [20.3 kB]
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 13054 files and directories currently installed.)
Preparing to unpack .../distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb ...
Unpacking distro-info (0.18ubuntu0.18.04.1~bpo18.04.1) over (0.18~ubuntu16.04.1) ...
Setting up distro-info (0.18ubuntu0.18.04.1~bpo18.04.1) ...

With that things work again.

root@x-bpotest:~# distro-info --lts
focal
root@x-bpotest:~# distro-info --supported-esm
xenial
bionic
focal

Review of the changes:
1. The debdiff to 0.18ubuntu0.18.04.1 in current bionic-updates
  $ debdiff distro-info_0.18ubuntu0.18.04.1.dsc distro-info_0.18ubuntu0.18.04.1~bpo18.04.1.dsc
  - set distro-info-data that has been the backport of esm data in xenial-updates
  - use older debian/compat
  - changelog referring to this bug
  => That should be save and just right
2. The debdiff to the 0.18~ubuntu16.04.1 in current xenial-backports
  $ debdiff distro-info_0.18~ubuntu16.04.1.dsc distro-info_0.18ubuntu0.18.04.1~bpo18.04.1.dsc
  - same as above
  - support for the milestone eol-esm and add filters for supported-esm (LP: #1808038)
  => which is exactly what we want

So yes, this LGTM, please accept it to xenial-backports

xenial-updates:
ii  distro-info                      0.14ubuntu0.2
ii  distro-info-data                 0.28ubuntu0.18

root@x-bpotest:~# distro-info --supported-esm
xenial
bionic
focal
root@x-bpotest:~# distro-info --lts
focal

Going to the bad version in backports

$ apt install distro-info/xenial-backports

As expected it doesn't know about --supported-esm

# distro-info --supported-esm
ubuntu-distro-info: unrecognized option `--supported-esm'

But even --lts fails due to the data format change.

Update to the build from xenial-unapproved
=> https://launchpadlibrarian.net/689166277/distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_source.changes
Build in sbuild against xenial-backports fine, just the expected non fatal Lintian warnings.

# apt install ./distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'distro-info' instead of './distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb'
The following packages were automatically installed and are no longer required:
  gettext-base libasprintf0v5 libfreetype6 libpng12-0
Use 'apt autoremove' to remove them.
Suggested packages:
  shunit2
The following packages will be upgraded:
  distro-info
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/20.3 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /root/distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb distro-info amd64 0.18ubuntu0.18.04.1~bpo18.04.1 [20.3 kB]
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 13054 files and directories currently installed.)
Preparing to unpack .../distro-info_0.18ubuntu0.18.04.1~bpo18.04.1_amd64.deb ...
Unpacking distro-info (0.18ubuntu0.18.04.1~bpo18.04.1) over (0.18~ubuntu16.04.1) ...
Setting up distro-info (0.18ubuntu0.18.04.1~bpo18.04.1) ...

With that things work again.

root@x-bpotest:~# distro-info --lts
focal
root@x-bpotest:~# distro-info --supported-esm
xenial
bionic
focal

Review of the changes:
1. The debdiff to 0.18ubuntu0.18.04.1 in current bionic-updates
  $ debdiff distro-info_0.18ubuntu0.18.04.1.dsc distro-info_0.18ubuntu0.18.04.1~bpo18.04.1.dsc
  - set distro-info-data that has been the backport of esm data in xenial-updates
  - use older debian/compat
  - changelog referring to this bug
  => That should be save and just right
2. The debdiff to the 0.18~ubuntu16.04.1 in current xenial-backports 
  $ debdiff distro-info_0.18~ubuntu16.04.1.dsc distro-info_0.18ubuntu0.18.04.1~bpo18.04.1.dsc
  - same as above
  - support for the milestone eol-esm and add filters for supported-esm (LP: #1808038)
  => which is exactly what we want

So yes, this LGTM, please accept it to xenial-backports

Christian Ehrhardt  (paelzer) on 2023-09-27

description:	updated
summary:	- distro-info in xenial backports needs a newer distro-info-data and - versioned dependency + [BPO] distro-info/0.18ubuntu0.18.04.1 from bionic
description:	updated

Affects		Status	Importance	Assigned to	Milestone
	Xenial Backports	Won't Fix	Undecided	Unassigned
	distro-info (Ubuntu)	Invalid	Undecided	Unassigned

Ubuntu
distro-info package

[BPO] distro-info/0.18ubuntu0.18.04.1 from bionic

Bug Description

Other bug subscribers

Remote bug watches

Ubuntudistro-info package

[BPO] distro-info/0.18ubuntu0.18.04.1 from bionic

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
distro-info package