[05:02] <pitti> Good morning
[05:30] <tjaalton> Unknown release wily
[05:30] <tjaalton> wth?
[05:31] <tjaalton> trying to upload
[05:31] <wgrant> tjaalton: What said that?
[05:31] <tjaalton> dput
[05:31] <tjaalton> -ng
[05:32] <wgrant> Sounds like out of date distro-info-data or similar.
[05:32] <tjaalton> yeah, upgrading
[08:14] <pitti> infinity: hey! do you happen to remember historic reasons why "mount" is split from util-linux?
[08:14] <pitti> infinity: just because of the any vs. linux-any arch:, or something else?
[08:14] <infinity> pitti: No idea.  You'd have to ask lamont.  Or maybe whoever maintained it before lamont.
[08:15] <pitti> infinity: thanks
[08:15] <infinity> pitti: Given that they're both required/essential, it does seem a bit silly, but is it causing harm?
[08:16] <pitti> infinity: ah was considering to merge them, as the split seems unnecessary, and it's making it easier to move stuff around like 'mountpoint' without having to NMU sysvinit again
[08:16] <pitti> infinity: so it's more like a "can we clean this up?" question, not really harmful
[08:17] <infinity> pitti: That statement didn't make much sense to me.  Oh, as in, moving mountpoint from X to Y and having to update a Breaks or Depends in sysvinit?
[08:17] <pitti> right
[08:17] <infinity> Yeah, mountpoint should be in util-linux, not mount.
[08:17] <pitti> infinity: ah, don't get too confused by that; having to update the Breaks: was mostly just what triggered the question why they need to be split in the first place
[08:18] <infinity> If I was actually participating in maintainership, I would have noticed that. :/
[08:18] <pitti> right, that's what we need to fix, to get back mountpoint for !linux
[08:18] <pitti> and while we're at it, he wondered if we shouldn't just move everythign, and make mount transitional (and then fix the ~ 5 rdepends over time)
[08:19] <infinity> pitti: The split may indeed just be about linux and non-linux.  Or maybe something more subtle.  But it also seems to do no harm to have the split, so I'm a bit "meh" about rocking that boat.
[08:20] <infinity> pitti: That said, while I have strong opinions about lots of things, I'm not sure it's worth listening to the opinion of someone who hasn't had time for util-linux in ages.
[08:27] <zyga> hmm
[08:27] <zyga> sone of the recent updates broke virtualenv -p python3 on wily
[08:27] <zyga> http://pastebin.ubuntu.com/11260203/
[08:28] <zyga> looks like it's in pip-1.5.6
[08:28]  * mgedmin wonders when ubuntu will get a more modern pip version
[08:34] <zyga> hmm
[08:35] <zyga> didrocks, barry: ^^ (virtualenv broken on wily, you are the last two uploaders of pip, any ideas?)
[08:37] <didrocks> zyga: was it broken on vivid?
[08:37] <zyga> didrocks: nope
[08:37] <zyga> didrocks: broke yesterday
[08:37] <zyga> didrocks: or so
[08:38] <zyga> didrocks: I'm on wily since day one, I don't rebuild my virtualenvs every day but I do do it often, so this broke very recently
[08:38] <didrocks> zyga: maybe python 3.5?
[08:38] <zyga> oh
[08:38] <zyga> did we get it now ^_^
[08:38]  * zyga looks
[08:39] <didrocks> seems so, yesterday at midnight
[08:39] <zyga> ah
[08:39] <zyga> I don't have python3.5 in apt yet at all
[08:39] <zyga> so probably not that
[08:39] <zyga> or maybe package uploads are out of alignment and it will fix itself with 3.5
[08:41] <zyga> didrocks: do you know if we build the wheel binaries out of the debianinzed packages or from original upstream wheels?
[08:41] <didrocks> zyga: that's a question for doko_ I guess
[08:42] <zyga> didrocks: thanks
[08:42] <didrocks> yw, let's see once he's around
[10:26] <lamont> pitti: I want to say it's just because of any vs linux-any
[10:26] <mvo> pitti: hi, just a quick (and maybe silly) question - could autopkgtest for snappy also drive real beagleboneblack with the ssh driver? I would love to have working reboot tests for this as well and wonder how realistic this is
[10:26] <lamont> which is much cleaner than the fugly mess it used to be
[10:27] <pitti> mvo: yes, should work; I've seen people run tests on a real BB in Austin
[10:28] <pitti> mvo: the one thing you need to do is to add the "--- ssh --reboot" parameter (or -r), to tell autopkgtest that it's safe to reboot the testbed (we can't assume this for everything)
[10:28] <pitti> lamont: thanks
[10:28] <mvo> pitti: nice, I will add that
[10:29] <pitti> mvo: (details @ http://www.piware.de/2015/05/autopkgtest-3-14-now-twice-as-rebooty/)
[10:30] <mvo> pitti: my other question is that I assume autopkgtest support "embeding", i.e. main autopkgtest builds the deb, runs the tests, installs the new debs into a snappy VM, then fires up a snappy VM using adt that contains the new debs and runs the selftest in the image with the new snappy)
[10:30] <mvo> pitti: cool, thanks
[10:31] <pitti> mvo: I don't understand that
[10:31] <mvo> pitti: sorry
[10:31] <pitti> mvo: how is that different from --dsc or --unbuilt-tree? that would build the debs,  install them on the testbed, and run the tests
[10:31] <mvo> pitti: maybe its not and I'm thinking too complicated :)
[10:31] <pitti> mvo: that's assuming --setup-commands 'mount -o remount,rw /' of course (IOW, cheating)
[10:32] <pitti> mvo: but, consider that you likely can't build anything *on* snappy, you should do that outside in a proper sbuild or so
[10:33] <mvo> pitti: yeah, thats the think, I build/test outside of the snappy image, then want to run the selftest in a snappy image that contains the newly build debs
[10:33] <mvo> s/think/thing/
[10:33] <pitti> mvo: so the usual approach would be sbuild -s newsnappy.dsc; adt-run newsnappy_amd64.changes --- ssh ...
[10:33] <pitti> mvo: or, more explicitly, adt-run *.deb -B newsnappy.dsc --- ssh ...
[10:34] <pitti> running a binary .changes is the same as running all debs in it plus the tests from the .dsc in it
[10:34] <mvo> pitti: ok, thanks. I will see what I can do (after lunch :)
[10:38] <ah> lamont: thanks for the background info w.r.t mount vs util-linux.
[13:39] <cjwatson> doko: Can you have a look at what's up with gcc* on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150521-wily.html (still in progress)?  That's a test rebuild of main in scalingstack with modern sbuild.
[13:40] <pitti> cjwatson: wohoo!
[13:40] <doko> cjwatson, the gcc-4.9-* are replaced by gcc-4-9-cross, working on it
[13:41] <cjwatson> If this works out OK we should be able to move all x86 builds into scalingstack in the next week or two.
[13:43] <doko> the other one is a mismatch between an alternate b-d and what is actually used for building
[13:43] <cjwatson> doko: gcc-5?
[13:44] <cjwatson> doko: can you expand on that?
[13:45] <barry> zyga, didrocks https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785787
[13:45] <didrocks> here we go :)
[13:45] <zyga> barry: thanks!
[13:47] <doko> cjwatson, gnat-5 gets installed, but gcc is called. should be gnatgcc-5 or gcc-5
[13:48] <cjwatson> doko: old sbuild would have done the same thing though, right?
[13:48] <cjwatson> since that's the first in a list of alternates
[13:48] <cjwatson> wgrant: shouldn't we be using --resolve-alternatives, though?  I had a mental note that we needed that for equivalence with old sbuild but missed it in review
[13:49] <doko> yeah, wondering why it showed up now, because it built before. and there is only gnat-5 in main, not gnat-4.9
[13:49] <cjwatson> wgrant: I suspect we'll see some things that are main Build-Depends: package-in-universe | package-in-main that now fail to build, but we'll see
[13:55] <cjwatson> doko: seems to be installing roughly the same build-deps, just different versions
[13:57] <cjwatson> doko: and lower parallelism because we're making different trade-offs in scalingstack, but I shouldn't have thought that would matter here
[13:57] <cjwatson> -checking for x86_64-linux-gnu-gcc... gnatgcc
[13:57] <cjwatson> +checking for x86_64-linux-gnu-gcc... gcc
[14:00] <cjwatson> doko: aha
[14:00] <cjwatson> cjwatson@pepo:~$ dpkg -c gnat-5_5.1.1-5ubuntu4_amd64.deb | grep bin/gnatgcc
[14:01] <cjwatson> lrwxrwxrwx root/root         0 2015-05-13 16:41 ./usr/bin/gnatgcc -> gcc-5
[14:01] <cjwatson> cjwatson@pepo:~$ dpkg -c gnat-5_5.1.1-6ubuntu1_amd64.deb | grep bin/gnatgcc
[14:01] <cjwatson> lrwxrwxrwx root/root         0 2015-05-19 21:13 ./usr/bin/gnatgcc-5 -> gcc-5
[14:01] <cjwatson> latter presumably more correct but do you perhaps need to take account of it in the build?
[14:02] <doko> ahh, I see. I shouldn't rename gnatgcc to gnatgcc-5 then. the gnat packages conflict anyway
[14:02] <doko> still waiting for feedback from ludovic brenta, he's very quiet recently
[14:02] <cjwatson> you'll presumably need to handle the existing name in order to build a fix :-)
[14:03] <doko> yep, or just using gcc-5
[14:12] <doko> hmm, just loged out, and after re-login, the vpn is still active?
[14:13] <xnox> yes... it's network manager
[14:13] <doko> interesting
[14:16] <xnox> doko: so stgraber runs VPNS in their own network namespace as a user-namespace container.... then the vpn is a user process as a whole.
[14:40] <cjwatson> tedg: Does the dbus-test-runner failure on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150521-wily.html mean anything to you?
[14:40]  * tedg clicks
[14:41] <cjwatson> tedg: (this is a test rebuild of main in scalingstack with modern sbuild; the main purpose is just to shake out problems related specifically to those changes before we make all of Ubuntu x86 build that way)
[14:42] <tedg> cjwatson, It looks like a timeout of shutting down dbus. Not sure why scalingstack or sbuild would effect that.
[14:43] <tedg> cjwatson, The test harness makes sure the dbus connection closes, or it times out and errors.
[14:43] <cjwatson> tedg: I can retry if you think that might help.  Is it possible that it just has an unnecessarily low timeout?
[14:43] <tedg> cjwatson, Oddly, it's failing on the easiest test case :-)
[14:43] <tedg> cjwatson, That would be my guess, but it would be kinda surprising.
[14:44] <cjwatson> tedg: The entire build only took 1.5 minutes, so the timeout can't be that long
[14:44] <tedg> It is something like 10 seconds.
[14:44] <cjwatson> (and that's including build-dep installation and such)
[14:45] <cjwatson> it's not running on dedicated hardware, so I suppose it could have been scheduled out if the nodes are overcommitted or something
[14:45] <cjwatson> retrying, scored up a bit so we get a chance to recheck soon
[14:46] <tedg> cjwatson, Great, thanks!
[15:25] <xnox> doko: i'm toying with boost here.... a no change rebuild with c++11 abi took out source-highlight with undefined symbols throughout.
[15:26] <xnox> i'll do more tests, but it seems like we will have pain with boot.
[18:12] <mrmcq2u> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1455845
[18:13] <mrmcq2u> any thoughts?
[18:19] <jamespage> please could an archive admin bump python3-greenlet to main in wily - its a binary only movement and is needed for new eventlet
[20:22] <cjwatson> jamespage: done
[20:37] <jamespage> cjwatson, ta
[23:08] <Dragonkeeper> hey guys
[23:09] <Dragonkeeper> im interested in if there is a way to install ubuntu on no standard hardware lacking a standard bios
[23:09] <Dragonkeeper> in this case a chromebook cb3-111
[23:27] <sarnold> Dragonkeeper: the iso images should do 64-bit uefi alright; 32-bit uefi may take more work
[23:29] <Dragonkeeper> sarnold: im attempting to use chrubuntu script to boot from usb + seemed my firmware wasnt in dev mode even though the OS was . so see how this goes