[14:27] <cpaelzer> teward: if I might ask what do you think of https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1862305 ?
[14:27] -ubottu:#ubuntu-devel- Launchpad bug 1862305 in Xenial Backports "distro-info in xenial backports needs a newer distro-info-data and versioned dependency" [Undecided, Won't Fix]
[14:31] <paride> @pilot in
[14: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
[14:42] <cpaelzer> teward: my question is more, would you still take anything for xenial? before I prepare and it is wasted effort
[14:44] <teward> in my personal opinion, no, but i'm also not sure how the archives handle uploads to xenial-* still or if they just reject.
[14:46] <teward> we havent had this type of case show up though before
[14:46] <teward> so i'd still want to check with ddstreet and mapreri
[14:47] <teward>  
[15:00] <lvoytek> @pilot in
[15:19] <guruprasad> paride, lvoytek, I have a follow-up question from my conversation here yesterday (https://irclogs.ubuntu.com/2023/09/25/%23ubuntu-devel.html). The ipython source package is imported from Debian and used as-is in mantic. Since the same isse that I reported is in the Debian package as well, should I submit the fix to Debian first?
[15:20] <guruprasad> I am speaking about https://bugs.launchpad.net/ubuntu/+source/ipython/+bug/2037286
[15:20] -ubottu:#ubuntu-devel- Launchpad bug 2037286 in lptools (Ubuntu) "lp-shell ipython instance throws error when typing open parenthesis" [Undecided, Confirmed]
[15:20] <bdmurray> guruprasad: Not necessarily first as we are so close to the release of mantic but it should definitely be submitted to debian.
[15:21] <guruprasad> bdmurray, thanks!
[15:21] <bdmurray> So then at the start of N we can get back in sync with debian
[15:22] <guruprasad> This is my first time doing anything with Debian/Ubuntu packaging. Is https://packaging.ubuntu.com/html/fixing-a-bug.html#work-on-a-fix a place to refer for doing this?
[15:23] <guruprasad> Or the new version of the site at https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/how-to/fixing-a-bug.html
[15:24] <bdmurray> Probably the new version but I do things the old-fashioned way
[15:25] <cpaelzer> teward: I've sent a mail to backports@lists.u.c  so you can have a group discussion, thanks in advance
[15:32] <paride> guruprasad, hi, given that you are new to fixing Ubuntu packages, but not new to git development, I suggest following this: https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageFixing.md
[15:33] <paride> guruprasad, that's a workflows that leverages git-ubuntu, a tool which is able to leverage Launchpad
[15:33] <paride> [...] leverage Launchpad's view of Ubuntu packages are git repositories
[15:34] <paride> *as* git repositories. (fat fingers moment -- sorry)
[15:35] <paride> guruprasad, however that document assumes some packaging knowledge. If you're totally new to it, I suggest moving one step back and learn how to download and build an existing package
[15:41] <guruprasad> paride, thanks for the useful pointers!
[15: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....
[15:50] <mapreri> I don't even know if that helps anybody really.  /cc teward
[16:23] <cpaelzer> mapreri: it was fixed in a distro-info sru, just the backport is left behind
[16: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.
[16:28] <teward> (this is why i wanted to play catchup)
[16: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.
[16:30] <teward> but that will require anyone using the backports version to do a manual downgrade
[16:30] <teward> since apt is picky about that
[16: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
[16:37] <mapreri> cpaelzer: ah, I see, I missed this part.
[16:37] <mapreri> teward: that would not fix systems that are currently running that.
[16: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
[16:38] <mapreri> cpaelzer: I think I would be fine, in this case, to backport what is currently in bionic-updates.
[16:38] <mapreri> which seems to be a bugfix-only update on top of what is currently in xenial-backports
[16:39] <teward> that's also an option
[16:39] <mapreri> all of this is assuming cpaelzer would prepare the update, of course :3
[16:39] <teward> :P
[16: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
[16:40] <teward> (my opinion)
[16:40] <mapreri> teward: In my mind, xenial is already in that state, this is already an exception handling to me.
[16: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?
[16:41] <teward> anyone still using Xenial without pro/esm is "frozen" then if we adopt this logic
[16:41] <mapreri> teward: how do I check what's in ESM?  LP in xenial is only showing lower versions.
[16:41] <teward> granted then we need Canonical to do the upload and intervene but still
[16:41] <teward> *burps a xenial box into existence*
[16:42] <mapreri> ah, wait, I understand what you mean now.
[16:42] <teward> yeah standard uploaders don't have access to ESM/Pro, but Canonical engineers do
[16: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)
[16:42] <mapreri> and I don't see any benefits of hiding such trivial update behind a paywall…
[16: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
[16: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.
[16:43] <teward> coffee reup first.
[16:43] <teward> *obtains more coffee from the unlimited coffee source aka the Keurig*
[16:49] <teward> gotta make sure this builds first so... *does a thing in local devel boxes*
[16:50]  * arraybolt3 pours coffee into the local dev box
[16:50] <arraybolt3> *vanishes back into hiding and observing*
[16:50] <teward> arraybolt3: nah, that goes into the coffee IV bags to go into my bloodstream :p
[16:50] <Eickmeyer> 😮
[16:51] <Eickmeyer> Sorry, just shocked every time I see arraybolt3 😁
[16:51] <teward> *rebuilt a Xenial chroot for sbuild to build things*
[16: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
[16:52] <teward> YOU can tell me if it uploads or not :p
[16: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.
[16:52] <Eickmeyer> arraybolt3: It would be great having you back. 😄
[16:52] <teward> ^^ that
[16:52] <arraybolt3> :) thanks!
[16: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)
[16:57] <teward> mapreri: because i'm too lazy to alter the package :p
[16:57] <teward> i'll do that and see if i can make it work
[16:57] <teward> mapreri: though, it build-deps on the higher version
[17:07] <paride> @pilot off
[17:07] <paride> @pilot out
[17:07] <paride> :-)
[17:08] <teward> mapreri: got it to compile.  Obvious lintian explodes but.
[17:08] <Eickmeyer> Ever since I got my pilot license 20 years ago, I haven't been able to pilot off paride. 😁
[17:08] <arraybolt3> @pilot shutdown now?
[17:09] <teward> fun discovery: "Unsupported release: xenial" according to dput-ng
[17:09] <Eickmeyer> 😂
[17:09] <teward> that uses distro-info though so
[17:12] <cjwatson> hopefully it has some kind of force option.  LP should accept it happily enough.
[17:13] <tumbleweed> yeah, you can delete the supported-distribution hook from /etc/dput.d/metas/ubuntu.json
[17:13] <teward> tumbleweed: i'll clone that to ubuntu-old :P
[17:13] <teward> thanks
[17:14] <paride> arraybolt3,
[17:14] <paride> arraybolt3,  nowdays pilotctl poweroff :P
[17:15] <Eickmeyer> 😂
[17:18] <teward> tumbleweed: yep separate profile and ubuntu-old target seemed to work and bypass the supported-distro hook
[17:18] <teward> uploaded but lets see if it rejects
[17: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
[17:20] <teward> mapreri: i'll let you ACK it here or just go in and approve yourself from the queue
[17:20] <teward> (if you ACK here and OK the upload I'll just handwave it in)
[17:23] <arraybolt3> paride: You could turn that into a running joke - pilotctl kexec to replace the current pilot, pilotctl enable to add a new authorized pilot, pilotctl mask to ban someone from the channel...
[17:23] <Eickmeyer> arraybolt3: That'd be up to Unit193. :)
[17:40] <paride> Unit193, I'll take the occasion to say hi!
[19:05] <lvoytek> @pilot out
[21: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
[21:06] <teward> (xenial-backports)
[22:25] <Unit193> paride: Hello!