[01:24] <jamesh> rvr: pong
[01:24] <rvr> jamesh: It's 2:25 AM here X-)
[01:24] <rvr> jamesh: Anyway...
[01:24] <rvr> jamesh: I was testing silo 9
[01:24] <jamesh> rvr: it was 1:30 am when you pinged me :)
[01:24] <rvr> jamesh: Oh, where do you live?
[01:25] <rvr> Australia?
[01:25] <jamesh> rvr: Western Australia (UTC +8)
[01:25] <rvr> I see!
[01:25] <rvr> jamesh: silo 9, thumbnailer... I was stress testing gallery-app
[01:25] <rvr> jamesh: I see some freezes when creating/deleting the files
[01:26] <rvr> jamesh: Is that expected?
[01:26] <rvr> I didn't check without the silo
[01:27] <jamesh> rvr: I have seen some issues with the stress tests even before we did the big thumbnailer landing a few weeks back.  Let me find the bug
[01:28] <jamesh> rvr: there is this bug: https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1475210
[01:28] <jamesh> so I don't think what you are seeing is caused by this silo.
[01:28] <rvr> jamesh: Right
[01:29] <rvr> jamesh: Looks like that's it, thanks. I'll perform some more tests tomorrow morning and will probably approve it.
[01:29] <jamesh> rvr: thanks.
[04:55] <Mirv> o/
[09:09] <pstolowski> hey trainguards, any idea why my silo 41 build failed? I cannot find any clue in the log - e.g. https://launchpadlibrarian.net/213648798/buildlog_ubuntu-vivid-arm64.unity-api_7.99%2B15.04.20150805-0ubuntu1_BUILDING.txt.gz ?
[09:17] <seb128> shrug
[09:17] <seb128> stupid question, but how does one add a landing ask with the new system?
[09:17] <seb128> ignore that
[09:18] <Mirv> (logging in with team creds checked)
[09:18] <seb128> I didn't check all the sso team permissions first time I logged in
[09:18] <seb128> (that's stupid that default doesn't include what it should)
[09:20] <seb128> and why do we have editable entries which are "don't touch"
[09:20] <Mirv> pstolowski: seems weird, but it's not that'd be a generic armhf problem
[09:20] <seb128> at least the hints should include the "don't touch"
[09:20] <seb128> without having to get the tooltip to hint that
[09:20] <Mirv> seb128: bugs/requests to https://bugs.launchpad.net/bileto .. not sure about why they are editable
[09:23] <sil2100> pstolowski: let me take a look
[09:23] <Mirv> pstolowski: the fatc that it happens on vivid too is especially problematic/weird.. I can't see anything wrong, but can you check with others who may be building unity8 atm? I have a vague memory of reading something yesterday about something breaking up unity something in vivid overlay... and that's all I can remember :D it's the only thing I can think of
[09:23] <Mirv> but let's have sil2100 look at it too, maybe his eyes spot something
[09:24] <Mirv> and of course, retrying is worth trying
[09:25] <tsdgeos> trainguards: any idea what's wrong in https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/189/console ?
[09:25] <tsdgeos> no space left?
[09:25] <sil2100> uh oh, oh shit
[09:26] <Mirv> urgh
[09:26] <sil2100> hm, df says that there's space still, but maybe it's not showing all the volumes or something
[09:27] <Mirv> I thought those two volumes (you just checked) were the ones..
[09:27] <pstolowski> Mirv, sil2100 ok thanks (note, amd64 build failed for sensible reason, only arm looks weird), retrying anyway
[09:28] <Mirv> sil2100: it says the same https://ci-train.ubuntu.com/job/cyphermox-test/1052/console
[09:28] <sil2100> Really strange
[09:29] <sil2100> tsdgeos: could you retry a watch_only build?
[09:29] <sil2100> Since this looks really strange
[09:30] <seb128> Mirv, thanks
[09:30] <tsdgeos> greyback_: can you do what sil2100 said ↑↑↑
[09:36] <sil2100> tsdgeos, greyback_: I did it
[09:56] <cjwatson> pstolowski: fallout from a buildd upgrade, sorry - retrying is the right thing to do
[09:57] <cjwatson> Mirv: ^-
[09:57] <sil2100> cjwatson: thanks!
[09:57] <sil2100> pstolowski: let me retry
[09:57] <cjwatson> I'll see if I can search for such failures and bulk-retry, after coffee
[09:57] <cjwatson> was just finishing up the proper fix for the underlying bug
[09:58] <pstolowski> sil2100, no!
[09:58] <pstolowski> sil2100, i've kicked the build already
[09:58] <pstolowski> cjwatson, ack, thanks!
[09:58] <sil2100> ACK, since I saw failures in the build, so I thought it failed again
[09:59] <pstolowski> sil2100, ah, right, it's failing again but for different reason i think
[09:59] <pstolowski> looking
[10:02] <cjwatson> pstolowski: bah, you kicked off an all-architectures rebuild for a problem on one architecture?
[10:04] <pstolowski> cjwatson, yes... i'm still chasing various g++5 related build failures, it's failing on all architectures atm afaict
[10:05] <cjwatson> pstolowski: vivid can have nothing to do with g++-5
[10:05] <cjwatson> pstolowski: for single-architecture failures, please don't use the ci-train "build" function
[10:05] <cjwatson> it's wasteful of what are actually quite highly contended resources
[10:05] <pstolowski> cjwatson, fair point... ok, how i do this otherwise?
[10:06] <cjwatson> pstolowski: get somebody in ~ci-train-ppa-service to use the retry function directly in the PPA
[10:06] <cjwatson> any train guard should be able to do so
[10:07] <greyback_> sil2100: I did watch-only rebuild again (disabled twin check), it went ok
[10:07] <cjwatson> I wish that the train exposed some function to let people do this by proxy for silos assigned to them
[10:10] <Mirv> thanks cjwatson!
[10:11] <sil2100> greyback_: it looked like a transient error, there's no way the train could have run out of space...
[10:11] <Mirv> cjwatson: trying the herd the people to not run full rebuilds is hard, everyone seems to default to it..
[10:11] <Mirv> CI Train is too easy!
[10:12] <cjwatson> Mirv: well this is in part because it doesn't expose the function they want, and they can't use it directly in the PPAs unless they're in ~ci-train-ppa-service which most users aren't
[10:12] <Mirv> that's true.
[10:12] <cjwatson> but ci-train proxies uploads, so it would make sense for it to proxy upload-gated functions such as retry as well
[10:14] <Mirv> filed https://bugs.launchpad.net/ubuntu-lt/+bug/1481687 about it
[10:14] <sil2100> Mirv: it's a dupe ;)
[10:15] <Mirv> sil2100: oh :) I just checked -lt bugs were empty. feel free to mark as so!
[10:15] <cjwatson> Mirv: thanks
[10:15] <Mirv> of course, people tend to use the "Build" without parameters even now when they want to rebuild a single package, so just having the option does not go all the way
[10:15] <cjwatson> https://bugs.launchpad.net/cupstream2distro/+bug/1397388 I expect
[10:16] <sil2100> Yes, there's a branch for that already, but missing tests yet
[10:16] <sil2100> Need to finish that up
[10:16]  * cjwatson marks as duplicate
[10:16] <sil2100> Thanks :)
[10:53] <pstolowski> cjwatson, it failed on armhf the same way https://launchpadlibrarian.net/213656647/buildlog_ubuntu-wily-armhf.unity-api_7.99%2B15.10.20150805.2-0ubuntu1_BUILDING.txt.gz
[10:54] <cjwatson> pstolowski: hm
[10:58] <cjwatson> pstolowski: this is all going to be connected to https://rt.admin.canonical.com/Ticket/Display.html?id=83632 anyway - I'm just checking that my requested upgrades fix it
[11:01] <pstolowski> cjwatson, ack. can you ping me when you think i should retry the build?
[11:02] <cjwatson> pstolowski: I'll deal with retrying them for you
[11:03] <pstolowski> cjwatson, ok, thanks
[11:03] <cjwatson> pstolowski: will get IS attention as quickly as I can, but IIRC we have no EU webops coverage this week so it will probably be a few hours :-/
[11:03] <pstolowski> uhm
[11:03] <pstolowski> that means lunch time
[11:03] <cjwatson> food is good
[11:04] <cjwatson> oh, and 2.5 of the architectures are going to need to wait for Adam to be around
[11:06] <cjwatson> he crashed about five hours ago, so hopefully also in a few hours?
[11:07] <cjwatson> FWIW I think this affects packages that B-D on something:any or something:native
[11:15] <cjwatson> ok, probably just :native, and my upgrade will fix it
[11:18]  * sil2100 off to prepare lunch
[12:23] <dobey> trainguards: so persistent-cache-cpp is landed now, but still got the ridiculously verbose changelog entry, despite the debian/changelog having a manual entry. can we find what is causing this bug exactly and get it fixed?
[12:26] <sil2100> dobey: sure, let's create a bug for that - it's interesting, maybe the logic changed after robru rewrote the whole thing, but normally the train should never touch the changelog for a merge that had manually added a changelog entry
[12:27] <sil2100> But as I said, the whole code got changed from the times we wrote it with didrocks
[12:28] <dobey> file a bug where?
[12:28] <dbarth> o/ trainguards, i'm done with testing silo 26 (oxide), can you help me publish that update to Wily?
[12:28] <sil2100> dobey: http://bugs.launchpad.net/cupstream2distro/
[12:28] <dbarth> (for ref. the vivid and trusty security updates have already been released)
[12:29] <dobey> dbarth: wily landing might be blocked by the gcc-5 transition
[12:29] <dbarth> ah, this is still on?
[12:29] <dbarth> ok, anyway, oxide is ready when the archive reopens
[12:29]  * ogra_ is curious how you even tested that 
[12:29] <dobey> yeah, a lot of things still failing in proposed as a result
[12:29] <sil2100> dbarth: hey! hmm, why wasn't this already released to wily by the oxide team?
[12:30] <rvr> anpok_: ping
[12:30] <dbarth> rvr: hey; and i've approved the branch in silo 15; let me know when you take that one next
[12:31] <anpok_> rvr: pong
[12:31] <rvr> dbarth: Yeah, I know. I already moved the card to the ready for testing lane :)
[12:31] <rvr> anpok_: Hey
[12:31] <rvr> anpok_: Can you take a look to the output of udevadm? I don't know whether it's fine or not.
[12:31] <anpok_> sure
[12:31] <dobey> dbarth: indeed, there's the gcc5 rebuild of oxide-qt in proposed at the moment, blocked on gcc-5 migration settling
[12:32] <rvr> anpok_: http://paste.ubuntu.com/12006552/
[12:32] <dbarth> dobey: ouch, that's a big one
[12:32] <dbarth> strange though, as it had gcc5 already in the ppa build logs
[12:32] <dbarth> maybe not the latest gcc build
[12:33] <anpok_> rvr: oh you have to replace <relative-device-path-below-sys> with a device path
[12:33] <dobey> dbarth: yes, the silo PPAs build against proposed
[12:33] <anpok_> rvr: i.e. run find /sys/ | grep capabilities
[12:33] <dobey> dbarth: but yeah, it's a big one. welcome ot the wonderful world of c++ abi incompatibilities
[12:33] <dbarth> :)
[12:34] <rvr> anpok_: http://paste.ubuntu.com/12006568/
[12:34] <anpok_> rvr: then on my system I get.. /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/capabilities  .. and remove the initial "/sys" and the capabilities suffix.. ..
[12:34] <ogra_> dbarth, i suspect you did your testing on wily against last weeks wily ?
[12:34]  * ogra_ fears you will likely have to re-test after the transition, everything you tested against will have changed then
[12:35] <rvr> anpok_: http://paste.ubuntu.com/12006581/
[12:35] <anpok_> yes..
[12:35] <ogra_> (otoh nobody runs wily on phones anyway, right ? :) )
[12:36] <sil2100> dbarth: if the oxide silo is ready for release, please mark it as ready and we can publish - but it might probably get stuck in -proposed
[12:36] <anpok_> rvr: one of those virtual input 1 to 4 is probably the touch screen
[12:36] <anpok_> but the output for mtk-kpd looks correct.
[12:37] <anpok_> rvr: with the change one of the four yields ID_TOUCHSCREEN=1
[12:37] <rvr> anpok_: http://paste.ubuntu.com/12006590/
[12:37] <rvr> anpok_: input4
[12:37] <rvr> ID_INPUT_TOUCHSCREEN=1
[12:38] <anpok_> cool.. so it still works :)
[12:40] <doko> sil2100, or others: could you have a look at http://autopkgtest.ubuntu.com/packages/q/qtcreator-plugin-ubuntu/wily/amd64/ ? is this being worked on?
[12:41] <dbarth> sil2100: "publish without qa"?
[12:41] <dbarth> ogra_: yes, indeed ! :/
[12:45] <dbarth> hmm, i read the fine manual, and that seems to be the right flag :)
[13:52] <dbarth> sil2100: is oxide getting rebuild in the end?
[13:52] <dbarth> sil2100: oSoMoN just noticed -proposed now has the silo/ppa version built last week
[13:52] <sil2100> dbarth: not sure, when did you guys build it? Did it build against gcc-5?
[13:53] <sil2100> cihelp: ping, are you guys resopnsible for the autopkgtests in proposed migration now?
[13:53] <dbarth> sil2100: according to the logs it was gcc-4.9 and there were gcc5 dependencies as well
[13:53] <sil2100> dbarth: ok, then we need to rebuild it...
[13:54] <sil2100> dbarth: you want to use the silo for the rebuild? Or chrisccoulson will do it in the other PPA?
[13:54] <dbarth> https://launchpadlibrarian.net/212992541/buildlog_ubuntu-wily-armhf.oxide-qt_1.8.4-0ubuntu1_BUILDING.txt.gz
[13:54] <josepht> sil2100: pitti is currently working on taking proposed-migration over.
[13:55] <dbarth> sil2100: can you reload the silo with a source copy then please? to ensure the right gcc5 packages are used
[13:55] <sil2100> dbarth: I can do that, will take a bit of time since even generating the source package takes a while ;)
[13:56] <sil2100> josepht: since we seem to be seeing strange issues with multiple autopkgtests, and even the logs are mentioning that it might be a testbed issue - who should we poke about those?
[13:57] <josepht> sil2100: can you paste a link to an example you're seeing please?
[13:59] <dbarth> sil2100: thanks; yes, that will take a while
[13:59] <sil2100> josepht: http://autopkgtest.ubuntu.com/packages/q/qtcreator-plugin-ubuntu/wily/amd64/ <- here for instance
[14:00] <sil2100> josepht: we tried installing the package in mention on a -proposed enabled chroot and everything seems to be fine, but maybe we're misunderstanding something
[14:03] <josepht> sil2100: this is something pitti should be able to answer
[14:03] <sil2100> josepht: ok, thanks!
[14:10] <doko> sil2100, or others: could you have a look at http://autopkgtest.ubuntu.com/packages/q/qtcreator-plugin-ubuntu/wily/amd64/ ? is this being worked on?
[14:10] <doko> ohh, reading backlog ...
[14:11] <sil2100> doko: yeah, on it :)
[14:11] <sil2100> doko: some rebuilds will be required sadly...
[14:22] <doko> sil2100, let me know if should do these directly in the archive
[14:37] <sil2100> dbarth: oh, silo 26 migrated?
[14:38] <sil2100> I thought we didn't want to have that published without rebuilding with gcc-5
[14:46] <Mirv> someone had marked that as ready to publish
[14:48] <sil2100> Probably dbarth, I thought he switched that back to 'no' after asking for a rebuild
[14:48] <Mirv> is a rebuild already building? I think if something like that is spotted, it'd be best to set the status and better yet remove the build.
[14:48] <Mirv> let's copy it as soon as it's done
[14:48] <sil2100> I'm still building the source package
[14:48] <sil2100> I'll need a silo to build it in
[14:48] <sil2100> Since I wanted to use the existing one, but it got freed, oh no
[14:53] <sil2100> Yay, even got the same silo o/
[14:53] <sil2100> Source package almost there, lintian running now
[14:54] <dbarth> sil2100: hmm, i had marked it ready to publish indeed, and forgot it was marked as such when we discussed the rebuild
[14:55] <dbarth> should i put a new request in the system?
[14:55] <sil2100> dbarth: already did that
[14:55] <dbarth> ah perfect
[15:11] <pstolowski> sil2100, hey, could you pls kick the build of unity-scopes-shell in silo 41 for Wily amd64 only?
[15:12] <sil2100> pstolowski: on it
[15:12] <pstolowski> thanks!
[15:13] <sil2100> pstolowski: only amd64, yes? It's re-running now
[15:13] <pstolowski> sil2100, yes, thanks!
[15:19] <pstolowski> brendand, ping
[15:55] <brendand> pstolowski, hi
[15:55] <pstolowski> brendand, hey,i've a humble request
[15:56] <brendand> pstolowski, i humbly accept your request, whatever it is :)
[15:56] <pstolowski> :)
[15:57] <pstolowski> brendand, can jhodapp's silo 021 get QA priority when ready for qa testing (should be soon)? we depend on the stuff from this silo for some other feature for ota6
[15:58] <brendand> pstolowski, it would be best to ask davmor2 that, he's in charge of silo testing while jibel is on holiday - i haven't handled those things in a while
[15:59] <pstolowski> brendand, ah, ok
[16:00] <pstolowski> davmor2, ^ ?
[16:01] <davmor2> pstolowski: pfff I'm not so humble, I'm more grumpy ;)  The queue is fairly quiet currently so it should be doable.  When the silo is ready to test just ping rvr with the request and he can reassign to alesage if he is busy.
[16:02] <brendand> davmor2, maybe that's why he asked me :)
[16:02] <davmor2> brendand: probably
[16:03] <pstolowski> phew, that was easy ;)
[16:03] <pstolowski> thanks davmor2
[16:04] <pstolowski> jhodapp, can you do that ^ in case i'm not around (eod soon)?
[16:04] <brendand> pstolowski, when even davmor2 agrees straight away you have nothing to worry about :)
[16:05] <brendand> sometimes he says no just for the fun of it
[16:05] <davmor2> pstolowski: brendand sarcasm doesn't work on irc if you miss of the tags
[16:05] <alesage> I'm just taking everyone at their word
[16:07] <jhodapp> pstolowski, just ping rvr you mean?
[16:07] <pstolowski> jhodapp, yeah, when your silo 21 is ready for qa
[16:08] <jhodapp> pstolowski, indeed, I can do that
[16:08] <jhodapp> thanks for asking QA about it
[16:08] <fginther> renatu, regarding indicator-transfer-buteo, that should be built against vivid with the overlay PPA, correct?
[16:08] <pstolowski> jhodapp, cool, thanks!
[16:10] <ogra_> sil2100, FYI i kidked off the image build we discussed before
[16:10] <davmor2> alesage: now remember "bird is the word"
[16:11] <sil2100> ogra_: ok, thanks for the info - I saw livecd-rootfs landing in the overlay so I expected that ;)
[16:11] <alesage> I've heard about that
[16:11] <ogra_> :)
[16:13] <davmor2> alesage: Everybody's hear about the bird
[16:15] <pstolowski> sil2100, hey, where do i find any trace of the amd64 build for silo 41 that you started some time ago? can't see any new builds in the status of the ppa
[16:16] <sil2100> pstolowski: ? Let me check that
[16:16] <cjwatson> pstolowski: I've almost succeeded in getting IS attention, BTW, should hopefully be sorted soon ...
[16:16] <sil2100> pstolowski: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/7761970 this is it
[16:17] <sil2100> pstolowski: started 1 hour ago, the rest was from 5 hours ago, so this is the newest failure after my manual re-build
[16:18] <ogra_> hmm is -gles out of sync in vivid ? i386 just fell over
[16:18] <pstolowski> sil2100, uhm.. pretty weird, i pushed a fix for this failure 6 hours ago
[16:19] <sil2100> ogra_: the emulator is broken since 2 OTAs
[16:19] <sil2100> (if that's what you're talking about)
[16:19] <ogra_> sil2100, yes, i know that but the image build just failed with a dependency error
[16:20] <sil2100> Oh?
[16:20] <ogra_> https://launchpadlibrarian.net/213681063/buildlog_ubuntu_vivid_i386_ubuntu-touch_BUILDING.txt.gz
[16:20] <ogra_> and thats nothing my livecd-rootfs change could cause
[16:21] <pstolowski> cjwatson, ack, thanks for heads up
[16:22] <sil2100> ogra_: ok, last image was successfull, but I see we had a new UITK landed
[16:22] <ogra_> sil2100, armhf definitely got past that point
[16:22] <ogra_> so yeah, likely the new UITK
[16:24] <dobey> trainguards: can item 55 in the requests list be marked as abandoned? i presume it was copied over from spreadsheet, but looks like it actually landed last week?
[16:26] <sil2100> ogra_: interesting, I don't see any packaging changes in the UITK landing
[16:26] <sil2100> dobey: hm, ok, let's mark it landed then - I'll double check and clear it out
[16:27] <ogra_> sil2100, perhaps the build of libqt5gui5-gles faile3d or some such ?
[16:28] <sil2100> ogra_: well, this one comes from qtbase-opensource-src-gles and we didn't have any uploads of that today
[16:29] <ogra_> well, something makes it uninstallable
[16:30] <ogra_> perhaps a buildd hiccup, i can triger an i386 build after armhf finished if you want
[16:30] <ogra_> to see if it is reproducable
[16:31] <pstolowski> sil2100, if you do a single arch rebuild in the ppa, it fetches all the LP branches again, right?
[16:31] <sil2100> dobey: ok, confirmed it as landed, probably some bogus stuff during migration
[16:31] <sil2100> pstolowski: hah, no :)
[16:31] <sil2100> pstolowski: if there are changes in the source you need to do a CI Train build
[16:31] <pstolowski> sil2100, ouch :(
[16:32] <pstolowski> sil2100, yeah.. i fixed that last error.. ok, rebuild in full then
[16:32] <sil2100> pstolowski: a single arch rebuild only 'retries the same build' - it helps in case there are transient issues or some problems with the build env
[16:32] <dobey> pstolowski: ouch? that's the correct thing to do. if you changed the source, then you need to recompile for all archs :)
[16:32] <sil2100> pstolowski: yeah, sadly source changes need new uploads
[16:33] <sil2100> Sorry I didn't mention that
[16:33] <pstolowski> dobey, yeah, makes sense. 'ouch' for my naivety
[16:33] <pstolowski> sil2100, thanks
[16:41] <robru> cjwatson: do you know of any documentation for the lp "teams" openid extension? for some reason on bileto login the necessary teams are unchecked and I don't see any way to make those teams default checked.
[16:42] <cjwatson> robru: That's SSO, not Launchpad.
[16:42] <cjwatson> robru: I don't know very much about it.
[16:42] <robru> cjwatson: do you know who would know?
[16:43] <cjwatson> robru: You could try in #u1-internal
[16:43] <robru> cjwatson: thanks
[16:46] <dobey> https://launchpadlibrarian.net/213682706/buildlog_ubuntu-vivid-armhf.unity-scope-click_0.1.1%2B15.04.20150805-0ubuntu1_BUILDING.txt.gz
[16:46] <dobey> well that's weird
[16:46] <bregma> hey robru, how do I mark my silo as 'all tests passed, you can finally publish now' in the new system?
[16:47] <robru> bregma: depending on whether or not your silo releases to vivid overlay, you can set the QA field to either 'Publish without QA' or 'Ready for QA'
[16:49] <bregma> whoops, there it is.....
[16:56] <cjwatson> dobey: That's the bug (or part of it) that I'm waiting for a launchpad-buildd deployment to fix
[16:56] <dobey> cjwatson: ah ok. i guess having it rebuild won't help?
[16:56] <renatu> fginther, yes
[16:58] <cjwatson> dobey: It will not help, no.
[16:58] <cjwatson> dobey: I blame dpkg upstream (for convoluted reasons).
[16:58] <dobey> cjwatson: ok, thanks
[16:59] <robru> mterry: kenvandine: anybody around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/lastSuccessfulBuild/artifact/compiz_packaging_changes.diff/*view*/ thx
[17:01] <sil2100> ogra_: give me a sign if a rebuild doesn't help
[17:02] <sil2100> ogra_: I'll try to tackle that tomorrow
[17:02] <ogra_> sil2100, will do ... damn ... my patch didnt help
[17:03] <ogra_> Get:1 http://ftpmaster.internal/ubuntu/ vivid/multiverse android all 20141117-0039-0ubuntu11 [439 MB]
[17:03] <ogra_> still pulls from the archive :/
[17:04] <sil2100> ogra_: maybe the existing sources.list before the step you made doesn't have the overlay in it?
[17:04] <ogra_> cjwatson, is the EXTRA_PPAS var in the environment for the whole build or does it get unset at some point ?
[17:05]  * ogra_ wonders why https://launchpadlibrarian.net/213678319/livecd-rootfs_2.300.2%2Bvivid2_2.300.2%2Bvivid3.diff.gz still uses the archive 
[17:05] <ogra_> sil2100, it is the very last step in the build, it should have everything in the sources.list that was used during buiild
[17:06] <ogra_> (that is the reason why the initial code that i comment out there actually exists)
[17:06] <cjwatson> ogra_: Only a limited set of environment variables are passed through to auto/build.
[17:06] <ogra_> UGH !
[17:06] <ogra_> if [ ! "$EXTRA_PPAS" ]; then
[17:06]  * ogra_ needs a refresh course in shell !
[17:06] <ogra_> damn
[17:07] <ogra_> that should be -z or "! -n"
[17:07] <cjwatson> ogra_: But that code looks quite wrong anyway.  You still want to do that stuff in the extra-ppas case, just somewhere else.
[17:07] <cjwatson> Can't you just move it down slightly?
[17:08] <ogra_> cjwatson, no, i dont want to wipe the sources.list but pull the android package from the PPA
[17:08] <ogra_> and the PPA should be available in the sources.list already so we would just get the newer package from there
[17:08] <sil2100> ogra_: ugh, duuh
[17:09] <sil2100> Missed that as well, my brain is too much C oriented to notice that
[17:09] <cjwatson> ogra_: [ -e config/archives/extra-ppas.list.chroot ] would probably work better.
[17:09] <ogra_> cjwatson, perfect !
[17:09] <cjwatson> I think.
[17:10] <ogra_> well, that livecd-rootfs only exists in the overlay anyway ... in the very worst case i could just rip out the whole snippet ... but i'd rather make it generic enough that i can push it upstream
[17:16] <mterry> robru, looking at that compiz packaging diff...
[17:17] <mterry> robru, the Breaks/Replaces changes use the wrong version number...  I don't think it causes a problem for the archive itself (the version is still newer than last published one)... But it's still bad practice/we should look at why that happened -- I thought we had a variable we could use and our build system would insert the right version
[17:18] <robru> mterry: yeah if you use 0replaceme it gets replaced with the generated version.
[17:18] <robru> bregma: ^^ did you not use 0replaceme?
[17:19] <bregma> the what?
[17:21] <mterry> bregma, do you know who changed the Breaks/Replaces lines in https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/lastSuccessfulBuild/artifact/compiz_packaging_changes.diff/*view*/ ?
[17:21] <sil2100> dbarth: hey! Forgot to give you a poke, oxide is building since a while in silo 26: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+packages
[17:21] <mterry> bregma, they use the wrong version, presumably because "0replaceme" wasn't used
[17:23] <bregma> mterry, that's https://code.launchpad.net/~mitya57/compiz/switcher-plugins-in-default/+merge/262518
[17:23] <bregma> I am unfamiliar with 0replaceme, it's not a Debian packaging thing
[17:25] <mterry> bregma, yeah, it's just a CI thing.  Because you don't know the version that will be released when you land your MP
[17:27] <mterry> robru, bregma: anyway, I guess +1 on those packaging diffs, since it won't cause a problem.  But just heads up about 0replaceme.  Do we have a wiki page that mentions it?
[17:27]  * bregma has gained a level!!
[17:27] <robru> mterry: ostensibly
[17:29] <robru> mterry: well I can't seem to find that in the documentation. awesome.
[17:29] <balloons> so plars, I can't get the intro wizard to go away. I've tried phablet-config. Do you ever have this issue?
[17:29] <robru> bregma: so yeah, anywhere you want to refer to "the version of the package that the train will generate for me" in any file under debian/* (but not recursively in subdirs), just use "0replaceme" and the train will replace it
[17:30] <plars> balloons: no, what are you trying?
[17:30] <robru> mterry: ok thanks
[17:30] <balloons> plars, phablet-config -s JB072312 edges-intro --disable, phablet-config -s JB072312 welcome-wizard --disable
[17:32] <plars> balloons: oh, one thing to be aware of, iirc using phablet-config just "disables" or turns them off, it doesn't stop the process. So you'll probably need to reboot to see it take effect
[17:33] <balloons> plars, lol. sorry for jumping channels
[17:33] <bzoltan_> robru:  I see in the http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html that the 1.3.1549+15.10.20150710.1-0ubuntu2~gcc5.1 UITK is blocked in the proposed migration by the misterious qtcreator-plugin-ubuntu error. Is it something what blocks the landing of the silo13 UITK?
[17:33] <balloons> and right, I've tried toggling them on and off and rebooting
[17:33] <balloons> I'll try setting the timezone and locale too, heh
[17:33] <balloons> that's what's popping up
[17:34] <plars> balloons: it doesn't give you any kind of error or anything?
[17:34] <dobey> bzoltan_: the qtcreator issue is blocking lots of things including gcc5
[17:34] <balloons> plars, no. Disabling again tells me it's already disabled. Otherwise they run fine
[17:34] <dobey> bzoltan_: the ubuntu-sdk-libs-dev needs to be updated to either not depend on libboost1.55-dev at all, or to instead depend on libboost-dev
[17:34] <bzoltan_> dobey:  the only problem is that  I have no idea what is wrong with that package...
[17:35] <plars> balloons: and is it just edges-intro, or welcome wizard also that fails to disable?
[17:35] <dobey> bzoltan_: that comes from the ubuntu-touch-meta package
[17:35] <balloons> plars, not sure, we don't get to edges intro. Rick tells me it's at the wizard to select language, etc
[17:36] <bzoltan_> dobey: here? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/sdk-libs-dev
[17:37] <dobey> bzoltan_: i don't know what that file is; it's not a debian/control file
[17:37] <bzoltan_> dobey:  is anybody working on it? Seems to be a super bitesize job
[17:38] <bzoltan_> dobey:  no, it is not... I used to propose MRs for that project.. ogra_ used to take care of that seed as I remember
[17:38] <cjwatson> dobey: ubuntu-touch-meta is generated from seeds
[17:38] <dobey> ok
[17:39] <cjwatson> there's an update script.  but I don't know how well it will be working at the moment with stuff stuck in -proposed
[17:39] <ogra_> (for wily at least :) )
[17:39] <cjwatson> dobey: unity-scope-click/armhf building for you now
[17:39] <plars> balloons: ok, so I actually had a krillin sitting next to me that had been recently installed, and nothing done to it
[17:39] <bzoltan_> dobey:  xnox has touched exactly that dependency there
[17:39] <dobey> cjwatson: well, slangasek uploaded a change to ubuntu-touch-meta a few days ago, but it only fixed the runtime deps. the -dev package still needs fixed
[17:39] <dobey> and uploaded
[17:40] <plars> balloons: I did: phablet-config welcome-wizard --disable ; phablet-config edges-intro --disable ; adb reboot
[17:40] <plars> balloons: and it came up with the regular unlock screen, I unlocked it and it never gave me the wecome screen or the edges intro (before reboot, it was freshly installed and waiting at the welcome screen)
[17:40] <robru> bzoltan_: sorry I don't know and I'm a bit swamped fixing SSO at the moment
[17:40] <bzoltan_> dobey:  cjwatson: and xnox -> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/revision/308
[17:40] <plars> balloons: are you sure it's rebooting?
[17:40] <bzoltan_> robru:  ignore it please :)
[17:41] <balloons> plars, I guess I can check uptime
[17:42] <dobey> bzoltan_: do you know why that is the versioned package rather than just "libboost-dev" ?
[17:44] <bzoltan_> dobey:  no idea... I think something depends on that particular package... at least the rdepends shows different list for it
[17:46] <dobey> i don't know why it depends on boost at all. exposing boost to consumers of our sdk/apis seems like a bad idea to me :)
[17:48] <bzoltan_> dobey:  pete woods added it with other Scope facing APIs
[17:48] <balloons> plars, indeed it's rebooting. I've set everything and rebooted a few times. Time to try again
[17:48] <dobey> oh, hmm
[17:56] <dobey> bzoltan_: so then i guess all that's needed is for someone to run the script to update the package and upload it to the archive
[17:56] <bzoltan_> dobey:  it came in here http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.vivid/revision/243
[17:56] <bzoltan_> dobey:  precisely ... "someone" :)
[17:57] <dobey> well, someone with the permissions to do so, of which i am not, or i would have done so on monday :P
[17:58] <dobey> bzoltan_: though, even with that uploaded, i think your package would still be blocked from migrating, by gcc5
[17:59] <bzoltan_> dobey:  very much possible
[17:59]  * bzoltan_ loves the new toolchain :)
[18:00] <balloons> plars, it's actually running now. Not sure if it was the magic of setting everything or not, but I'll just do that from now one
[18:01] <plars> balloons: so it works? you may want to retry just to be sure, but I'm not sure what went wrong before
[18:01] <plars> balloons: I didn't hit any snags here, but perhaps you ran into some weird race or something
[18:01] <balloons> plars, yes it works. I reflashed this morning after not having success yesterday and it didn't seem to change anything
[18:02] <plars> balloons: the other thing, is of course to make sure you do adb wait-for-device after installing, before using phablet-config
[18:02] <balloons> plars, ahh. also noted
[18:02] <jhodapp> robru, hey, can you please dput all of the gstreamer source packages in ppa:jhodapp/ubuntu/ppa into silo 21
[18:02] <robru> jhodapp: sure one sec
[18:02] <jhodapp> sure, thanks
[18:04] <robru> jhodapp: ok copied. You can do a WATCH_ONLY build in the silo if you want to be IRC pinged when the silo builds are complete
[18:05] <jhodapp> robru, awesome, thanks for the tip!
[18:05] <jhodapp> robru, btw, silo 38 is no longer needed as 21 replaced it
[18:08] <robru> jhodapp: will free it, thanks
[18:09] <jhodapp> np
[18:09] <robru> jhodapp: lol, how many builds did you do? https://ci-train.ubuntu.com/job/ubuntu-landing-038-3-merge-clean/4/console
[18:10] <jhodapp> robru, apparently many :)
[18:26] <jhodapp> robru, any idea why silo 21 is trying to build gst-libav1.0 first when its debian/control specifies that it must build gstreamer1.0 and gst-plugins-base1.0 first?
[18:27] <robru> jhodapp: I don't think PPAs particularly care about build order.
[18:27] <robru> jhodapp: if one fails due to another one not being present the PPA will retry it an hour or two later.
[18:27] <jhodapp> robru, I thought they'd respect the dependency version order and figure it out by that?
[18:28] <robru> jhodapp: well I'm not an expert on PPA buildds, but I'm not aware of any such thing. you put a package in there and it builds it.
[18:29] <jhodapp> I'm going to kill my build then and try a manual order
[18:29] <robru> jhodapp: if the deps aren't available it will just depwait
[18:29] <jhodapp> yeah I think that's what it was doing, but the deps it needs are in that silo
[18:29] <robru> jhodapp: if the build shows that it's trying to build and failing, that would suggest that you don't have the packaging right. eg it's not depending on the correct version number.
[18:30] <robru> jhodapp: ok but if the deps it needs aren't built yet, then they're not really "in the silo" in any meaningful sense ;-)
[18:30] <jhodapp> well specified to be in that silo :)
[18:36] <jhodapp> robru, yeah, I don't understand why it can't find libgstreamer1.0-dev...it did successfully build it and it is version 1.5.2 which is what it's looking for
[18:37] <robru> jhodapp: "Building. Preparing packages. Building. Building. Packages built" can you please stop starting jobs before the previous one finishes?
[18:37] <jhodapp> robru, well I would if they didn't appear to be stuck waiting on deps
[18:39] <robru> jhodapp: I don't know what to say. starting a jenkins job while another one is already running is not going to have any impact on the deps in the PPA. "The Map is not the Territory". The jenkins jobs are just loose wrappers around the PPA, "cancelling the jenkins job" does not cancel anything in the PPA.
[18:40] <jhodapp> robru, oh I see, wasn't aware of that
[18:40] <jhodapp> I thought they were linked
[18:40] <robru> jhodapp: no, they are emphatically not linked in any way.
[18:40] <jhodapp> that's good to know, and that's my missing piece then
[18:40] <robru> jhodapp: I really can't stress enough that jenkins is just a pile of shoelaces and bubble gum. Don't expect it to do anything sensible ever.
[18:41] <jhodapp> robru, right, but it's a black box to me...you're very familiar with it, I'm not at all
[18:41] <robru> jhodapp: I try to make it better one piece at a time but there's a long way to go
[18:42] <jhodapp> robru, and yeah, it's good stuff that you've done
[18:43] <robru> jhodapp: thanks
[18:43] <jhodapp> robru, thanks for your patience with me while I learn how this all works :)
[18:43] <rvr> robru: On the latest image gallery opens empty
[18:43] <robru> jhodapp: so particularly with manual source packages like you've copied in, jenkins is really doing nothing at all. triggering a build job just watches what's in the PPA, and cancelling the job doesn't cancel the PPA builds.
[18:44] <rvr> robru: No title no nothing
[18:44] <robru> rvr: on a released image?
[18:44] <rvr> robru: rc-proposed
[18:44] <rvr> 86
[18:44] <jhodapp> robru, yeah that makes sense now...it's PPAs that, until yesterday, I knew nothing about other than how to use a PPA on an ubuntu install
[18:44] <robru> jhodapp: so if there's a problem with a package building in the ppa you may need me to trigger rebuilds in the PPA manually, jenkins can't do it
[18:45] <jhodapp> robru, alright
[18:46] <robru> jhodapp: ok now that I'm looking at the actual PPA, yeah I see gstreamer build successful but everything else is depwait. Normally if this were to happen the PPA would retry the builds after a couple of hours, but I can trigger retries right now to speed that up
[18:47] <jhodapp> robru, yes please, try gst-plugins-base1.0 first
[18:47] <jhodapp> robru, then the rest can go in parallel
[18:50] <robru> jhodapp: oh oops I just did them all, bah
[18:50] <jhodapp> no worries, let's see what happens
[18:50] <robru> jhodapp: anyway please do a single WATCH_ONLY build and don't cancel it no matter how badly everything explodes ;-)
[18:50] <jhodapp> ha, ok :)
[18:51] <dobey> robru: with the new requests system, there's no more logging the device/image the silo was tested on? just setting to "ready for qa" ?
[18:52] <robru> dobey: please put that information in a comment, or in the "test plan" field or something. it was never strictly enforced, just informational
[18:55] <robru> jhodapp: ok so gst-plugins-base1.0 is going, if that one succeeds and then you see others stuck on depwait just ping me and I can retry them again
[18:55] <jhodapp> robru, perfect, thanks!
[18:57] <dobey> hmm, seems nobody else is putting that info anywhere
[18:57] <robru> jhodapp: you're welcome
[18:58] <robru> dobey: like I said, not enforced.
[19:07] <infinity> robru: Are you training today?
[19:07] <robru> infinity: I was but now I'm putting out SSO fires
[19:08] <infinity> robru: By "train", I meant ci-train, not training to be a better man or anything. :P
[19:08] <infinity> robru: Anyhow, if you like disappointing people, empty out silo 045, and tell the uploaders that they're on crack.
[19:08] <robru> infinity: oh, well yeah, I train every day. but I'm also supposed to be learning +1, but that's stalled
[19:08] <infinity> robru: embedded copies of interpreters (ew) but, even worse, downloading external deps during build.
[19:09] <infinity> robru: Which, I assume, they originally tried to do from github, found out that doesn't work, and the changelog says:
[19:09] <robru> infinity: yikes.
[19:09] <infinity> Branch io.js from our own import as git is seemly
[19:09] <infinity>     not allowed in CI.
[19:09] <infinity> I guess they didn't think to ask anyone WHY downloading during build time was forbidden, they just found the firewall hole we have for recipe builds and took advantage of it. :P
[19:10] <infinity> robru: So, yeah.  That'll be rejected with extreme prejudice if they try to land it in the archive, but it shouldn't land in the overlay either.  So both targets in there are duds.
[19:10] <robru> infinity: thanks for the pre-emptive strike
[19:11] <robru> infinity: I don't know why marcustomlinson isn't on IRC to answer for this
[19:11] <robru> since he's doing the job
[19:11] <infinity> robru: If you have some way to block that and communicate some sort of bird-flipping type thing, that would be lovely.
[19:11] <robru> infinity: well I can cancel the build. I don't really have a way to stop him from building it again though
[19:11] <robru> infinity: I'll email him
[19:12] <cjwatson> infinity: Nice.  Maybe once we have a configurable-per-build proxy for snap builds, we should look at locking that down to just recipe builds.
[19:12] <infinity> cjwatson: Yeah.  I only caught this in passing because I was watching a build log for entirely unrelated reasons (the sbuild upgrade), and saw the string 'v8' flash by.
[19:12] <infinity> cjwatson: Which triggers software PTSD.
[19:12] <infinity> cjwatson: And I had to dig deeper.
[19:13] <cjwatson> Speaking of, I think the :native thing is fixed everywhere now.
[19:14] <cjwatson> Poking rebuilds of things that were stuck on that.  Mostly just ubuntu/landing-041 I think
[19:15] <infinity> Read that as "porking rebuilds".  There's your dyslexic interpretation of that day, brought to you by my need for breakfast.  Back later.
[19:15] <cjwatson> thanks for that image, I appreciate it.
[19:15] <cjwatson> wait, the other one.
[19:16] <infinity> cjwatson: I live to give,
[19:16] <infinity> .
[19:54] <robru> somebody didn't check their emails!
[19:54] <jhodapp> robru, the other gstreamer packages are ready to be built again...base has completed
[19:55] <robru> jhodapp: ok
[19:55] <jhodapp> thanks
[20:06] <robru> jhodapp: ok, I kicked some retries, do another WATCH_ONLY
[20:11] <bfiller> robru: just starting to use bileto, what's the process to reconfigure? just added a new MR to the list then not sure what to do..
[20:11] <robru> bfiller: click the same 'Assign' link, it will detect the silo is already assigned and reconfigure it for you
[20:12] <bfiller> robru: got it, thanks
[20:12] <robru> bfiller: you're welcome
[20:18] <jhodapp> robru, thanks man
[20:18] <robru> jhodapp: you're welcome
[20:26] <robru> jhodapp: btw do you know anything about this gst: https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-014 ?
[20:27] <robru> jhodapp: seems ancient history, no?
[20:27] <robru> uploaded to PPA in may...
[20:31] <jhodapp> robru, seems to be, double check that with rsalveti if you don't mind
[20:32] <jhodapp> robru, do you have access to remove a package within silo 21?
[20:32] <robru> jhodapp: yeah, which one?
[20:32] <jhodapp> robru, if so, I need qtmultimedia deleted as we'll need to upload a version that's one minor release older to correspond to what's actually on vivid+overlay
[20:33] <jhodapp> robru, I already have a source package generated locally
[20:34] <robru> jhodapp: you can't upload a package with a lower version number than what's already in the PPA, even if you delete it. the PPA remembers
[20:34] <salem_> robru, hey, I removed one of my MR from silo 20 using requests.ci-train.., but it doesn't seem to work. is there any additional step to reconfigure the silo?
[20:34] <jhodapp> robru, never?
[20:34] <robru> jhodapp: never
[20:34] <jhodapp> wtf
[20:34] <jhodapp> this it not my day
[20:34] <jhodapp> *is
[20:34] <robru> salem_: after you safe the request you need to click 'assign' to inject the new mp list into jenkins.
[20:35] <jhodapp> robru, so I need to request a completely new silo again is the only solution?
[20:35] <robru> jhodapp: well, are you really sure you need to bump the version number down? are you sure you can't bump something else up instead?
[20:36] <jhodapp> robru, yeah I'm sure, I asked Mirv if we could release qtmultimedia 5.4.2 instead of 5.4.1 onto vivid+overlay...he said too risky
[20:36] <salem_> robru, ok, thanks!
[20:37] <robru> jhodapp: then yeah, you need a new request.
[20:37] <robru> salem_: you're welcome
[20:37] <jhodapp> robru, alright
[20:38] <jhodapp> robru, so I can't upload to my own personal PPA again because of the same thing even though I deleted it...I need to get it to another PPA then where you can upload to the new silo from
[20:42] <robru> jhodapp: yep! you can create more PPAs for yourself though
[20:43] <jhodapp> robru, yeah I'll have to give that another try as it said that package was already uploaded to launchpad
[20:46] <jhodapp> robru, alright got it, qtmultimedia from ppa:jhodapp/ubuntu/qtmultimedia to silo 38 please
[20:49] <robru> jhodapp: ok, do you need me to copy all that gst stuff as well?
[20:50] <jhodapp> robru, no it's not going to work after all...I'm going to have to go back a version or two on media-hub
[20:50] <robru> jhodapp: oh ok, well just ping me whenever you need packages copied anywhere, I can do that.
[20:50] <jhodapp> robru, thanks so much!
[20:50] <robru> jhodapp: you're welcome!
[20:59] <cyphermox> ^ignore, this is an old silo that should have been freed a while ago.
[21:01] <robru> cyphermox: thanks for freeing
[21:01] <cyphermox> robru: no prob. I thought I had mentioned it could be freed, but maybe not
[21:02] <cyphermox> about to free you another one
[21:04] <cyphermox> awe_: ^ wifi scanning fix for wily...
[21:04] <robru> john-mcaleely: I'm not sure if QA will know to pick up your tarball request there, we're still having some growing pains with the new system. better to ping a QA person directly to make sure it's on their radar
[21:05] <awe_> cyphermox, cool; I'm working on the stale AP bug, so may wait to release for the phone...as the scanning fix actually makes the stale ap fix worse
[21:05] <john-mcaleely> robru, understood. I'll ping davmor2 tomorrow then ;-)
[21:05] <awe_> s/stale ap fix worse/stale ap bug worse/
[21:05] <cyphermox> robru: fwiw, that trainguards "ready for QA" notice didn't trigger my own trainguards highlight...
[21:06] <cyphermox> awe_: syre
[21:06] <cyphermox> *sure
[21:06] <robru> cyphermox: what IRC client? some IRC clients highlight pings from channel notices and some don't (queuebot uses channel notices instead of real messages)
[21:06] <cyphermox> right
[21:06] <cyphermox> Quassel
[21:06] <davmor2> robru, john-mcaleely: Alex's device tarball for arale came through not sure if he did any different
[21:06] <cyphermox> I'm only mentioning it because it may affect others ;)
[21:06] <robru> cyphermox: there might be a setting for that, not sure.
[21:06] <robru> davmor2: I didn't see anything on the trello board.
[21:07] <davmor2> robru: number 94 top left
[21:07] <cyphermox> robru: hrm, it could also be because for some reason I have no highlights configured here?
[21:07] <davmor2> robru: although john-mcaleely 's has appeared yet
[21:07] <robru> cyphermox: heh
[21:08] <robru> davmor2: yeah I'm wondering if that other one was manually entered or something
[21:08] <john-mcaleely> well, let me know what buttons to hassle you with if I missed one davmor2 :-)
[21:09] <davmor2> john-mcaleely: I think talk to sil2100 in the morning I think he might of eased it through
[21:09] <john-mcaleely> ah, right. will do
[21:09] <davmor2> robru: you could be right :)
[21:10] <robru> davmor2: I haven't seen jibel's trello bot code but I would expect it to only create cards with status='Packages built' and qa='Ready for QA', which john-mcaleely's isn't
[21:10] <davmor2> robru: I have no idea :)
[21:11] <davmor2> robru: and I'm too tired to care ;)
[21:11] <robru> davmor2: hah, go to sleep!
[21:11] <davmor2> robru: I will as soon as this install finishes it is the last one I'm doing tonight
[21:14] <rvr> davmor2: Hey
[21:14] <davmor2> rvr: hey
[21:14] <rvr> davmor2: Gallery app is broken in current image
[21:14] <rvr> davmor2: It opens empty
[21:14] <rvr> No title no nothing
[21:15] <davmor2> rvr: firing up
[21:25] <davmor2> rvr: confirmed, but on ubuntu it works so not sure what is happening there
[21:26] <davmor2> bfiller: ^
[21:27] <rvr> davmor2: On Ubuntu, desktop?
[21:27] <bfiller> rvr: odd, we haven't updated it
[21:28] <davmor2> rvr: ignore me I was on wily/ubuntu prior and it opened there
[21:28] <davmor2> rvr: file a bug and with that I'm going to bed
[21:28] <bfiller> rvr: I see it too, what changed? any new thumbnailer or anything land yesterday?
[21:29] <rvr> bfiller: Yes
[21:29] <rvr> bfiller: A thumbnailer landed, I tested it :-/
[21:30] <bfiller> rvr: guessing it could be related
[21:30] <rvr> Land Thumbnailer 2.2 (GCC 5 compatibility, stability fixes with Wily's GStreamer)
[21:33] <rvr> https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1481920
[21:34] <jgdx> seems there's something going on with this [1] job. Lateral dbus timeouts. [1] https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/
[21:35] <jgdx> s/lateral/cross project: e.g. https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2971/testReport/junit/ubuntu_system_settings.tests.test_about/StorageTestCase/test_space_used_by_apps/ and https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2970/testReport/junit/webbrowser_app.tests.test_bookmark_options/TestBookmarkOptions/test_save_bookmarked_url_in_existing_folder/
[21:40] <bfiller> rvr: did content-hub change at all in today's image
[21:40] <rvr> bfiller: Not that I know
[21:41] <rvr> Yesterday I tested the thumbnailer and ubuntu-ui-toolkit
[21:46] <bfiller> rvr: new ui-toolkit landed? coudl be that
[21:46] <bfiller> artmello: ^^^
[21:46] <bfiller> rvr: all the other apps working ok?
[21:46] <rvr> Next landing of the UITK 1.3 with tons of bugfixes and convergence specific changes
[21:47] <rvr> System Settings works
[21:47] <artmello> bfiller, rvr: It seems a qml error, so yes that could be the problem
[21:47] <rvr> Browser too
[21:47] <artmello> bfiller, rvr: I am flashing my device to test it
[21:47] <rvr> artmello: Cool
[22:39] <alesage> egads
[22:41] <alesage> trainguards, sure I'm not doing this right in the bileto UI, trying to "QA Granted" #88, silo 15
[22:45] <alesage> trainguards ok I have levelled up on intuitive web form design however I might've created a couple of nonsense requests above ^^
[22:49] <robru> alesage: you have QA granted silos 2 and 47, was that not your intention?
[22:49] <alesage> robru, that was not my intention
[22:50] <robru> alesage: hm, looks like silo 47/ req38 was approved by rvr according to the trello board, is that just a timing coincidence
[22:50] <robru> alesage: I don't understand how you did this exactly. you would have had to have clicked on request 75 and clicked 'edit' and set QA Granted and then clicked save... how did you not notice it was the wrong request?
[22:51] <alesage> robru, this may have been by "QA Granting" an empty form (situated above 88, which I wasn't yet *editing*)
[22:51] <robru> alesage: not likely. the empty form at the top of the page will create a new request if you click the 'Create New Request' button. it won't modify existing requests
[22:52] <alesage> robru, ok timing coincidence possible, nevermind me
[22:53] <robru> alesage: but silo 2 / req75 isn't in the trello board as far as I can see, that one might indeed be a mistake
[22:53] <rvr> robru: I approved silo 47 half an hour ago
[22:54] <robru> rvr: great, do you know anything about silo 2? it got approved just one minute after
[22:54] <rvr> robru: o_O nope
[22:54] <rvr> It's not even in trello
[22:55] <robru> rvr: alesage: ok I'll publish silos 15 and 47 but I'll wait for silo 2 because that seems unknown/wrong
[22:55] <alesage> robru, ok by me
[22:56] <jhodapp> rvr, alesage I won't have anything this evening for you guys to look at for testing, should be tomorrow
[22:56] <alesage> jhodapp, ack
[22:56] <rvr> robru: Ack
[22:57] <rvr> jhodapp: Ok
[22:58] <robru> alright, lunch break at 4PM!
[22:58] <ogra_> robru, nah, its 1am ... thats a nice midnight snack
[22:59] <robru> :-P
[23:00] <artmello> rvr: about gallery issue, I proposed a MR o fix the problem
[23:01] <rvr> artmello: Great!
[23:01] <artmello> rvr: one of the properties we use in gallery seem to be changed (probably last change on ui-toolkit), so we just need to update it
[23:01] <rvr> artmello: I thought I broke something approving the thumbnailer silo :)
[23:02] <artmello> rvr: not for gallery :)
[23:02] <rvr> lol
[23:02] <rvr> artmello: Thanks for fixing this quickly
[23:03] <artmello> rvr: np. I will ask someone to review it, but I think it is eod for most of the team