[07:24] <klebers> 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] <laney> 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] <klebers> 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] <sil2100> \o/
[08:29] <klebers> 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] <doko> 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] <utkarsh2102> hey, what's the correct link for reading the ubuntu-policy?
[10:40] <utkarsh2102> sometime back, it was hosted on http://people.canonical.com/~cjwatson/ubuntu-policy/
[10:41] <utkarsh2102> is it https://ubuntu.com/legal/terms-and-policies?
[10:59] <xnox> 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] <doko> good start ... :-/
[11:42] <xnox> it's on riscv64
[13:15] <GunnarHj> 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:33] <xnox> 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] <doko> xnox, did you revert the "cat" approach that I added?
[13:34] <xnox> 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] <xnox> doko:  i am keeping cat, because that preserves ownership
[13:34] <doko> ok
[13:35] <xnox> doko:  i did not test if chmod --reference $file-to-modify $tempfile; followed by chmod --reference $tempfile $modified-file => does everything right.
[13:35] <xnox> or i.e. if chown is also needed. does binutils looses owner/group too?
[13:35] <xnox> "loose" -> mangle / destroy
[13:36] <doko> I think that thing is reverted in 3.37, which we now have in the archive
[13:36] <xnox> 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] <doko> 2.37
[13:36] <xnox> ah, so we might not need anything anymore?!
[13:36] <doko> I haven't looked to rrr yet
[13:38] <Trevinho> GunnarHj: not in vacation :-)
[13:40] <GunnarHj> Trevinho: Ah, good. Then can you please visit that bug and clarify the situation.
[13:43] <Trevinho> GunnarHj: mh I checked, but I wasn't involved on that, was i?
[13:47] <LocutusOfBorg> xnox, please forward in Debian too
[13:47] <LocutusOfBorg> I don't want this delta
[13:48] <LocutusOfBorg> in Ubuntu, for vbox
[13:53] <xnox> LocutusOfBorg:  i'm not touching anything in virtualbox yet; trying to fix debhelper/binutils incompat in ubuntu
[13:54] <LocutusOfBorg> also hirsute needs fixes, or we can just set R^3: no after its EOL :D
[14:04] <GunnarHj> 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.
[14:36] <rbasak> 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] <GunnarHj> rbasak: I'm trying to find out. :)
[14:37] <GunnarHj> ^
[14:39] <rbasak> :)
[15:21] <rbasak> GunnarHj: I just went ahead and accepted gnome-control-center into Focal, seeing as nobody has objected by now.
[15:22] <rbasak> If that's wrong, we can always upload over the top if necessary.
[15:22] <rbasak> (I didn't want to hold up _this_ bug any more given we have people actively working on it)
[15:22] <rbasak> GunnarHj: and thank you again for sponsoring and following up!
[15:24] <GunnarHj> Thanks rbasak
[18:01] <juliank> Looking for feedback on whether delta upgrades would be a meaningful improvement for Ubuntu users, and which
[18:12] <sarnold> 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] <sarnold> 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] <juliank> sarnold: it's the same number of delta deb files as it is for deb files, though
[18:14] <sarnold> juliank: *iff* you allow downloading a single exact jump from whatever previous package the user has installed to whatever latest is, yeah
[18:14] <sarnold> juliank: if the way to jump four versions involves downloading four diffs, it'll be much more
[18:15] <juliank> 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] <sarnold> juliank: ah so in the case of jumping four versions, apt would just download the new version like it does today?
[18:17] <juliank> sarnold: yeah if no such delta exists, sure
[18:17] <juliank> sarnold: there was the question of how to check for the delta and verify it
[18:18] <juliank> 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] <juliank> sarnold: And of course, my approach with a bloom filter file and an additional index file per source package
[18:20] <sarnold> juliank: ooo. I initially quite like that bloom filter with index-per-source idea.
[18:21] <juliank> sarnold: See repository layout v2 https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs
[18:22] <juliank> 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] <sarnold> juliank: I'm reminded of perfect hash maps, eg https://docs.rs/boomphf/0.5.9/boomphf/
[18:22] <sarnold> 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] <juliank> sarnold: not _really_
[18:23] <juliank> sarnold: so the deltas are between package ids, and can hence be across source packages
[18:23] <juliank> 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] <juliank> is really a delta
[18:24] <juliank> sarnold: All you have to do in the end I think is to add rename support to the delta generator
[18:24] <juliank> Well, maybe you want to avoid delta lookups for new installs, and hence want that rename support in apt too
[18:25] <juliank> So yes it can be a bit to wrap your head around
[18:26] <sarnold> 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] <juliank> sarnold: so you'd have to have the complete deb for that