[05:22] <didrocks> Mirv: hey, I'm around if any packaging review needed :)
[05:23] <Mirv> morning didrocks! upower in system-settings http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Settings/job/cu2d-settings-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings_0.1+13.10.20130813-0ubuntu1.diff + new mir packages in platform-api http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_platform-api_0.18.3+13.10.20130813-0ubunt
[05:24] <didrocks> Mirv: good morning! system-settings + mir: ack ;)
[05:24] <didrocks> Mirv: will you look at u-s-c and apps? we have 35 minutes to figure out what's wrong before next daily release :)
[05:25] <Mirv> platform, not mir :) mirslave seems to be depending on this.
[05:25] <didrocks> Mirv: sorry, I meant, platform :)
[05:25] <Mirv> unity-system-compositor:i386 Depends on libmirserver1
[05:25] <Mirv> so after platform gets them to NEW it'd be resolved?
[05:26] <Mirv> no actually different package
[05:26] <didrocks> Mirv: no need for NEW? (normally yeah, binary NEW, but we bypass that with daily releases)
[05:26] <didrocks> yeah, it's the AP tests that are failing
[05:26] <didrocks> like a lot of them
[05:26] <Mirv> the whole line is about strict version dependency unity-system-compositor:i386 Depends on libmirserver1 [ i386 ] < none -> 0.0.9+13.10.20130813-0ubuntu1 > ( libs ) (= 0.0.9+13.10.20130812.4-0ubuntu1) can't be satisfied!
[05:27] <Mirv> didrocks: platform has the new binary packages libubuntu-application-api-mirserver1 + libubuntu-application-api-mirclient1, but the whitelist was only for new source packages?
[05:28] <Mirv> apps on the other hand has gathered a lot of gstreamer/libav dependencies
[05:28] <didrocks> Mirv: oh yeah, the whitelist is only source packages
[05:28] <didrocks> Mirv: yeah, I just checked them, they seem ok (almost all in main). I just wonder about gstreamer0.10-ffmpeg
[05:28] <didrocks> Mirv: you know, ffmepg isn't really allowed everywhere
[05:29] <didrocks> Mirv: mind poking upstream about it? (not blocking on that, but let's do that preventively)
[05:29] <didrocks> and note in the "not blocking release part"
[05:29] <didrocks> Mirv: btw, not sure you noted, but you have the dependency chain before the +<package> in the logs
[05:29] <didrocks> like:
[05:29] <didrocks> /var/log/upstart/otto-setup.log:   Installing gstreamer0.10-ffmpeg as Depends of gallery-app
[05:29] <didrocks> /var/log/upstart/otto-setup.log:     Installing libavcodec53 as Depends of gstreamer0.10-ffmpeg
[05:29] <didrocks> /var/log/upstart/otto-setup.log:       Installing libavutil51 as Depends of libavcodec53
[05:30] <didrocks> it helps to know what's pulling the different components :)
[05:31] <Mirv> didrocks: ok, poking and noting, meanwhile https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/apps_gstreamer_libav/+merge/179848
[05:32] <didrocks> Mirv: +1, please merge :)
[05:32] <didrocks> Mirv: btw, if you have any idea on how we can make this list more easy to deal with…
[05:32] <didrocks> Mirv: it's the biggest part I'm not happy about, but I don't know how we can deal with that ensuring the same security in term of detecting transitions
[05:33] <didrocks> (and packages that we shouldn't dep on)
[05:33] <didrocks> the only piece of improvment I guess is to add to the dep list the stack we depend on package list as well
[05:34] <Mirv> yes it's a bit ugly. diff:s would be easier with newlines, but then it'd take even more space
[05:34] <Mirv> ok apps redeployed, shall I rerun check or let the next run handle it?
[05:37] <Mirv> didrocks: what do you think about these repeated unity7 AP problems? now I haven't seen the aborted AP sessions, but still differentiation. there was a successful (marked as such) check run during the night, and the diff against the new one is http://pastebin.ubuntu.com/5979939/
[05:37] <didrocks> Mirv: next run is in 20 minutes, I'm fine with waiting
[05:37] <Mirv> should we start the familiar-from-the-past manual testing on the differing tests and forcing publication if no problems found?
[05:37] <didrocks> Mirv: I guess we shouldn't do the manual testing anymore as long as there is no urgency
[05:37] <didrocks> Mirv: juste poke upstream + the manager
[05:38] <didrocks> and write in the list
[05:38] <Mirv> right. with the webapps now functioning, autopublishing should happen every now and then.
[05:38] <didrocks> Mirv: we have enough to do TBH without adding the manual testing :)
[05:38] <didrocks> yeah ;)
[05:38] <didrocks> Mirv: can you start with the list of mirslaves unity AP tests failing?
[05:38] <didrocks> Mirv: I think that list is urgent
[05:38] <didrocks> (because mir and platform-api are blocked in -proposed as long as those are not addressed)
[05:41] <Mirv> didrocks: I don't see the failing AP tests? just the dependency problem.
[05:41] <Mirv> http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/950/label=autopilot-ati/console etc
[05:42] <didrocks> Mirv: argh
[05:42] <didrocks> Mirv: I've been trapped by the jenkins ui
[05:42] <Mirv> there was a new mir snapshot that go tin two hours ago
[05:42] <didrocks> I guess it's a sign for coffee needed :p
[05:42] <Mirv> didrocks: hehe :) that's not a miracle, the ui is what it is
[05:42] <didrocks> Mirv: don't tell me :)
[05:43] <Mirv> I'd think the dependency problem would resolve itself now that the new mir is built
[05:43] <didrocks> Mirv: it's interesting in fact
[05:43] <didrocks> mirslaves deps on mir
[05:44] <didrocks> so normally mir finished before mirslaves start
[05:44] <didrocks> and is published
[05:44] <didrocks> Mirv: maybe we can quickly run mirslaves?
[05:44] <didrocks> (the tests are taking 10 minutes, should just be before the tick)
[05:44] <Mirv> sure we can, just foo run?
[05:45] <didrocks> yeah
[05:45] <Mirv> ok, it's running
[05:45] <didrocks> thanks Mirv :)
[05:45] <didrocks> I propose we trademark the "foo run" :)
[05:46] <Mirv> you're welcome
[05:46] <didrocks> ok, passed the installation step, I think we had a publisher mismatch possibly
[05:46] <didrocks> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/lastSuccessfulBuild/console
[05:47] <didrocks> as you can see mir is run in the first pass
[05:47] <didrocks> and mirslave in the second
[05:47] <didrocks> __________ divide dependencies
[05:47] <didrocks> (there is no more manual scheduling)
[06:43] <TheMuso> p/quit
[07:28] <tjaalton> i guess we're not going to see g-c-c/g-s-d 3.8.x in saucy?
[07:28] <didrocks> tjaalton: I think it's a question for seb128 (he will be around late)
[07:29] <tjaalton> didrocks: ok
[07:32] <darkxst> tjaalton, g-s-d yes, g-c-c probably not
[07:33] <tjaalton> darkxst: alright
[07:33] <darkxst> its still blocked by the ibus/keyboard-indicator stuff though
[07:40] <tjaalton> hmm I think the new wacom stuff needs g-c-c 3.8 too, but oh well
[07:48] <Mirv> didrocks: apps would be ready with the ffmpeg packaging addition http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_gallery-app_0.0.67+13.10.20130813.1-0ubuntu1.diff
[07:48] <tkamppeter_> top
[07:49] <didrocks> Mirv: ok, +1 for publishing, did you ping upstream? (cc Pat maybe?)
[07:49] <didrocks> Mirv: will start on qt3d & co in a few minutes
[07:49] <Mirv> didrocks: just did as osomon appeared to be online
[07:49] <didrocks> great :)
[07:50] <Mirv> didrocks: there's something going on at platform-api, ../mir/mir.project* doesn't exist http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-1.1prepare-platform-api/226/console
[07:51] <didrocks> Mirv: yeah, I changed the job so that it's starting to be green instead of yellow
[07:52] <didrocks> Mirv: in fact, it means that there is nothing to release (see the logs before)
[07:52] <sil2100> :)
[07:52] <didrocks> there is force_rebuild set
[07:52] <didrocks> but the condition "having a newest Mir" isn't met
[07:52] <didrocks> so no need for rebuilding
[07:52] <didrocks> good morning sil2100
[07:52] <didrocks> it should just be green in that case
[07:52] <didrocks> let me relaunch, I fixed it
[07:52] <sil2100> Good morning everyone!
[07:52] <Mirv> didrocks: ah, that kind of dependency
[07:53] <Mirv> hello sil2100
[07:53] <didrocks> Mirv: exactly, this is to avoid rebuilding platform-api and unity-system-compositor if it's not needed
[07:53] <didrocks> Mirv: should be green now :)
[07:54] <Mirv> it's green now. ok, just mirslave and unity tests running, all others green
[07:54] <didrocks> sweet!
[07:54] <sil2100> Mirv: so I see this daily-release run is ready? :)
[07:55] <Mirv> sil2100: two runs already :)
[07:55] <sil2100> Excellent!
[07:55] <sil2100> Then I'll deal with the next one then
[07:55] <didrocks> yeah, it's nice when it's releasing quickly, there is not so much ;)
[07:55] <didrocks> sil2100: wait for unity/mirslave to finish
[07:56] <sil2100> didrocks: there is still time, hope unity will manage!
[07:56] <didrocks> yeah and mirslave
[07:56] <didrocks> last ran blocked on ati :/
[07:56] <didrocks> (even with latest compiz)
[07:59] <darkxst> tjaalton, still hoping to get g-c-c 3.8 in, but really not much time left.
[07:59] <sil2100> ;/
[08:01] <sil2100> didrocks: that's too bad then... but at least we're no longer running an 'external application from another package' from inside of compiz, which I always thought was a bit strange
[08:01] <tjaalton> darkxst: same blocker?
[08:01] <didrocks> sil2100: right, it's not that bad, as we don't have unity-2d anymore anyway
[08:01] <didrocks> sil2100: I gave RAOF access this morning, he's preparing a new version of Mir/u-s-c/Xmir with intrumentation
[08:02] <darkxst> tjaalton, yes, but there is a bunch of additional minor issues, that I can't fix since the desktop team hasnt even looked at it yet to decide what they want
[08:02] <darkxst> I did fix all the major blockers
[08:02] <sil2100> didrocks: \o/ would be nice to finally know what's up with mir and the ati machine
[08:02] <didrocks> yeah ;)
[08:02] <sil2100> Strange that no one encountered it locally though
[08:06] <tjaalton> darkxst: that's cool
[08:29] <sil2100> Mirv, didrocks: unity testing finished \o/
[08:29] <didrocks> sil2100: great \o/
[08:29] <sil2100> ATI had a bit too many failures it seems, I even saw it was a bit slower then the others - probably some timeouts or hangups
[08:29] <didrocks> (unity-system-compositor passed)
[08:30] <sil2100> didrocks: \o/
[08:30] <didrocks> in the way, unityshell was loaded this time :)
[08:30] <sil2100> Ok, so we're clear for the next run
[08:30] <didrocks> sil2100: it's intel rather: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-2.2check/328/console
[08:30] <didrocks> sil2100: jibel stops at the first card which doesn't pass
[08:30] <didrocks> (too many regressions for intel)
[08:31] <sil2100> didrocks: oh, but I checked here: http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/956/testReport/
[08:31] <didrocks> sil2100: depending on what you want, if you poke upstream to get the number lower (we need that anyway, 17 is way too much)
[08:31] <sil2100> didrocks: but right
[08:31] <didrocks> we can force publishing
[08:31] <didrocks> it's your pick
[08:31] <didrocks> but in any case, ensure that you or Mirv track upstream to get the number of flacky tests down
[08:31] <sil2100> didrocks: ok, but if I poke them, you think it's ok to force publishing?
[08:32] <didrocks> sil2100: yeah, I think that's fine for that time
[08:32] <didrocks> (to not having another unity rebuild for nothing)
[08:32] <sil2100> didrocks: btw. in the end, in such a case how am I supposed to force publishing again ;) ? I mean, do I have to do it from the head job somehow?
[08:32] <sil2100> didrocks: since I remember yesterday something with running the publish job manually was wrong or something?
[08:33] <sil2100> (it anyway doesn't propagate properly to the head job)
[08:33] <sil2100> I would like a head job flag such as 'do only publishing, but don't force the publication yet'
[08:33] <didrocks> sil2100: so, run it on the head
[08:33] <sil2100> So that I can see if the publish is yellow or not
[08:33] <didrocks> with AUTO_PUBLICATION on
[08:33] <didrocks> not FORCE_PUBLICATION
[08:33] <sil2100> Oh :D
[08:34] <sil2100> : D
[08:34] <sil2100> didrocks: it seems you were reading my mind and prepared everything beforehand!
[08:34] <sil2100> didrocks: with foo, yes?
[08:34] <didrocks> sil2100: ahah, I try to prepare all cases where we need to manually unblock things ;)
[08:34] <didrocks> sil2100: doesn't matter :p
[08:36] <didrocks> ah, we are in that case
[08:36] <didrocks> "the previous run already failed, can't republish automatically the stack. Report to that run to get more info."
[08:36] <sil2100> hmm
[08:36] <didrocks> let me try to think if that's really needed, because it was a double shield protection
[08:37] <didrocks> sil2100: should we define for that trick to be foo + AUTO_PUBLICATION?
[08:38] <sil2100> didrocks: you mean, that it would still run publish even if the previous run failed when it's a special case of AUTO_PUBLICATION and foo as the project to build?
[08:38] <didrocks> sil2100: right
[08:38] <didrocks> I doubt we need another flag for that
[08:39] <sil2100> didrocks: fine with me, but it would be nice to document it somewhere
[08:39] <sil2100> didrocks: quirks of jenkins daily-release ;)
[08:39] <didrocks> sil2100: we need to have that controller out of jenkins
[08:39] <didrocks> sil2100: normally, we should never ever have to do that btw ;)
[08:41] <didrocks> sil2100: ok, redeployed, do you mind trying that?
[08:41] <sil2100> didrocks: trying!
[08:42] <sil2100> didrocks: seems like the same
[08:42] <sil2100> didrocks: "the previous run already failed, can't republish automatically the stack. Report to that run to get more info."
[08:42] <didrocks> interesting
[08:43] <didrocks> and rebuild_only is set to foo…
[08:43] <didrocks> sil2100: sorry, I'm *really* stupid
[08:44] <didrocks> esil2100: should be better now, please try again. Btw, I added another message to tell to use "foo" to force a normal manual publication
[08:45] <didrocks> one day, I'll learn the difference between = and !=
[08:45] <sil2100> Trying ;)
[08:45] <sil2100> hehe, typos happen!
[08:45] <sil2100> didrocks: it seems to be working \o/
[08:46] <didrocks> great ;)
[08:46] <didrocks> sil2100: the message will now be FYI/
[08:46] <didrocks> +      echo "ERROR: The previous run already failed, can't republish automatically the stack. Report to that run to get more info."
[08:46] <didrocks> +      echo "If you wanted to try/force a manual regular publication, you can use AUTO_PUBLICATION and set REBUILD_ONLY to foo to bypass this safeguard."
[08:46] <didrocks> sil2100: sounds legit? ^
[08:46] <didrocks> we will need to redeploy all stacks to get that in production though
[08:46] <sil2100> didrocks: sounds good indeed!
[08:47] <sil2100> We still have like 13 minutes to the next run to start, right?
[08:47] <didrocks> sil2100: Mirv: ZOMG it's all green! quick quick, tape a picture: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/
[08:47] <didrocks> asac: you as well, we have prooves! :)
[08:47] <sil2100> OHSHIT
[08:47] <didrocks> sil2100: 1h13
[08:47] <didrocks> sil2100: meanwhile, maybe you can start lurking as well on the Raring/SRU side?
[08:47] <sil2100> didrocks: ah! I think I forgot about the UTC offset ;)
[08:47] <didrocks> (seeing if stuff are stuck in proposed)
[08:48] <didrocks> sil2100: heh, yeah, we are +2 ;)
[08:48] <sil2100> didrocks: ok!
[08:48] <didrocks> that will be an interesting challenge with the UTC offset
[08:48] <didrocks> I set the times so that every run can be looked at
[08:48] <didrocks> so, I think we may need to move the time with UTC change, or just not caring of the delta
[08:49] <didrocks> let's see
[08:50] <asac> didrocks: nice!!!!!!
[08:51] <Mirv> didrocks: !!!
[08:51] <asac> well done
[08:51] <Mirv> I'll take a screenshot for sure
[08:51] <didrocks> :)
[08:51] <asac> didrocks: what about phone testing ? guess thats next?
[08:51] <asac> or is that already in those greens?
[08:52] <didrocks> asac: no, it's not
[08:52] <asac> right
[08:52] <didrocks> asac: I'm still on a huge backlog, as told in the meeting, I'll need someone in the QA team to help
[08:53] <asac> didrocks: do they know how otto is done etc.?
[08:53] <didrocks> Mirv is desperatly waiting on me for Qt for instance :)
[08:53] <didrocks> asac: I'm unsure of it
[08:53] <asac> didrocks: could we try to use utah for the provisioning part? what special requirements do we have for daily-release?
[08:53] <asac> use/reuse
[08:54] <didrocks> asac: jibel transmitted the requirements to the UTAH team
[08:54] <didrocks> which are basically:
[08:54] <didrocks> - be able to specify a ppa
[08:54] <didrocks> - be able to have a list of packages we filter on (like, if we install more than this list of packages, bails out and show a diff)
[08:54] <didrocks> - have a switch to disable this previous check, for multiple runs
[08:55] <didrocks> - have a switch to dist-upgrade from the whole ppa
[08:55] <didrocks> - have a snapshot capability that we can transmit usptream to rerun that locally
[08:55] <didrocks> - and have a way to ssh to the machine while it's running
[08:55] <didrocks> - oh also: if we kill the jenkins job, the test should be aborted
[08:55] <didrocks> and be able to run the next one
[08:56] <didrocks> - and have the timeout working (it regressed a lot in the past)
[08:56] <didrocks> this is in addition to have a stable runs of course
[08:56] <asac> didrocks: how often do you use ssh?
[08:56] <didrocks> asac: almost daily
[08:56] <didrocks> when upstream need to investigate live
[08:56] <didrocks> because they can't reproduce locally
[08:57] <asac> interesting
[08:57] <didrocks> RAOF for instance was connected this morning for Mir
[08:57] <asac> didrocks: how long do we leave an instance live?
[08:57] <didrocks> of course, when we ssh, the machine should be temporarly deprovisionning
[08:57] <didrocks> asac: 2h
[08:57] <asac> after it has failed
[08:57] <asac> 2h?
[08:57] <didrocks> ah
[08:57] <didrocks> 2h is the timeout
[08:57] <didrocks> if the machine is stuck
[08:57] <asac> or is is a special job for "hacking"?
[08:57] <didrocks> then, we have snapshot
[08:57] <didrocks> and we can restore any snapshot from the past week
[08:58] <didrocks> which will restore the same environment when you left
[08:58] <asac> didrocks: so you basically say we need an lxc solution?
[08:58] <didrocks> asac: not sure, I guess with a VM this will be possible as well
[08:58] <asac> sure
[08:58] <asac> but right now we dont have VM
[08:58] <asac> and we dont have lxc
[08:58] <asac> so not sure if your requirements are realisitic short term
[08:58] <asac> maybe i am wrong about lxc
[08:59] <asac> lets see how stuff is going on the emulator front
[08:59] <asac> xnox: ^^ :)
[08:59] <didrocks> asac: can we have at least the UTAH team looking at them and giving an answer?
[08:59] <asac> you could safe the world
[08:59] <didrocks> yeah ;)
[08:59] <didrocks> we all rely on xnox!
[08:59] <didrocks> asac: but that's what we need daily basically and from what I know, it's the gap we missed with UTAH in the early days
[08:59] <asac> didrocks: no... utah team are not able to solve problems like "ouch we have no virtualization solution on our phone"
[09:00] <asac> thats just unrealistic. the experts about that are elsewhere
[09:00] <didrocks> asac: I meant for the rest, like ppa, filtering package list and so on
[09:00] <didrocks> aborting when the jenkins job aborts
[09:00] <asac> didrocks: so would a solution with just the "realisitic" things be useful?
[09:00] <didrocks> asac: I think this will block everything
[09:01] <didrocks> like if upstream can't debug what's wrong live… we'll be way slower to fix issues
[09:01] <asac> i know
[09:01] <asac> so you say we shouldn't even try to get anythng that isnt virtualized there
[09:01] <didrocks> this is what happened with unity during the natty cycle
[09:01] <didrocks> I think so
[09:01] <asac> otoh we have the problems then in the image
[09:01] <asac> which slows stuff even more down
[09:01] <asac> because the distance from image to developer is even greater and the disconnect as well
[09:01] <didrocks> wdym?
[09:02] <didrocks> with the virtualization?
[09:02] <asac> didrocks: people have problems fixing bugs that we see on real phones
[09:02] <asac> saying we slow down development because we block those issues at daily-release stage
[09:02] <asac> is probably not right
[09:02] <asac> right now we just dont see lots of problems and hence dont care
[09:02] <asac> anyway
[09:03] <asac> lets wait for xnox to bring us good news
[09:03] <didrocks> yeah, let's see
[09:03] <xnox> didrocks: asac: i'm at debconf this week. I will come back to above, when available.
[09:04] <xnox> didrocks: asac: per-se lxc doesn't provide snapshots, the emulator does copy/snapshot the virtual disks to provide a snapshot, but there is little or no cost starting a fresh emulator each time.
[09:05] <didrocks> xnox: asac: right, we do emulate snapshot ourselves
[09:05] <didrocks> providing a tar that people can restart
[09:06] <xnox> didrocks: asac: i didn't bring up unflipped yet to the point of working/booting the gui. And not sure how much flipped bring up will need, since i don't think goldfish kernel has lxc ported/enabled.
[09:07] <didrocks> asac: I think on the phone, we won't have the snapshot at first, so that can be delayed, but at least, the same configuration for developers will help (and a way to ssh to the machines/unprovision-reprovision)
[09:30] <didrocks> sil2100: latest change redeployed everywhere
[09:31] <sil2100> didrocks: \o/ right on time!
[09:31] <didrocks> heh ;)
[09:39] <sil2100> Oh! No seb128!
[09:45] <didrocks> sil2100: not today
[09:45] <didrocks> he will be connected at 5pm approx
[09:45] <sil2100> ACK
[09:46] <sil2100> Since I have a g-c-c-u question from raring
[09:47] <sil2100> g-c-c-u is stuck in -proposed, not sure what to do exactly, as there is one bug fixed there but not fixed 'completely' - and it's arguable if we should release it like that or not
[09:48] <didrocks> ah ok, let's wait for him maybe :)
[09:59] <sil2100> !
[09:59] <sil2100> Hello seb128
[09:59] <seb128> sil2100, hey, how are you?
[10:00] <didrocks> seb128: already arrived?
[10:00] <seb128> didrocks, no, in Zurich
[10:00] <didrocks> ah ok :)
[10:00] <didrocks> seb128: quick quick, 2 minutes before next run: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/
[10:01] <seb128> didrocks, something went wrong with the red color
[10:01] <seb128> it went missing
[10:01] <seb128> ?
[10:01] <didrocks> seb128: right, we changed jenkins' assets :)
[10:02] <seb128> ;-)
[10:02] <seb128> nice one indeed
[10:02] <seb128> did you take a screenshot to have a proof it happened? ;-)
[10:02] <didrocks> apparently, we are multiple to have taken some :)
[10:02] <didrocks> seb128: how is the travel btw? everything on time?
[10:03] <didrocks> nice that you have Wifi :)
[10:03] <seb128> didrocks, yeah, everything is just fine, first flight was around 40min and second one is around 1h
[10:03] <seb128> Zurich airport is nice for that
[10:04] <seb128> they have one hour free wifi available from pretty much anywhere in the airport
[10:04] <didrocks> great ;)
[10:05] <sil2100> Awesome :)
[10:21] <sil2100> didrocks: hm, strangeness! Webapps is red because of the check job, which didn't even run
[10:21] <sil2100> ERROR: Build aborted. No projects to trigger. Check your configuration!
[10:21] <sil2100> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/WebApps/job/cu2d-webapp-head-2.2check/58/console
[10:21] <didrocks> sil2100: right, I'm looking at that just now
[10:21] <didrocks> sil2100: I wonder why when redeploying, commenting the check wasn't enough
[10:21] <didrocks> sil2100: you know… as we disabled the check for it
[10:21] <didrocks> it shouldn't even have been ran
[10:21] <didrocks> (I only wanted to comment the minimal part)
[10:22] <sil2100> hmm
[10:22] <didrocks> sil2100: ok, commenting everything then
[10:22] <didrocks> (redeploying and rerunning)
[10:23] <sil2100> didrocks: but this will mean the need for redeployment of everything again? Watch out for other projects that might be running!
[10:23] <didrocks> sil2100: no no, only webapps is in that case
[10:23] <seb128> ok, boarding time, back online in some hours
[10:23] <didrocks>     if 'extracheck' in stack and stack['extracheck']:
[10:24] <didrocks> seb128: safe travel
[10:24] <seb128> didrocks, thanks
[10:24] <didrocks> sil2100: any idea why even with extracheck: False, it's trying to get it?
[10:24] <didrocks> oh maybe yaml want a space before #
[10:24] <didrocks> it's extracheck: False#autopilot-saucy-daily_release
[10:25] <sil2100> didrocks: could be, I never tried doing that without a whitespace before #
[10:26] <didrocks> sil2100: yeah, that was it :)
[10:26]  * didrocks reruns webapp
[10:26] <didrocks> sil2100: ah, the -check job is off the hook now :)
[10:27] <didrocks> sil2100: so, I just delete the -check job for now, ok?
[10:27] <sil2100> btw. why was the check job for webapps disabled?
[10:27] <didrocks> sil2100: so that the "view" can be green
[10:27] <sil2100> Ok
[10:28] <didrocks> sil2100: because nobody is fixing unity_qml_webapps
[10:28] <didrocks> sil2100: so it's disabled for dailies
[10:28] <sil2100> didrocks: ;/
[10:28] <didrocks> we gave them a week
[10:36] <czajkowski> Good morning :)
[10:37] <didrocks> hey czajkowski
[10:38] <mlankhorst> heya
[10:38] <czajkowski> so running saucy and loving it however what ever updates I did last night is leading to much brokenness this morning., :(
[10:38] <czajkowski> https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1205896
[10:38] <ubot2`> czajkowski: Error: launchpad bug 1205896 not found
[10:38] <czajkowski> https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1211718
[10:38] <ubot2`> czajkowski: Error: launchpad bug 1211718 not found
[10:38] <czajkowski> all happen on start up
[10:38] <czajkowski> :/
[10:39] <didrocks> czajkowski: I would blame new glib, seeing the stacktrace. Mind pinging seb128 when he's back?
[10:39] <didrocks> desrt: or maybe you can have a look dude? ^
[10:40] <didrocks> (the second one is not retraced yet)
[10:40]  * didrocks goes for a run, see you later
[10:41] <czajkowski> didrocks: cheers
[10:53] <czajkowski> seb128 is for once not here :(
[11:07] <sil2100> didrocks: there seems to be an extra package missing in platform-api
[11:07] <sil2100> didrocks: let me check that and fix it
[11:20] <desrt> didrocks: i get 404s for those pages?
[11:23] <czajkowski> desrt: let me add you to them
[11:23] <czajkowski> they're private bugs
[11:24] <czajkowski> desrt: what is your LP id ?
[11:25] <sil2100> didrocks: once you're back: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_hardware-api_to_platform/+merge/179900
[11:25] <sil2100> I jump out for lunch and dentist
[11:26] <desrt> czajkowski: desrt
[11:27] <czajkowski> done :)
[11:50] <didrocks> sil2100: approved
[11:56] <didrocks> sil2100: rerun and approving the packaging changes I already approved :)
[12:16] <sil2100> ;)
[12:16] <sil2100> didrocks: ok
[12:19] <popey> hmm, bug 1189850 says it's fixed but I'm still seeing lots of corruption on Intel on saucy
[12:19] <ubot2`> Launchpad bug 1189850 in xserver-xorg-video-intel (Ubuntu) "(Needs a 3.10.3 kernel) saucy/raring has frequent image corruption (intel, sna)" [High,Fix released] https://launchpad.net/bugs/1189850
[12:20] <popey> ahh, "needs a 3.10.3 kernel"?
[12:29] <desrt> czajkowski: these two traces don't look particularly related
[12:30] <desrt> #25 0x00007f574a3e2d9b in dconf_settings_backend_write (backend=0x164c9d0, key=0x200c5d0 "/org/gnome/eog/view/background-color", value=0x1c13690, origin_tag=0x0) at dconfsettingsbackend.c:79
[12:30] <desrt> uh
[12:32] <desrt> ya... that's a bug
[12:33] <desrt> EogScrollView is hooking up bidirectional gsettings bindings to _itself_ during _construction_
[12:38] <czajkowski> ah well at least it makes sense to you :)
[12:38] <desrt> although i'm sure that this is definitely wrong, i wonder if there is something else that is wrong as well
[12:39] <desrt> simple fix: changing G_SETTINGS_BIND_DEFAULT, to G_SETTINGS_BIND_GET on line 2561 of eog-scrolled-view.c
[12:39] <desrt> but there may be another bug hiding out here
[12:41] <tkamppeter> I have removed the binary package ghostscript-cups and have moved the contents into cups-filters, is it OK if cups-filters has breaks/conflicts/replaces: ghostscript-cups? Or do I need a ghostscript-cups transitional package (provided by which source package and what should it depend on?). How can I make an update uninstall the current ghostscript-cups when cups-filters 1.0.36 gets installed?
[12:41] <popey> any intel users seeing desktop lockups as per bug 1211754  ?
[12:41] <ubot2`> Launchpad bug 1211754 in unity (Ubuntu) "Desktop freezes for some seconds then continues" [Undecided,New] https://launchpad.net/bugs/1211754
[12:45] <desrt> hmmmm.  may be some interesting damage here caused by our recent priv shuffling
[12:50] <desrt> czajkowski: are you reliably able to reproduce this eog problem?
[12:50] <Mirv> popey: I've seen that, ie compiz/unity crash or something, although not this week yet
[12:51] <popey> Mirv: I get it daily, multiple times a day
[12:51] <Mirv> maybe it's the xmir/unity-system-compositor magic that fixed it for me :)
[12:51] <Mirv> popey: I guess it was no apport triggering or anything?
[12:51] <popey> I'm running that
[12:51] <popey> nothing in /var/crash Mirv
[12:52] <Mirv> yeah that was annoying to me as well
[12:53] <czajkowski> desrt: it's happening on start up for me not sure what it's doing for dholbach
[12:53] <czajkowski> I've to run for interviews for the next hour but back then if I can help
[12:59] <didrocks> Mirv: ok, finally your turn
[12:59] <didrocks> phew :)
[13:01] <popey> Mirv: interestingly after the crash, I get visible corroption on the screen
[13:01] <popey> indicators blinking at me
[13:01] <didrocks> popey: it's the new blink functionality of indicators :)
[13:01] <popey> \o/
[13:07] <didrocks> Mirv: on http://pastebin.ubuntu.com/5976449/, I'm happy about the change, but I would like to have something else than just a "forwarded: no"
[13:07] <didrocks> like why can't it be forwarded? why would we care the delta forever (when this file change)
[13:11] <didrocks> Mirv: qt3d sponsored!
[13:12] <Mirv> didrocks: I tried... it can be forwarded, I just would like for the person who can explain the problem best to describe it to upstream
[13:12] <didrocks> Mirv: agreed, so not sponsoring until this is settled
[13:12] <didrocks> Mirv: it's the only way of pressure we have :)
[13:13] <didrocks> but the guy writing it should forward it
[13:14] <Mirv> thomi: ^ could you file an upstream bug / feature wish about the testability environment variable that could be then referred to in the patch, and then a codereview request to fix that bug? I can help.
[13:15] <Mirv> in the e-mail from Aug 7th there was the guide to submitting patches as well
[13:19] <popey> ok, desktop locking up every 10 mins is getting old now.
[13:20] <tkamppeter> Anyone can help me with a packaging issue?
[13:20] <didrocks> tkamppeter: just ask and people who will have an idea will maybe answer :)
[13:21] <tkamppeter> I have removed the binary package ghostscript-cups and have moved the contents into cups-filters, is it OK if cups-filters has breaks/conflicts/replaces: ghostscript-cups? Or do I need a ghostscript-cups transitional package (provided by which source package and what should it depend on?). How can I make an update uninstall the current ghostscript-cups when cups-filters 1.0.36 gets installed?
[13:21] <didrocks> tkamppeter: ok, so ghostscript-cups will be empty and should be removed, right?
[13:23] <didrocks> (and nothing is build-depending on ghostscript-cups?)
[13:26] <tkamppeter> didrocks, yes
[13:26] <tkamppeter> didrocks, there are some depends which I can easily change before FF.
[13:27] <didrocks> tkamppeter: if you don't have any build-depends, you just need to use a conflicts/provides/replaces
[13:27] <tkamppeter> didrocks, there are probably no build-depends.
[13:27] <didrocks> that will remove the old package throught apt and will install the new one instead
[13:28] <didrocks> ensure that what is depending on ghostscript-cups or seeded directly pull cups-filters then
[13:28] <didrocks> (so that's in on the CD by default)
[13:28] <tkamppeter> didrocks, so no ttransitional packages, the binary package cups-filters which will hold the files which formerly came in ghostscript-cups will simply conflicts/provides/replaces ghostscript-cups?
[13:28] <didrocks> tkamppeter: exactly, no transition packages and right, this relationship between the 2 packages will do the trick
[13:29] <didrocks> the only thing you need to look at is how ghostscript-cups was pulled on the CD
[13:29] <didrocks> you need at least one dep to pull cups-filters
[13:29] <didrocks> or changing the seed to list cups-filters instead of ghostscript-cups
[13:30] <tkamppeter> didrocks, as cups-filters will provide ghostscript-cups, will a Depends: ghostscript-cups in another package pull cups-filters then?
[13:30] <didrocks> tkamppeter: no, because it only a "provides"
[13:30] <didrocks> and you can have more than one provides
[13:30] <didrocks> so you can't directly install a provides
[13:30] <didrocks> but
[13:31] <didrocks> if you have cups-filters installed on your system
[13:31] <didrocks> anything that depends on ghostscript-cups will have the dependency fulfilled (because cups-filters provides ghostscript-cups)
[13:31] <didrocks> so, the only question is "how ghostscript-cups was pulled in the CD?"
[13:31] <didrocks> and you need one thing to pull cups-filters on the CD
[13:32] <tkamppeter> didrocks, cups-filters gets already pulled in by cups, and ghostscript-cups is not seeded, it is only puilled in by several printer driver packages (which I wuill change to pull cups-filters).
[13:32] <didrocks> tkamppeter: ah ok, so if cups-filters was already pulled in, no worry :)
[13:32] <didrocks> the dependency will be set
[13:33] <didrocks> just add this conflicts/provides/replaces and you're fine :)
[13:33] <tkamppeter> didrocks, thanks.
[13:33] <didrocks> tkamppeter: yw!
[13:35] <didrocks> Mirv: should we mark the Qt5 saucy snapshot module as DONE?
[13:36] <Mirv> didrocks: I tend to add more and more stuff to it, but the qtlocation in there could be separated into its own item now
[13:36] <didrocks> Mirv: yeah, let's do that :)
[13:36] <Mirv> ok
[13:36] <didrocks> thanks Mirv
[14:01] <sabdfl> checking
[14:01] <sabdfl> gack
[14:01] <sabdfl> ww
[14:10] <seb128> hey
[14:12] <didrocks> seb128: had a good end of travel?
[14:13] <seb128> didrocks, yeah, perfect, thanks
[14:24] <sil2100> seb128: hi! You on stable grounds now?
[14:24] <seb128> sil2100, hey, yeah, I'm at dholbach's
[14:25] <sil2100> Awesome! btw. you working today or do you have a free day? ;)
[14:25] <didrocks> seb128: so, you are going to watch cat's picture the whole afternoon now?
[14:25] <seb128> didrocks, Daniel is rather a dog guy :p
[14:25]  * seb128 has a dog sleep just next to his shoes
[14:26] <didrocks> oh, he lied to me on his favorite activity!
[14:26] <seb128> sleeping*
[14:26] <didrocks> ahah :)
[14:26] <didrocks> I hope you don't call Daniel a dog :p
[14:26] <seb128> oh, maybe he likes to watch cat's pictures to forget about the dog ;-)
[14:26] <seb128> haha
[14:27] <didrocks> sil2100: Mirv: so FYI, Mir dailies are blocked now
[14:27] <didrocks> (and mirslaves as well)
[14:27] <didrocks> until the ATI issue is fixed
[14:27] <didrocks> sil2100: I set enabled: False on magners config
[14:27] <didrocks> (you can see it with bzr diff)
[14:27] <didrocks> sil2100: if the issue is fixed, bzr revert will just reenable the stacks
[14:27] <didrocks> making sense?
[14:27] <didrocks> (yeah, it's easier than removing the schedule and redeploying, right? p:)
[14:29] <sil2100> huh?
[14:30] <sil2100> But isn't it *sometimes* working ? ;)
[14:30] <didrocks> sil2100: right, but let's ensure it's getting fixed now
[14:30] <sil2100> didrocks: agreed ;)
[14:30] <sil2100> didrocks: since it's breaking the machine basically, so every time it happens we have a problem with resetting the machine
[14:30] <sil2100> Which is blocking everything
[14:31] <didrocks> olli_: FYI: Mir/Mirslave not daily releasing anymore: DONE (in fact, was done during the meeting, just a 30s thing :p)
[14:31] <didrocks> sil2100: exactly
[14:58] <asac> didrocks: will this "in manual mode" show up as a state here: http://reports.qa.ubuntu.com/daily/ ?
[14:58] <asac> mir/mirslave
[14:58] <didrocks> asac: I think it's a question for fginther, but I think it won't
[14:58] <didrocks> asac: the information isn't in jenkins
[14:58] <didrocks> asac: but we should see that the stack isn't run for a long time
[14:58] <asac> right
[14:58] <asac> thansk
[14:59] <didrocks> asac: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=3 is updated though
[15:00] <asac> kk
[15:12] <fginther> didrocks, the mir/mirslave jobs will stop running?
[15:14] <didrocks> fginther: right
[15:16] <fginther> didrocks, asac, in that case the stack will appear as published, but the publish date will not be updated until the job is re-enabled
[15:21] <sil2100> didrocks: opinion! What do you think would be the better option for media-scanner naming: ubuntu-mediascanner or unity-mediascanner ? Do you know if there is a specific convention in distro for that where we should use ubuntu- and where soemthing else?
[15:24] <didrocks> sil2100: TBH, we had that discussion already, and it seems we want to name everything without prepending ubuntu-
[15:24] <didrocks> is media-scanner already taken?
[15:25] <didrocks> asac: dailies are so green that I want to cry honestly :)
[15:25] <didrocks> (but TBH, not a lot is coming in)
[15:26] <didrocks> we only released 27 packages from the past 24 hours
[15:30] <seb128> hey
[15:30] <seb128> it's meeting time:
[15:30] <seb128> !
[15:31] <qengho> Salut.
[15:31] <seb128> hey qengho
[15:32] <seb128> qengho, mlankhorst, tkamppeter, attente, (desrt?), larsu: hey, it's meeting time
[15:32] <qengho> - Wrote first 90% of new GRIT/gettext migration tool to support Launchpad translations in Chromium-browser.  This clears up (again) the reason we didn't adopt Cr as default in 12.04.
[15:32] <qengho> +-- Imported latest templates and strings in Launchpad.
[15:32] <qengho> - Discussing plugin behavior with businesspeople.
[15:32] <qengho> - Preparing 28.0.1500.95 for more testing and then #security.
[15:32] <qengho> EOL
[15:33] <seb128> qengho, thanks
[15:33] <seb128> mlankhorst, hey
[15:35] <seb128> no mlankhorst?
[15:35] <seb128> Laney, hey, here or busy at Debconf?
[15:37] <seb128> ok, busy I guess...
[15:37] <seb128> tkamppeter, hey
[15:38] <jbicha> seb128: maybe no one's here? ;)
[15:38] <seb128> seems so....
[15:38] <seb128> attente, hey
[15:38] <larsu> seb128: attente is on vacation I think
[15:38] <seb128> jbicha, but some people are on holidays, some are at Debconf
[15:38] <seb128> ok
[15:38] <seb128> larsu, your turn :p
[15:38] <seb128> going to be a quick meeting ;-)
[15:39] <larsu> - last days of GUADEC, had some nice talks with people, but mostly working during the hackfest days
[15:39] <larsu> - MR UnityThemeIconProvider to ubuntu-ui-toolkit (slightly more featureful version of the one in unitymenumodel). It will help to get rid of the gicon provider which is only causing trouble. Not merged because there are no tests, Wellark agreed to write some because I'm busy (and on vacation soon)
[15:39] <larsu> - indicator-messages: consolidate branches. WIP but everybody wants it to land (phone-app is blocked on it)
[15:39] <larsu> - wrote a proposal for Saviq and MacSlow on how to handle system dialogs
[15:39] <larsu> - and general explaining-how-icons-should-be-done in unity8
[15:39] <larsu> eof
[15:40] <tkamppeter> sorry, I am also here
[15:40] <tkamppeter>  - Release of cups-filters 1.0.36
[15:40] <tkamppeter>  - cups-filters upstream work
[15:40] <tkamppeter>  - Testing for fix of Onboard right-click emulation bug
[15:40] <tkamppeter>  - Bugs
[15:40] <tkamppeter>  - GSoC
[15:40] <tkamppeter>  - Tried out webbrowser-app on standard Unity desktop on Thinkpad Twist.
[15:41] <mlankhorst> seb128: woops, fixing up mesa 9.2 build for saucy, tested 9.1.4 for raring, pushed 9.1.6 to saucy (for raring next week). helping out with mir, some upstream nouveau fixes.
[15:41] <seb128> mlankhorst, tkamppeter, larsu: thanks
[15:42] <seb128> ok, me
[15:42] <seb128> - basically system settings
[15:42] <seb128> spent most of the week on the battery panel, debugged qtsystem/upower integration
[15:43] <seb128> added upower integration and charge graph
[15:43] <seb128> and I'm continuing on that atm
[15:43] <seb128> otherwise some sponsoring and reviews on the side
[15:43] <seb128> </week
[15:44] <desrt> nobody cares about desrt
[15:44] <didrocks> desrt: you were asked for!
[15:44] <desrt> not in turn :)
[15:45] <larsu> ts ts ts
[15:45] <desrt> anyway, i have very little to report anyway since i was at GUADEC most of last week.  only one item, really:
[15:45] <seb128> desrt, hey, I though you were on holidays/travelling
[15:45] <desrt> the disk usage thing has spun out of control as people want to add more and more features to it and now we're left with an unbindable API.  i'll try to make sure it's all sorted by end-of-cycle still, though
[15:45] <seb128> ok, thanks
[15:46] <larsu> desrt: can we get a subset of the api first? Or is that unfeasible?
[15:47] <desrt> larsu: not unless we want the _full form later...
[15:47] <desrt> it's sort of annoying because gobject-introspection is bad at cases where we have two callbacks (progress callback + async callback)
[15:47] <larsu> desrt: that's what I feared. Nevermind then :)
[15:48] <desrt> and further complicated by the fact that the scope of the progress callback is bounded by the single call to the async callback and we do not have a way of specifying this in introspection
[15:48] <desrt> i should talk to colin...
[15:48] <larsu> how does g_bus_own_name do it?
[15:48] <desrt> ...but i think he's on vacation too
[15:48] <desrt> _with_closures maybe?
[15:48] <larsu> yeah, I think that's what vala uses at least
[15:48] <desrt> we don't have a closure convention for async callbacks, though
[15:48] <desrt> so... fail
[15:49] <larsu> :-/
[15:49] <desrt> seb128: did you want to use this API sync or async?
[15:49] <seb128> desrt, async but I don't really need status updates
[15:50] <seb128> desrt, e.g I can spawn a sync version in a worked thread
[15:50] <seb128> worker*
[15:50] <seb128> I just want to animate a spinner until I get a value and then display the value
[15:51] <desrt> ya..... alex's idea is that nautilus could share the same API
[15:51] <desrt> which is a nice idea
[15:52] <desrt> i guess you're also using it from C
[15:52] <desrt> (or C++)
[15:52] <desrt> so an initial lack of bindability would not be a problem for you
[15:52] <seb128> C++ yes
[15:52] <seb128> indeed
[15:53] <desrt> k.  thanks for the input.
[15:53] <seb128> I could even system("du") but that's really not nice...
[15:53] <desrt> this problem already exists with other functions like copy_async, fwiw
[15:53] <desrt> so i think we'll have to fix the bindings layer at some point anyway
[15:57] <jbicha> seb128: is there any good way to test whether webkit builds on powerpc before pushing to the regular archives?
[16:00] <didrocks> robru: Mirv: sil2100: cyphermox: https://plus.google.com/hangouts/_/75e8e7309827ce11c50e72e98393d200a9993937?hl=fr
[16:00] <didrocks> where is ken?
[16:00] <robru> dunno
[16:00] <didrocks> let's do the hangout as we decided last week :)
[16:00] <sil2100> Hi!
[16:01] <sil2100> Joining in
[16:02] <seb128> jbicha, did the MIR got approved?
[16:02] <jbicha> seb128: I think it just needs a bug subscriber, bug 1186553
[16:03] <ubot2`> Launchpad bug 1186553 in libwebp (Ubuntu) "[MIR] libwebp" [Undecided,Incomplete] https://launchpad.net/bugs/1186553
[16:04] <seb128> jbicha, otherwise I'm not too sure where you can test on ppc before upload...
[16:05] <kenvandine> didrocks, did i miss the link?
[16:05]  * kenvandine was disconnected
[16:05] <didrocks> kenvandine: yeah, you were disconnected
[16:05] <didrocks> kenvandine: https://plus.google.com/hangouts/_/75e8e7309827ce11c50e72e98393d200a9993937?hl=fr
[16:05] <jbicha> seb128: what if it fails to build on ppc and no one fixes it?
[16:06] <didrocks> kenvandine: still disconnected?
[16:08] <seb128> jbicha, whoever uploads better fix it
[16:16] <pstolowski> hello, i'm getting garbage on 1/3rd of the screen when booting today's saucy iso on intel hd 3000 gfx; known?
[16:19] <pstolowski> tvoss: ^
[16:23] <tkamppeter> didrocks, thank you very much for your help, my cups-filters package correctly uninstalls ghostscript-cups now.
[16:49] <ev> hi folks. Would someone with more intimate knowledge of glib's inner workings care to comment on this: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1211417
[16:49] <ubot2`> Launchpad bug 1211417 in whoopsie (Ubuntu) "whoopsie takes 100% CPU on the phone" [Critical,Confirmed]
[16:49] <ev> I'm having a hard time reproducing it as it's racy
[16:50] <ev> but it looks like glib is getting wedged in g_main_context_prepare
[16:50] <didrocks> tkamppeter: great! :)
[16:53] <seb128> ev, try asking desrt
[16:54] <robru> didrocks, Mirv: can you elaborate a little bit on what needs to be done for ubuntu-docviewer-app/poppler-qml-plugin ? i don't understand some of the bullet points in the spredsheet
[16:55] <didrocks> robru: sorry, I think you'll have to check with Mirv directly (but I think he EOD, well deserved ;))
[16:55] <didrocks> robru: may be try by email?
[16:55] <robru> didrocks, ok
[16:55] <didrocks> it was AFAIK:
[16:55] <didrocks> - ensuring/helping upstream to setup their LP project to match source package name
[16:55] <didrocks> - reviewing packaging and so on
[16:55] <didrocks> (from the conversation we had in the hangout)
[16:59] <jbicha> cyphermox: do you know what's currently blocking indicator-keyboard from landing?
[17:01] <ev> desrt: if you have a moment, I'd greatly appreciate your comments on that bug ^
[17:01] <ev> seb128: thanks
[17:02] <desrt> ev: i looked at it just now
[17:02] <desrt> hard to make very much of it.  would be good if you could give a way to reproduce it
[17:02] <ev> desrt: I don't suppose you have a nexus 4?
[17:02] <desrt> nope
[17:02] <ev> damn
[17:03] <ev> I've not seen it anywhere else
[17:03] <ev> outside of the touch images, that is
[17:04] <desrt> i have a nexus 7
[17:04] <ev> oh, I imagine it'll show on that as well
[17:04] <desrt> i'm kinda close to end of day, though, and going on vacation for 3 weeks starting tomorrow :)
[17:04] <ev> ah damn
[17:04] <desrt> do you have very quick steps to reproduce?
[17:05]  * didrocks waves good evening
[17:05] <ev> phablet-flash cdimage-touch --pending did it for me
[17:05] <desrt> didrocks: nite
[17:05] <ev> but that's going to take time to pull the image down
[17:05] <didrocks> desrt: thanks, you too! :)
[17:05] <desrt> ev: oh.  the problem is on the flash tool?
[17:05] <ev> desrt: no, that just gets the broken bits onto your nexus 7
[17:05] <desrt> ah.  afraid i don't have time for a reinstall :p
[17:06] <ev> desrt: would you be able to judge whether the problem lies in glib or in whoopsie from that stack trace?
[17:06] <ev> (the final one, that is - it's got the clearest listing)
[17:07] <desrt> this stack trace is ... not legit
[17:07] <desrt>  #4  g_main_context_dispatch (context=0x40531cd5 <g_pattern_spec_free+8>) at /build/buildd/glib2.0-2.37.5/./glib/gmain.c:3641 No locals. #5  0x4054132a in g_test_build_filename_va (file_type=<optimized out>, first_path=<optimized out>, ap=...) at /build/buildd/glib2.0-2.37.5/./glib/gtestutils.c:2938
[17:07] <desrt> this is not possible....
[17:07] <desrt> neither of those functions call each other
[17:07] <desrt> even indirectly
[17:07] <ev> https://launchpadlibrarian.net/147473611/whoopsie2.crash
[17:08] <ev> but yeah, perhaps we've corrupted the stack inside whoopsie as gdb hints at
[17:09] <desrt> i'd whip out valgrind as a first step...
[17:09] <ev> yeah
[17:09] <ev> will do in the morn'
[17:10] <ev> thanks for your help
[17:10] <desrt> sorry :/
[17:10] <desrt> but good luck :)
[17:10] <ev> no worries :) enjoy your holiday!
[17:11] <desrt> thanks
[18:16] <cyphermox> jbicha: tests are still failing
[18:39] <jbicha> cyphermox: are you sure? trunk appeared to build fine for me yesterday https://launchpad.net/~jbicha/+archive/dev/+build/4870587
[18:39] <cyphermox> jbicha: it does some of the time, but fails here in sbuild and in pbuilder for continuous integration
[18:40] <cyphermox> in other words, it's an unreliable test that needs to be fixed or (if there's no other option) removed
[18:44] <jbicha> sorry for getting a bit impatient but I expected indicator-keyboard to land about 2 weeks ago and it's blocking getting gnome-settings-daemon 3.8 in which ought to land before Feature Freeze
[18:45] <jbicha> I don't think the g-s-d keyboard indicator had tests so I believe it's at least better than what we had before