[00:32] <arraybolt3> Silly question, but is there some reason why p7zip has been the only 7z implementation in Debian and Ubuntu for years when true 7z runs just fine on Linux? Just no one to package it or is there an issue that keeps it from being packaged?
[00:33] <arraybolt3> I'd like to work on it for Debian and Ubuntu if no one knows of blockers. I see someone tried to get it into debian in 2021 and it just got left.
[00:33] <arraybolt3> The only issue I saw was unRAR code, which someone was able to just disable and probably patch out.
[00:35] <bdrung> tsimonq2, the code change for the ubuntu-sponsoring move is ready in the main branch and building in https://code.launchpad.net/~ubuntu-sponsors/+recipe/ubuntu-sponsoring-daily now. Next step is to setup the environment (i.e. install that package and configure a webserver)
[00:47] <tsimonq2> amurray: Thanks for your help, and leosilva thanks in advance for what you're able to get to. :)
[00:48] <tsimonq2> arraybolt3: I don't see why not, but I'd look carefully at the licensing and any existing packages that may implement such functionality.
[00:48] <tsimonq2> arraybolt3: I could totally see an embedded copy being *somewhere*.
[00:49] <arraybolt3> I think all the compression thingies we have are front ends (at least Ark, File Roller, LXQt Archiver, and xarchiver for sure are).
[00:50] <tsimonq2> bdrung: Nice! That looks really promising. Thanks again!
[00:53] <bdrung> tsimonq2, the code could get more improvements like test cases, splitting data collection and rendering, etc.
[01:05] <arraybolt3> heh, I'm late. "True" 7zip is already in the repos and I just missed the memo.
[01:16] <tsimonq2> bdrung: Sounds good, hopefully we can get that polished soon. :)
[01:17] <tsimonq2> bdrung: Would the goal be to charm/do something magical so it can be redeployed on recent releases? (Is it already deployed on a recent release?)
[01:17] <tsimonq2> arraybolt3: Nice job. ;)
[01:29] <arraybolt3> doko: Attempting to get experience working with Universe packages, you don't mind if I steal your `sc` merge do you? (It's a TUI spreadsheet app.)
[01:57] <tsimonq2> Looks like both openjdk-21 packages are almost done. Let's see what Lintian wants to yell about...
[02:19] <tsimonq2> vpa1977: I really dislike all these Lintian flags being thrown... https://paste.ubuntu.com/p/MDfnPGRd7d/
[02:20] <tsimonq2> vpa1977: I'd appreciate it if these could be worked on at some point in the very near future...
[02:21] <tsimonq2> vpa1977: That being said, I don't plan on torturing you over this, so I think I'll (very hesitantly) let it slide.
[02:29] <vpa1977> tsimonq2: a few things there definitely need attention - a good idea for me would be to finish with java 21 ftbfs'es and clean up warnings
[02:29] <vpa1977> tsimonq2: so that it is ready for the January release
[02:29] <tsimonq2> vpa1977: Let me know if you need any help getting things polished. :)
[02:30] <vpa1977> tsimonq2: thank you !!! ;)
[02:46] <tsimonq2> vpa1977: No problem :)
[03:04] <tsimonq2> vpa1977: cron> I don't remember if I've mentioned this to you or not, but some piece of tooling likes to add an extra line to the end of the changelog. Please remove it (and watch out for it). ;)
[03:05] <tsimonq2> I really should fix that bug someday. :P
[03:07] <tsimonq2> vpa1977: Not to be a *huge* pain, but just so you remember for next time, please push that minor change ;) as soon as that's done, I'll sponsor.
[03:10] <tsimonq2> mitchdz: So, your hibagent diff seems okay, but I'm seeing this in a few places:   <frozen importlib._bootstrap>:530: DeprecationWarning: the load_module() method is deprecated and slated for removal in Python 3.12; use exec_module() instead
[03:11] <tsimonq2> mitchdz: I'll leave it until the morning for good measure, but I'm curious whether you also plan on addressing those, or if the change you made is somehow different/more urgent.
[03:13] <mitchdz> tsimonq2:  I was curious about that too, but since it seems to be working I didn’t really worry about it too much. I can look into the “proper” way to do it tomorrow.
[03:13] <tsimonq2> mitchdz: No worries, thanks! Let me know if I can help. :)
[03:18] <vpa1977> tsimonq2: (cron) apologises, done
[03:18] <tsimonq2> vpa1977: No worries, thanks!
[03:19] <vpa1977> tsmimonq2: looks like a bug in git-ubuntu
[03:25] <tsimonq2> vpa1977: Seemingly so, but I recall those scripts being in/near grab-merge as well.
[03:26] <tsimonq2> vpa1977: https://launchpad.net/ubuntu/+source/cron/3.0pl1-178ubuntu1 🎉🎉🎉🎉
[03:26] <tsimonq2> Okay, okay, for real this time. I'll leave some packages for the others. :P
[03:27] <vpa1977> tsimonq2: thank you =)
[03:27] <tsimonq2> No worries :)
[08:29] <ogayot> I'm doing +1 rotation this week. If anything worth looking comes up, feel free to ping me
[10:01] <mkukri> looks like my libarchive upload broke abi in some way in armhf.
[10:01] <mkukri> unrar-free is blocking migration. no op rebuild of unrar-free makes the test pass.
[10:01] <mkukri> however i am slightly concern that it might break something else silently
[10:10] <seb128> do you understand what change in the update is creating the issue?
[10:10] <seb128> maybe figuring that out would be the first step
[10:11] <mirespace> is there any trick to build i386 packages in launchpad? Trying to do it in "details"  ->  Intel x86 (i386) only marked
[10:11] <mirespace> forcing architecture: i386 in the package doesn't work either (rejected qith that and with aby)
[10:11] <mirespace> s/aby/any/
[10:12] <mkukri> seb128: sorry wrong about that, it isn't abi, rebuild test still fails.
[10:13] <mkukri> what the new librachive is dieing on is some malformed input validation tests in unrar that originally targeted some CVEs in it's own implementation that got replaced with libarchive.
[11:09] <ginggs> ogayot: I suggest **not** looking at anything R-related; rmatrix, lme4, r-cran-*, etc
[12:36] <ogayot> ginggs: ack, thanks!
[12:53] <kjerome> Hi guys, I'm new around here and was wondering what's the "official" way of contributing bug fixes to a random package, can anyone help me with that?
[13:00] <nteodosio> Hey kjerome, generate a patch with the fix (https://wiki.ubuntu.com/Bugs/Patches), attach it to the corresponding package bug in Launchpad (create one if not reported yet) and subscribe ubuntu-sponsors or share the bug number here.
[13:01] <nteodosio> You could also submit upstream first and see if they accept it so that Ubuntu doesn't need to carry that patch.
[13:08] <kjerome> Thanks! I'll work on it :)
[13:39] <xnox> mirespace: there is filter applied on per-ubuntu series which packages are allowed to build on i386 based on an inclusion set. It is mostly minimal buildd chroot packages + multi-arch libraries as commonly used to run 3rd-party / proprietary i386 binaries (windows apps and games)
[13:40] <xnox> mirespace: there is no way to build stuff beyond that set on a whimp. if you are working on an transition, you can request ahead of time inclusion of libfoo7 if currently libfoo6 is the one in the i386 inclusion set to aid with bootstrapping. but that's about it.
[13:40] <xnox> mirespace: is this something you want for yourself, or is this something as part of an api/abi/name transition of the existing set of i386 binaries?
[15:29] <mirespace> xnox: it's for the unbound migration: I'm checking i386 dependendcies that needs also to be used in its build, and wanted to have a unique repo to make the build with all of them... I set a local repo after colin also confirmed to me the herency of the white and black list for i386 from the Archive to ppa
[15:30] <mirespace> xnox: and I found that redis depends on hiredis, and hiredis on redis to be built... circular build dependecy
[15:54] <xnox> fun
[15:55] <xnox> mirespace: in general if you need forward looking package inclusions on i386 you can request them from archive admins (and ask them to follow the https://wiki.ubuntu.com/ArchiveAdministration#i386_whitelist_updates process)
[15:55] <xnox> or try to ensure you break the depends cycle on i386 and disable packges
[15:55] <xnox> because usually new stuff is not needed for old stuff compat
[15:56] <xnox> (as we only care about compat with existing 3rd party i386 binaries, without expecting any new one being built at all)
[15:57] <mirespace> xnox: thanks :) I did , I asked for hiredis to be included , but it has dependencies that are also missing for i386 ... so I got the dependency tree, but I though that I should built it all to ensure nothing is missing
[15:58] <xnox> mirespace: including the "head/top-level" should pull in all the build-depends chain into scope.
[15:58] <mirespace> xnox: so, for including in i386 whitelist, the package is copied, not built again?
[15:58] <xnox> so just wait for that to be updated
[15:58] <xnox> after it's in the allow list; i386 builds still need to be triggered or bootstrapped.
[15:59] <xnox> one can do that with api to add missing build records; or copy to & from the same package archive with binaries; that will too, trigger build-record on i386
[16:01] <mirespace> xnox: bootstraped ... it recalls me dotnet... bootstrapping pursues me!
[16:01] <mirespace> xnox: thanks for the explanation!
[19:30] <vpa1977> Hi, would it be possible to hit retry on https://launchpad.net/ubuntu/+source/openjdk-21/21.0.1+12-2~20.04/+build/27010651 - gcc crashed on a riscv builder, the package previously succesfully built on riscv in a PPA
[19:30] <vpa1977> Thank you!!!
[19:35] <bryceh> @pilot in
[19:35] <bryceh> @vpa1977, done
[19:35] <vpa1977> bryceh: Thank you!!!
[20:04] <arraybolt3> dannf: Stealing the pending Munin merge, feel free to steal it back whenever.
[20:22]  * bryceh --> lunch bbl
[20:34] <tsimonq2> @pilot in
[20:35] <tsimonq2> bryceh: Afternoon. I'm going back to my "one or two" today, I'll probably just knock out arraybolt3's unless you've already started reviewing it.
[20:46] <tsimonq2> ogayot: +1 rotation> find a reason to make another upload to kitty. ;)
[20:47] <tsimonq2> ogayot: Actually... there is a merge that could be done. ;) ;) ;)
[20:47] <tsimonq2> arraybolt3: Uploaded jigit for you.
[20:47] <arraybolt3> thanks :)
[20:47] <tsimonq2> Of course. :)
[20:52] <dannf> arraybolt3: I didn't realize I'd claimed that - thanks for taking it!
[21:00] <tsimonq2> mkukri: cryptsetup> osk-sdl armhf> I'm going to give it a retry against migration-reference/0 to see if that works. Honestly seems like it just needs a simple string update.
[21:01] <mkukri> i think i did a retrigger this morning and no dice
[21:02] <mkukri> didnt have much time to look into it today, but it's on my todo list
[21:02] <tsimonq2> Well, you did a retrigger against cryptsetup, which is good and all to make sure it's not flaky. What I'm really looking for is whether it's regressed in the release pocket, which that migration-reference/0 trigger does. :)
[21:03] <tsimonq2> We'll know in ~6 minutes whether it's regressed in the release pocket, I'll keep you posted.
[21:03] <mkukri> cheers
[21:04] <tsimonq2> The same failure exists in debci on stable...
[21:04] <tsimonq2> https://ci.debian.net/packages/o/osk-sdl/stable/armhf/38488279/
[21:04] <tsimonq2> Somebody just misspelled something, I think. :P
[21:04] <tsimonq2> 241s 	got:            potmarketOS
[21:04] <tsimonq2> 241s 	expected:       postmarketOS
[21:04] <arraybolt3> mmm, potmarketOS. Sounds like a tool to order food.
[21:05] <tsimonq2> This one's my favorite: 151s got:            porketOS
[21:05] <tsimonq2> ( https://ci.debian.net/packages/o/osk-sdl/unstable/ppc64el/39424498/ )
[21:07] <mkukri> hmm i guess that's an easy fix, still waiting for the amd64 results tho
[21:09] <tsimonq2> https://salsa.debian.org/DebianOnMobile-team/osk-sdl/-/blob/debian/master/test/test_functional.sh#L183
[21:10] <tsimonq2> If I had to take a shot in the dark, I'd say we need to bump that delay up.
[21:11] <tsimonq2> mkukri: It *did* in fact fail against migration-reference/0, so it will not be a blocker for migration of cryptsetup. That being said, you're more than welcome to add this on your list for practice. :)
[21:11] <tsimonq2> (Fixing autopkgtests is Generally Nice if you have the time, even if it doesn't affect the current "transition" directly.)
[21:13] <mkukri> next week ill be doing +1 maintenance, so it should get fixed anyways. but i might get to it earlier, will see how other things progress
[21:15] <tsimonq2> Sounds good!
[21:16] <tsimonq2> bryceh: I typically consider kernel stuff to be slightly over my head, but if you want to look at bug 1970672 it's all yours. ;)
[21:16] -ubottu:#ubuntu-devel- Bug 1970672 in makedumpfile (Ubuntu Focal) "makedumpfile falls back to cp with '__vtop4_x86_64: Can't get a valid pmd_pte.'" [Medium, Confirmed] https://launchpad.net/bugs/1970672
[21:17] <tsimonq2> xnox: You may know who, if not bryceh ^
[21:59] <tsimonq2> @pilot out
[22:54] <bryceh> tsimonq2, sorry, got caught up with other stuff
[23:00] <bryceh> tsimonq2, yeah I'm also unsure about the kernel-adjacent items
[23:03] <tsimonq2> bryceh: No worries, thanks!
[23:08] <tsimonq2> arraybolt3: Uploaded samtools-legacy for you.