[09:13] <Skia> cjwatson: thanks for all the info and the plan. I indeed have access to the VM, and found a `setup-history` file in the juju environment. To me, it doesn't look really hard to maintain or redeploy: it's just a bunch of python triggered by a cron, so compared to autopkgtest or the error tracker, it's a breeze. The only thing I don't have right now is time to really commit to it. I only kick it from time
[09:13] <Skia> to time when something gets stuck :-)
[09:17] <Skia> also, with the HAProxy in frontend, it shouldn't be too hard to spin up a new modern VM and play with it until it works, then switch the backend.
[09:19] <cjwatson> Skia: right :)
[09:40] <guruprasad> cjwatson, "would be stored in OpenStack object storage, but you'd need a DB to keep track of all the pointers", are we doing another librarian? :)
[09:43] <cjwatson> guruprasad: Conceptually a bit similar!  Though much simpler
[12:51] <toabctl> Skia, could you make the bzr branch of merge-o-matic emtpy so others do not run into the same mistake?
[13:18] <Skia> toabctl: the thing is that MoM is currently still deployed with bzr, so it's technically still the main repo. I'll do all that when I get to work on MoM. Maybe I should plan something for next pulse, so that the situation doesn't stay for too long...
[13:19] <toabctl> ah. ok. thx
=== mfo_ is now known as mfo
[17:02] <tsimonq2> adrien: I'd be deeply interested in learning what the latest developments are in post-quantum cryptography support if you happen to have any pointers.
[17:03] <tsimonq2> (I've taught myself the basics of quantum mechanics recently so this is more of a hobby-based question, to be honest.)
=== matttbe1 is now known as matttbe
[17:24] <liushuyu> Hi, can someone sponsor https://code.launchpad.net/~liushuyu-011/ubuntu/+source/ruby3.3/+git/ruby3.3/+merge/479108? (Must be CoreDev or better, as this package is in main)
[17:39] <tsimonq2> liushuyu: looking
[17:39] <liushuyu> tsimonq2: Thanks!
[17:39] <tsimonq2> I would ping Utkarsh as well for an FYI but he's still bouncerless. :(
[17:41] <tsimonq2> liushuyu: Hey, before I sponsor, I just want to dot my Is and cross my Ts... this will start a Ruby transition. You all prepped and ready to go for that?
[17:41] <tsimonq2> (I suppose not a *major* one, but notable enough where I figured I'd ask.)
[17:42] <liushuyu> tsimonq2: I think the transition is already on-going (needs autopkgtest infrastructure to be a bit stable though)
[17:42] <tsimonq2> Skia, paride: ^^^ I've occasionally been running retry-autopkgtest-regressions --only-unknown - if this is counterproductive please let me know
[17:42] <tsimonq2> liushuyu: Thanks!
[17:43] <Skia> tsimonq2: well, usually, it's not, and thanks for that, but with the current outage in PS6, it's just not really useful, because tests just aren't processed
[17:44] <tsimonq2> Skia: Ah okay, got it :)
[17:44] <tsimonq2> liushuyu: Any chance you could rebase your changes on the NMU?
[17:45] <tsimonq2> https://tracker.debian.org/news/1604414/accepted-ruby33-336-11-source-into-unstable/
[18:10] <liushuyu> tsimonq2: Will do
[18:18] <liushuyu> tsimonq2: Done now. So this new NMU dropped another Ubuntu delta, nothing else
[18:26] <tsimonq2> liushuyu: Precisely. Thanks, looking again :)
[18:28] <tsimonq2> liushuyu: One more thing... what's up with that debian/rules diff?
[18:28] <tsimonq2> -DEB_BUILD_OPTIONS += abi=time64
[18:28] <tsimonq2> -
[18:28] <tsimonq2> what does this do
[18:29] <liushuyu> tsimonq2: we have that in Ubuntu by default and according to a previous uploader of this package, we need to remove it to avoid issues with debhelper in Ubuntu
[18:30] <tsimonq2> ...which I touched last. Nice. :P
[18:30] <tsimonq2> Okay, no objection, uploading.
[18:31] <liushuyu> tsimonq2: Thanks! The fix for ppc64le has been merged upstream, but the upstream won't backport this fix to the 3.3 series
[18:32] <tsimonq2> liushuyu: Meh that's fine, just make sure Debian has it if they need it :)
[18:33] <tsimonq2> (I didn't look too closely at that specific element here because you've been good about it in the past.)
[18:33] <liushuyu> tsimonq2: It's forwarded to Debian as https://salsa.debian.org/ruby-team/ruby/-/merge_requests/9
[18:33] -ubottu:#ubuntu-devel- Merge 9 in ruby-team/ruby "Fix memory corruption issues and enable LTO" [Opened]
[18:34] <tsimonq2> awesome :)
[18:34] <liushuyu> GCC won't blow up the Ruby interpreter on non-ppc64le platforms, but the issue is present on all architectures
[18:34] <liushuyu> (I checked Clang and Clang indeed will misoptimize Ruby 3.3 due to more aggressive optimizations)
[18:35] <tsimonq2> Ah, okay. That makes sense.
[18:35] <tsimonq2> liushuyu: https://launchpad.net/ubuntu/+source/ruby3.3/3.3.6-1.1ubuntu1
[18:36] <tsimonq2> Skia, paride: hi yes many autopkgtests incoming ;) https://launchpad.net/ubuntu/+source/ruby3.3/3.3.6-1.1ubuntu1
[18:37] <liushuyu> tsimonq2: Thanks! MRI Ruby C code quality is quite questionable, but eh, we can't do a lot about that
[18:38] <tsimonq2> liushuyu: heh fair enough :)
[18:39] <liushuyu> Do we have a general policy for adding extra dependencies for Debian/Ubuntu packages?
[18:42] <liushuyu> ... the question is more about if it's okay to add 20+ dependencies to the newer version of a package because the upstream decided to import a lot of libraries?
[18:43] <tsimonq2> Depends. Off the top of my head, I'd gauge that with two questions...
[18:43] <tsimonq2>  1. Is the package in Main?
[18:43] <tsimonq2>  2. Is it necessary?
[18:44] <tsimonq2> If #1 is no and #2 is yes, JFDI.
[18:44] <tsimonq2> If both are yes, be careful of MIRs.
[18:44] <tsimonq2> If both are no, then I'd say yeah, think twice, but it's your GPG key not mine. ;)
[18:46] <liushuyu> tsimonq2: The package in question is https://launchpad.net/ubuntu/+source/mailman-hyperkitty, so the newer version added 20+ Python dependencies, which are hard requirements (missing any of those 20+ new dependencies will result in the software non-functional). The other option is to not upgrade though
[18:46] <liushuyu> Debian did not pick up the updates because the debian/watch file is broken
[18:47] <tsimonq2> > the debian/watch file is broken
[18:47] <tsimonq2> Let me guess, GitHub?
[18:47] <tsimonq2> liushuyu: Seems okay on first glance, I'd just double check with Debian Policy 4.13. Embedded code copies <https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies>
[18:49] <tsimonq2> (Is there a debhelper substvar that can be used for Python includes? If not, that might be awesome to have.)
[18:49] <liushuyu> tsimonq2: Not GitHub, but PyPI. Well, I should probably say that the upstream decided to stop doing releases on PyPI and moving everything to GitLab
[18:49] <tsimonq2> liushuyu: Ah, okay. So even more drastic.
[18:49] <tsimonq2> something something make sure to poke Debian etc etc
[18:50] <liushuyu> tsimonq2: Yes, the newer version also bundles a megaton of minified JavaScript libraries
[18:50] <tsimonq2> boo.
[18:51] <liushuyu> Okay, I guess I will probably start the discussion or something in Debian first
[18:51] <tsimonq2> liushuyu: The debian/copyright of qt6-base, qt6-declarative, and qt6-webengine might be useful references, specifically the Files-Excluded section
[18:52] <tsimonq2> Debian-first is certainly best practice, but if you have it nailed down correctly and you're verysure, feel free to upload to Ubuntu. But yeah, discussion in lieu of a (lowercase c) canonical answer there is probably useful.
[18:52] <liushuyu> tsimonq2: I am familar with the source tarball repacking business, but a lot of web applications like this don't like it if the static files are replaced by symbolic links
[18:53] <tsimonq2> liushuyu: Very true. I do webdev in $dayjob a bit, and I've seen many projects nail down a specific e.g. jQuery version and don't support anything else.
[18:53] <tsimonq2> I suppose the downside of "modern" languages having their own package managers, and JavaScript in general, is dependency hell. :P
[18:54] <tsimonq2> (But I've also seen symlink-related issues too, Ben comes to mind.)
[18:54] <liushuyu> (oh yes, wait until you see some projects start to compile C/C++ code to WebAssembly/asm.js for cross-platform compatibility)
[18:55] <tsimonq2> Oh yeah. We have a few of those internally. Unfortunately I'm aware.
[18:56] <liushuyu> I see, so it's more widespread than I think then
[18:57] <tsimonq2> Yeahp. :(
[18:58] <tsimonq2> (This is why I wrote the entire nascent Lubuntu CI in C++ with QHttpServer and some *basic*, basic JS on the frontend. It's because I'm sick of using 500,000,000 languages all cobbled together. :P)
[19:00] <liushuyu> Oh, you don't like the experience of minifying 8 billion different Npm modules and merging them into your code?
[19:00] <tsimonq2> Yes of course, it's the reason I get up in the morning. /s
[19:02] <tsimonq2> liushuyu: Have you started your Core Dev application btw? From my perspective it doesn't seem like it'll be long :P
[19:02] <tsimonq2> (meaning, a long time before you actually submit it, not referencing the length of the application)
[19:02] <liushuyu> Ha ha. No wonder your blanket can't hold you hostage in the morning
[19:02] <tsimonq2> XD
[19:04] <liushuyu> tsimonq2: I do, initially I was preparing to apply for CoreDev. But someone suggested me to go through a safer route
[19:04] <liushuyu> ... so the application for CoreDev actually already existed, I just need to revise a bit
[19:04] <tsimonq2> Agreed that it's safer, it's not often you see successful "no rights" -> Core Dev applications.
[19:05] <tsimonq2> liushuyu: If you can nail this Ruby transition, I'd say that's worth an endorsement, or at least a comment. No pressure. ;P
[19:07] <liushuyu> Sounds like I have one more excuse to enable the Rust bits in Ruby then
[19:08] <liushuyu> (the new JIT compiler)
[19:08] <tsimonq2> :))
[19:47] <adrien> tsimonq2: I feel like the PQC field is incredibly large (and deep), and changing. I feel like it's very difficult to summarize. https://blog.cloudflare.com/pq-2024/ should be a good read (although it's not necessarily the page I was looking for)
[20:00] <liushuyu> Hi, can someone take a look at https://code.launchpad.net/~liushuyu-011/ubuntu/+source/nut/+git/nut/+merge/479590? Thanks!
=== lionel6205 is now known as lionel620