=== sil2100_ is now known as sil2100
[11:09] <jamespage> anyone else noticed that the SRU report is not updating?  http://people.canonical.com/~ubuntu-archive/pending-sru.html
[12:21] <flocculant> Odd_Bloke: thanks :)
[12:21] <flocculant> yofel superm1 stgraber - any of you doing xenial beta 1
[12:22] <flocculant> infinity: so - any idea of who's doing the release-team bit yet?
[12:22] <knome> infinity, also, what's the status of the "base" merges? :X
[13:03] <Odd_Bloke> flocculant: :)
[13:57] <cyphermox> flocculant: you should still see both, low disk should show a screen that is titled "Sorry" and has just how much space you have and how much is needed, and no connection should have the updates checkbox disabled and a caption under it that says why
[14:02] <lotuspsychje> can some check if a package hits xenial for enyc?
[14:03] <lotuspsychje> mythtv 0.28
[14:06] <ginggs> lotuspsychje: mythtv FTBFS on some archs https://launchpad.net/ubuntu/+source/mythtv/2:0.28.0+fixes.20160217.44fd8a6-0ubuntu1
[14:06] <lotuspsychje> ginggs: thank you! enyc ^
[14:08] <apw> qmake for Qt5.2 or newer not found.
[15:35] <flocculant> cyphermox: ok - cool, not seen the no internet one - assumed there'd be something in that case :)
[15:36] <cyphermox> you did see the space one though?
[15:36]  * davmor2 shakes his fist at cyphermox dude why you make ubiquity crash?
[15:36] <cyphermox> does it crash now?
[15:37] <flocculant> cyphermox: yep - 8Gb not enough for Ubuntu :)
[15:37] <cyphermox> err, that's probably wrong
[15:38] <flocculant> seems to want 8.6Gb iirc - not often booting ubuntu image
[15:38] <cyphermox> ok.. well I'm going to have to try a few images and flavors to see
[15:38] <davmor2> cyphermox: on current with the check sum of 09bc9cec32f7cd49270f165b81390d7a  iso/daily-live/current/xenial-desktop-amd64.iso on macbook pro
[15:38] <cyphermox> ok
[15:38] <davmor2> all intel mac that is
[15:39] <cyphermox> davmor2: would need to know what the crash is. you'll file a bug?
[15:39] <davmor2> cyphermox: about to if I can get the wifi to connect
[15:45] <xnox> flocculant, if your RAM >> disk space then yes partioner does things weridly. Are you testing in a VM with a weirdly sized config?
[15:45] <xnox> davmor2, ^ ?
[15:45] <davmor2> 268699
[15:46] <xnox> bug 268699
[15:46] <ubot5> bug 268699 in Empathy "empathy crashed with SIGSEGV in tp_connection_run_until_ready()" [Critical,Fix released] https://launchpad.net/bugs/268699
[15:46] <xnox> davmor2, is that your phone number? or sudo password?
[15:46] <davmor2> xnox: no
[15:47] <davmor2> xnox: otp in the wrong window :)
[15:48] <flocculant> cyphermox xnox: possibly - vm with 2Gb ram in a 8Gb drive - anyway - my ping was really just about the change - not how much space something needs - I'd actually only have concerns if it was xubuntu :)
[15:48] <davmor2> xnox, cyphermox: bug 1548362
[15:48] <ubot5> Error: Launchpad bug 1548362 could not be found
[15:50] <davmor2> xnox, cyphermox: subscribed you both so you should have access
[15:50] <xnox> flocculant, is this a real machine or a VM? i believe swap is generated to be 1x or 2x of RAM, i can't remember, and then there is not much disk space left. we have the weird swap calculation, so do use "normal" machines, were disk drive is >> RAM.
[15:50] <xnox> davmor2, strange. upower doesn't exist anymore....
[15:50] <utlemming> could I bother a core-dev for a merge of https://code.launchpad.net/~utlemming/livecd-rootfs/v380/+merge/286806 ?
[15:50] <xnox> does it?
[15:50] <davmor2> xnox: mine is a macbook pro 2011 all intel iirc
[15:50] <flocculant> xnox: vm - so if it did 1x with the ram I give then - then leaves 6.something Gb for install
[15:51] <davmor2> might 2013 it's been a while anyway :)
[15:52] <xnox> flocculant, and the argument is that with 6GB of disk space, there is not enough space to a) ever install any additional apps b) store any documents/photos/music/files
[15:52] <xnox> flocculant, do thin provisioning/non-preallocated 20GB drive or some such, if you are testing in a VM.
[15:52] <flocculant> xnox: yea - I'm not complaining at all - this is JUST about me wanting to double check that things were supposed to be missing from ubiquity now :)
[15:53] <flocculant> I didn't want a discussion about disk sizes :)
[15:54] <xnox> flocculant, ubiquity fails to install whenever disk ~= RAM size. and it's not a bug =)
[15:54] <xnox> it has always been the case.
[15:55] <flocculant> dude - I know - you're reading too much into my comments :p
[15:56] <flocculant> I have NO idea at all - how much space ubuntu would want - I don't use it - I only ever install it to check if a bug I see is global or just xubuntu
[16:00] <davmor2> xnox, jibel, cyphermox: http://paste.ubuntu.com/15171252/
[16:09] <cyphermox> davmor2: so, clearly upower got broke
[16:10] <davmor2> cyphermox, jibel: oddly works on vm with the same image
[16:10] <cyphermox> davmor2: oh, I think I know what this is
[16:10] <cyphermox> or have an idea, anyway
[16:47] <Odd_Bloke> slangasek: Your switch to a plain rootfs broke some of our outside-of-buildds code, so I've opened https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/ext4/+merge/286809 to (partially) revert it; I've retained the hard-coding because (as you identified) building with an alternative type of rootfs doesn't make sense.
[17:12] <xnox> Odd_Bloke, slangasek is on 4 week holiday =)
[17:12] <superm1> flocculant: it's not looking good to me for mythbuntu.  mythtv 0.28 didn't make it out of proposed still, mythtv isn't building on non-x86 stuff properly, we're not really sure why but that will blcok the proposed migration
[17:14] <Odd_Bloke> xnox: Yeah, I know; I'm going to bug someone else soon. :p
[17:15] <tgm4883> superm1: isn't it specifically just arm64?
[17:15] <superm1> tgm4883: and s390x, ppc64el, powerpc
[17:15] <tgm4883> ah
[17:15] <superm1> i mean i personally don't think anyone is going to be running mythtv on anything but x86 and arm, but anyway..
[17:18] <cjwatson>     CHECK_QMAKE="qmake-qt5 /usr/lib64/qt5/bin/qmake /usr/lib/x86_64-linux-gnu/qt5/bin/qmake /usr/lib/i386-linux-gnu/qt5/bin/qmake /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake /usr/local/lib/qt5/bin/qmake $qmake"
[17:18] <cjwatson> none of those look very clever
[17:19] <cjwatson> maybe pass --qmake=/usr/bin/qmake to mythtv's configure as well as to mythplugins?
[17:20] <flocculant> superm1: thanks :)
[17:21] <superm1> cjwatson: we did some test builds on a PPA to look more into it and i want to say it tried /usr/bin/qmake and wasn't working still.  tgm4883 where is that test build?
[17:25] <superm1> tgm4883: i thought it was on ~mythbuntu/master-building but maybe teh logs got destroyed when you copied the x86 builds
[17:25] <xnox> superm1, however arm64 should kind of work. i'm poking darkness with a stick in a ppa.
[17:26] <tgm4883> looking
[17:26] <superm1> yeah the test build was trying to give some more verbosity to that error
[17:27] <cjwatson> https://launchpad.net/~mythbuntu/+archive/ubuntu/master-building/+build/9028662 exists and is a little different
[17:27] <cjwatson> found qmake at /usr/bin/qmake but version failed
[17:27] <tgm4883> https://launchpadlibrarian.net/240280457/buildlog_ubuntu-trusty-arm64.mythtv_2%3A0.29.0~master.20160218.e4fface-0ubuntu0mythbuntu3_BUILDING.txt.gz
[17:27] <tgm4883> cjwatson: yea that's the error
[17:28] <tgm4883> found qmake at /usr/bin/qmake but version failed
[17:28] <tgm4883> qmake: could not find a Qt installation of ''
[17:28] <superm1> which makes me wonder if qmake is misconfigured in the chroot?
[17:29] <cjwatson> perhaps this is a QT_DEFAULT=5 thing or whatever the syntax is
[17:29] <cjwatson> QT_SELECT=5, sorry
[17:30] <superm1> that's for when you have 4 and 5 side by side though right?  shouldn't be needed when only 5 is around?
[17:31] <cjwatson> yeah
[17:31]  * xnox is downloading all the build-deps in an s390x chroot....
[17:32] <cjwatson> looks like you're just missing some Qt-related build-dep, anyway, question is which
[17:32] <xnox> libqtmirclient1-not-ported-dev </joking>
[17:33] <xnox> (xenial-s390x)root@DEVAC02:~# QT_SELECT=5 qmake -version
[17:33] <xnox> QMake version 3.0
[17:33] <xnox> Using Qt version 5.5.1 in /usr/lib/s390x-linux-gnu
[17:33] <xnox> (xenial-s390x)root@DEVAC02:~# qmake -version
[17:33] <xnox> qmake: could not find a Qt installation of ''
[17:33] <Odd_Bloke> xnox: Speaking of bugging people, I notice that you could merge https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/ext4/+merge/286809 ^_^
[17:34] <xnox> sounds like export QT_SELECT=5 is the thing.... /me ponders what makes it work on  [x86 + armhf]
[17:34] <Odd_Bloke> xnox: (For context, we're pinned on an old version of livecd-rootfs until this happens <coercion>which will make fixing any s390x problem tricky</coercion>)
[17:35] <cjwatson> QT_SELECT=5 does indeed make a difference here
[17:35] <cjwatson> superm1: ^- I'd suggest exporting that and trying
[17:35] <tgm4883> superm1: so how do we add that to our packaging?
[17:36] <cjwatson> export QT_SELECT = 5 in debian/rules
[17:36]  * xnox ponders if our qt5 is borked somehow
[17:36] <tgm4883> that's what I figured
[17:41] <xnox> Mirv, qmake is weird. On armhf,i386,x86_64 there are two of them built "armhf" and "native", and on those arches, installing qt5-qmake "qmake -version" just works.
[17:42] <xnox> Mirv, but on all other architectures requires an export of QT_SELECT=5 to "find" the qt installation.
[17:49] <jderose> infinity: could you point me to the tools you use to build the daily/release ISOs? I'd like to build up-to-date 15.10 ISOs (desktop and server) to master System76 images from, so i can avoid any chance of USN-2900-1/CVE-2015-7547 compromising the VM during the initial update
[17:51] <infinity> jderose: Surely, you install/update on an isolated network?
[17:52] <jderose> infinity: yes, but the VM still makes network requests that get sent to the outside world. short of disabling networking, i'm not sure there's a reasonable way to work around this.
[17:52] <jderose> plus, i've always wanted to know how the ISOs are built anyway :)
[17:53] <infinity> jderose: I can point you at livecd-rootfs, live-build, cdimage, and debian-cd, but you won't like what you find (and certainly won't like it for a one-off respin) :P
[17:54] <jderose> infinity: hmm, i always hope there was just a magic button you pushed :P
[17:54] <infinity> jderose: If you ask really nicely when I'm not on VAC, though, I could be pursuaded to do a one-off daily of wily for you.
[17:54] <davmor2> jibel, cyphermox: so played with live desktop mode on hardware and vm both look okay so just that upower issue so far oh and the fact that the new store is missing from the launcher.
[17:54] <jderose> infinity: ah, didn't realize you were on vacation ATM. sorry about that, ignore me and enjoy your time off
[17:54] <infinity> jderose: That said, I'd suggest your network should just be more isolated.  Authoritative nameserver with limited outside resolution, local mirrors, etc.
[17:56] <xnox> cjwatson, superm1 - build-dependency resolution is somehow off, so on some architectures one ends up pulling in libqtcore4 which has default preset to qt4, on other architectures only qt5 is pulled in which doesn't have such a default.
[17:58] <xnox> unless i'm doing something wrong, let me try again.
[17:59] <xnox> actually i'm wrong.
[18:00] <xnox> superm1, on both amd64 and s390x qmake doesn't find any installations. It's just i guess x86/armhf configure options result in qmake not being needed at all during mythtv mythtv portion of the build.
[18:36] <xnox> cjwatson, superm1 - ok found it. Mythtv plugins are funky and did tricks behind our back with iterating:
[18:36] <xnox> if [ x"$qmake" = "xqmake" ]; then
[18:36] <xnox>     CHECK_QMAKE="qmake-qt5 /usr/lib64/qt5/bin/qmake /usr/lib/x86_64-linux-gnu/qt5/bin/qmake /usr/lib/i386-linux-gnu/qt5/bin/qmake /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake /usr/local/lib/qt5/bin/qmake $\
[18:36] <xnox> qmake qmake-qt4"
[18:36] <xnox> in case of "qmake" default qmake specified.
[18:37] <xnox> and thus it "worked" on x86_64, i386, armhf only =)
[18:37] <xnox> exporting QT_SELECT=5 would have been a better trick.
[18:37] <xnox> or like querying the triplet from gcc.
[18:38] <xnox> Mirv, our qt is fine, it's mythtv which is funny.
[18:54] <superm1> xnox: thanks so much for digging in and that analysis, we'll yell at upstream.
[18:57] <xnox> superm1, qt-chooser is an "upstream" thing as far as I understand. and all they should do is like QT_CHOOSER=5 qmake, QT_CHOOSER=4 qmake, and then give up, and that's it.
[19:53] <Mirv> xnox: fun hacks there. arguably though qtchooser is a bit of a hack itself and not universally liked either (Fedora chose to rename all binaries instead)
[19:54] <xnox> =(
[19:54] <xnox> i see
[19:54] <xnox> meh
[19:54] <xnox> Mirv, time to switch "default" to qt5 and forget this ever happened?
[19:54] <flocculant> infinity: didn't realise you're on vacation - who else is likely to do the beta stuff for the flavours?
[19:55] <stgraber> FFe request for LXD. We'll be tagging our next beta tomorrow so it'd be great if we could have this reviewed before then!
[19:55] <stgraber> https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1548489
[19:55] <ubot5> Launchpad bug 1548489 in lxd (Ubuntu) "[FFe] Let's get LXD 2.0 final in Xenial" [Undecided,New]
[19:58] <infinity> flocculant: It's only one day of VAC, though if you can talk someone else into doing this one (hi, stgraber!), I've done my fair share of milestones already. :P
[19:59] <flocculant> infinity: yea I know you have :)
[19:59] <stgraber> sure, I'm around this week, so I can take care of the machinery, so long as someone else takes care of tracking, paperwork, announcement, ...
[20:00] <flocculant> stgraber: I'm doing that stuff
[20:00] <stgraber> cool, who's participating?
[20:00] <stgraber> creating the milestone now, then do a one-off build and switch all of those off in cron
[20:01] <flocculant> stgraber: lubuntu/kylin/mate/cloud/gnome/studio and xubuntu
[20:01] <flocculant> https://wiki.ubuntu.com/XenialXerus/Beta1 is up to date
[20:01] <flocculant> I pinged yofel earlier today re kubuntu
[20:02] <flocculant> and you didn't reply about Edubuntu - but I kind of assumed you'd not be anyway :p
[20:03] <stgraber> we won't
[20:03] <stgraber> not even sure we'll be releasing 16.04 at all in fact
[20:03] <stgraber> highvoltage and I have been rather busy with !Edubuntu stuff and we've said that if we'd make a 16.04, it would be the last release we'd be involved in, though even that seems unlikely now
[20:03] <flocculant> right
[20:04] <stgraber> flocculant: http://iso.qa.ubuntu.com/qatracker/series/56/manifest does that look good?
[20:04]  * stgraber fires up VPN
[20:05] <stgraber> dailies disabled for those
[20:05] <flocculant> stgraber: if all of those EC2 things are cloud - then yep that looks like the right things :)
[20:05] <stgraber> yeah, they're the cloudy stuff
[20:06] <flocculant> cool
[20:06] <stgraber> oh, though I'm not sure if they still matter since they have their own tracker
[20:06] <flocculant> thanks stgraber :)
[20:06] <stgraber> utlemming, rcj, Odd_Bloke: do you guys still need the products in the manifest on iso.qa.ubuntu.com or is that only tracked through the cloud tracker nowadays?
[20:06] <stgraber> if they don't need it, I'll remove those entirely from the manifest so they don't keep popping up
[20:07] <flocculant> stgraber: I'll let people taking part know things are building *soon*
[20:07] <flocculant> and yea - if they use something else
[20:08] <stgraber> I "think" they don't need those anymore
[20:09] <flocculant> I have no clue for sure :)
[20:10] <stgraber> rebuilds requested for all the participating products, the bot will announce as they show up
[20:11] <flocculant> stgraber: thanks :)
[20:23] <Odd_Bloke> stgraber: We don't.
[20:44] <wxl> we have a rebuild going on for some reason?
[21:03] <flocculant> stgraber: looks like bug 1547518 is going to be an issue
[21:03] <ubot5> bug 1547518 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.InvalidArgs: No such interface '/org/freedesktop/UPower'" [Critical,Confirmed] https://launchpad.net/bugs/1547518
[21:03] <flocculant> stgraber: also - what timezone are you?
[21:04] <stgraber> US/Canada eastern but usually working pacific hours
[21:05] <utlemming> stgraber: correct, we do not need the products on iso.qa.ubuntu.com. We have cloud.qa.ubuntu.com for that stuff.
[21:05] <stgraber> utlemming: cool, removed from manifest
[21:05] <stgraber> flocculant: yeah, that sounds like a potential problem. Looks like it's been assigned to cyphermox so "just" need to wait for a fix and then ask everyone to respin their images
[21:05] <flocculant> stgraber: ok thanks - just so I know when to see you about if I need anything, I'm UK time
[21:06] <flocculant> stgraber: yup
[21:17] <stgraber> qatracker is temporarily down because of a security reboot taking longer than expected
[21:18] <flocculant> yep
[21:19] <stgraber> oh, this may actually trigger a second rebuild of some images when the server does come back online as the image builder wasn't able to mark things as built or published :(
[21:19] <flocculant> heh
[21:20] <flocculant> awesome timing :)
[21:20] <stgraber> yeah...
[21:20] <flocculant> stgraber: most people expect milestones to show up on Tuesday anyway so ...
[21:22] <stgraber> qatracker is back, lets see what's been lost in the process
[21:23] <stgraber> I confirmed that nusakan thinks that everything was processed so any product that's missing will be getting another build
[21:24] <flocculant> lubuntu missing desktops/gnome missing 32bit/ Mate missing completely
[21:25] <stgraber> convenietly all the missing ones are marked as rebuilding :)
[21:26] <stgraber> triggered those again now
[21:27] <flocculant> very convenient - also seems that I can read and agree with that :)
[21:37] <cyphermox> flocculant: that ubiquity crash, do you get it with the live session or with only ubiquity for installing?
[21:38] <wxl> cyphermox: both. bug report now says that
[21:38] <cyphermox> hrm, sorry, I didn't notice
[21:38] <wxl> cyphermox: also it's i386 and amd64. i'm trying to get one of my ppc testers to check it out there, too, but it likely affects them as well
[21:38] <wxl> cyphermox: i just changed it
[21:38] <cyphermox> I'm trying to figure out why
[21:38] <wxl> cyphermox: somehow it's related to the presence of the battery
[21:39] <cyphermox> don't bother checking every arch, it will fail eveywhere
[21:39] <cyphermox> yeah
[21:39] <flocculant> cyphermox: I've not seen it
[21:39] <wxl> cyphermox: earliest report seems to be the 19th. i wonder if earlier images have something different in terms of the kernel or upower?
[21:39] <cyphermox> we only go ask dbus for upower if there is a battery
[21:39] <cyphermox> they might have, yes
[21:39] <cyphermox> we got 0.99.4-1 on the 18th
[21:40] <cyphermox> (but I also uploaded the last ubiquity on the 17th, so it's not a large different in timing)
[21:41] <cyphermox> I think the new upower is broken somehow, haven't managed to find out how just yet but I also don't have a system with a battery to debug this today, I will later.
[21:42] <cyphermox> before patching out the crashy bits I'd still like to know why it's crashing
[21:43] <jibel> cyphermox, if it's upower pitti could have a look tomorrow morning?
[21:45] <cyphermox> yeah, I'll look too, just a bit later.
[21:45] <wxl> cyphermox: but did ubiquity have any changes that would affect its dealings with dbus?
[21:46] <cyphermox> wxl: not directly, but I did move stuff tangentally relevant to upower, when I moved off the "connected to power" widget
[21:46] <cyphermox> so it's probably just some timing issue where upower isn't starting fast enough or something
[21:48] <cyphermox> nah, the widgets themselves don't reference that at all
[21:55] <jibel> cyphermox, actually on a laptop just run upower -d and upowerd crashes
[21:56] <cyphermox> figures
[21:56] <cyphermox> oh, so it does, nifty
[21:56] <cyphermox> I had looked in case there was something like this, but I saw it was just running the daemon seemingly happily on my laptop
[21:57] <jibel> cyphermox, the dbus call probably make it crash too
[21:58] <cyphermox> yeah
[21:58] <cyphermox> well, I got the backtrace, going to look at the code to see
[22:01] <jibel> cyphermox, https://errors.ubuntu.com/bucket/?id=/usr/lib/upower/upowerd%3A11%3Ag_variant_is_trusted%3Ag_variant_builder_add_value%3Ag_variant_valist_new%3Ag_variant_new_va%3Ag_variant_new
[22:05] <cyphermox> yeah
[22:11] <flocculant> stgraber: thanks for starting the ball rolling - I'm off now - back tomorrow :)
[22:11] <cyphermox> jibel: I think I'll let pitti play with this
[22:13] <jibel> cyphermox, k, I'll ping him in the morning
[22:14] <jibel> it's a showstopper for beta1 IMHO
[22:14] <wxl> jibel: well, server, netboot and lubuntu alternates will be fine :)
[22:14] <cyphermox> jibel: I'm fixing up a patch to ubiquity to not crash
[22:49] <flexiondotorg_> infinity, You around?
[23:03] <cyphermox> flexiondotorg_: infinity has a day off today, can I help?
[23:03] <flexiondotorg_> cyphermox, Hi :-)
[23:03] <cyphermox> hey
[23:03] <flexiondotorg_> infinity, Asked me to annoy him about Xubuntu Base and Ubuntu MATE Base.
[23:04] <flexiondotorg_> Just here to do as instructed :-)
[23:05] <cyphermox> ok, then remind again tomorrow maybe ;)
[23:50] <yofel> flocculant: yes, kubuntu would like to do beta1 - not like we can test much, but it would be nice to at least get ubiquity etc. tested
[23:58] <flexiondotorg_> cyphermox, Wilco :-)
[23:58] <flexiondotorg_> cyphermox, Catch you tomorrow!