[00:03] I found a bug in the dash === sam113101 is now known as sam113101_afk === sam113101_afk is now known as sam113101 [04:14] Good morning [04:40] jibel, gtk is failing autopkgtests in notify-osd, would you be able to have a look at that? [04:40] we were hoping to get this update into alpha2 [06:26] 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] robru: oh, that's so sad! let me approve it then :) [06:29] robru: only because of the smiley :p [06:29] hahah [06:30] done ;) [06:30] thanks robru! [06:30] didrocks, thanks [06:30] robru: once merged, you will prepare the cu2d-config? [06:30] (probably your tomorrow) [06:31] didrocks, oh, what needs to be done in -config? [06:31] robru: adding the new component [06:31] it's not in yet, right? [06:31] (for daily releases) [06:32] didrocks, hmmm, well it has no autopilot and I don't see any tests running during build... should it be daily released? [06:32] robru: yeah, it's a simple settings package, should be part of misc I guess [06:33] didrocks, hmmm, let me do that now, because I want you to review it before you leave today [06:33] ok ;) [06:33] robru: you will need to poke fginther for setting up the upstream merger part though [06:36] 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] robru: I think that's fine, I'm not sure if the upstream merger needs more TBH… [06:38] robru: so, let me approve it, please check with fginther once he's online to set up the upstream merger [06:38] robru: and then, you can redeploy the stack to add the component to tomorrow's daily [06:38] sounds good? [06:38] 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] didrocks, ok [06:39] robru: yeah, sounds like the case, he needs to create the CI part anyway ;) [06:49] didrocks, hmmm, how do I fix this? http://paste.ubuntu.com/5906637/ [06:51] robru: you need to be in the team [06:51] bah! [06:51] Laney: can you add robru to ~system-settings-touch? [06:51] is it worth joining the team (since this isn't my usual stack) or should I just let somebody else do this? [06:51] robru: well, can be easier in case you need to deploy :) [06:51] ok [06:54] good morning [06:54] salut jibel [06:58] jibel: mind doing a quick review? http://paste.ubuntu.com/5906654/ [06:59] jibel: the corresponding change to cu2d-run is http://paste.ubuntu.com/5906657/ [07:04] Salut didrocks [07:08] didrocks, I am not sure about the change in cu2d-run, I need to look at the code in its context [07:09] jibel: I've already ran it, it's just using the "head" job now for everything [07:10] 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] jibel: http://paste.ubuntu.com/5906678/ [07:13] the full command [07:13] I've moved jobname up now [07:13] as we are always using head [07:15] didrocks, it is different from the patch, but LGTM :) [07:15] didrocks, approved [07:16] 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] jibel: thanks! [07:16] deploying all the stacks and pushing [07:24] Trevinho: woah, bamf support for qmlscene?! [07:24] I thought we wanted to have a proper launcher instead of relying on qmlscene [07:27] bienvenue à les premiers langpacks pour saucy ! [07:27] hey larsu, wie gehts? [07:30] pitti: sehr gut danke! Will sign a lease for an appartment in Berlin today :) [07:31] pitti: wie geht's dir? [07:31] larsu: oh, not homeless any more! :-) [07:31] larsu: sehr gut, danke [07:31] pitti: yeah! Now I have a home (with nothing in it :D) [07:36] Hi desktoppers! [07:36] hm, I noticed appmenu-gtk stopped building in the PPA because of the lack of gtk/ubuntumenuproxy.h [07:36] Did something change? Or is appmenu-gtk so deprecated that it won't build anymore? [07:37] sil2100: it depends on a patch in gtk that got dropped [07:37] good morning desktopers [07:37] seb128: morning! [07:37] hey sil2100, larsu [07:38] larsu: oh, so maybe it would be wise for me to disable it from daily release then? [07:38] sil2100, what larsu said, the source got dropped from saucy recently, we should probably stop daily building it as well [07:38] Right [07:39] sil2100: yep :) [07:45] seb128, larsu, didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/drop_appmenu-gtk/+merge/176615 [07:45] If it's ok, I'll be redeploying indicators and re-running, since appmenu-gtk was blocking the release [07:45] hey seb128, sil2100, larsu [07:45] and pitti [07:45] didrocks, lut [07:45] Hi! \o/ [07:45] sil2100: before redeploying, ensure to merge to trunk ;) [07:45] didrocks: good morning didrocks! [07:46] woah, double-ping [07:46] :) [07:46] 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] didrocks, https://code.launchpad.net/~sil2100/cupstream2distro-config/drop_appmenu-gtk/+merge/176615 seems fine to me? [07:46] sil2100: I don't even know what this does... so I'll let didrocks handle the MR [07:46] sil2100: ok, thanks [07:46] didrocks, that's not covered in the faq, seems weird that it needs a new file just to drop a component? [07:46] sil2100: if it's still broken, please let me know [07:47] thomi: thanks guys! [07:47] sil2100: no worries [07:47] one of those problems was really hard to track down :) [07:47] seb128: I think sil2100 wants still to have the upstream merger in [07:48] 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] ;) [07:48] Having autolanding is not a bad thing for now [07:50] didrocks: ok, merged in trunk and now redeploying \o/ [07:55] didrocks: hmmm [07:56] didrocks: strange thing happened [07:56] didrocks: I redeployed the indicators stack for head, but it still has appmenu-gtk in it? [07:56] sil2100: is the strange thing linked to my modification from the morning? [07:56] sil2100: yeah, the jobs aren't removed [07:56] sil2100: it's just "unplugged" [07:56] so that you can still track the history [07:56] you need to remove it manually [07:56] (the prepare job itself) [07:57] didrocks: do I have to remove the prepare job for the check job to not notice it? [07:57] didrocks: maybe I need to rebuild the stack without 'foo', since it's still looking for appmenu-gtk [07:58] sil2100: no, you don't need to remove the prepare job, it's already unplugged [07:58] sil2100: so, just rebuild with foo [07:58] ah [07:58] yeah, indeed [07:58] you need to remove .project file [07:58] or rebuild the whole stack [08:00] * sil2100 removed the .project file and re-ran [08:00] sil2100: so, I changed the "force publication" mecanism [08:00] if you use the command line tool, no change for you [08:00] (just ensure you have the latest cupstream2distro) [08:00] didrocks: I noticed that it's available on the head job as well [08:01] it's only available on the head job now [08:01] Ah [08:01] \o/ unity landing [08:01] that way, we'll get "green" everywhere in the stack [08:01] seb128: yes, yesterday it landed ;p I mean, I forcefully landed it :< [08:01] no more "yellow" even if published [08:01] bonjour seb128 [08:01] sil2100, what was the issue/how did it get unblocked? [08:01] pitti, salut, ça va bien ? [08:01] it's in proposed, right? [08:01] blocked manually by Laney I guess [08:01] le vert, le vert pour tous le monde ! [08:01] hello [08:01] didrocks, a2 block I guess [08:02] seb128: oui, merci ! et toi ? [08:02] Laney, good morning [08:02] seb128: oh, right, for lubuntu maybe [08:02] Laney: good day! [08:02] pitti, ça va bien, merci ;-) [08:02] 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] phew [08:02] didrocks: \o/ [08:03] didrocks: so, even when using the CLI tool, the head job will turn green then? [08:03] sil2100: yep [08:03] 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] didrocks,ubuntukylin rather I guess [08:03] (they use unity) [08:04] Laney: no, it just prevent having an override for one line [08:04] seb128: ah ok [08:04] seb128: btw, I already preNEWed the settings package from Laney? [08:04] seems weird and less self documenting [08:04] didrocks, is that a question? ;-) [08:04] argh, brain broken [08:04] it was: [08:05] seb128: btw, *did you*… [08:05] didrocks, yes [08:05] great, so should be there as soon as fginther setup the upstream merger [08:05] am I supposed to merge this branch or wait for that? === Ursinha-afk is now known as Ursinha [08:07] Laney: I think it will be the right timing to check to test fginther deployement :) [08:07] k === tkamppeter_ is now known as tkamppeter === ivanka-train is now known as ivanka [08:27] didrocks: hm, the mirslave check job seems to be hanged for ati [08:27] didrocks: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/583/label=autopilot-ati/console [08:28] didrocks: it's not moving, and it blocks other AP tests [08:28] sil2100: indeed, it seems that the tests didn't start [08:28] sil2100: let me ssh [08:28] sil2100: well, it will block until the timeout… [08:28] The timeout is quite large ;) [08:28] sil2100: I don't remember, still 2 hours? [08:28] sil2100: or did we keep a higher value for your dbus issue? [08:29] No idea, hm, I always thought it's till 2 hours for all, but maybe it's not? [08:29] sil2100: so 2h is needed, see the time taken by unity tests… === tim___ is now known as vorpalbunny === LordOfTime is now known as LordOfTime|EC2 === vorpalbunny is now known as thumper === jasoncwarner__ is now known as jasoncwarner_ === e11bits_ is now known as e11bits === thumper is now known as thumper-afk [08:31] sil2100: ok, I'm powering that off [08:32] didrocks: ok, thanks :) [08:32] will retry after those tests ran [08:32] Sweetshark: hi. i am sorry that i just overlooked/ignored your mail regarding libreoffice 4.1.0 rc1. === seb128_ is now known as seb128 [08:32] Sweetshark: do you want to update the branch to rc4? [08:33] Sweetshark: do you want to merge debian-experimental-4.1? [08:35] 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] bdrung: it already merged debian-experimental-4.1 quite recently. [08:39] Sweetshark: then it doesn't seem to be pushed to alioth. === mvo__ is now known as mvo [08:42] sil2100: it seems the ati machine is screwed, no? [08:42] weird that we only see this on the ati machine [08:42] didrocks: it happened on intel today as well [08:42] sil2100: a race in distro? what changed? [08:43] it's the same snapshot than yesterday though [08:43] 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] jibel: you didn't change anything on the machines, right? ^ [08:49] FJKong: welcome to our team! [08:51] #sil2108 thank you very much :) [08:51] sil2100, thank you [08:52] welcome FJKong :) [08:52] hey FJKong, welcome to the desktop team! [08:52] FJKong: task #1: learn French [08:52] :o [08:53] salut Monsieur FJKong, bienvenue à l'équipe de bureau ! [08:53] * sil2100 doesn't know French yet! [08:54] ah but you put it in your annual objectives, yesyes? :P [08:54] FJKong, hey, welcome on board! [08:55] pitti, French sounds good, symbol of romantic. [08:55] thank you guys, happy to meet you here. [08:58] wtf [08:58] maliit "general packaging cleanup" -> throw away everything that was there before and start again [08:59] who did that? [08:59] oh, rsalvati [08:59] yes [08:59] weird [08:59] he's usually doing reasonable changes [08:59] quite annoying [09:00] rsalveti, ^ can you explain why you redid the packaging? (I guess you are sleeping, but later when you read the backlog) [09:00] I guess it's what was in the phablet branch [09:01] well, that's an upload to the archive, they should have rebased on the archive version [09:01] not the other way around [09:02] you'd think... [09:04] that's also the packaging that's in debian ^o) [09:06] let's wait for rsalveti [09:06] no need to speculate about the reasons [09:08] wasn't [09:10] Laney, btw, I reviewed your tz merge proposal [09:10] Laney, that list is crazy :p [09:11] haha [09:11] it'll only be displayed when you type something in the box [09:11] it better does that, if you don't want to spend your day scrolling down ;-) [09:16] will do that after reviewing the diagnostics branch again [09:17] 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] 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] somehow i expected that answer [09:19] ;-) [09:27] * Laney eyes the PS Jenkins bot [09:29] Laney: what about it? [09:29] there's something off in its chroot [09:29] https://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-saucy-amd64-ci/148/console [09:30] Laney: ah, I thought you meant the upload in proposed [09:30] 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] no, don't know anything about any upload [09:30] not sure I want to :P [09:31] ogra_, well i just want a build id, surely once we don't have android bits we still need it [09:32] mhr3, well, then the ubuntu image build id is probably the best === tkamppeter_ is now known as tkamppeter [09:33] ogra_, then again we want it so the individual operator variants can be distinguished, so not exactly :) [09:33] and that file is also compatible with i.e. debian-installer or ubiquity installations [09:34] well, then you need the id from the props i guess [09:34] btw, i wouldnt expect the edge to work differently from the nexus images we have today [09:35] we will have more access to the binary blobs there but i wouldnt expect the concept to change to radical here === thumper-afk is now known as thumper [09:38] ogra_: mhr3: there is another file we use for oem/sku distinguishing. [09:38] xnox, in the cdimage generated builds ? [09:38] xnox, there is? [09:38] i dont think we did put any stamp info inside until i implemented the above one [09:38] 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] right [09:39] ogra_: but using same stamp as oem-config will make it compatible between phone/desktop installs. [09:39] 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] ogra_: var/log/installer/oem-id [09:41] ah === psivaa_ is now known as psivaa [09:42] 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] 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] xnox, ah, that why i never saw it on arm installs [09:44] we never ran the preparation step there but instead started directly into the config [09:44] 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] Laney, did you get a reply from anyone on the CI chroot issue? [09:49] seb128: nope, who/where is the place to ping about that? [09:49] sil2100, ^ can you help? [09:52] seb128: this is the upstream merger [09:53] I doubt sil2100 can help [09:53] didrocks, that's fginthers? [09:53] I think you need to ping fginther/alesage… [09:53] yeah [09:53] thanks [09:53] that was the question "who to ping" ;-) [09:54] Sadly, all the upstream merger people are US based... [09:54] This is a bit sad I must say [09:54] that's why I try to avoid the CI word [09:54] but it seems I'm in the minority [09:54] anyway… [09:55] oh, I know what's the issue is [09:55] hum, or not [09:55] Laney, oh, I know [09:55] Laney, you need libtimezonemap >= 0.4.0.1 or that version is only in proposed and CI doesn't use proposed [09:56] so it fails to install the requirement [09:56] why is it going on about python? [09:56] I don't know, apt errors on install fail can be confusing [09:57] didn't we make the daily releases use proposed now anyway? [09:57] pbuilder-satisfydepends-dummy : Depends: libtimezonemap1-dev (>= 0.4.0.1) but it is not going to be installed. [09:57] ... [09:57] Laney, CI != merger [09:57] yes [09:57] but they should use the same sources [09:58] we have been going forth and back on that [09:58] I didn't follow closely what was decided, they both have issues [09:59] Laney, can you unblock libmaptimezone out of proposed? [09:59] 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] it doesn't seem there is any reason to hold it in there, it's not a disruptive update [10:01] Laney, there doesn't seem to be an issue with proposed, what do you mean? [10:02] the argument against enabling proposed there [10:03] 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] I'd rather unblock it than do that [10:03] but I'd rather have to do neither [10:03] 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] still, I'll unblock [10:03] not convinced this is the only problem though :-) [10:03] thanks [10:04] let's see [10:04] I just tried in a pbuilder [10:04] which suggests it is [10:04] not sure why python is listed in that log though [10:18] didrocks: packages list refreshed! [10:18] didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_check_to_unity8/+merge/176407 [10:18] didrocks: it tests on jenkins, so it's ok [10:18] (there are some failures though) [10:18] Test failures [10:18] 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] and* [10:18] sil2100: you did ping him? [10:19] didrocks: will to ;) But I guess the branch is OK for approval in the meantime [10:19] sil2100: DONE [10:19] didrocks: THX :D [10:20] Laney, CI just acked https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-design-update/+merge/176645 for me [10:20] Laney, which suggests the chroot is fine, it's just getting unhappy about the libtimezone thing [10:20] it's in saucy now so let's see [10:21] if it triggers itself [10:21] you might need to change the status of the mp to retrigger a CI run [10:21] or ping fginter/alasage [10:22] i'll wait until it is on the mirror [10:22] ok [10:23] * Laney dives into FilterProxy hell === vrruiz_ is now known as rvr === MacSlow is now known as MacSlow|lunch [11:43] desrt, ping [11:57] Saviq: hey [11:57] desrt, hey, I stumbled upon an issue with Gio.Settings.new_with_path [11:58] desrt, it seems to require trailing slash [11:58] that's correct [11:58] dconf and gsettings have a very strict concept of what is a pathname and what is a keyname [11:58] and pathnames always require trailing slashes to identify them as such [11:58] it's because in dconf you can have both /a and /a/b [11:58] desrt, would it make sense to error out if it doesn't? [11:58] so /a is the key and /a/ is the path containing 'b' [11:59] Saviq: i think so... they are two different entities [11:59] desrt, so yeah, new_with_path takes it in blindly [11:59] desrt, and then the path is simply concatenated with the key value when you set_ it [11:59] ohhh [11:59] ouch! [11:59] ya. that is a bug [11:59] please file that [11:59] thanks [11:59] desrt, which project? [12:00] glib [12:00] desrt, doing [12:00] https://bugzilla.gnome.org/enter_bug.cgi?product=glib in case you didn't find it already :) [12:04] desrt, https://bugzilla.gnome.org/show_bug.cgi?id=704802 [12:04] Gnome bug 704802 in gsettings "new_with_path deosn't check for trailing slash in path" [Normal,Unconfirmed] [12:04] Saviq: thanks === MacSlow|lunch is now known as MacSlow [12:20] Laney, easier to discuss it, what's the advange of an enum there? the enum helps to translate numbers to names right? [12:20] discuss it *here* [12:20] seb128: yes, readability, I'm sure your one works too [12:20] Laney, in that case I just want to store/read the number [12:20] well, I couldn't do index = key [12:21] I would need to do (sort == "name") ? 1 : 0 [12:21] yep [12:21] you think it would be easier to read? [12:22] that's basically what my first version with the boolean do btw [12:22] https://code.launchpad.net/~seb128/ubuntu-system-settings/storage-store-sorting/+merge/176429 [12:22] Feels that way but not sure [12:22] yeah it's like that but more extensible [12:22] I don't mind though - do what you think is best [12:22] I don't foresee any other option to be added there [12:22] ok, let's accept the boolean one then [12:22] just responded to you asking if it was nice [12:23] ok, in a bit though - getting this fitlering to work [12:23] sure, thanks [12:33] seb128, Laney: good morning guys [12:33] desrt, hey [12:33] how are you? [12:33] howdy desrt [12:33] pretty good [12:34] * desrt has his coffee ;) [13:01] 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] you can see the bzr log for the packaging branch [13:02] also, afaik sergio tried to make this compatible with what we had before [13:02] rsalveti, seems like that packaging branch had a packaging different from the one from the archive/Debian [13:02] it's just that upstream is kind of broken at this moment [13:02] is debian using 0.99 as well? [13:02] * rsalveti checks [13:02] updating the version usually don't need to redo debian/ [13:03] just to bump changelog and adapt depends and stuff [13:03] right, but everything changed with 99 [13:03] drop support for gtk [13:03] moving from qt4 to qt5 [13:03] and such [13:03] I was trying to keep the packages the same [13:03] I'd have helped review and sponsor any update into Debian [13:04] I'm not sure you want .99 in debian at this point [13:04] it's only in experimental as is [13:04] it only works for us because we'll be pushing a touch specific keyboard [13:04] even the examples, from maliit-plugins is sort of broken =\ [13:04] right from upstream [13:05] 94 -> 99 is a major change [13:06] so the package is going to be useless for any other consumer than touch for now? [13:06] Laney: yes [13:06] because that's the state of upstream [13:07] it's not the state of what we had before in the archive though [13:08] 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] 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] phew [13:19] filtering works! [13:20] Laney, well done ;-) [13:20] the list data isn't great though [13:20] hm, no qtdeclarative5-dev for ppc [13:21] rsalveti, v8 doesn't exit on ppc [13:21] exist [13:21]