[00:03] <sam113101> I found a bug in the dash
[04:14] <pitti> Good morning
[04:40] <darkxst> jibel, gtk is failing autopkgtests in notify-osd, would you be able to have a look at that?
[04:40] <darkxst> we were hoping to get this update into alpha2
[06:26] <robru> didrocks, good morning! actually it seems I don't have permission to top-approve this one: https://code.launchpad.net/~robru/gsettings-ubuntu-touch-schemas/packaging/+merge/176569
[06:29] <didrocks> robru: oh, that's so sad! let me approve it then :)
[06:29] <didrocks> robru: only because of the smiley :p
[06:29] <robru> hahah
[06:30] <didrocks> done ;)
[06:30] <didrocks> thanks robru!
[06:30] <robru> didrocks, thanks
[06:30] <didrocks> robru: once merged, you will prepare the cu2d-config?
[06:30] <didrocks> (probably your tomorrow)
[06:31] <robru> didrocks, oh, what needs to be done in -config?
[06:31] <didrocks> robru: adding the new component
[06:31] <didrocks> it's not in yet, right?
[06:31] <didrocks> (for daily releases)
[06:32] <robru> didrocks, hmmm, well it has no autopilot and I don't see any tests running during build... should it be daily released?
[06:32] <didrocks> robru: yeah, it's a simple settings package, should be part of misc I guess
[06:33] <robru> didrocks, hmmm, let me do that now, because I want you to review it before you leave today
[06:33] <didrocks> ok ;)
[06:33] <didrocks> robru: you will need to poke fginther for setting up the upstream merger part though
[06:36] <robru> didrocks, https://code.launchpad.net/~robru/cupstream2distro-config/add-gsettings/+merge/176606 I guess this is all that's needed? I'm not sure what else needs to be done
[06:38] <didrocks> robru: I think that's fine, I'm not sure if the upstream merger needs more TBH…
[06:38] <didrocks> robru: so, let me approve it, please check with fginther once he's online to set up the upstream merger
[06:38] <didrocks> robru: and then, you can redeploy the stack to add the component to tomorrow's daily
[06:38] <didrocks> sounds good?
[06:38] <robru> didrocks, I don't think so... none of the other packages listed there have anything special. I think it's only when CI needs to know about autopilot that you need to do anything special.
[06:38] <robru> didrocks, ok
[06:39] <didrocks> robru: yeah, sounds like the case, he needs to create the CI part anyway ;)
[06:49] <robru> didrocks, hmmm, how do I fix this? http://paste.ubuntu.com/5906637/
[06:51] <didrocks> robru: you need to be in the team
[06:51] <robru> bah!
[06:51] <didrocks> Laney: can you add robru to ~system-settings-touch?
[06:51] <robru> is it worth joining the team (since this isn't my usual stack) or should I just let somebody else do this?
[06:51] <didrocks> robru: well, can be easier in case you need to deploy :)
[06:51] <robru> ok
[06:54] <jibel> good morning
[06:54] <didrocks> salut jibel
[06:58] <didrocks> jibel: mind doing a quick review? http://paste.ubuntu.com/5906654/
[06:59] <didrocks> jibel: the corresponding change to cu2d-run is http://paste.ubuntu.com/5906657/
[07:04] <jibel> Salut didrocks
[07:08] <jibel> didrocks, I am not sure about the change in cu2d-run, I need to look at the code in its context
[07:09] <didrocks> jibel: I've already ran it, it's just using the "head" job now for everything
[07:10] <jibel> didrocks, indeed that's what I read from the pastebin but would like to check if it doesn't have any side effect since you're creating the main job in the publish section
[07:13] <didrocks> jibel: http://paste.ubuntu.com/5906678/
[07:13] <didrocks> the full command
[07:13] <didrocks> I've moved jobname up now
[07:13] <didrocks> as we are always using head
[07:15] <jibel> didrocks, it is different from the patch, but LGTM :)
[07:15] <jibel> didrocks, approved
[07:16] <didrocks> jibel: yep, as told, I just moved the jobname up (instead of defining it twice in the if with the same name :p)
[07:16] <didrocks> jibel: thanks!
[07:16] <didrocks> deploying all the stacks and pushing
[07:24] <larsu> Trevinho: woah, bamf support for qmlscene?!
[07:24] <larsu> I thought we wanted to have a proper launcher instead of relying on qmlscene
[07:27] <pitti> bienvenue à les premiers langpacks pour saucy !
[07:27] <pitti> hey larsu, wie gehts?
[07:30] <larsu> pitti: sehr gut danke! Will sign a lease for an appartment in Berlin today :)
[07:31] <larsu> pitti: wie geht's dir?
[07:31] <pitti> larsu: oh, not homeless any more! :-)
[07:31] <pitti> larsu: sehr gut, danke
[07:31] <larsu> pitti: yeah! Now I have a home (with nothing in it :D)
[07:36] <sil2100> Hi desktoppers!
[07:36] <sil2100> hm, I noticed appmenu-gtk stopped building in the PPA because of the lack of gtk/ubuntumenuproxy.h
[07:36] <sil2100> Did something change? Or is appmenu-gtk so deprecated that it won't build anymore?
[07:37] <larsu> sil2100: it depends on a patch in gtk that got dropped
[07:37] <seb128> good morning desktopers
[07:37] <sil2100> seb128: morning!
[07:37] <seb128> hey sil2100, larsu
[07:38] <sil2100> larsu: oh, so maybe it would be wise for me to disable it from daily release then?
[07:38] <seb128> sil2100, what larsu said, the source got dropped from saucy recently, we should probably stop daily building it as well
[07:38] <sil2100> Right
[07:39] <larsu> sil2100: yep :)
[07:45] <sil2100> seb128, larsu, didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/drop_appmenu-gtk/+merge/176615
[07:45] <sil2100> If it's ok, I'll be redeploying indicators and re-running, since appmenu-gtk was blocking the release
[07:45] <didrocks> hey seb128, sil2100, larsu
[07:45] <didrocks> and pitti
[07:45] <seb128> didrocks, lut
[07:45] <sil2100> Hi! \o/
[07:45] <didrocks> sil2100: before redeploying, ensure to merge to trunk ;)
[07:45] <larsu> didrocks: good morning didrocks!
[07:46] <larsu> woah, double-ping
[07:46] <didrocks> :)
[07:46] <sil2100> didrocks: I re-ran QA since a new autopilot with the AP fixes has landed after the daily-release process, so it might be green now
[07:46] <seb128> didrocks, https://code.launchpad.net/~sil2100/cupstream2distro-config/drop_appmenu-gtk/+merge/176615 seems fine to me?
[07:46] <larsu> sil2100: I don't even know what this does... so I'll let didrocks handle the MR
[07:46] <didrocks> sil2100: ok, thanks
[07:46] <seb128> didrocks, that's not covered in the faq, seems weird that it needs a new file just to drop a component?
[07:46] <thomi> sil2100: if it's still broken, please let me know
[07:47] <sil2100> thomi: thanks guys!
[07:47] <thomi> sil2100: no worries
[07:47] <thomi> one of those problems was really hard to track down :)
[07:47] <didrocks> seb128: I think sil2100 wants still to have the upstream merger in
[07:48] <sil2100> didrocks: we could drop it completely as well, but I thought it's not up to me if it's 'dropped' completely or not
[07:48] <sil2100> ;)
[07:48] <sil2100> Having autolanding is not a bad thing for now
[07:50] <sil2100> didrocks: ok, merged in trunk and now redeploying \o/
[07:55] <sil2100> didrocks: hmmm
[07:56] <sil2100> didrocks: strange thing happened
[07:56] <sil2100> didrocks: I redeployed the indicators stack for head, but it still has appmenu-gtk in it?
[07:56] <didrocks> sil2100: is the strange thing linked to my modification from the morning?
[07:56] <didrocks> sil2100: yeah, the jobs aren't removed
[07:56] <didrocks> sil2100: it's just "unplugged"
[07:56] <didrocks> so that you can still track the history
[07:56] <didrocks> you need to remove it manually
[07:56] <didrocks> (the prepare job itself)
[07:57] <sil2100> didrocks: do I have to remove the prepare job for the check job to not notice it?
[07:57] <sil2100> didrocks: maybe I need to rebuild the stack without 'foo', since it's still looking for appmenu-gtk
[07:58] <didrocks> sil2100: no, you don't need to remove the prepare job, it's already unplugged
[07:58] <didrocks> sil2100: so, just rebuild with foo
[07:58] <didrocks> ah
[07:58] <didrocks> yeah, indeed
[07:58] <didrocks> you need to remove .project file
[07:58] <didrocks> or rebuild the whole stack
[08:00]  * sil2100 removed the .project file and re-ran
[08:00] <didrocks> sil2100: so, I changed the "force publication" mecanism
[08:00] <didrocks> if you use the command line tool, no change for you
[08:00] <didrocks> (just ensure you have the latest cupstream2distro)
[08:00] <sil2100> didrocks: I noticed that it's available on the head job as well
[08:01] <didrocks> it's only available on the head job now
[08:01] <sil2100> Ah
[08:01] <seb128> \o/ unity landing
[08:01] <didrocks> that way, we'll get "green" everywhere in the stack
[08:01] <sil2100> seb128: yes, yesterday it landed ;p I mean, I forcefully landed it :<
[08:01] <didrocks> no more "yellow" even if published
[08:01] <pitti> bonjour seb128
[08:01] <seb128> sil2100, what was the issue/how did it get unblocked?
[08:01] <seb128> pitti, salut, ça va bien ?
[08:01] <didrocks> it's in proposed, right?
[08:01] <didrocks> blocked manually by Laney I guess
[08:01] <pitti> le vert, le vert pour tous le monde !
[08:01] <Laney> hello
[08:01] <seb128> didrocks, a2 block I guess
[08:02] <pitti> seb128: oui, merci ! et toi ?
[08:02] <seb128> Laney, good morning
[08:02] <didrocks> seb128: oh, right, for lubuntu maybe
[08:02] <pitti> Laney: good day!
[08:02] <seb128> pitti, ça va bien, merci ;-)
[08:02] <sil2100> seb128: so, there was a lot of issues with unity, first we had the DBus saturation issue which got fixed in HUD, then we had autopilot failures, then there were otto problems with OOM (due to recordmydesktop), then we had powerpc FTBFS and finally there was a flacky unit test that fails randomly on slow armhf machines
[08:02] <sil2100> phew
[08:02] <sil2100> didrocks: \o/
[08:03] <sil2100> didrocks: so, even when using the CLI tool, the head job will turn green then?
[08:03] <didrocks> sil2100: yep
[08:03] <Laney> didrocks: I don't understand what the point of passing --fail-missing to all dh commands is? Does something other than dh_install listen to it?
[08:03] <seb128> didrocks,ubuntukylin rather I guess
[08:03] <seb128> (they use unity)
[08:04] <didrocks> Laney: no, it just prevent having an override for one line
[08:04] <didrocks> seb128: ah ok
[08:04] <didrocks> seb128: btw, I already preNEWed the settings package from Laney?
[08:04] <Laney> seems weird and less self documenting
[08:04] <seb128> didrocks, is that a question? ;-)
[08:04] <didrocks> argh, brain broken
[08:04] <didrocks> it was:
[08:05] <didrocks> seb128: btw, *did you*…
[08:05] <seb128> didrocks, yes
[08:05] <didrocks> great, so should be there as soon as fginther setup the upstream merger
[08:05] <Laney> am I supposed to merge this branch or wait for that?
[08:07] <didrocks> Laney: I think it will be the right timing to check to test fginther deployement :)
[08:07] <Laney> k
[08:27] <sil2100> didrocks: hm, the mirslave check job seems to be hanged for ati
[08:27] <sil2100> didrocks: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/583/label=autopilot-ati/console
[08:28] <sil2100> didrocks: it's not moving, and it blocks other AP tests
[08:28] <didrocks> sil2100: indeed, it seems that the tests didn't start
[08:28] <didrocks> sil2100: let me ssh
[08:28] <didrocks> sil2100: well, it will block until the timeout…
[08:28] <sil2100> The timeout is quite large ;)
[08:28] <didrocks> sil2100: I don't remember, still 2 hours?
[08:28] <didrocks> sil2100: or did we keep a higher value for your dbus issue?
[08:29] <sil2100> No idea, hm, I always thought it's till 2 hours for all, but maybe it's not?
[08:29] <didrocks> sil2100: so 2h is needed, see the time taken by unity tests…
[08:31] <didrocks> sil2100: ok, I'm powering that off
[08:32] <sil2100> didrocks: ok, thanks :)
[08:32] <didrocks> will retry after those tests ran
[08:32] <bdrung> Sweetshark: hi. i am sorry that i just overlooked/ignored your mail regarding libreoffice 4.1.0 rc1.
[08:32] <bdrung> Sweetshark: do you want to update the branch to rc4?
[08:33] <bdrung> Sweetshark: do you want to merge debian-experimental-4.1?
[08:35] <Sweetshark> bdrung: I updated to rc4, and have a testbuild running in https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging -- I will push when it succeeds.
[08:35] <Sweetshark> bdrung: it already merged debian-experimental-4.1 quite recently.
[08:39] <bdrung> Sweetshark: then it doesn't seem to be pushed to alioth.
[08:42] <didrocks> sil2100: it seems the ati machine is screwed, no?
[08:42] <didrocks> weird that we only see this on the ati machine
[08:42] <sil2100> didrocks: it happened on intel today as well
[08:42] <didrocks> sil2100: a race in distro? what changed?
[08:43] <didrocks> it's the same snapshot than yesterday though
[08:43] <sil2100> didrocks: today's unity run had a timeout on intel and ati passed - I poked jibel about that, since in case of unity I thought it's the OOM thing with recordmydesktop
[08:43] <didrocks> jibel: you didn't change anything on the machines, right? ^
[08:49] <sil2100> FJKong: welcome to our team!
[08:51] <FJKong> #sil2108 thank you very much :)
[08:51] <FJKong> sil2100, thank you
[08:52] <didrocks> welcome FJKong :)
[08:52] <pitti> hey FJKong, welcome to the desktop team!
[08:52] <pitti> FJKong: task #1: learn French
[08:52] <sil2100> :o
[08:53] <pitti> salut Monsieur FJKong, bienvenue à l'équipe de bureau !
[08:53]  * sil2100 doesn't know French yet!
[08:54] <Laney> ah but you put it in your annual objectives, yesyes? :P
[08:54] <seb128> FJKong, hey, welcome on board!
[08:55] <FJKong> pitti, French  sounds good, symbol of romantic.
[08:55] <FJKong> thank you guys,  happy to meet you here.
[08:58] <Laney> wtf
[08:58] <Laney> maliit "general packaging cleanup" -> throw away everything that was there before and start again
[08:59] <seb128> who did that?
[08:59] <seb128> oh, rsalvati
[08:59] <Laney> yes
[08:59] <seb128> weird
[08:59] <seb128> he's usually doing reasonable changes
[08:59] <Laney> quite annoying
[09:00] <seb128> rsalveti, ^ can you explain why you redid the packaging? (I guess you are sleeping, but later when you read the backlog)
[09:00] <Laney> I guess it's what was in the phablet branch
[09:01] <seb128> well, that's an upload to the archive, they should have rebased on the archive version
[09:01] <seb128> not the other way around
[09:02] <Laney> you'd think...
[09:04] <Laney> that's also the packaging that's in debian ^o)
[09:06] <seb128> let's wait for rsalveti
[09:06] <seb128> no need to speculate about the reasons
[09:08] <Laney> wasn't
[09:10] <seb128> Laney, btw, I reviewed your tz merge proposal
[09:10] <seb128> Laney, that list is crazy :p
[09:11] <Laney> haha
[09:11] <Laney> it'll only be displayed when you type something in the box
[09:11] <seb128> it better does that, if you don't want to spend your day scrolling down ;-)
[09:16] <Laney> will do that after reviewing the diagnostics branch again
[09:17] <mhr3> seb128, continuing on yesterday's build.id, where to get that from once hybris doesn't provide it? ie where will it be on ubuntu-edge? :)
[09:18] <seb128> mhr3, no I don't, I'm not even sure those details are defined yet ... check with ogra_ or rsalveti maybe they know
[09:19] <mhr3> somehow i expected that answer
[09:19] <seb128> ;-)
[09:27]  * Laney eyes the PS Jenkins bot
[09:29] <didrocks> Laney: what about it?
[09:29] <Laney> there's something off in its chroot
[09:29] <Laney> https://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-saucy-amd64-ci/148/console
[09:30] <didrocks> Laney: ah, I thought you meant the upload in proposed
[09:30] <ogra_> seb128, mhr3, well, the question is, do you want to expose android build info at all :) the ubuntu rootfs build id is in /var/log/installer/media-info in case you prefer that
[09:30] <Laney> no, don't know anything about any upload
[09:30] <Laney> not sure I want to :P
[09:31] <mhr3> ogra_, well i just want a build id, surely once we don't have android bits we still need it
[09:32] <ogra_> mhr3, well, then the ubuntu image build id is probably the best
[09:33] <mhr3> ogra_, then again we want it so the individual operator variants can be distinguished, so not exactly :)
[09:33] <ogra_> and that file is also compatible with i.e. debian-installer or ubiquity installations
[09:34] <ogra_> well, then you need the id from the props i guess
[09:34] <ogra_> btw, i wouldnt expect the edge to work differently from the nexus images we have today
[09:35] <ogra_> we will have more access to the binary blobs there but i wouldnt expect the concept to change to radical here
[09:38] <xnox> ogra_: mhr3: there is another file we use for oem/sku distinguishing.
[09:38] <ogra_> xnox, in the cdimage generated builds ?
[09:38] <mhr3> xnox, there is?
[09:38] <ogra_> i dont think we did put any stamp info inside until i implemented the above one
[09:38] <xnox> created by oem-config, i don't think cdimage creates it at the moment, but if/when we will have per-sku/operator builds, we will add it.
[09:38] <ogra_> right
[09:39] <xnox> ogra_: but using same stamp as oem-config will make it compatible between phone/desktop installs.
[09:39] <ogra_> xnox, what is that stamp file ? /var/log/installer/media-info is what all tools use (i.e. apport)
[09:40]  * ogra_ never heard of another one except for jenkins build stamps (shich nothing in the archive uses)
[09:41] <xnox> ogra_: var/log/installer/oem-id
[09:41] <ogra_> ah
[09:42] <xnox> ogra_:  that's present on all OEM pre-installed ubuntu machines, I believe, or if one manually create oem install and configures it.
[09:42]  * ogra_ never saw it ... even in preinstalled oem installs, do you need to preseed anything to have it created ?
[09:43] <xnox> ogra_: so when ubiquity is launched in oem mode, it offers to specify oem id, it's optional field =/ and then it will be propogated to var/log/installer/oem-id. There is no other magic to it =) it's meant to denote batch/sku of machines
[09:44] <ogra_> xnox, ah, that why i never saw it on arm installs
[09:44] <ogra_> we never ran the preparation step there but instead started directly into the config
[09:44] <xnox> ogra_: right, cause only the later "client" portion is used in pre-installed arm. The oem-id is in the "prepare" portion of it.
[09:48] <seb128> Laney, did you get a reply from anyone on the CI chroot issue?
[09:49] <Laney> seb128: nope, who/where is the place to ping about that?
[09:49] <seb128> sil2100, ^ can you help?
[09:52] <didrocks> seb128: this is the upstream merger
[09:53] <didrocks> I doubt sil2100 can help
[09:53] <seb128> didrocks, that's fginthers?
[09:53] <didrocks> I think you need to ping fginther/alesage…
[09:53] <didrocks> yeah
[09:53] <seb128> thanks
[09:53] <seb128> that was the question "who to ping" ;-)
[09:54] <sil2100> Sadly, all the upstream merger people are US based...
[09:54] <sil2100> This is a bit sad I must say
[09:54] <didrocks> that's why I try to avoid the CI word
[09:54] <didrocks> but it seems I'm in the minority
[09:54] <didrocks> anyway…
[09:55] <seb128> oh, I know what's the issue is
[09:55] <seb128> hum, or not
[09:55] <seb128> Laney, oh, I know
[09:55] <seb128> Laney, you need libtimezonemap >= 0.4.0.1 or that version is only in proposed and CI doesn't use proposed
[09:56] <seb128> so it fails to install the requirement
[09:56] <Laney> why is it going on about python?
[09:56] <seb128> I don't know, apt errors on install fail can be confusing
[09:57] <Laney> didn't we make the daily releases use proposed now anyway?
[09:57] <seb128>  pbuilder-satisfydepends-dummy : Depends: libtimezonemap1-dev (>= 0.4.0.1) but it is not going to be installed.
[09:57] <seb128> ...
[09:57] <seb128> Laney, CI != merger
[09:57] <Laney> yes
[09:57] <Laney> but they should use the same sources
[09:58] <seb128> we have been going forth and back on that
[09:58] <seb128> I didn't follow closely what was decided, they both have issues
[09:59] <seb128> Laney, can you unblock libmaptimezone out of proposed?
[09:59] <Laney> it wouldn't be much good if it passed here and then failed to build in the daily release PPA because of a problem in proposed
[09:59] <seb128> it doesn't seem there is any reason to hold it in there, it's not a disruptive update
[10:01] <seb128> Laney, there doesn't seem to be an issue with proposed, what do you mean?
[10:02] <Laney> the argument against enabling proposed there
[10:03] <seb128> Laney, well, alternatively, if you don't want to unblock the lib, can you lower the build-depends and list the things that you need to workaround the buggy -dev depends?
[10:03] <Laney> I'd rather unblock it than do that
[10:03] <Laney> but I'd rather have to do neither
[10:03] <seb128> Laney, I'm not arguing in favor or anything, the CI guys are U.S based and sleeping and I don't want us to block work on them to be up and on further discussions
[10:03] <Laney> still, I'll unblock
[10:03] <Laney> not convinced this is the only problem though :-)
[10:03] <seb128> thanks
[10:04] <seb128> let's see
[10:04] <seb128> I just tried in a pbuilder
[10:04] <seb128> which suggests it is
[10:04] <seb128> not sure why python is listed in that log though
[10:18] <sil2100> didrocks: packages list refreshed!
[10:18] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_check_to_unity8/+merge/176407
[10:18] <sil2100> didrocks: it tests on jenkins, so it's ok
[10:18] <sil2100> (there are some failures though)
[10:18] <sil2100> Test failures
[10:18] <didrocks> sil2100: ande working apparently, right? (well some tests failing, but that's up to Saviq's team of a bad interaction with unity7 loaded?)
[10:18] <didrocks> and*
[10:18] <didrocks> sil2100: you did ping him?
[10:19] <sil2100> didrocks: will to ;) But I guess the branch is OK for approval in the meantime
[10:19] <didrocks> sil2100: DONE
[10:19] <sil2100> didrocks: THX :D
[10:20] <seb128> Laney, CI just acked https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-design-update/+merge/176645 for me
[10:20] <seb128> Laney, which suggests the chroot is fine, it's just getting unhappy about the libtimezone thing
[10:20] <Laney> it's in saucy now so let's see
[10:21] <Laney> if it triggers itself
[10:21] <seb128> you might need to change the status of the mp to retrigger a CI run
[10:21] <seb128> or ping fginter/alasage
[10:22] <Laney> i'll wait until it is on the mirror
[10:22] <seb128> ok
[10:23]  * Laney dives into FilterProxy hell
[11:43] <Saviq> desrt, ping
[11:57] <desrt> Saviq: hey
[11:57] <Saviq> desrt, hey, I stumbled upon an issue with Gio.Settings.new_with_path
[11:58] <Saviq> desrt, it seems to require trailing slash
[11:58] <desrt> that's correct
[11:58] <desrt> dconf and gsettings have a very strict concept of what is a pathname and what is a keyname
[11:58] <desrt> and pathnames always require trailing slashes to identify them as such
[11:58] <desrt> it's because in dconf you can have both /a and /a/b
[11:58] <Saviq> desrt, would it make sense to error out if it doesn't?
[11:58] <desrt> so /a is the key and /a/ is the path containing 'b'
[11:59] <desrt> Saviq: i think so... they are two different entities
[11:59] <Saviq> desrt, so yeah, new_with_path takes it in blindly
[11:59] <Saviq> desrt, and then the path is simply concatenated with the key value when you set_ it
[11:59] <desrt> ohhh
[11:59] <desrt> ouch!
[11:59] <desrt> ya.  that is a bug
[11:59] <desrt> please file that
[11:59] <desrt> thanks
[11:59] <Saviq> desrt, which project?
[12:00] <desrt> glib
[12:00] <Saviq> desrt, doing
[12:00] <desrt> https://bugzilla.gnome.org/enter_bug.cgi?product=glib in case you didn't find it already :)
[12:04] <Saviq> desrt, https://bugzilla.gnome.org/show_bug.cgi?id=704802
[12:04] <ubot2`> Gnome bug 704802 in gsettings "new_with_path deosn't check for trailing slash in path" [Normal,Unconfirmed]
[12:04] <desrt> Saviq: thanks
[12:20] <seb128> Laney, easier to discuss it, what's the advange of an enum there? the enum helps to translate numbers to names right?
[12:20] <seb128> discuss it *here*
[12:20] <Laney> seb128: yes, readability, I'm sure your one works too
[12:20] <seb128> Laney, in that case I just want to store/read the number
[12:20] <seb128> well, I couldn't do index = key
[12:21] <seb128> I would need to do (sort == "name") ? 1 : 0
[12:21] <Laney> yep
[12:21] <seb128> you think it would be easier to read?
[12:22] <seb128> that's basically what my first version with the boolean do btw
[12:22] <seb128> https://code.launchpad.net/~seb128/ubuntu-system-settings/storage-store-sorting/+merge/176429
[12:22] <Laney> Feels that way but not sure
[12:22] <Laney> yeah it's like that but more extensible
[12:22] <Laney> I don't mind though - do what you think is best
[12:22] <seb128> I don't foresee any other option to be added there
[12:22] <seb128> ok, let's accept the boolean one then
[12:22] <Laney> just responded to you asking if it was nice
[12:23] <Laney> ok, in a bit though - getting this fitlering to work
[12:23] <seb128> sure, thanks
[12:33] <desrt> seb128, Laney: good morning guys
[12:33] <seb128> desrt, hey
[12:33] <seb128> how are you?
[12:33] <Laney> howdy desrt
[12:33] <desrt> pretty good
[12:34]  * desrt has his coffee ;)
[13:01] <rsalveti> Laney: seb128: the general package clean up was on top of sergio's changes, just adding vcs, fixing control, etc, not really big changes
[13:01] <rsalveti> you can see the bzr log for the packaging branch
[13:02] <rsalveti> also, afaik sergio tried to make this compatible with what we had before
[13:02] <seb128> rsalveti, seems like that packaging branch had a packaging different from the one from the archive/Debian
[13:02] <rsalveti> it's just that upstream is kind of broken at this moment
[13:02] <rsalveti> is debian using 0.99 as well?
[13:02]  * rsalveti checks
[13:02] <seb128> updating the version usually don't need to redo debian/
[13:03] <seb128> just to bump changelog and adapt depends and stuff
[13:03] <rsalveti> right, but everything changed with 99
[13:03] <rsalveti> drop support for gtk
[13:03] <rsalveti> moving from qt4 to qt5
[13:03] <rsalveti> and such
[13:03] <Laney> I was trying to keep the packages the same
[13:03] <Laney> I'd have helped review and sponsor any update into Debian
[13:04] <rsalveti> I'm not sure you want .99 in debian at this point
[13:04] <Laney> it's only in experimental as is
[13:04] <rsalveti> it only works for us because we'll be pushing a touch specific keyboard
[13:04] <rsalveti> even the examples, from maliit-plugins is sort of broken =\
[13:04] <rsalveti> right from upstream
[13:05] <rsalveti> 94 -> 99 is a major change
[13:06] <Laney> so the package is going to be useless for any other consumer than touch for now?
[13:06] <rsalveti> Laney: yes
[13:06] <rsalveti> because that's the state of upstream
[13:07] <Laney> it's not the state of what we had before in the archive though
[13:08] <rsalveti> it'll be better once we push the other keyboard, which is not touch specific btw, it'll be the one we're using for touch
[13:09] <rsalveti> we'll do a bit of more work on it still, we just needed a newer version because that got tons of changes we needed
[13:19] <Laney> phew
[13:19] <Laney> filtering works!
[13:20] <seb128> Laney, well done ;-)
[13:20] <Laney> the list data isn't great though
[13:20] <rsalveti> hm, no qtdeclarative5-dev for ppc
[13:21] <seb128> rsalveti, v8 doesn't exit on ppc
[13:21] <seb128> exist
[13:21] <rsalveti> argh
[13:21] <seb128> rsalveti, so most of qt5 is !ppc
[13:21] <ogra_> bah, so we wont have PPC phone support
[13:21] <ogra_> how bad
[13:21] <rsalveti> seb128: so should disable builds for ppc for packages depending on qt5 then?
[13:21] <rsalveti> or just let it pending in the archive?
[13:21] <seb128> rsalveti, no, they are just going to depwait
[13:21] <Laney> leave it depwaiting
[13:22] <seb128> rsalveti, but if it existed before (because it was e.g qt4) you need an archive admin to delete the old ppc binaries
[13:22] <rsalveti> who knows, someone might want to port v8
[13:22] <Laney> seb128: I'm going to reject my outstanding MPs and submit a new big one
[13:22] <seb128> otherwise britney stops migration
[13:22] <seb128> Laney, ok
[13:22] <rsalveti> seb128: yeah, that's the case here
[13:22] <rsalveti> seb128: oh, and btw, you're an archive admin :P
[13:23] <seb128> rsalveti, right :p is that for maliit?
[13:23] <rsalveti> seb128: yup
[13:23] <seb128> does it has rdepends?
[13:23]  * seb128 checks
[13:24] <seb128> rsalveti, there is a nemo plugin depending on it ... is that going away or?
[13:24] <rsalveti> seb128: we got a dep wait for maliit-framework and maliit-plugins
[13:24] <rsalveti> as both uses qt5 now
[13:25] <rsalveti> seb128: new maliit-plugins should bring a newer version of that package
[13:25] <seb128> rsalveti, ok, great, let me check with cjwatson to make sure it's ok to delete the binaries and that's going to make britney happy
[13:26] <rsalveti> seb128: great, thanks
[13:28] <attente> rsalveti, what keyboard are you planning to switch to?
[13:29] <rsalveti> attente: it's basically the one already used in the touch images, but that is part of a fork that happened on top of the previous maliit-plugins package
[13:30] <rsalveti> what we'll be doing is pushing another package with just our keyboard, so we can drop the fork
[13:30] <attente> ah, thanks
[13:48] <pitti> seb128, didrocks: Just a FYI, please don't expect bug 1201485 to land soon
[13:48] <ubot2`> Launchpad bug 1201485 in langpack-o-matic "Need to import translations for the unity daily builds" [Undecided,Triaged] https://launchpad.net/bugs/1201485
[13:48] <seb128> pitti, :-(
[13:48] <seb128> pitti, why not?
[13:48] <pitti> seb128, didrocks: if we need to do that entirely in langpack-o-matic, we need to replicate the entire LP logic for importing the raw tarballs
[13:49] <pitti> seb128, didrocks: which is a nontrivial amount of work due to all the overrides and mapping logic
[13:49] <pitti> seb128, didrocks: my iniitial reaction would have been "let's ask LP to import these tarballs itself", but I guess that's not that much faster as there is no devel crew any more
[13:50] <seb128> right
[13:51] <seb128> we can still check with wgrant
[13:51] <seb128> but I guess waiting on launchpad is going to take forever
[13:51] <pitti> but that also means that translating all these packages in LP is broken, right?
[13:51] <pitti> as the updated translations or POTs never get fed into it
[13:52] <seb128> right, that's what the bug is about
[13:52] <seb128> the new templates are not imported
[13:52] <seb128> so the list of strings is outdated
[13:52] <seb128> the export/langpack is actually fine
[13:54] <pitti> seb128: right, but I can't fix that on the langpack-o-matic side
[13:54] <pitti> the only thing I can do theoretically is to download the raw tarballs, do the mangling/mapping logic myself, and put them into langpacks
[13:54] <pitti> but that'll of course sidestep LP translations
[13:54] <seb128> shrug
[13:54]  * seb128 tries to think
[13:55] <pitti> so the conceptually cleanest solution is actually to copy the raw translation tarballs along when copying the source/binaries
[13:55] <pitti> as if it were an upload
[13:56] <seb128> pitti, no trivial solution, I wonder if we should just hack around by scripting a "upload updated template to launchpad manually" meanwhile
[13:57] <desrt> pitti: hey
[13:57] <seb128> pitti, it sucks to have unity and indicators not correctly translated
[13:57] <desrt> pitti: wanted to talk to you about this systemd version number thing.  what's your take on that?
[13:58] <sil2100> jibel: what do you think? https://code.launchpad.net/~sil2100/otto/fix_1203809/+merge/176692
[13:59] <pitti> seb128: I updated the bug and pinged William/Steve about it
[13:59] <pitti> hey desrt
[13:59] <seb128> pitti, thanks
[13:59] <sil2100> Saviq: approved! Let's get the ball rolling
[13:59] <pitti> desrt: my gut feeling is that adding a version API to -shim should be ok
[13:59] <pitti> desrt: but it could of course lure other programs into thinking that we actually have systemd as pid 1
[14:00] <desrt> ya....
[14:00] <desrt> i was wondering if maybe we could get upower upstream to change their behaviour
[14:00] <desrt> but really, why is upower issuing power management jobs these days?
[14:00] <desrt> some legacy code is poking its interfaces or something?
[14:01] <desrt> it seems pretty ridiculous that we have a app -> upower -> logind -> systemd-shim -> kernel path :/
[14:01] <pitti> desrt: yes; it doesn't issue suspend request by itself, just when you ask it over its dbus interface
[14:01] <Saviq> sil2100, yeah... at least half an hour for it to land, though :/
[14:01] <pitti> desrt: as it has had the suspend/hibernate calls for many years, we need to transition everything to logind first before we can disable them
[14:02] <pitti> desrt: but it works in principle; there is of course the new libusbx sometimes crashing/hanging upower, which causes some problems right now
[14:03] <pitti> seb128: so by #u-devel this might actually be much simpler on the LP side
[14:04] <seb128> pitti, just read that, great
[15:10] <ritz> Sweetshark ping, sorry about https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/628105 .
[15:10] <ubot2`> Ubuntu bug 628105 in libreoffice (Ubuntu Quantal) "[Upstream] Text not black in LibreOffice" [Undecided,In progress]
[15:10] <ritz> Sweetshark I will go ahead and subscribe ubuntu-sponsor to this
[15:11] <Sweetshark> ritz: np
[15:12] <Sweetshark> ritz: do you need this for precise or quantal?
[15:13] <ritz> precise
[15:13] <ritz> quantal, not so much. non -LTS
[15:13] <ritz> but nice to have
[15:14] <Sweetshark> ritz: Right. So there is a source package locked and loaded at: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-oneirictest-20110718 -- It only needs the SRU redtape foo ...
[15:14] <ritz> mvo hi, https://wiki.ubuntu.com/UbuntuDebdeltaSupport . this seems interesting
[15:15] <ritz> How could I push for this out ?
[15:17] <Sweetshark> ritz: while few people (some ~300) are using the libreoffice-3-5 ppa this package has been tested there (with only a different version number) for a month now
[15:50] <sil2100> didrocks: can I redeploy and re-run unity8?
[15:50] <didrocks> sil2100: sure
[15:59] <didrocks> kenvandine: hey, btw, not sure if you published recently manually :)
[16:00] <didrocks> FYI, the publisher changed slightly its logic
[16:00] <didrocks> it will always retriggers all jobs
[16:00] <didrocks> to have "green" instead of "yellow/red"
[16:00] <didrocks> that will clear the view up
[16:00] <didrocks> if you used the command line tool, nothing will change, just ensure to have latest cupstream2distro
[16:01] <didrocks> if you did it directly on the webui, the "force publication" check is on the head job now, not on the publisher job anymore
[16:01] <didrocks> cyphermox: as well, FYI ^
[16:01] <cyphermox> cool
[16:07] <kenvandine> didrocks, cool, thanks
[16:37] <seb128> laney: oh, another detail ... "Time Zone" or "Time zone"?
[16:37] <seb128> the second one is the style we are supposed to use, I was just unsure of "TimeZone" is considered as a word
[16:37] <Laney> where?
[16:37] <Laney> oh, you mean the design is wrong?
[16:38] <seb128> Laney: we didn't have consistency so far but design confirmed recently we should use "sentence case" (e.g only capital for the start of the string)
[16:38] <Laney> should it be Time & date then?
[16:39] <seb128> I'm not sure when there is a "&"
[16:39] <Laney> mpt: ^?
[16:41] <Laney> fixed Time zone anyway
[16:41] <seb128> thanks
[16:41] <seb128> kenvandine, do you want to give a look to the cpp code from https://code.launchpad.net/~laney/ubuntu-system-settings/datetime-panel/+merge/176689 or should I just ack it?
[16:41] <seb128> (we can always fix bugs later)
[16:42] <Laney> what's the recommended api for the location detection bit?
[16:42] <Laney> qtmobility?
[16:42] <kenvandine> seb128, you can just ack it
[16:42] <kenvandine> Laney, i think it's qtlocation now
[16:42] <kenvandine> but i haven't used it
[16:42] <Laney> ok
[16:43] <Laney> not just hitting the geolookup web service then ;-)
[16:43] <seb128> Laney: qtlocation indeed, backend work is almost done, see https://code.launchpad.net/~thomas-voss/platform-api/add-location-service-api-take-2/+merge/173457
[16:44] <Laney> ok
[16:44] <Laney> I hope it works on the desktop
[16:44] <Laney> hate having to build on armhf
[16:44] <seb128> yeah, me too
[17:00] <seb128> laney, I still have https://code.launchpad.net/~seb128/ubuntu-system-settings/storage-store-sorting/+merge/176429 up for review if you feel like doing an easy one ;-)
[17:02] <Laney> seb128: yeah, can do
[17:02] <seb128> Laney: thanks
[17:02] <seb128> laney: I just approved your datetime, great work ;-)
[17:02] <seb128> next on my list is the language one
[17:02] <seb128> review list that's it
[17:03] <Laney> thanks
[17:04] <Laney> seems alm still didn't land
[17:04] <seb128> :-(
[17:08] <Laney> sabdfl http://www.oscon.com/oscon2013/public/content/video
[17:10] <seb128> laney: laggy here :/
[17:11] <Laney> :(
[17:11] <Laney> works quite fine for me
[18:17] <kenvandine> fginther, can you look at my CI failures for https://code.launchpad.net/~ken-vandine/libpam-freerdp/bootstrap/+merge/176751
[18:18] <kenvandine> the thin-client stack shouldn't be building for quantal CI and it's using some old config, nesting the debian dir
[18:18] <kenvandine> we've had CI succeed before... since inlining the packaging
[19:54] <fginther> kenvandine, sorry, got wormholed.
[19:54] <fginther> kenvandine, I'll get to it soon
[19:55] <kenvandine> fginther, thx... the branch has merged
[19:55] <kenvandine> but CI failed with the merge problem
[20:33] <robru> kenvandine, can you redeploy the misc stack from -config trunk? I can't do it because I'm not in ~system-settings-touch
[20:35] <kenvandine> robru, i just added you
[20:35] <robru> kenvandine, ah thanks
[20:36] <robru> I'll deploy then
[21:05] <mpt> Laney, Title Case for the top-level categories (e.g. Time & Date), Sentence case for everything lower (e.g. Time zone)
[21:09] <czajkowski> mpt: boo
[21:09] <mpt> You can't scare me, czajkowski, you're too far away.
[21:09] <czajkowski> mpt: did you like your M&Ms
[21:10] <mpt> czajkowski, you were here???
[21:11] <czajkowski> I was
[21:11] <czajkowski> didnt evan tel you they were from me :(
[21:12] <czajkowski> mpt: there was even cake!
[21:12] <mpt> Drat and tarnation
[21:12] <mpt> czajkowski, they melted slightly against my screen.
[21:13] <czajkowski> :o
[21:14] <czajkowski> we had yummy carrot cake from Kondor  & Cook, it said Thank you - was for wgrant and stevenk
[21:15] <mpt> So that's what happens when I go into a meeting room to work in peace and quiet. I miss out on carrot cake.
[21:17] <czajkowski> you snooze you lose
[21:17] <czajkowski> I sent M&Ms down to you
[21:18] <czajkowski> and you let them melt!
[21:18] <mlankhorst> O_O
[22:51] <poz> hi, anyone know how to change the transparency of unity dash with out unity tweek utility or compiz config
[22:51] <poz> ?
[22:57] <sarnold> poz: check this out: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L2233
[23:03] <poz> thanks sarnold, i will take a look