[03:43] <pitti> Good morning
[03:57] <Mirv> morning
[06:55] <mlankhorst> morning
[07:50] <sil2100> Mirv: morning!
[07:51] <Mirv> sil2100: morning!
[07:51] <sil2100> Mirv: did you noticed that something strange is happening with the Apps stack job?
[07:51] <sil2100> Mirv: the head job is failing, hm
[07:52] <Mirv> sil2100: yeah, I didn't reply to the e-mail anymore but it seems a mixed bag now, and insights would be welcome. so Apps head job fails, indicators is like I said (looks like network problem), and then some other stacks simply build, test and publish fine
[07:52] <Mirv> so it's really weird
[07:53] <Mirv> and on top of that, the tick didn't start automatically even though there was no queue
[07:56] <sil2100> Mirv: I guess that's because of Apps
[07:56] <sil2100> Mirv: Apps head says "only one instance of a stack can be queued for building"
[07:57] <sil2100> Mirv: so maybe the machinery is in the invalid state of Apps being running all the time
[07:57] <sil2100> I need to ssh and see what's up
[07:58] <Mirv> sil2100: ah. maybe in the work directory? that could resolve the whole thing if found.
[07:59] <Mirv> sil2100: yep, stack.building there
[07:59] <Mirv> trying without
[07:59] <sil2100> Mirv: let's delete that and re run :)
[07:59] <Mirv> did that
[08:00] <Mirv> did not help
[08:00] <sil2100> Mirv: stack.started lets remove as well
[08:00] <sil2100> Since this did not help
[08:01] <sil2100> Removing
[08:01] <sil2100> And re-running
[08:01] <sil2100> Mirv: it's working now
[08:01] <Mirv> helped
[08:01] <Mirv> sil2100: yeah I just watched that it had a wrong status marked there
[08:02] <Mirv> ok
[08:02] <Mirv> sil2100: any bright ideas if you looked at the indicators check fail? :)
[08:03] <Laney> ello
[08:03] <Mirv> unity8 had a build error btw, I didn't file a bug yet but trying once again
[08:03] <Mirv> h laney
[08:03] <Laney> h
[08:04] <Mirv> sil2100: oh and btw yes I tried relaunching indicators and it happened again. I relaunched stacks manually in the morning (well, most of them).
[08:05] <sil2100> ;/
[08:07] <sil2100> Hi Laney, seb128
[08:07] <seb128> hey sil2100, Laney, Mirv
[08:07] <seb128> so you had infrastructure fun yesterday?
[08:07] <sil2100> Mirv: no ideas yet...
[08:11] <sil2100> seb128: still have! A bit
[08:12] <sil2100> Mirv: I think we need jibel, this is clearly a network config issue on the container or something
[08:12] <sil2100> Mirv: but other stacks pass on intel?
[08:15] <Mirv> hey seb128, and yes
[08:15] <Mirv> sil2100: yeah, that's the weird thing
[08:15] <Mirv> sil2100: and then there's the issue that it may be that stack autostarting has stopped (or at least it looked like that 2h ago). do you have any idea how the autostart worked?
[08:16] <Mirv> at least now the crontabs are empty..
[08:16] <sil2100> Mirv: as I said, it didn't autostart because of Apps
[08:16] <sil2100> Mirv: since the system thought that Apps is running all the time, and when a stack is running autostart is not happening
[08:17] <sil2100> (the stack.started flag)
[08:20] <Mirv> sil2100: ah, right because of building
[08:20] <Mirv> sil2100: so it could be all good except for indicators now
[08:20] <Mirv> and the stack.building
[08:21] <sil2100> Yes, the indicators mystery :D
[08:25] <sil2100> seb128: yesterday I browsed through the settings code and built/ran it, so I'll be helping out with minor reviews from now on as well
[08:29] <seb128> sil2100, great, I saw you accepted one of my MR, thanks for that!
[08:47] <Sweetshark> seb128: https://gerrit.libreoffice.org/#/c/5813/ <- fixed the tiff issue upstream
[08:49] <sil2100> Mirv: will you re-run the left-over stacks? (friends especially) ;D
[08:49] <Mirv> sil2100: already did during the call, starting from friends
[08:49] <Mirv> sil2100: apps has the same -intel network problem as indicators, I wonder if we should ignore the intel (nvidia has green light) and check what was built and publish?
[08:50] <seb128> Sweetshark, hey, great!
[08:50] <seb128> Sweetshark, well done
[08:51] <Mirv> sil2100: just gallery-app, and no packaging changes
[08:51] <Sweetshark> seb128: and also fixed bug 1204592 yesterday ...
[08:51] <ubot2`> Launchpad bug 1204592 in libreoffice (Ubuntu) "LibreOffice unity menus populate sluggishly the first time" [Medium,In progress] https://launchpad.net/bugs/1204592
[08:51] <seb128> Sweetshark, oh, how?
[08:52] <seb128> Sweetshark, did you workaround it in some new way or did you found out the issue?
[08:55] <Sweetshark> seb128: well, libreoffice menues are just too big to activate them when you first click on them, but couldnt easily be populated earlier as in LO there are separate menu objects and frame objects (windows) and a menu could be attached to a frame way after its creation.
[08:56] <sil2100> Mirv: hm, I think let's indeed ignore -intel for the time being
[08:57] <sil2100> And publish if nvidia is ok
[08:57] <Sweetshark> But Dbus/ActionGroups has a query_action thingie and in there I can check if the current menu of was already synced in for this frame and if not, can populate it.
[08:58] <seb128> Sweetshark, ah, nice
[08:58] <seb128> Sweetshark, do you work on getting an upload ready with those fixes?
[08:58] <Sweetshark> seb128: thus the menu is populated before it was first clicked by the user, but after the menu was attached to the frame. So the user should not see a delay unless he races to the menu in the first half second of the window appearing.
[08:59] <Sweetshark> seb128: https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=13badfb5ccd296faf480b19b2b33f7633f4085c5;hp=43b84bbba2519686eb6b0463f422bf695d2d74b9 <- upstream diff
[08:59] <Mirv> sil2100: ok
[08:59] <seb128> I like it ;-)
[09:00] <Sweetshark> seb128: my plan was: upload with these fixes to ppa ~today, but update for saucy ~next week as 4.1.2~rc2 will be tagged upstream then and we should take that along.
[09:00] <Mirv> seb128: http://10.97.0.1:8080/view/cu2d/view/Head/view/Phone/job/cu2d-phone-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_messaging-app_0.1+13.10.20130905-0ubuntu1.diff
[09:00] <seb128> Sweetshark, that works for me
[09:01] <Mirv> adds dependencies that were already being used
[09:01] <seb128> Mirv, why is there nothing in the changelog about those changes or why they are needed?
[09:01] <seb128> Mirv, shouldn't there be a commit associated with them?
[09:02] <Mirv> seb128: they were already being used but only happened to work since image had the runtime dependencies installed from elsewhere
[09:02] <Mirv> and the stack
[09:03] <seb128> Mirv, well, should there be a commit/msg "add depends to control that are used by the code" or something
[09:03] <Mirv> so the commit adds those dependencies and modifies one autopilot tests
[09:03] <Mirv> seb128: it does say "Fix runtime dependencies"
[09:03] <seb128> oh, that's part of the same commit
[09:03] <seb128> I got confused by the "Ensure the text entry has active focus before starting to input text."
[09:03] <Mirv> yeah, two fixes in a same commit
[09:03] <seb128> Mirv, +1
[09:04] <Mirv> ok
[09:04] <seb128> brb, session restart
[09:33] <Mirv> sil2100: so you could now set the manual publishing mode, as stacks are now done/idle
[09:37] <Mirv> sil2100: I need to go for a lunch now
[09:53] <sil2100> Mirv: ok, doing the switch
[09:54] <sil2100> Mirv: I'll maybe block this tick as well in the meantime
[09:57] <Sweetsha1k>  
[10:04] <sil2100> Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/manualpublish_on/+merge/184060
[10:11] <Mirv> sil2100: happroved
[10:15] <asac> Mirv: sil2100: so our pump is done and we just wait for final bits to go through proposed?
[10:15] <asac> nice
[10:23] <sil2100> Mirv, asac: redeployed all the stacks with the changes... need to check somehow if this thing works correctly now ;p
[10:23] <asac> sil2100: how can you check?
[10:23] <asac> like an empty publishing round? :)
[10:23] <asac> or do we want to push a trivial change from some stacki
[10:23] <sil2100> asac: I'll look for a stack that had some change in it, run it manually and see if it will wait with publishing
[10:24] <asac> cool
[10:48] <Laney> darkxst_: Not in #ubuntu-release? How are you guys looking for beta 1?
[10:50] <Sweetshark> czajkowski: https://bugs.freedesktop.org/show_bug.cgi?id=67805#c4
[10:50] <ubot2`> Freedesktop bug 67805 in UI "LibreOffice unity menus populate sluggishly the first time" [Normal,Resolved: fixed]
[10:54] <smartboyhw> Laney, amjjawad (Ubuntu GNOME QA Lead) is in #ubuntu-gnome, you can ask him:)
[10:54] <sil2100> jibel: morning!
[10:54] <sil2100> jibel: did Mirv already contact you about the container issues we seem to encounter on the intel machine?
[10:55] <jibel> sil2100, Good morning. No he didn't
[10:55] <jibel> what's going on?
[10:55] <jibel> or is it about the kernel crash on this machine?
[10:55] <sil2100> jibel: ok, so the thing is... we seem to have some internet configuration problems in the intel container, as it cannot connect to the internet and download things from archives
[10:56] <sil2100> jibel: no no, it's about something new
[10:56] <Laney> smartboyhw: MORE! CHANNELS!
[10:56] <smartboyhw> Laney, heh
[10:56] <Laney> I just want to know if the world ends if I take the beta 1 block away
[10:56] <sil2100> jibel: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1547/label=autopilot-intel/console <- for instance here
[10:56] <sil2100> jibel: we also had the same for the Apps stack
[10:57] <sil2100> jibel: only on intel, it seems to not have internet connectivity, maybe the container is broken or something
[10:57] <sil2100> jibel: /var/log/upstart/otto-setup.log:   Could not resolve 'archive.ubuntu.com'
[10:57] <sil2100> jibel: nvidia is fine
[10:57] <Mirv> sil2100: no, not yet
[10:57] <Sweetshark> Laney: isnt that supposed to be MOAR!?
[10:57] <jibel> sil2100, interesting. When it happens is name resolution still working on the host?
[10:58] <Mirv> jibel: yes, it works, and other stacks using the same machine work...
[10:58] <jibel> sil2100, Mirv is it reproducible or random?
[10:58] <Mirv> for example http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1549/label=autopilot-intel/console
[10:58] <Mirv> jibel: it seems to always happen for Apps + Indicators at least
[10:58] <sil2100> jibel: seems reproducible, we had it 2 times on indicators and once on Apps
[10:59] <sil2100> jibel: not sure why some other stacks were ok, since the same container is used, right?
[10:59] <Mirv> so how can stack break networking is beyond me :)
[10:59] <sil2100> Mysteryy
[10:59] <sil2100> ;)
[10:59] <jibel> sil2100, Mirv : ack. I'll have a look early afternoon
[10:59] <sil2100> Thanks!
[10:59] <jibel> sil2100, Mirv I'm also really tempted to switch this machine with the intel box from the raring testing pool
[11:00] <czajkowski> Sweetshark: awww yay!
[11:30] <seb128> Laney, what are you working on?
[11:31] <Laney> seb128: Change current password/passphrase
[11:31] <seb128> Laney, or said differently are you changing the background panel?
[11:31] <Laney> no
[11:31] <Laney> should I be?
[11:31] <seb128> Laney, if not, I'm going to port it to optionselector and do a few UI tweaks
[11:31] <seb128> Laney, no, I'm checking before duping work ;-)
[11:31] <seb128> Laney, thanks
[11:31] <Laney> cool, do it
[11:34] <sil2100> Laney: hello! unity-lens-applications still blocked from migrating to release? ;) Is it because of FF?
[11:34] <seb128> Laney, just saw you mr for the filtering, the SDK is supposed to provide a search entry widget, so don't bother too much adding the icon and stuff
[11:34] <seb128> Laney, e.g https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1186965
[11:34] <ubot2`> Launchpad bug 1186965 in Ubuntu UI Toolkit "Re-usable search component" [High,In progress]
[11:35] <Laney> seb128: cool
[11:35] <Laney> sil2100: if it's seeded then yes
[11:35] <Laney> just talking to people to remove the block
[11:35] <Laney> should be done in a few minutes
[11:39] <Laney> doing
[11:39] <Laney> done
[11:57] <sil2100> Mirv: hm, manualpublish mode doesn't seem to work!
[11:58] <sil2100> :O
[11:58] <Mirv> sil2100: hmm? did something get published?
[11:58] <sil2100> Mirv: maybe a full stack redeploy is needed, not only with -S
[11:58] <Mirv> sil2100: I always use -U
[11:58] <sil2100> Mirv: yes, I used -S -U since that's what Ken said to use
[11:59] <sil2100> Mirv: since with just -U it takes much longer, since all the branches are configured too
[11:59] <sil2100> Mirv: anyway, I tried it out on unity8 and it's green ;/
[11:59] <sil2100> With a successful rsync
[12:00] <sil2100> I'll check cupstream2distro code
[12:00] <Mirv> :S
[12:01] <Mirv> it'd good of course that the FTBFS got fixed
[12:01] <sil2100> Good that it's after the image got spinned out ;)
[12:01] <sil2100> Yeah ;p
[12:01] <sil2100> Ok, checking the jobs
[12:02] <sil2100> AH!
[12:02] <sil2100> Craaap
[12:02] <sil2100> I know what I did wrong ;)
[12:02] <sil2100> Let me fix that
[12:02]  * sil2100 is stupid
[12:03] <sil2100> Mirv: ok, now it should be fine - I forgot to pull in the changes on mangers
[12:03] <sil2100> So when it was parsing the configs it still had the old, non-manualpublish
[12:07] <sil2100> Mirv: for testing, I'll re-run indicators - ok?
[12:11] <sil2100> Mirv: btw. hm, strange thing that we got webapps green - the file conflict is no more?
[12:11] <Mirv> sil2100: right, I thought normal changes got in without pulling on magners?
[12:11] <Mirv> sil2100: like when we change the packages: lines, I've just run the update but haven't ever pulled on magners
[12:12] <Mirv> sil2100: yeah it was green, I guess something got fixed.. I was meaning to look at some point at those bugs filed about the issues
[12:13] <sil2100> Mirv: yes, in most cases a pull is not required on mangers, but in this case he was looking for the manualpublish flag directly in the -config, so a pull was probably needed
[12:14] <Mirv> right
[12:47] <happyaron> seb128: mind review ubuntukylin-wallpapers?
[13:00] <seb128> happyaron, hey ... hum, I've already a stack of reviews and my own work, I can do it maybe at the end of my day but it would be nice if a patch pilot could review it
[13:00] <seb128> happyaron, the calendar says apw and xnox are on duty today
[13:00] <seb128> happyaron, can you try to ping them?
[13:01] <happyaron> ok
[13:01] <xnox> seb128: yes! thanks for reminding!
[13:01] <xnox> happyaron: looking
[13:01] <seb128> xnox, happyaron: great ;-)
[13:01] <happyaron> :)
[13:01] <sil2100> Mirv: manualpublishing works \o/
[13:02] <sil2100> Mirv: (and the intel machine for indicators as well)
[13:02] <xnox> happyaron: where is it? nothing in the report.
[13:02] <sil2100> jibel: did you fix anything ;p ?
[13:02] <happyaron> xnox: https://code.launchpad.net/~ubuntukylin-members/ubuntukylin/ubuntukylin-wallpapers
[13:02] <sil2100> Mirv: anyway, look look! https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/269/console
[13:03] <xnox> happyaron: brand new package?
[13:03] <xnox> =)
[13:03] <happyaron> yes
[13:04] <happyaron> skeleton is forked from ubuntu-wallpapers
[13:05] <xnox> happyaron: yeap, can tell =)
[13:08] <xnox> happyaron: i think you want "ubuntukylin-wallpapers" package to depend on "ubuntukylin-wallpapers-saucy". Cause at the moment it depends on "ubuntu-wallpapers-saucy" meaning that your contest wallpapers will not get installed.
[13:08] <xnox> happyaron: copy & paste error ? =)
[13:08] <rickspencer3> kenvandine, ping
[13:08] <happyaron> xnox: lemme change it
[13:09] <kenvandine> rickspencer3, pong
[13:09] <rickspencer3> kenvandine, did I see something about the content hub landing yesterday?
[13:09] <kenvandine> "landing"
[13:09] <kenvandine> it's been in saucy for a couple weeks :)
[13:10] <kenvandine> but it is getting more complete everyday
[13:10] <happyaron> xnox: anything else need to be changed?
[13:10] <Mirv> sil2100: great!
[13:10] <kenvandine> rickspencer3, we had the basic use case working and landed middle of last week, and pending branches right now that adds the switching apps, etc
[13:11] <xnox> happyaron: what's the license of the images. Have they been created / collected under Create Commons Attribution-ShareAlike 3.0?
[13:11] <rickspencer3> kenvandine, \o/
[13:11] <kenvandine> seb128, last night i had it start gallery-app when needed by system-settings ;)
[13:11] <happyaron> xnox: yes
[13:12] <seb128> kenvandine, great!
[13:12] <xnox> happyaron: ok. awesome =)
[13:12] <kenvandine> seb128, on the phone even... and the desktop :)
[13:12] <happyaron> xnox: it's a prerequest for people submitting their works.
[13:12] <xnox> happyaron: good =)
[13:12] <kenvandine> seb128, it does require a small patch to system-settings, i'll propose that today
[13:12] <kenvandine> removing 2 lines of code :)
[13:12] <xnox> happyaron: some people in the past did get upset when their images got selected =)))) all is good then.
[13:13] <happyaron> :)
[13:15] <seb128> kenvandine, I guess that's in the background panel? if so pleases stack it on top of https://code.launchpad.net/~seb128/ubuntu-system-settings/background-option-selector-and-ui-tweaks/+merge/184081 to avoid conflicts
[13:15] <kenvandine> ok
[13:15] <seb128> kenvandine, well, assuming they edit the same source, which is likely
[13:15] <seb128> kenvandine, bonus point if you review that one ;-)
[13:15] <Laney> want to fix the fallback image case while you're in background? ;-)
[13:15] <kenvandine> :)
[13:17] <seb128> Laney, is https://code.launchpad.net/~seb128/ubuntu-system-settings/reset-unity-launcher/+merge/183490 blocked on changes from my side? did you want me to change that bool return to void?
[13:17] <Laney> seb128: Don't mind
[13:17] <Laney> Do what you think is best; I'll approve or you can self approve
[13:18] <seb128> Laney, well, your call, just let me know if I need to do something before it's approved
[13:18] <seb128> Laney, let's keep it this way, I'm going to add code to handle the error cases later
[13:18] <jibel> sil2100, not really
[13:18] <Laney> k
[13:19] <jibel> sil2100, I found that the client (lxc guest) issues a dhcp discovery, and stops here while the server responded correctly
[13:19] <jibel> sil2100, so it doesn't acquire an ip address
[13:20] <jibel> and is unable to do name resolution of course
[13:20] <jibel> sil2100, but why only intel, that's the big question
[13:21] <sil2100> hmmm
[13:22] <sil2100> jibel: that would mean that this was simply not-always-reproducible, and we just got unlucky to get the same bug on the indicator stack twice in a row
[13:24] <jibel> sil2100, well, I usually don't believe in coincidences, can you ping me next time you see this happening?
[13:24] <xnox> happyaron: uploaded. It will be in NEW queue, requirying archive admin check. I'll ping them about it.
[13:25] <happyaron> xnox: thanks!
[13:26] <sil2100> jibel: sure thing, thanks for looking into that :)
[13:49] <sil2100> Mirv: I see the previous run of the stacks didn't finish... I'll abort it to make place for the 16:00 tick to kick in, ok?
[13:53] <sil2100> Mirv: all halted, I hope that the 14 UTC tick will start correctly!
[13:54] <Mirv> sil2100: ok, probably it will
[15:00] <sil2100> kenvandine, cyphermox: had to run all stacks manually, since the tick didn't start because of a bug on mangers (a leftover stack.started in unity)
[15:09] <kenvandine> sil2100, will it run next tick?
[15:11] <sil2100> kenvandine: yes
[15:11] <sil2100> kenvandine: as long as there is no other power outage ;)
[15:13] <kenvandine> :)
[15:14] <jibel> sil2100, there is a job called cu2d-build_all-head to run all the stacks
[15:16] <desrt_> pitti: hey
[15:16] <desrt_> pitti: hitting some weird pygobject issues suddenly
[15:19] <desrt> pitti: in particular, this weird _PyGObject_API thing being conditionally defined as 'extern' is causing all kinds of weirdness
[15:22] <xnox> I'd like a quick reality check: on ubuntu desktop we do not use nm-applet, instead we use indicator-network ?!
[15:24] <xnox> i think seeds agree with me.
[15:25] <seb128> xnox, no
[15:26] <seb128> xnox, desktop uses nm-applet, indicator-network is in universe
[15:26] <seb128> xnox, i-n lacks stuff like vpn support atm, it's not at feature parity for default install
[15:28] <xnox> seb128: ok. In that case what does "NotShownIn=GNOME" mean? any DE started with gnome-session?
[15:28] <seb128> xnox, it means it starts in Unity sessions but not GNOME (gnome-shell) ones
[15:28] <seb128> xnox, because gnome-shell has its own indicator
[15:29] <xnox> seb128: .... what about lubuntu / xubuntu?
[15:29] <seb128> xnox, they are XFCE and LXDE so it starts there
[15:29]  * xnox thought those were also GNOME
[15:29] <xnox> seb128: hm ok.
[15:31] <seb128> xnox, not sure what happens in gnome-panel's session though
[15:31] <seb128> jbicha, ^
[15:31] <seb128> jbicha, doesn't using NotShownIn=GNOME in nm-applet creates issue for gnome-panel users?
[15:33] <xnox> seb128: jbicha: for the record this is about bug 1189309 and patch by darkxst at https://bugs.launchpad.net/ubuntu/+source/libappindicator/+bug/1189309/comments/11
[15:33] <ubot2`> Launchpad bug 1189309 in libappindicator "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [High,Confirmed]
[15:34] <seb128> xnox, I think that patch is going to create issues for gnome-panel users
[15:38] <cyphermox> sil2100: thanks
[15:45] <jbicha> I was talking with the Edubuntu guys earlier this week: I think that since GNOME Flashback uses indicators and is more similar to Unity than GNOME Shell that it should identify itself as Unity
[15:46] <jbicha> that would fix a lot of little issues like this
[15:46] <seb128> you would get controls in g-c-c like the unity launcher controls
[15:47] <seb128> or the screenlock looking different
[15:47] <seb128> or nautilus and stuff behaving differently
[15:47] <jbicha> right but I believe Edubuntu wants the Ubuntu/Unity look and behavior anyway
[15:48] <jbicha> the Unity launcher controls could check dbus for whether Unity is running instead of XDG_CURRENT_DESKTOP
[15:48] <seb128> sure, patches are welcome
[15:48] <jbicha> flashback uses the same gnome-screensaver that Unity 7.1 does
[15:49] <seb128> we change the look of the lock screen under unity
[15:49] <seb128> e.g hide the top panel
[15:49] <seb128> since that looks like gnome-shell top's bar
[15:50] <jbicha> oh I don't think that's very important since with the indicators, Flashback doesn't look like GNOME Shell's top bar either
[15:55] <seb128> jbicha, well, it was on example, I know we made some distro specific behaviour depends on the session type being Unity, it means changing the value is going to have an impact on some runtime things for those session
[15:55] <seb128> jbicha, but not my call, I'm just pointing it
[16:53] <seb128> Laney, Scroller.qml and TimePicker.qml are mostly copy from code already being shipped right? did you change lot?
[16:54] <Laney> A bit. I added a date picker that I took from mzanetti's git repository
[16:54] <Laney> Made some other visual changes - the ones in the calendar app hardcoded a lot of their things
[16:55] <Laney> TimePicker.qml could probably be called TimeAndDatePicker.qml
[16:56] <seb128> Laney, those are going to go away over time anyway right?
[16:56] <Laney> when the proper pickers arrive they will die, yes
[16:56] <seb128> Laney, in case you didn't notice, I'm trying to find myself an excuse to just glance over that code, quite some code to review :p
[16:57] <Laney> haha
[16:57] <seb128> Laney, I'm going to do an "user review" and read a bit through the code but not be too picky about it
[16:57] <seb128> e.g "it works, ship it" ;-)
[16:57] <Laney> Put pressure on the sdk guys to make the pickers come then you get to make it disappear faster
[16:57] <Laney> ok :P
[16:57] <seb128> yeah, I can do that as well!
[17:05] <seb128> Laney, ok, +1 on the datetime, I don't see anything obviously wrong from a quick reading and it works great here ... just need to be rebased due to pot conflict
[17:06] <Laney> alrighty, thanks, will do that in a second
[17:06] <seb128> (those start being annoying, I'm pondering just letting them out of the mps and do a manual refresh every now and then)
[17:06] <seb128> Laney, if you could rebase https://code.launchpad.net/~laney/ubuntu-system-settings/change-current-security-ui/+merge/184138 on top of the datetime as well...
[17:08] <Laney> timedate pushed
[17:08] <Laney> let me merge the other one
[17:09] <seb128> Laney, I found a bug in that one as well, commented on the mr
[17:09] <Laney> done, resubmitted with prerequisite
[17:09] <Laney> ah, correct, good spot
[17:10] <Laney> fixed
[17:10] <seb128> excellent
[17:10] <seb128> nice to see stuff landing ;-)
[17:10] <seb128> and backends working
[17:11] <Laney> having some kind of namespace comprehension fail with _
[17:11] <seb128> _?
[17:11] <Laney> for i18n
[17:12] <seb128> Laney, namespace = gettext domain ?
[17:12] <Laney> no, C++ namespace
[17:12] <Laney> it doesn't find the function
[17:12] <seb128> oh :/
[17:13] <seb128> Laney, does it work if you use dgettext()?
[17:13] <Laney> probably will do
[17:32] <Laney> bah, that broke it
[17:32] <Laney> will have to look more in the morning
[17:34] <seb128> Laney, have a nice evening!
[17:34] <Laney> apparently it's the last day of good weather all year ;-)
[17:34] <Laney> going to go for a ride to say goodbye
[17:34] <seb128> sounds great
[17:35] <seb128> weather is nice here today and should still be good tomorrow
[17:35] <seb128> then it starts raining
[17:49] <seb128> jbicha, libgdata is stucked on proposed beause tests hang often during build, do you plan to look at that?
[17:52] <seb128> xnox, did you end up reviewing the kylin wallpaper and nautilus-share?
[18:00] <xnox> seb128: wallpapers in new queue, did not upload share.
[18:01] <seb128> xnox, ok, do you plan to look at it or should I put it on my todo (or keep it there rather ;-)
[18:05] <jbicha> seb128: I don't think I'm going to be able to look into the libgdata tests
[18:06] <seb128> jbicha, ok, I might just open an upstream bug and disable some of those
[18:06] <seb128> well, I'm going to try to call pitti for help first, if he's not overbusy
[20:13] <fginther> cyphermox, do you know what's going on with these failures? https://jenkins.qa.ubuntu.com/job/cu2d-oif-head-1.1prepare-grail/325/console
[20:17] <fginther> cyphermox, it looks similar to a problem I started hitting with some launchpad scripts, I had to change the login method
[20:17] <cyphermox> yeah
[20:17] <cyphermox> somehow the server can't properly speak to api.launchpad.net, but it seems to me more like a network problem than anything else
[20:18] <cyphermox> the login method wouldn't cause this