=== arrayboltIRSSI is now known as arraybolt3 [06:07] * Unit193 awaits ahasenack's return. [11:37] Hi, could an AA look at the following upload? https://launchpad.net/ubuntu/+source/opencolorio/2.1.2+dfsg1-3ubuntu1 ; there is a new binary package libopencolorio2.1. Thanks! [12:24] is something wrong with the main archive site? I got this for armhf and arm64 now: [12:24] E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/kinetic/main/binary-arm64/Packages 404 Not Found [IP: 185.125.190.36 80] [12:34] ops, sorry for the noise, it's a very different url [12:34] I just moved my lxd profile from my amd64 host to a pi4 box, and didn't realize the archive urls need changing [13:16] RikMills, hi :), is KDE going to use QT6 as default in kinetic? [13:21] hmm, I guess that answers my question - https://community.kde.org/Schedules/Plasma_6 [13:38] ricotz: indeed, no === luis220413_ is now known as luis220413 [16:04] RikMills, are you pushing more qt6-abi rebuilds? :) - like pyqt6, calibre [16:06] ricotz: calibre doesn't need it, as there is calibre in -proposed that just needs retrying when qt6-webengine has built [16:06] others are pointless until webengine has built. the I will do them [16:07] *then I [16:08] RikMills, thanks! [16:08] np === nicoz is now known as ninox === ninox is now known as nicoz [20:49] ahasenack: https://salsa.debian.org/debian/wireguard/-/merge_requests/6#note_330684 pinged dkg, but like I said seems fine. I can no longer merge/upload wireguard to Ubuntu so I guess you'll have to merge/sync though. [20:50] Merge 6 in debian/wireguard "New DEP8 and build-time tests" [Opened] [21:12] Unit193: that's because of the MIR promotion of wireguard? [21:12] yeah :( [21:12] hm [21:13] Unit193: but you do upload it in debian, right? [21:13] I took a look at the package last night or so, I plan to drop all patches and make other adjustments. [21:13] ahasenack: Yes, I seem to be the most active on it now. [21:14] I defer to dkg because he's actually the maintainer, but I'm in 'uploaders'. [21:14] I'm subscribed to it in the debian tracker, I will get notified of any uploads or bugs even [21:14] so I don't think ubuntu will fall behind [21:15] Great. That's actually how I got sucked into this, Ubuntu fell far behind and I did a few merges. [21:16] ah, famous TIL [21:17] I think after the DEP8 upload, we can just sync. The flip of the recommends shouldn't really matter too much anymore. [21:19] I think so too [21:22] but I'll recheck when the time gomes [21:22] comes [21:22] there was something about ubuntu cloud images that kept the recommends flip in place back then [21:23] I have links to irc conversations with apw about that [21:24] not just cloud images, but if you happen to be on a kernel that doesn't have the module, then dkms would be pulled in and just do the right thing [21:24] something like that [21:24] Basically it could pull in a hwe kernel or one of the other kernels when pulling in the dkms module would have been the sane option. [21:24] but since dpkg doesn't check the *running* kernel, I don't remember how this could work in all cases [21:24] Since it should now be everywhere... [21:26] I think it's also time for wireguard-linux-compat to be removed from Debian (and Ubuntu too I imagine.) [21:28] if debian gets rid of it first, it's much easier for ubuntu to follow [21:28] but I remember upstream commenting in a bug about that, objecting. Or am i mixing up things, maybe upstream objected to the dkms removal [21:28] I can't find that package via apt-cache show wireguard-linux-compat on any of my machines that are turned on [21:28] for awareness, I've just uploaded an openssh package to kinetic that switches sshd to use systemd socket activation. Please yell at me if you see any regressions https://lists.ubuntu.com/archives/kinetic-changes/2022-August/005198.html [21:33] sarnold: wireguard-linux-compat is the source package, wireguard-dkms is the binary. [21:33] ahhhhhhh [21:33] I shoulda checked the machine that's turned off :) [23:07] Is it worth keeping around my original 22.04 ISOs for potential future use in testing, or is it an OK idea to chuck them and only keep the 22.04.1 ISOs? [23:11] arraybolt3: do whatever you want with them? they'll still be available for download from old-releases.u.c [23:12] The flavors, not usually. Multiple flavor ISOs are just gone from there. [23:12] oh for flavors, right [23:12] I usually pull "missing" ISOs from Archive.org but there's no guarantee that they'll be there. [23:12] (Also, out of curiosity, *why* are the flavor ISOs deleted even from old-releases?) [23:12] well I would say there's diminishing value in testing the .0 ISOs that aren't even available for download [23:13] arraybolt3: Keep the torrent files, hope for the best? [23:13] arraybolt3: old-releases has always been an archive of releases; we've never retained cdimage.u.c content there [23:13] Yeah, I just thought for regression testing and that sort of thing. But I don't think it will be needed - if there's a regression, it can be verified with a downgraded package. [23:14] vorlon: Hmm, there certainly are a lot of ancient Ubuntu flavor ISOs on there. Just curious since they can be rather valuable in some instances. [23:14] Unit193: If only I could torrent safely with my ISP... [23:14] Weird, as long as they're legal torrents the ISP shouldn't care. :/ [23:15] moreover, it's decreasingly important whether a bug is a regression vs the release pocket [23:15] we don't undo a point release because someone found a regression 3 months later [23:15] Unit193: They are legal, but I'm on cellular internet (T-Mobile hotspot through Calyx Institute) and T-Mobile considers BitTorrent to be network abuse. :( I could try it, but they might throttle me down beyond all reason. [23:16] and if you're testing for regressions in individual packages in -updates, as opposed to of the installer, there are more efficient ways of doing that [23:16] vorlon: Good point. I guess I'll save on disk space then and clear out the old ones. [23:16] vorlon: Can be helpful to find at what stage the regression hit so as to help figure out what change caused it. [23:16] Note: "Can be" [23:17] Unit193: My use case for very old Ubuntu flavor releases is mostly out of preference - sometimes you've gotta run some ancient app in a VM and would rather do it with KDE4 than with Unity. But I'm getting off-topic now. [23:22] arraybolt3: "ancient Ubuntu flavor ISOs" - well kubuntu and edubuntu once upon a time were distributed from releases.u.c; the others are on there by accident, but unfortunately they've been deleted from the source but this doesn't reflect on the web frontend [23:23] Ah, that makes sense to me.