[01:08] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: tsimonq2 [01:45] In case anyone hasn't noticed, I added an average age to the sponsorship queue. [01:45] What I'm hoping we can accomplish there is to get some of the older ones taken care of. [01:46] Obviously less is better, but it will fluctuate. [01:46] When I started my "shift" it read "24 days, 3:48:34.054719" - we'll see how that goes. [01:48] LOL, so if anyone wants to check out one of the relics of the GCC 5 transition: https://bugs.launchpad.net/ubuntu/+source/sidplay-libs/+bug/2093826 [01:48] -ubottu:#ubuntu-devel- Launchpad bug 2093826 in sidplay-libs (Ubuntu) "Sync sidplay-libs 2.1.1-16 (universe) from Debian unstable (main)" [Undecided, New] [02:08] enr0n: Hey! Just wanted to follow up on https://bugs.launchpad.net/ubuntu/+source/needrestart/+bug/2085070/comments/5 :) [02:08] -ubottu:#ubuntu-devel- Launchpad bug 2085070 in needrestart (Ubuntu Oracular) "[SRU] glusterd should not be automatically restarted" [Undecided, Incomplete] [02:10] sarnold: Hey! Do you happen to recall what the outcome was here? https://code.launchpad.net/~r41k0u/ubuntu/+source/nbd/+git/nbd/+merge/478236 [02:10] It *seems* like the MP should be marked "Needs Fixing" per your comment, I just wanted to double check. [02:14] bdrung: Hey! juliank mentioned previously that you might be one to review https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2093164 - could you please take a look when you have the chance? [02:14] -ubottu:#ubuntu-devel- Launchpad bug 2093164 in initramfs-tools (Ubuntu Plucky) "initramfs-tools generates deprecated netplan config gateway4 and gateway6" [Undecided, In Progress] [02:18] Diff against target: 8225 lines (+7256/-15) https://code.launchpad.net/~pushkarnk/ubuntu/+source/user-setup/+git/user-setup/+merge/479273 o_o [02:18] * tsimonq2 blinks at mwhudson who TIL and ducks [02:22] hmm [02:22] - debian/po: keep translations as part of the package [02:22] i assume that's responsible for 90% of the line count [02:22] On a quick skim, yeah. [02:26] Skia, paride: Do you happen to have ideas about how MoM is *actually* deployed? This might be interesting: https://code.launchpad.net/~toabctl/merge-o-matic/py3/+merge/479252 [02:26] Last I heard (long enough ago to question it), it was on some ancient release like 12.04 or 14.04. [02:53] I'm concerned about rejecting https://code.launchpad.net/~mschiu77/ubuntu/+source/alsa-ucm-conf/+git/alsa-ucm-conf/+merge/476661 due to HWE affiliations. It might be good for someone to give them a poke about it. [02:53] (I didn't give a hard reject, the branch just needs to be rebased. That being said, it's pedantic *enough* where I'd like someone to poke at it.) [03:01] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: N/A [03:02] The sponsorship queue is in really good shape! [03:02] I'll have some exact numbers when it refreshes in a few minutes, but all of the remaining items are either pending feedback or kernel-related (too scary for me.) [03:03] Either way, we should be down to less than 10. That being said, I'd say I did more rejects than acceptions this time. I don't believe I was overly pedantic, but if anyone notices something off, feel free to shoot me a ping. [03:06] The final number is 12 \o/ and I should note https://launchpad.net/bugs/2085524 as an exception to what I said earlier about the remaining items. [03:06] -ubottu:#ubuntu-devel- Launchpad bug 2085524 in krank (Ubuntu Oracular) "not starting after upgrading to 24.04" [Undecided, Confirmed] [03:06] > Average request age: 26 days, 5:27:02.651627 [03:06] Meh, I expected it to go up. :) [03:07] Anyway, o/ [09:22] Hello, can anyone from the SRU team have a look at LP2045923 and LP2059734? The verification has been done for a while now and they are pending release into -update. [09:58] tsimonq2: Thanks for the announcement! :-) [09:59] tsimonq2: regarding MoM, I have access to it, but we need to come up with a plan on how to roll out a new Python3 branch [10:00] it's running on bionic right now, so not as old as 14.04, but still not fresh [10:53] tsimonq2, yes, i'll review it. i am currently in the process of merging initramfs-tools from Debian. [11:23] seb128: when you have a sec, could you please sync polkit 126-1 from unstable to plucky? the one patch you have is included upstream, so a fork is no longer necessary - TIA [12:14] Skia, for MoM, can you share what python version and OS version this is currently running on? and how long a full cron.daily run roughly takes currently? [12:16] bluca, thanks for the ping, synced [12:26] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: seb128 [12:41] thank you [12:54] toabctl: yes: bionic and Python 2.7. As for the time it takes, it's really hard to tell, in part because it's very variable, but also because the system doesn't even record its logs :/ [12:55] toabctl: It's usually less than half an hour for sure [12:55] toabctl: but when it's not been running for a while, because it needed kicking, then the first one or two runs are more than half an hour :-) [12:56] toabctl: hope this helps, tell me if you want me to dig more [12:57] I'm asking because https://code.launchpad.net/~toabctl/merge-o-matic/py3/+merge/479252 takes multiple hours for running ./cron.daily (on a 10 years old laptop, so...). [12:58] multiple hours even for a 2nd run.so not starting with nothing. I need to investigate what actually takes that much time. [13:02] toabctl: I think much of the performance can actually come from the network. MoM is running inside the infra, so has a direct access to the archive [13:23] seb128: given you are pilot, would you be able to please help with sponsoring a backport of a sphinx extensions to noble? #2095011 - TIA! [13:23] https://bugs.launchpad.net/ubuntu/+source/sphinxcontrib-globalsubs/+bug/2095011 [13:23] -ubottu:#ubuntu-devel- Launchpad bug 2095011 in sphinxcontrib-globalsubs (Ubuntu Noble) "[BPO] sphinxcontrib-globalsubs/0.1.2-2 from plucky" [Undecided, Confirmed] [13:34] bluca, let me check [13:35] oh, when you said backport you meant the backport pocket, let me try to remember how that is handled [13:36] seb128: a recent-ish one I had asked for help by a sponsor has a command listed in the ticket that should do the trick I think: https://bugs.launchpad.net/ubuntu/+source/package-notes/+bug/2073502/comments/1 [13:36] -ubottu:#ubuntu-devel- Launchpad bug 2073502 in package-notes (Ubuntu Noble) "[BPO] package-notes/15 from oracular" [Undecided, Fix Released] [13:37] thx [14:00] seb128, bluca: https://wiki.ubuntu.com/UbuntuBackports [14:00] fwiw [14:32] Eickmeyer, thx [16:01] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: athos, seb128 [16:15] @pilot out === seb129 is now known as seb128 [16:17] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: athos [16:21] bluca, so I just checked that backport request and I think that should be a normal SRU, see https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#other-safe-cases `entirely new packages are usually fine` [16:27] thanks, but that's a lot more involved, no? a backport is simpler? [16:32] bluca, I don't think it should be more involved, it's basically pushing to a different queue and having a different reviewer. SRU team is strict on regression potential but there isn't one for a new package so it should be easy enough [16:36] liushuyu: You may be interested in some of the MoM-related scrollback (overnight). :) [16:37] tsimonq2: That seems like a gap we need to fill, as far as I know, MoM code has been migrated to a Git repository on LP [16:37] As a general note, I'm seeing lots of recent polishing to tooling, generally (MoM, sponsoring queue, ISO build tooling). It's very much appreciated and noticed. [16:38] https://code.launchpad.net/~ubuntu-core-dev/merge-o-matic/+git/main/+ref/main [16:38] Skia, toabctl: Hey, see liushuyu's note about Git vs Bazaar in this case ^ [16:39] Also I actually made the Python 3 migration MP about half a year ago https://code.launchpad.net/~liushuyu-011/merge-o-matic/+git/main/+merge/475917 [16:39] seb128, bluca: just to note that 1) a new package is more straightforward to SRU wrt. regression risk, assuming its presence won't cause anything to start pulling it in (need to check carefully with debhelper, especially since debhelper is regularly backported to -backports), *however* the second time won't be; 2) since debhelper is routinely backported via -backports, and this is a dh-thing, maybe [16:39] -backports is actually preferable? [16:40] liushuyu: If you happen to have the time, could you possibly diff the two to see if the two could be merged, or if you spot anything? No rush; if you don't get to it I'll take a look later. [16:41] rbasak, ah, good point, if it needs to keep up with updates indeed backport is better [16:41] tsimonq2: I already checked, the other MP is mostly a subset of mine (but independently done by another person, which means there seems to be only one solution to the problem huh) [16:42] liushuyu: I'm sure we can get this reconciled :) thanks both for your MP and for noticing the latest MP! [16:44] tsimonq2: Thanks! I think the issue previously I heard from someone else was, the person who knows how to deploy MoM is no longer here [16:45] liushuyu: Unfortunately I expect to hear that a bit in the coming days/weeks/(I hope not months) due to Canonical departures. :( [16:45] liushuyu: that's true, but also it shouldn't be complicated to deploy. From my pov, it's mostly about time [16:45] * tsimonq2 remains optimistic [16:45] I have that in a corner of my head, to work on redeploying your branch, and I should get to it at some point [16:46] I know the current instance is probably a very old LTS, but my branch has a very wide Python compatibility range: 3.8 to 3.13 [16:47] So any Ubuntu version from 20.04 to 25.04 is fine [16:47] it's running bionic :'D [16:48] When I'll redeploy, I'll choose Noble, for quite obvious reasons [16:48] Skia: Yes, the previously plan was to re-deploy Focal for some reasons I don't remember [16:48] liushuyu: toabctl: if you know exactly what's needed to run it locally, I'd be glad if you could write something about this in the README [16:49] Skia: In my MP, I have already documented the requirements in README [16:49] liushuyu: no, I'm just going to spawn a new fresh machine and redeploy from scratch, especially since it's not really storing any data, no migration is really needed [16:50] Skia: It is storing some persistent data. There are multiple package lists that I could not find anywhere [16:50] liushuyu: yes, I've found the requirements, but that doesn't tell me at all how the software works. Basically explain what you need to run, and what will be produced, and what needs to be served over HTTP, that kind of stuff [16:50] (Comments on individual items would be nice to keep.) [16:50] tsimonq2: true, I forgot about that [16:50] I can only assume they are stored somewhere on the system [16:51] but I don't expect that to be in a fully grown up RDMS, more likely a json file or something [16:51] That's exactly the kind of thing that you can already help document, liushuyu, if you have time :-) [16:51] Skia: That file should be a CSV-like thing [16:52] SQLite like some p-m stuff? [16:52] okay, I'm eod now, but will read the logs if you keep discussing the matter [16:52] o/ thanks Skia :) [16:54] Skia: I actually have a Dockerfile I used locally to test the changes: https://pastebin.ubuntu.com/p/xH5Z47zwzp/ [17:01] Skia: On the topic of Git versus Bazaar, I'd love to also talk about Ben and how that's deployed. [17:01] I did upload some changes to Ubuntu (not sure if LocutusOfBorg reverted but meh) that updates the logo and does a refresh. Would be nice to see that in the infra. :) [19:23] I think I may have left some kind of README in the prodstack tenant for MoM explaining roughly how to deal with it [19:23] Deployment of new versions is basically just bzr pull somewhere; switching to a different OS release would obviously be more work though IIRC I tried to make that vaguely possible [19:24] (of course, maybe this has been revised further since I left) [19:47] cjwatson: Yes, we switched MoM to Git a while ago [19:47] Good plan - I meant to but never got round to it [19:48] I think the question would be are the package lists inside that prodstack VM also available elsewhere (i.e. are they version tracked?) [20:34] tsimonq2: unfortunaely it appears this has been completely forgotten, there's been no further comments on https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/2078255 [20:34] -ubottu:#ubuntu-devel- Launchpad bug 2078255 in nbd (Ubuntu) "autopkgtest error: several issues, permission denied" [High, Triaged] [20:37] sarnold: Thanks for the info! [21:41] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Oracular | Patch Pilots: N/A [22:27] Eickmeyer: if you would like to review, this is the quirk I had in mind for ubuntustudio upgrades: https://code.launchpad.net/~enr0n/ubuntu-release-upgrader/+git/ubuntu-release-upgrader/+merge/479520 [23:23] liushuyu: I wouldn't expect package lists to be version-tracked in the sense of something like git. My intent was to get them all into PostgreSQL eventually since that feels like a much better fit, but I never got there [23:24] cjwatson: I see. So when you were planning to use PostgreSQL, how do you plan to add/remove entries from the database? [23:24] liushuyu: and also, nowadays there's really no reason why MoM should need to keep its own copies of a metric tonne of actual package data - it could just fetch them dynamically from LP. But there was a whole _bunch_ of stuff needed to make that switch, because it's using presence/absence of that kind of thing to track what diffs etc. it needs to produce [23:25] liushuyu: the sorts of processes that today are driven by cron.daily (produce-merges.py etc.) would mutate the database instead, and there'd be a frontend that serves stuff from the DB rather than serving static files on disk [23:26] cjwatson: keep its own copies of a metric tonne of actual package data > I agree. I guess the "next generation" of MoM should be git-ubuntu centered [23:26] liushuyu: probably actually most files would be stored in OpenStack object storage, but you'd need a DB to keep track of all the pointers, effectively [23:26] (files as in diffs and so on) [23:27] Somewhere I had like a 25-point plan for all this which was mostly unexecuted. I wonder if I kept a copy of it anywhere [23:27] I appreciate that in an ideal world I'd have checked it in somewhere, sorry ... [23:28] cjwatson: 25-point plan > sounds like this was very well planned before [23:28] aha! [23:28] I exported it from Trello to a .org file, apparently [23:28] https://paste.ubuntu.com/p/vy7963dgWy/ [23:29] There may be a bit of "draw the rest of the owl" in there ... but maybe that's helpful? [23:29] cjwatson: ideal world I'd have checked it in somewhere, sorry ... > I think that's okay, we do have a lot to modernize [23:30] That might at least give you a sense of roughly where I thought I was with it [23:30] cjwatson: There may be a bit of "draw the rest of the owl" in there ... but maybe that's helpful? > That's already very helpful. Thanks! Some tasks on that list were already done [23:30] And yes, there's a clear overlap with git-ubuntu, but I'm not sure exactly how much [23:31] And from the looks of it, if I were to continue the service, I would also think of doing most of the stuff on that list, but maybe minus the object storage part [23:32] Up to you obviously - "Clear out most of pool" would already make the thing a lot easier to maintain [23:32] And doing the frontend etc. split would potentially allow it to have a much cleaner deployment story [23:32] ... or you know, just start clean and re-generate everything [23:33] IIRC I put a basic Apache unit in as a frontend to make it easier to redeploy the backend, at least [23:33] I already did a test, start anew takes about a week at most [23:33] Can it actually all be regenerated? [23:33] cjwatson: Yes if you have the package lists [23:34] Nearly all of the old data were unneeded [23:34] I guess nobody really cares about the pre-dapper stuff any more where LP doesn't have the files [23:34] (LP has snapshots of warty, hoary, breezy as released, but not their development cycles) [23:34] I was also a bit worried that snapshot.debian.org is incomplete [23:35] Well we can always backup the entire thing and move to the a cold storage I guess [23:35] But I guess LP has a lot of that too [23:35] Regenerating the whole thing and comparing as a test seems like a good exercise, if you've already done that [23:36] Anyway, not my circus not my monkeys any more and obviously it's up to current people what you do - but I'm available as a possibly flaky memory bank if you need me :) [23:36] cjwatson: I did not do the comparing part, since I don't have the access to those package lists, I just fill the lists with some random packages [23:37] Oh, you don't actually have permission to ssh into the backend? [23:37] cjwatson: not my circus not my monkeys any more > That I understand [23:37] cjwatson: you don't actually have permission to ssh into the backend? > No, we are in the process of moving that to a proper host [23:38] ...maybe, that's what I heard [23:38] It was on prodstack last I checked, shouldn't be too hard to get access to the tenant [23:38] It's possible somebody is confused about where it lives, but when I left it it was in PS5 [23:38] prod-merges-ubuntu-com IIRC [23:38] cjwatson: but when I left it it was in PS5 > I see. [23:39] Skia: Do you have access to that VM? I guess you will want to take a backup first [23:40] Like the deployment is a bit ropey and not really up to standards because the service needed to be improved roughly according to the plan above before that could be improved ... but it was definitely in a place where it ought to be quite easy for IS to grant access to Foundations folks [23:40] cjwatson: Anyways, thanks a lot for the information! [23:41] * cjwatson finds old firewall configs, it was prod-merges-ubuntu-com@foundations-bastion-ps5.internal [23:41] And I think it probably even had working juju status and stuff [23:41] (wow, I haven't typed that in a while) [23:42] I see [23:43] anyway, I'm off to bed, HTH [23:43] cjwatson: Good night [23:55] juliank: Hey! Whenever you happen to have the chance, I'd appreciate your feedback on this PR (in the context of recent sbuild changes and otherwise): https://github.com/canonical/ubuntu-packaging-guide/pull/85 - TIA if you happen to get to it :) [23:55] -ubottu:#ubuntu-devel- Pull 85 in canonical/ubuntu-packaging-guide "Initial documentation for building packages" [Open]