Unit193It's most certainly annoying enough to fix one way or another! :)00:32
tsimonq2hah :)00:32
sarnoldback to python 2 everyone!00:35
sarnoldthis silly warning was the last straw00:35
Unit193sarnold: I think it's the 124M bot or 119M daemon that do it for me. :(00:46
Unit193A bot shouldn't be using 12% of system ram. :(00:46
sarnoldUnit193: oww00:47
Unit193I'm a little worried when deluge converts to py3, how much is that going to take. :300:48
infinityUnit193: 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:19
infinityWhile 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:20
infinityUnit193: 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
infinityUnit193: 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? :P01:22
infinityWell, the libraries would be.  Maybe not the python binary itself.  But it's not huge in comparison.01:23
Unit193Heh, 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:25
Unit193infinity: As far as bug reports, both things are mostly unmaintained, so I'm out of luck there.  Thanks for considering it though!01:28
infinityUnit193: 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
infinityfail2ban 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:29
infinity(Though, I think a fail2ban rewrite in a compiled language is long overdue, personally)01:30
Unit193Nah, it's a 2K line daemon with a lot of baggage.01:30
infinityMaybe a good "My first Rust/Go/C/C++/whatever project" for someone.01:31
Unit193Yes, I'd agree there..01:31
Unit193Though rusty things are somewhat annoying to package..01:31
tsimonq2Unit193: Pun intended, I hope. :P01:31
sarnoldoh man. a rust rewrite of fail2ban would be nice.01:31
infinityRust and Go can get nasty if you involve half the ecosystem.01:31
infinityfail2ban 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-101:32
Unit193What 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:33
infinityUnit193: The golang/github development workflow is actively hostile to people who like stable interfaces, yes.  I've never been a fan.01:39
infinityI 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.01:39
Unit193infinity: 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:39
infinityUnit193: Excluding upstream changelogs isn't about compressed package size, it's about pointless junk on the installed system.10:51
infinityUnit193: Same reason we trim everything but the first 10 Debian changelog entries.10:51
Unit193I 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.10:53
=== Wryhder is now known as Lucas_Gray
adrian15Can anyone with Secure Boot enabled run: "mokutil --sb-state" and share with me its output ?13:37
tsimonq2slashd: 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
ubottubug 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/180338518:21
tsimonq2slashd: I'm not entirely comfortable touching the debian-installer stack, otherwise I would look myself.18:22
tsimonq2Laney: 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
ubottubug 1763520 in gtk+3.0 (Ubuntu Cosmic) "after upgrade to bionic, printing fails without explanation / logs / debuggability" [High,In progress] https://launchpad.net/bugs/176352018:34
tsimonq2juliank: Hi, did you plan on sponsoring bug 1762572?19:02
ubottubug 1762572 in dput (Ubuntu) "sftp method no longer uses temporary file name during upload" [Low,Triaged] https://launchpad.net/bugs/176257219:02
alkisgHi 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
alkisgThe 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
ubottuLaunchpad bug 1811496 in ipxe (Ubuntu) "Make grub-ipxe work under UEFI" [Medium,New] https://launchpad.net/bugs/181149619:16
tsimonq2Hi alkisg! Looking again.19:18
alkisgThank you tsimonq219:18
alkisgThe 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 instead19:21
tsimonq2alkisg: 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 sponsoring19:22
tsimonq2(unless he would like to do it).19:23
tsimonq2s/ another//19:23
tsimonq2(You get my point :) )19:23
alkisgtsimonq2: 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
alkisgso my question was mostly directed to him; ...well, unless it's possible for debdiffs to get approved otherwise... dunno19:24
alkisgThis package is ubuntu-only, not in debian, so I'm not sure of the correct procedure...19:26
tsimonq2alkisg: 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
alkisgI'm not19:26
tsimonq2Right, so I defer to ahasenack.19:26
alkisgI think that everyone agrees that the fix is fine, but noone is interested in pushing it19:26
alkisgahasenack hasn't provided any input in the last months...19:26
tsimonq2As for the actual fix, you're looking at a use case for UEFI-without-secureboot only, correct?19:27
alkisg(hmmm apt changelog doesn't show ahasenack; I'm not sure if he's involved directly in that package)19:28
tsimonq2Okay, 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:28
alkisgtsimonq2: the change is in the grub-ipxe binary package, which is build from the ipxe source package; so only ipxe is involved19:29
alkisgipxe does ship an /etc/grub.d/ script, but the grub source package isn't involved in the fix19:29
tsimonq2The 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:29
tsimonq2Oh, that makes sense, okay.19:30
alkisgBut grub isn't involved...19:30
tsimonq2I am simply stating the rationale on the bug report for him being involved in the first place. :)19:30
tsimonq2Anyway, please attach a debdiff to the bug report.19:30
alkisgThank you; will do it on Monday morning from work19:31
alkisgI also add a small "feature" there; I'm not looking for any SRUs/backports, hope that's ok to go in a singe debdiff19:31
alkisgThe feature is that in the BIOS case, ipxe supports loading an ipxe script as initrd; it's just one line19:31
tsimonq2Yeah, 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
alkisgThanks again!19:33
tsimonq2No problem. :)19:33
* tsimonq2 finds some lunch before working on the sponsorship queue some more...19:35
tsimonq2@pilot in19:56
=== 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
tsimonq2There we go.19:56
julianktsimonq2: yes, but it seems I frogot ,will add it to my list20:50
tsimonq2juliank: Thanks!20:50
tsimonq2sarnold: Hi, did you plan on following up on bug 1821811?20:59
ubottubug 1821811 in flatpak (Ubuntu Cosmic) "New upstream microrelease flatpak 1.0.8" [Low,New] https://launchpad.net/bugs/182181120:59
Unit193tsimonq2: Since you seem to be patch pilot, you should merge debhelper. :>21:37
tsimonq2Unit193: I wanted to get all the way to the bottom of the sponsors queue first. ;)21:37
tsimonq2But, sure.21:37
tsimonq2I also have yet to file a bug against debootstrap in Debian for my earlier upload.21:38
tsimonq2TIL Japan is starting a new era... https://japan.kantei.go.jp/98_abe/statement/201904/_00001.html21:38
tsimonq2Unit193: Is debhelper the only one you see? :P21:39
tsimonq2The only package you'd like merged.21:41
tsimonq2gusnan: 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
ubottubug 1804865 in scite (Ubuntu Bionic) "Lua dynamic libraries isn't enabled" [Low,New] https://launchpad.net/bugs/180486521:42
Unit193I don't think there's anything else in Main, nope.21:43
Unit193(gandi-cli requires 12.1, I merged it in a PPA for a disco build then backported it as well.)21:44
tsimonq2Ahh, got it.21:44
tsimonq2Yeah, probably a good idea before Adam flicks on the autosyncer. :P21:45
tsimonq2Unit193: I want to send an email to ubuntu-devel first detailing where we're at with the sponsorship queue.21:46
tsimonq2Meaning, it'll be a bit. :P21:47
Unit193https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/10042159/+listing-archive-extra fwiw.21:48
tsimonq2Looking at devscripts now,22:13
tsimonq2Er, debhelper.22:13
Unit193I'm going to presume there's no progress on backports?  I have a dh 12 ready for that too.22:13
tsimonq2Not that I know of. :(22:13
Unit193I guess that's what PPAs are for.22:15
tsimonq2Unit193: debhelper> .22:20
tsimonq2And with that...22:26
tsimonq2@pilot out22:26
=== 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:
tsimonq2Off to get some fresh air or something.22:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!