[07:24] xnox, hey! the riscv meta update was already published to -proposed in case you want to test it. Also, do we need those Breaks to it? [08:06] bdmurray: almost all packages will have that. As part of initialisation we look for a pass in the history, so that we can determine if a failure is a regression or not. [08:28] sil2100, hi! Sorry, I missed your ping yesterday. The default riscv meta switch to 5.11 is already in -proposed, we can promote it to -updates as soon as all the pieces are tested together. [08:29] \o/ [08:29] but we also should check with xnox if adding the Breaks he suggested will be necessary. In that case we'll need to start a re-spin asap. [09:45] fyi, gcc-defaults pointing to GCC 11 is now in impish-proposed, but not yet built on all archs. will follow-up once it it built everywhere [10:40] hey, what's the correct link for reading the ubuntu-policy? [10:40] sometime back, it was hosted on http://people.canonical.com/~cjwatson/ubuntu-policy/ [10:41] is it https://ubuntu.com/legal/terms-and-policies? [10:59] doko: i am getting illegal instructions after building u-boot. It's using gcc-10 still, but uses gcc-11-base things. It shouldn't matter. Will try rebuilding u-boot from impish in hirsute to check if that is any better. [11:01] good start ... :-/ [11:42] it's on riscv64 [13:15] Hi rbasak! Would be good if you could revisit bug #1938747 and accept the focal upload too. Trevinho seems to be on vacation, and the uploader is on the alert with verification. [13:15] Bug 1938747 in gnome-control-center (Ubuntu Focal) "[SRU] can't adjust output volume through volume-slider after changing output-device" [High, In Progress] https://launchpad.net/bugs/1938747 [13:33] LocutusOfBorg: doko: uploaded http://launchpadlibrarian.net/551745370/debhelper_13.3.4ubuntu1_13.3.4ubuntu2.diff.gz to hopefully fix setuid and setgid bits that go missing after dh_strip. [13:34] xnox, did you revert the "cat" approach that I added? [13:34] i wonder if any other similar commands that do things to binaries need to do the same. I.e. in case strip_nondeterminism operates on setuid or setgid [13:34] doko: i am keeping cat, because that preserves ownership [13:34] ok [13:35] doko: i did not test if chmod --reference $file-to-modify $tempfile; followed by chmod --reference $tempfile $modified-file => does everything right. [13:35] or i.e. if chown is also needed. does binutils looses owner/group too? [13:35] "loose" -> mangle / destroy [13:36] I think that thing is reverted in 3.37, which we now have in the archive [13:36] also I was confused about umask. Rules-Requires-Root: binary-targets and Rules-Requires-Root: no are different umasks, no? 0022 vs 0002 no idea if that matters. [13:36] 2.37 [13:36] ah, so we might not need anything anymore?! [13:36] I haven't looked to rrr yet [13:38] GunnarHj: not in vacation :-) [13:40] Trevinho: Ah, good. Then can you please visit that bug and clarify the situation. [13:43] GunnarHj: mh I checked, but I wasn't involved on that, was i? [13:47] xnox, please forward in Debian too [13:47] I don't want this delta [13:48] in Ubuntu, for vbox [13:53] LocutusOfBorg: i'm not touching anything in virtualbox yet; trying to fix debhelper/binutils incompat in ubuntu [13:54] also hirsute needs fixes, or we can just set R^3: no after its EOL :D [14:04] Trevinho: You became involved indirectly since you had pushed a hirsute fix of another bug to the repo, and I uploaded that. Please see comment #11. === genii-core is now known as genii === genii is now known as genii-away [14:36] GunnarHj: thank you for following up. I'm happy to just accept the Focal upload. I just want to confirm that Trevinho is happy with that, but sounds like he is? [14:37] rbasak: I'm trying to find out. :) [14:37] ^ [14:39] :) === genii-away is now known as genii [15:21] GunnarHj: I just went ahead and accepted gnome-control-center into Focal, seeing as nobody has objected by now. [15:22] If that's wrong, we can always upload over the top if necessary. [15:22] (I didn't want to hold up _this_ bug any more given we have people actively working on it) [15:22] GunnarHj: and thank you again for sponsoring and following up! [15:24] Thanks rbasak [18:01] Looking for feedback on whether delta upgrades would be a meaningful improvement for Ubuntu users, and which === georgiag_ is now known as georgiag [18:12] juliank: at first I'm skeptical -- the pdiff things for debian package lists always felt vastly slower for me than just grabbing new lists entirely [18:13] juliank: delta updates sounds appealing for folks on slow connections, but those folks also often have high-latency connections, and doing a bunch of little bursty things can take as much time as fewer larger things [18:13] sarnold: it's the same number of delta deb files as it is for deb files, though [18:14] juliank: *iff* you allow downloading a single exact jump from whatever previous package the user has installed to whatever latest is, yeah [18:14] juliank: if the way to jump four versions involves downloading four diffs, it'll be much more [18:15] sarnold: no jumps allowed because the delta is just passed to dpkg to install like a normal deb (it patches the installed files directly; well into .dpkg-new files) [18:16] juliank: ah so in the case of jumping four versions, apt would just download the new version like it does today? [18:17] sarnold: yeah if no such delta exists, sure [18:17] sarnold: there was the question of how to check for the delta and verify it [18:18] sarnold: The approaches were to have an index file like Packages, just called Deltas with SHA256 and Filename fields (we just so we get a SHA256 for the delta), well and size; and then use Pdiffs for that [18:19] sarnold: And of course, my approach with a bloom filter file and an additional index file per source package [18:20] juliank: ooo. I initially quite like that bloom filter with index-per-source idea. [18:21] sarnold: See repository layout v2 https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs [18:22] There's some stuff about unique package ids that's needed to, and it's different unique ids than what reproducible builds people want, which is distracting [18:22] juliank: I'm reminded of perfect hash maps, eg https://docs.rs/boomphf/0.5.9/boomphf/ [18:22] juliank: .. of course using something like this would make it awkward to add new packages to a release, so at least kernel packages would be miserable.. [18:23] sarnold: not _really_ [18:23] sarnold: so the deltas are between package ids, and can hence be across source packages [18:23] sarnold: Basically you'd look at the new ID, download the delta index if you see old ID -> new ID in bloom filter and then see if there [18:24] is really a delta [18:24] sarnold: All you have to do in the end I think is to add rename support to the delta generator [18:24] Well, maybe you want to avoid delta lookups for new installs, and hence want that rename support in apt too [18:25] So yes it can be a bit to wrap your head around [18:26] juliank: is there a way to unapply these diffs? I'm really surprised how often I need to tell people about /var/cache/apt/archives/ to help them unstick things.. [18:27] sarnold: so you'd have to have the complete deb for that === genii is now known as genii-core