[02:00] <mwhudson> there is a bunch of ubiquity code that talks about language-support-$LL packages
[02:01] <mwhudson> when did they stop being a thing?
[02:01] <mwhudson> huh i guess https://old-releases.ubuntu.com/ubuntu/pool/main/l/language-support-en/ suggests 2009!
[02:03] <sarnold> all the datestamps on the directories on http://archive.ubuntu.com/ubuntu/pool/main/l/ suggests maybe 2016 instead
[02:03] <sarnold> is there a reason we don't reap the empty directories on the mirrors?
[02:04] <mwhudson> ah that's when they got deleted https://launchpad.net/ubuntu/+source/language-support-en/+publishinghistory
[02:04] <mwhudson> last upload was karmic though
[02:05] <mwhudson> i guess they got deleted from archive.ubuntu.com when lucid went EOL?
[02:06] <sarnold> "Deleted on 2011-05-26 by Martin Pitt" "Removed from disk on 2016-10-31"  heh
[02:09] <mwhudson> ANYWAY
[02:09] <mwhudson> long dead
[06:27] <sigv> if there is a package versioned 5.0.0-4 (directly pulled from Debian) and I want to get it SRU'd in Focal based on a bug - what should the new version number be?
[06:27] <sigv> 5.0.0-4ubuntu1 or 5.0.0-4.1 or something else is preferred?
[06:28] <sigv> Bionic is back on 4.6.1-1 so there is not reason for putting the 20.04 in the version for the SRU, I would assume.
[07:35] <Unit193> teward: Any updates on those two simple pastebinit commits? :)
[11:55] <ddstreet> mapreri teward i set 'expires' for all of us in the ubuntu-backports team, and it's self-renew once the expires date arrives, i figured neither of you would mind that
[12:15] <teward> Unit193: Its Simon's Fault?
[12:16] <teward> ddstreet: ack alls good
[14:34] <jawn-smith> bdmurray: good morning. mwhudson uploaded golang-1.17 with the risc-v shared library patches and it successfully made it into -release overnight
[14:58] <bdmurray> ginggs: Have you looked at the hwloc ppc64el autopkgtest failure closely?
[15:00] <slyon> ddstreet: what do you think about https://pad.lv/1943982 (also see attached MP to revert the change in Focal and unblock the phased updates)? I'll be working on integrating the additional relevant patches into Hirsute next.
[15:07] <ginggs> bdmurray: I have not, I only triggered the test in release to confirm it wasn't a regression caused by nvidia-settings
[15:13] <bdmurray> ginggs: ack, thanks
[17:32] <jawn-smith> Should we aim to get Go 1.17 in the impish beta?
[17:33] <jawn-smith> well, golang-defaults 1.17 that is
[17:36] <bdmurray> jawn-smith: what does "in the impish beta" mean to you?
[17:38] <jawn-smith> bdmurray: It was my understanding we were building beta images next week. So by "in the impish beta" I meant golang-defaults 1.17 in -release when those images are built
[17:38] <bdmurray> jawn-smith: but is golang-defaults in those images?
[17:39] <jawn-smith> Ah good question
[17:39] <jawn-smith> I'll check, but I think you're right that it's not
[17:41] <jawn-smith> bdmurray: you are correct, it's not in the images.
[17:41] <bdmurray> jawn-smith: out of curiousity how did you check?
[17:42] <jawn-smith> I conveniently have both a desktop and server image that I flashed to Pis yesterday and haven't touched
[17:43] <jawn-smith> I checked if it was installed on them. So not an exhaustive check. Is there a better way to check that?
[17:43] <bdmurray> you might want to check out seeded-in-ubuntu
[17:43] <jawn-smith> Ah I've used that for MIRs
[17:44] <jawn-smith> It says golang-defaults is seeded in ubuntu-mate
[17:44] <jawn-smith> or more specifically: golang-go and golang-src (which are provided by golang-defaults) are seeded in ubuntu-mate
[17:45] <bdmurray> it doesn't seem to be on the images though http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/
[17:48] <jawn-smith> So I'm no longer worried about getting golang-defaults uploaded quickly, but I'm curious why it would be seeded in ubuntu-mate but not present in the images?
[17:49] <bdmurray> 'The minimal, boot, standard, desktop, and either ship or live seeds go onto our CDs and the supported packages are available from the FTP site.'
[17:49] <bdmurray> https://wiki.ubuntu.com/SeedManagement
[17:49] <jawn-smith> cool, thanks! I'll give it a read
[17:51] <jawn-smith> ah yeah it's seeded in ubuntu-mate (supported). Very informative, thanks again!
[19:38] <jawn-smith> I've identified a couple of packages that should be removed from both Debian and Ubuntu. They are leaf packages that don't provide any binaries.
[19:39] <jawn-smith> I know the process for requesting a package removal in Ubuntu, but haven't come across this situation yet where it needs to be removed from Debian as well
[19:39] <jawn-smith> Should I just create the bug requesting removal in both the Debian BTS and LP?
[19:44] <bdmurray> jawn-smith: the removal that we'd do in Ubuntu is temporary the package would get auto imported during JJ's development
[19:45] <jawn-smith> bdmurray: it gets auto imported from Debian right?
[19:46] <bdmurray> yes at the start of the development cycle
[19:46] <jawn-smith> Since it's also a leaf package in Debian it should just be removed there as well, right?
[19:47] <bdmurray> autoimported up to https://wiki.ubuntu.com/DebianImportFreeze
[19:47] <dbungert> jawn-smith: are these packages going to want control file changes?
[19:48] <bdmurray> Why are you asking for its removal? Would the same reason apply to Debian?
[19:48] <jawn-smith> bdmurray: I am asking for removal because the package is a leaf that provides no binaries, and FTBFS with Go 1.17
[19:49] <jawn-smith> Debian is not on Go 1.17 yet, so they are not seeing FTBFS issues with this package
[19:50] <bdmurray> So then it seems to me there isn't a reason to remove it from Debian
[19:50] <jawn-smith> Okay great, I'll just request the removal in Ubuntu then. Thanks bdmurray
[19:51] <jawn-smith> and dbungert: No control changes needed, the packages just FTBFS and aren't needed to build any other packages
[19:52] <dbungert> I wonder if they are meant to be someone else's build dependency.  Not a reason to keep it for impish though, especially if jj will just reimport it.
[19:57] <jawn-smith> Yes that's exactly what they are. There are quite a few go packages that just provide source code used to build other packages. Some of them no longer have reverse-dependencies though'
[20:02] <bdmurray> well you might check to see if there is already a removal request for the package in debian
[20:09] <jawn-smith> bdmurray: there are not removal requests in Debian for the packages that I'm looking at
[20:09] <bdmurray> jawn-smith: okay, if there were then we'd probably also want to add them to the sync blacklist
[20:10] <jawn-smith> That makes sense. Thanks for answering all these questions
[20:11] <bdmurray> no problem