[00:04] <jdstrand> cjwatson: re boot> yeah, that is consistent with what I saw just poking around after reboot. thanks for checking
[00:05] <jdstrand> cjwatson: re click auto-uploads> oh nice, thanks :)
[00:38] <jdstrand> ok, seems like click-apparmor got a lot farther along
[00:38] <jdstrand> 2014-03-13 00:38:14,523 INFO Source available in ppa
[00:38] <jdstrand> 2014-03-13 00:38:15,199 INFO arch: ppc64el, status: building
[00:38] <jdstrand> 2014-03-13 00:38:15,200 INFO arch: i386, status: building
[00:38] <jdstrand> 2014-03-13 00:38:15,200 INFO arch: powerpc, status: building
[00:38] <jdstrand> 2014-03-13 00:38:15,200 INFO arch: amd64, status: building
[00:38] <jdstrand> 2014-03-13 00:38:15,200 INFO arch: armhf, status: building
[00:38] <jdstrand> ...
[00:39] <jdstrand> so that is good. I didn't talk to stgraber, but saw the commit he made to click (and the next one). I don't claim to know exactly why it is working, but am happy that it is
[00:46] <robru> jdstrand, excellent. need any help with anything?
[00:46] <jdstrand> robru: so... it built, but the changelog is nuts: https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/+packages
[00:46] <jdstrand> I think it is every commit ever made
[00:46] <robru> jdstrand, oh crap
[00:47] <robru> jdstrand, you're right, it's every commit ever made. there's a way to fix that, let me try to remember what it is
[00:47] <jdstrand> that is weird. granted, I forgot to add the debian/control updates I made to make it work at all to the merge commit message...
[00:48]  * jdstrand adds that to the merge since it is clear he will rebuild the package
[00:48] <robru> jdstrand, yeah, normally once you've been in ci train for a while, it knows when it's last release was and only grabs new commits. there's a way for new projects to say "don't grab old commits" but I forget
[00:49] <robru> "for a while" = at least one release with ci train
[00:49] <jdstrand> yeah
[00:49] <jdstrand> maybe that click merge request has it
[00:54] <jdstrand> I wonder it I need a tag
[00:54] <jdstrand> s/it/if/
[00:55] <jdstrand> no, I have a tag
[00:59] <robru> jdstrand, yeah just poking at the changelog code directly. i know i was told how to do this but i'm really struggling to remember here :-(
[00:59] <robru> jdstrand, it looks like it does scan for tags. perhaps the tag you have doesn't match the tag it expects
[01:00] <jdstrand> I didn't tag the new version-- I just have 0.1.14
[01:00] <jdstrand> I'm reading https://wiki.ubuntu.com/DailyRelease/FAQ
[01:00] <robru> jdstrand, no no, it'll make the new tag for you. but it scans for old tags to figure out how many commits go in the changelog
[01:01] <jdstrand> but I think that doesn't quite apply to what I'm doing since I have a native version
[01:01] <jdstrand> I see
[01:01] <robru> jdstrand, yeah, that documentation is for the old daily_release system which was discontinued in january. ci train inherits some of that code but not all, so documentation is a bit stale
[01:02] <robru> jdstrand, yeah, I found the part in the code where it tries to look for a tag, and then if it fails it literally just says "ok, grab the most recent 100 commits" and it uses that
[01:02] <jdstrand> heh, I only have 97 commits atm
[01:02] <jdstrand> what is the format of the tag?
[01:03] <jdstrand> currently, the tags I have are things like:
[01:03] <jdstrand> 0.1.12               92
[01:03] <jdstrand> 0.1.13               95
[01:03] <jdstrand> 0.1.14               96
[01:04] <jdstrand> r97 has my citrain commit
[01:04] <jdstrand> so I can tag it differently if needed
[01:04] <jdstrand> or I guess I can rename the 0.1.14 one
[01:05] <robru> jdstrand, just checking on that right now
[01:06] <jdstrand> thanks
[01:06] <robru> jdstrand, buh, this might be another native vs non-native bug. Here's lp:unity's tags: http://bazaar.launchpad.net/+branch/unity/changes
[01:07] <robru> jdstrand, maybe just try renaming the 0.1.14 tag to something like 0.1.14+14.04.20140312-0ubuntu1 to see if that appeases the changelog maker.
[01:08] <jdstrand> heh, ok
[01:10] <robru> jdstrand, I dunno, this code is a bit obtuse, but it seems to be checking the version number as it exists in distro and then looking for a tag with that exact value. given that ubuntu archive has '0.1.14' I have no idea why it failed to find '0.1.14' tag. I don't have super high hopes for a phony version tag, but I have no idea at this point.
[01:11] <robru> jdstrand, http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/build#L233 if you want to try to make sense of this with me
[01:12] <robru> jdstrand, also http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/cupstream2distro/branchhandling.py#L180
[01:15] <robru> jdstrand, oh, duh. I think if you just write your own debian/changelog entry, citrain will preserve that.
[01:16] <jdstrand> hmm, I did that. let me try that then. do I need to delete the built packages from the ppa or will things just be ok?
[01:17] <robru> jdstrand, should just be ok as far as I know. i've only had to delete packages manually when a whole project gets dropped from the MP list.
[01:38] <jdstrand> hmm, no
[01:38] <jdstrand> https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/+packages shows the previous build
[01:38]  * jdstrand revs the version
[01:39] <robru> jdstrand, oh yeah, ppa won't accept identical version uploads. that's not a problem with non-native packages because citrain just adds a .1 on the end of the date
[01:40] <jdstrand> right
[01:53] <jdstrand> it seems to be autogenerating 0.1.15 and not taking what I have in the changelog
[01:53] <jdstrand> http://162.213.34.102/job/landing-001-1-build/70/console
[01:53] <jdstrand> oh, it only grabbed 97
[01:54] <jdstrand> maybe I have to re-request the merge
[02:02] <jdstrand> sigh
[02:02] <jdstrand> well, it is somewhat better
[02:10] <robru> jdstrand, that log you linked indicates that it grabbed revision 99
[02:11] <robru> jdstrand, grep for "at rev"
[02:11] <jdstrand> erf
[02:11] <robru> jdstrand, where it says 'committed revision 97" that refers to the resulting trunk commit.
[02:12] <jdstrand> robru: now what am I doing wrong? https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/+packages (see 0.1.15.2)
[02:12] <jdstrand> sorry, 0.1.15.2)
[02:12] <jdstrand> robru: yeah, I figured that out later
[02:12] <robru> jdstrand, uhhh, probably "UNTRUSTED" ?
[02:13] <jdstrand> meh
[02:13] <jdstrand> durr
[02:13] <jdstrand> still, I had the same changelog a minute ago, but with 'trusty'
[02:13] <jdstrand> I have been fiddling with this *way* too long
[02:13] <robru> jdstrand, oh i see that too
[02:14] <robru> jdstrand, the only other thing I can see that's even slightly different is 'urgency=medium'. Maybe citrain doesn't understand that (I've literally never seen it before).
[02:14] <robru> jdstrand, it seems like citrain just can't handle urgency so it's making a new entry that urgency=low, but it has no info to put there, so you get a blank bullet point
[02:14] <jdstrand> it is what dch gave me
[02:15] <jdstrand> I can adjust
[02:15] <robru> jdstrand, yeah, if you're willing to fiddle further, I'd recommend a .3 release with urgency=low just to see if it honors your changelog then. if you're out of patience, leave it for tomorrow and yell at didrocks ;-)
[02:17]  * jdstrand attempts
[02:33] <jdstrand> well, lookie there. a reasonable changelog
[02:42] <robru> jdstrand, EHRR. MAH. GERD.
[02:42] <robru> jdstrand, so you should mention the issues you faced to didrocks. ;-)
[02:44] <jdstrand> I will, though honestly I don't know why it worked now...
[02:44] <jdstrand> robru: thanks for the urgency and UNTRUSTED tip :)
[02:44] <jdstrand> and the hand holding in general
[02:45] <robru> jdstrand, oh absolutely! I'm really excited about CI Train so I'm trying really hard to see it succeed.
[02:46] <robru> jdstrand, i mean, you're welcome
[02:51] <jdstrand> heh
[03:05] <bregma> hey robru landing-002 is ready for publish when you are
[03:07] <robru> bregma, sweeet
[03:09] <robru> bregma, done
[03:36] <robru> I'm EOD 2.5 hours ago, anybody need anything before I sign off?
[03:44] <jdstrand> robru: one easy question
[03:44] <jdstrand> robru: on 'Testing done', I should fill in 'yes' when I'm done?
[03:45] <robru> jdstrand, yes! also it helps to ping me so I know to publish it, because I don't always monitor the spreadsheet extremely closely.
[03:45] <jdstrand> well, I have the last test I am running
[03:45] <jdstrand> it takes a while though
[03:46] <jdstrand> ~15 minutes
[03:46] <robru> jdstrand, like, more than an hour? i can wait a bit to publish it
[03:46] <robru> jdstrand, oh yeah, i'll publish that for you when it's done
[03:47] <jdstrand> ok. I'm core-dev and iirc, I should have the necessary acls to do the publish myself
[03:47] <robru> jdstrand, oh right. well I'll hang around just in case that didn't get set up properly for you.
[03:47] <jdstrand> k, thanks
[03:48] <robru> jdstrand, or wait, are you going to sign & upload the package manually?
[03:48] <jdstrand> not this time
[03:48] <jdstrand> I figure I'd use the process before I comment on it
[03:48] <robru> jdstrand, ok yeah. i've seen sometimes people have the wrong permissions even in spite of being core devs.
[03:48] <jdstrand> :)
[03:48] <jdstrand> I was added to a citrain group too
[03:48] <jdstrand> (after training)
[03:49] <robru> jdstrand, yeah, the jenkins instance has it's own ACL I think, independent of lp groups...
[03:51] <jdstrand> while I'm not ready to press Build yet, I'm looking at http://162.213.34.102/job/landing-001-2-publish/build
[03:52] <jdstrand> I'm not sure what all I need except ACK_PACKAGING since I had the changes to debian/control
[03:52] <jdstrand> seems the others I shouldn't need to check
[03:54] <robru> jdstrand, yeah, should be just ACK_PACKAGING only. the rest of those are for recovery from various error states, which you aren't in, since it's the first publish
[04:06] <jdstrand> robru: ok, tests done. I am attempting to publish
[04:06] <robru> jdstrand, great
[04:07] <jdstrand> http://162.213.34.102/job/landing-001-2-publish/49/
[04:07] <jdstrand> Finished: SUCCESS
[04:07] <jdstrand> \o/
[04:07] <robru> yay!
[04:08] <robru> jdstrand, so once that gets to the archive (usually ~45 minutes depending on how many autopkgtests there are in -proposed), you can hit merge & clean and then the process is really done
[04:08] <jdstrand> cool, that was in my notes-- thanks for the confirmation. thanks again for the hand-holding and have a good evening :)
[04:08] <robru> jdstrand, you're welcome! good night
[04:11] <elopio> ping cihelp, is there anybody available? I need some help with the qt5.2 job.
[04:12] <doanac`> elopio: its super late for me, but I can try and take a token look for you.
[04:12] <elopio> doanac`: I already got a good result earlier, and I just wanted to confirm it.
[04:13] <elopio> doanac`: if it's so late for you, better keep resting :)
[04:13] <doanac`> elopio: i don't mind taking a quick look. otherwise you might have to wait about 5 hours
[04:14] <elopio> doanac`: ok, if you insist
[04:14] <elopio> http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/label=mako-06/73/consoleText
[04:14] <elopio> I'm getting things like this:
[04:14] <elopio> autopilot.introspection.ProcessSearchError: Search criteria (dbus bus = 'session', connection name = 'com.canonical.Shell.BottomBarVisibilityCommunicator', object path = '/com/canonical/Autopilot/Introspection') returned no results
[04:14] <elopio> ADB_RC=1
[04:14] <elopio> + log_error screen unlock failed, skipping shorts_app
[04:14] <elopio> + echo ERROR: screen unlock failed, skipping shorts_app
[04:14] <elopio> I haven't seen that before, and have no idea how to debug further.
[04:15] <doanac`> elopio: ah the evil unlock-screen stuff
[04:15] <doanac`> i haven't been following those as closely lately, but that type error used to be somewhat flaky
[04:16] <doanac`> elopio: one thing to consider:
[04:17] <doanac`> lp:ubuntu-test-cases/touch (which runs this test) is broke on trunk for this job. So veebers is working off an older revno on our branch
[04:17] <doanac`> i think since that revno, we may have made some changes to the unlock_screen.py file.
[04:17] <doanac`> so its possible that branch doesn't have the best unlock_screen.py  logic.
[04:18] <doanac`> let me check version history
[04:18] <elopio> hum, I can try with latest touch.
[04:18] <doanac`> our trunk still won't work for this job :/
[04:19] <elopio> doanac`: latest change on that project was on the 7th
[04:19] <elopio> today I got a successful run, and then two failed with those unlock screen errors.
[04:19] <doanac`> elopio: yeah. revno 200 backed out the unlock_screen change so it shouldn't have changed
[04:19] <doanac`> i suspect its just flaky
[04:24] <elopio> well, failed 44 times. I suspect is something broken, or misconfigured.
[04:24] <elopio> but anyway, I can wait.
[04:25] <elopio> Mirv gets up in a few hours, and he can tell somebody from ci to take a look.
[04:49] <jdstrand> fyi, click-apparmor 0.1.15.3 migrated to trusty
[04:55] <jdstrand> ok, merged and cleaned (had to manually merge due to acls, but that's fine)
[04:57] <jdstrand> weird, jenkins told me to just free the silo, so I did, but now Status is 'Gave up this landing. Cleaning silo'
[04:57] <jdstrand> oh well, it is in the archive
[05:01] <jdstrand> oh, maybe that was just spurious
[05:02] <Mirv> morning
[05:02] <Mirv> elopio: right, interesting, good that we had at least that one good new run. indeed CI people will be awake only in ~3 hours or so
[05:02] <jdstrand> Mirv: hey-- fyi, click-apparmor 0.1.15.3 is migrated to trusty. the merge and clean just fininished
[05:03] <Mirv> jdstrand: \o/
[05:03] <jdstrand> Mirv: the status on Pending is empty though
[05:03] <jdstrand> not sure if that will right itself or not
[05:04] <Mirv> empty, interesting. well either it updates soon or something went funny, but at least merge and clean seems to have completed well indeed https://code.launchpad.net/~ubuntu-security/click-apparmor/trunk
[05:04] <jdstrand> (I had to merge the branch manually-- maybe that had something to do with it)
[05:05] <jdstrand> I think the merge failed cause it didn't have access to ~ubuntu-security?
[05:05] <Mirv> ah, only free silo
[05:05]  * jdstrand guesses
[05:05] <jdstrand> I tried merge and clean. the merge failed. it said to free the silo, so I did
[05:05] <Mirv> oh, that'd be then a failure in setting up the project for CI Train usage, indeed ps-jenkins would need to be in correct teams
[05:05] <jdstrand> and here we are :)
[05:05] <Mirv> well, that explains it, but at least we know that actually it succeeded
[05:06] <Mirv> yep, https://launchpad.net/~ubuntu-security/+members
[05:06] <jdstrand> interesting. well, ps-jenkins definitely can't be in ubuntu-security, so either they will always need to be manual or I need to think about it more
[05:06] <Mirv> good point. or click-apparmor branch under some different team?
[05:06] <jdstrand> right, that is what I need to think about
[05:07] <jdstrand> alright, I'm going to call it a night. it is landed even if the spreadsheet doesn't think so
[05:07] <jdstrand> Mirv: thanks
[05:08] <Mirv> good night. I left a comment in the sheet and I'll let Didier decide if something else needs to be done
[05:08] <jdstrand> thanks!
[06:48] <didrocks> hey Mirv
[06:49] <didrocks> Mirv: the click apparmor fix has landed, but not in night image, right?
[06:49] <didrocks> seems not
[06:49]  * didrocks kicks a new image
[06:51] <Mirv> didrocks: correct
[07:42] <didrocks> rsalveti: locked component list available (had to set it as a notes or the header in the CI Train spreadsheet would take the whole screen).
[08:07] <sil2100> Mirv: are we landing 5.2 today?
[08:08] <Mirv> sil2100: good question. it'll get decided in the meeting in 5h (13:00 UTC) probably. if it's not today, then it's next week, was discussed yesterday.
[08:08] <Mirv> all the AP failures seem to be under control from what is currently seen
[08:08] <Mirv> rsalveti filed some new bugs, and I'm not then sure if those need some tinkering or will be sorted out later
[08:09] <Mirv> I'm patch pilotting today for a bit
[08:11] <sil2100> Mirv: what about that font too small bug? I see some comments mentioning a fix working, is this done now? :)
[08:15] <Mirv> sil2100: yes, that's done and works. even though it's once again not the "real fix" but patching qtwebkit, while Kaleo continues to work with upstream for the real fix in future Qt versions.
[08:18] <popey> didrocks: with #236 I'm seeing colours changed in calendar
[08:18] <popey> has new ui toolkit landed?
[08:18] <didrocks> popey: wasn't intential in your opinion?
[08:18] <didrocks> popey: nope
[08:18] <popey> how can I get screenshot from this now?
[08:18] <didrocks> popey: last one you tested was?
[08:19] <popey> well, calendar didn't start previously
[08:19] <popey> i haven't dogfooded properly for a few days
[08:19] <didrocks> popey: adb shell mirscreencast -m /tmp/mir_socket -n1
[08:20] <didrocks> adb pull /tmp/mir_screencast_768x1280.rgba
[08:20] <didrocks> convert -size 768x1280 -depth 8 mir_screencast_768x1280.rgba screenshot.png
[08:20] <popey> http://imgur.com/ddIvGSh
[08:20] <popey> thanks
[08:21] <didrocks> popey: it's… art :)
[08:22] <didrocks> minimalist was a thing I heard
[08:22] <popey> otehr apps broken too
[08:22] <popey> but differently
[08:22] <popey> http://paste.ubuntu.com/7083526/
[08:23] <popey> has some theme component been dropped?
[08:23] <didrocks> popey: no, I see nothing related in the past 4 days :/
[08:23] <popey> hmm
[08:23] <didrocks> just checked the diff…
[08:23] <didrocks> in case I missed anything
[08:23] <didrocks> but no :/
[08:24] <didrocks> can you try to revert just to #235?
[08:24] <popey> sure
[08:24] <didrocks> first to see if it's on the latest latest for you
[08:24] <didrocks> I think dave and others will have noticed this as well
[08:24] <didrocks> hanks
[08:24] <didrocks> thanks*
[08:25]  * didrocks finishes his upgrade
[08:25] <popey> aha, i think i may know..
[08:25]  * popey fiddles
[08:25] <didrocks> popey: user's issue, like due to you, you and only you? :)
[08:25] <popey> could be ㋛
[08:26] <popey> hey dude, if we're going to be on 200M phones, some of those users will be idiots
[08:26] <popey> I am simulating that
[08:26] <popey> \o/ fixed
[08:26] <popey> lets not speak of this again
[08:26] <didrocks> popey: no no no
[08:26] <didrocks> you told too much
[08:27] <didrocks> or not enough
[08:27] <didrocks> so, there is no way back :p
[08:27] <popey> I backed up all my data the other day
[08:27] <popey> sick of setting everything up
[08:27] <didrocks> making sense…
[08:27] <popey> restored it last night
[08:27] <popey> adb push phone_backup /home/phablet
[08:27] <didrocks> yep
[08:27] <popey> means most of /home/phablet now owned by root
[08:27] <didrocks> ah :)
[08:27] <popey> chown fixed it
[08:27] <didrocks> hehe
[08:28] <popey> Sorry ☻
[08:28] <didrocks> ok, let's not talk about it then :p
[08:28] <popey> haha
[08:28] <didrocks> ok, confirmed I do not have that here :)
[08:28] <popey> haha
[08:28] <popey> fancy that
[08:28] <didrocks> popey: ok, I hope that this new image will be next promoted one, so dogfooding will be important :)
[08:28] <popey> ok
[08:36] <popey> \o/
[08:36] <popey> screenshot script updated
[08:36] <popey> http://popey.com/~alan/phablet/device-2014-03-13-083616.png
[08:37] <didrocks> popey: your clock is wrong, OMG YOU HAVE A BUG! :)
[08:38] <popey> hah
[08:38] <popey>  /nick chicken_little
[08:38] <didrocks> ;)
[08:38] <didrocks> ah… 236 testing starts \o/
[08:53] <didrocks> cjwatson: thanks for the click link system explanation :)
[09:30] <sil2100> didrocks: you have the meeting e-mail? :)
[09:31] <didrocks> sil2100: no, I didn't get it again :/
[09:31] <ogra_> sigh, i knew it wasnt clever to use my normal account during UDS ... now i cant get into the meeting again
[09:32] <didrocks> ogra_: try harder!
[09:32] <didrocks> no pressure, we are waiting for you :p
[09:33] <didrocks> (and of course, bitch about you as you're not around)
[09:33] <davmor2> ogra_: different browsers for different accounts ;)
[09:33] <ogra_> i use different browsers differently  :P
[11:05] <davmor2> didrocks: things are looking pretty good on 236 for me :)
[11:07] <ogra_> for me all input just died on flo
[11:07] <ogra_> hmm, no, just the webapp
[11:11] <ogra_> and not only this one
[11:12] <ogra_> seems all webapps are crashy after a while, some even right after startup
[11:13] <sil2100> I don't like the sound of that
[11:13] <ogra_> well, it kind of goes hand in hand with the webbrowser-app crashes i suspect
[11:22] <davmor2> ogra_: I see no crashers here on mako let me reflash flo and try there
[11:27] <davmor2> Morning all by the way :)
[11:30] <ogra_> heh
[12:13] <psivaa> sil2100: the tests on mako in the lab has finished. so we could continue on the unity8 investigation
[12:21] <sil2100> \o/
[12:21] <sil2100> psivaa: give me a moment
[12:21] <sil2100> I will prepare everything
[12:22] <didrocks> psivaa: did you rerun the webbrowser-app ones?
[12:23] <psivaa> didrocks: sorry, not yet. will do that
[12:23] <didrocks> psivaa: and do you know what failed on music-app and dropping letters?
[12:23] <didrocks> psivaa: maybe do it before sil2100 is available :)
[12:23] <didrocks> (the settling thingy)
[12:23] <psivaa> didrocks: ack, doing it straight away
[12:23] <sil2100> Indeed ;) I need to modify some more parts of the test
[12:23] <didrocks> psivaa: thanks!
[12:25] <Saviq> didrocks, hey, I didn't manage to point this out in the session yesterday - there's a bit too much monitoring involved during the landing process, do you think we could have a bot that would ping landers on IRC here when jobs complete?
[12:26] <didrocks> Saviq: please open a feature request. Would be nice to have feedback first on recent improvements I've introduced for the landers though
[12:26] <didrocks> Saviq: I'm afraid we're going to turn the intermediate train process in something long-lived if we start adding too much
[12:31] <psivaa> didrocks: unity-system-compositor  and /usr/lib/arm-linux-gnueabihf/unity-scope-home/unity-scope-home are on top of music and dropping letters settle tests
[12:31] <Saviq> didrocks, where should I open? ubuntu-ci-services-itself?
[12:31] <didrocks> Saviq: cupstream2distro
[12:32] <didrocks> psivaa: ok, none changed recently and are not linked to any test, so I'm happy to call that a non issue for now
[12:32] <didrocks> psivaa: let's hope the webbrowser-app rerun will give us good news
[12:32] <Saviq> didrocks, re: adding too much... sure, but those ideas can hopefully live through CI Train and get on CI Airline when ready
[12:32] <psivaa> didrocks: ack, could rerun them if you'd like after the webbrowser tests
[12:33] <didrocks> psivaa: not really needed I guess
[12:33] <didrocks> just let's focus and believe in webbrowser
[12:33] <psivaa> didrocks: ack, thank you :)
[12:33] <didrocks> psivaa: keep me posted, thanks!
[12:36] <didrocks> Saviq: maybe it will be time for me to practice some go…
[12:37] <Saviq> didrocks, ;)
[12:39] <Saviq> didrocks, https://bugs.launchpad.net/cupstream2distro/+bug/1291966
[12:42] <popey> didrocks: update manager seems broken in #236 - it keeps prompting for the same apps over and over
[12:42] <jdstrand> that may not be a 236 thing
[12:43] <popey> the mail from Roman Zonov on the phone list prompted me to look
[12:43] <jdstrand> I'm on 229 and saw that. that was the first with update-manager back iirc after being gone a while. I had some 10 apps that needed updating, so I did 'update all' (or whatever)
[12:44] <popey> yeah, it has broken in the past
[12:44] <jdstrand> at the end, 2 were left as needing to still be updated, so I updated them manually
[12:44] <popey> but it worked again, and now its broken again
[12:44] <popey> yes, that was a package issue - calc and weather, right?
[12:44] <jdstrand> and they were still listed as not updated
[12:44] <jdstrand> honestly, I'm not sure-- when I did it I wasn't at my computer or in a position to diagnose
[12:45] <popey> for a few days there were broken updates for calc and weather
[12:45] <jdstrand> popey: but those sound about right, yes
[12:46] <didrocks> popey: jdstrand: yeah, not new at all
[12:47] <didrocks> Saviq: thanks. Question, how would you make then people caring if something is stuck in proposed or in NEW for hours then? As they expect to receive a ping and don't look back at the spreadsheet
[12:47] <didrocks> thanks for the debug & fix jdstrand btw :)
[12:47] <jdstrand> didrocks: you're welcome. btw, I had quite some issues using citrain for the first time yesterday
[12:48] <Saviq> didrocks, not sure, but the publishing job could monitor it and time out?
[12:48] <Saviq> or maybe fork a proposed-monitoring job or something, that would time out and ping
[12:48] <sil2100> psivaa: let me send you a modified version of test_url_dispatcher.py
[12:48] <didrocks> Saviq: and so harass people like every 4h?
[12:49] <sil2100> psivaa: when re-running the AP test suite, are we forced to do a reinstall, or will it use the existing, pre-installed packages?
[12:49] <didrocks> jdstrand: seems the bot doesn't have commit access to trunk, right?
[12:49] <didrocks> jdstrand: that's something that needs to be done when people swith "in CI Train": True
[12:49] <Saviq> didrocks, not sure about the details, as in how long can a proposed migration take, but I'd say pinging one time would be enough
[12:49] <jdstrand> didrocks: that was one thing-- that isn't a big deal
[12:49] <didrocks> Saviq: if the person isn't connected at that time?
[12:49] <Saviq> didrocks, email
[12:50] <Saviq> didrocks, it's not like it's worse than today
[12:50] <didrocks> Saviq: well, today people know they need to look at the spreadsheet/dashboard
[12:50] <Saviq> didrocks, at that point either the user would have to act and/or restart the monitoring job to get another report
[12:50] <didrocks> Saviq: here, you are creating other expectation
[12:51] <psivaa> sil2100: test_url_dispatcher.py wont be reinstalled if we have a version there
[12:51] <Saviq> didrocks, sure, but if you say that if the migration monitoring fails, for whatever reason, there is action required, it would IMO be fine
[12:51] <sil2100> Excellent
[12:51] <Saviq> didrocks, whether that action is fixing whatever issue caused the migration to get stuck, or just kicking the monitor again
[12:53] <jdstrand> didrocks: if you look at builds 59-74, you could do some archaeology, but basically, I didn't know how to setup the branch correctly to work with citrain. I didn't have a url in my notes and didn't come across it. if it exists and was in training and I missed it, that's on me
[12:53] <didrocks> Saviq: ? the monitoring is working, the question is if it's get stuck, today, you are excepted to look at the spreadsheet
[12:53] <didrocks> on the other hand, you will just get pinged one
[12:54] <jdstrand> didrocks: but I have a native package, so I had to set up debian/control differently. I saw what stgraber did for click, so adjusted that
[12:54] <didrocks> jdstrand: do you have a link for me to look at?
[12:54] <didrocks> jdstrand: the only exceptation is that "bzr bd" works
[12:54] <jdstrand> didrocks: http://162.213.34.102/job/landing-001-1-build/59/ - http://162.213.34.102/job/landing-001-1-build/74/
[12:54] <jdstrand> jdstrand: really have no idea why what stgraber did worked, but it did
[12:55] <jdstrand> didrocks: then it was the changelog handling
[12:55] <didrocks> jdstrand: 59 has the info, didn't?
[12:55] <jdstrand> at first, it added the first 100 commits
[12:55] <didrocks> 2014-03-12 21:30:42,404 ERROR There is no commit message in https://code.launchpad.net/~jdstrand/click-apparmor/click-apparmor.lstat. Please check that you set a commit message on all your MPs.
[12:55] <didrocks> jdstrand: yeah, you missed a release tag I guess
[12:55] <jdstrand> didrocks: I'm not asking that you look through all of it-- I'm just saying those have everything if you want to
[12:56] <jdstrand> so, I didn't know how changelog handling should be-- so, yes, I missed it in the MP
[12:56] <didrocks> jdstrand: ok, I think you just didn't setup it. We are doing that verification when in the bootcamp, we turn "in CI Train" to yes
[12:56] <jdstrand> I added it and got the last 100 commits, even though I had the 0.1.14 tag already
[12:56] <didrocks> jdstrand: hum, weird, it's getting the previous release, and tagging it
[12:57] <didrocks> then, just collect since the previous release tag
[12:57] <jdstrand> I asked cyphermox to look at my wiki pages, but I didn't ask about my branch
[12:57] <Saviq> didrocks, the "needs to look at..." is the bad part, I need to remember to look at it in between other tasks, and I often forget, missing the time when I could have already acted by minutes, or worse, hours
[12:57] <jdstrand> didrocks: yes, that didn't work
[12:57] <didrocks> (and it's the setup for the 300 projects we have)
[12:57] <didrocks> hum
[12:57] <Saviq> didrocks, let's discuss on the bug?
[12:57] <jdstrand> but then, all of a sudden, it did
[12:57] <didrocks> I'll try to have a look
[12:57] <jdstrand> and I don't know why
[12:57] <didrocks> Saviq: well, then, people don't look and complain as well they don't know about the image state
[12:57] <didrocks> because the landing email isn't enough
[12:58] <didrocks> and they don't look at the spreadsheet
[12:58]  * didrocks is unsure about what to do
[12:58] <didrocks> jdstrand: I'll have a look and see, we should probably update as well the bootstrapping project wiki page
[12:58] <jdstrand> didrocks: the whole time, my MP branch had changes to debian/changelog. then, after it was working, I was getting weird duplicate entries in the autogenerated one
[12:59] <didrocks> jdstrand: do you have your final branch?
[12:59] <didrocks> jdstrand: the rule is pretty simple: it's taking the commit message if you didn't touch debian/changelog in that MP
[12:59] <didrocks> if you changed anything in debian/changelog in the MP, it won't add anything
[13:00] <jdstrand> finally the combination seemed to be: have a commit message in the MP that exactly matches what is in the branch (minus the first and last lines (ie, no pkackage ..., and no committer), set the disrtibution name to UNRELEASED, increment the version to something not in the landing ppa, use urgency=low
[13:01] <didrocks> jdstrand: not really
[13:01]  * cjwatson scans the Qt silo for successful builds in the primary archive without successful builds in the silo, finds none
[13:01] <didrocks> it's the rule I put above ^
[13:01] <cjwatson> that's a relief
[13:01] <jdstrand> I was told that if I had changes to debian/changelog, it would prefer those. I did the whole time, so I don't know why I had 100 commit messages at first-- but the debian/changelog wasn't set to UNRELEASED or urgency=low, so maybe it was that
[13:01] <cjwatson> jdstrand: FWIW that isn't a combination I've needed to follow with click
[13:01] <jdstrand> didrocks: re not really> except, yes, really :) it may not suypposed to work that way, but that was the only combination that worked
[13:01] <didrocks> jdstrand: urgency=low has nothing to do for sure :)
[13:02] <cjwatson> I use UNRELEASED as a matter of course; but urgency=medium has been fine for me and I haven't needed to be at all careful about the commit message
[13:02] <didrocks> so, as told:
[13:02] <didrocks> (please read this :p)
[13:02] <didrocks> 1. we collect and merge the branches
[13:02] <jdstrand> what can I say-- robru suggested I change it, then it started working. maybe there was another change that went with it. I don't know
[13:02] <didrocks> 2. then, we start from previous released version available in debian/changelog
[13:02] <didrocks> look for the tag
[13:03] <didrocks> bzr log --diff -r tag:<that version>
[13:03] <didrocks> and on each commit on the mainline
[13:03] <didrocks> è we take the commit message if debian/changelog wasn't touched in that commit
[13:03] <didrocks> - we don't do anything if debian/changelog has changed
[13:03] <didrocks> and that's what is filing the changelog
[13:05] <jdstrand> didrocks: right, so I thought I had done what was needed for '2'-- I had a tag and I changed the changelog, and I got 100 commits. I can say that I didn't use UNRELEASED at this point
[13:06] <jdstrand> didrocks: but, I'm not trying to waste your time here. this isn't a proper bug report-- I don't have all the exact steps to repeat. I am more describing how it all played out and it took hours to finally get it sorted
[13:06] <didrocks> jdstrand: weird, this code has been there for almost 2 years, I'm sure we're missing something in the boostrap process
[13:07] <cjwatson> UNRELEASED sounds like a plausible candidate, if dch -r is being used
[13:07] <jdstrand> if I had been pointed to a wiki page in training that said "here is how you set up your branches. here is how autocommits work. here is how the changelog is generated. ps-jenkins needs to have commit access. here is what you do differently for a native packag. etc" then I would have been better off
[13:07] <didrocks> jdstrand: we had that for daily releases
[13:07] <jdstrand> if I was pointed to that and missed it, again, that's on me
[13:07] <didrocks> jdstrand: remember I was tasked for 2 days for CI Train
[13:08] <didrocks> and I'm already at 12h+ a day, so if someone can either take that off me or help here…
[13:08] <cjwatson> I dunno about you but that argument never works for me ;-)
[13:08] <didrocks> cjwatson: yeah, I keep being hopeful :p
[13:09] <dobey> are native versions not working in CI train? does it not use the same code as the older daily-release stuff?
[13:09] <didrocks> dobey: it's the same code
[13:09] <didrocks> dobey: so your change is in
[13:09] <didrocks> and click is native IIRC
[13:09] <dobey> oh ok, good
[13:09] <cjwatson> it is
[13:10] <jdstrand> didrocks: well, also, note, I am not being critical of the process or of you. I was asked last night to let you know the issues I had. I am only suggesting that if I or others had been pointed at wiki documentation, then I (and/or others-- maybe I'm the only one) would've had an easier time coming online
[13:11] <jdstrand> didrocks: so, don't feel you have to be an archaeologist, just saying, if you want to dive in, you know where to look
[13:11] <Saviq> fginther, hey, so we've reached one more instance where we need to land unity8 and unity-mir together, but -ci jobs obviously don't know about that, is there any short-term plan to improve that situation or do we need to wait for CI Airline for that?
[13:11] <didrocks> jdstrand: I agree that's needed, I'll try to get some people documenting that, we need a good bootstrap story rather than "ask us"
[13:11] <didrocks> psivaa: webbrowser-app is fine now
[13:11] <dobey> ideally the bootstrap story would be "convert your package to native"
[13:12] <jdstrand> didrocks: re ask us> I did ask-- I had a note to ask if I was setup properly, but I didn't think to ask if the branch was setup right, so my questions were leading
[13:12] <didrocks> dobey: not the case for everyone, a lot of people are opinionated in different ways
[13:12] <psivaa> didrocks: yep, just running once more to confirm
[13:12] <cjwatson> well, ultimately our CI needs to be able to handle a variety of package types
[13:13] <didrocks> cjwatson: yeah, but if you have a branch with 100 without any tag for previous releases, no way to get that info reliably
[13:13] <dobey> didrocks: yes, well, there is no "for everyone" case. but "make it native" is a) simple b) well understood by people who make packages
[13:13] <cjwatson> if it can only handle things we're upstream for, that limits its usefulness
[13:13] <jdstrand> didrocks: I think maybe it was assumed in training that people coming online were already doing daily releases in the past. this was my first time setting up a branch in this manner...
[13:13] <didrocks> to generate a changelog
[13:13] <cjwatson> didrocks: sure
[13:13] <didrocks> jdstrand: probably yeah, we had no change for most of projects
[13:13] <didrocks> basically it's:
[13:13] <didrocks> - getting the bot commit rights to access the project
[13:14] <didrocks> - ensure bzr bd is working (for bzr branch)
[13:14] <jdstrand> didrocks: so I didn't really understand the technical implications of doing the automerge and autochangelog.
[13:14] <didrocks> - get the previous release tagged
[13:14] <jdstrand> didrocks: so I didn't ask more questions. that is probably on me too
[13:14] <cjwatson> with click we have a separate thing under ~ubuntu-managed-branches that the bot commits to, which I then merge back
[13:14] <jdstrand> cjwatson: yeah, I noticed that
[13:15] <didrocks> yeah, I know, and you have a special tag in debian/control which tells "don't do anything to the changelog about from dch -r it"
[13:15] <cjwatson> right
[13:15] <didrocks> s/about/apart/
[13:15] <jdstrand> I still need to work out the autocommit bits, but I understand how to do that
[13:15] <cjwatson> didrocks: I know you know :)  but suspected jdstrand didn't have all the details
[13:16] <elopio> cjohnston: I need some help understanding why the clock tests are not being run here: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/75/label=mako-06/testReport/%28root%29/ubuntu_clock_app/phablet_test_run/?
[13:16] <didrocks> davmor2: so, dogfooding == +1? :)
[13:17] <fginther> Saviq, We don't have an intermediate plan for that use case. It's probably worth a discussion with didrocks if there is a reasonable short term fix for that
[13:17] <davmor2> didrocks: yeah I said it looked good hours ago dude ;)  I just need to fill out a million and one forms now
[13:17] <jdstrand> didrocks: there are a few bona-fide bugs though: 1) when I click 'build' in jenkins it takes me to 2fa. noscript thinks it is an XSS. 2) if I change debian/changelog, jenkins tells me I still need to have a commit message in the MP, even though it is (apparently) discarded. 3) cause the autocommit failed, I was told to free the silo. I did, but the spreadsheet didn't notice that the changes actually migrated to trusty-- it seemed it could hav
[13:18] <didrocks> fginther: no idea, as it's clearly the airline for that
[13:18] <davmor2> [11:05 ]<davmor2> didrocks: things are looking pretty good on 236 for me :)
[13:18] <cjohnston> elopio: looking
[13:18] <didrocks> davmor2: just confirming it was a clera +1 from you :)
[13:18] <fginther> Saviq, A lot of it will have to do with the timeline for rolling out the ci-airline. If we can continue to make good progress on it, it may not be that painful for long
[13:19] <jdstrand> didrocks: regarding debian/control> X-Auto-Uploader. and now I know what it does based on your comment :)
[13:19] <Saviq> fginther, mhm
[13:19] <didrocks> jdstrand: I guess 1) is a general jenkins + online account integration?
[13:19] <didrocks> sorry sso
[13:19] <davmor2> didrocks: yeah seems no better or worse than 226 or 229
[13:19] <jdstrand> didrocks: re 1> perhaps, just passing it along
[13:19] <didrocks> jdstrand: for 2), yeah, I need to work on that
[13:20] <didrocks> jdstrand: on 3) -> well, I would say it's complicated to do in the timeframe I'm given for it
[13:21] <didrocks> jdstrand: can't do with 2 days all functionalities that are in a month project, and this one would be a special case hard to track TBH
[13:21] <didrocks> ogra_: let's promote #236 then!
[13:21] <cjohnston> elopio: it looks like things are being run, at 08:41
[13:22] <jdstrand> didrocks: there seems to be a 4) autochangelog didn't dtrt wrt tag -- I don't know the exact symptoms though. it magically went away. perhaps it was related to the distribution name... I really don't know. the bug is probably that I didn't format things correctly (ie, a docs bug)
[13:22] <ogra_> didrocks, ok
[13:22] <jdstrand> didrocks: again, this isn't me being critical. I'm only giving feedback as a first time user. feel free to add it to a TODO list or delegate, or whatever
[13:23] <elopio> cjohnston: on the logs I see (process:3131): dconf-CRITICAL **: unable to create file '/run/user/32011/dconf/user': Permission denied.  dconf will not work properly.
[13:23] <didrocks> jdstrand: I'm really puzzled on the 4) though, and hard to see after the fact (because of the rerun) why it didn't pick up the tag
[13:23] <elopio> could that be related? It says critical.
[13:23] <cjohnston> elopio: no idea.. fginther ^
[13:24] <fginther> cjohnston, elopio reading backlog
[13:24] <jdstrand> didrocks: fwiw, robru poured through the code and couldn't see it either. I wouldn't necessarily waste too much time on it if we are going to have docs for the bzr branches
[13:24] <didrocks> jdstrand: yeah, I think it's the best approach to get
[13:25] <jdstrand> it would take too long to recreate-- there were commits to trunk, to the MP, changes to the MP in LP, re-requests to merge, incrementing versions, distribution name changes, etc, etc
[13:25] <jdstrand> there was a lot going on trying to get it to work :)
[13:26] <jdstrand> ok, enough about all that
[13:26] <didrocks> jdstrand: ah, on the commit message though
[13:26] <didrocks> jdstrand: as the bot bzr merge in your branch
[13:26] <didrocks> it needs to have a commit message
[13:26] <jdstrand> now that click-apparmor is all set up (except the autocommit, which I may need today) I'd like to request a landing for 2.0. this is for supporting the 14.04 frameworks. it can come after qt5.2. I am off tomorrow and there is no landings meeting today
[13:27] <didrocks> it can maybe debcommit if there are changes in debian/changelog
[13:27] <jdstrand> didrocks: in the docs, it might be worthwhile to mention that commits to debian/changelog need to happen in a certain matter
[13:27] <jdstrand> s/matter/manner/
[13:27] <didrocks> what do you mean?
[13:27] <jdstrand> whoa, not click-apparmor 2.0, but 0.2
[13:28] <didrocks> ah, no that far :)
[13:28] <jdstrand> didrocks: I sometimes commit to debian/changelog with the code commits. a couple of times in this conversation, it sounds like maybe it needs to happen differently. perhaps I misunderstood
[13:28] <elopio> cjohnston, fginther: I can get it on my phone. Test starts to run, then gets stuck showing NaN on some timer rows, and finally the terminal prints killed.
[13:28] <didrocks> jdstrand: I'm not sure as well you got the support you needed TBH
[13:29] <elopio> and now my phone doesn't want to turn the screen on :/
[13:29] <didrocks> jdstrand: some people operating the engine have misconception, and even repeating the same things, it doesn't seem to stick
[13:29]  * sil2100 has to jump out on an emergency right now ;/
[13:29] <jdstrand> well, people are busy. I haven't done autolandings before
[13:29] <jdstrand> note> people were not too busy to help me
[13:29] <jdstrand> robru and cyphermox were very helpful and responsive
[13:30] <didrocks> jdstrand: basically, the rule is simple: if you change debian/changelog, it won't touch it for that MP. If you didn't, it will take the commit message on the mainline
[13:30] <cjwatson> jdstrand: for click, I more or less always commit to debian/changelog with the code commits, FWIW
[13:30] <jdstrand> yes, that is my understanding and what I've documented for myself
[13:30] <jdstrand> cjwatson: ok, good to know
[13:30] <didrocks> jdstrand: https://wiki.ubuntu.com/DailyRelease/StackPublish#The_prepare_phase (5th bullet)
[13:30] <didrocks> 6th sorry
[13:31] <didrocks> "Then, we prepare the changelog content.
[13:31] <didrocks> "
[13:31] <fginther> elopio, that sounds a bit like the behavior in the test. I see "killed" on the log
[13:31] <fginther> elopio, "Killed" to be precise
[13:31] <jdstrand> I might chalk it all up to that trunk didn't have X-Auto-Uploader and did do UNRELEASED (though it did have a tag)
[13:31] <jdstrand> s/did do/didn't do/
[13:32] <jdstrand> didrocks: ack> I didn't have the page in my notes. like I said, if it was given, that's on me
[13:32] <elopio> fginther: I suppose it's autopilot being killed, because if it's just the clock, then on the following test autopilot would open it again.
[13:32] <didrocks> jdstrand: well, this is the special case for core-devs/people who want to control themselves the changelog (only click and system-image are using that)
[13:32] <didrocks> jdstrand: you enter that category, so you can use it :)
[13:32] <Saviq> fginther, didrocks, I think the simplest short-term thing we could do would be to allow providing a ppa: parameter to be added for -ci jobs - would obviously require manual intervention, but once a dependant silo is built, we could use it in -ci jobs for additional verification
[13:33] <didrocks> in that case, it will never try to generate the changelog
[13:33] <jdstrand> didrocks: I see
[13:33] <didrocks> Saviq: agreed
[13:33] <didrocks> jdstrand: let me check what it does if you don't set it to UNRELEASED though
[13:33] <jdstrand> as for click-apparmor 0.2, may I have a slot in Pending?
[13:34] <didrocks> jdstrand: sure, sil2100 ^
[13:34] <elopio> well, it's like everything gets stuck
[13:34] <jdstrand> I don't really care if it lands today or anything-- I just want it to be all built so we can land after qt5.2 lands. cause once that lands, we are going to add the 14.04 click frameworks
[13:35] <fginther> elopio, any crash files?
[13:35] <Mirv> rsalveti: your 5.1.1-1ubuntu5 in qtwebkit-c looks great! meaning, that can be used as is without recompilation if need be. I was looking to get your changes into my branch but there's nothing to change really from yours.
[13:36] <rsalveti> Mirv: you're fast
[13:36] <rsalveti> :P
[13:36] <rsalveti> was upgrading it here
[13:36] <fginther> Saviq, that's not an impossible idea.  I have some changes coming for the touch testing in a couple weeks. I think that might be an easy add
[13:36] <jdstrand> didrocks: one last thing, and it is more of a heads up. I'm going to ask for a landing for apparmor first thing next week. apparmor is controlled by us, but for historical reasons, we have orig.tar.gz and treat it like an upstream. I imagine I'll want to upload packages to the silo ppa. we don't need to discuss this all now, but just fyi, I'll need more hand-holding next week
[13:36] <Mirv> rsalveti: you don't have that many PPAs to browse through to find possible treats :)
[13:36] <rsalveti> Mirv: :-) but cool, still testing, but can indeed be used without recompilation
[13:36] <didrocks> jdstrand: hum, seems sil2100 isn't there…
[13:37] <didrocks> jdstrand: let me asssign it to you, but I don't see a line
[13:37] <Saviq> fginther, awesome, btw, do you know who do I talk to to make sure smokeng does the same changes to unlock you guys did for touch testrunner?
[13:37] <elopio> fginther: I get almost the same as http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/label=mako-06/lastSuccessfulBuild/artifact/clientlogs/ubuntu_clock_app/application-click-com.ubuntu.clock_clock_1.0.373.log
[13:37] <didrocks> jdstrand: sure no worry :)
[13:37] <jdstrand> didrocks: that is a question in the process. should I add a line to Pending and then request a silo or do I ask first?
[13:38] <didrocks> jdstrand: no, just add a line, then turn the "Ready" to Yes
[13:38] <jdstrand> ah
[13:38] <jdstrand> ok
[13:38]  * jdstrand does that
[13:38] <didrocks> jdstrand: we are looking regularly at the spreadsheet, so if you are not in a hurry, no real need to ping us
[13:38] <didrocks> you can always ping us if needed of course :)
[13:38] <jdstrand> I'll add the line, then prepare it all today. I won't mark to Ready until later today
[13:39] <jdstrand> didrocks: thanks again! and thanks for listening to my whining :)
[13:39] <didrocks> jdstrand: ok, we'll assign it once you set it to Ready ;)
[13:39] <fginther> Saviq, that would normally be doanac` and plars-away, but I can check to see what it's doing... give me a moment please
[13:39] <rsalveti> davmor2: mind trying webkit from https://launchpad.net/~rsalveti/+archive/qtwebkit-c/+packages ?
[13:39] <didrocks> jdstrand: no worry
[13:39] <jdstrand> my tone was not intended to be of complaint, but of information
[13:39] <didrocks> yeah, I know, no worry
[13:39] <jdstrand> sharing
[13:39] <jdstrand> ok
[13:39] <Saviq> fginther, thanks
[13:40] <rsalveti> davmor2: add the ppa, run apt-get update, then: apt-get install libqt5webkit5=5.1.1-1ubuntu5 libqt5webkit5-qmlwebkitplugin=5.1.1-1ubuntu5
[13:40] <fginther> elopio, but nothing in /var/crash?
[13:41] <rsalveti> Mirv: but yeah, I can play fruity pops again :-)
[13:41] <jdstrand> cjwatson: thanks for your help too. the pointers on what stgraber did and the info on your click/citrain experience was/is very helpful
[13:41] <rsalveti> ogra_: ^
[13:41] <Mirv> davmor2: popey: ^ if you have time to test rsalveti's special qtwebkit (to see if it works good for us, also for the OpenGL webapps), see http://pastebin.ubuntu.com/7084694/ on how to install on your Qt 5.2 enabled device
[13:42] <fginther> Saviq, it's using the 'old' method. The process helpers method was added on march 6, but backed out the next day
[13:42] <davmor2> Mirv, rsalveti: I can after lunch yes
[13:42] <popey> Mirv: unsure I'll have time. I'm solid with UDS sessions today
[13:42] <ogra_> rsalveti, yay
[13:42] <ogra_> most important !
[13:43] <elopio> fginther: no, nothing there.
[13:43] <Saviq> fginther, hmm so sounds about the same time you guys were doing the changes for touch testrunner
[13:43] <elopio> oh, there's one file now.
[13:43] <Saviq> fginther, thanks, I'll pick it up with the guys
[13:43] <fginther> Saviq, you're welcome
[13:45] <Saviq> doanac`, plars-away, hey guys, wanted to ask about the unity8 unlock script used in smoke tests, we're removing the thing you're relying on soon, fginther and om26er already implemented the new method using unity8's helpers that we maintain, apparently you tried it and backed out around a week ago, can we help making the switch somehow?
[13:46] <fginther> Saviq, who soon before the thing you going to remove gets removed?
[13:46] <fginther> s/who/how/
[13:47] <elopio> fginther: http://ubuntuone.com/5jruFMGVY7ueXemsPhxndI
[13:47] <didrocks> jdstrand: I think I've an evil idea on how to do 3) (the wrong gave up when you didn't really gave up)
[13:47] <didrocks> in a cheap way
[13:47] <Saviq> fginther, we already have the branch ack'ed, just waiting for Qt 5.2 to land, and then - asap
[13:47] <fginther> Saviq, thanks for the timeline
[13:48] <Saviq> fginther, but obviously only after we resolve this testing situation
[13:55] <jdstrand> didrocks: neat :)
[13:57] <sergiusens> fginther, I'd just move that to phablet-test-run with an option to have 'whatever component we need' reloaded with the testability driver
[14:01] <fginther> sergiusens, ack, there's also an unlock_unity() method in this case. But I agree, there's no reason this can't be done as part of ptr.
[14:02] <sergiusens> fginther, just so we are all on the same page
[14:02]  * sergiusens needs the FFe approved though
[14:03] <didrocks> sergiusens: I saw the status changing
[14:03] <didrocks> I guess it was on your bug
[14:04] <sergiusens> didrocks, yeah, someone marked it confirmed; not sure that's from the release team though
[14:05] <didrocks> sergiusens: yeah, I don't know
[14:05] <didrocks> didn't click on the name, but doesn't ring a bell
[14:06] <rsalveti> Mirv: I'd guess we also need to rebuild webbrowser-app?
[14:06] <rsalveti> I can rebuild it as well
[14:08] <fginther> elopio, now that you have a crash, do you have what you need to make progress on it? At the moment, I don't know why the job didn't record any logs or the crash, I can create a bug for it.
[14:08] <didrocks> jdstrand: ok, 3) fixed (even if it's a rare corner case where you can't merge your branch but components are in destination)
[14:09] <elopio> fginther: well, I need to decipher it. When I try to report it with apport-cli, I get:
[14:09] <elopio> http://paste.ubuntu.com/7084803/
[14:09] <elopio> I'm not really sure what I'm looking for.
[14:09] <jdstrand> didrocks: nice! (that was fast :)
[14:09] <Mirv> rsalveti: maybe, but at least it doesn't fail to find any symbols or such
[14:09] <rsalveti> Mirv: yeah
[14:09] <rsalveti> but it's always good anyway
[14:10] <Mirv> sure it is
[14:10] <rsalveti> Mirv: problem is that to rebuild on the ppa, we first need to drop the 5.2 based qtwebkit packages
[14:10] <rsalveti> and copy the 5.1 ones
[14:10] <rsalveti> Mirv: do we have the 5.2 qtwebkit packages available at another ppa?
[14:10] <Mirv> rsalveti: yeah, I was wondering whether it would be best to do already (first making a backup of the 5.2.1 debs somewhere)
[14:11] <rsalveti> if so we can probably drop it already from landing 6, and copy the 5.1.1 on top
[14:11] <rsalveti> Mirv: yeah
[14:11] <Mirv> rsalveti: ok, let me handle it
[14:11] <rsalveti> Mirv: thanks
[14:11] <fginther> elopio, try '/usr/share/apport/whoopsie-upload-all -t 0'. it might do enough to get a stack trace
[14:12] <fginther> elopio, if so, it'll update the crash file in place
[14:12] <sergiusens> elopio, send me the crash
[14:12] <elopio> sergiusens: http://ubuntuone.com/5jruFMGVY7ueXemsPhxndI
[14:12] <elopio> fginther: running that...
[14:17] <elopio> fginther: after running whoopsie: http://ubuntuone.com/2j253XGeiTTh0GSZKubHQ3
[14:17] <elopio> not a lot more, it added the dependencies.
[14:18] <sergiusens> elopio, I think that's a bogus error because there's no core in your crash file
[14:19] <sergiusens> elopio, looking by the loaded symbols; and if this only happens in autopilot testing; I'd look at /usr/lib/libautopilot_driver_qt5.so.1.0.0 and probably /usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu/PerformanceMetrics/libUbuntuPerformanceMetrics.so
[14:20] <elopio> sergiusens: it doesn't happen only with autopilot testing.
[14:20] <elopio> when I open the clock manually, and go to the timer tab, I see the same as autopilot, and after a while it crashes.
[14:22] <elopio> anyway, I still don't know what should I look on those libs :). Mirv, something about this makes sense to you?
[14:22] <sergiusens> elopio, I suggest to load the clock app and attach gdb to qmlscene
[14:24] <elopio> ok, I'll try to do that.
[14:36] <mhr3> sil2100, can i get a ignore conflicts silo for line 37?
[14:42] <didrocks> jdstrand: the vUDS session was boring. So 2/ -> fixed. We try to fallback to debcommit if there is no commit message available
[14:42] <didrocks> jdstrand: it's in preprod now, I'll put that in prod if everything's fine tomorrow morning
[14:43] <mhr3> didrocks, to kill your boredom ^^ :)
[14:43] <didrocks> jdstrand: I'm passing 1/ to webops, but I guess nobody is maintaining the jenkins sso plugin I'm afraid :/ on 4/ -> I have no idea on the tag
[14:43] <didrocks> mhr3: I'm sad sil2100 is again not around :/
[14:44] <silDroid> mhr3: I think so, yes, although I'm not in front of my pc right bow
[14:44] <silDroid> *now
[14:44] <silDroid> I'm around around, I can try doing it now ;)
[14:44] <didrocks> silDroid: hum, it's been some hours I'm asking you and it happens quite often you are not around :/
[14:44] <silDroid> Might take a bit longer, through the phibe
[14:44] <didrocks> anyway
[14:45] <didrocks> mhr3: I'm doing it… you are not going to publish click-scope before 5.2?
[14:45] <mhr3> didrocks, probably not, unless 5.2 takes few more days
[14:46] <didrocks> mhr3: should be today or tomorrow
[14:46] <Mirv> elopio: I'm not sure, but the .crash files don't have a CoreDump so it's not the sort of crasher that a backtrace can be gotten for
[14:47] <rsalveti> didrocks: thanks for the locked component list
[14:47] <didrocks> rsalveti: yw
[14:47] <silDroid> psivaa: any progress? How far is it?
[14:47] <jdstrand> didrocks: re 2> again, nice! :)
[14:48] <psivaa> silDroid: the tests finished.. let me find the logs after this meeting that i am in .. in about 20 mins
[14:48] <jdstrand> didrocks: as for '1', yeah-- I haven't see that sso XSS anywhere else besides jenkins, so thought it was odd
[14:48] <didrocks> jdstrand: I think it's a plugin canonical contributed (https://wiki.jenkins-ci.org/display/JENKINS/OpenID+plugin)
[14:49] <didrocks> jdstrand: we have it installed on most of our jenkins instance AFAIK
[14:49] <silDroid> psivaa: thanks, as the time of test execution made me wonder if those got ran ;) It still says something 2 hours ago
[14:49] <ogra_> [14:49]  * jdstrand is not a big jenkins user until recently, if you hadn't guessed :)
[14:49] <didrocks> ogra_: sweet!
[14:50] <didrocks> jdstrand: heh, I won't blame you for that :p
[14:50] <ogra_> sorry that it took so long
[14:50] <didrocks> ogra_: well, it's ok, the image isn't going to change by itself :p
[14:50] <psivaa> silDroid: those runs can not be seen in the dashboard. but: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-unity8/27/
[14:51] <didrocks> mhr3: assigned
[14:51] <silDroid> psivaa: ah, right, looking! Thanks
[14:53] <silDroid> Hmmm
[14:54] <silDroid> psivaa: give me a poke once you're after the meeting
[14:54] <pmcgowan> rsalveti,Mirv  anything I can help with landings wise
[14:55] <pmcgowan> I saw we reverted webkit to last version
[14:55] <psivaa> silDroid: http://paste.ubuntu.com/7085028/ *.qml
[14:55] <Mirv> pmcgowan: schedule a meeting in two hours so we can catch up again?
[14:55] <pmcgowan> ok
[14:55] <Mirv> yes, the webkit reversion seems to help with the OpenGL games
[14:55] <psivaa> silDroid: http://paste.ubuntu.com/7085032/ test_results.xml
[14:56] <Mirv> so it could be the solution until oxide arrives
[14:56] <davmor2> rsalveti, Mirv: that fix seems to let all three play again
[14:56] <psivaa> silDroid: http://paste.ubuntu.com/7085034/ tmp*.desktop
[14:56] <rsalveti> pmcgowan: yeah, let's talk during the uds lunch break
[14:57] <pmcgowan> rsalveti, Mirv scheduled
[14:57] <elopio> sergiusens, Mirv: does this give more information? http://paste.ubuntu.com/7085037/
[14:57] <rsalveti> pmcgowan: but it seems that the qtwebkit revert helps fixing the webgl games
[14:57] <rsalveti> davmor2: great
[14:57] <pmcgowan> rsalveti, odd, but who knows
[14:57] <pmcgowan> oxide will help fer sure
[14:57] <rsalveti> pmcgowan: it's fine, we don't need to care much anyway
[14:57] <pmcgowan> agreed
[14:58] <silDroid> psivaa: thanks, but it seems the first pastebin (the one with qml) is the same as the result pastebin here
[14:58] <rsalveti> all we needed is a working webkit until we're able to land oxide
[14:58] <silDroid> Anyway, magic
[14:58] <sergiusens> elopio, v4 was the new qml engine, right?
[14:58] <sergiusens> rsalveti, ^^?
[14:59] <rsalveti> pmcgowan: there's just one remaining issue that tsdgeos is investigating (qmlscene crash)
[14:59] <elopio> yes
[14:59] <davmor2> rsalveti: is that the next big land after 5.2.1 or is the next one scopes?
[14:59] <rsalveti> sergiusens: yes
[14:59] <sergiusens> elopio, so it's v4
[14:59] <pmcgowan> rsalveti, did the sudoku issue get fixed?
[14:59] <Mirv> elopio: it might be related to the one that was given to tsdgeos rsalveti filed about
[14:59] <rsalveti> davmor2: not sure what is next, but oxide will take a few days at least to be ready
[14:59] <rsalveti> pmcgowan: there's a mr already, didn't test it though
[14:59] <davmor2> rsalveti: man days :'(
[15:00] <pmcgowan> rsalveti, hah, he just deleted the line that failed
[15:00] <pmcgowan> probably was not needed anyway
[15:01] <rsalveti> pmcgowan: right :-)
[15:02] <rsalveti> elopio: sergiusens: looks like a different crash, is that qt5.2 related? also, what crashed exactly?
[15:02] <sergiusens> rsalveti, clock app
[15:02] <sergiusens> rsalveti, qt5.2
[15:02] <elopio> rsalveti: if you have your phone with qt5.2, just open the clock and go to the timer tab
[15:02] <rsalveti> sergiusens: when running autopilot?
[15:02] <elopio> you might need to click a preset.
[15:02] <rsalveti> oh, ok
[15:02] <rsalveti> let me try
[15:02] <davmor2> pmcgowan: after hearing that the phone is sabdfl's sudoku machine now we have to make sure that it works it's critical right :)
[15:03] <pmcgowan> davmor2, super critical, defcon 5
[15:03] <elopio> ogra_: btw, thanks for the screenshooter. It was really hard to report bugs taking photos to the phone with my webcam :)
[15:04] <pmcgowan> davmor2, balloons so can we get that mr landed for sudoku?
[15:04] <ogra_> :)
[15:04] <balloons> haha davmor2
[15:04] <davmor2> pmcgowan: nothing I can do about it,  I think it is one for balloons and popey maybe?
[15:05] <rsalveti> elopio: not sure if crashed, but my flo is now dead
[15:05] <rsalveti> even ssh was dropped
[15:05] <davmor2> rsalveti: ran out of battery?
[15:05] <rsalveti> no, screen is still on ;-)
[15:05] <rsalveti> but it seems cpu is on fire in here
[15:05] <elopio> rsalveti: give it some time, then the clock app will be closed, your device will be again usable, and the crash will appear on /var/crash
[15:06] <rsalveti> and eating all the memory
[15:09] <elopio>  https://bugs.launchpad.net/ubuntu-clock-app/+bug/1292047
[15:09] <psivaa> silDroid: http://paste.ubuntu.com/7085119/ sorry about it earlier
[15:10] <rsalveti> yeah, this is a serious bug
[15:10] <rsalveti> it makes the device useless basically
[15:11] <rsalveti> consuming 76% of my ram
[15:11] <rsalveti> and oom already killed a bunch of other guys
[15:13] <davmor2> rsalveti: do you get video for unity8 vuds session
[15:13] <rsalveti> following oem customizations atm
[15:14] <ogra_> same here
[15:18] <sil2100> psivaa: thanks!
[15:20] <psivaa> sil2100: is that enough. i need to enable some devices in the lab if we are done with it for the next tests to picke the right devices
[15:21] <sil2100> psivaa: could you double check if there still is no url-dispatcher?
[15:21] <sil2100> log?
[15:22] <psivaa> sil2100: not under /home/phablet/.cache/upstart
[15:22] <sil2100> What madness is that, eh
[15:23] <sil2100> psivaa: last question - the *.desktop file you got from /home/phablet/.local/share/applications/tmp1I0Vwc.desktop, right?
[15:24] <psivaa> sil2100: yeas
[15:24] <psivaa> *yes
[15:26] <sil2100> Too bad we can't really see what's happening on screen
[15:26] <pmcgowan> jdstrand, my calculator works again
[15:26] <jdstrand> \o/
[15:27] <jdstrand> pmcgowan: now you can calculate the tip for cjwatson and me :)
[15:27] <pmcgowan> jdstrand, hang on there
[15:27] <jdstrand> what is 20% of 0?
[15:27] <pmcgowan> right
[15:27] <jdstrand> :)
[15:27] <pmcgowan> but you have to split it
[15:28] <jdstrand> better make it 25% then
[15:28] <jdstrand> I'll only take 7% for my bit. I didn't do nearly the heavy lifting
[15:39] <sil2100> psivaa: are you still around for a different test for a different issue ;p ?
[15:39] <psivaa> sil2100: could do.. :)
[15:43] <sil2100> psivaa: so, I would need any mako device that just ran all the tests (and had the _usr_sbin_system-image-dbus.32011.crash crash)
[15:44] <sil2100> psivaa: could you log into that device and do a simple `ls -l /var/log/system-image`?
[15:44] <sil2100> We want to see if the perms are alright
[15:49] <psivaa> sil2100: the device that ran all the tests has been used for some other installation. i'll run ubuntu_system_settings test which i think produces this crash
[15:50] <sil2100> psivaa: ok, thanks :)
[15:54] <rsalveti> Mirv: it seems you already updated everyone that depends on qtwebkit
[16:03] <psivaa> sil2100: http://paste.ubuntu.com/7085394/ is the client.log under /var/log/system-image/
[16:03] <psivaa> on the device that saw _usr_sbin_system-image-dbus.32011.cras crash
[16:03] <sil2100> psivaa: can you check the permissions of files there?
[16:04] <sil2100> Like, the permission of /var/log/system-image and the files there (so like ls -l /var/log/system-image)
[16:05] <psivaa> sil2100: http://pastebin.ubuntu.com/7085411/
[16:07] <sil2100> psivaa: thanks! :)
[16:07] <psivaa> sil2100: yw :). can i release the device?
[16:07] <psivaa> before forgetting :)
[16:08] <sil2100> psivaa: yes, thanks ;) But I don't guarantee I won't poke you or someone else in the nearest time again ;p Sorry about that!
[16:08] <psivaa> sil2100: ok :)
[16:24] <Mirv> rsalveti: yeah, most, some manual uploads building in another PPA but CI Train ones were rebuilt already
[16:27] <balloons> pmcgowan, davmor2 the fix for sudoku has been pushed to the store, popey will have a review and it'll land
[16:28] <pmcgowan> great
[16:29] <rsalveti> Mirv: great
[16:29] <rsalveti> pmcgowan: just concerned now with the 2 qmlscene crashes we have
[16:29] <davmor2> balloons: \o/ sabdfl will be happy to hear that :)
[16:31] <pmcgowan> rsalveti, I saw the bug for stackbrowser, is there another?
[16:32] <rsalveti> pmcgowan: for clock-app, which is more critical for me
[16:32] <rsalveti> pmcgowan: as that will trash your device
[16:32] <pmcgowan> rsalveti, is that a cpu lockup thing?
[16:32] <rsalveti> pmcgowan: it just gets killed when it gets most of the system memory
[16:32] <rsalveti> cpu and memory
[16:32] <pmcgowan> oh
[16:32] <rsalveti> and it's also probably a bug in our app lifecycle
[16:33] <pmcgowan> bug #?
[16:33] <rsalveti> as we shouldn't allow an app to trash the system like that
[16:33] <rsalveti> pmcgowan: bug 1292047
[16:33] <pmcgowan> I dont think we implemented any memory controls per se, just default OOM right
[16:33] <rsalveti> yeah
[16:34] <rsalveti> but don't know if the app has lower prio than system services
[16:34] <rsalveti> I saw NM was killed here
[16:34] <rsalveti> such as ssh
[16:34] <pmcgowan> thats odd
[16:34] <pmcgowan> how is it doing the timer
[16:39] <rsalveti> not sure yet
[16:39] <rsalveti> Mirv: just updated from landing 6 and can't start gallery-app
[16:41] <Mirv> rsalveti: it never worked since last Friday when it changed to be a click app, since it needs a rebuild. if you do apt-get install gallery-app you get a second, rebuilt gallery-app icon that works. elopio also tested that the AP:s pass.
[16:41] <rsalveti> Mirv: oh, great then
[16:41] <rsalveti> was scared for a second
[16:46] <rsalveti> pmcgowan: you just need to go to timer, and click at a preset
[16:46] <rsalveti> we first need to understand why we're getting nan:nan as a preset label
[16:46] <rsalveti> once you click that, it crashes hard
[16:46] <pmcgowan> that could be a javascript change
[16:47] <pmcgowan> oh weird
[16:48] <balloons> ping doanac`
[16:49] <rsalveti> pmcgowan: who knows clock-app enough to help us?
[16:49] <doanac`> balloons: hey
[16:49] <pmcgowan> rsalveti, maybe nik90 is around
[16:49] <balloons> doanac`, :-) So, just curious why http://s-jenkins.ubuntu-ci:8080/job/calculator-app-click/ builder seems to be failing.
[16:49] <nik90> rsalveti, pmcgowan: I am here ;)
[16:50] <balloons> doanac`, log says click-buddy can't be found
[16:50] <pmcgowan> nik90, see the bug report above ^^
[16:50] <pmcgowan> nik90, related to qt 5.2 testing
[16:50] <balloons> doanac`, seems the builder is using saucy, should be using trusyt methinks
[16:50] <nik90> pmcgowan: elopio already told me about the error
[16:50] <nik90> pmcgowan: How can I help?
[16:51] <doanac`> balloons: but click-buddy shouldn't have gone away
[16:51] <pmcgowan> nik90, could you try to reproduce it? or any suggestions how to debug
[16:51] <balloons> doanac`, mm.. I wonder if it didn't get converted to use click-buddy like the other builders
[16:51] <pmcgowan> nik90, I was assuming you wrote this app is that correct?
[16:51] <doanac`> balloons: i wonder if phablet-tools got installed: E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
[16:52] <nik90> pmcgowan: yes I wrote the code
[16:52] <doanac`> balloons: that's the problem we can't install phablet-tools in that job
[16:52] <nik90> pmcgowan: I don't have qt 5.2 installed yet since this is my primary machine for university
[16:52] <doanac`> let me see if i can see why that would happen
[16:52] <nik90> pmcgowan: what puzzles me is that the code around the timer list is quite similar to other parts of the app.
[16:52] <balloons> doanac`, kk
[16:56] <cyphermox> seb128: re: line 38, any of this should be covered by an FFe, given that there are "changes to match design"
[16:56] <cyphermox> it's unclear whether it's bugfix or what
[16:56] <pmcgowan> nik90, how is that model getting loaded, is it from a u1db doc?
[16:56] <cyphermox> heh, but then I guess there is the lp in the merge anyway
[16:57] <nik90> pmcgowan: yes it is basic list view which gets the data from u1db.documen.
[16:57] <pmcgowan> nik90, seems thats not working somehow
[16:58] <nik90> pmcgowan: Can someone test if commenting out the u1db document code resolves the crash? It is defined in the TimerPage.qml file right at the begining
[16:58] <nik90> kalikiana: ping
[16:58] <pmcgowan> nik90, yes we can try that
[16:58] <pmcgowan> rsalveti, ^^
[16:59] <nik90> rsalveti: after commenting the code, you will need to delete the locally saved u1db file in the clock folder
[16:59] <nik90> rsalveti: on the desktop, it is stored at .local/share/com.ubuntu.clock/
[16:59] <rsalveti> cool, let me try
[17:00] <pmcgowan> rsalveti, Mirv landing call
[17:01] <nik90> pmcgowan: here is my theory, when I save the time, it is saved as a integer in u1db. I have a feeling this is not supported by u1db which could be causing the issue. But I need to confirm with the u1db developers about this.
[17:02] <pmcgowan> kalikiana, ?^
[17:02] <Mirv> rsalveti: you're keeping us at suspense :)
[17:03] <rsalveti> let me join the meeting
[17:03] <rsalveti> if I remove the u1db part it'll indeed not crash
[17:05] <sil2100> There is a landing call? Or only a landing call for qt5.2?
[17:05] <popey> 5.2
[17:05] <sil2100> k
[17:06] <doanac`> balloons: i think the issue might be that we have an old version of phablet-tools for arm. it seems to be on 1.0+13.10.20131016.3-0ubuntu1 which doesn't have click buddy
[17:06] <balloons> doanac`, right.. I wonder if the saucy build has trailed behind, or is failing, etc
[17:07] <doanac`> balloons: no. its up-to-date on my x86 saucy laptop
[17:07] <robru> seb128, remember how I was complaining about my screens not blanking some months ago? well now the new lockscreen is really preventing my screens from blanking. last two days I woke up to find my screens on bright, and then after I unlocked them, they powered down, then powered back up. has nobody else experienced this? how can I troubleshoot this?
[17:07] <davmor2> popey: can you try the new update for g+ for me I get the unknown browser all the time now
[17:07] <ogra_> davmor2, seems that depends on the screen size
[17:08] <doanac`> balloons: here's the issue: https://launchpad.net/ubuntu/saucy/armhf/phablet-tools
[17:08] <ogra_> i get that on desktop, flo and manta
[17:08] <balloons> doanac`, well for x86 sure, but
[17:08] <davmor2> ogra_: this is no mako and was working
[17:08] <ogra_> works on mako
[17:08] <ogra_> hmm, i updated it today ... still works here
[17:08] <balloons> ouch, no new builds!
[17:08] <ogra_> (only the click package though)
[17:09] <cjwatson> /ubuntu/saucy/armhf/phablet-tools is specifically the primary archive, i.e. SRUs
[17:09] <cjwatson> if you're talking about some regular daily build or something then that isn't what you want
[17:09] <popey> davmor2: works on mako here
[17:09] <doanac`> balloons: oh - i see. i'm using the phablet-tools ppa on saucy
[17:09] <doanac`> its up-to-date
[17:10] <balloons> yes.. nothing has been pushed to saucy itself since release that sort of shows that
[17:11] <davmor2> popey, rsalveti: ^ might be the revert of qtwebkit or qt 5.2.1 then the last version worked fine
[17:15] <doanac`> balloons: let me chat with fginther about how we should fix this. shouldn't be too bad
[17:15] <balloons> doanac`, great thanks! I just need a new click for calc from trunk :-)
[17:17] <rsalveti> davmor2: hm, I just flashed and updated from landing 6 (all packages), and can open it successfully
[17:17] <rsalveti> we also rebuilt a few more things, like webbrowser-app
[17:18]  * sil2100 sighs
[17:18] <kalikiana> nik90: there's a qt bug that can garble numeric values which you could be hitting
[17:18] <kalikiana> more specifically in the way the javascript engine stores numbers
[17:19] <kalikiana> nik90: if that's the one, converting to and from string should solve it
[17:19] <kalikiana> I can have a look if you point me to the code
[17:25] <fginther> doanac`, balloons calculator just needs to converted to using cmak
[17:25] <fginther> e
[17:26] <balloons> fginther, you mean the builder or ? the app uses it
[17:26] <doanac`> fginther: isn't "click-buddy --dir ." going to fail though? that's not in the saucy phablet-tools
[17:26] <fginther> balloons, the builder (at least that's what I'm assuming)
[17:26] <popey> balloons: fginther calc uses cmake..
[17:27] <balloons> fginther, right that was my guesstimate.. ok, I agree :-)
[17:28] <fginther> doanac`, the solution is to use a trusty chroot
[17:29] <fginther> doanac`, I've been in the slow process of converting the build process for all the click apps, but it can't be done until the app is ready
[17:29] <popey> balloons: sudoku still has https://bugs.launchpad.net/sudoku-app/+bug/1285279 failing
[17:29] <popey> is that something we can quickly fixup?
[17:29] <pmcgowan> kalikiana, did you get a pointer to the clock code?
[17:30] <nik90> pmcgowan: just back from dinner.  I will help kalikiana
[17:30] <pmcgowan> nik90, great
[17:31] <doanac`> fginther: ack. you need me to try and do fix this?
[17:31] <nik90> kalikiana: http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/timer/TimerPage.qml#L45
[17:31] <balloons> popey, i've been re-running the landing jobs.. however, my quick prognosis i think might be wrong. The same tests seem to be failing (when it's not bit by launching issues)
[17:31] <balloons> so it appears additionally there might be an issue with the tests
[17:32] <fginther> doanac`, already done, it's just a copy and paste from one of the other jobs (it's setup to templated once all the projects have been updated)
[17:32] <popey> balloons: ☹
[17:32] <fginther> balloons, http://s-jenkins.ubuntu-ci:8080/job/calculator-app-click/112/ passed
[17:33] <balloons> fginther, brillant ty
[17:33] <balloons> popey, ok so i'll push calc
[17:34] <fginther> doanac`, it's a bit of a minefield right now as things are in flux and there hasn't been enough time to tie all the piece together properly
[17:34] <doanac`> fginther: i was hoping to not have to touch it :)
[17:35] <balloons> fginther, one sidebar since we're on it.. http://s-jenkins.ubuntu-ci:8080/job/weather-app-click-build/ is kind of cool. A generic builder for cmake enabled branches could be useful
[17:38] <didrocks> robru: around?
[17:38] <robru> didrocks, hi
[17:39] <didrocks> robru: hey, mind coming to https://plus.google.com/hangouts/_/canonical.com/qt-5-2-landing?
[17:39] <didrocks> cyphermox: you as well if possible? ^
[17:39] <robru> didrocks, ok, can't promise i have anything to say.
[17:39] <rsalveti> kalikiana: nik90: the database itself looks fine it seems
[17:40] <rsalveti> http://paste.ubuntu.com/7085921/
[17:40] <rsalveti> just removed the other items, let it just with one
[17:40] <kalikiana> that looks normal
[17:40] <rsalveti> maybe the query is breaking it?
[17:41] <kalikiana> I'm just going through the code, the number issue I was mentioning wouldn't apply to these small amounts
[17:41] <nik90> kalikiana: ok
[17:41] <kalikiana> no obviously wrong stuff there
[17:41] <fginther> balloons, that's actually part of the work in progress to build click packages while testing MPs
[17:41] <nik90> kalikiana: could something be wrongn with http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/timer/PresetList.qml#L48
[17:42] <nik90> kalikiana: that's the code which gets the time from the database and converts it into hours and minutes
[17:43] <sil2100> Damn
[17:44] <sil2100> Mirv: any decision on the qt5.2 landing?
[17:44] <rsalveti> nik90: yeah, want to get just the string to see if that would work at least
[17:44] <rsalveti> ignoring the time
[17:44] <kalikiana> nik90: there's no error check… not sure what would happen if timer is something other than a number
[17:45] <kalikiana> I don't know if eg. undefined % 60 could crash
[17:45] <nik90> kalikiana: well the time is something that the user cannot just enter in a textfield. It is inputted through the dialer. So we can guarantee it is within the limits <60 and is a number.
[17:47] <sil2100> Mirv, didrocks: mind if I join your call as a spectator?
[17:47] <didrocks> sil2100: sure
[17:47] <robru> sil2100, please do
[17:48] <kalikiana> nik90: yes but if there's a bug anywhere between changing/adding and that function you can still have undefined
[17:49] <kalikiana> I'd just play it safe rather than having faith in code
[17:50] <nik90> kalikiana: +1
[17:56] <pmcgowan> kalikiana, can we determine if this bug will affect any other users of the API
[17:56] <pmcgowan> or is it app specific? seems odd it changed behavior when qt changed
[17:56] <pmcgowan> although V* changed
[17:59] <kalikiana> pmcgowan: I'm still unsure where exactly the bug lies. it wouldn't be the first breaking change in javascript from 5.0 to 5.*
[17:59] <kalikiana> there were also changes in the Date type
[17:59] <kalikiana> but that's not used here I think
[17:59] <pmcgowan> kalikiana, yep, please let me know when you do understand then
[18:00] <nik90> kalikiana: but what about the timer names? Currently they seem missing according to the bug report. They are just normal strings.
[18:00] <pmcgowan> seems the entire doc did not load correctly
[18:01] <nik90> yes
[18:01] <rsalveti> nik90: yeah, seems model is busted at ./timer/PresetList.qml
[18:01] <rsalveti> the crash seems to be happening here: analogTimer.ssToTime(model.contents.duration)
[18:01] <kalikiana> this one would plausibly  happen if contents is just empty https://launchpadlibrarian.net/169369228/screenshot-20140313-090202.png
[18:01] <kalikiana> just judging from the screenie
[18:01] <nik90> rsalveti: so if you change that to model.contents.duration is everything fine?
[18:02] <rsalveti> if I put a fixed time instead of using model.contents.duration it doesn't crash, but still can't get the string
[18:02] <kalikiana> nik90: if that's the one you mean by missing names
[18:02] <rsalveti> and can't get the value
[18:02] <nik90> kalikiana: yes that's what I meant by missing names
[18:02] <rsalveti> yeah, that's why I believe model is busted
[18:02] <rsalveti> even the string is not there
[18:02] <kalikiana> rsalveti: try throwing JSON.stringify(contents) in there
[18:02] <rsalveti> text: model.contents.name returns me null
[18:03] <nik90> rsalveti: try text: JSON.stringify(contents) as kalikiana said
[18:03] <rsalveti> sure
[18:03] <nik90> that should output the entire model element
[18:03] <rsalveti> what will that do?
[18:03] <nik90> ^^
[18:03]  * rsalveti is kind of new to qml
[18:04] <kalikiana> it should give you the document the same why it was typed as json in qml
[18:04] <kalikiana> with any changes
[18:04] <kalikiana> *way
[18:04] <kalikiana> the default output of qml errors isn't smart enough to do it out of the box
[18:05] <pete-woods> Mirv: hi, don't know if you need this from me, but I see the qt5.2 status says packaging changes need manual verification for some of my packages
[18:05] <pete-woods> but I looked at the changes and they are indeed what I expected
[18:06] <rsalveti> text: JSON.stringify(model.contents)
[18:06] <rsalveti> just gave me: {"time":{"duration:911,"n...
[18:07] <rsalveti> duration seems fine
[18:07] <kalikiana> and name is in there?
[18:08] <rsalveti> in there, but can't get the entire dump
[18:08] <rsalveti> as it tries to display at the preset name
[18:08] <rsalveti> is there a way to dump this to a file or similar?
[18:08] <Mirv> pete-woods: hi! we're in hangout pushing buttons. thanks for rechecking, it's happening now and we get to collect the pieces then :)
[18:09] <Mirv> pete-woods: thanks again for the fixes you did
[18:09] <pete-woods> Mirv: no problem, thankyou for all the effort getting this thing landed!
[18:09] <kalikiana> rsalveti: you can do sth like: var docs=db.listDocs();for(var doc in docs)console.log(JSON.stringify(db.getDoc))
[18:10] <rsalveti> great
[18:10] <kalikiana> er pass the doc to getDoc of course, sorry
[18:10] <rsalveti> {"timer":{"duration":180,"name":"Soft-boiled egg"}}
[18:10] <nik90> rsalveti, kalikiana: If it seems that the model.contents seems intact, then the crash must be occuring due to analogTimer.ssToTime(model.contents.duration) and getstringTimer(model.contents.duration)
[18:11] <rsalveti> text: JSON.stringify(model.contents)
[18:11] <nik90> rsalveti: can you replace getstringTimer(model.contents.duration) with just model.contents.duration
[18:11] <rsalveti> right, for some reason it's not extracting the data correctly from the model
[18:11] <nik90> rsalveti: and comment out  analogTimer.ssToTime(model.contents.duration)
[18:11] <nik90> rsalveti: this should stop the crash
[18:11] <nik90> rsalveti: I can figure out how to improve those 2 functions
[18:12] <nik90> if I get a confirmation that stops the crash
[18:12] <rsalveti> but why text: model.contents.name returns nothing?
[18:13] <nik90> rsalveti: it could be that by calling  getstringTimer(model.contents.duration), it causes the model to be corrupted in the listview? Not sure
[18:13] <rsalveti> hm, right
[18:13] <rsalveti> but in my current code I hardcoded that with 10
[18:14] <rsalveti> so not calling getstringTimer anyway
[18:14] <didrocks> rsalveti: 90/117
[18:14] <didrocks> FYI :)
[18:15] <kalikiana> rsalveti: should it be mode.contents.timer.name?
[18:15] <kalikiana> *model.contents.timer.name
[18:16] <nik90> kalikiana: that doesn't work on qt 5.0.2
[18:16] <nik90> kalikiana: the index is defined as expression: ["timer.name", "timer.duration"]
[18:16] <rsalveti> right, why would that change?
[18:16] <nik90> kalikiana: query is query: ["*", "*"]
[18:16] <popey> didrocks: what's the deadline for getting packages in the default image before 14.04?
[18:17] <nik90> kalikiana: so the index already gathers only the timer documents
[18:17] <didrocks> popey: no particular deadline, if the FFe is accepted
[18:17] <didrocks> and you find some available archive admin :)
[18:17] <rsalveti> kalikiana: nik90: but yeah, works after adding custom.timer instead of just using as custom
[18:17] <kalikiana> nik90: the qt shouldn't matter for that but rsalveti said above that he got {"timer":{"duration":180,"name":"Soft-boiled egg"}} in contents
[18:17] <popey> didrocks: what if it's a click?
[18:17] <rsalveti> thought I tried that, maybe got a typo
[18:17] <popey> didrocks: e.g. reminders-app
[18:18] <nik90> rsalveti: wait, so what worked?
[18:18] <rsalveti> nik90: yup
[18:18] <rsalveti> text: model.contents.timer.name
[18:18] <rsalveti> text: getstringTimer(model.contents.timer.duration);
[18:18] <didrocks> rsalveti: failed on the 117th :p
[18:19] <rsalveti> didrocks: oh
[18:19] <rsalveti> overflow? maybe started counting on 0 :P
[18:19] <nik90> kalikiana: did you read what rsalveti said...it worked with model.contents.timer.name
[18:20] <nik90> rsalveti, kalikiana: With Qt 5.0, http://imgur.com/SKOmuix
[18:20] <didrocks> rsalveti: no no, someone sneaked in a conflict :p
[18:20] <rsalveti> nik90: that's weird
[18:20] <nik90> rsalveti, kalikiana: That's the output of JSON.stringify(model.contents)
[18:20] <nik90> kalikiana: so that's what changed!
[18:20] <rsalveti> pmcgowan: so u1db is fine
[18:20]  * pmcgowan dances
[18:21] <nik90> rsalveti: well why do we need that change in the first place when moving from 5.0 to 5.2?
[18:21] <nik90> rsalveti: I mean when I try your method, it fails on my computer
[18:21] <rsalveti> that's what I'm trying to understand
[18:21] <pmcgowan> rsalveti, what happened? the syntax for the model elemtns changed?
[18:22] <rsalveti> pmcgowan: yes
[18:22] <pmcgowan> they probably fixed a bug
[18:22] <rsalveti> before we could use model.contents.duration
[18:22] <rsalveti> now we need to call model.contents.timer.duration
[18:22] <rsalveti> as timer is indeed an entry in the db
[18:22] <rsalveti> http://paste.ubuntu.com/7085921/
[18:22] <pmcgowan> right seems to make sense
[18:22] <rsalveti> maybe we'd need to query timer.* or similar?
[18:23] <nik90> rsalveti: well that's done in the index expression: ["timer.name", "timer.duration"]
[18:23] <nik90> kalikiana: what do you think?
[18:23] <nik90> rsalveti: but does this solve all the crash issues?
[18:23] <rsalveti> with qt5.2, yes
[18:23] <nik90> rsalveti: also did you uncomment all the u1db document code I asked before in the TimerPage.qml file?
[18:23] <rsalveti> problem is that the number was null in there
[18:24] <rsalveti> so analogTimer.ssToTime caused the crash
[18:24] <rsalveti> once I moved it to use model.contents.timer.duration, it worked
[18:24] <nik90> rsalveti: but now it no longer causes the crash with the correct input to it
[18:25] <rsalveti> nops
[18:25] <rsalveti> all good
[18:25] <nik90> rsalveti: I will do better error detection once qt 5.2 lands in trusty since it is hard to fix a function when I cannot test if I fixed it or not :)
[18:25] <nik90> rsalveti: awesome...
[18:25]  * nik90 is relieved
[18:25] <rsalveti> but still, what should we do?
[18:25] <rsalveti> propose this fix once we land qt 5.2?
[18:25] <rsalveti> or try to find a way to be compatible with both cases
[18:25] <pmcgowan> rsalveti, does the change not work on 5.0?
[18:26] <pmcgowan> thats nasty
[18:26] <rsalveti> yeah, breaks 5.0
[18:26] <nik90> pmcgowan, rsalveti: I can get a MP ready so that it is good to go the moment you give the go ahead
[18:26] <kalikiana> nik90: rsalveti I'm doubtful this is 5.0/.2 I rather suspect the u1db-qt version is higher and everyone has a different one installed here
[18:27] <didrocks> rsalveti: I'm doing so bad things to cheat and win time because of this failure, you have no idea…
[18:27]  * didrocks should get drunk
[18:27] <pmcgowan> didrocks, no not yet!
[18:27] <kalikiana> there were some bug fixes going on as nik90 is aware and we didn't know when they would land
[18:27] <rsalveti> didrocks: lol
[18:27] <nik90> kalikiana: I think so..I am using the core apps daily PPA which has a more recent u1db version while the phone could be lagging behind on that
[18:27] <rsalveti> get drunk, always good
[18:28] <pmcgowan> kalikiana, fixes at what level
[18:28] <nik90> rsalveti: can you find out the u1db-qt version
[18:28] <nik90> rsalveti: apt-cache policy qtdeclarative5-u1db1.0
[18:28] <didrocks> pmcgowan: ahah, my hand is away from a beer for now :p
[18:28] <rsalveti> 0.1.5+14.04.20140306-0ubuntu1
[18:28] <nik90> 0.1.5+13.10.20130916bzr112saucy0
[18:28] <kalikiana> pmcgowan: u1db-qt trunk has bug fixes, but with all the withheld images and ci etc. I have no idea when what lands
[18:28] <nik90> that's mine
[18:28] <rsalveti> yeah, they are quite different it seems
[18:29] <pmcgowan> man thats old
[18:29] <kalikiana> applause for our rock solid ci :-]
[18:29] <pmcgowan> from sept? or is the tag wrong
[18:29] <rsalveti> grab the source
[18:29] <rsalveti> check changelog
[18:29] <rsalveti> yeah
[18:29] <rsalveti> september
[18:30] <rsalveti> last upload was on saucy
[18:30] <rsalveti> jezz
[18:30] <rsalveti> can someone try to replicate this bug with qt 5.0 + qtdeclarative5-u1db1.0 0.1.5+14.04.20140306-0ubuntu1?
[18:31] <rsalveti> let me reflash
[18:31] <pmcgowan> where can I get the new deb
[18:32] <pmcgowan> kalikiana, how can that not have landed with all the other  uitk landings
[18:32] <rsalveti> I guess you'd need to rebuild the deb anyway
[18:33] <didrocks> rsalveti: oh, I hate you for qtwebkit as well, nobody rewatched ppa
[18:33] <pmcgowan> whats in the sdk ppa
[18:33]  * didrocks adds more faking
[18:33] <didrocks> I'll need a second beer :p
[18:33] <rsalveti> didrocks: haha, I can pay the second one, sorry ;-)
[18:33] <pmcgowan> you will need a 6 pack before you are done
[18:33] <didrocks> ;)
[18:33] <didrocks> pmcgowan: possible!
[18:34]  * didrocks adds more hacks now so that the 3rd publish is fast
[18:34] <didrocks> rsalveti: you are annoying, stop fixing bugs and rocking!
[18:34] <didrocks> :)
[18:34] <kalikiana> pmcgowan: it's a separate package, the uitk is a different branch entirely lp:u1db-qt versus lp:ubuntu-ui-toolkit
[18:34] <pmcgowan> kalikiana, ok, then we needed to request a landing it seems
[18:34] <popey> DEBUG   18:33:56: rnrclient.vala:113: Getting reviews from URL: https://reviews.ubuntu.com/reviews/api/1.0/reviews/filter/en_US/(null)/click/1.0.5/(null)/
[18:35] <popey> well that looks broken
[18:35] <kalikiana> pmcgowan: nothing has formally changed in the process for ages but I guess somebody might have pulled a cable that nobody noticed
[18:35] <pmcgowan> kalikiana, did not follow
[18:35] <rsalveti> yeah, things are still getting merged in trunk but not released in the distro
[18:36] <rsalveti> so we basically didn't add it as part of our CI
[18:36] <pmcgowan> oh
[18:36] <kalikiana> pmcgowan: for u1db-qt there was no change, train or anything, it still uses (or should be using) the same merge→publish cycle
[18:36] <pmcgowan> kalikiana, how can that be?
[18:36] <pmcgowan> everything is through ci train
[18:36] <pmcgowan> except what isnt I guess
[18:36] <pmcgowan> moot now
[18:36] <kalikiana> there's a number of packages in that group afair, not just u1db
[18:37] <pmcgowan> not ones we are upstream for I would think
[18:37] <pmcgowan> or that get on the phone I guess
[18:37] <pmcgowan> kalikiana, nik90, popey do you know which other apps use u1db?
[18:37] <nik90> pmcgowan: I believe file-manager is using it
[18:37] <nik90> pmcgowan: others are using LocalStorage afaik
[18:37] <pmcgowan> ok
[18:37] <kalikiana> then there's the recipe ape, I forget the name
[18:38] <kalikiana> saucybacon
[18:38] <kalikiana> *app
[18:38] <pmcgowan> recipe ape would e a nice app name
[18:38] <nik90> kalikiana: 3rd party apps like saucybacon, Flashback, UbuntuTasks also use it
[18:38] <nik90> and finally Geldliste also uses it
[18:39] <popey> pmcgowan: http://paste.ubuntu.com/7086260/
[18:40] <popey> every occurrance of U1db on my phone
[18:40] <nik90> popey: what's the magic command for that
[18:40] <kalikiana> didrocks: would you be able to check what the current landing process is for u1db-qt? if it changed/ disabled unbeknownst to me or something
[18:40] <popey> http://paste.ubuntu.com/7086263/ less verbose
[18:40] <pmcgowan> wow
[18:40] <popey>  adb shell "grep -R 'import U1db' /opt/click.ubuntu.com/*/current/*.qml" | pastebinit
[18:40] <pmcgowan> stackbrowser is on there too btw
[18:40] <popey> so may not be 100% accurate
[18:41] <nik90> pmcgowan: was that also crashing?
[18:41] <pmcgowan> kalikiana, so do we need to check each of those apps usage of the api
[18:41] <didrocks> kalikiana: it's in CI Train
[18:41] <pmcgowan> nik90, yes it is
[18:42] <kalikiana> didrocks: ha. good that I asked then :-D so I guess I should start requesting silos
[18:42] <seb128> cyphermox, UIF is tonight, that's not a FFE, just tweaks
[18:42] <rsalveti> pmcgowan: kalikiana: can we then not land u1db-qt now if that is indeed the one causing the issue?
[18:42] <didrocks> kalikiana: it's in the Qt5 silos for now
[18:42] <didrocks> kalikiana: but you can just add a branch with the fix
[18:42] <kalikiana> didrocks: hmm what does that mean?
[18:42] <didrocks> and ask robru to reconfigure it
[18:42] <cyphermox> seb128: got you your silo already..
[18:42] <didrocks> kalikiana: just do a MP against your trunk :)
[18:43] <seb128> cyphermox, thanks, I'm just back and catching up with backlog
[18:43] <cyphermox> np
[18:43] <cyphermox> gotta look at webbrowser app and whether it's really closing bugs now
[18:44] <pmcgowan> rsalveti, seems we should verify it is the u1db-qt difference, but seems it must be
[18:44] <rsalveti> I'm flashing latest and will check that with qt 5.0
[18:45] <robru> kalikiana, yeah, just propose a merge against your trunk with a fix for whatever issue you see, then give me the branch. I can walk you through the process
[18:45] <pmcgowan> rsalveti, is there a 5.0 based deb of u1db-qt in some ppa?
[18:46] <rsalveti> not that I know
[18:48] <Mirv> a lot happening at https://lists.ubuntu.com/archives/trusty-changes/2014-March/thread.html
[18:48] <pmcgowan> wow
[18:48] <kalikiana> hmm so what I'm still wondering is, at which revision did the current trunk stop, and where did it start waiting for the silo
[18:49] <pmcgowan> well the last package is from sept
[18:49] <kalikiana> that is the thing, that is long before train
[18:49] <ogra_> Mirv, yeah, looks like some crazy person updated all of Qt to 5.2 :)
[18:50] <robru> kalikiana, yeah, just look at the last release commit. both citrain and the old daily_release will make a trunk commit to indicate they did a release.
[18:50] <cjwatson> Mirv: ooh, you pulled the trigger?
[18:51] <kalikiana> robru: okay so then there definitely was no release from the train
[18:51] <robru> kalikiana, yep
[18:51] <didrocks> cjwatson: we did, but blocked on proposed
[18:51] <didrocks> we miss 7 of them, only 110 on 117
[18:51] <robru> kalikiana, well there's about to be because we're doing a qt5.2 rebuild thing right now. but yeah, if you need to fix something, just give me the MP and I can include it
[18:52] <cjwatson> didrocks: just waiting for publication, or is there anything I can help with?
[18:52] <cjwatson> (although this is almost the worst time for me, I have to go shortly)
[18:53] <didrocks> cjwatson: no worry, I have no error on my side though
[18:54] <cjwatson> it's certainly still publishing, anyway
[18:54] <didrocks> 2 were NEW packages
[18:55] <kalikiana> robru: rsalveti: nik90: so if I see it correctly I suspect rsalveti has an image with the latest trunk changes now which includes bug fixes but changes the model.contents in this case and thus indirectly causes the crash; so 5.2 being here is incidental
[18:55] <didrocks> so 5 are missing
[18:55] <rsalveti> kalikiana: that's what I'm trying to confirm
[18:55] <cjwatson> it triggered a bunch of builds, but I think that's just stuff that will dep-wait or fail, trying again
[18:55] <rsalveti> building latest u1db-qt on top of qt 5.0 to see
[18:55] <didrocks> cjwatson: yeah, I'm looking at -changes though
[18:55] <didrocks> this is where the 5 are missing
[18:56] <didrocks> (trying to locate those)
[18:56] <robru> kalikiana, sorry i don't know any details about your project. all I know is that your trunk is about to get released, so if there's something wrong in your trunk, please make an MP that fixes it
[18:56] <cjwatson> didrocks: do you have package names?
[18:56] <robru> kalikiana, but don't commit to trunk, specifically please give us an MP
[18:56] <cjwatson> I can check the copy logs
[18:56] <didrocks> cjwatson: I'm taking the list one by one
[18:57] <rsalveti> so qt 5.2 is happening
[18:57] <ogra_> already gone
[18:57] <ogra_> :)
[18:58] <ChickenCutlass> rsalveti: ship it
[18:58] <didrocks> cjwatson: Mirv built http://pastebin.ubuntu.com/7086347/
[18:58] <didrocks> those are the 5 missing
[18:58] <cjwatson> [2014-03-13 18:48:58,274: INFO/PoolWorker-3] Job:
[18:58] <cjwatson> <PlainPackageCopyJob to copy package qtcreator-plugin-ubuntu from ubuntu/landing-006, RELEASE pocket, in ubuntu trusty to ubuntu/primary, PROPOSED pocket, in ubuntu trusty, including binaries>
[18:58] <cjwatson> raised CannotCopy:
[18:58] <nik90> kalikiana: ok
[18:58] <cjwatson> qtcreator-plugin-ubuntu 3.0.1-0ubuntu2 in trusty (Cannot copy DDEBs to a primary archive)
[18:59] <didrocks> hum
[18:59] <didrocks> why do we have ddebs
[18:59] <cjwatson> those must have been initially built in a misconfigured PPA
[18:59] <didrocks> weird, the ppa didn't change though
[18:59] <cjwatson> I bet they were copied-with-binaries from there
[18:59] <didrocks> yeah
[18:59] <didrocks> oh
[18:59] <rsalveti> yeah
[18:59] <nik90> pmcgowan, rsalveti, kalikiana: So what is the immediate plan? Are we pushing an update to u1db-qt with the Qt 5.2 transition (in which case I need to update clock app as well) ? Or are we postponing the u1db landing?
[18:59] <didrocks> so I guess it's the same for the 5
[18:59] <cjwatson> yeah, you can't copy-with-binaries into a landing PPA from something that isn't specially configured for builds aimed at the distro
[19:00] <didrocks> yeah, I didn't know it before now…
[19:00] <cjwatson> I suggest just rebuilding those five and recopying
[19:00] <rsalveti> nik90: let me just confirm it first
[19:00] <nik90> rsalveti: ok
[19:00] <Mirv> cjwatson: didrocks: doh, that's correct
[19:00] <rsalveti> as this will probably affect a bunch of other packages as well if indeed caused by u1db
[19:01] <cjwatson> yeah, all the same cause
[19:01] <rsalveti> didrocks: Mirv: just trigger a rebuild and I can copy them later today
[19:01] <cjwatson> pokerth 1.1.1-2ubuntu1 in trusty (Cannot copy DDEBs to a primary archive)
[19:01] <cjwatson> qtwebkit-opensource-src 5.2.1+dfsg-0ubuntu2 in trusty (Cannot copy DDEBs to a primary archive)
[19:01] <cjwatson> qtcreator 3.0.1-0ubuntu2 in trusty (Cannot copy DDEBs to a primary archive)
[19:01] <cjwatson> peg-e 1.1.2-1ubuntu1 in trusty (Cannot copy DDEBs to a primary archive)
[19:01] <Mirv> rsalveti: didrocks: doing
[19:01] <cjwatson> qtcreator-plugin-ubuntu 3.0.1-0ubuntu2 in trusty (Cannot copy DDEBs to a primary archive)
[19:01] <didrocks> rsalveti: yeah, we are doing that. However, I need to do a quick fix in cu2d or you will have another issue doing the publish on publish (with source packages)
[19:01] <didrocks> cjwatson: ok, all have the same source, thanks for looking
[19:01] <kalikiana> robru: nik90: it may be related to http://bazaar.launchpad.net/~uonedb-qt/u1db-qt/trunk/revision/113 if that's the case I can propose a revert for it so we get the other fixes at least
[19:02] <rsalveti> ok
[19:02] <rsalveti> yeah, looks like
[19:02] <cjwatson> off for a while, please sms me if you have other obscure publication failures or whatever that need investigation
[19:02] <rsalveti> sure, thanks
[19:03] <kalikiana> rsalveti: "looks like" as in: should I make a revert branch if that would solve it for now?
[19:04] <rsalveti> kalikiana: building it as we speak, let me just confirm the issue
[19:04] <kalikiana> okay
[19:04] <rsalveti> build-dep is huge
[19:07] <davmor2> popey, rsalveti: so fresh install of 236 fresh install of g+, first run is triggered correctly I get to login, I get the install the app page or click here to goto the website, and the stream opens correctly.  I open it a second time and now I get unsupported browser
[19:07] <didrocks> rsalveti: ok, you should be able to republish once ready
[19:07] <didrocks> I hot fixed the production
[19:07]  * didrocks crosses fingers
[19:07] <kalikiana> aaaarrrrgggg one of the days I'll glue the yubikey to my finger, why does it have to ask so often
[19:07] <didrocks> rsalveti: anyway, keep us posted, not a lot we can do now until the packages are rebuilt
[19:08] <rsalveti> didrocks: yeah, thanks a lot
[19:08] <didrocks> Mirv finishes his reupload
[19:08] <didrocks> and we rerun build with "watch ppa only"
[19:08] <rsalveti> lovely
[19:09] <popey> davmor2: what device?
[19:09] <rsalveti> davmor2: will try to reproduce
[19:09] <davmor2> popey: mako
[19:09] <rsalveti> but that is with qt 5.0, right?
[19:09] <rsalveti> you said fresh 236
[19:10] <davmor2> rsalveti: yeap completely fresh standard 236
[19:12] <rsalveti> kalikiana: pmcgowan: yeah, got nan:nan with latest u1db and qt 5.0
[19:12] <rsalveti> so not related with qt 5.2
[19:12] <pmcgowan> davmor2, I dont see any relevant package changes for that
[19:12] <pmcgowan> rsalveti, great
[19:13] <pmcgowan> kalikiana, so you think 113 did this? or 112?
[19:13] <davmor2> rsalveti: yes not qt5.2 related it's broken on 5.0 too :)
[19:14] <kalikiana> rsalveti: pmcgowan: my guess would be 113, I'll prepare an MR for testing in a moment
[19:14] <pmcgowan> at least thats a one liner
[19:14] <davmor2> pmcgowan: the google+ app was updated today to use webcontainer by the look of it
[19:14] <pmcgowan> davmor2, oh, what was it using?
[19:15] <pmcgowan> and whose app is it?
[19:15] <davmor2> pmcgowan: xnox's iirc and it was using a bastardise au on qtwebkit direct iirc
[19:15] <rsalveti> kalikiana: yeah, reverted 113 and it's now working again
[19:15] <davmor2> pmcgowan: ua even
[19:16] <pmcgowan> davmor2, he may need better config, I can ask alex to check it
[19:17] <sil2100> Damn, this is stressing
[19:17] <davmor2> sil2100: what in particular?
[19:18] <sil2100> davmor2: landing qt 5.2 in -proposed, watching those publish and build jobs is as exciting as the olympics!
[19:18] <pmcgowan> heh
[19:18] <ogra_> who wins ?
[19:18] <rsalveti> sil2100: lol
[19:19] <davmor2> ogra_: passes hopefully
[19:19] <nik90> kalikiana: once the qt 5.2 dust settles, we can propose rev 113 in u1db along with necessary fixes in other apps as well
[19:19] <Mirv> rsalveti: so reuploaded qtcreator qtcreator-plugin-ubuntu pokerth peg-e qtwebkit-opensource-src which were the ones that were built in another PPA. now building.
[19:19] <davmor2> ogra_: after all this we don't wont the failed to builds to win
[19:19] <rsalveti> pmcgowan: so, only remaining issue is bug 1291602
[19:20] <rsalveti> Mirv: great, thanks!
[19:20] <ogra_> davmor2, dont put the bar so high ... else tears are involved in the end
[19:20] <ogra_> :)
[19:20] <pmcgowan> rsalveti, did you see that stackbrowser uses u1db? any chance it can be related?
[19:20] <rsalveti> pmcgowan: hm
[19:20] <rsalveti> will check again later today
[19:21] <rsalveti> once we get stuff in proposed, and a new u1db as well
[19:21] <kalikiana> nik90: I'm pondering a slightly different change for that; if it's that disruptive; I'll elaborate in a bit
[19:21] <kalikiana> first I'm changing the unit test for the revert
[19:23] <didrocks> rsalveti: pmcgowan: ok, all done on my side, good luck guys!
[19:23] <rsalveti> didrocks: thanks!
[19:23] <sil2100> robru: let's be in touch
[19:23] <pmcgowan> oh no didrocks is leaving :0
[19:23] <sil2100> robru: for now I'll keep on monitoring and re-building
[19:23] <Mirv> rsalveti: pmcgowan: ok, all done on my side, good luck guys!
[19:23] <Mirv> :)
[19:23] <didrocks> pmcgowan: yeah, but I checked everything is cleaned! ;)
[19:23] <sil2100> Mirv, didrocks: good work, goodnight!
[19:23] <pmcgowan> thanks guys
[19:23] <didrocks> cjwatson: should be good now, we can rerun things and republish partially ;)
[19:23] <didrocks> see you tomorrow!
[19:24] <didrocks> (with good news please ;))
[19:24] <nik90> kalikiana: ok..I should have caught this issue earlier if only I tested the latest u1db with clock-app. But that said, atleast a lesson learnt about versioning and release
[19:24] <sil2100> We'll *try* making sure all the rest goes through ;p
[19:24] <kalikiana> peopel are leaving, now to see who stays when the hard liquor gets opened
[19:24]  * pmcgowan crosses fingers, legs, everything
[19:24] <didrocks> heh
[19:24] <nik90> lol
[19:24] <rsalveti> nik90: but that u1db change probably broke some other apps as well
[19:24] <rsalveti> so if we indeed want to push that forward, we need a better solution to avoid breaking other clients
[19:25] <pmcgowan> yeah needs to work both ways
[19:25] <robru> sil2100, ok sorry about that, i'm totally starving. just ping me when you need something.
[19:25] <nik90> rsalveti: agreed. but sometimes the new fixes coming into u1db might require possible changes in the clients. The rev 113 was an important fix actually.
[19:26] <nik90> rsalveti: So I will be looking forward to working with kalikiana on that after qt 5.2
[19:26] <rsalveti> sure, just need to be better coordinated I guess
[19:27] <Mirv> rsalveti: sil2100: one more thing that can wait until my morning but in case it becomes a topic: three remaining manual rebuilds of qtwebkit reverse dependencies at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper/+packages - pyqt5 , qtquick1, qtwebkit-examples. there are no dependency errors, but rebuilds nice to have anyway since we changed qtwebkit and pyqt5 needed a patch to build
[19:27] <Mirv> like said, those can wait, but you can also dget them and dput to landing-006 if you want (as we just found out, binary copy will no tdo)
[19:27] <rsalveti> right
[19:31] <popey> pmcgowan: fyi https://bugs.launchpad.net/sudoku-app/+bug/1285279 is currently blocking sudoku
[19:32] <popey> balloons: bounced calc back
[19:32] <pmcgowan> popey, but why failing now? is there a new test?
[19:33] <popey> pmcgowan: look at the date on the bug. it was already failing
[19:33] <popey> not new.
[19:33] <pmcgowan> so why is it blocking anything
[19:33] <popey> because it fails so i dont put it in the store
[19:33] <pmcgowan> but the app in the store is broken, seems like madness
[19:34] <popey> right, so broken and broken differently
[19:34] <kalikiana> nik90: rsalveti: https://code.launchpad.net/~kalikiana/u1db-qt/revertResultFields/+merge/210890
[19:35] <rsalveti> great, let me test that
[19:36] <pmcgowan> popey, can you try the one liner balloons suggested in the test?
[19:36] <popey> i think balloons re-thought that
[19:37]  * balloons pops in
[19:37] <balloons> so we talking calc or sudoku?
[19:37] <popey> sudoku, calc is just version issue, easy for you to fix ㋛
[19:38] <balloons> i hate the interface.. since I can't back it out, i've screwed myself
[19:39] <balloons> ok so soduku has failures.. i remember the bug
[19:39] <popey> only one failure
[19:43] <balloons> well, i suppose i can give a few mins to looking at it
[19:43] <barry> fginther: i think you should replace xnox's gallery_app branch with mine
[19:43] <barry> instead of https://code.launchpad.net/~xnox/gallery-app/fix-sample-dir/+merge/210517
[19:43] <barry> use
[19:43] <barry> https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877
[19:43] <sil2100> Mirv: ACK
[19:43] <barry> (the latter passes ci)
[19:47] <fginther> barry, seeing as xnox has approved your branch and rejected his original, I say that's effectively been replaced
[19:47] <barry> fginther: sounds good!
[19:55] <rsalveti> sil2100: can you add https://code.launchpad.net/~kalikiana/u1db-qt/revertResultFields/+merge/210890 to the landing 6? (qt 5.2)
[19:55] <popey> balloons: I'll hang around for updates.
[19:56] <rsalveti> pmcgowan: kalikiana: tested the mr with qt 5.0 and qt 5.2, works fine
[19:56] <balloons> popey, mp is trying to land
[19:56] <balloons> popey, for calc tho, can you somehow delete or remove the pending upload?
[19:56] <balloons> it's an ardous and annoying process involving committing a change otherwise
[19:56] <popey> nope
[19:56] <sil2100> rsalveti: uuh, hm, I'll add it in a moment
[19:57] <rsalveti> sil2100: sure
[19:58] <pmcgowan> rsalveti, thanks, now you are a qml guru too
[19:58] <rsalveti> pmcgowan: lol
[19:58] <sil2100> robru: did Didier mention to set anything else besides the explicit list of packages to build?
[19:59] <robru> sil2100, .... no
[19:59] <rsalveti> sil2100: they triggered a rebuild for a few packages http://pastebin.ubuntu.com/7086347/
[19:59] <rsalveti> and then he told me to do a build with watch-only
[19:59] <rsalveti> once the builds are done
[19:59] <rsalveti> that was all :-)
[20:01] <sil2100> rsalveti: I know I know, it's just that we published most of the stuff already, so I'm just making double sure about everything
[20:01] <sil2100> rsalveti: right now the build job is running
[20:01] <sil2100> rsalveti: so I need to wait for that to finish
[20:01] <sil2100> rsalveti: then I'll re-trigger
[20:02] <rsalveti> sil2100: great, thanks
[20:02] <rsalveti> pmcgowan: so we should be good now
[20:02] <rsalveti> pmcgowan: did we have any missing fix for notes-app as well?
[20:03] <pmcgowan> rsalveti, bfiller or elopio may know
[20:03] <pmcgowan> I kept hearing of a workaround
[20:03] <bfiller> rsalveti: I'm looking at it now
[20:03] <popey> balloons: maybe bueno can?
[20:04] <pmcgowan> rsalveti, although I think we agreed to ignore it, I still asked bfiller if he could look
[20:04] <bfiller> pmcgowan: yup, we should skip the test for now until we figure it out
[20:04] <pmcgowan> rsalveti, and need to land sudoku ;)
[20:04] <rsalveti> right
[20:04] <rsalveti> that's high prio
[20:06] <davmor2> rsalveti: google + and sudoku are critical
[20:06] <kenvandine> Mirv, i see your rebuild of qml-box2d was rejected because of the version
[20:06] <davmor2> rsalveti: did you not see sabdfl's keynote last night ;)
[20:06] <kenvandine> Mirv, i actually have a new upstream snapshot prepared to upload, mind if i just upload that?
[20:08] <sergiusens> popey, balloons did you screw up the versions?
[20:08] <balloons> sergiusens, yea, left off a zero.. which makes it hard to upload now
[20:08] <sergiusens> popey, balloons if so, bump it in the manifest (versions are obsolete these days anyways)
[20:08] <balloons> i don't get why i can't back out an upload
[20:09] <rsalveti> davmor2: well, I didn't help breaking google + at least
[20:09] <balloons> sergiusens, yes, but i have to commit the manifest then, etc
[20:09] <balloons> it's just annoyingly silly
[20:09] <sergiusens> balloons, just like you can't back out a deb, to avoid replay attacks
[20:09] <davmor2> rsalveti: :)
[20:10] <sergiusens> balloons, popey the proper solution is for the version to be read from the manifest and not have you type it in yourself; I've been told that was already ready
[20:10] <rsalveti> kenvandine: it seems it wasn't reject
[20:10] <rsalveti> *rejected
[20:10] <rsalveti> kenvandine: https://launchpad.net/ubuntu/+source/qml-box2d
[20:10] <balloons> sergiusens, I agree with that.. there's some leftovers from debian packaging in the upload process tho
[20:10] <balloons> it still is lint checked
[20:11] <kenvandine> rsalveti, it was rejected in the promotion
[20:11] <kenvandine> still in proposed
[20:11] <kenvandine> qtdeclarative5-box2d1.0_0.1~git20131115_arm64.deb: Version older than that in the archive. 0.1~git20131115 <= 0.1~git20131115ubuntu1
[20:11] <rsalveti> oh, but every package will be reject in promotion
[20:11] <rsalveti> hm, ok
[20:11] <kenvandine> the version number is wrong
[20:11] <rsalveti> might be a wrong error though
[20:12] <kenvandine> but i have a new snapshot i had wanted to upload today anyway
[20:12] <kenvandine> and we have nothing in the image depending on it
[20:12] <rsalveti> I know did blocked the promotion for all that packages
[20:12] <kenvandine> so that'll get built
[20:12] <rsalveti> kenvandine: ok
[20:12] <kenvandine> against the right qt
[20:12] <kenvandine> cool
[20:12]  * kenvandine uploads
[20:12] <rsalveti> but afaik it'll be blocked as well
[20:14] <sil2100> rsalveti: it's still building if anything, so I guess we need a bit more time
[20:14] <rsalveti> yeah
[20:14] <rsalveti> will take at least ~2h I guess
[20:15] <kenvandine> ok, uploaded
[20:24] <robru> sil2100, didier said something about "getting an archive admin to reenable the cron job", is that still relevant? or did he do that himself already?
[20:28] <sil2100> robru: it's enabled from what he said
[20:28] <sil2100> robru: so he did it himself already
[20:28] <robru> sil2100, ok thanks
[20:28] <sil2100> (from what I understood!)
[20:29] <sil2100> robru: those missing packages are still building... could you also keep a lookout for those? I will have to EOD soon
[20:29] <robru> sil2100, ok
[20:29] <sil2100> robru: rsalveti asked for an additional merge to be added - we'll have to rebuild then and publish
[20:30] <robru> sil2100, ok, I can add that, but it has to wait for the current build to finish, right?
[20:34] <rsalveti> yup
[20:57] <thomi> fginther: got a second? There's soemthing odd happening with an AP branch test run - looks like bzr conflicts, but I can't see why it would be merging anything.. should just be a 'bzr branch' as far as I can tell: https://jenkins.qa.ubuntu.com/job/autopilot-trusty-amd64-ci/300/console
[20:57] <thomi> do the jobs try and merge in trunk or something?
[20:58] <fginther> thomi, yes, all jobs start with a merge to trunk
[20:59] <thomi> ok, is that new?
[20:59] <sil2100> robru: it's still building...
[20:59] <fginther> thomi, no, that's always been the case
[20:59] <sil2100> I have to go now so good luck!
[20:59] <thomi> oh.. well, ok then :)
[20:59] <sil2100> Remember to publish everything later ;)
[20:59] <thomi> thanks
[21:00] <robru> rsalveti, ok, i guess it's just you and me now... still waiting on that build to finish
[21:01] <rsalveti> robru: :-)
[21:01] <rsalveti> will take at least more one hour
[21:03] <pmcgowan> this is like waiting for xmas
[21:04] <thomi> robru: cyphermox: I wonder if I could ask one of you fine gentlemen to allocate me a silo, so I can do a silo build & test on my Monday (which is USA Sunday)?
[21:04] <thomi> (spreadsheet row 42)
[21:06] <robru> thomi, ok
[21:06] <thomi> robru: thanks!
[21:07] <robru> thomi, ok, you got silo 3
[21:08] <thomi> robru: awesome - talk to you Monday about landing it :)
[21:10] <robru> thomi, for sure
[21:11] <thomi> now I get to spend the weekend testing :)
[21:11] <robru> sweet
[21:19] <robru> rsalveti, i gotta step out for about 20 minutes, will be right back though.
[21:20] <rsalveti> np
[21:23] <cyphermox> robru: assigning line 40.
[21:45] <robru> back
[21:46] <robru> wow, still building
[21:50] <rsalveti> yeah
[21:57] <cyphermox> robru: I'm going to go get dinner, bbl
[21:57] <robru> cyphermox, enjoy
[22:10] <robru> rsalveti, good god, it's done. now what? publish first, or add your mp first?
[22:10] <robru> i guess publish...
[22:11] <rsalveti> robru: yeah, please
[22:12] <robru> bah, not working
[22:12] <robru> http://162.213.34.102/job/landing-006-2-publish/37/console
[22:13] <robru> rsalveti, do you have any idea what is going wrong with qtwebkit-opensource-src
[22:13] <robru> ?
[22:14] <robru> I guess I have to re-prepare that one
[22:14] <rsalveti> I remember we also had to run build with watch-only
[22:14] <robru> rsalveti, ok i'll try some stuff
[22:16] <robru> great
[22:16] <robru> this is a fustercluck of the highest order
[22:32] <robru> rsalveti, I don't know what to do with qtwebkit-opensource-src. There's a phantom version in the PPA that citrain is puking on
[22:32] <robru> http://162.213.34.102/job/landing-006-2-publish/38/console
[22:32] <rsalveti> robru: hm, do you know which version is it?
[22:32] <robru> rsalveti, the error suggest re-preparing, so I did, and rebuilt (watch only), same error
[22:32] <rsalveti> 2014-03-13 22:31:33,951 ERROR Version in ci-train-ppa-service/landing-006 (5.2.1+dfsg-0ubuntu2) is not the last one prepared (5.1.1-1ubuntu6) (direct upload?).
[22:33] <rsalveti> when it was prepared, the version was 5.2.1+dfsg-0ubuntu2
[22:33] <rsalveti> the new one is 5.1.1-1ubuntu6
[22:33] <robru> rsalveti, yeah, so the ppa looks to me like it has 5.1.1-1ubuntu6, and that's what citrain expects, but it fails because it finds 5.2.1+dfsg-0ubuntu2 which I don't see in the PPA
[22:33] <robru> rsalveti, yeah but Mirv just uploaded that 5.1 one 3 hours ago
[22:34] <robru> rsalveti, no, I *just* prepared it like 2 minutes ago, and rebuilt, 5.2 is nowhere, it was not there when I prepared it
[22:34] <rsalveti> right, but it was at some point
[22:34] <rsalveti> maybe it got confused now somehow
[22:35] <robru> rsalveti, I dunno, i also saw this error much earlier, when didrocks was still around. it's been confused for a while
[22:35] <robru> rsalveti, do you have any idea how to fix this? I tried everything I know
[22:35] <rsalveti> so how did he manage to publish it a few hours ago?
[22:35] <robru> rsalveti, i have no idea
[22:36] <robru> rsalveti, didrocks was live-editing production code, it's all black magic to me, i have no idea what he did
[22:36] <rsalveti> maybe he published it manually
[22:36] <rsalveti> as the old job is still looking for latest version of qtwebkit
[22:37] <robru> rsalveti, https://launchpad.net/ubuntu/+source/qtwebkit-opensource-src there is no 5.2 in distro or even -proposed! This is really weird.
[22:37] <rsalveti> I believe he thought that running build with watch only would be enough
[22:37] <rsalveti> but maybe the landing code is still not handling the case when you need to downgrade a package
[22:38] <rsalveti> robru: it was in this ppa yesterday
[22:38] <rsalveti> but got downgraded
[22:38] <rsalveti> maybe that is what is confusing landing now
[22:38] <robru> rsalveti, so what then, abandon the silo and start totally over? i have no idea how to fix this
[22:39] <rsalveti> maybe cyphermox can give us a hand?
[22:39] <robru> when he gets back from dinner.
[22:40] <rsalveti> robru: can you add the one for u1db-qt?
[22:40] <rsalveti> then we can get it published once we know how to proceed
[22:41] <robru> rsalveti, where's the mp for that
[22:41] <rsalveti> robru: https://code.launchpad.net/~kalikiana/u1db-qt/revertResultFields/+merge/210890
[22:41] <robru> thanks
[22:43] <robru> rsalveti, ok, preparing new mp
[22:53] <robru> rsalveti, ok, got u1db-qt rebuilding here: http://162.213.34.102/job/landing-006-1-build/85/console
[22:53] <robru> ugh
[22:54] <robru> rsalveti, merge failed because u1db-qt was already published, but hasn't been merged, so changelogs conflict.
[22:54] <rsalveti> urgh
[22:55] <rsalveti> how to fix this one?
[22:56] <robru> rsalveti, ugh, well basically I have to make a new MP that resolves the changelog, but then after *that* gets built & publish it'll probably fail the merge & clean step. total disaster
[22:57] <rsalveti> urgh
[23:06] <robru> rsalveti, ok, got the mp, re-preparing
[23:07] <rsalveti> great, thanks
[23:07] <robru> no worries.
[23:11] <bregma> robru!! Unity7 daily landing in line 44!!
[23:12] <robru> OMG!!
[23:12] <robru> ok
[23:13] <robru> rsalveti, ok this is building: http://162.213.34.102/job/landing-006-1-build/86/console lets see what the next problem is
[23:13] <robru> bregma, ok, you got silo 7
[23:13] <bregma> thak a lot eh!!!
[23:14] <robru> you are welcome
[23:18] <robru> rsalveti, http://people.canonical.com/~platform/citrain/landing-006 this is the backend state that citrain uses to remember what it's doing. note there's no version numbers associated with the packages. so I have *no idea* why citrain is so insistent on this 5.2 version thing. it's not in the ppa! how can it know this?
[23:18] <rsalveti> no idea either
[23:19] <rsalveti> ok, will grab dinner, be back later
[23:21] <robru> rsalveti, yeah me too
[23:23] <cjwatson> I expect it's looking for the most recent source pub and forgetting to limit to published/pending
[23:25] <cjwatson> suggest you familiarise yourself with the lp apidoc for an archive
[23:28] <cjwatson> Mirv: fyi, you can safely copy without including binaries, no need to dget/dput
[23:29] <cjwatson> s/most recent source pub/highest-versioned source pub/
[23:31] <rsalveti> cjwatson: in this case the archive still has an older version (5.1.1-1ubuntu4), and 5.2 was published in the ppa yesterday, but got removed and replaced with a new package based on the 5.1 series (5.1.1-1ubuntu6)
[23:31] <rsalveti> so we believe the older version (5.2) is stored somewhere in the CI publishing logic
[23:32] <cjwatson> you don't need to invoke that; it's quite possible it's getting it from LP
[23:32] <cjwatson> there are patterns of incorrect api invocation that would lead to this
[23:32] <rsalveti> wouldn't it complain if we tried to published a minor version?
[23:32] <cjwatson> if anyone can point me at the source I can have a look
[23:32] <cjwatson> and stop trying to guess
[23:33] <rsalveti> robru might know, don't know where the code is
[23:34] <cjwatson> ah, cupstream2distro maybe
[23:35] <cjwatson> hm, that's seen a fix from me, it should be right
[23:37] <cjwatson> double hm
[23:37] <cjwatson> I wonder if LP's sorting logic changed, or if I analysed it wrongly before
[23:37] <cjwatson> In [7]: for source in sources:
[23:37] <cjwatson>    ...:     print source.source_package_name, source.source_package_version
[23:37] <cjwatson>    ...:
[23:38] <cjwatson> qtwebkit-opensource-src 5.2.1+dfsg-0ubuntu2
[23:38] <cjwatson> qtwebkit-opensource-src 5.2.1+dfsg-0ubuntu1
[23:38] <cjwatson> qtwebkit-opensource-src 5.1.1-1ubuntu6
[23:38] <cjwatson> qtwebkit-opensource-src 5.1.1-1ubuntu5
[23:38] <cjwatson> I would have expected the getPublishedSources to give me answers in reverse publication order
[23:41] <cjwatson> but the LP code that prefers sorting by version dates back to at least 2011
[23:42] <cjwatson> I think we probably need to sort by date_created
[23:45] <cjwatson> In [8]: for source in sorted(sources, key=attrgetter("date_created"), reverse=True):
[23:45] <cjwatson>     print source.source_package_version, source.status, source.date_created
[23:45] <cjwatson>    ...:
[23:45] <cjwatson> 5.1.1-1ubuntu6 Published 2014-03-13 19:06:16.211082+00:00
[23:45] <cjwatson> 5.1.1-1ubuntu5 Superseded 2014-03-13 14:53:49.380706+00:00
[23:46] <cjwatson> 5.2.1+dfsg-0ubuntu2 Deleted 2014-03-11 13:26:12.714869+00:00
[23:46] <cjwatson> 5.2.1+dfsg-0ubuntu1 Superseded 2014-02-28 11:12:12.219638+00:00
[23:46] <cjwatson> better
[23:53] <robru> cjwatson, sorry just got back. did you find the code? it is indeed lp:cupstream2distro (look under citrain/)
[23:53] <cjwatson> yes
[23:53] <cjwatson> god this test suite requires root!
[23:54] <robru> cjwatson, anything we can do about this for now? keep in mind I don't have permissions to push that code to production, so basically unless you can fix it on the LP side, our hands are tied until didrocks wakes up
[23:54] <cjwatson> it's not broken on the LP side
[23:54] <cjwatson> rather, I apparently misunderstood the API four months ago
[23:54] <robru> cjwatson, I mean like "can you erase that version number out of existence"
[23:54] <cjwatson> and hence misadvised didrocks
[23:54] <cjwatson> no
[23:55] <robru> rsalveti, oh, u1db-qt built. kalikiana are you around to test this? get the package from silo 6 and make sure it doesn't explode
[23:56] <cjwatson> how am I supposed to run the cupstream2distro test suite?  it blows up with a bazillion errors starting with
[23:56] <cjwatson> OSError: [Errno 2] No such file or directory: '/home/cjwatson/src/ubuntu/cupstream2distro/trunk/tests/tests/data/branches/multiple_symbols_with_changelog'
[23:56] <cjwatson> which rather suggests it's lost its mind about its base directory
[23:57] <cjwatson> es
[23:57] <cjwatson> sorry
[23:57] <robru> cjwatson, i have no idea i've never run it. you'd have to ask didrocks.
[23:57] <cjwatson> sod it, ln -s . tests/tests
[23:58] <cjwatson> the only possible hotfix I can think of is to do this in a different silo
[23:59] <robru> cjwatson, yeah, it occurred to me to jettison the silo and start over, but the thought terrifies me
[23:59] <cjwatson> well, you'd probably just copy rather than jettisoning as such
[23:59] <cjwatson> what actual changes are needed here?
[23:59] <cjwatson> is it literally just package rebuilds or is it source changes?
[23:59] <robru> cjwatson, especially considering we already published the silo so most of the packages require a merge & clean, but there's just a small handful that need to be republished