[00:04] <nacc> gsilvapt: no, i just was wondering
[00:04]  * gsilvapt *breathers in reliefP
[08:11] <bdrung_work> hi bdmurray. i converted apport to git and pushed my changes to https://code.launchpad.net/~bdrung/apport/+git/retrace-debian
[09:19] <Unit193> mdeslaur: Howdy!  Just saw the Irssi merge, quick note:  use_ssl = "yes"  is the "old" name, it's  use_tls = "yes"  now (also seems you didn't keep/add  tls_verify = "yes")
[09:19] <Unit193> (I'll close LP 1685561)
[09:37] <rbasak> jbicha: did you get "Import problem - Spanish (es) - gnome-settings-daemon in Ubuntu Zesty" or was that email misdirected only to me?
[10:09] <jbicha> rbasak: wow, no I didn't get that email this time
[10:11] <jbicha> the Spanish translation contributor has a bug in his translation tool where it messes up the header sometimes, I'm pushing the fix upstream now
[10:13] <rbasak> jbicha: thanks. I think that's a shortcoming in Launchpad for SRUs. It's not a problem; I just wanted to pass it on. Do you need the actual email? It has more details.
[10:13] <rbasak> (well it might be a problem that you care about but there's little I can do about it now :-)
[10:16] <jbicha> no, I already corrected the header in GNOME
[10:17] <rbasak> OK thanks
[10:17] <jbicha> someone that's really bored could go look up all the Spanish translations across GNOME to make sure it's fixed :|
[10:23] <doko> ricotz: cmake hangs in -proposed ...
[10:35] <infinity> juliank: Weekly reminder that test-apt-download-progress still sucks.
[10:35] <infinity> doko: https://bugs.launchpad.net/ubuntu/+source/rhash/+bug/1688298
[10:38] <Unit193> rhash?  Huh.
[11:04] <xnox> juergh, nice =)
[11:10] <mdeslaur> Unit193: oh! I didn't notice that at all...did you fix it?
[11:12] <ricotz> doko, why? missing "cmake-modules" rebuilds?
[11:13] <infinity> ricotz: No, the rhash MIR, see above.
[11:14] <ricotz> oh, I see :(
[11:15] <ricotz> LocutusOfBorg, thanks ^
[11:16] <juliank> infinity: Oh true, it's failing an awful lot of times on armhf since after 1.4.1. new machines?
[11:16] <infinity> juliank: Nope.
[11:16] <juliank> But it's kind of odd that it consistently fails since a week, and worked the first 3 weeks of april
[11:17] <infinity> juliank: But it always sucked, maybe we just had a lucky run for a bi?
[11:17] <infinity> s/bi/bit/
[11:17] <juliank> Well, probably
[11:17] <infinity> juliank: http://autopkgtest.ubuntu.com/packages/apt/zesty/armhf paints a more erratic picture.
[11:17] <juliank> I gotta add some sleep() in our testing web server
[11:18] <juliank> (If I rate limit the web server, apt will eventually show some download progress...)
[11:19] <juliank> damn it. stupid close tab key binding
[11:19] <infinity> juliank: It comes with an appropriate /part message.
[11:19] <infinity> 05:18 -!- juliank [vf03RlAbiP@ubuntu/member/juliank] has left #ubuntu-devel ["that was probably by accident"]
[11:19] <LocutusOfBorg> ricotz, yw :)
[11:20] <infinity> juliank: Custom job, or does your IRC client just know you that well?
[11:20] <juliank> infinity: Yep, I set this up at some point, because I really only leave channels by accident usually
[11:20] <infinity> Heh.
[11:22] <infinity> juliank: As for the oddness of the pattern, it probably relates to load.
[11:23] <juliank> Yes. The more load, the better basically
[11:23] <infinity> juliank: Since armhf autopkgtests are lxc containers on a shared host.
[11:23] <infinity> juliank: I was assuming the inverse, given the pattern.  The last week, the infra has been running flat out.
[11:23] <juliank> hmm
[11:23] <juliank> maybe
[11:24] <juliank> The problem is that we are trying to rate limit transfers in the client, which does not really work if the server sends all data basically at once.
[11:24] <infinity> So send it one byte at a time? :)
[11:24] <juliank> That's why slowing down the server instead should work and give us reliable progress detection
[11:25] <infinity> But yes, under high load, I would expect the "server" process to still be near instant, while the client would be more likely to hitch up, as it's much more complex code.
[11:25] <infinity> Given that your server is probably a few lines of "open a socket and dump stuff in it".
[11:29] <juliank> The server is even advanced enough to send a directory listing!
[11:30] <infinity> A dynamic one, or did you just screenscrape a mod_dir index and send that html? :P
[11:30] <mdeslaur> Unit193: ah crud, I didn't see your merge bug either...sorry :(
[11:30] <infinity> (And if it's the former, dear god, why not the latter?)
[11:30] <mdeslaur> Unit193: I'll fix the tls option
[11:30] <juliank> infinity: It actually builds a real html directory listing
[11:30] <infinity> juliank: Those are hours you'll never get back.
[11:31] <juliank> It also handles basic auth
[11:31] <infinity> I don't think you quite grasp the concept of mocking. ;)
[11:31] <Laney> Release it separately
[11:31] <Laney> I'll use it
[11:32] <infinity> Laney: Well, by all accounts, it's the fastest httpd on the planet, which is why the testsuite fails.
[11:32] <infinity> Laney: So, yeah, we should all switch.
[11:32] <juliank> infinity: DonKult wrote it in 2013+, and it's about 1000 lines long
[11:32] <juliank> And it uses C++ threads, apparently
[11:33] <juliank> fancy
[11:33] <juliank> https://anonscm.debian.org/cgit/apt/apt.git/tree/test/interactive-helper/aptwebserver.cc
[11:33] <juliank> Also supports chunked encoding, partial requests, if-range and some other weird crap
[11:34] <juliank> At least far enough for the tests to work...
[11:34] <juergh> xnox, ?
[11:36] <xnox> juergh, unping.
[11:36] <xnox> juergh, nice about the apt releases =)
[11:36] <xnox> juliank, ^^^^^
[11:36] <xnox> juergh, i suck at irc thing this morning
[11:36] <xnox> however it is afternoon already
[11:36] <juliank> xnox: I wonder if I want to set up new 1.3 and 1.2 for zesty and xenial today (in case somebody wants to play during the weekend?)
[11:37] <juliank> It's about 2 minute cherry-picking per release.
[11:38] <juliank> s/zesty/yakkety/
[11:38]  * juliank confuses releases all the time
[11:40] <xnox> juliank, yes please. =)
[11:49] <infinity> juliank: If only they were in alphabetical order or something.
[11:50] <juliank> infinity: Well, it always happens at the start of a new cycle, although this one was very weird.
[13:00] <cyphermox> cjwatson: do you recall why grub2's linuxefi_require_shim.patch was required?
[13:01] <cyphermox> right now that's breaking (to some degree) EFI boot if secure boot is enabled by shim validation is disabled, because in that case shim doesn't install its protocol... but I'm not sure what the details were that needed to be fleshed out before this patch was dropped.
[13:02] <cyphermox> (and that was 4 years ago :)
[13:07] <cjwatson> cyphermox: I think it may have been because of discussions of signing GRUB directly
[13:08] <cjwatson> cyphermox: I've found the relevant swathe of IRC log but it would take a while to parse it - can I just hand it over to you and let you work it out from the information I had available to me at the time? :)
[13:08] <cjwatson> cyphermox: this was from before shim was packaged, I think
[13:10] <cjwatson> cyphermox: https://pastebin.canonical.com/187573/ (internal pastebin because it's an unedited dump from an irc.c.c channel, but feel free to use your judgement on information gained from that since I doubt much of it remains private)
[13:10] <cyphermox> sure, no problem
[13:11] <cyphermox> that would make sense, in any case, as if you sign grub directly then you don't want it to bypass signature validation just because shim's proto doesn't exist
[13:15] <cjwatson> yeah, I don't remember if there's a way to tell whether we've been entered via shim
[13:16] <juliank> xnox: uploaded :)
[13:16] <infinity> cyphermox: Keep in mind that while discussing EFI boot protocols involving shim/grub/linux, that arm64 doesn't involve shim in the process.  So, booting grub directly is a thing we do support, though maybe not on x86.
[13:17] <cyphermox> I don't think that would break arm64 in any way
[13:17] <juliank> Or more detailed: apt 1.2.22, 1.3.7, and 1.4.2~17.04.1 are now in the xenial-proposed, yakkety-proposed, and zesty-proposed queues :)
[13:17] <infinity> cyphermox: Sure, not familiar at all with the code or the deeper discussion, just popped in my head due to the mention of direct grub booting versus chaining from shim.
[13:18] <cyphermox> cjwatson: I was thinking, in that care you'd see you have no shim protocol, and thus install your own; but I asked about why the shim protocol wasn't installed when shim's validation is disabled, seems like it stil lshould be.
[13:19] <cyphermox> infinity: yes, definitely something to look at. in this case they basically never have shim though, so the net change would be to go through kernel EFI code that might not have been called previously.
[13:22] <cyphermox> basically, they're most likely, right now, getting in the case that sforshee was seeing before, where there is no shim protocol installed in EFI, so grub doesn't start the kernel as an EFI binary
[13:23] <juliank> The binutils SRU for trusty also aged enough now, and is good to go in (to both -updates and -security)
[13:23] <cyphermox> ... because ..._secure_validate() fails, so we exit the linuxefi module and use linux instead.
[13:23] <infinity> juliank: Except we don't release SRUs on Fridays.
[13:23] <juliank> Ah, yes, it's Friday.
[13:23] <juliank> I forget week days :)
[13:24] <infinity> juliank: Ahh, student life.
[13:50] <infinity> tjaalton: Is xserver-xorg Recommending xserver-xorg-legacy intentional or an accident?
[13:57] <tjaalton> infinity: intentional, useful for ubuntu-gnome on virtualbox, for instance
[13:58] <tjaalton> it was added for stretch
[13:59] <jbicha> to be more specific, I don't think Ubuntu needs that for VBox but Debian does
[13:59] <infinity> tjaalton: It's already in the ubuntu-gnome-desktop task anyway.  Was just curious to see it getting pulled in for !gnome when it's not been there since before xenial.
[13:59] <tjaalton> jbicha: right, the metapackage pulls it already
[14:00] <jbicha> it was only added to gnome-shell/ubuntu-gnome-desktop as a workaround since fixing the nvidia drivers was taking a very long time
[14:00] <jbicha> https://github.com/tseliot/nvidia-graphics-drivers/pull/10
[14:00] <tjaalton> it does no harm anyway
[14:01] <tseliot> jbicha: I included your change in my local branch, BTW. I'm going to upload it with 375.66
[14:01] <infinity> jbicha: You could have spoofed me as the committer on that prime commit. :P
[14:02] <jbicha> next time :)
[14:03] <jbicha> (I believe Ubuntu has basic vbox support drivers included in default install but Debian does not)
[14:38] <juliank> Oh, if anyone wants the apt SRUs *now*, they're in the PPA: https://launchpad.net/~deity/+archive/ubuntu/apt
[14:52] <LocutusOfBorg> jbicha, while this is true, that legacy package is still the "safer" option, at least until vbox people upstream their patches into the official drivers
[14:52] <LocutusOfBorg> IIRC I got some issues also on non-gnome environments
[14:55] <juliank> I'm trying to setup a daily recipe for lp:apt (git), but it always sets up one for lp:apt (bzr)
[14:55] <juliank> That's insane.
[14:55] <LocutusOfBorg> juliank, same issue :(
[14:55] <LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/+recipe/boinc-upstream-daily
[14:56] <cjwatson> juliank,LocutusOfBorg: workaround in https://bugs.launchpad.net/launchpad/+bug/1623924
[14:57] <juliank> LocutusOfBorg: I now used lp:~deity/apt/+git/apt instead of lp:apt, that might work
[14:58] <juliank> cjwatson: Emptying the bazaar link seems like a good idea, too, thanks. I wanted to delete the bzr import, but it did not let me "1 branch share..."
[14:58] <cjwatson> Yeah, sharing is awkward.
[14:59] <juliank> I'm currently thinking about creating a new PPA where I just continously build all branches for their respective releases.
[15:00] <juliank> So you get daily 1.2 builds for xenial, daily 1.3 for yakkety, and daily 1.4 for zesty and artful
[15:00] <LocutusOfBorg> how do I create a new git repo? I need to merge the debian directory into the upstream git
[15:12] <mapreri> LocutusOfBorg: RTFM => https://help.launchpad.net/Code/Git
[15:12] <mapreri> ♥
[15:12] <juliank> a very friendly manual
[15:13] <mapreri> yeah, it's so nice and colourful!
[15:39] <LocutusOfBorg> thanks!
[15:39] <LocutusOfBorg> I was expecting a "create new git repo" on the code page
[16:51] <nacc> coreycb: ping
[16:51] <coreycb> nacc: hi
[16:52] <nacc> re: LP: #1605278, i've got maas buy-in to merge with django 1.11 (which is an LTS) and is in experimental. Would you like a PPA to test against for openstack?
[16:53] <coreycb> nacc: yes that would be good if we could get some testing with that before it gets uploaded.  thanks.
[16:53] <nacc> coreycb: ok, i'll update the ppa in the bug shortly
[16:54] <nacc> coreycb: thanks for the quick feedback!
[18:01] <nacc> xnox: does runit in 16.04 need a patch to not call it's postinst's /sbin/start runsvdir? someone in #ubuntu just got https://pastebin.com/raw/MyaBbBcL (ignore the ppa for couchdb)
[18:02] <nacc> xnox: it seems like that should never be used on 16.04, right? but if it's there (which i think it might be by default for the session manager on desktop?) then it will fail to start the upstart service and error out?
[18:03] <xnox> nacc, are they upgrading, and have they rebooted?
[18:03] <nacc> xnox: they said it was a fresh install
[18:04] <nacc> xnox: i was going to spin up a vm to see if i can reproduce
[18:05] <xnox> nacc, well..... checkout my last upload, maybe i need to SRU that to xenial.
[18:05] <nacc> xnox: yep, that's why i asked you specifically :)
[18:05] <xnox> nacc, what other packages do they have installed?
[19:18] <hjd> nacc xnox: That sounds like bug 1448164...
[19:20] <xnox> 232 affected people, that is hot
[19:20] <nacc> hjd: ack it does appear to be
[19:20] <sarnold> I thought I'd seen runit installed on a surprising number of machines; git-all dragging it in suddenly it makes sense
[19:21] <nacc> hjd: but honestly, afaict, isn't the sru-able portion just the postinst bits?
[19:21] <nacc> afaict, we don't want to talk to upstart in the postinst on 16.04, even if upstart's bins are present
[19:29] <hjd> nacc: I have to admit I don't know. I asked in one of the comments if it was SRU-able because I wasn't really sure what fixed it or how deep it went.
[19:30] <hjd> *exactly what
[19:50] <greenbard> does anybody know whether UBUNTU_MENUPROXY=0 does not work anymore with Ubuntu 17.04 on purpose?
[19:56] <s1aden> greenbard: if it doesn't do what you expect.  Please file a bug
[19:58] <greenbard> It doesn't do anything on a cleanly installed Ubuntu 17.04. I just wanted to ask, since I do not use Ubuntu myself and have a bug report myself ;-)
[19:59] <sarnold> :)
[19:59] <greenbard> Thanks
[20:02] <Unit193> mdeslaur: Thanks, and no problem.  In theory the option should be backwards compatible, but perhaps a bit pointless without -verify.
[20:03] <mdeslaur> Unit193: thanks for pointing it out, I uploaded it
[20:04] <Unit193> Of course, thanks for the upload.
[20:46] <nacc> hjd: ack, i am not sure either