[02:09] <imgbot> [02:22] <rsalveti> ribru: issue with train: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-003
[02:22] <rsalveti> ribru: it seems it's adding ~rtm by default
[02:22] <rsalveti> in this case, it was added in the wrong place
[03:09] <imgbot> [03:24] <imgbot> [03:24] <imgbot> [04:19] <imgbot> [04:19] <imgbot> [04:56] <Mirv> mornings
[05:21] <ribru> rsalveti: looks right to me? ~rtm always came before 0ubuntu1
[05:21] <rsalveti> ribru: what if we already have 0ubuntu1 ?
[05:21] <rsalveti> and the next sync is 0ubuntu2
[05:21] <rsalveti> this is basically what happened
[05:22] <ribru> rsalveti: sorry i don't understand the issue.
[05:22] <rsalveti> current RTM version: 0.99.0+git20130923+17fdf86-0ubuntu2
[05:22] <rsalveti> current vivid version: 0.99.0+git20130923+17fdf86-0ubuntu3
[05:22] <rsalveti> after the sync, the version on the ppa: 0.99.0+git20130923+17fdf86~rtm-0ubuntu3
[05:23] <rsalveti> lp is saying 0.99.0+git20130923+17fdf86-0ubuntu2 is older than 0.99.0+git20130923+17fdf86~rtm-0ubuntu3
[05:24] <ribru> rsalveti: bump the version I guess? call it 0.99.0+git20130923+17fdf86.1 and then citrain will add ~rtm-0ubuntu1 and be fine
[05:24] <rsalveti> ribru: why bumping the packaging major version?
[05:24] <rsalveti> this is a src package
[05:25] <rsalveti> this is a bug on the train side
[05:25] <rsalveti> will happen with every other package that has a similar version id
[05:25] <rsalveti> I actually expected it to not add ~rtm by default
[05:25] <ribru> rsalveti: orders from on high were to prevent src builds in rtm from not having ~rtm tag, because we have a big problem where there's a huge delta between utopic & rtm where the versions are the same bug package content are different.
[05:25] <rsalveti> adding it by default is annoying
[05:26] <rsalveti> ribru: right, but this is not a normal landing via MR
[05:26] <rsalveti> this is a src package landing
[05:27] <rsalveti> I'll probably manually sync from the archive into the ppa
[05:27] <rsalveti> and run watch-only
[05:27] <rsalveti> would be nice to have an option to not add ~rtm by default
[05:27] <ribru> rsalveti: we had that option and it caused too many problems, we were told to take it away
[05:28] <ribru> rsalveti: it's not a source package upload, it's a sync, and the sync code mangles the version for a source rebuild on purpose.
[05:28] <rsalveti> right, but doing the wrong thing here
[05:28] <ribru> rsalveti: please don't unmangle the version unless you're doing a binary copy
[05:29] <rsalveti> ribru: why that?
[05:29] <rsalveti> I'm not doing another upload to vivid just because of this
[05:29] <rsalveti> makes no sense
[05:29] <ribru> rsalveti: because there is an *enormous* delta between utopic and rtm in which source packages have different contents but same version numbers. it's hugely broken
[05:29] <rsalveti> and changing the upstream version of the package
[05:29] <rsalveti> I know, but this is not the case
[05:29] <rsalveti> and I know what I'm doing
[05:30] <rsalveti> when I said it's a source package upload, is that even when landing on vivid, it was a src package upload
[05:30] <rsalveti> no MRs involved
[05:30] <ribru> rsalveti: ok, well, this isn't a train bug, train is doing what it was designed to do so that rtm packages would have distinguishable versions. if anything it's an rtm bug, because rtm is a total fustercluck.
[05:30] <rsalveti> if a developer makes a mistake here, it's his own problem
[05:31] <rsalveti> well, the version here is clearly wrong
[05:31] <rsalveti> and the train did all the work
[05:31] <ribru> rsalveti: don't ask me, I didn't determine the versioning scheme. ~rtm-0ubuntu1 was decided on a long time ago, it's what the archive admins wanted.
[05:31] <rsalveti> I know rtm is in a broken/weird state, but the tool changed the version to an invalid one
[05:31] <ribru> they know things (presumably)
[05:32] <rsalveti> it works for 0ubuntu1
[05:32] <rsalveti> not for versions higher than that (0ubuntu2...)
[05:32] <ribru> rsalveti: right but if rtm always had the right version, ~rtm-0ubuntu2 would be higher than ~rtm-0ubuntu1. so the issue is that a previous release had a wrong version, not that this version has the wrong versino
[05:34] <rsalveti> ribru: but how would rtm have the right version if it was a binary sync from ubuntu?
[05:34] <rsalveti> it *has* the right version now
[05:34] <rsalveti> there's nothing wrong with it :-)
[05:35] <rsalveti> see that I'm just trying to bump the package version of something that is already in RTM (via src package upload), doing the sync because I wanted to land first on vivid
[05:36] <ribru> rsalveti: yeah I don't know how to solve this problem. I'm not going to change the code to do -0ubuntu3~rtm because that code is a disaster unto itself. just do a manual copy into the ppa i guess.
[05:37] <rsalveti> ribru: sure, just reporting the issue anyway :-)
[05:38] <ribru> rsalveti: thanks. one day I'll just delete rtm and nobody will notice...
[05:39] <rsalveti> sounds like a good plan
[05:39] <rsalveti> :-)
[05:39] <rsalveti> having so much pain to sync so many packages from rtm into vivid
[05:39] <rsalveti> so we can land new stuff there and sync back
[05:53] <ribru> rsalveti: oh btw, OTA1 is gonna be based on utopic, so now we need to sync fixes between utopic, rtm, and vivid, but new features need to be synced between utopic + vivid but not rtm. have fun!
[05:54] <rsalveti> yup
[05:54] <rsalveti> madness
[05:55] <ribru> makes me glad I'm not an upstream ;-) I just push buttons...
[07:45] <tvoss> good morning
[07:46] <tvoss> trainguards, could someone add qtubuntu-media-signals to the sync silo 12?
[08:11] <tvoss> sil2100, hey there
[08:16] <sil2100> o/
[08:38] <sil2100> tvoss: I think qtubuntu-media fails to build in the silo
[08:38] <tvoss> sil2100, because qtubuntu-media-signals is missing
[08:40]  * brendand got that crash again
[08:40] <tvoss> brendand, got crash file with core?
[08:41] <brendand> tvoss, what does the 'with core' bit mean?
[08:41] <brendand> i mean why would it not always be there?
[08:42] <tvoss> brendand, there are numerous reasons why that can happen, difficult to tell. But we are hit by it for this particular crash quite regularly
[08:42] <brendand> tvoss, the CoreDump field is there
[08:43] <tvoss> brendand, mind sharing the .crash file then?
[08:44] <sil2100> tvoss: ah, so we need to rebuild those?
[08:45]  * sil2100 retries
[08:45] <tvoss> sil2100, yup
[08:47] <brendand> tvoss, http://people.canonical.com/~brendan-donegan/_usr_bin_unity8.32011.crash.2
[08:48] <tvoss> brendand, is apport still running?
[08:48] <Wellark> brendand: sorry, had a power blackout yesterday. you and jussi managed to triage the problem with silo 3?
[08:49] <brendand> Wellark, sort of
[08:49] <brendand> Wellark, well silo 3 landed anyway :)
[08:51] <brendand> tvoss, whoops! ignore that crash file...
[08:52] <tvoss> brendand, ack
[08:53] <brendand> tvoss, i just remembered that i flashed 139 to test system-image, so that crash is most probably one of the already fixed ones
[08:53] <tvoss> brendand, ack
[09:01] <oSoMoN> trainguards: hey, can I have a silo for line 103?
[09:02] <Mirv> oSoMoN: sure
[09:02] <dbarth> good morning
[09:02] <dbarth> trainguards: i have verified silo 8 for publication to vivid
[09:03] <oSoMoN> Mirv, thanks! dbarth’s silo 8 would conflict, but I’ll wait for it to land before I hit the "build" button
[09:05] <Mirv> oSoMoN: yes, exactly, the 008 will be m&c:d soon (30mins maybe) after it has migrated
[09:05] <tvoss> brendand, sent you testing packages
[09:10] <abeato> Mirv, sil2100, line 54 on the spreadsheet says Status="Silo ready to build", but is is actually a source package and packages have been built automatically. brendand was asking about whether that status message can be changed to "QA needs to sign off"
[09:14] <Mirv> abeato: yes it probably just needs watch only build, doing
[09:14] <Mirv> abeato: additionally, the source package specified is wrong (lacks 1.0), needs reconfigure
[09:15] <abeato> Mirv, ok, thanks
[09:16] <Mirv> abeato: now it's like it should be
[09:17] <abeato> Mirv, awesome, thanks, what was that "watch only build" step? just building from the dashboard?
[09:18] <sil2100> abeato: yeah, you build it from the dashboard and tick the 'Watch only' flag in jenkins
[09:18] <sil2100> Before pressing build
[09:20] <abeato> sil2100, ah, good to know, previously I had trouble using build from the dashboard with a source package, I didn't know about the flag ;)
[09:20] <abeato> brendand, now silo 8 has the right status
[09:21] <abeato> sil2100, btw, could you remove line 19 from the spreadsheet? It is not valid anymore (already landed). Or can I do that myself?
[09:23] <brendand> abeato, ok. right now the queue is a bit big from the freeze + image testing, but it should be tested by tomorrow at the latest
[09:24] <abeato> brendand, great, I just want to make sure that is in some queue ;)
[09:24] <abeato> thanks
[09:25] <sil2100> abeato: sure!
[09:26] <abeato> sil2100, thanks
[09:28] <ogra_> sil2100, i was just looking at the top output from all these systemsettle issues ... seems like we have a lot of whoopsie running all over the place
[09:28] <brendand> ogra_, is phablet-network working on 141?
[09:28] <ogra_> sil2100, most likely caused by all the scoperunner crashes
[09:28] <sil2100> ogra_: let me connect to the VPN and see
[09:29] <ogra_> scoperunner crashes in every test run ...
[09:29] <sil2100> hm, we didn't get that one resolved, right?
[09:29] <ogra_> didnt we have a fix for that ?
[09:29] <ogra_> i thought thostr_ had prepared a silo
[09:30] <tvoss> ogra_, iirc, it is the scope crashing, not the runner
[09:30] <tvoss> thostr_, ^
[09:30] <tvoss> ?
[09:30] <sil2100> I just remember poking thostr_ about it, but don't remember if it had a fix prepared
[09:30] <ogra_> tvoss, well, whatever crashes trashes test results :)
[09:30] <thostr_> yes, this wasn't  the scope runner but the scope
[09:31] <thostr_> and IIRC cwayne or somebody from his team was taking care of it
[09:31] <ogra_> well, we should land that quickly :)
[09:46] <thostr_> ogra_: it's supposed to have landed already... https://bugs.launchpad.net/hanloon/+bug/1388035
[09:47] <ogra_> thostr_, yep, we just discussed it in the landin team meeting
[09:47] <ogra_> thanks !
[09:51] <brendand> Mirv, i have a silo here whose changelog says it changes nothing but the version. do you have that code snippet for doing the proper diff?
[09:52] <brendand> Mirv, normally i'd expect that if the diff is wrong it would have more changes, not less
[09:58] <Wellark> brendand: so you tested on rtm, right?
[10:10] <Mirv> brendand: http://pastebin.ubuntu.com/8558016/ :)
[10:10] <Mirv> I always need to browse ~20 pastebin url:s from browser history to find it, but it's quicker than typing it again!
[10:11]  * Mirv suddenly has something that builds!
[10:13] <Mirv> "builds" means allowed to eat lunch
[10:13] <ogra_> bah
[10:13] <ogra_> botochart isnt even in rtm
[10:15] <popey> bootchart is broken on desktop
[10:15] <popey> has been for months
[10:15] <popey> collector runs forever, never generates an image
[10:15] <popey> (for me)
[10:16] <ogra_> oh, is there a bug ?
[10:16]  * popey looks
[10:17] <popey> hmm, can't find one
[10:17] <ogra_> yeah
[10:17] <tvoss> brendand, ping
[10:17] <tvoss> davmor2, ping
[10:17] <popey> i ended up removing it
[10:17] <popey> broke after updating to utopic
[10:18] <brendand> tvoss, hey
[10:18] <popey> last image I have is from trusty
[10:18] <tvoss> brendand, did you have a chance to give my packages a spin?
[10:18] <brendand> tvoss, not yet
[10:18] <popey> ogra_: I'll file one from my desktop
[10:18]  * ogra_ just runs phablet-bootchart ... 
[10:18] <ogra_> but that will need some changes for the passwd stuff
[10:18] <tvoss> ogra_, are you able to easily reproduce the current unity crashes?
[10:19] <ogra_> tvoss, no, for me they are totally random
[10:19] <ogra_> one a day
[10:29] <ogra_> popey, why is there so much blank space at the bottom of the music app ?
[10:29] <popey> where?
[10:29] <ogra_> (in "now playing")
[10:30] <ogra_> the controls feel like "one row to high up"
[10:30] <popey> there's a toolbar down there, which appears in other views.
[10:30] <popey> go to albums while playing something
[10:30] <ogra_> right
[10:31] <popey> ogra_: bug 1389166
[10:31] <ogra_> cool, thanks
[10:31] <popey> today I learned that my desktop has been installed since quantal ☻
[10:31] <popey> check the pastebin link in there
[10:32] <ogra_> popey, oh, i think the png generation only works if you pipe the tgz to pybootchartgui nowadays
[10:32] <popey> waaaat
[10:33] <popey> why is that useful?
[10:33] <ogra_> it dropped the java dependency that was responsible back then for png generation
[10:33] <popey> interesting
[10:33] <popey> i only run it for the funky png files
[10:33] <ogra_> you get them (or even svg's) when you call "pybootchartgui /path/to/tgz"
[10:34] <ogra_> it should have been installed as a dep
[10:34] <popey> it is installed, just seems to make no sense, that should be part of bootchart
[10:35] <popey> given the purpose of bootchart (in my simple brain) is to make "Boot Charts" ☻
[10:35] <ogra_> you can generate the data without UI tools
[10:36] <ogra_> on servers you would only install bootchart and have a central machine rsync the tgz's to pipe them to pybootchartgui
[10:36] <popey> right, so it should be a switch "make png/svgs/nothing"
[10:36] <ogra_> Recommends: pybootchartgui
[10:36] <ogra_> Breaks: bootchart-java
[10:36] <ogra_> on desktops you always have the parser installed alongside
[10:37] <ogra_> (due to recommends by default)
[10:37] <popey> right, but it doesn't run, is my point
[10:38] <ogra_> one could write an upstart job for pybootchartgui that watches the dir with inotify and generates pngs if a new tarball shows up
[10:39] <ogra_> but i have no idea how a systemd equivalent would look like ... hello vivid :P
[10:39] <popey> heh
[10:39] <popey> ok, thanks.
[10:40] <tvoss> does anyone find some time to give silo 12 a spin?
[10:40] <tvoss> on devel-proposed, obviously
[10:40] <Saviq> trainguards, icanhassilo for line 71 please
[10:42] <bzoltan_> trainguards: May I ask for a silo to process the line 63?
[10:44] <davmor2> tvoss: brendand is on silos and vrruiz will be too I'm on sanity and exploratory testing
[10:51] <Mirv> Saviq: bzoltan_: done
[10:51] <Saviq> o/
[10:52] <bzoltan_> Mirv:  thank you
[10:53] <Saviq> Mirv, hmm spreadsheet borked?
[10:53] <Saviq> Mirv, line 71 doesn't look right
[10:54] <Saviq> Mirv, and http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-007 doesn't list the unity8 MPs?
[10:54] <Saviq> or comment...
[11:00] <popey> ogra_: pybootchart craps out with "IndexError: string index out of range" - so.. yeah ㋛
[11:11] <ogra_> popey, yes, looking at that
[11:16] <ogra_> woah
[11:16] <ogra_> http://people.canonical.com/~ogra/ubuntu-phablet-vivid-8.png
[11:16] <ogra_> i wonder what runs this dpkg-query zombie
[11:19] <Mirv> Saviq: still borked? looks sane to me
[11:19] <Mirv> Saviq: the prepare-silo was here https://ci-train.ubuntu.com/job/prepare-silo/3064/console
[11:19] <Saviq> Mirv, no, seems it updated
[11:19] <brendand> tvoss, media-hub-server is using close to 100% cpu here - with no media playing
[11:20] <ogra_> play media then, so it isnt wasted :P
[11:20] <tvoss> brendand, core dump and strace would be great
[11:21] <brendand> tvoss, how do you make a core dump if it hasn't crashed?
[11:22] <tvoss> brendand, https://sourceware.org/gdb/onlinedocs/gdb/Core-File-Generation.html
[11:22] <tvoss> brendand, so find the pid of the process, attach with gdb as in: sudo gdb -p PID
[11:23] <tvoss> then generate core file, quit gdb by entering quit
[11:25] <davmor2> tvoss: why would you enter to quit is that not like pressing start to shutdown on windows ;)
[11:27] <ogra_> Saviq, is unity8-dash anywhere calling dpkg-query or lsb_release from the code ?
[11:28]  * ogra_ tries to find out what trashes the bootchart so badly, seems both of the above is started right after unity8-dash (could be a scope doing that though)
[11:29] <Saviq> ogra_, something like that is very possible, the scope backend sends out data about the phone
[11:29] <Saviq> ogra_, and click scope probably needs some of that info, too
[11:29] <Saviq> ogra_, your best bet would be pstolowski and alecu
[11:29] <ogra_> ah, right, i wouldnt expect a confined scope to have that permission
[11:30] <ogra_> click might indeed make sense here ... though on rtm it gets the wrong info anyway
[11:30] <ogra_> (from lsb_release)
[11:31] <brendand> tvoss, (gdb) strace
[11:31] <brendand> warning: Couldn't determine the static tracepoint marker to probe
[11:31] <brendand> Static tracepoint 1 at 0xb6a23712
[11:31] <brendand> tvoss, am i doing that wrong?
[11:32]  * brendand needs to take some time to learn gdb
[11:32] <tvoss> brendand, you cannot run strace from within gdb
[11:32] <tvoss> brendand, that being said: use gdb to generate the core file, quit gdb, and then run sudo strace -p PID
[11:32] <tvoss> where PID refers to unity8
[11:33] <pstolowski> ogra_, unity8-dash calls dpkg-query to get versions of unity8 and 2 other packages
[11:33] <ogra_> pstolowski, what for ?
[11:34] <ogra_> (and why on every boot)
[11:34] <ogra_> the process goes into zombie state for ~5 seconds
[11:34] <ogra_> are you sure it even returns what you want ?
[11:34] <ogra_> http://people.canonical.com/~ogra/ubuntu-phablet-vivid-8.png
[11:34] <pstolowski> ogra_, it needs versions number to report them with every search query send to smart scopes server
[11:35] <ogra_> (scroll down to unity8-dash)
[11:35] <ogra_> hmm
[11:35] <pstolowski> ogra_, but it just gets them once on startup
[11:35] <pstolowski> ogra_, yes, i'm pretty sure i'm getting the expected version strings
[11:35] <ogra_> well, it makes unity8-dash peg the CPU quite heavily alongside having the query sit there as a zombie
[11:36] <ogra_> (cpu pegging might be unrelated though, it might just be initializing a ton of scopes)
[11:37] <pstolowski> ogra_, what it does is just "dpkg-query -W libunity-scopes3 unity-plugin-scopes unity8" (http://bazaar.launchpad.net/~unity-team/unity-scopes-shell/trunk/view/head:/src/Unity/scopes.cpp); so, any idea why it's that slow?
[11:38] <ogra_> well, the dash seems to do a lot other stuff at that time too ... might be so busy that it cant process the return value from the query
[11:38] <ogra_> i'm not sure where that CPU hammering comes from (all the blue little stripes you  see in the unity8-dash bar on that chart)
[11:41] <ogra_> pstolowski, i wonder if there isnt some apt lib you could use instead of the dpkg-query that would provide you a better api than firing up a subprocess ... apt is C++ there should be something you can use thats better suited ... mvo_ might be able to help
[11:41] <pstolowski> ogra_, i'm not sure what to do about it right now. could you please file a bug? we need alternative and it's not going to be a one line fix
[11:41] <ogra_> mvo_, mind take a look at http://bazaar.launchpad.net/~unity-team/unity-scopes-shell/trunk/view/head:/src/Unity/scopes.cpp#L162 in a spare minute ?
[11:44] <brendand> tvoss, and then what? it just stays on epoll_wait
[11:45] <tvoss> brendand, in strace?
[11:45] <brendand> tvoss, yes
[11:45] <tvoss> brendand, ack, then just ctrl-c. I would need the core file
[11:48] <brendand> tvoss, well here's the core file: http://people.canonical.com/~brendan-donegan/media-hub-server.core
[11:48] <tvoss> brendand, thanks
[11:49] <brendand> tvoss, still uploading though
[11:49] <brendand> tvoss, will probably be about 30 minutes
[11:49] <tvoss> brendand, ack and thx
[12:03] <Mirv> brendand: I don't find bug #1374481 in the lists
[12:04] <Mirv> 11/6+11/13 targets nor in 11/13 iteration wishlist/escalations
[12:15] <brendand> Mirv, doesn't need to be since it was given the tag by olli himself - see just above comment 22
[12:16] <brendand> Mirv, if the tag was given my olli or pmcgowan then its automatically ok
[12:30] <Mirv> brendand: the latest e-mail from olli was 18 hours ago, and it only talks about the topblockers + additionally escalated bugs' wishlist. the tag was added 3 weeks ago, which is several iterations earlier of the process.
[12:30] <Mirv> note that I might be totally wrong, I just try to decipher the landing rules and last I heard it was limited to the topblockers list, after which another "wishlist" appeared that can be landed additionally
[12:31] <mvo_> ogra_, pstolowski: looking at this now. could you give me a little bit of context, what is this data needed for? it might be way simpler to simply export this as part of the package build or even postinst into a single location and avoid the overhead of reading the (big) status file entirely
[12:32] <mvo_> pstolowski: happy to help with this, but I need to understand first what exactly there is done (i.e. what data do you need from dpkg)
[12:32] <ogra_> mvo_, http://people.canonical.com/~ogra/ubuntu-phablet-vivid-8.png ... scroll down to unity8-dash there ... the dpkg-query call turns into a zombie (grey) while unity8-dash gets very busy (blue bars)
[12:33] <ogra_> mvo_, i was wondering iif there isnt a way to do that a bit cleaner and without a subprocess call directly from C++
[12:33] <ogra_> it seems to need that data to query the right stuff from the scopes server
[12:33] <pstolowski> mvo_, i need to read versions of 3 important packages.. whenever any of them is upgraded, i need the new version to be picked at runtime (after reboot)
[12:33] <mvo_> ogra_: yeah, definitely, but maybe the overhead can be avoided entirely by exporting the information at build/install time
[12:33] <ogra_> i suspect that could also be put into a file at rootfs build time though
[12:34] <ogra_> which you simply read ...
[12:34] <ogra_> but it will likely break in case you make the image writable and install a new unity8-dash for i.e. testing purposes
[12:34] <ogra_> (or in desktop-next)
[12:34] <mvo_> pstolowski: thanks, so you read this at startup and compare to the previous version? (pardon my ignorance)
[12:35]  * ogra_ understood it isnt even compared but just sent
[12:35] <pstolowski> mvo_, no, i just pass it to the smart scopes server
[12:35] <Mirv> sil2100: if you're around, could you clarify the landing rules to me and brendand :) see comments 5 + 20 mins ago
[12:36] <sil2100> Mirv: reading those right now ;)
[12:36] <mvo_> pstolowski: thanks, I get the idea now. let me think for a moment about it
[12:37] <Mirv> so, my current "check lists" are a) 11/6 & 11/13 targets b) 11/13 iteration wishlist/escalations
[12:37] <sil2100> Mirv, brendand: so as always there's a lot of ambiguity with the current rules, but the [TOPBLOCKER] bugs are essentially bugs that NEED to be fixed before we release the final image
[12:38] <sil2100> Mirv, brendand: I suppose anything that was set for an earlier milestone but just didn't make it on time should still land normally
[12:39] <Mirv> sil2100: 4 days ago there was an email that said "approved landings: only the ones listed in [1] are OK to land, anything else needs to be escalated to the Product Team"
[12:39] <sil2100> Mirv, brendand: from what I know, the rule is to keep the topblockers as top priority for developers and landing, but I didn't hear anything about us not landing critical bugs that have been approved earlier
[12:39] <mvo_> ogra_: using libapt for this would be fine, but if the cache needs rebuilding its still a performance hit we can avoid, its just three packages afterall
[12:39] <Mirv> and 18h ago there was another email about this wishlist/escalations
[12:39] <sil2100> Mirv: I think I need to clear this out with olli once he's online
[12:40] <sil2100> Maybe he wasn't exactly super clear in the e-mail back then
[12:40] <Mirv> sil2100: based on those two latest e-mail from olli, I restrict myself to the 11/6 & 11/13 targets + 11/13 iteration wishlist/escalations for now. it seemed clear in those e-mails we're restricting ourselves to the lists.
[12:41] <Mirv> but let's see if any new information emerges once he's online!
[12:44] <cwayne> sil2100: hey, so we do have a fix for that scope crashing
[12:44] <cwayne> don't yet have a fix for the activity indicator never going away
[12:44] <sil2100> cwayne: hello! Excellent, we thought so during our morning meeting actually
[12:44] <ogra_> land it !!
[12:44] <ogra_> :)
[12:44] <sil2100> cwayne: is it in the custom tarball you mentioned yesterday?
[12:45] <cwayne> sil2100: yeah
[12:45] <sil2100> davmor2: how busy are you?
[12:45] <Saviq> Mirv, any idea why http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-007 doesn't show the unity8 MPs (and cuts off the description, too)?
[12:45] <Saviq> ↑ loaded question
[12:46] <davmor2> sil2100: fairly but nearly done, custom will happen after Lunch though
[12:46] <sil2100> davmor2: great to hear that, we'll be waiting!
[12:46] <sil2100> cwayne: ^
[12:47] <Mirv> Saviq: I don't see what'd be missing, the last bug in the description is "Fix answering by accident", same as in ci train
[12:48] <Saviq> Mirv, oh, I'm blind, but still, MPs are not listed?
[12:48] <Mirv> Saviq: no idea why the unity8 popover is empty, sil2100?
[12:48] <Saviq> Mirv, yeah, newlines FTW, is why I couldn't see them all
[12:48] <Mirv> maybe some parsing error, at least there are blank lines in the MP list (only thing that comes into my mind)
[12:48] <Saviq> hmm that wasn't a problem before
[12:49] <Saviq> anyway, let's see how a build goes
[12:50] <davmor2> ogra_: mako on vivid can you connect via mtp?
[12:51] <ogra_> davmor2, no idea, no mako with vivid around here :P
[12:51] <ogra_> shouldnt be different from krillin rtm though
[12:51] <ogra_> when the screen is unlocked it should let you in
[12:52] <sil2100> Saviq, Mirv: not sure... the CSV parsers can sometimes be a bit dumb too
[12:52] <davmor2> ogra_: is the popup window I get on image 8 Unable to open MTP device '[usb:003,030]'
[12:52] <davmor2> ogra_: and that is logged in :)
[12:53] <ogra_> davmor2, sounds liek mtp-server crashed then
[12:53] <ogra_> check /var/crash
[12:55] <davmor2> ogra_: phablet   3988  0.0  0.0   4844   672 pts/0    S+   12:54   0:00 grep --color=auto mtp  I'm assuming I should see it running right?  and nothing in /var/crash
[12:59] <ogra_> davmor2, you should see mtp-server running
[12:59] <ogra_> seemsingly you dont
[13:00] <davmor2> ogra_: indeed so I'm assuming it just isn't started
[13:01] <davmor2> ogra_: manually I did start mtp-server now it is working
[13:01] <ogra_> davmor2, right, file a bug and let cyphermox know
[13:01] <sil2100> olli: hey!
[13:01] <ogra_> sounds liek you dont get the right upstart events or some such
[13:01] <olli> hi sil2100
[13:01] <ogra_> davmor2, which is a bit weird, since this definitely didnt change in vivid vs rtm
[13:02] <ogra_> i know there is a pending fix for an mtp crash, but nothing that touches the upstart setup
[13:04] <oSoMoN> trainguards: can silo 6 (vivid) be published, please?
[13:05] <mvo_> pstolowski: sorry for the delay, got distracted. something like http://paste.ubuntu.com/8818749/ for the three packages in question maybe a cheap way to store the information. filename/location may not be ideal but you get the idea I guess :)
[13:07] <sil2100> oSoMoN: o/
[13:08] <pstolowski> mvo_, is it going to be triggered and updated whenever any of these packages get upgraded?
[13:09] <sil2100> Mirv, brendand: ok, so confirmed that what Mirv mentioned holds true - we should really only consider topblockers right now (for most cases)
[13:09] <mvo_> pstolowski: the snippet needs to be added to the postinst/postrm of the three packages affected and then you can simply read it from there. you could use libapt too, but in the worst case you will still have to read /var/lib/dpkg/status which is 6mb on my workstation just to get these 3 lines
[13:14] <oSoMoN> sil2100, re- packaging changes, where can I get a link to the relevant diff for changes in debian/, so that I can ask a core dev to review?
[13:16] <sil2100> ogra_: do you have a moment for a packaging ACK for webbrowser? :)
[13:16] <ogra_> sure
[13:17] <sil2100> oSoMoN, ogra_: so, I checked the diff right now and I see a problem
[13:17] <sil2100> oSoMoN, ogra_: https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/32/artifact/packaging_changes_webbrowser-app_0.23+15.04.20141104-0ubuntu1.diff/*view*/
[13:17] <sil2100> oSoMoN, ogra_: but... qtdeclarative5-quicklayouts-plugin is in universe, while webbrowser-app is in main
[13:18] <Mirv> sil2100: ok, good that I kept saying that then :)
[13:18] <sil2100> So this dep is a bit troublesome
[13:18] <ogra_> yes
[13:18] <sil2100> Mirv: yes :)
[13:18] <ogra_> that would break on desktop
[13:18] <Mirv> sil2100: brendand: pete-woods: thostr_: rtm-019 is CI sign-off:d but blocked by not being approved by olli. please submit it to "11/13 iteration wishlist/escalations" spreadsheet.
[13:18] <Mirv> s/CI/QA/
[13:19] <olli> if that's https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1374481
[13:19] <olli> then pls proceed landing it
[13:19]  * sil2100 goes off for lunch o/
[13:19] <olli> just cut the wishlist thing short
[13:19] <olli> that should hvae been a topblocker
[13:20] <Mirv> olli: yes it is, thanks! then I'll just publish it, thostr_ + pete-woods
[13:20] <olli> sorry, we missed that one somehow when looking at topblockers
[13:20] <olli> Mirv, sil2100, if in doubt -> wishlist and ping pmcgowan or me
[13:21] <thostr_> olli: just to be sure: on the wishlist spreadsheet, only the new tab applies, meaning it overrides the previous one?
[13:21] <Mirv> olli: sure, that's what we do. there was just a bit of confusion of the process but it turned out I had the correct idea.
[13:22] <olli> thostr_, correct
[13:23] <brendand> olli, but can only TOPBLOCKER bugs land?
[13:27] <oSoMoN> sil2100: oh, good catch! sorry I didn’t catch it upfront, I’ll fix this somehow
[13:27] <pstolowski> mvo_, i see. yeah, this script seems like a good solution, thanks for that
[13:28] <mvo_> pstolowski: yw
[13:28] <sil2100> oSoMoN: might not be a big issue, maybe it can just be included into main... but you know how MIR issues can be tiring sometimes ;)
[13:29] <oSoMoN> sil2100: no need for that, I’ll just make sure we remove the need for QtQuick Layouts in the browser, it’s a minor change anyway
[13:29] <olli> brendand, unless explicitely approved in the wishlist
[13:31] <brendand> olli, am i correct in thinking this is a change from a couple of weeks ago? pmcgowan told me that bugs with the three tags could land as long as the tags were added by you or him
[13:31] <brendand> (two tags actually)
[13:31] <brendand> rmt14+date
[13:33] <olli> brendand, correct, I tried to outline it in my mail to phablet "next landing dates and milestones for BQ" from 10/30
[13:34] <brendand> olli, ack
[13:35] <olli> brendand, with some luck we might be able to improve this situation a lot, soon
[13:35] <olli> luck = me having some time today
[13:36] <pmcgowan> brendand, we do appreciate you guys reviewing changes for landing risk, as some of these were tagged some time ago
[13:58] <brendand> abeato, i'm testing 10 right now btw
[13:59] <abeato> brendand, ack
[14:00] <davmor2> sil2100: Krillin on 141 passes sanity, Mako on devel-proposed Fails mtp isn't started.
[14:01] <ralsina> trainguards can I get a silo for #72 please?
[14:05] <Saviq> trainguards, can you please reconfigure vivid silo 7 for me, added unity-api there
[14:20] <davmor2> sil2100, ogra_: is there a bug for not being able to disable a specific test set based on device?
[14:20] <sil2100> davmor2: on smoketesting?
[14:20] <sil2100> Saviq: sure
[14:21] <sil2100> ralsina:
[14:21] <sil2100> o/
[14:21] <davmor2> sil2100: yes ie filemanager tests on krillin
[14:21] <brendand> davmor2, https://bugs.launchpad.net/ubuntu-test-cases/+bug/1387391
[14:21] <ralsina> sil2100: yes sir!
[14:21] <davmor2> ah nice thanks brendand
[14:21] <brendand> davmor2, it's all under control
[14:21] <davmor2> yay
[14:23] <ogra_> davmor2, ask plars :P
[14:23] <ogra_> ah, there is
[14:23]  * ogra_ should read the full backlog :P
[14:23] <davmor2> ogra_: already in hand thanks to brendand :)
[14:23] <ogra_> yeah
[14:24] <plars> davmor2, ogra_: yep, I know about it, there's some other things I'm supposed to finish first though
[14:25] <Saviq> sil2100, thanks
[14:25]  * sil2100 needs to use the manual job again
[14:26] <plars> ogra_: the systemsettle change seems to need some more tweaking
[14:26] <sil2100> Since after ribru's changes it's trying to push all those merges throught the POST request
[14:26] <ogra_> plars, given that whoopsie constantly eats the devices thats hard to say :P
[14:26] <plars> ogra_: true
[14:27] <Saviq> sil2100, looks like I'm putting too much data in my silos, it doesn't fit through POST ;)
[14:28] <sil2100> Saviq: right ;) But that's good, originally that's what CI Train was supposed to be able to handle
[14:28] <sil2100> It might be changed once the spreadsheet changes, we can change the method for fetching the MP list then
[14:28] <sil2100> ribru did it for this purpose, to make sure CI Train is 'spreadsheet agnostic'
[14:29] <plars> ogra_: it can be a pretty flaky check too though sometimes - I see cases where we idle more than the threshold according to top, but the average of /proc/stat checks apparently wasn't good enough in the last run, so in the end there isn't always a clear culprit
[14:32] <ogra_> plars, well, i cecked random topbefore and topafter logs for 141 and nearly all of them have python3 between 80-100% and show whoopsie show up later then
[14:37] <bfiller> sil2100: rtm 6 not updating correctly on the webpage, it should be marked as tested awaiting QA approval
[14:41] <sil2100_> grrr
[14:46] <pstolowski> ogra_, https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1389257
[14:46] <brendand> tvoss, now it's posclientd and ubuntu-location-service
[14:46] <tvoss> brendand, core dumps would be helpful
[14:46] <ogra_> pstolowski, awesome !
[14:46] <pstolowski> ogra_, feel free to escalate to have it prioritized
[14:46] <brendand> tvoss, and something called slpgwd
[14:47] <tvoss> brendand, that's the here stuff
[14:47] <tvoss> brendand, can you take core dumps of all of them
[14:48] <sil2100> Is that for the 100% CPU usage?
[14:49] <cwayne> davmor2: sorry, trying to get one last update in first
[14:49] <cwayne> and was in a meeting
[14:56] <brendand> tvoss, uploading
[15:14] <jhodapp> sil2100, can you please free up vivid silos 9 and 12 please? silo 5 is a converged silo of these 2
[15:14] <ogra_> convergence !!!
[15:15] <sil2100> jhodapp: sure :)
[15:15] <jhodapp> sil2100, thanks
[15:15] <jhodapp> ogra_, haha yes, the future is now! :)
[15:15] <ogra_> :D
[15:18] <Saviq> sil2100, can you please restart the builds in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-007/+sourcepub/4550289/+listing-archive-extra
[15:18] <Saviq> sil2100, unity-api is built now
[15:20] <sil2100> Saviq: sure
[15:20] <sil2100> Saviq: hm, but these should start by themselves soon anyway, right?
[15:20] <sil2100> As they're in dep-wait
[15:21] <Saviq> sil2100, define "soon"
[15:21] <Saviq> sil2100, they would, but if you restart, it'll be sooner than soon :)
[15:21] <sil2100> hm, not sure, but yeah, sometimes that was taking some time ;)
[15:22] <sil2100> Saviq: ok, kicked
[15:23] <Saviq> sil2100, thanks
[15:27] <sil2100> cwayne: thanks for the changelog!
[15:27] <bzoltan_> ogra_: ping ... we have a problem, Huston. The  there is an SSH protocol mismatch between the SDk and the Vivid image. The device and SDK  capabilities don't match
[15:27] <sil2100> cwayne: I was wondering, is the product team aware about those fixes? As there are a lot of fixes there that wasn't consulted with olli and the product managers
[15:29] <bzoltan_> ogra_ the SDK supports aes128-cbc,3des-cbc but the device with vivid image supports aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com.
[15:30] <bzoltan_> sil2100: we have a showstopper issue for the Vivid images ... ^
[15:30] <cwayne> sil2100: joe is aware of all of them (and asked for the majority of them)
[15:30] <cwayne> fginther: ping
[15:30] <sil2100> cwayne: ok, good to know
[15:31] <cwayne> fginther: all of a sudden my jenkins job is failing with weird permissions stuff (not having adequate permissions to create a dir)
[15:32] <sil2100> bzoltan_: ugh
[15:32] <bzoltan_> sil2100: We are  not late to fix that.. vivid is still fresh out
[15:32] <ogra_> bzoltan_, no issues with ssh here
[15:33] <ogra_> http://paste.ubuntu.com/8820556/
[15:33] <bzoltan_> ogra_:  I guess you do not use the SDK
[15:33] <ogra_> why would that matter
[15:33] <sil2100> ogra_: btw. can you lead the evening meeting today? I need to go to practice today again
[15:33] <ogra_> sil2100, sure
[15:33] <sil2100> Thanks :)
[15:33] <bzoltan_> sil2100: ogra_: it is not the ubuntu ssh package what is wrong
[15:34] <ogra_> bzoltan_, what do you mean then ? if someone runs the SDK on a 2 year old fedora and tries to connect to a vivid phoen ?
[15:34] <ogra_> :P
[15:34] <bzoltan_> ogra_: the QtCreator uses its own ssh library and it requires the listed capabilities
[15:34] <fginther> cwayne, I can take a look in a short moment
[15:34] <ogra_> bzoltan_, well, we dont make any changes to ssh
[15:35] <ogra_> bzoltan_, i guess thats something to bring up with the ssh maintainer then
[15:35] <bzoltan_> ogra_:  no, I mean if you try to run an app from Trusty or  Utopic PC on a vivid device
[15:35] <ogra_> (who would be cjwatson )
[15:35] <ogra_> bzoltan_, well, either fix your shipped lib or make ssh use more protocols
[15:35] <ogra_> err
[15:35] <ogra_> more algorithms
[15:36] <bzoltan_> ogra_: yes, these are the options... sadly the QtC comes as it comes
[15:36] <ogra_> sadly ssh comes as it comes
[15:36] <ogra_> :P
[15:36] <ogra_> one of you needs to change :)
[15:36] <bzoltan_> ogra_: I know, I know :)
[15:36] <ogra_> not really much i can do there, thats a matter of ssh vs QTc
[15:36] <ogra_> *QtC
[15:37] <bzoltan_> ogra_: I think it would be simpler to change the vivid ssh than fixing the QtC and backport to U and T
[15:37] <ogra_> bzoltan_, explain that to the server admins over the world ... or to the juju guys .... or whereever else ssh is used in ubuntu
[15:37] <bzoltan_> ogra_:  I know it is not your desk :) I just try to keep you well informed
[15:38] <bzoltan_> ogra_:  yes, ssh is used all over the places :)
[15:38] <ogra_> bzoltan_, btw, i dont see a ssh landing on vivid-changes
[15:39] <ogra_> must either be coming directly from debian (unchanged) or it simply is still the same one we had in utopic
[15:39] <bzoltan_> ogra_:  it could be on utopic image too
[15:39] <bzoltan_> ogra_:  for some time I was testing the SDK against the RTM images
[15:40] <ogra_> well, i woulld be surprised if none of our app developers had hit it in utopic
[15:40] <cwayne> fginther: think i got it
[15:45] <oSoMoN> trainguards, do you know what’s up with the silo builders? e.g. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/6537580 (and other arches but for armhf) has been queued, whereas it usually starts right away
[15:48] <ogra_> oSoMoN, builders being busy ?
[15:51] <oSoMoN> right, I guessed so, but I’m surprised as I’d never seen any wait time for silos before, I assumed they had a really high priority that made them skip the queue, basically
[15:51] <oSoMoN> seems it’s not entirely true
[15:52] <oSoMoN> and the wait time is increasing by the minute
[15:53] <cwayne> oSoMoN: do you have an eta on rtm silo 15 landing?
[15:55] <davmor2> cwayne: do you need that landing for something in custom?
[15:55] <cwayne> davmor2: it's not blocking anything
[15:55] <cwayne> davmor2: but it's a bugfix that a customer wanted
[15:55] <davmor2> phew
[15:55] <cwayne> :)
[16:00] <oSoMoN> cwayne, not yet, but we have an oxide call in 30min where I expect this will be discussed and hopefully resolved
[16:03] <ogra_> tvoss, meeting notification just crashed my session ...
[16:03]  * ogra_ checks for .crash files
[16:04] <ogra_> nothing :(
[16:07] <cjwatson> bzoltan_: SDK has to be fixed, this was an upstream ssh decision for good security reasons which I am not going to overrule
[16:07] <cjwatson> (also, not at work today)
[16:07] <cjwatson> surely QtC upstream would be receptive to fixing interop with all OpenSSH 6.7 installations
[16:09] <cjwatson> oSoMoN: they do have a high priority but they don't cause builds actually in progress to be interrupted, so still have to wait for any long builds in progress to complete
[16:09] <cwayne> lalalala /me waits for image-import to finish
[16:09] <ogra_> cwayne, will your next custom tarball also fix the constant fitbit related crash of UAL ?
[16:09] <cjwatson> also possible that the wait time is a bit of a guess
[16:09] <ogra_> this is really annoying and makes whoopsie kick off totally unneeded
[16:09] <cwayne> ogra_: i think so
[16:09] <ogra_> phew
[16:09] <ogra_> thanks so much
[16:10] <cwayne> ill have to double check that it made it in in time
[16:10] <cjwatson> http://www.openssh.com/txt/release-6.7 has the note about cipher changes
[16:10] <cwayne> it's definitely in trunk, so if not this one then next one
[16:10] <cjwatson>  * sshd(8): The default set of ciphers and MACs has been altered to
[16:10] <cjwatson>    remove unsafe algorithms. In particular, CBC ciphers and arcfour*
[16:10] <cjwatson>    are disabled by default.
[16:10] <cjwatson>    The full set of algorithms remains available if configured
[16:10] <cjwatson>    explicitly via the Ciphers and MACs sshd_config options.
[16:13] <oSoMoN> cjwatson, got it, thanks
[16:17] <bregma> hey mr. vanguard fginther, I'm having trouble with ci-job compiz-0.9.11-ci on s-jenkins building in a Utopic environment instead of a 14.04 environment...  is there any way that can be fixed?
[16:44] <fginther> bregma, yes that can be fixed, will let you know when it's ready
[16:44] <bregma> fginther, thanks
[16:51] <Saviq> sil2100, looks like LP hates you... https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-007/+build/6536261 will only start building in 52 minutes?
[16:52] <Saviq> amd64 and i386 were quite far the queue, too
[16:58] <cjwatson> bzoltan_: there is the option of shipping a modification to sshd_config on the phone images that changes Ciphers to whatever you need; I advise against that because those ciphers are unsafe, but it's clearly intended by upstream to remain an option for cases where there's no alternative; I guess that would be something for ogra_ or one of his colleagues to sort out.  If you do that you should still make sure this is raised to ...
[16:58] <cjwatson> ... whichever QtC component is responsible, though, and we should try to carry it for as short a time as possible
[16:59]  * ogra_ would feel pretty uneasy about adding such hacks 
[16:59] <kgunn> ogra_: just to make sure, if i flash channel=devel-proposed that's vivid right ?
[16:59] <kgunn> just reading here
[16:59] <kgunn> http://developer.ubuntu.com/start/ubuntu-for-devices/image-channels/
[16:59] <kgunn> might need a vivid update
[17:00] <ogra_> kgunn, i'll let sil know (he is out on tuesday evenings)
[17:00] <kgunn> ack
[17:01] <oSoMoN> cwayne, oxide 1.3 officially rejected for RTM, so the fix for tel: links will have to wait for the first OTA update
[17:01] <cwayne> :(
[17:02] <ogra_> davmor2, coming to the meeting ?
[17:04] <ogra_> bfiller, is anyone looking into the cmaera-app test failure in smoke testing ?
[17:06] <bfiller> ogra_: not yet, but I will get someone to look at it
[17:06] <ogra_> cool, thanks
[17:06] <bfiller> ogra_: on krillin?
[17:06] <ogra_> yep
[17:11] <bfiller> ogra_: all the failures look like the app is not launching
[17:12] <bfiller> looking at crash file
[17:12] <ogra_> bfiller, well, its only 4 out of 16 tests failing
[17:12] <ogra_> so it must run somehow
[17:12] <bfiller> ogra_: right, all the ones that fail are due to the app not launching
[17:12] <bfiller> it get relaunched after each test
[17:16] <om26er> cyphermox, Hi!
[17:17] <cyphermox> howdy
[17:17] <om26er> cyphermox, I am trying to figure out what to test for rtm silo 16 ?
[17:17] <om26er> cyphermox, there is not mentioned testplan
[17:17] <om26er> or neither is there a mention of how to verify the bug fix
[17:17] <cyphermox> it's in the bug description
[17:18] <cyphermox> https://bugs.launchpad.net/indicator-network/+bug/1386109
[17:18] <om26er> cyphermox, so qdbus on the phone says 'qdbus: could not find a Qt installation of '''
[17:18] <cyphermox> om26er: you should be able to install qdbus on the phone separately
[17:18] <brendand> olli, pmcgowan - who do you need input from for https://bugs.launchpad.net/ubuntu-rtm/+source/maliit-framework/+bug/1373985?
[17:19] <olli> brendand, Elleo
[17:20] <olli> Elleo, ping
[17:20] <Elleo> olli: what input do you need?
[17:20] <olli> Elleo, the repro steps don't seem conclusive
[17:20] <olli> i.e. isn't it missing a starting state?
[17:21] <olli> Elleo, if I do what's described I do get the expected behavior
[17:21] <olli> on #140 / krillin
[17:21] <Elleo> olli: I think what isn't clear in those steps is that you need to have a password not a pin set
[17:21] <olli> ah
[17:22] <ogra_> pmcgowan, why would bug 1378821 not affect europe ? we are not all running on UTC TZ here :P
[17:22] <om26er> cyphermox, ok, had to download the deb separately due to some reason :0
[17:22] <Elleo> olli: I've updated it to make that clear
[17:23] <ogra_> ribru, who is that robru guy ?
[17:23] <ogra_> havent seen him around here
[17:23] <ogra_> :P
[17:23] <ribru> :-P
[17:23] <Elleo> olli: have to leave to catch a train now, but if there's any other questions ping me and I'll answer them when I get back later tonight
[17:23] <ribru> ogra_: i still have a highlight on robru ;-)
[17:23] <ogra_> hah
[17:30] <davmor2> ogra_, cwayne: sanity is good on custom moving to test the delta now :)
[17:31] <ogra_> yay
[17:31] <pmcgowan> ogra_, ask you fellow EUers, they blew me off :)
[17:31] <cwayne> davmor2: ive found an issue, but i've also just fixed it :)
[17:31] <ogra_> pmcgowan, well, specifically spain and portugal are not on UTC
[17:32] <pmcgowan> I guesss it was the yesterday thing would be unlikely
[17:32] <ogra_> well, its only UTC+1 so it will only be wrong while you are drunk in a bar or some such
[17:32] <ogra_> i.e. while the day turns
[17:33] <pmcgowan> ogra_, so it is likely :)
[17:33] <ogra_> :)
[17:33] <ribru> ogra_: is it safe for me to land some stuff? I see some silos that say they're ready, not sure if you guys are about to build an image or what
[17:34] <ogra_> ribru, vivid can land all the time ... rtm only whats on olli's approval list
[17:34] <ogra_> didnt change :)
[17:34] <ogra_> the custom tarball landing will trigger a new image, i was planning to kick another one after that for a new rootfs
[17:34] <ogra_> i see two new landings on the rtm-changes mailing list
[17:35] <ribru> ogra_: so eg there's an rtm landing for system-image, it has qa signoff and claims to be approved for 10/30. can i publish that?
[17:35] <ogra_> you should, yeah ... check twice on olli's spreadsheet before hitting the button though
[17:36] <pmcgowan> ribru, is that the phased updates fix? if so thats expected
[17:37] <pmcgowan> ribru, silo 4 is good to go
[17:38] <ribru> pmcgowan: thanks
[17:40] <om26er> cyphermox, so basically I just test that the bug is fixed. Is there some regressions suite for network-manager that I could run ?
[17:40] <om26er> "just to be sure"
[17:47] <ogra_> oooh, the whoopsie fix !
[17:47] <ogra_> finally
[18:08] <cyphermox> om26er: https://wiki.ubuntu.com/NetworkManager/DistroTesting
[18:08] <cyphermox> aside from that there are some autopkgtests
[18:15] <ribru> does nobody need to build anything? c'mon people, it's a great time to build a silo! ;-)
[18:42] <dobey> ribru: i guess one thing about the current landing policy is that silos are going to be free when needed generally. :P
[18:57] <om26er> ribru, is there a way to revert a silo added to my phone with 'citrain' tool ?
[18:59] <brendand> om26er, i suppose ppa-purge would work, but wouldn't rely on it
[19:00] <om26er> brendand, ppa-purge is fine, though it pulls alot of crap with it, the likes of aptitude etc.
[19:01] <brendand> om26er, but please don't base your silo testing on anything involving ppa-purge
[19:01] <brendand> om26er, if you need to check if an issue is present without the silo, ask someone
[19:02] <om26er> brendand, and whats the reason for that ?
[19:02] <brendand> om26er, because citrain itself is not accurate as it is
[19:03] <brendand> om26er, but it's the best we have, and if we start throwing other things in the mix then we just open ourselves up to mistakes
[19:04] <om26er> brendand, I have a different test case and I'll perhaps do some manual fiddling, like disabling the ppa and then just installing with package_name/ubuntu_release
[19:06] <om26er> sometimes you need to go back to the old version of a software to compare a before-after situation -- this can work just reliable atleast for the cases where the changeset is isloated into one source.
[19:08] <ribru> om26er: yeah i specifically did not implement ppa-purge inside citrain tool because it pulled in deps and dirtied the image. The only reliable way to get back to a clean state is to reflash.
[19:09] <cwayne> davmor2: ive got to run for awhile, pleae shoot me an email when testing is done, otherwise ping me here and ill press the magic button as soon as i'm back
[19:15] <ribru> bregma: ubuntu 12 and 14
[19:25] <fginther> bregma, the compiz-0.9.11 jobs have been updated. https://code.launchpad.net/~compiz-team/compiz/compiz-0.9.11.3-version-bump/+merge/228329 is now passing
[19:26] <bregma> fginther, I saw that, thanks for the fix
[19:26] <fginther> bregma, you're welcome
[19:55] <davmor2> cwayne: Build is good
[19:59] <davmor2> sil2100, ogra_: ^ ogra_ that should make you happier once cwayne is about to press the magic fairy lights button
[20:01] <davmor2> ogra_: only crashes I see are mtp server which I think died when I enabled dev mode and camera app \o/
[20:01] <cwayne> davmor2: pressing now
[20:02] <davmor2> woohoo!
[20:02] <cwayne> pressed :D
[20:02]  * cwayne goes back to being afk
[20:07] <sil2100> davmor2: woot!
[20:08] <davmor2> sil2100: I know right give it chance though I mean cwayne-afk broke it before I even started testing the delta, and then fixed it :)
[20:12] <davmor2> sil2100: https://bugs.launchpad.net/bugs/1389223 this is the only new bug today I hit a couple of the older ones but they are already listed this is a vivid bug
[20:13] <davmor2> sil2100: that is a blocker on sanity tests too just so you know :)
[20:13] <cyphermox> davmor2: got the fix for that ready
[20:13] <davmor2> cyphermox: I saw
[20:13] <cyphermox> I think we're at the point of requesting a silo now :)
[20:13] <davmor2> woohoo
[20:13] <davmor2> :)
[20:14] <davmor2> Right I'm off
[20:14] <dobey> davmor2: we know you're off :)
[20:43] <ogra_> whee, an update \o/
[20:44] <ogra_> sil2100, i was pondering to also roll a new rootfs for the landed bits
[20:44] <sil2100> ogra_: I guess it makes sense, and it might be safe to have a new image now
[20:45] <ogra_> yeah, i was waiting for the terball first
[20:47] <ogra_> building
[20:54] <imgbot> [21:04] <cwayne-afk> ogra_: so I'm sorry but the version string isn't fixed still :(  I thought changing what system-image used as a version string would work, but apparently it's read directly from /custom/build_id, which I can't change as too many things depend on it
[21:04] <ogra_> cwayne, hmm, h
[21:04] <ogra_> k even
[21:05] <cwayne> unless we had system-settings read a different file, but i'd bet we'd have a hard time landing that
[21:05] <ogra_> yeah, not for rtm i guess
[21:05] <ogra_> but we have another open bug to display the channel ... perhaps thats combinable ;)
[21:06] <cwayne> sure :)
[21:06] <ogra_> thoush thats for post rtm as well
[21:06] <ogra_> sigh, browser and webapps crash a lot lately
[21:06]  * ogra_ didnt belive rsalveti when he said that today ... 
[21:08] <ChickenCutlass> ogra_: are they crashing or getting killed by OOM
[21:08] <ChickenCutlass> ogra_: I think the later
[21:08] <ogra_> ChickenCutlass, nope ... they are completely vanishing
[21:08] <ogra_> it hangs hard for a while and then just vanishes
[21:09] <ogra_> OOM should (theoretically) restart them via lifecycle mgmt
[21:17] <dobey> hanging for a while and then vanishing sounds more like a crash, with crash report being collected
[21:17] <dobey> i'd expect OOM to just vanish without a long wait
[21:24] <ogra_> https://errors.ubuntu.com/oops/1e65bb3a-6450-11e4-87c8-fa163e373683
[21:24] <ogra_> there we go
[21:25] <rsalveti> ogra_: do you know if iso tracker should be working for vivid images? trying to trigger a new one
[21:25] <rsalveti> it says rebuilding for a while, but nothing showing up at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/
[21:25] <ogra_> rsalveti, theoretically yes, practically better ask stgraber if he got that set up already
[21:25] <rsalveti> hm, probably not
[21:26] <ogra_> just use nusakan :P
[21:26] <rsalveti> let me trigger one via cmdline for now
[21:26] <ogra_> yeah
[21:26] <ogra_> it is not like we are stepping on each others toes with image builds all the time :)
[21:26] <rsalveti> yeah
[21:27] <ogra_> isotracker is fine if 20 peaople can/do build images
[21:34] <imgbot> [21:35] <ogra_> there you go :)
[21:36] <rsalveti> :-)
[21:39] <sil2100> Yay :)
[22:01] <sil2100> o/
[22:09] <jhodapp> ribru, can I get a vivid silo for line 58 please?
[22:10] <ribru> jhodapp: well line 58 says rtm on it...
[22:10] <jhodapp> ribru, oops, forgot to update it
[22:10] <ribru> jhodapp: no worries, just need to be clear
[22:11] <ribru> jhodapp: ok vivid 5
[22:11] <jhodapp> ribru, thanks
[22:11] <ribru> jhodapp: you're welcome
[22:22] <om26er_> kenvandine, Hi!
[22:49] <ogra_> rsalveti, bah, rtm failed too, but i386 has such a low build score that it will only start in 1h ... which is why my cmdline didnt return yet
[22:49] <rsalveti> ogra_: yeah, same for the vivid build I did
[22:50] <rsalveti> so yay, no builds for today
[22:53] <ogra_> yeah :(
[22:55]  * ogra_ gives up
[22:59] <ribru> ogra_: hey it sounds like you're not busy! ;-) can you ack some packaging? https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141104-0ubuntu1.diff
[23:57] <Saviq> ribru, hey, could you ↑?
[23:57] <Saviq> oh
[23:57] <Saviq> that was fast
[23:57] <Saviq> kgunn, ↑
[23:58] <Saviq> oops
[23:58] <Saviq> fixin'
[23:59] <Saviq> ribru, fixed ↑
[23:59] <Saviq> sry
[23:59] <ribru> hehe