[Bug 1862305] Re: distro-info in xenial backports needs a newer distro-info-data and versioned dependency

Wed Sep 27 05:29:42 UTC 2023

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 at 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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to distro-info in Ubuntu.
https://bugs.launchpad.net/bugs/1862305

Title:
  distro-info in xenial backports needs a newer distro-info-data and
  versioned dependency

Status in Xenial Backports:
  Won't Fix
Status in distro-info package in Ubuntu:
  Invalid

Bug description:
  Hi,
  askubuntu [1] made me aware of this issue.

  What I see is:
  root at x:~# apt-cache policy distro-info distro-info-data
  distro-info:
    Installed: (none)
    Candidate: 0.14ubuntu0.1
    Version table:
       0.18~ubuntu16.04.1 100
          100 http://archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages
       0.14ubuntu0.1 500
          500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
       0.14build1 500
          500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  distro-info-data:
    Installed: 0.28ubuntu0.13
    Candidate: 0.28ubuntu0.13
    Version table:
   *** 0.28ubuntu0.13 500
          500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
          500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
          100 /var/lib/dpkg/status
       0.28 500
          500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  The distro-info in backports is this atm:
  https://launchpad.net/ubuntu/+source/distro-info/0.18~ubuntu16.04.1

  The problem is that this is non-functional with the `distro-info-data`
  in Xenial.

  $ apt install distro-info=0.18~ubuntu16.04.1
  $ distro-info --lts
  ubuntu-distro-info: Header `version,codename,series,created,release,eol,eol-server,eol-esm' in file `/usr/share/distro-info/ubuntu.csv' does not match excatly `version,codename,series,created,release,eol,eol-server'.

  For distro-info=0.18~ubuntu16.04.1 to work there should:
  - also be a distro-info-data in backports
  - the distro-info=0.18~ubuntu16.04.1 probably needs a versioned dependency on the newer distro-info

  [1]: https://askubuntu.com/questions/1208133/virtual-machine-with-
  uvitools-problem

To manage notifications about this bug go to:
https://bugs.launchpad.net/xenial-backports/+bug/1862305/+subscriptions