| 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:13 |
| 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:17 |
| cjwatson | Skia: right :) | 09:19 |
| 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:40 |
| cjwatson | guruprasad: Conceptually a bit similar! Though much simpler | 09:43 |
| toabctl | Skia, could you make the bzr branch of merge-o-matic emtpy so others do not run into the same mistake? | 12:51 |
| 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:18 |
| toabctl | ah. ok. thx | 13:19 |
| === mfo_ is now known as mfo | ||
| 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:02 |
| tsimonq2 | (I've taught myself the basics of quantum mechanics recently so this is more of a hobby-based question, to be honest.) | 17:03 |
| === matttbe1 is now known as matttbe | ||
| 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:24 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| tsimonq2 | Skia: Ah okay, got it :) | 17:44 |
| tsimonq2 | liushuyu: Any chance you could rebase your changes on the NMU? | 17:44 |
| tsimonq2 | https://tracker.debian.org/news/1604414/accepted-ruby33-336-11-source-into-unstable/ | 17:45 |
| liushuyu | tsimonq2: Will do | 18:10 |
| liushuyu | tsimonq2: Done now. So this new NMU dropped another Ubuntu delta, nothing else | 18:18 |
| tsimonq2 | liushuyu: Precisely. Thanks, looking again :) | 18:26 |
| 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:28 |
| 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:29 |
| tsimonq2 | ...which I touched last. Nice. :P | 18:30 |
| tsimonq2 | Okay, no objection, uploading. | 18:30 |
| 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:31 |
| tsimonq2 | liushuyu: Meh that's fine, just make sure Debian has it if they need it :) | 18:32 |
| 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:33 | |
| 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:34 |
| tsimonq2 | Ah, okay. That makes sense. | 18:35 |
| tsimonq2 | liushuyu: https://launchpad.net/ubuntu/+source/ruby3.3/3.3.6-1.1ubuntu1 | 18:35 |
| tsimonq2 | Skia, paride: hi yes many autopkgtests incoming ;) https://launchpad.net/ubuntu/+source/ruby3.3/3.3.6-1.1ubuntu1 | 18:36 |
| liushuyu | tsimonq2: Thanks! MRI Ruby C code quality is quite questionable, but eh, we can't do a lot about that | 18:37 |
| tsimonq2 | liushuyu: heh fair enough :) | 18:38 |
| liushuyu | Do we have a general policy for adding extra dependencies for Debian/Ubuntu packages? | 18:39 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:49 |
| liushuyu | tsimonq2: Yes, the newer version also bundles a megaton of minified JavaScript libraries | 18:50 |
| tsimonq2 | boo. | 18:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| tsimonq2 | Oh yeah. We have a few of those internally. Unfortunately I'm aware. | 18:55 |
| liushuyu | I see, so it's more widespread than I think then | 18:56 |
| tsimonq2 | Yeahp. :( | 18:57 |
| 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) | 18:58 |
| 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:00 |
| 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:02 |
| 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:04 |
| 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:05 |
| liushuyu | Sounds like I have one more excuse to enable the Rust bits in Ruby then | 19:07 |
| liushuyu | (the new JIT compiler) | 19:08 |
| tsimonq2 | :)) | 19:08 |
| 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) | 19:47 |
| liushuyu | Hi, can someone take a look at https://code.launchpad.net/~liushuyu-011/ubuntu/+source/nut/+git/nut/+merge/479590? Thanks! | 20:00 |
| === lionel6205 is now known as lionel620 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!