[00:32] <Unit193> It's most certainly annoying enough to fix one way or another! :)
[00:32] <tsimonq2> hah :)
[00:35] <sarnold> back to python 2 everyone!
[00:35] <sarnold> this silly warning was the last straw
[00:35] <tsimonq2> hahahahaha
[00:46] <Unit193> sarnold: I think it's the 124M bot or 119M daemon that do it for me. :(
[00:46] <Unit193> A bot shouldn't be using 12% of system ram. :(
[00:47] <sarnold> Unit193: oww
[00:48] <Unit193> I'm a little worried when deluge converts to py3, how much is that going to take. :3
[01:19] <infinity> Unit193: python has never been known for its efficient RAM usage, especially for long-running processes, but if you've noticed something getting drastically worse between 2.7 and 3.x, Ubuntu, Debian, and/or Python upstream might not mind a bug with some investigation.
[01:20] <infinity> While some in-memory structures may have grown here and there (for, say, better charset handling), I'd expect things to be about the same, ish, unless you're tripping on a memory leak or really, really lazy garbage collection.
[01:22] <infinity> Unit193: Unless you're just talking about the size of the interpreter itself, not how much it uses beyond initial binary/library mapping.  That might be something we can't do much about.
[01:22] <infinity> Unit193: But at least you can relax a little knowing that most of those python (and library) copies in RAM are all pointing at the same location in memory, rather than 32 copies? :P
[01:23] <infinity> Well, the libraries would be.  Maybe not the python binary itself.  But it's not huge in comparison.
[01:25] <Unit193> Heh, yeah I'm trying to move everything over to py3 anyway, but several of the daemons are just memory intensive.  I'm pretty sure it's due to lack of code optimization on the specific things (fail2ban and irker are *very* small, still.)
[01:28] <Unit193> infinity: As far as bug reports, both things are mostly unmaintained, so I'm out of luck there.  Thanks for considering it though!
[01:29] <infinity> Unit193: I didn't mean bug reports on the applications, I meant on python itself, if you're finding that converting simple daemons leads to awful results.
[01:29] <infinity> fail2ban is a perfect example.  While maybe they could pack their data better or something, there's really not much it juggles in memory to start with, so if a naive conversion is making its usage explode, that seems suboptimal.
[01:30] <infinity> (Though, I think a fail2ban rewrite in a compiled language is long overdue, personally)
[01:30] <Unit193> Nah, it's a 2K line daemon with a lot of baggage.
[01:31] <infinity> Maybe a good "My first Rust/Go/C/C++/whatever project" for someone.
[01:31] <Unit193> Yes, I'd agree there..
[01:31] <Unit193> Though rusty things are somewhat annoying to package..
[01:31] <tsimonq2> Unit193: Pun intended, I hope. :P
[01:31] <sarnold> oh man. a rust rewrite of fail2ban would be nice.
[01:31] <infinity> Rust and Go can get nasty if you involve half the ecosystem.
[01:32] <infinity> fail2ban is so simple that you could probably write it with nothing but a stdlib dependency.
[01:32] <tsimonq2> "involve half the ecosystem" did someone say node.js? http://devhumor.com/media/node-modules-1
[01:33] <Unit193> What mostly annoys me about golang is that libs don't have releases, and they have breaking changes between git commits such that the applications which *do* have releases depend on a specific commit. >_<
[01:39] <infinity> Unit193: The golang/github development workflow is actively hostile to people who like stable interfaces, yes.  I've never been a fan.
[01:39] <infinity> I mean, fine, "kids these days" have to re-learn lessons of the previous generation the hard way, but they seem to be taking their sweet time with it.
[10:39] <Unit193> infinity: Given that ISOs can seed whole stacks of software in squashfs (snaps) and that packages use xz by default, is there really any reason for debhelper to have the delta to exclude upstream changelogs at this point?
[10:51] <infinity> Unit193: Excluding upstream changelogs isn't about compressed package size, it's about pointless junk on the installed system.
[10:51] <infinity> Unit193: Same reason we trim everything but the first 10 Debian changelog entries.
[10:53] <Unit193> I wouldn't say they're pointless, but alright.  I got the impression it was somehow from back when people were trying to keep it CD sized.
=== Wryhder is now known as Lucas_Gray
[13:37] <adrian15> Can anyone with Secure Boot enabled run: "mokutil --sb-state" and share with me its output ?
[18:21] <tsimonq2> slashd: Hi, did you plan on taking another look at bug 1803385? I'm going through the sponsoring queue and saw it was last updated in November.
[18:21] <ubottu> bug 1803385 in debian-installer-utils (Ubuntu Cosmic) "fetch-url does not use --no-check-certificate on HTTP to HTTPS redirects" [Medium,In progress] https://launchpad.net/bugs/1803385
[18:22] <tsimonq2> slashd: I'm not entirely comfortable touching the debian-installer stack, otherwise I would look myself.
[18:34] <tsimonq2> Laney: Hi, did you plan on sponsoring bug 1763520 to Bionic and Cosmic as well, or did you want to roll it in with some other fixes?
[18:34] <ubottu> bug 1763520 in gtk+3.0 (Ubuntu Cosmic) "after upgrade to bionic, printing fails without explanation / logs / debuggability" [High,In progress] https://launchpad.net/bugs/1763520
[19:02] <tsimonq2> juliank: Hi, did you plan on sponsoring bug 1762572?
[19:02] <ubottu> bug 1762572 in dput (Ubuntu) "sftp method no longer uses temporary file name during upload" [Low,Triaged] https://launchpad.net/bugs/1762572
[19:16] <alkisg> Hi guys, I'm at a loss concerning LP bug 1811496. I proposed a bug fix, ahasenack seemed interested, then the chat with vorlon  there got sidetracked to UEFI secure boot, and finally tsimonq2 just now unsubscribed the Sponsors team as there are no debdiffs.
[19:16] <alkisg> The bug is still there, and my fix fixes it. My question is, should I provide a debdiff, or will the effort be in vain for some reason I didn't understand?
[19:16] <ubottu> Launchpad bug 1811496 in ipxe (Ubuntu) "Make grub-ipxe work under UEFI" [Medium,New] https://launchpad.net/bugs/1811496
[19:18] <tsimonq2> Hi alkisg! Looking again.
[19:18] <alkisg> Thank you tsimonq2
[19:21] <alkisg> The short story is that under uefi, the grub-ipxe package tries to load ipxe.lkrn whichis a linux16 binary, so the PC fails to boot with an error; and a small shell script change makes it load the correct ipxe.efi instead
[19:22] <tsimonq2> alkisg: I was looking at this purely from the perspective of the Ubuntu Sponsors Team; there is no debdiff to sponsor, and thus, the Ubuntu Sponsors Team shouldn't be subscribed (it shouldn't be in our queue). If you attach another debdiff, the Ubuntu Sponsors Team can take a look. That being said, I was not personally working on this, and I would like another look from vorlon before sponsoring
[19:23] <tsimonq2> (unless he would like to do it).
[19:23] <tsimonq2> s/ another//
[19:23] <tsimonq2> (You get my point :) )
[19:24] <alkisg> tsimonq2: I understand; and AFAIK vorlon doesn't object for the patch and leaves it up to the maintainer, which I believe is ahasenack,
[19:24] <alkisg> so my question was mostly directed to him; ...well, unless it's possible for debdiffs to get approved otherwise... dunno
[19:26] <alkisg> This package is ubuntu-only, not in debian, so I'm not sure of the correct procedure...
[19:26] <tsimonq2> alkisg: I have the technical ability to sponsor your debdiff as an Ubuntu Core Developer, but if you already are discussing it with other Ubuntu Developers, I don't want to step in and sponsor something first.
[19:26] <alkisg> I'm not
[19:26] <tsimonq2> Right, so I defer to ahasenack.
[19:26] <alkisg> I think that everyone agrees that the fix is fine, but noone is interested in pushing it
[19:26] <alkisg> ahasenack hasn't provided any input in the last months...
[19:27] <tsimonq2> As for the actual fix, you're looking at a use case for UEFI-without-secureboot only, correct?
[19:27] <alkisg> Right
[19:28] <alkisg> (hmmm apt changelog doesn't show ahasenack; I'm not sure if he's involved directly in that package)
[19:28] <tsimonq2> Okay, so to be clear, is this change needed in the configuration for GRUB, or in ipxe itself? The bug is against ipxe but the description only mentions GRUB configuration files.
[19:29] <alkisg> tsimonq2: the change is in the grub-ipxe binary package, which is build from the ipxe source package; so only ipxe is involved
[19:29] <alkisg> ipxe does ship an /etc/grub.d/ script, but the grub source package isn't involved in the fix
[19:29] <tsimonq2> The package is in Main, and the Ubuntu Server Team is responsible for it. He wears a hat there, so that's where he fits. Steve is a member of Foundations, which is responsible for GRUB.
[19:30] <tsimonq2> Oh, that makes sense, okay.
[19:30] <alkisg> But grub isn't involved...
[19:30] <tsimonq2> I am simply stating the rationale on the bug report for him being involved in the first place. :)
[19:30] <alkisg> OK
[19:30] <tsimonq2> Anyway, please attach a debdiff to the bug report.
[19:31] <alkisg> Thank you; will do it on Monday morning from work
[19:31] <tsimonq2> Thanks!
[19:31] <alkisg> I also add a small "feature" there; I'm not looking for any SRUs/backports, hope that's ok to go in a singe debdiff
[19:31] <alkisg> The feature is that in the BIOS case, ipxe supports loading an ipxe script as initrd; it's just one line
[19:33] <tsimonq2> Yeah, sure. As long as you have a rationale on the bug report/in the patch description/in the changelog, and that rationale can be understood, if it's just going to the development release (which should open Soon), I don't see a problem with it.
[19:33] <alkisg> Great
[19:33] <alkisg> Thanks again!
[19:33] <tsimonq2> No problem. :)
[19:35]  * tsimonq2 finds some lunch before working on the sponsorship queue some more...
[19:56] <tsimonq2> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: FF, DIF | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots: tsimonq2
[19:56] <tsimonq2> There we go.
[20:50] <juliank> tsimonq2: yes, but it seems I frogot ,will add it to my list
[20:50] <tsimonq2> juliank: Thanks!
[20:59] <tsimonq2> sarnold: Hi, did you plan on following up on bug 1821811?
[20:59] <ubottu> bug 1821811 in flatpak (Ubuntu Cosmic) "New upstream microrelease flatpak 1.0.8" [Low,New] https://launchpad.net/bugs/1821811
[21:37] <Unit193> tsimonq2: Since you seem to be patch pilot, you should merge debhelper. :>
[21:37] <tsimonq2> Unit193: I wanted to get all the way to the bottom of the sponsors queue first. ;)
[21:37] <tsimonq2> But, sure.
[21:38] <tsimonq2> I also have yet to file a bug against debootstrap in Debian for my earlier upload.
[21:38] <tsimonq2> TIL Japan is starting a new era... https://japan.kantei.go.jp/98_abe/statement/201904/_00001.html
[21:39] <tsimonq2> Unit193: Is debhelper the only one you see? :P
[21:41] <Unit193> Pardon?
[21:41] <tsimonq2> The only package you'd like merged.
[21:42] <tsimonq2> gusnan: Hi, thanks for the quick turnaround on bug 1804865! I'll go ahead and sponsor it, but could you please add a [Regression Potential] section in the bug report description?
[21:42] <ubottu> bug 1804865 in scite (Ubuntu Bionic) "Lua dynamic libraries isn't enabled" [Low,New] https://launchpad.net/bugs/1804865
[21:43] <Unit193> I don't think there's anything else in Main, nope.
[21:43] <tsimonq2> Cool.
[21:44] <Unit193> (gandi-cli requires 12.1, I merged it in a PPA for a disco build then backported it as well.)
[21:44] <tsimonq2> Ahh, got it.
[21:45] <tsimonq2> Yeah, probably a good idea before Adam flicks on the autosyncer. :P
[21:46] <tsimonq2> Unit193: I want to send an email to ubuntu-devel first detailing where we're at with the sponsorship queue.
[21:47] <Unit193> OK?
[21:47] <tsimonq2> Meaning, it'll be a bit. :P
[21:48] <Unit193> https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/10042159/+listing-archive-extra fwiw.
[21:48] <tsimonq2> Alright.
[22:12] <tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-April/040665.html
[22:13] <tsimonq2> Looking at devscripts now,
[22:13] <tsimonq2> s/,/./
[22:13] <tsimonq2> Er, debhelper.
[22:13] <Unit193> I'm going to presume there's no progress on backports?  I have a dh 12 ready for that too.
[22:13] <tsimonq2> Not that I know of. :(
[22:15] <Unit193> I guess that's what PPAs are for.
[22:18] <tsimonq2> heh
[22:20] <tsimonq2> Unit193: debhelper> .
[22:26] <tsimonq2> https://salsa.debian.org/installer-team/debootstrap/merge_requests/29
[22:26] <tsimonq2> And with that...
[22:26] <tsimonq2> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Archive: FF, DIF | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
[22:29] <tsimonq2> Off to get some fresh air or something.