[00:16] <robru> back, anybody need anything?
[01:02] <thomi> cyphermox: any idea what's happening with the autopilot package in proposed? I'm wondering how long to wait before I start thinking that it's gotten stuck :)
[01:13] <cyphermox> thomi: autopkgtest is still running
[01:13] <cyphermox> all you need to do is wait
[01:13] <thomi> cyphermox: oh, ok - how can I see that?
[01:14] <cyphermox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[01:22] <thomi> cyphermox: nice - so it runs the autopkgtests for all the reverse-depends?
[01:26] <cyphermox> pretty much
[02:05] <imgbot> [03:20] <imgbot> [03:20] <imgbot> [06:18] <Mirv> didrocks: morning. landing-009 is tested but it's been specified there that  lp:sync-monitor would need a preNEW review.
[06:18] <didrocks> Mirv: yeah, I'm backlogging first on emails
[06:18] <didrocks> Mirv: can you do a first review?
[06:20] <Mirv> hmm
[06:20] <Mirv> didrocks: it seems sil2100 has done one, but it's not included in the landing yet. so I think it'll need to be included and rebuilt.
[06:21] <didrocks> Mirv: hum, are you sure it's not included? robru and bill mentionned it was
[06:21] <didrocks> Mirv: mind double checking that before handing it over to me? :)
[06:21] <Mirv> didrocks: aha, right, renato has merged it without marking so
[06:21] <robru> didrocks, bill told me it was, i didn't confirm personally
[06:21] <didrocks> ok
[06:21] <didrocks> just do a double check
[06:22] <didrocks> robru: hey! still awake?
[06:22] <Mirv> didrocks: ok, so it's there, but to be sure I'll check that renato's branch first too. so the branch to actually check is lp:~renatofilho/sync-monitor/initial-release
[06:22] <robru> didrocks, mmmm, only slightly ;-)
[06:22] <robru> didrocks, helping my girlfriend with her PhD...
[06:22] <didrocks> ah ;)
[06:22] <didrocks> good luck to her!
[06:22] <didrocks> robru: I don't see an answer on the location-service + reverted process-cpp (but I'm not at the bottom of all emails yet)
[06:24] <robru> didrocks, oh sorry, for that one I didn't send an email, just commented on the bug. (bug 1304362)
[06:27] <didrocks> robru: ah, reading!
[06:28] <didrocks> robru: ok, bad luck then :/
[06:29] <didrocks> Mirv: there is already a lintian warning to fix
[06:29] <robru> didrocks, yeah, so I'm not sure why it didn't reproduce the first time on image 240 (it seems backwards to me; it reproduced when I used --bootstrap --wipe, but not when I didn't, I would expect it to reproduce only with extra stuff lying around, not with a fresh flash). but basically yeah, it goes back a long way
[06:29] <didrocks> not sure if people don't look at that
[06:29] <didrocks> Mirv: W: sync-monitor source: syntax-error-in-dep5-copyright line 58: Continuation line outside a paragraph (maybe line 57 should be " .").
[06:29] <didrocks> robru: yeah, that's really weird…
[06:30] <didrocks> robru: but ok, thanks for the investigation!
[06:32] <didrocks> Mirv: only GPL3 copying
[06:32] <didrocks> not LGPL2.1
[06:32] <didrocks> Mirv: please add that one
[06:33] <Mirv> didrocks: yes, I was still reviewing it myself and I just noted on the branch about the LGPL missing
[06:33] <didrocks> Mirv: all the rest +1 for me, but please, recheck ;)
[06:34] <Mirv> didrocks: commented the dep5 too there, I didn't build it yet and I'll do that still. indeed otherwise it looks good to me too.
[06:35] <didrocks> Mirv: yeah, I did build it and didn't notice anything shocking, once you're done, I suggest you just add a fix branch to the landing, rebuild and we can land that
[06:35] <Mirv> ok
[06:36] <Mirv> I'll touch the package descriptions a bit too
[06:43] <Mirv> ok, sync-monitor is now rebuilding, landing can be done after it has succeeded
[06:43] <Mirv> changes from Renato's branch http://pastebin.ubuntu.com/7225028/
[06:43] <Mirv> oh, needs fixing, Digia mentioned :S
[06:44] <Mirv> good to use pastebin myself too it seems
[06:46] <Mirv> building, again, with those lines fixed
[06:47] <didrocks> Mirv: ahah, self-checking!
[06:47] <didrocks> Mirv: oh, something more
[06:47] <didrocks> Mirv: the description of the copyright is LGPL3+?
[06:47] <didrocks> and not 2.1+?
[06:48] <didrocks> ah no
[06:48] <didrocks> forget about it :p
[06:48] <didrocks> misread :p
[06:48] <sil2100> Is it about sync-monitor? ;p
[06:48] <didrocks> (first time I see the mention)
[06:48] <didrocks> sil2100: yeah, Mirv is doing latest fixes :p
[06:48] <didrocks> sil2100: copyright dude! copyright!
[06:49] <didrocks> sil2100: and watch for lintian warnings :p
[06:49] <sil2100> didrocks: I did the copyright!
[06:49] <sil2100> And lintian!
[06:49] <didrocks> sil2100: hum…
[06:49] <didrocks> maybe Mirv took the wrong branch then?
[06:49] <Mirv> didrocks: no, sil2100's branch was merged there
[06:49] <didrocks> I'll let you guys figuring that out :p
[06:49] <Mirv> sil2100: so copyright was fine, but LICENSE.LGPL for the two intel files were missing
[06:50] <didrocks> and there was one lintian warning
[06:50] <Mirv> sil2100: and then lintian complained about missing new paragraph ".":s in copyright
[06:50] <sil2100> Mirv: ah! The license files in source! Missed that one, thanks for spotting ;)
[06:51] <Mirv> so I added 4 more commits https://code.launchpad.net/~timo-jyrinki/sync-monitor/last_bits_of_packaging_polishing on top of Renato's branch where your branch was merged (without attribution or notion that a branch was merged) in commit 61
[06:52] <sil2100> I wonder why my branch was merged into renato's and not added to the MR list as I did it yesterday
[06:52] <sil2100> They want to erase my existance from the changelog!
[06:53] <Mirv> I'd assume workflow/habit type of explanation, but renato could learn about bzr merge & bzr commit --author at least. also the inclusion of that another merge request would have been better for the changelog.
[06:54] <sil2100> I'm a bit saddish, since I'm gathering packaging evidence for my MOTU application - but besides that I don't really mind
[06:54] <didrocks> Mirv: they prefer to debate about trunk
[06:55] <didrocks> sil2100: please tell that to renato
[06:55] <didrocks> it's not a nice behavior
[06:55] <didrocks> sil2100: you can followup on the email thread
[06:57] <sil2100> didrocks: ok, it's not a big deal though, but still - at least my changelog entry would have mentioned all the install, multi-arch and packaging changes
[06:57] <didrocks> yeah
[06:57] <didrocks> but still
[06:58] <didrocks> especially from people telling on the ML that we are blocking them from releasing
[06:58] <didrocks> and when I answer that there was no block, no answer
[06:58] <didrocks> so I guess they should not spread FUD and act nicely
[06:59] <didrocks> FYI: seb is in a train, I'm merge and cleaning for him
[07:03] <sil2100> o/ Ok
[07:05] <sil2100> didrocks: should I m&c for thomi?
[07:05] <didrocks> sil2100: if we are low in silo, why not
[07:06] <didrocks> sil2100: seems gallery app has one reproducible failure
[07:06] <Mirv> sil2100: no hurry, but at least if we get low on silos
[07:06] <didrocks> sil2100: mind looking at it?
[07:06] <Mirv> FYI SDK team will have a preNEW request soon probably, I've been reviewing their new plugin package
[07:06] <sil2100> didrocks: on latest image, yes? Let me upgrade and check that :)
[07:06] <sil2100> Mirv: ok
[07:09] <didrocks> sil2100: yeah, latest and the one before
[07:09] <didrocks> Mirv: they need to ping the release team to ensure it's getting into the Touch FFe
[07:09] <didrocks> Mirv: but it seems less linked to it, so they will probably need a new one
[07:13] <circ-user-qlPK2> imgbot, status 283 flo
[07:13] <imgbot> Image 283 test results on flo - Total: 676, Pass: 671, Crashes: 4, Rate: 98.9%
[07:15] <bzoltan> didrocks: Mirv: line 66 is the one
[07:15] <didrocks> bzoltan: you need a FFe
[07:16] <didrocks> bzoltan: and get it accepted from the release team
[07:16] <bzoltan> didrocks:  it is granted and it is linked to the line
[07:16] <didrocks> bzoltan: oh nice! thanks :)
[07:16] <bzoltan> didrocks: better ask then miss :D
[07:16] <didrocks> yep ;)
[07:18] <sil2100> bzoltan: we would need links to merge requests though in the MR list ;)
[07:20] <Mirv> bzoltan: yep ^ merge requests instead of branch url:s
[07:28] <sil2100> dbarth: hi! Could we have a landing for those two branches? It would be nice to have un-broken packages in the archive before the release ;) ->
[07:28] <sil2100> https://code.launchpad.net/~robru/signon/trunk/+merge/210917
[07:28] <sil2100> https://code.launchpad.net/~sil2100/libaccounts-qt/fix_dev_conflict/+merge/211058
[07:29] <bzoltan> Mirv: OK
[07:29] <bzoltan> sil2100: sure
[07:31]  * Mirv publishes landing-009 now that it has finished rebuilding with the cosmetic packaging changes
[07:33] <sil2100> Mirv: \o/
[07:35] <bzoltan> sil2100: Mirv: all set ... I put Mirv as reviewer
[07:37] <Mirv> bzoltan: qtcreator itself is not a CI Train package, it should be uploaded separately via the "Additional source packages to land"
[07:37] <Mirv> the MP for it also claims a text conflict in debian/changelog
[07:37] <Mirv> (which seems correct, it's not in sync)
[07:38] <bzoltan> Mirv:  should I just remove that line or what?
[07:38] <Mirv> bzoltan: you should remove that line, fix the branch and add "qtcreator" to the next column. when you get the silo, you dput the qtcreator manually.
[07:38] <bzoltan> Mirv: Ahaaaaa.. dput manually ... I did not expect that one :D
[07:39] <Mirv> yes, that's for packages that are not ours / not in CI Train
[07:39] <sil2100> didrocks: huh, just ran the whole testsuite and had no failures on 283
[07:40] <sil2100> didrocks: let me try running the failing one a few times in a loop
[07:40] <didrocks> sil2100: weird, look at the dashboard… it failed yesterday and today :/
[07:40] <Mirv> bzoltan: silo assigned landing-003 (https://launchpad.net/~ci-train-ppa-service/+archive/landing-003)
[07:41] <Mirv> if you need the new qtcreator built there before the plugins, just dput the qtcreator there and don't hit the Build button yet
[07:41] <bzoltan> Mirv:  yes, that is what I need
[07:45] <sil2100> psivaa: morning! Out of curiosity, once you're around, could you maybe re-run the gallery-app test suite for the latest image?
[07:49] <sil2100> didrocks: ran the single test 10 times and it succeeded every time - let me try and maybe clean the gallery-app database, maybe it fails on a fresh one
[07:49] <sil2100> hm
[07:49] <sil2100> Actually wait, no
[07:49] <sil2100> Since it's anyway using its own database during tests
[07:52] <sil2100> didrocks: btw. any decision has been made regarding blocking the landings? Since I didn't see any announcement on the ML
[07:53] <didrocks> sil2100: not yet but near to it
[07:54] <didrocks> sil2100: I'll tell you during the meeting
[07:54] <didrocks> sil2100: maybe try to understand the error in the dashboard without reproducing? weird that it failed twice in a row
[07:54] <sil2100> didrocks: doing that this very instance
[07:54] <Saviq> didrocks, hey, we've a problem in silo 005, it doesn't upload u-s-c to the ppa for some reason https://ci-train.ubuntu.com/job/landing-005-1-build/18/console
[07:56] <didrocks> Saviq: 2014-04-09 07:50:36,003 INFO Grab code for unity-system-compositor (0.0.2+14.04.20140403-0ubuntu1) from trusty
[07:56] <didrocks> 2014-04-09 07:50:36,950 INFO Downloading unity-system-compositor version 0.0.2+14.04.20140403-0ubuntu1
[07:56] <didrocks> 2014-04-09 07:50:38,807 INFO No new useful revision published compared to dest, no need to upload this component
[07:56] <psivaa> sil2100: ack, let me do that
[07:56] <sil2100> psivaa: thank you :)
[07:56] <Saviq> didrocks, hmpf, so how do we do rebuild-only MPs?
[07:56] <didrocks> Saviq: force rebuild with the package name
[07:56] <didrocks> Saviq: as per the option descriptions
[07:56] <Saviq> didrocks, ah force rebuild
[07:57] <Saviq> didrocks, thanks
[07:57] <didrocks> yw
[07:59] <Mirv> bzoltan: actually, you'll need me to use the dput since you're not in the group that can upload. so once you have the fixed qtcreator branch, give it to me
[07:59] <Saviq> sil2100, could we get a prep silo for line 20? still can-be-flushed status
[07:59] <Mirv> didrocks: sync-monitor now in NEW queue
[08:03] <bzoltan> Mirv: LP just told me the same "Rejected: Signer has no upload rights to this PPA.  " :D
[08:07] <bzoltan> Mirv: I am pushing to lp:~bzoltan/kubuntu-packaging/qtcreator right now
[08:09] <sil2100> Saviq: sure! ACK
[08:09] <sil2100> Saviq: we have a bit more silos today so maybe it will be fine this time
[08:10] <didrocks> Mirv: yeah, I can't ack it though
[08:10] <didrocks> Mirv: needs to be the release team
[08:10] <didrocks> Mirv: I just +1 on the NEWing
[08:11] <Mirv> right, right
[08:19] <bzoltan> Mirv:  it takes ages to push the qtc branch to the lp
[08:19] <Mirv> bzoltan: you could have just dput:d to some other PPA where I could take it..
[08:20] <Mirv> still could
[08:20] <bzoltan> Mirv:  How true...
[08:20] <Mirv> if you're not near the 1GB push amount it takes
[08:20] <Mirv> for the branch
[08:25] <bzoltan> Mirv: https://launchpad.net/~bzoltan/+archive/qt5
[08:29] <Mirv> bzoltan: you didn't sync/fix the branch correctly, 3.0.1-0ubuntu3 is already in Ubuntu
[08:30] <bzoltan> Mirv:  I did merge from the trunk of the packaging branch
[08:30] <sil2100> didrocks: it seems to be a flaky test in gallery_app... re-run didn't have the failure
[08:30] <Mirv> bzoltan: yeah, but you added to the ubuntu3 changelog instead of creating a new ubuntu4 entry
[08:30] <bzoltan> Mirv:  I guess only the changelog is wrong then
[08:30] <didrocks> sil2100: can you infer what made it failing at first?
[08:30] <bzoltan> Mirv:  i did not know if the ubuntu3 landed alreadz ... sorry
[08:30] <sil2100> didrocks: yes, let me re-log to the meeting
[08:30] <sil2100> Since my firefox died...
[08:31] <Mirv> bzoltan: yeah only the changelog
[08:31] <Mirv> bzoltan: upload ubuntu4 there too, then, with your entry separated
[08:31]  * Mirv hangout
[08:31] <bzoltan> Mirv:  sorry... I guess you need to touch the changelog as the uploader should be you and not me
[08:38] <Mirv> bzoltan: no, I can sign your upload easily
[08:38] <bzoltan> Mirv: ohh.. that is handy
[08:40] <bzoltan> Mirv:  I have added a QtC-Ubuntu-plugin  MR too to the landing line, would you please reconfigure the silo after the QtC has built there ... it will take about 2 hours
[08:48] <mandel> sil2100, can you give me a quick hand, I pushed a fix in udm for silo 19 but I cannot trigger a build, could you do that for me?
[08:55] <mandel> or maybe didrocks, can you do that?? ^^
[08:55] <Mirv> bzoltan: do you have the ubuntu4 now somehwere? I'm soon done with the call
[08:56] <bzoltan> Mirv: https://launchpad.net/~bzoltan/+archive/qt5
[08:58] <ogra_> cihelp, i have a very weird CI failure on https://code.launchpad.net/~ogra/unity8/speed-up-indicator-startup/+merge/214779 (chroot times out all the time it seems)
[08:58] <didrocks> mandel: doing
[08:58] <didrocks> Mirv: sorry, we had our meeting
[08:58] <mandel> didrocks, sweet, thx!
[08:59] <Mirv> didrocks: no problem, I participated! :D
[08:59] <Mirv> (ha ha)
[08:59] <Mirv> bzoltan: now you removed the ubuntu3 entry, but I guess I'll just take that and fix manually
[08:59] <Mirv> now that I have time
[09:00] <didrocks> Mirv: arghhhhhhhhhhhh :)
[09:00] <didrocks> too many m :p
[09:00] <didrocks> it's a m plague
[09:00] <vila> ogra_: looking
[09:00] <bzoltan> Mirv: oh man ... I am hustling with that poor changelog
[09:00] <ogra_> thanks
[09:00] <ogra_> not sure if there is anything wrong on my side
[09:00] <vila> ogra_: that's otto for you not a chroot, digging
[09:01] <ogra_> the change is so trivial that i cant imagine it can cause CI failures
[09:02] <vila> ogra_: yeah, that's what make those changes interesting :)
[09:02] <sil2100> didrocks, psivaa: so, looking at the failure logs for gallery, it *looks* to me that the toolbar might have been invalidly unhidden or simply the click event for button-click wasn't correctly interpreted
[09:02] <ogra_> heh
[09:02] <sil2100> I'll fill in a bug anyway and poke someone, since it's a flakyness we'd like gone
[09:04] <didrocks> sil2100: thanks!
[09:04] <psivaa> sil2100: because of the fact that it fails when run with a lot of tests, 'mediaselector' could be slow coming up? ( i'm not very sure what that is but guessing that to be a selector from media library)
[09:04] <didrocks> sil2100: Mirv: going for some exercise before seb arrives home
[09:05] <psivaa> sil2100: and the library could be slow to come up when it has more files
[09:05] <psivaa> s
[09:05] <Mirv> ok
[09:05] <sil2100> didrocks: ok :)
[09:05] <sil2100> didrocks: have fun!
[09:06] <sil2100> psivaa: could be, but the timeout I think is 10 seconds - not sure if that's possible to take that long
[09:06] <Mirv> bzoltan: ok, qtcreator now building in landing-003 and silo also reconfigured so that you can click build after the umpteem hours it takes for armhf to build
[09:06] <sil2100> psivaa: and there's not that many files in there - my gallery-app after all tests has only 4 pictures
[09:06] <bzoltan> Mirv:  awesome! Thanks for standing my ignorance :)
[09:07] <davmor2> ogra_, didrocks: so I changed the permissions on the Image file and now it shows up in gallery,  However all the music and the videos show up in the scopes and music player so I'm assuming a change in the gallery app over a change in mediascanner but I could be wrong
[09:07] <psivaa> sil2100: yea it should not take more than 10 seconds. In the lab mediaplayer tests run before the gallery app test.
[09:08] <davmor2> ogra_: also do you have any idea how mpt will work on the tablet in a multiuser environment ?
[09:08] <ogra_> davmor2, well, if it is apt induced thats a really low prio bug ... people should use mtp for transferring media
[09:08] <ogra_> *adb
[09:08] <ogra_> tsk ...
[09:08] <ogra_> davmor2, nope
[09:08] <ogra_> ask me again once we have multiuser ... :)
[09:09] <davmor2> ogra_: we do have multiple users on tablet, you have one, popey has one, I have one :P
[09:09] <ogra_> i suspect we need to teach the different mtp-servers to detach/re-attach  with the user change
[09:09] <ogra_> but we will neeed multiuser support first to develop that
[09:09] <ogra_> haha
[09:10] <davmor2> ogra_: fair enough :)
[09:10] <sil2100> psivaa: oh, let me try that then - I'll run mediaplayer tests and then gallery
[09:18] <vila> ogra_: the otto host has been updated since your run, I triggered a rebuild first
[09:19] <ogra_> vila, thanks
[09:19]  * ogra_ crosses fingers
[09:21] <dbarth> morning
[09:21] <dbarth> sil2100: o/ on line 67 for an urgent landing of the new Facebook API key
[09:21] <dbarth> that's a one liner MP, but an important one...
[09:23] <sil2100> dbarth: looking
[09:23] <sil2100> Assigning!
[09:26] <dbarth> sil2100: thank you sir
[09:26] <dbarth> :)
[09:27] <sil2100> dbarth: silo 11, go for it o/
[09:30] <popey> davmor2: i only have a nexus 7 at the moment
[09:31] <sil2100> psivaa: sadly, even running mediaplayer tests before gallery didn't cause a problem on my local device
[09:31] <sil2100> Let me fill in a bug for that
[09:31] <psivaa> sil2100: ack, thx. wrong theory then :)
[09:56] <vila> ogra_: the job ended up on a different otto node (haha, trying to escape !), from the KVM, the node is up but nothing happens, digging inside the container
[09:57] <sil2100> didrocks, psivaa: just something to keep track of this: https://bugs.launchpad.net/gallery-app/+bug/1304950
[09:57] <ogra_> vila, ok
[10:01] <mandel> didrocks, I'm an asshole and I forgot to define a variable in the deb rules.. can you trigger a revuild in silo 19.. sorry sorry sorry
[10:05] <davmor2> popey: I was saying there were multiple tablet users rather than a multiuser tablet ;)
[10:05] <davmor2> morning all
[10:20] <vila> ogra_: 09:33:39.582 ERROR content:49 - Could not add content object 'None' due to IO Error: [Errno 13] Permission denied: '/var/log/syslog' rings a bell ?
[10:21] <ogra_> nope
[10:21] <ogra_> i have never committed anything to the branch, never seen its tests ... and the change that is there is a simple two line change to its upstart job
[10:21] <vila> ogra_: more context https://pastebin.canonical.com/108055/
[10:22] <vila> ogra_: right, looks like both of us know too little ...
[10:22] <ogra_> vila, "gnome-session" ?
[10:23] <ogra_> unity8 surely should run under a gnome-session when doing its tests
[10:23] <vila> ogra_: this is from /home/ubuntu/.cache/upstart/gnome-session-Unity.log
[10:23] <ogra_> Saviq, ^^^
[10:23] <ogra_> oh, thats unity7 ?
[10:23] <ogra_> no, the lines in the log all point to unity8
[10:23] <dbarth> sil2100: i have silo 8 ready, but, a question...
[10:23] <vila> ogra_: in the container and seems to be the last log changed (and contains something relevant)
[10:23] <dbarth> sil2100: i'd like to land it with other fixes for specific webapps (new MR set)
[10:24] <dbarth> sil2100: and osomon has a quick change for the browser as well, so we'd need 2 more silos again
[10:24] <dbarth> sil2100: should i repurpose silo 8 for the quick change (already tested, so it's a formality)
[10:25] <ogra_> "/var/local/autopilot//artifacts/unity8.shel
[10:25] <ogra_> l.tests.test_notifications.EphemeralNotificationsTests.test_update_notification_same_layout (Desktop Nexus 4).ogv'"
[10:25] <dbarth> sil2100: or land 8 but obtain 2 others to pass the rest and be sync'ed for the next image update
[10:25] <dbarth> ?
[10:25] <ogra_> desktop nexus 4 ?!?
[10:25] <vila> ogra_: wait, may be more stuff before that: https://pastebin.canonical.com/108058/
[10:26] <Saviq> ogra_, what am I looking at?
[10:26] <ogra_> Saviq, the CI test for my upstart job change
[10:26] <ogra_> for unity8
[10:26] <vila> Saviq: on an otto node
[10:27] <vila> Saviq: i.e. a desktop
[10:27] <ogra_> Saviq, it seems to do really weird things like firing up a gnome-session session to run unity8
[10:28] <Saviq> ogra_, yeah, otto does that
[10:28] <ogra_> ah, so thats normal
[10:28] <ogra_> i'm getting spammed by CI failures in the MP ... and i cant imagine the two line change of that MP can cause any test failures
[10:28] <Saviq> ogra_, Build timed out (after 60 minutes). Marking the build as failed.
[10:29] <ogra_> yeah
[10:29] <ogra_> thats what got me to poke vila
[10:29] <Saviq> otto's been rather unstable for us lately :/
[10:29] <ogra_> yeah
[10:29]  * Saviq kicked a rebuild
[10:30] <vila> Saviq: there is one running already
[10:30] <Saviq> vila, oh ok, aborting
[10:30] <vila> Saviq: but it seems stuck in the same way, I'm connected to the kvm and nothing happens there
[10:30] <Saviq> vila, mhm
[10:31] <vila> timeout expired
[10:32] <vila> Saviq: do you have a successful run handy for a version previous to ogra's one ?
[10:33] <sil2100> dbarth: one moment
[10:33] <Saviq> vila, http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/3978/
[10:33] <vila> Saviq: by 'otto's been rather unstable for us lately :/' you mean you re-run jobs until they pass or you have some way to avoid/workaround  the otto failures ?
[10:34] <vila> thanks, looking
[10:34] <Saviq> vila, no, we've had it fail all the time for quite some time, then it got fixed last night I think
[10:34] <sil2100> dbarth: hm, so I would say - you need to think about how urgent those changes are
[10:34] <Saviq> vila, and we've had a few green runs
[10:34] <Saviq> vila, and apparently it broke again
[10:34] <sil2100> dbarth: since, if you repurpose silo 8, in the end all the changes will land theoretically faster, but with the risk that if we spot a regression the whole merge set will be reverted (but that's low probability)
[10:35] <vila> Saviq: was fginther involved somehow ?
[10:35] <Saviq> vila, we weren't paying much attention to what happens with those jobs (like unlock scripts and such...), were relying on you guys to sort things out
[10:35] <Saviq> vila, I imagine so...
[10:35] <sil2100> dbarth: if we release silo 8 and you will add 2 more landings, stuff can take a bit longer as you know that currently webbrowser-app during each release is held up in UNAPPROVED
[10:36] <sil2100> dbarth: and then there's the migration which takes time, so it might be a bit longer in overall
[10:36] <vila> Saviq: still weird, the last container has been created 20140402-0754 so not yesterday...
[10:36] <Saviq> vila, yeah, but then there are the unlock scripts and such, which were rather picky lately...
[10:37] <didrocks> mandel: you don't have any lander in your timezone for your team?
[10:37] <vila> Saviq: for the phones not for otto right ?
[10:37] <Saviq> vila, uh, of course
[10:37] <Saviq> vila, so yeah, no unlocking in otto
[10:37] <didrocks> sil2100: Mirv: still catching up, can you look at mandel's request? ^
[10:37] <mandel> didrocks, not yet, sergiusens should be around soon, sorry
[10:37] <Saviq> vila, but yeah, I've lost track of what happened in there, I'm afraid :|
[10:37] <vila> Saviq: ack
[10:38] <dbarth> sil2100: ah the unapproved queue, right
[10:38] <sil2100> didrocks: looking
[10:38] <vila> ogra_: the trail is cold :-/ Will check with fginther , I'm not aware of changes on the CI side... so worth double-checking first with him
[10:38] <dbarth> sil2100: so then i could land 008, reload other silos, and ask for an approved once everything is ready
[10:39] <davmor2> popey:     sp.call(["adb", "shell", "chown", "-R", "phablet:phablet", "/home/phablet/Music"]) at the end of each  def that'll fix the permissions issue I believe :D
[10:39] <Mirv> didrocks: sure
[10:40] <davmor2> popey: obviously changing the Music for the relevant Folder :)
[10:40] <sil2100> mandel: do you need a rebuild for your silo?
[10:40] <ogra_> vila, whatever helps to make it pass :)
[10:40] <mandel> sil2100, yes, silo 19, it everything should be fine now :)
[10:40] <dbarth> sil2100: i think we can do that then
[10:40] <sil2100> mandel: rebuilding then ;)
[10:40] <sergiusens> mandel: for what?
[10:41] <dbarth> sil2100: you can land silo 8
[10:41] <mandel> sergiusens, ah, to click the rebuild button in silo 19, I found the issue with the signals and everything works great now :)
[10:41] <sil2100> mandel: what project do you want to rebuild in that silo?
[10:41] <dbarth> sil2100: and i'll add the new requests now
[10:41] <mandel> sil2100, ubuntu-download-manager
[10:41] <sergiusens> sil2100: no worries; I'll do it
[10:41] <sergiusens> sil2100: meh
[10:41] <sil2100> sergiusens: ok ;)
[10:42] <sil2100> dbarth: ok, so I'll land it, thanks o/
[10:42] <Mirv> bzoltan: adjusted your empty MP's commit message to include the bug number
[10:42] <bzoltan> Mirv: ohh.. sorry and thank you
[10:45] <Mirv> bzoltan: one more thing is needed, you need to add (for example using that join-CI branch) copyright headers to the files you added (not modified) ie. abstractremotelinuxrunconfiguration.h/cpp
[10:45] <Mirv> bzoltan: see eg. the Canonical copyright headers in qtcreator-plugin-cmake
[10:45] <bzoltan> Mirv:  OK, a sec
[10:49] <sergiusens> sil2100: are we good on silos? I have a rather quick one for phablet-tools to add the bootchart script on line 69
[10:49] <sil2100> didrocks: packaging ACK needed -> https://ci-train.ubuntu.com/job/landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_webbrowser-app_0.23+14.04.20140408.3-0ubuntu1.diff <- seems ok, a bit strange that the build-dep is not being bumped and only the binary package dep, but since it's qml-related, I think the build-dep is only cosmetic
[10:49] <Mirv> sergiusens: possible, adding
[10:49] <sil2100> sergiusens: we're much better today, let me take a look
[10:49] <sil2100> Oh, Timo already picked it up
[10:50] <sergiusens> thanks
[10:50] <sergiusens> it's just a script so should fly
[10:50] <sil2100> We love landings like that
[10:50] <sergiusens> and leaf packages are easier to test :-)
[10:51] <Mirv> sergiusens: landing-013
[10:51] <bzoltan> Mirv: done
[10:52] <didrocks> sil2100: yeah, let's say good enough
[10:53] <sergiusens> ty
[10:55] <didrocks> davmor2: do you have a bug # that I missed for the adb thingy?
[10:57] <sil2100> Mirv: wait with that webbrowser landing, I just published dbarth's other landing
[10:57] <davmor2> didrocks: no not yet I was going to go beat xnox round the head a bit but was doing other things bug filing is next on the list :)
[10:57] <didrocks> sure ;)
[10:57] <Mirv> sil2100: yeah, I just added the note there after trying to assign a silo. nice if other webbrowsers landings are landing
[11:01] <Mirv> didrocks: bzoltan would appreciate if you could do a preNEW review on lp:~bzoltan/qtcreator-plugin-remotelinux/join_the_train
[11:02] <vila> ogra_: I've re-created the lxc container and re-ran the job https://pastebin.canonical.com/108060/
[11:02] <vila> ogra_: out of the blue, I'll point a gentle finger to autopilot and ask for something a bit more explicit than '_StringException'
[11:02] <ogra_> vila, weird ... my change doesnt toouch any code there
[11:03] <vila> ogra_: oh, I have no idea if your code is the culprit, it may just be that another change somewhere else triggers that
[11:03] <ogra_> yeah
[11:04] <didrocks> Mirv: it's a copy of valgrind?
[11:04] <vila> ogra_: unless you can revert your change and kick a rebuild just to make sure it's indeed your code that triggers that ;)
[11:04] <Mirv> didrocks: it's a copy of multiple plugins, see the FFe https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620
[11:04] <vila> ogra_: but to me, this looks like AP see the failure and..... die in an unexpected way without telling anything in its own log...
[11:05] <Mirv> with a couple of modified files in the remotelinux pugin
[11:05] <didrocks> Mirv: ok
[11:05] <didrocks> Mirv: bzr bd doesn't work here, no source tarball
[11:06] <vila> ogra_: or is stuck somewhere and the stream I'm looking at is incomplete and produces this weird empty exception...
[11:06] <didrocks> Mirv: I guess it will use direct package upload?
[11:07] <Mirv> didrocks: hmm, weird, bzr bd worked fine for me. the idea was to build CI Train with that branch
[11:07] <vila> ogra_: yeah, it's stuck, it's still running according to 'ps fax'
[11:07] <ogra_> vila, right
[11:07] <ogra_> thats why it times out
[11:07] <didrocks> Mirv: you need to try to bzr branch in one directoy
[11:07] <didrocks> and just bzr bd
[11:07] <vila> ogra_: yeah
[11:07] <didrocks> Mirv: there is an empty line on top of an .install file
[11:08] <didrocks> in 2 actually
[11:08] <vila> ogra_: https://pastebin.canonical.com/108061/ stuck starting unity8 ?
[11:08] <didrocks> 3…
[11:08] <Mirv> didrocks: I was apparently testing different patch
[11:08] <Mirv> bzoltan: how come your branch does not have the fixes in the trunk?
[11:08] <didrocks> Mirv: the version in debian/changelog isn't UNRELEASED
[11:08] <ogra_> vila, initctl status unity8 (as the user under which upstart is running)
[11:08] <didrocks> should I hold on the review then?
[11:09] <bzoltan> Mirv:  which branch?
[11:09] <ogra_> vila, assuming AP actually properly uses upstart
[11:09] <bzoltan> Mirv:  the joining one?
[11:09] <vila> ogra_: err, requires sudo and: initctl: Unknown job: unity8
[11:09] <Mirv> bzoltan: oh, a correction. you didn't do the .bzr-builddeb addition I asked you in the morning. I did it locally so I didn't notice it's missing.
[11:10] <ogra_> vila, doesnt require sudo, but you need to beteh user owning the session
[11:10] <ogra_> *be the
[11:10] <bzoltan> Mirv:  Ohh... man... I am fucked up today
[11:10] <Mirv> bzoltan: also, address the comments above ^
[11:10] <vila> ogra_: then is says: Command 'initctl' is available in '/sbin/initctl'
[11:10] <vila> The command could not be located because '/sbin' is not included in the PATH environment variable.
[11:10] <vila> This is most likely caused by the lack of administrative privileges associated with your user account.
[11:10] <vila> initctl: command not found
[11:10] <Mirv> didrocks: yeah, so I didn't branch a clean branch, just watched Zoltan's changes. he'll add the .bzr-builddeb + fix the version to UNRELEASED in changelog
[11:10] <ogra_> how did you become that user ?
[11:11] <vila> ogra_: by 'owning... right
[11:11] <didrocks> Mirv: all short descriptions are the same
[11:11] <ogra_> su  wont work
[11:11] <vila> lxc-attach, su - ubuntu ;)
[11:11] <vila> ha
[11:11] <didrocks> Mirv: some long descriptions are the same as well
[11:11] <vila> hold on
[11:11] <Mirv> bzoltan: and handle those ^
[11:11] <Mirv> didrocks: right, I stared only lintian warnings, but the descriptions are wrong
[11:12] <vila> ogra_: silly me, no dash in the kvm, how to I start  a terminal there ?
[11:12] <Mirv> there were some copyright fixes already and many other fixes, but seems not everything was covered
[11:12] <vila> got it
[11:13] <vila> ogra_: unity8 start/pre-start, process 8698 (yay for no copy/paste >-/)
[11:13] <Mirv> didrocks: all long descriptions have variation, but the short ones have the cmake copy-pasted over and over
[11:13] <dbarth> sil2100, Mirv: protocol-wise, can i merge & clean silo 8 now? and get to line 67
[11:14] <ogra_> vila, hmm
[11:14] <ogra_> vila, so it hangs in the upstart job actually
[11:15] <vila> ogra_: leaving fingerprints somewhere I can look at ?
[11:15] <sil2100> dbarth: let me see what's the status of that silo
[11:16] <bzoltan> Mirv: didrocks: i have just added the .bzr-builddeb and changed the version to UNRELEASED in changelog
[11:16] <ogra_> vila, there should be a log in the users home under .cache/upstart/unity8.log
[11:16] <sil2100> dbarth: well... theoretically we could *force* this m&c if we're sure that it will land in the archive
[11:16] <dbarth> sil2100: unapproved queue, by i asked the release team to hold this one for now
[11:16] <dbarth> sil2100: it will land with the next change yes
[11:16] <sil2100> hmmmm
[11:16] <sil2100> didrocks: ^ what do you think?
[11:17] <didrocks> sil2100: what's the gain?
[11:17] <didrocks> the release team needs to hold that one?
[11:17] <vila> ogra_: none
[11:17] <didrocks> so why not rejecting it?
[11:17] <didrocks> then, we clean the silo
[11:17] <didrocks> and dbarth does a new landings with previous MP + the new ones?
[11:17] <vila> ogra_: https://pastebin.canonical.com/108062/
[11:17] <dbarth> didrocks: just because we have another webbrwoser-app change next
[11:18] <sil2100> didrocks: well, that was my proposition earlier, ot just add the new MRs to silo 8
[11:18] <dbarth> didrocks: or they can ack this one, and ack the other one right after
[11:18] <didrocks> dbarth: but, didn't you turned testing to yes?
[11:18] <didrocks> why should they block the current one?
[11:18] <dbarth> on silo 8 yes, tested last night
[11:18] <vila> ogra_: I can give you scope-registry.log instead: https://pastebin.canonical.com/108063/ ;)
[11:19] <vila> ogra_: but that's surely not the same thing ...
[11:19] <sil2100> dbarth: I think rejecting and blocking is not the right way, I would say - let's move it to -proposed and then m&c if we're sure if the package will have no problems moving to release
[11:19] <didrocks> I don't understand why the current version should be hold back…
[11:19] <sil2100> didrocks: ^
[11:19] <didrocks> in addition the message dropped in #ubuntu-release is certainly going to be unread
[11:19] <ogra_> WTF
[11:20] <ogra_> why did LP just log me out
[11:20] <dbarth> didrocks: just held because there are further updates; i wanted to avoid having them ack the current update, and 2h later do another one
[11:20] <vila> ogra_: new SSL cert ?
[11:20] <dbarth> didrocks: but maybe that's just the way to go
[11:20] <dbarth> didrocks: ie, can't optimize that
[11:20] <didrocks> dbarth: so, if you want to do that, cancel your current landing
[11:20] <didrocks> and rebuild with both
[11:20] <ogra_> and now it wants 2fa for my regular login !
[11:20] <didrocks> I can remove your package from the unapproved queue
[11:20] <ogra_> now thats annoying
[11:21] <dbarth> hmm, so it's better if we group them in silo8 you say
[11:21] <didrocks> yeah
[11:21] <dbarth> makes sense
[11:21] <dbarth> ok
[11:21] <didrocks> ok, rejecting from unapproved
[11:21] <didrocks> dbarth: please add your new Mps to silo8
[11:21] <didrocks> and rebuild
[11:22] <didrocks> dbarth: kicked out of proposed
[11:22] <vila> ogra_: right, the SSL issue kind of imply your password may have been compromised right ?
[11:22] <didrocks> well, unapproved*
[11:22] <Mirv> bzoltan: what about the empty lines in .install files?
[11:23] <ogra_> vila, yeah, indeed :P
[11:23] <dbarth> didrocks: thanks
[11:23] <Mirv> bzoltan: or the erronous descriptions?
[11:23] <didrocks> yw
[11:24] <vila> ogra_: lunch break here, keep me posted, since I re-created the lxc containers I don't think fginther have additional hints but will check nevertheless
[11:24] <ogra_> that would be good
[11:24] <ogra_> i still dont see a reason why my change should make it fail
[11:24] <ogra_> (and i actually just added the same change to a test install here without issues)
[11:25] <dbarth> didrocks: silo ready for a reconfig; i resetted the test plan, bug list and test indicator
[11:27] <didrocks> dbarth: all is fine, you can reconfigure yourself as long as you didn't add new components
[11:27] <dbarth> sil2100: o/ silo 11 is ready for publication
[11:28] <dbarth> didrocks: ah sure
[11:28] <bzoltan> Mirv:  that one too
[11:28] <sil2100> dbarth: thanks o/
[11:31] <sil2100> hmmm, interesting
[11:34] <sil2100> dbarth, didrocks: does anyone of you know what happened with account-plugins version 0.11+14.04.20140401-0ubuntu1? trunk has that version released by the CI train, but it's not in the archive
[11:35] <sil2100> didrocks: because of that ^ the packaging diff for the new version is bigger, since it has 2 versions in it: https://ci-train.ubuntu.com/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_account-plugins_0.11+14.04.20140409-0ubuntu1.diff
[11:36] <sil2100> didrocks: the actual change from the landing is a one-liner in debian/rules, but here it also presents the changes from the previously released (and missing from the archive?) version
[11:37] <sil2100> Ah, ok, I see it got rejected
[11:37] <sil2100> didrocks: it's in the rejected queue
[11:38] <Mirv> didrocks: ok you could do bzr pull in the remotelinux branch, Zoltan addressed the issues
[11:41] <dbarth> sil2100: why rejected?
[11:41] <dbarth> mardy: can you see if there is an issue with the release please ^^
[11:42] <sil2100> dbarth: that's something that I do not know and would like to know, I don't see any 'reason' field in the rejected queue...
[11:43] <sil2100> https://launchpad.net/ubuntu/trusty/+queue?queue_state=4&queue_text=account-plugins
[11:44] <didrocks> sil2100: I wonder then why it was merged?
[11:44] <sil2100> Indeed, gm
[11:44] <sil2100> hm
[11:44] <didrocks> the previous version
[11:44] <sil2100> Let me try looking into the logs
[11:44] <didrocks> Mirv: sure
[11:45] <mardy> sil2100: oh, so confusing...
[11:45] <mardy> sil2100: so, the previous version didn't land, because the lander wanted some additional changes
[11:46] <sil2100> didrocks: https://ci-train.ubuntu.com/job/landing-007-3-merge-clean/2/console
[11:46] <mardy> sil2100: which I did in https://code.launchpad.net/~mardy/account-plugins/lp1299659/+merge/213415
[11:46] <sil2100> didrocks: so, it seems dbarth set the ignore flag and merge&cleaned it when it wasn't yet released
[11:46] <mardy> sil2100: why trunk has an older version of those changes, beats me
[11:46] <bzoltan> Mirv: the Silo3 is ready.. would you please reconfigure the Silo to take the qtc-u-p mr too?
[11:46] <didrocks> grumpf
[11:46] <didrocks> dbarth: why? ^
[11:47] <mardy> sil2100: anyway, what we want is to have both https://code.launchpad.net/~mardy/account-plugins/lp1299659/+merge/213415 and https://code.launchpad.net/~mardy/account-plugins/lp1304798/+merge/214901 merged into trunk and released
[11:47] <sil2100> dbarth: do you remember why you m&c the account-plugins with the 'ignore' flag?
[11:47] <sil2100> mardy: yes, we know, we just want to figure out what happened, since there archive != trunk right now, which should not happen
[11:48] <mardy> sil2100: yep
[11:48] <dbarth> i don't remember doing that
[11:49] <dbarth> i set the ignore flag for building after a reconfig generally
[11:49] <Mirv> bzoltan: like I said earlier, it was already reconfigured
[11:49] <dbarth> i did not for this release of account-plugins
[11:49] <dbarth> and probably not for the previous one either
[11:50] <dbarth> ignore flag set, buh
[11:51] <bzoltan> Mirv: i started the build
[11:53] <sil2100> hum, now it will be hard to figure out why that happened
[11:54] <sil2100> didrocks: do you know if we can somehow get any information about the reason that package got thrown into the rejected queue?
[11:54] <davmor2> didrocks: oh https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1300326 looks like the fix is in QT is this ina silo somewhere?
[11:54] <sil2100> didrocks: since basically we'll release all the changes now - and because of that I would like to know what were the reasons previously it wasn't 'fit for the archive'
[11:54] <didrocks> yeah
[11:54] <didrocks> let me see
[11:56] <didrocks> sil2100: no, it's not published apparently
[11:57] <didrocks> sil2100: so I guess poking the release team
[11:57] <sil2100> I'll try poking then
[11:58] <seb128> hey there
[11:58] <seb128> could be useful to archive some of landed entries from the CI train table
[11:58] <seb128> having to scroll through all the noise is not optimal
[11:59] <sil2100> seb128: hi! Indeed, but at least you have that nice 'green' feeling while doing that ;) Green is nice!
[11:59] <seb128> hehe
[11:59] <dbarth> didrocks, sil2100: i don't know what happened; trying hard to remember why i apparenty set the ignore flag
[11:59] <sil2100> sergiusens: publishing 13
[11:59] <dbarth> are you guys able to recover that error?
[12:00] <sil2100> didrocks: packaging change made by a core dev, auto-packaging-ACKing ;)
[12:00] <sil2100> didrocks: (for landing 13)
[12:01] <didrocks> sil2100: good :p
[12:02] <sil2100> ;p
[12:02] <mardy> sil2100: I know why the package was rejected: the dpkg-maintscript-helper lines were missing the version number
[12:02] <mardy> sil2100: if you compare trunk with https://code.launchpad.net/~mardy/account-plugins/lp1299659/+merge/213415, you'll see they differ
[12:02] <mardy> sil2100: IIRC, it was infinity who rejected it
[12:03] <sil2100> Oh
[12:06] <sil2100> mardy: hmmm, so, if that was the reason, then the current landing would be rejected as well ;/
[12:06] <mardy> sil2100: yes, we need both https://code.launchpad.net/~mardy/account-plugins/lp1299659/+merge/213415 and https://code.launchpad.net/~mardy/account-plugins/lp1304798/+merge/214901
[12:08] <sil2100> mardy: the current landing doesn't have that branch in it and the packages still have the wrong maint scripts...
[12:08] <sil2100> dbarth: ^
[12:10] <sil2100> didrocks: so, hm, to make sure infinity's reasoning was correct, could you take a peek at https://ci-train.ubuntu.com/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_account-plugins_0.11+14.04.20140409-0ubuntu1.diff and the dpkg-maintscript-helper lines to make sure it's a -1 ?
[12:10] <vila> ogra_: weird, what could be the difference then ? What kind of test install do you use ? otto is a container on top of bare metal to access the graphical card.
[12:11] <ogra_> vila, i use a phone and replace the two lines in the upstart job ... then i reboot and find unity8 working fine
[12:11] <vila> ogra_: wow, yeah, lots of differences then ;)
[12:12] <ogra_> vila, because yours is not working fine ?
[12:12] <ogra_> :P
[12:12] <vila> ogra_: yeah, for your MP ;-p I see other runs happily running their tests and animating the kvm ;)
[12:14] <sil2100> In the meantime, I go fry some meat
[12:14] <sil2100> bzoltan: will look into publishing your latest landing in a moment
[12:15] <sil2100> bzoltan: just to make sure - did you check if  running your silo and gallery-app AP test result in a success? ;)
[12:15] <didrocks> sil2100: hum, because it's a +1 for you?
[12:17] <sil2100> didrocks: just want to confirm it's still -1 ;) I didn't use dpkg-maintscript-helper too much so I don't yet know the consequences of not providing the version number - some core-dev had to +1 it so that it landed in -proposed, so it's probably a 'mixed-opinion' thing
[12:18] <ogra_> vila, should i kill the MP and re-try ? (not sure thats easily possible, i guess Saviq needs to reject it or so)
[12:19] <sil2100> didrocks: besides the dpkg-maintscript-helper doubt, everything else looks ok to me
[12:19] <mardy> sil2100: the -1 is because without the version number the script will be run every time the package updates
[12:20] <didrocks> sil2100: I'm quite unsure, I would say missing numbers
[12:20] <mardy> sil2100: it's not a big issue, but with the version it's better
[12:20] <didrocks> sil2100: and it would be better if they use the .maintscript helpers
[12:21] <vila> ogra_: either click the rebuild url or push a new revision, no need to kill the MP I think
[12:21] <cjwatson> helpers> agreed
[12:22] <cjwatson> it's quite easy with dh_installdeb's built-in support nowadays
[12:22] <cjwatson> and yeah, I would include the version numbers otherwise it's basically a time-bomb for future weirdness
[12:22] <sil2100> cjwatson, didrocks: thanks, so I'm -1'ing it for now
[12:23] <cjwatson> just make sure to use the right prior version as it's not entirely intuitive; it's best to identify the first version for which the operation *isn't* required and then append ~ to it
[12:23] <vila> ogra_: but unless you have some change to try, I think we should wait for fginther and see if there is an otto node we could give you access too to debug. If it's upstart/lxc related (not sure why I have a feeling it's lxc related) I'm a bit out of my league
[12:24] <ogra_> vila, i have no clue what to debug ... it is not my code, i dont know the tests etc ... i just contributed a fix to an upstart job
[12:27] <vila> ogra_: :-/ Since some jobs succeed, it's hard to say otto is broken... Who can debug then ? AP guys ? upstart guys (random failure to start unity8) ?
[12:27] <ogra_> well, it clearly works in real world testing
[12:28] <ogra_> so upstart should be fine
[12:28] <ogra_> unity8 too
[12:28] <ogra_> that only leaves AP or CI/otto
[12:28] <ogra_> or there is something wrong with  the MP
[12:28] <ogra_> (though i woudnt know what)
[12:28] <sil2100> didrocks: eeek! Did you see the spreadsheet? The UID is used instead of the silo number now!
[12:28] <didrocks> sil2100: yeah, I'm adding a new field
[12:29] <didrocks> so just wait for 5 minutes
[12:29] <sil2100> ;D
[12:29] <sil2100> Phew ;) Thought someone else was meddling in the spreadsheet fields
[12:29] <vila> ogra_: well, the two otto nodes your MP fail on had successful runs 37 and 25 mins ago...
[12:29] <vila> ogra_: AP ftw ?
[12:29] <ogra_> no idea, really
[12:30] <ogra_> this MP takes more time and attention than i'm willing to give it :(
[12:30] <seb128> sil2100, so, what about archiving those landed lines?
[12:31] <didrocks> sil2100: should be fixed now
[12:46] <sergiusens> sil2100: Mirv is unity-scope-click currently locked?
[12:47] <sergiusens> or let me ask this in a better way, is there a place we can check what currently is locked?
[12:50] <sil2100> seb128: I don't know how to archive those ;) It's usually either Didier doing that, or it's somehow automated
[12:50] <sil2100> sergiusens: yes
[12:50] <sil2100> sergiusens: I mean, yes, you can check that:
[12:51] <sil2100> sergiusens: on the spreadsheet, look at the top row, column F - hover over it and you get a list
[12:51] <sergiusens> ok, thanks
[12:51] <sil2100> sergiusens: doesn't look like unity-scope-click is locked, so you can request a landing
[12:52] <sergiusens> sil2100: I need a rebuild actually, mandel change the abi (for testing sake)
[12:52] <mandel> sil2100, the ABI of udm changes and the click scope is affected, that is all
[12:53] <sergiusens> sil2100: can you reconfigure silo 19 please?
[12:53] <sil2100> sergiusens: doing that :)
[12:56] <sil2100> sergiusens: hm, could you wait a moment with the reconfigure?
[12:57] <sil2100> sergiusens: since we seem to have some spreadsheed modifications ongoing, which basically disables us from doing stuff
[12:57] <seb128> sil2100, time to learn how to do that I guess ;-)
[12:58] <sil2100> didrocks: is everything already prepared after adding that one column? Since prepare jobs fail to find the UIDs I guess, they're probably looking for it in the wrong column?
[12:58] <didrocks> sil2100: oh oh oh
[12:58] <didrocks> yeah
[12:58] <didrocks> let me change that
[12:58] <sil2100> Thank you :)
[13:02] <didrocks> sil2100: better?
[13:04] <bfiller> didrocks, sil2100, Mirv: thanks for help on the silo 9
[13:04] <didrocks> bfiller: yw!
[13:04] <bfiller> didrocks: who would be best to ping on release team for the FFE?
[13:04] <didrocks> bfiller: just ask on #ubuntu-release directly
[13:04] <didrocks> they are reading it
[13:04] <bfiller> ok
[13:04] <didrocks> you can tell I've done the archive admin review
[13:05] <bfiller> didrocks: ok, it's just for sync-monitor right? I notice the status for folks says unapproved and wasn't sure about that one
[13:06] <didrocks> bfiller: yeah, folks will be reviewed like the other components that are not Touch-specific
[13:06] <didrocks> (seeded on desktop for instance)
[13:06] <dbarth> sil2100: so i lost silo 8 content and couln't add the other branch because of a conflict, but i've now filled silo 8 with extra branches
[13:07] <dbarth> sil2100: in short i need a reconfig override ;)
[13:07] <dbarth> did you get closure on my account-plugins error?
[13:07] <dbarth> mardy: ^^ ?
[13:11] <sil2100> dbarth: give me some moments
[13:11] <sil2100> didrocks: checking
[13:11] <sil2100> didrocks: better \o/
[13:12] <didrocks> great!
[13:12] <dbarth> ok
[13:19] <rsalveti> ogra_: just a heads up that I'm doing another i386 image build
[13:19] <Mirv> sil2100: didrocks: robru: landing-014 has now building qtdeclarative with a fix to the bug #1300326 blocker bug. if nothing else, I'll start the AP tests in the morning after it has built (armhf takes ~2.5h from now)
[13:19] <ogra_> rsalveti, ok
[13:19] <Mirv> but surely it could be tested by landed by US timezone people too, after it has built
[13:20] <sil2100> Mirv: ok, thanks :)
[13:21] <sil2100> dbarth: so... let me try and get up-to-date on the situation of silo 8
[13:21] <t1mp> sil2100: hello
[13:21] <sil2100> dbarth: so, webbrowser-app that got published in the morning got rejected, right?
[13:22] <dbarth> sil2100: yes
[13:22] <t1mp> sil2100: you were checking the failures in gallery-app autopilot tests yesterday right?
[13:22] <dbarth> sil2100: we lost those good packages unfortunatley
[13:22] <t1mp> sil2100: before you reverted the ubuntu-ui-toolkit landing
[13:22] <dbarth> sil2100: and we're going to rebuild (and retest) just the same
[13:22] <dbarth> + some other packages that are ready and i would like to pass at the same time
[13:22] <sil2100> t1mp: hi! I was just looking at them briefly, and trying out Leo's fix before reverting UITK
[13:24] <sil2100> dbarth: so, in other words, you need now a reconfigure, right? ;)
[13:24] <t1mp> sil2100: with my branch (that was reverted) I cannot reproduce the bug on my desktop, only if I pass a wrong QML2_IMPORT_PATH, see http://pastebin.ubuntu.com/7226193/
[13:24] <ogra_> vila, i have removed my branch and re-proposed it as https://code.launchpad.net/~ogra/unity8/speed-up-indicator-startup/+merge/214944 ... lets see
[13:25] <sil2100> t1mp: we're not testing it on the desktop, since we're running all the tests on mako devices - maybe that's the reason?
[13:25] <t1mp> sil2100: do you know if somehow on the device or in jenkins, an alternative path is set?
[13:25] <dbarth> sil2100: yes
[13:25] <dbarth> sil2100: to put it simply
[13:25] <sil2100> hmmm
[13:25] <t1mp> sil2100: yeah makes sense, I need to test it on device to see what it does there
[13:25] <sil2100> t1mp: not sure, will try checking that in a moment
[13:25] <t1mp> sil2100: I'll try it on the device as well, but I wonder why on desktop I only get that failure when I pass the wrong qml2 path
[13:26] <sil2100> dbarth: ok, phew, reconfigured - you can try re-building now and seeing if all is ok
[13:28] <dbarth> sil2100: thank you
[13:42] <Mirv> sil2100: spreadsheet broken regarding everything "Landed"?
[13:43] <sergiusens> sil2100: is mine reconfig as well?
[13:44] <sil2100> sergiusens: ah, yes o/
[13:44] <sergiusens> ty
[13:45] <sergiusens> mandel: https://ci-train.ubuntu.com/job/landing-019-1-build/13/console
[13:46] <mandel> seb128, sweet
[13:46] <mandel> sergiusens, ^^
[13:47] <mandel> seb128, ups.. sorry
[13:47] <mhr3> sil2100, silo for 70 pls?
[13:47] <seb128> mandel, no worry
[13:51] <sil2100> mhr3: looking!
[13:53] <sil2100> sergiusens: hmmm, wait a moment, something doesn't seem right
[13:53] <Mirv> I guess the spreadsheet is just struggling with the code/field changes a bit
[13:53] <sil2100> sergiusens: ah, no, wait, nevermind
[13:54] <sil2100> mhr3: sadly, it seems unity-scope-click is already locked by a landing from Sergio
[13:54] <Mirv> it also doesn't pick the fact that there's a watch only build ongoing for landing-014
[13:54] <sil2100> didrocks: is the status refreshing disabled on the spreadsheet right now?
[13:54] <didrocks> Mirv: oh really? which line?
[13:54] <didrocks> no
[13:54] <didrocks> should work
[13:55] <didrocks> I changed the field
[13:55] <didrocks> nothing is updating?
[13:55] <sil2100> didrocks: since landing-015 also didn't update the status
[13:55] <sil2100> Same as the list of locked components
[13:55] <sil2100> hmmm
[13:55] <mhr3> sil2100, hmm, mandel what's the status there? the landing seems pretty red
[13:55] <mhr3> seems to be just a rebuild landing, maybe we could ignore it
[13:56] <mandel> mhr3, it is just a rebuild because there is a change in the ABI of udm
[13:56] <mandel> mhr3, and we want to test udm + ofono + mms support on the phone and not have a phone without the click scope working so that we can do its test plan too
[13:56] <mhr3> mandel, hm, i thought things are talking to udm via dbus
[13:57] <mandel> mhr3, the click scope using a qt lib that was updated in udm to add support for some extra methods they requested
[13:57] <Mirv> didrocks: yeah, feels like nothing is updating
[13:57] <Mirv> now the "Landed" are back though
[13:57] <Mirv> didrocks: but it might be some events were just lost, and now only new changes are noticed?
[13:57] <mhr3> mandel, anyway, how much time to we have till you get it to build properly?
[13:58] <Mirv> so the fact that https://ci-train.ubuntu.com/job/landing-014-1-build/9/console is running is just not visible
[13:58] <mhr3> s/to/do/
[13:58] <mandel> mhr3, build properly what? udm is already fixed and should build ok in all archs AFAIK
[13:58] <mhr3> mandel, the silo says, failed to build, asking when will it succeed
[13:59] <sil2100> mhr3: the spreadsheet might not be updated correctly...
[13:59] <sil2100> mhr3: so, it might be built correctly now even, just the spreadsheet still has the old status... let me check
[13:59] <mandel> mhr3, it failed on arm64 and there is a package for all other platforms in the silo https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+packages
[13:59] <mandel> mhr3, and I have already pushed the fix for the arm64
[14:00] <sil2100> mhr3: it's building right now
[14:00] <sil2100> mandel: ^
[14:00] <mandel> https://ci-train.ubuntu.com/job/landing-019-1-build/13/console
[14:00] <sil2100> So we'll know in some time if it's alright now
[14:00] <mandel> exactly
[14:00] <mhr3> sil2100, mandel, ok, so i'll wait instead of asking for ignore conflicts
[14:01] <mandel> mhr3, I'm trying to land this because it is needed to fix a critical bug in the click scope AFAIK
[14:02]  * Mirv reruns landing-014 build/watchonly
[14:04] <didrocks> I'm looking…
[14:06] <didrocks> do you know which silo was used for line68?
[14:06] <didrocks> sil2100: Mirv? ^
[14:06] <didrocks> it's the one at fault
[14:07] <Mirv> no, I don't know about that landing
[14:08] <sil2100> Let me look
[14:09] <sil2100> 68?
[14:09] <sil2100> Let me try recalling that
[14:09] <sil2100> didrocks: silo 13 it was
[14:10] <Mirv> yeah just found it too, https://ci-train.ubuntu.com/job/landing-013-2-publish/9/console
[14:10] <didrocks> Mirv: sil2100: back to normal now
[14:10] <didrocks> yeah, did the same :p
[14:10] <sil2100> As per https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text=phablet-tools <- ;)
[14:10] <Mirv> yes, "Building" shows now
[14:10] <sil2100> \o/
[14:10] <sil2100> didrocks: what was wrong?
[14:10] <Mirv> sil2100: oh, an intelligent method instead of brute force..
[14:10] <sil2100> Did I break anything while publishing?
[14:10] <didrocks> sil2100: nice trick!
[14:10] <sil2100> Mirv: ;)
[14:10] <didrocks> sil2100: the siloname field contained "landed"
[14:11] <didrocks> instead of the real status
[14:11] <didrocks> so it looked for a reference of an unexisting sheet
[14:11] <didrocks> and so, the sync script failed
[14:11] <sil2100> Ahh
[14:11] <sil2100> Ouch
[14:24] <fginther> Saviq, can you make anything out of these IO error messages here: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/4036/artifact/results/upstart/gnome-session-Unity.log/*view*/
[14:26] <Saviq> fginther, if I had to guess... dbus issues?
[14:28] <fginther> Saviq, hmm. I assume that could be unrelated to unity8 not starting. The best I can tell, the autopilot test tries to run, but I'm not seeing any indication that ever starts
[14:28] <fginther> 'that unity8 ever starts'
[14:33] <sil2100> dbarth: regarding landing line 66, please at least try to integrate mardy's https://code.launchpad.net/~mardy/account-plugins/lp1299659/+merge/213415 branch (at least the parts from the post* and pre* scripts) - or maybe poke some core-dev to give advice on how to fix it 'better'
[14:34] <sil2100> dbarth: then, after rebuilding, we can publish silo 11 without worrying about a rejection in the archive
[14:34] <sil2100> dbarth: thanks :) !
[14:36] <Laney> sil2100: Make a package.maintscript file and you don't have to edit maintainer script manually.
[14:36] <Laney> See man dh_installdeb
[14:37] <Laney> If you do edit them you should put #DEBHELPER# in there so that debhelper can insert its code (man debhelper)
[14:38] <sil2100> Laney: ah, right, that can be done as well, dbarth ^ :)
[14:38] <sil2100> Laney: thanks!
[14:43] <Saviq> fginther, as in the process is started, but no UI displayed?
[14:44] <mandel> sil2100, mhr3 all build except for ppc64el ar ok, and that one failed due to one of the integration tests not being able to talk with the local http server which is not an issue at all
[14:44] <mandel> sil2100, mhr3 I'll add a bug so that if that happens the test is skipped so that the packaged can be built
[14:47] <sil2100> mandel: ACK, thanks
[15:05] <Laney> robru: would you please include DEP-3 patch headers when adding debian patches to packages? It makes it so that the next person who comes to merge or update the package can see what the patch is about. (syncevolution in this case)
[15:06] <dbarth> sil2100, Laney: ok, will pass on the recommendation
[15:12] <seb128> sil2100, so, are you looking at cleaning the landed lines? did you ask didrocks about it?
[15:14] <sil2100> seb128: not yet, let me poke didrocks now
[15:15] <sil2100> didrocks: how does the archiving of landings work?
[15:15] <sil2100> didrocks: I didn't see a menu script for that - is there a function in the scripts that does it?
[15:15] <didrocks> sil2100: yeah, it's unfortunately manual for now
[15:15] <sil2100> Do I have to run it manually, or maybe this is 100% manual?
[15:15] <didrocks> sil2100: you copy/paste (use the "paste values only") from one sheet to another
[15:15] <sil2100> Ok
[15:15] <didrocks> and then delete the line at the source
[15:16] <sil2100> o/
[15:16] <sil2100> Doing
[15:16] <sil2100> didrocks: thanks :)
[15:16] <didrocks> thanks
[15:18] <ogra_> fginther, do you have any idea about https://code.launchpad.net/~ogra/unity8/speed-up-indicator-startup/+merge/214944 ? there is no reason at all that jenkins should fail (the two line chnage works fine in real world testing)
[15:23] <jhodapp> didrocks, just a heads up, we're going to want to land media-hub today
[15:23] <didrocks> jhodapp: great! you got the FFe? (maybe check with the release team to ensure it's covered for them through the Touch FFe)
[15:24] <jhodapp> didrocks, we already have an FFe approved specifically for it
[15:24] <didrocks> jhodapp: and add it to the bug list if it's the case to the bug
[15:24] <didrocks> ah good!
[15:24] <jhodapp> didrocks, which bug list?
[15:24] <didrocks> jhodapp: if you have a FFe, you don't need it
[15:24] <jhodapp> ok great
[15:25] <sil2100> Ah
[15:25] <sil2100> didrocks: are you working on the line from silo 007 ;p?
[15:25] <sil2100> didrocks: since I think I was reverting your work or something by accident ;p
[15:25] <didrocks> sil2100: argh, that explains
[15:25] <didrocks> sil2100: yeah, don't publish it
[15:25] <sil2100> didrocks: since I saw it being 'REF?' error, so I wanted to fix it, but I see now that you're on that column :<
[15:25] <didrocks> please
[15:25] <fginther> ogra_, I'm looking into it. I'm not convinced that the 2 line change is the issue.
[15:26] <didrocks> sil2100: the testing isn't done on it
[15:26] <didrocks> I was looking for a line with nobody touching it :p
[15:26] <sil2100> didrocks: ok, no worries, didn't intend to
[15:26] <sil2100> ;)
[15:26] <ogra_> fginther, i'm convinced it isnt :)
[15:26] <didrocks> sil2100: trying to get the support
[15:26] <sil2100> I just played with the spreadsheet
[15:26] <didrocks> for QA sign of
[15:26] <sil2100> Ok
[15:26] <ogra_> so we are at least on the same page :)
[15:26] <didrocks> formulas are going to make me mad!
[15:27]  * sil2100 doesn't touch the formulas now, because he accidentally became didrocks poltergeist
[15:27] <sil2100> Changing back his changes ;p
[15:28] <sil2100> seb128: spreadsheet cleaned, should be a bit better now
[15:31] <seb128> sil2100, thanks
[15:32] <plars> dbarth: ping
[15:33] <plars> dbarth: I'm going through some old notes and had taken a look at the cordova tests some time ago, but iirc there was some problem with them at the time. I'm taking a look again and see 2 failures in the latest image. I've only run them once though
[15:33] <plars> dbarth: is that something we still care about running on the daily images?
[15:35] <plars> cordova_ubuntu.tests.test_mobilespec.TestMobileSpec: test_file and test_storage were the two failures, but I saw there was a unity crash, so it could have just been related to that
[15:36] <didrocks> sil2100: ok, support for QA sign of is in!
[15:38] <sil2100> Oooh!
[15:41] <didrocks> Saviq: nobody reviewed https://code.launchpad.net/~aacid/unity8/delegateRangeNeedsOriginY/+merge/214757?
[15:41] <didrocks> Saviq: sad I have to pull to get updates on bugs :/
[15:42] <Saviq> didrocks, AM LOOKING :P
[15:43] <Saviq> didrocks, we're actually doing other work, too, I'm afraid, especially when we're on a sprint here
[15:43] <didrocks> Saviq: yeah, I wonder how blockers are dealt… the release is just a week away
[15:43] <didrocks> but I guess it's something more for the management
[15:44] <bzoltan> didrocks:  if I reconfigure the silo ... will it remove the package what was additionally dput there or not?
[15:44] <Saviq> bzoltan, no
[15:44] <didrocks> bzoltan: no, it won't
[15:44] <didrocks> well
[15:44] <bzoltan> didrocks: Saviq: thanks!
[15:44] <didrocks> if you removed from the list
[15:44] <didrocks> it will :)
[15:44] <didrocks> remove*
[15:44] <didrocks> so if you remove a component, it will detect that
[15:44] <didrocks> and think "let's remove it"
[15:45] <bzoltan> didrocks:  all right, thanks
[15:48] <plars> dbarth: next time I ran it, it was test_file and test_network, and there was no crash file for unity8
[15:50] <dbarth> plars: cordova? probably outdated, since its folded into html5 now
[15:50] <dbarth> plars: do you have a pointer
[15:50] <dbarth> ?
[15:50] <plars> dbarth: a pointer to what, the results?
[15:50] <plars> dbarth: I just ran them locally. I can send you a junit xml file if that helps
[15:50] <mhr3> didrocks, you're missing an 'f' in the spreadsheet... :P
[15:51] <mhr3> "sign off"
[15:51] <dbarth> plars: yes, which tests are your running? cordova-ubuntu autopilot something?
[15:51] <mhr3> makes some of the asks look like "no sign of QA needed"
[15:52] <plars> dbarth: yes
[15:52] <dbarth> plars: i think that they point to the old cordova 2.8 runtime, so we should drop and replace with a newer test suite
[15:54] <dbarth> plars: asking zaspire (the maintainer) to share cordova medic test results with you to ensure that this runtime works properly with the current image
[15:55] <plars> dbarth: cordova medic?
[15:57] <dbarth> plars: automated testsuite from the cordova upstream project
[15:58] <plars> dbarth: is that packaged? Or can it be swapped out with cordova-ubuntu-autopilot if it's more appropriate as a test?
[15:59] <dbarth> plars: unfortunately not, it's a whole cloud instance, runs a ton of nodejs and whatnot
[15:59] <dbarth> plars: but we should put that on a public ip as a dashboard
[16:00] <dbarth> plars: will send an email to put you in touch and get that moving
[16:00] <didrocks> mhr3: ah, so, there is 2!
[16:01] <didrocks> mhr3: ok, will replace :p
[16:02] <didrocks> cyphermox: robru: coming?
[16:02] <plars> dbarth: that sounds like an entirely different animal from the autopilot tests we normally run. Is there any plan to fix up the existing AP tests? It looks like most of them pass fine
[16:05] <didrocks> mhr3: sign off has 2 f now!
[16:06] <didrocks> thanks :p
[16:07] <mhr3> didrocks, awesome, makes everything else moot, we're ready for release now :)
[16:07] <dbarth> plars: done
[16:08] <dbarth> plars: it's a different animal, the AP / click test suite still makes sense; maxim and victor should resume work on that
[16:08] <didrocks> mhr3: heh
[16:08] <didrocks> rsalveti: are you going to rebuild an image soon?
[16:08] <didrocks> we can get an armhf one if needed
[16:08] <rsalveti> didrocks: not planning to build one, but can do if you want
[16:09] <rsalveti> are we waiting any other landing?
[16:09] <rsalveti> otherwise we can do a new build now that we're in traincon-0
[16:12] <ogra_> fginther, is there any way to get my MP above to pass the bot ?
[16:12] <ogra_> or is there a general issue with unity8 landings
[16:13] <fginther> ogra_, the only way to get it past the bot right now is to disable that test.
[16:13] <ogra_> rsalveti, i dont know what happens with img numbering if you build i386 alone, thats why i asked didrocks to coordinate with you, we should probably build both arches at the same time if possible
[16:14] <fginther> ogra_, I've tested unity8 trunk and it also fails miserably, but with a different signature
[16:14] <ogra_> ok
[16:14] <rsalveti> ogra_: yes, then we should *always* build both together
[16:14] <ogra_> so there is something fishy
[16:14] <ogra_> rsalveti, right, i just dont know if we have to
[16:14] <rsalveti> otherwise I guess we might get out-of-sync regarding the system-image id
[16:14] <ogra_> but i guess we do
[16:15] <ogra_> since s-i doesnt produce them based on arch
[16:15] <rsalveti> right
[16:15] <rsalveti> yeah, just saw the i386 one got an id bump
[16:15] <rsalveti> version 2 now
[16:15] <fginther> ogra_, yes, we appear to be at a case where the current otto job needs some work to test unity8 correctly
[16:15] <rsalveti> so we're fine atm, but once we sync the i386 rootfs, we need to always build both at the same time
[16:16] <ogra_> fginther, then i'll just line up with all the other unity8 landings and stop poking :)
[16:16] <fginther> ogra_, :-)
[16:16] <ogra_> rsalveti, well we should just set i386 in /etc/default-arches on cdimage
[16:17] <ogra_> and have it always produce both by default
[16:17] <rsalveti> ogra_: right, mind updating that?
[16:18] <ogra_> rsalveti, i always get the logic wrong ... but i can try ... worst case i will bother infinity or cjwatson to fix it (as i always have to :P )
[16:18] <rsalveti> ogra_: right, thanks :-)
[16:19] <jdstrand> hi!
[16:19] <cjwatson> ogra_: happy to review
[16:20] <jdstrand> so we have an update to oxide for the grooveshark issue and other fixes
[16:20] <jdstrand> this is built in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages
[16:20] <ogra_> cjwatson, http://paste.ubuntu.com/7226949/
[16:21] <cjwatson> ogra_: please put the trusty- line below saucy to match the sorting used elsewhere in that file, but otherwise LGTM
[16:21] <jdstrand> in addition to grooveshark, there are 2 webapp-container issues: one is a process groups issue and another the OOM
[16:21] <jdstrand> this update fixes the first
[16:22] <ogra_> cjwatson, thanks, fixed and merging
[16:22] <jdstrand> (the OOM is something that webapp-container may address separately)
[16:22] <jdstrand> in addition to these fixes are other bug fixes and features for parity on the desktop
[16:23] <jdstrand> we have an ack from #ubuntu-release once testing passes
[16:23] <jdstrand> so, right now I am asking for a silo. if you agree, before you give it to me, lets talk with dbarth about coordinating on silo 008
[16:24] <jdstrand> (I would binary copy from our ppa to whatever silo we decide on)
[16:26] <didrocks> rsalveti: sorry, was in the meeting, for the i386, do you plan to do one or should I just kick one image for now?
[16:27] <rsalveti> didrocks: I did one already, don't need to worry right now
[16:27] <rsalveti> didrocks: ogra_ will add as a default arch
[16:27] <ogra_> didrocks, rsalveti, already happened
[16:28] <didrocks> ok, good then!
[16:28] <didrocks> plars: please look at report the results ^
[16:29] <ogra_> didrocks, rsalveti did an x86 only build ...
[16:29] <didrocks> ah
[16:29] <didrocks> so kicking
[16:29] <plars> didrocks: for what, the x86 build?
[16:30] <ogra_> (and already happened meant that i added x86 to the default arches already)
[16:30] <didrocks> plars: no, I'm kicking another one
[16:30] <didrocks> yep
[16:30] <didrocks> ok, got it now
[16:30] <ogra_> which means the build will likely take longer
[16:30] <plars> didrocks: ok, I don't think we have anything for that ready in ci just yet. I can look at the new image on devices for sure though
[16:30] <plars> didrocks: there were a couple of crashes I'm seeing in the previous image that I don't recall seeing before
[16:30] <plars> didrocks: will be interesting to see if they show up again
[16:31] <plars> didrocks: one was mediascanner, but was on the default smoke tests of all things
[16:31] <ogra_> i hope we can drop that one soon
[16:31] <plars> didrocks: the other was in messaging app, and the crash was with telephony-service-approver
[16:31] <dbarth> jdstrand: either we can get a free silo and upload there, or if the CI team is low on silo, we can take it in silo 8
[16:31] <ogra_> mediascanner is effectively dead, its all mediascanner-2
[16:31] <didrocks> plars: a touch build starting
[16:31] <didrocks> plars: yeah
[16:31] <dbarth> jdstrand: i think developers would prefer to test in isolation first, ie in a new silo
[16:32] <plars> didrocks: I don't believe you, I only trust imgbot
[16:32] <plars> :)
[16:32] <didrocks> :p
[16:32] <ogra_> lol
[16:32] <didrocks> come on imgbot!
[16:32] <ogra_> imgbot, stunt
[16:32]  * imgbot rolls on its back and purrs
[16:32] <didrocks> I clicked the button :p
[16:32] <jdstrand> dbarth: I'm fine with whatever works best for people.
[16:35] <davmor2> ogra_: Shame on you
[16:35] <ogra_> on me ?
[16:36] <ogra_> what did i do ?
[16:36] <sil2100> The mediascanner is dead, long live the mediascanner-2!
[16:36] <ogra_> ++
[16:36] <davmor2> ogra_: Call yourself a geek and you don't know the DEFCON levels pffff
[16:36] <ogra_> lol
[16:37] <davmor2> ogra_: Never seen Wargames either will be the next line ;)
[16:37] <ogra_> yeah, and my suggestion trashes asac's beautiful analogy too
[16:37] <ogra_> davmor2, well, except that wargames has it the wrong way round
[16:38] <cjwatson> And the real ones aren't zero-based
[16:38] <ogra_> that too
[16:39] <davmor2> ogra_: haha
[16:39] <ogra_> i just want something where i dont have to read the wikipedia article every time i see it :P
[16:39] <davmor2> cjwatson: Trust you to come in and be all sensible :D
[16:40] <imgbot> [16:40] <ogra_> didrocks, ^^
[16:40] <ogra_> there ... stop complaining
[16:40] <jdstrand> sil2100, Mirv, didrocks: can one of you comment on the oxide request? ^
[16:40] <rsalveti> ogra_: thanks
[16:41] <ogra_> :)
[16:41] <jdstrand> (when you have a moment)
[16:43] <didrocks> jdstrand: do you have a line for it? I guess getting that in silo8 will make sense if not
[16:43] <jdstrand> pft
[16:43] <jdstrand> sorry, I got excited and forgot to add it
[16:43] <didrocks> jdstrand: this is for the multimedia double build with codec support?
[16:43] <jdstrand> let me do that real quick
[16:43] <didrocks> ahah :)
[16:43] <jdstrand> didrocks: it is, please other fixes
[16:43] <jdstrand> let me add a line and then we can talk
[16:50] <mhr3> robru, silo for 34 pls?
[16:50] <jdstrand> dbarth: so I am clear, we believe that the ipc change chrisccoulson made will fix the oxide portion of bug #1303676?
[16:56] <dbarth> jdstrand: yes, that's what is fix should do
[16:56] <jdstrand> cool
[16:56] <dbarth> jdstrand: and then the oom killer should kill us cleanly
[16:56] <jdstrand> didrocks: ok, line added
[16:56] <dbarth> and unity8 should be happy too
[17:03] <Saviq> retoaded, hey, there seems to be an issue with the qmluitests job http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-trusty/
[17:03] <Saviq> retoaded, the machines that could run them seem to be dead for some time now
[17:03] <didrocks> jdstrand: ok, I would favor landing that separately
[17:03] <didrocks> jdstrand: there is no need to land anything else in sync?
[17:03] <retoaded> Saviq, checking
[17:03] <jdstrand> didrocks: correct. it can land alone
[17:03] <didrocks> jdstrand: assigning it to you then
[17:04] <didrocks> jdstrand: sorry, I was finishing my long email :)
[17:04] <jdstrand> didrocks: ack. I'll watch the page
[17:04] <jdstrand> didrocks: thanks!
[17:06] <mhr3> mandel, any progress on the silo?
[17:06] <didrocks> jdstrand: yw!
[17:07] <mandel> mhr3, I'll ping sergiusens and will let you know
[17:12] <Saviq> robru, hey, icanhassilo for row 35? should be a quick landing
[17:14] <rsalveti> sil2100: didrocks: can someone reconfigure silo 17? added a new MR for mediaplayer-app
[17:15] <sil2100> rsalveti: hi! Let me take a look
[17:16] <rsalveti> sil2100: thanks!
[17:17] <sil2100> rsalveti: ok, reconfigured, could you check if it's ok now?
[17:17] <rsalveti> sil2100: sure, thanks!
[17:18]  * sil2100 EOD now
[17:18] <sil2100> o/
[17:18] <Saviq> dammit! missed sil ;)
[17:34] <retoaded> Saviq, there are some stale processes on s-jenkins preventing the nodes from connecting. the only way to resolve it will be to restart the jenkins service itself on s-jenkins. We are going to schedule that but it might be an hour or three since there are jobs running.
[17:34] <dbarth> infinity: i think you have the context for account-plugins, is that MP correct for you? https://code.launchpad.net/~dbarth/account-plugins/fix-maintainer-scripts/+merge/214998
[17:34] <dbarth> to fix the issue we've had earlier in the day
[17:36] <Saviq> retoaded, sure, that's ok, thanks
[17:36] <Saviq> cyphermox, icanhassilo for row 35? got to blocker fixes there
[17:38] <infinity> dbarth: If I'm the one who rejected it, I honestly don't recall why, or even when.
[17:38] <dbarth> ah
[17:38] <infinity> Oh, yes, I remember why now that I'm seeing your merge.
[17:38] <dbarth> ah (bis)
[17:39] <infinity> dbarth: I talked to the committer/uploader at the time about the use of dpkg-maintscript-helper without version constraints.
[17:39] <dbarth> that should have been mardy
[17:39] <infinity> It was, yes.
[17:39] <infinity> At least, that sounds right. :P
[17:39] <dbarth> but then the issue is that i published and with the ignore flag
[17:40] <dbarth> and so trunk is out of sync as well
[17:40] <dbarth> so all in all i'm trying to redo an upload that puts us back in a clean state
[17:40] <infinity> So, which debhelper snippet processes .maintscript?  That's a new one to me.
[17:41] <cyphermox> Saviq: k, assigning...
[17:41] <dbarth> dunno, that's greek to me; i'm just going by the previous recommendations i was given
[17:41] <infinity> installdeb, looks like.
[17:41] <cjwatson> infinity: dh_installdeb
[17:41] <dbarth> sil2100, Laney, then robru to interpret those
[17:41] <cjwatson> I was responsible for that :)
[17:41] <infinity> cjwatson: grep beat you.
[17:41] <Saviq> cyphermox, thanks!
[17:41] <cjwatson> Debian #574443
[17:42] <infinity> cjwatson: So, that's just raw dpkg-m-h commands, as I read the manpage?
[17:42] <infinity> cjwatson: Which means it still wants version constraints, it doesn't try to be clever somehow?
[17:42] <dbarth> i guess it means the MP is fine
[17:42] <dbarth> i'll re-request a silo then
[17:42] <infinity> dbarth: No.
[17:42] <dbarth> oops
[17:43] <infinity> dbarth: So, that MP has the same problem.  No version constraint on the rm_conffile, which means it will run on every upgrade ever, for no good reason.
[17:43] <cjwatson> infinity: right
[17:43] <dbarth> ahhh
[17:44] <infinity> dbarth: See 'prior-version' in dpkg-maintscript-helper(1)
[17:44] <cjwatson> infinity: it just saves on errors introduced by people writing maintscript containers for that code when they otherwise don't need to
[17:44] <infinity> dbarth: What you want there is probably version-you're-about-to-upload~
[17:44] <cjwatson> right, I said something similar here a few hours back
[17:44] <cjwatson> 13:23 <cjwatson> just make sure to use the right prior version as it's not entirely intuitive; it's best to identify the first version for which the operation *isn't* required and then append ~ to it
[17:44] <infinity> dbarth: If that's really hard, due to automagic daily build nonsense giving you versions you don't know in advance, just picking a date "after the latest, and before the current" should work, ish.
[17:45] <dbarth> so "rm_conffile /etc/signon-ui/webkit-options.d/secure.flickr.com.conf 0.11+14.04.20140401 -- "$@""
[17:45] <cjwatson> in a .maintscript file, don't include the -- "$@"
[17:45] <dbarth> ok
[17:45] <cjwatson> /usr/share/debhelper/autoscripts/maintscript-helper takes care of that
[17:46] <cyphermox> Saviq: conflicts with silo 2: greeter split, is that expected?
[17:46] <infinity> cjwatson: the dh_installdeb manpage might want to be vaguely clearer on pointing out that the -- extra params bit isn't needed.
[17:46] <ogra_> Saviq, LOL !
[17:46] <Saviq> cyphermox, yes, that one is prep only
[17:46] <Saviq> ogra_, ?
[17:46] <cjwatson> infinity: yeah, and it should mention including a version too.  file a bug?
[17:46] <ogra_> Saviq, so i was hunting donw CI people because that silly two line MP for unity8 upstart failed all the time in jenkins :P
[17:47] <Saviq> ogra_, right, yeah
[17:47] <ogra_> Saviq, thanks for just pulling it in
[17:47] <ogra_> i was slowly starting to rip my hair out :)
[17:47] <Saviq> ogra_, ;)
[17:47] <Saviq> ogra_, we'll handle
[17:47] <ogra_> :)
[17:50] <imgbot> [17:50] <imgbot> [17:50] <cyphermox> Saviq: you got silo 4
[17:50] <Saviq> cyphermox, thanks
[17:50] <dbarth> cyphermox: can you help with silo 011? (robru is off to an hour or so)
[17:51] <dbarth> cyphermox: i'd like advice on whether i need to unblock the upload with https://code.launchpad.net/~dbarth/account-plugins/fix-maintainer-scripts/+merge/214998
[17:51] <cyphermox> what's with silo 11?
[17:51] <dbarth> cyphermox: or if i need to add it back, rebuild, re-test and attempt a new landing
[17:52] <dbarth> cyphermox: facebook api key renewal
[17:52] <dbarth> got revoked this morning, we're rushing to re-enable the service for users (desktop mostly, but friends app is affected as well)
[17:52] <dbarth> see https://bugs.launchpad.net/account-plugins/+bug/1304798
[17:53] <cyphermox> well, as cjwatson said
[17:53] <cyphermox> you'll want to add your merge request to the silo, rebuild, retest, etc.
[17:54] <cyphermox> needing to unbreak facebook isn't a reason for short-circuiting the processes we have in place, if they work, and if I'm not told otherwise by $deity
[17:54] <dbarth> sorry missed that but sure
[17:54] <cyphermox> as far as I can tell it's not been uploaded yet
[17:54] <dbarth> i'm not asking to short circuit i'm confirming the process
[17:55] <dbarth> in that particular case, there was a mistake with the previous landing attempt (my mistake)
[17:55] <cyphermox> ok
[17:55] <dbarth> so i don't want to make it worse by going the wrong way ;)
[17:56] <cyphermox> no problem :)
[18:01] <dbarth> cyphermox: i think the silo is reconfigured now and building fine
[18:01] <dbarth> fingers crossed
[18:01] <dbarth> and thanks all for your help
[18:02] <mardy> dbarth: hi! I'm here just briefly :-)
[18:02] <mardy> dbarth: thanks for taking care of that
[18:02] <sergiusens> cyphermox: robru is the dependency chain preventing me from building unity-scope-click here? https://ci-train.ubuntu.com/job/landing-019-1-build/14/console
[18:02] <cyphermox> dbarth: np
[18:02] <sergiusens> mandel: ^^
[18:02] <cyphermox> sergiusens: moo?
[18:02] <mardy> dbarth: your MP looks right, just please link your branch to those two bugs, or the changelog won't be updated automatically
[18:02] <dbarth> mardy: should be fine now, or so i hope
[18:03] <sergiusens> cyphermox: so I told the build to only build unity-scope-click and it fails saying that the download manager can't build (it failed on ppc)
[18:03] <cyphermox> sergiusens: isn't that just a test failing?
[18:03] <cyphermox> ah
[18:03] <sergiusens> cyphermox: it didn't even dput unity-scope-click :-)
[18:03] <cyphermox> right
[18:04] <cyphermox> did you just add unity-scope-click to the field for packages to rebuild?
[18:04] <dbarth> mardy: which 2 bugs? i just see one
[18:04] <Saviq> cyphermox, robru, rsalveti, FWIW, if you need to flush one of my prep silos, please do the infographics first, is easier to recover
[18:06] <cyphermox> right, we're somewhat short right now
[18:06] <dbarth> mardy: i guess the flickr one and the facebook one
[18:06] <dbarth> mardy: better now? https://code.launchpad.net/~dbarth/account-plugins/fix-maintainer-scripts
[18:06] <cyphermox> sergiusens: you want to do some quick testing of MTP before I ask robru to publish it?
[18:06] <cyphermox> that one is quite very safe to land anytime
[18:07] <sergiusens> cyphermox: if davmor2 is still around, I'd like to offhand to him
[18:07] <cyphermox> k
[18:07] <cyphermox> davmor2 has already tested it I think
[18:07] <sergiusens> cyphermox: if not, I'll grab it in a bit
[18:07] <cyphermox> fginther: ah?
[18:08] <fginther> cyphermox, ?
[18:08] <cyphermox> fginther: (just curious) why does it need restarting for that, shouldn't those be external processes?
[18:08] <davmor2> cyphermox: have I, is this the everything but the names showing correctly fix?
[18:08] <cyphermox> davmor2: the names showing correctly?
[18:08] <cyphermox> oh right
[18:09] <cyphermox> davmor2: yes, exactly
[18:09] <davmor2> yeah I tested it then :)
[18:09] <cyphermox> ok
[18:09] <cyphermox> then we'll just be down to asking robru to push the button, since it's my code ;)
[18:10] <fginther> cyphermox, ah, the slaves are connected via ssh processes. these get wedged for an unknown reason and the defunct ssh process appears to prevent jenkins from starting a new connection.
[18:10] <cyphermox> fginther: interesting
[18:10] <fginther> cyphermox, the only way we've found to recover from this is to restart jenkins
[18:10] <cyphermox> defunct processes shouldn't normally be blocking you from doing much
[18:10] <cyphermox> but who knows how jenkins really works ;P
[18:10] <Saviq> cyphermox, do you have an idea on what happens in https://ci-train.ubuntu.com/job/landing-004-1-build/15/console ? twice already bzr barfed ;(
[18:11] <Saviq> I can merge it fine locally...
[18:11] <fginther> cyphermox, right :-)
[18:11] <cyphermox> Saviq: something broke in the ancestry?
[18:11] <sergiusens> cyphermox: I missed you comment; yes I did add unity-scope-click to the packages to rebuild; can be seen in the logs and in the build Parameters
[18:12] <Saviq> cyphermox, not sure how to resolve that, though... it might be related to the in-distro revert...
[18:12] <sergiusens> cyphermox: https://ci-train.ubuntu.com/job/landing-019-1-build/14/console -> 2014-04-09 15:23:14,956 INFO Adding unity-scope-click MP(s) to prepare
[18:12] <cyphermox> well then you shouldn't be seeing the others... hold on
[18:12] <sergiusens> cyphermox: oh, it might be ignoring the empty merge
[18:12]  * Saviq gives up for now...
[18:13] <cyphermox> Saviq: I'll deal with sergiusens issue first, it should be simpler
[18:13] <Saviq> cyphermox, sure, thanks
[18:13] <cyphermox> Saviq: I'll get right to it next and stage that locally with the scripts
[18:13] <Saviq> cyphermox, I gtg, if you manage to get it done, please kick a build so that I can test later tonight and ACK for landing
[18:13] <cyphermox> sure
[18:13] <Saviq> thanks
[18:13] <cyphermox> sergiusens: mind if I run the build again?
[18:13] <Saviq> over'n'out
[18:14] <cyphermox> Saviq:  / and Ctrl-D? :D
[18:15] <cyphermox> sergiusens: there is actually something to rebuild there?
[18:15] <sergiusens> cyphermox: yeah, the empty commit is to make a no change rebuild
[18:15] <sergiusens> cyphermox: u-d-m broke abi
[18:15] <cyphermox> https://ci-train.ubuntu.com/job/landing-019-1-build/15/console
[18:16] <sergiusens> cyphermox: oh, I wasn't doing force rebuild
[18:17] <cyphermox> that may well be expected, your build might still check whether u-d-m successfully build on all arches
[18:30] <cyphermox> sergiusens: ftbfs https://launchpadlibrarian.net/172373269/buildlog_ubuntu-trusty-amd64.unity-scope-click_0.1%2B14.04.20140409-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:31] <sergiusens> cyphermox: 302 mandel :-)
[18:31] <cyphermox> ahah ;)
[18:32] <sergiusens> cyphermox: fwiw, I'm just here to click on 'build' now
[18:33] <cyphermox> ok
[18:34] <cyphermox> sweet, I can reproduce Saviq's issue easily
[18:34] <cyphermox> brb
[18:44] <mardy> dbarth: approved, thanks
[19:17] <mhr3> cyphermox, can i get silo for line 34? it should be super quick build+publish
[19:21] <cyphermox> mhr3: ack
[19:25] <cyphermox> mandel: did you find anything about the failure from earlier?
[19:28] <jhodapp> robru, hey, can you kick off a rebuild of media-hub (from an MR push) on silo 017?
[19:29] <jhodapp> robru, nm, rsalveti is back
[19:35] <rsalveti> yup, already triggered it
[19:52] <dbarth> o/ silo 008 ready for publication
[19:53] <dbarth> that's webapps for the destkop mostly, but also applicable to phone
[19:55] <mhr3> cyphermox, forgot about me?
[19:55] <cyphermox> mhr3: no
[19:57] <mhr3> cyphermox, so what's the holdup?
[19:59] <cyphermox> you got silo 20
[19:59] <cyphermox> robru: around?
[20:04] <dbarth> o/ silo 003 is also ready to go
[20:06] <mhr3> ty
[20:06] <plars> sergiusens: hey, would you be open to adding flo to the default settings.py in phablet-tools? We make use of detect_device from there in the ci scripts. Otherwise we could reimplement detect_device, but that seems kind of a waste.
[20:06] <sergiusens> plars: no worries, we can add it
[20:07] <plars> sergiusens: awesome, thanks!
[20:15] <cyphermox> cool
[20:16]  * cyphermox goes to grab food, back shortly
[20:28] <mhr3> cyphermox, sigh, giving up 020, apparently Laney pushed it straight to distro a week ago
[20:28] <mhr3> how are these things synced?
[20:29] <mhr3> straight push to trunk without bots?
[20:32] <dbarth> robru: when you are back, we have silo 008 and 011 which are both ready for landing now; silo-003 may require some special treatment to comb through the packaging changes once more, but the runtime is verified to be working
[20:56] <tedg> Hello, can someone rebuild silo 13 for me please?
[21:07] <dbarth> cyphermox: not sure if you can land 008 and 011 or want to review with robru
[21:07] <dbarth> cyphermox: but can you pass on to him when he returns then
[21:07] <dbarth> i'm about to eod
[21:07] <jdstrand> I can actually push 008
[21:07] <jdstrand> but I want to talk to a landing team person before I do
[21:08] <jdstrand> robru, cyphermox, rsalveti: can one of you advise me on a silo 8 question?
[21:09] <dbarth> jdstrand: you're on silo 16
[21:10] <jdstrand> dbarth: hehe
[21:10] <jdstrand> I am!
[21:11] <jdstrand> robru, cyphermox, rsalveti: can one of you advise me on a silo 16 question? :)
[21:15] <dbarth> jdstrand: i will just log a bug for the things we noticed
[21:16] <jdstrand> dbarth: ack
[21:16] <jdstrand> dbarth: can you add this paste to the bug: http://paste.ubuntu.com/7228130/
[21:19] <dbarth> jdstrand: https://bugs.launchpad.net/oxide/+bug/1305317
[21:23] <jdstrand> robru, cyphermox, rsalveti: ok, I am going to have to step away for a few hours. I just wanted your ACK to push silo 16. it works much better at the expense of introducing bug 1305317 on a desktop webapp that has other issues
[21:23] <rsalveti> lemmesee
[21:23] <jdstrand> rsalveti: hi!
[21:24] <jdstrand> basically, with this oxide upload, we can tweak the image seed to install oxideqt-codecs-extra and the grooveshark bug is fixed
[21:25] <rsalveti> jdstrand: what oxideqt-codecs-extra will gain us?
[21:25] <jdstrand> in addition, we have greatly improved the bug #1303676
[21:25] <jdstrand> rsalveti: so chromium has a compile time flag to build with or without some codecs like mp3 and h264
[21:25] <dbarth> +1 with jdstrand
[21:26] <robru> sorry everybody, just got back from the doctor, reading scrollback now
[21:26] <jdstrand> rsalveti: we did for oxide what we already do for chromium-browser
[21:26] <rsalveti> oh, right
[21:26] <rsalveti> and we're not installing them by default anymore
[21:26] <jdstrand> rsalveti: we build twice-- once with and once without, and ship in two packages
[21:26] <rsalveti> do we want and can we install them by default?
[21:26] <jdstrand> so the desktop image will ship with oxideqt-codecs, but I'll add to ubuntu-restricted-addons oxideqt-codecs-extra
[21:27] <jdstrand> rsalveti: we can't
[21:27] <rsalveti> right, makes sense
[21:27] <jdstrand> but the desktop image has a checkbox to install 3rd party codecs like this
[21:27] <jdstrand> and what I just said will tie in to that
[21:27] <rsalveti> great
[21:27] <jdstrand> the phone can just ship them I believe
[21:27] <rsalveti> not so sure
[21:27] <jdstrand> we just need to tweak the seed
[21:27] <rsalveti> that's why we want to use the hwcodecs
[21:28] <dbarth> rsalveti: it's either that or grooveshark won't work ;)
[21:28] <rsalveti> so we don't need to ship any other mp3/h264 codecs
[21:28] <jdstrand> ok, well, then that is a discussion point
[21:28] <rsalveti> it worked before because webkit was using gstreamer
[21:28] <rsalveti> and we had a license to use the implementation that was done by fluendo
[21:28] <jdstrand> aiui, this is in the bowels of the chromium content api
[21:29] <rsalveti> ideally we could hook this up with our media-hub, that would then use gstreamer
[21:29] <rsalveti> but that's for later
[21:29] <jdstrand> I may have mentioned that you and chrisccoulson may want to discuss this point :)
[21:29] <rsalveti> yeah, there's no way to do hardware accelerated decoding if we do go that path
[21:29] <rsalveti> we need to use media-hub at least for video playback
[21:29] <rsalveti> and if we use it also for audio, we're covered
[21:30] <jdstrand> well, I can saw that on flo it does work quite well (oxideqt-codecs-extra)
[21:30] <rsalveti> I'm fine with the change itself, but can't give a +1 for the seeds changes (above may paygrade)
[21:31] <jdstrand> this is google's ffmpeg implementation and I know we have compositing working with oxide in general
[21:31] <rsalveti> jdstrand: right, but it's software decoding
[21:31] <jdstrand> I can easily add the one to ubuntu-restricted-addons-- that is what it is for. I will hold off on the touch one
[21:31] <rsalveti> we want to use media-hub so we can also use hardware decoding for the webapps/browser
[21:32] <rsalveti> jdstrand: yeah, problem with touch is that we don't have a way for the user to opt-in
[21:32] <dbarth> and that is ready and available inthe image?
[21:32] <rsalveti> read license and so on
[21:32] <tedg> Can someone hit build on silo 013 please?
[21:32] <rsalveti> dbarth: we're landing media-hub as we speak, but we'd need further work to integrate it on oxide
[21:32] <dbarth> how fast is that to have oxide call into qt to get media-hub/hw decoding support?
[21:32] <jdstrand> is this what this bug is about: bug #1249387 ?
[21:33] <rsalveti> that's not trivial and not something for 14.04
[21:33] <dbarth> right
[21:33] <rsalveti> yeah
[21:33] <dbarth> so maybe we need to switch back grooveshark to using qtwebkit
[21:33] <dbarth> and use gstreamer again
[21:34] <rsalveti> jdstrand: so +1, and please sync with pat tomorrow regarding oxideqt-codecs-extra
[21:34] <dbarth> technically we still have that path open
[21:34] <rsalveti> dbarth: if that's feasible, then yeah
[21:34] <dbarth> jdstrand: ^^?
[21:34] <jdstrand> rsalveti: ack
[21:34] <jdstrand> dbarth: I have no problem with that, other than the OOM issue you were seeing (but is greatly improved by this upload anyway)
[21:35] <dbarth> right
[21:35] <jdstrand> dbarth: but lets talk to pat tomorrow
[21:35] <dbarth> and that's hopefully a quick thing to re-enable
[21:35] <rsalveti> yeah, before deciding re-enable it with webkit
[21:35] <dbarth> yes
[21:35] <jdstrand> I will push oxide in the ppa then
[21:35] <dbarth> about to eod, almost midnight here
[21:35] <rsalveti> because it's a question of copyright, license, patents and etc
[21:35] <rsalveti> I know we're covered with the mp3 gst plugin we have
[21:35] <dbarth> robru: if you read the backlog, silo 008 and 011 are ready
[21:36] <dbarth> rsalveti: makes sense
[21:37] <rsalveti> tedg: done
[21:37] <robru> dbarth, ok, just checking. wow what a hectic day to be afk :-/
[21:37] <tedg> rsalveti, thanks!
[21:37] <dbarth> robru: i'll be around for hte next 5 or so if you 've got questions
[21:37] <dbarth> or catch me for breakfast tomorrow
[21:38] <robru> dbarth, just looking now
[21:39] <jdstrand> I will be afk for a while
[21:39] <robru> dbarth, ok, silo 11 published. checking the other
[21:39] <jdstrand> I did the Publish step and alerted #ubuntu-release to it (this was discussed earlier)
[21:41] <rsalveti> jdstrand: thanks
[21:41] <robru> dbarth, ok, silo 8 published as well. good night!
[21:44] <dbarth> robru: thank you
[21:44] <dbarth> will m&c tomorrow
[21:44] <robru> dbarth, you're welcome!
[21:46] <robru> mhr3_, do you need help resolving the conflict in silo 20?
[21:47] <robru> cyphermox, what am I pushing the button on?
[21:48] <mhr3_> robru, yea, the thing i was trying to land is already in distro, how to sync it up?
[21:49] <robru> mhr3_, you need to apply this diff as a commit on your branch: http://launchpadlibrarian.net/171586578/ubuntuone-credentials_14.04%2B14.04.20140306_14.04%2B14.04.20140306ubuntu1.diff.gz
[21:49] <robru> mhr3_, then rebuild and citrain will see that distro is synced.
[21:50] <robru> mhr3_, (if the diff doesn't apply because those changes are already made, just make sure the changelog entry is present)
[21:50] <mhr3_> robru, well if it's already in distro i don't need to land it, do i?
[21:50] <mhr3_> so isn't it enough to just push it to trunk?
[21:51] <robru> mhr3_, well, yeah, you can push it to trunk too ;-)
[21:51] <mhr3_> oh wait, trunk is owned by some weird team, i can't push it
[21:52] <robru> mhr3_, then it should work if you just add it to your branch then.
[21:52] <mhr3_> not my branch :)
[21:52] <robru> mhr3_, groan! I guess you have to make a new MP and add it to the list then
[21:53] <robru> mhr3_, the real irony is that it's all laney's fault. he did a direct upload and then a branch, weird that he wouldn't do either two direct uploads or two branches.
[21:54] <mhr3_> well... hopefully he'll read this :)
[21:54] <robru> ;-)
[21:54] <robru> mhr3_, actually I seem to have access to that trunk if you want me to just do a trunk push
[21:55] <mhr3_> robru, go ahead, at least i silo can be cleared faster
[21:55] <mhr3_> s/i/the/
[21:55] <cyphermox> robru: poke
[21:55] <robru> mhr3_, no wait... this branch is laney syncing his distro upload already...
[21:55] <cyphermox> where can I halp?
[21:55] <robru> cyphermox, hey
[21:55] <robru> cyphermox, are we go for publish in silo 1?
[21:56] <mhr3_> robru, but he didn't sync changelog
[21:56] <cyphermox> I already pushed the button
[21:56] <robru> mhr3_, yes I guess that's the issue.
[21:56] <mhr3_> robru, so just push the diff you pasted ^
[21:56] <robru> mhr3_, i thought they were two distinct changes at first
[21:56] <robru> mhr3_, sure
[21:56] <thomi> robru: I wonder if I could please get a silo allocated for row 39?
[21:57] <robru> thomi, one sec, we're quite low but I'm about to free one
[21:57] <robru> mhr3_, ok pushed, will free your silo
[21:57] <thomi> robru: awesome, thanks
[21:57] <thomi> robru: this should be a fast landing
[21:58] <mhr3_> robru, thx, marking the mp as merged
[21:58] <Laney> wait, what did I do
[21:58] <mhr3_> robru, eh, no permission, if you could pls
[22:02] <robru> Laney, not a big deal, I misunderstood at first. basically your manual upload of ubuntuone-credentials was fine, but when you submitted an MP for it as well, the MP should have included the changelog. I fixed it already
[22:02] <Laney> I did the MP first
[22:02] <robru> Laney, hmm, then why the direct upload? why not just let CI Train do the upload?
[22:02] <Laney> took a while to get it approved
[22:03] <Laney> anyways, sorry if it caused any trouble
[22:03] <robru> Laney, well, whichever came first, when CI Train tried to build the MP, it failed because the archive contained a changelog entry that wasn't in trunk, so I thought you had done two different things. but they were the same change, so it was funny ;-) no worries, all fixed now
[22:04] <Laney> I figured the next CI train landing would generate the changelog and that wouldn't matter
[22:04] <Laney> i.e. that you could overwrite the one in the archive
[22:04] <robru> Laney, CI Train does generate the changelog when it's building an MP into distro. but when distro  contains a changelog entry that isn't already in trunk, it gets confused.
[22:04] <Laney> fair enough
[22:05] <robru> Laney, that was an option too, but generally the distro changelogs should be considered sacrosanct, better to sync distro's changelog into trunk than to overwrite distro's changelog with a generated one
[22:05] <robru> (is my understanding)
[22:05] <robru> (not that I need to lecture you about distro changelogs)
[22:06] <Laney> I don't consider it a problem personally (we remove changelogs all the time for syncs and merges where people don't keep them), but either way works
[22:06] <robru> Laney, ok great.
[22:06] <Laney> if it makes life easier for you then I'll try to remember in future
[22:07] <robru> Laney, yeah, easiest possible thing for me is just don't do distro uploads outside of ci train ;-)
[22:07] <robru> obviously it's not always possible, no worries.
[22:11] <robru> bregma, you got silo 9
[22:11] <robru> bfiller, you got silo 15
[22:11] <robru> thomi, you got silo 20 ;-)
[22:11] <bregma> woo-hoo! the party starts now!
[22:12] <thomi> robru: thanks
[22:14] <thomi> robru: not sure if this is a known bug or not, but after doing the auth dance on ci-train, the login service sends me back to a broken URL (https://job/landing-020-1-build/build?delay=0sec)
[22:14] <thomi> I can work around it, but it's a PITA
[22:15] <robru> thomi, hmm, I haven't seen that specifically, but I do sometimes have some hiccups when logging in
[22:15] <thomi> robru: it's 100% reproducible for me
[22:15] <thomi> I encountered it in the last landing as well, so it's been around for a few days at least
[22:15] <robru> thomi, what are the steps? click a link from the spreadsheet, it redirects to 2fa, then redirects back to the wrong place?
[22:15] <thomi> exactly
[22:15] <bregma> oh yeah, it's a clicky clickfest
[22:16] <bregma> keeps it lively
[22:16] <robru> bregma, thomi: for me, I usually see the 2fa, then it sends me back to the right page, then I click 'build', but it doesn't start the build, it just redirects around and then back to the same page, so I end up having to click build twice.
[22:16] <robru> not sure who to raise that with, i'll email didrocks
[22:16] <thomi> robru: oh, I have that as well, but that's not so annoying
[22:17] <bregma> 2fa brings me to an invalid page, then click build then click build
[22:18] <thomi> reminds me of that Warren Zevon song "My shit's f***ed up"
[22:18] <thomi> :)
[22:19] <robru> thomi, lol. well I once got redirected to something like citrain.ubuntu.com/openid and it 404'd but that was only once or twice. not something I can reproduce.
[22:57] <ToyKeeper> Okay, need a tag to help keep track of which bugs are currently considered promotion blockers.
[22:57] <ToyKeeper> touch-blocker?  promotion-blocker?
[22:59] <ToyKeeper> qa-touch-blocker?
[23:00] <robru> ToyKeeper, I like that last one
[23:01] <ToyKeeper> This is so a script can automate a bunch of searching and reporting.
[23:01] <robru> ToyKeeper, excellent
[23:02] <ToyKeeper> Otherwise, /me fails with ETOOMANYBUGS
[23:04] <robru> ToyKeeper, yeah, if it weren't for didier's daily emails with the bug lists, I'd be lsot
[23:04] <ToyKeeper> Yeah, me too.
[23:05] <ToyKeeper> I expect I'll put this up under my domain, at least for now...  something like http://qlbr.toykeeper.net/phablet-blockers  (after I add the code for it)
[23:08] <robru> ToyKeeper, what code? launchpad can already search on bug tags?
[23:09] <ToyKeeper> Ever tried to do a LP search on 80 different projects all at once?
[23:10] <ToyKeeper> It's great for individual projects, or sometimes even for projects arranged into a hierarchy.  Not so much for a collection of less-organized projects.
[23:12] <robru> ToyKeeper, hmmm
[23:17] <robru> ToyKeeper, https://bugs.launchpad.net/bugs/+bugs?field.tag=qa-touch-blocker seems fine to me
[23:18] <ToyKeeper> Ooh, global LP search?  How long has that existed?  :)
[23:19] <robru> ToyKeeper, admittedly I had to hand-craft the URL but it gives the desired result, doesn't it? ;-)
[23:19] <ToyKeeper> ish
[23:19] <ToyKeeper> It returns two more bugs than I expected...  now figuring out why.
[23:19] <ToyKeeper> Searching just within ubuntu, I got one less than expected.
[23:21] <robru> ToyKeeper, the global search is probably cached, it might not update the results immediately or something.
[23:21] <ToyKeeper> Looks like it's reporting once per project, rather than once per bug ID.
[23:41] <cjwatson> It'll be once per task.
[23:58] <thomi> cihelp - it looks like the autopilot gatekeeper job might be stuck? http://q-jenkins:8080/job/autopilot-release-gatekeeper/105/label=mako-06/console
[23:59] <thomi> is mako-06 down perhaps?