[04:28] c/c === pitti_ is now known as pitti [05:07] Good morning [06:12] are app previews supposed to be default in Unity now? This means an extra click just to open an app.... workflow is suffering [06:13] bkerensa: bug 1188656 [06:13] Launchpad bug 1188656 in unity (Ubuntu) "Bring back single left mouse click to open unity dash icons" [Undecided,Confirmed] https://launchpad.net/bugs/1188656 [06:53] thanks Mirv ;) (and hey!). What were the platform issues? (I saw the FTBFS, but didn't open) [07:01] didrocks: hey! there was some random apt-get update has mismatch error that had stopped qtubuntu build before it started [07:01] s/has/hash/ [07:02] Mirv: ok, so nothing that we can prevent? [07:02] probably not, if it was some delicate archive update timing issue [07:02] ok, thanks Mirv :) [07:02] you're welcome [07:10] good morning [07:11] salut jibel, ça va? [07:12] bonjour didrocks , ça va pas trop mal et toi? [07:13] jibel: ça va bien :) [08:01] hey there [08:03] Laney, good morning, how are you? [08:04] pretty good [08:04] just watched an epic 20 minute bird fight take place outside my house, that's a fun way to start the day [08:04] you? [08:05] ahah [08:06] just finished my first coffee, let fun day start but useful one :p [08:06] 6 magpies! [08:31] didrocks: so, the stack status: [08:32] didrocks: apps stack failed due to a flackyness of autopilot, we get that sometimes, I'll re-poke the guys about it, a re-run should be fine [08:33] didrocks: HUD is still basically 'blocked' on those two HUD failures, this seems like a real bug [08:33] didrocks: Ted was looking into that but I did not get a report from him and his findings [08:34] didrocks: I suspect it might be related to HUD <-> u-g-m support [08:34] (even though Ted added support for that lately) [08:34] sil2100, ted set up some merge requests to fix hud issues yesterday [08:34] https://code.launchpad.net/~ted/hud/bamf-focus-fix/+merge/168539 [08:34] https://code.launchpad.net/~ted/hud/proper-client-names/+merge/168518 [08:35] sil2100, you should retry once those fixes are merged in [08:35] seb128: will do, we'll have to get those reviewed first though [08:35] right, ping larsu/charles when they are online [08:36] seb128: thanks for pointing those out [08:36] didrocks: ^ [08:36] yw [08:37] sil2100, can you approve https://code.launchpad.net/~seb128/gnome-control-center-unity/correct-async-calls/+merge/168620 ? [08:37] didrocks: as for indicators... some prepare jobs failed, looks like a jenkins issue [08:37] seb128: looking [08:38] sil2100, it's a backport of a GNOME commit and I confirmed it fixes the segfault that happens if go appareance and click back on "all settings" [08:44] sil2100, thanks for reviewing it ;-) [08:48] Laney, https://bugzilla.gnome.org/show_bug.cgi?id=701964 [08:48] Gnome bug 701964 in Misc. "evolution-data-server provider not displayed in UOA." [Normal,Unconfirmed] [08:58] darkxst: It seems to work with NoDisplay=true [08:59] yeh sure, but upstream didnt seem to keen on adding a desktop file for e-d-s [08:59] it sounds like his concern is having it appear in launchers and stuff [09:02] Laney, ok [09:02] * Laney commented [09:21] didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/qa_add_missing_package/+merge/168627 [09:24] didrocks: this would unblock qa [09:25] didrocks: in the meantime, I go rest for some time [09:28] sil2100: did you relaunch indicators? [09:28] had* [09:29] doesn't seem so [09:29] I'll relaunch it with just indicator-datetime [09:30] sil2100: not sure what's up in unity though, did you look? [09:33] didrocks: I took a quick one, but it seemed like a lot of failures ;/ [09:33] No reason for those though === greyback is now known as greyback|shops [10:05] didrocks, sil2100: do you know what the autolander is unhappy about there? https://code.launchpad.net/~larsu/notify-osd/fix-1189281/+merge/168550 [10:05] is it due to the coverity issues? [10:16] seb128: I got similar issues with the medium job, I had to ask mmrazik/fghinter to disable it for another one [10:17] fginther, ^ === om26er is now known as om26er|away [10:33] sil2100: I relaunched the QA stack FYI after deploying === tkamppeter_ is now known as tkamppeter === MacSlow is now known as MacSlow|lunch [11:49] * didrocks wonders why getPublishedBinaries() doesn't take any status parameter compared to the doc… [11:54] * didrocks wonders why Launchpad is lying that much… [11:54] it's annoying, in that particular case :/ [11:57] In [1]: lp.distributions['ubuntu'].main_archive.getPublishedBinaries(binary_name='dconf', status='Superseded')[0].binary_package_version [11:57] Out[1]: u'1.6-0ubuntu1' [11:57] didrocks: ^? [11:57] Laney: I'm using the getPublishedBinaries over a source object [11:59] I don't see that the docs there claim that it takes a status parameter [12:00] Laney: argh, Ctrl + F failure, I was on the one in the archive, didn't notice I changed section [12:00] heh :P [12:00] (weird to have same function names, but different parameters support) [12:00] but still… ok :p [12:03] I have a weird problem with Chromium - for some reason it declines to offer to remember passwords for *some* sites on my company intranet that use HTTP Basic auth. Can anyone give me pointers to turning this into a less-than-useless bug report? (e.g. is there any way I can make it log potentially relevant stuff?) [12:03] Chrome works, fwiw [12:03] qengho: hey, any hint? ^ [12:07] oh, and I blew away my entire ~/.config/chromium/ to verify it's not some profile-related quirk [12:09] Mirv: any news on python-ubuntu-platform-api? this starts to block jibel and I running otto on the phablet :) [12:16] didrocks: the last fix to the packaging is now merged at lp:python-upa === MacSlow|lunch is now known as MacSlow [12:22] Mirv: want me to pre-NEW it? then we can add it to a stack? [12:26] * didrocks announces that now cu2d can now ignore some optional archs conditionnaly (if it's not published in archive or ppa, in the dest) [12:26] woot [12:30] didrocks, well done ;-) [12:30] thx :) [12:32] didrocks: yes, please. let's see if you spot anything, and please tell if you want those more cosmetic lintian errors silenced (sil2100 opted not to use lintian-overrides for those) [12:33] Mirv: sure, will do :) [12:38] Mirv: minor, but debian/copyright says 2012 and the headers are 2013 :) [12:38] Mirv: however, more annoying: the project rename wasn't done? [12:38] https://launchpad.net/python-upa [12:38] and source package is python-ubuntu-platform-api [12:38] IIRC, we agreed to that renamed [12:40] Mirv: as I don't build on armhf, do you have somewhere the build logs + lintian? [12:40] Mirv: this is all what I spotted on the source so far :) [12:41] word up, eurodudes [12:41] didrocks: I was wondering about the project name as well, didn't know it was agreed to be renamed [12:41] hey desrt, how is it going? [12:42] didrocks: I've the pbuilder logs, I can put them up [12:42] Mirv: oh, no worry, I'm stealing the autopilot ppa :) [12:42] didrocks: so you want project name renamed, or source package renamed? [12:42] binary-without-manpage -> we can ignore that :) [12:42] didrocks: great!! [12:42] Mirv: wdyt? I think the source package name makes more sense to me [12:42] didrocks: me too, ok [12:42] Mirv: let's do that [12:42] czajkowski: hey, around? [12:43] Mirv: ok, all look good otherwise, do you mind preparing the MP with the renaming needed in the package (+ the year typo in debian/copyright fixed?) [12:43] I'll coordinate with czajkowski about the launchpad side :) [12:49] didrocks: ok, will do, I created https://launchpad.net/python-ubuntu-platform-api though with the same maintainer/driver already :( [12:49] too fast [12:52] didrock back in a bit out at physio [12:52] Mirv: let's see how we can deal with it, no worry! :) [12:52] didrocks ^^ [12:53] czajkowski: just ping me once you are available, no worry! [12:53] didrocks: I could just push the trunk in there, and then we'd change configuration as needed. python-upa-team is fine as is. [12:53] Mirv: we need to move bug reports [12:54] hum, one fix committed bug [12:54] it's tempting :) [12:54] Mirv: let's do the branch change first and see how long it is for czajkowski to be back. If we can't do it before eod, let's move manually [12:54] sounds good? [12:54] sounds good [12:56] https://code.launchpad.net/~timo-jyrinki/python-upa/rename_project_update_copyright/+merge/168664 [12:58] Mirv: approved, just remain the cupstream2distro-config change and then redeploying the QA stack :) [13:01] didrocks: any chance at the precise SRU in near future, btw? your patch pilot turn last week was in the middle of saucy chaos.. [13:01] but there'd the next SRU already knocking at the door, so the previous would be nice to get out sooner rather than later [13:02] Mirv: yeah, I plan to do my patch pilot this week [13:03] Mirv: but seeing how active the SRU team is :/ [13:03] Mirv: I'm afraid that the raring second publish SRU is going the same road than the first one, isn't it? [13:03] Mirv: or did you see progress? [13:03] ok.. and yes, that's another thing altogether (although precise queue is quite empty) [13:04] didrocks: I did, in the sense they were looked at, I got the comments on the changelog cosmetic issues but they weren't synced still. I'm now waiting for a reply to my latest ping. [13:04] well, same people, so maybe they won't get to it as well… [13:04] it's sad to have a fix for unity touching netbooks for a month and half and still no review :/ [13:04] Mirv: ok, keep me posted! [13:04] maxb: The Way to avoid profile interaction is to run "chromium-browser --temp-profile", btw. [13:05] didrocks: I will [13:05] qengho: I'll bear it in mind for the future :-) [13:05] maxb: so, what are the versions of Chrome and chromium-browser? [13:06] 27.0.1453.110-r202711 and 25.0.1364.160-0ubuntu3 [13:06] (This is on raring, with the http://dl.google.com/linux/chrome/deb stable main repo) [13:10] qengho: btw, when can we get a new chromium? I need 26 for css transitions on pseudo elements :) [13:10] didrocks: Sorry, you're only getting 27. [13:11] didrocks: webapps patches aren't working right now, so once that's solved, it's in. [13:12] maxb: Hrm, okay. With a clean or temp profile, chromium doesn't offer to remember some passwords? [13:12] qengho: I can live with 27 (but not sure what's new I would need) :p [13:12] ogra_, stgraber, seb128 tells me you'd know about the operator-specific partition for customizations, is this specced out somewhere already? [13:13] qengho: That is correct. Unfortunately I've been unable to spot any obvious differences in the sites where it does vs. does not [13:14] mhr3, not specced at all yet ... stgraber should know whats planned for image based upgrades though [13:15] maxb: fun. Let's test something. $ chrome --user-data-dir=$(mktemp -d chromeXXXXXXXX) [13:15] stgraber, so any place where i could read about this? like how is it going to work, where will the partition be mounted, etc, etc? [13:15] maxb: and then use that new Chrome browser to log in to those sites too. [13:16] qengho: Well... actually with chromium-browse --temp-profile it doesn't seem to want to remember *any* passwords - though that's possibly because the "do you want to save the password" is being trumped by a "do you want to install the unity webapps plugin" ? [13:16] maxb: "Trumped"? They should stack. [13:17] OK, in that case it's just not appearing at all [13:17] ...I think. [13:17] So, you'd like me to test chrome with a different --user-data-dir? not chromium-browser ? [13:19] maxb: yes. I once had a extension that rewrote web pages to remove the autocomplete="no" from web pages. If your intranet has that, and your Chrome is changing it, but Chromium isn't, that could explain it. [13:19] OK, I'll try it, but all of the problems are with *HTTP* auth, so there shouldn't be any HTML involved? [13:20] maxb: oh. [13:21] Still, bare browsers, both and confirm. [13:21] google-chrome with --user-data-dir prompted and saved ok to gnome keyring [13:22] chromium-browser with --user-data-dir did not prompt [13:22] mhr3: the current plan is to have a path on the system partition that'd be reserved for such customizations. That path would have to always be empty in the base rootfs image, then we can have a second image that we stack on the base one with just that directory. [13:22] maxb: Interesting! That's definitely worthy of a bug report. Do you have a Launchpad account? [13:22] ~maxb [13:23] It is irksome that I've only managed to reproduce it with intranet sites [13:23] stgraber, ok, how will that path be exposed to apps/libs? or will we just change one of the XDG_ dirs? [13:23] maxb: agreed. :( [13:24] mhr3: no idea, I'm just providing an empty dir that additional images can dump stuff into. What's in there and how it's used is for someone else to figure out. [13:24] maxb: care to capture the headers on the response that signals auth is needed? [13:24] stgraber, who is that someone? :) [13:24] didrocks: regarding a bamf changelog fix I did (http://bazaar.launchpad.net/~unity-team/bamf/0.4/revision/538 - adding a LP: bug number and removeing repeating the same message), what should we do if we'd like to have the same 13.05.31 release in the SRU queue but with its changelog entry fixed? [13:25] didrocks: should we do manual uploads to SRU queue in those cases, for example dget:ing the version, fixing the changelog manually and uploading? [13:25] mhr3: I have absolutely no idea ;) I've been talking about that kind of stuff with lool so maybe he knows who's in charge of that side of things. [13:25] lool, ping? :) [13:26] stgraber, is at least the path already well known? [13:26] mhr3: no [13:26] maxb: okay, never mind. It looks like this is a bug that's fixed in v27. [13:26] Oh, heh [13:26] maxb: the upcoming update will fix you. [13:27] mhr3: as far as I'm concerned, it can be anywhere on the fs as long as we make sure never to write anything to it in the base image, was hoping that whoever was speccing that bit would suggest one :) [13:27] OK then. What was the factor that was somehow affecting only some sites? [13:27] maxb: no idea. [13:27] maxb: https://code.google.com/p/chromium/issues/detail?id=174199 [13:28] stgraber, and do you know who is speccing it out? [13:28] mhr3: wish I knew, lool is really your best bet at this point I think [13:29] Mirv: did we have any other update in bamf 0.4 since the 13.05.31? [13:29] didrocks: unfortunately yes [13:29] stgraber, k, will bother him once he's him, thx for help so far [13:29] s/him/here/ [13:29] maxb: As a workaround TRY putting your username in the URL. http://maxb@skunkworks.internal/hax0r [13:29] didrocks: so the question is what to do in such a situation where we'd like to have it still SRUed but with a fixed changelog [13:30] Mirv: hum, so yeah, manual upload in that case and MP to get that back in the 0.4 branch [13:30] didrocks: ok [13:30] For now I will work around it by saving the passwords in Chrome (having fiddled things such that Chrome and Chromium are using the same application ID to talk to gnome-keyring) [13:31] maxb: okay. Thanks for asking. [13:31] jbicha: hi, could you please check if lp:~jbicha/bamf/have-dev-depend-on-gir still merges with trunk? [13:32] mhr3: pong [13:33] lool, i'm trying to figure out if the operator-specific partition/image is specced out somewhere? [13:34] didrocks: should we consider some sort of system were SRU branch merges should be actually stalled until the previous published-to-queue one gets into the archives? it'd solve situations like this [13:34] mhr3: I've quickly scanned the backlog, I think you're asking about "partition for customizations"; I don't think we've defined the specific idea of a partition which would hold specifiically customizations, but we've had chats about customizations and about partitioning, would you mind going into more details on your top goals between these two? [13:36] Mirv: maybe, not sure if upstream would be happy about it though. Also, if it's stalled for a long time, we can have a lot of branches to merge in one shot. If there is a regression, we can't go back in history and see when the regression started to happen (which merge) [13:36] Mirv: so they are both pros and cons… [13:36] didrocks: true. just a thought in the air. [13:37] Mirv: I wonder if we can't have continuing build, and stalling "trunk maintenance branch" at the same time. Something to think about :) [13:51] stgraber: Ah I see now why mhr3 went to you, there are 2 efforts / projects which customizations will affect [13:51] stgraber: on one side e.g. unity teams for unity customization points (obviously) [13:51] stgraber: but on the other side there's the question of supporting customizations in the images [13:51] stgraber: right now our answer would be to build custom images and a custom distribution channel [13:52] stgraber: but that'd mean fragmentation and many images to maintain; what we could do is have some kind of overlay; in fact I think the current image updates would preserve additional files such as overrides in the image, but I wouldn't want us to rely on this [13:54] define overlay ... [13:54] ogra_: got a keyword on it? :p [13:54] we noticed that loop mounting images gives us a big performance hit [13:54] completely open for discussion :-) [13:54] I wouldn't want fs overlays I think [13:54] so we cant really use that [13:55] the other option i see for an overlay would be copying stuff in at boot time [13:55] which will make the boot slow [13:55] only the first boot though, yeah that could work [13:55] first boot only? [13:55] depends whether you copy stuff in the user data partition or in the system partition [13:56] lxc-android-config already ships an upstart job that creates the fstab on first boot ... (i doubt we'll keep it though, but as interim solution it could be extended) [13:57] lool: the plan so far as we discussed it at the sprint was to only allow customizations (both default config and extra apps) through a single integration point, which would be a specific path on the filesystem [13:58] stgraber, and how would youput that in place ? [13:58] lool: when flashing, we'd first apply the full image for the system, then another image which would only write to that path [13:58] ah, at install time [13:58] sounds more clever than first boot [13:58] ogra_: I'm not talking about an overlay, I'm talking about a simple directory that the various bits will have to look at [13:58] stgraber: I quickly grep-ed the wiki pages for "custom" but couldn't find this; did we capture this in the https://wiki.ubuntu.com/ImageBasedUpgrades.* wiki pages yet? [14:00] stgraber: if not, I guess we could followup on this discussion and capture the workflow [14:00] lool: nope, it's not mentioned in the current set of wiki pages because the spec itself covers it (we can have any number of tarball unpacked on top of any partition). I'm not against adding it to the spec explicitly but would prefer to have the rest of that feature specced by the relevant team first to make sure we didn't miss anything [14:00] stgraber: I think it's something we need to define along factory reset [14:00] to be clear, I really don't care how we do this and what goes in there, on my side, all I'll have to do is ship an extra tarball for those devices [14:01] stgraber: that's the thing, I'm not sure the tarball would be shipped [14:01] lool: won't affect factory reset as the data is stored on the system partition and so won't get wiped [14:01] stgraber: it might just be something we have somewhere at factory flash time, and then gets updated forever [14:02] lool: that'd work too. If a carrier/oem decides to only do partial updates, then they never have to ship a full tarball of those bits. [14:02] stgraber: so basically the approach is that we are careful to never mkfs, even when installing a full image, yes? [14:03] lool: no, when we get a full image, every bits have to be there, so we will format in that case then unpack the tarballs in the right order on top of the partition. [14:04] lool: what I'm saying is that a carrier who doesn't want to publish those bits as a tarball (which seems silly considering anyone can build the tarball from their own device anyway) will just have to stick to partial images only (which they're likely to want anyway) [14:04] in which case, we never reformat as we never have full images [14:08] stgraber: sorry, I think the use case I was describing wasn't clear [14:08] stgraber: currently we say that OEMs need custom images [14:09] stgraber: I'm saying it would be good to have a support path for official unmodified ubuntu touch images and distribution channels _with_ preserved OEM changes [14:09] stgraber: that is, there would be OEM customizations in the factory image, and then the device would get Ubuntu touch updates [14:09] lool: I never sayed and never thought we'd use custom images for OEMs [14:10] stgraber: so we'd point at two locations in the device OS updater config? one for OEM tarball and one for Ubuntu? [14:11] lool: not in the updater, in the index file on our server. An update can be made of any number of tar.xz files that can come either from our server or from an external server. [14:11] stgraber: so we'd know about every single OEM-ed / customized combination? [14:12] lool: for any device that uses our update server, yes [14:13] stgraber: the pro is that this allows us to update the OEM bits, the con is that it means we have a channel / set of hosted files / scripts etc. for each OEM / custom image out there which doesn't seem too scalable [14:13] seb128, didrocks: have you guys managed to get an alternate keyboard layout in the touch images? [14:14] mdeslaur: I never tried to investigate into that area. I think it should be possible with maliit, but didn't get time to look at it [14:15] didrocks: oh! we're using maliit? i thought it was onboard...ok, thanks, I'll poke some more [14:15] I guess it's ok as an initial approach for us to host tarballs and we can think about providing a more flexible option as an update [14:15] lool: well, technically the only extra hosted file would be the OEM customization so we won't waste much space, we won't need extra scripts per OEM either, we'll just need a rather massive loop that goes through every single channel and device to publish the update. [14:15] it doesn't change how customizastions themselves would be implemented anyway [14:15] mdeslaur: I'm 95% sure we are using maliit :) [14:16] lool: recent talks with slangasek, achiang, ... also showed that OEM/carriers are likely to want QA before any publishing, so we already need fine grained publishing for those [14:16] stgraber: I had conflicting reports there [14:16] stgraber: on one end of the spectrum, we'd want to be able to release different versions to different OEMs at different times [14:17] stgraber: at the other end of the spectrum, we'd want everyone to run the latest and the same Ubuntu, possibly with some OEM customizations on top, but up-to-date [14:17] stgraber: was this on some list? [14:17] stgraber: I guess we ought to settle this and put it on the wiki [14:17] lool: right, but there are legal/liability concerns and that's where we're stuck at for now [14:17] seb128 https://bugs.launchpad.net/ayatana-design/+bug/723864 , this dialog has been removed from gnome-keyring [14:17] Ubuntu bug 723864 in gnome-keyring (Ubuntu) "The alignment of the “[number of minutes] minutes” selector in the “Unlock Keyring” window is wrong." [Wishlist,Triaged] [14:18] stgraber: yup, and perhaps we will want both options, let's find out; one way to look at it is pleasing the OEM, another angle is building a strong product / avoiding fragmentation, both are valid view points and we need to arbitrate between the two [14:18] * lool brb [14:20] Mirv: sil2100: ok, renaming done, I'll add it to the QA stack, redeploy and rerun the stack [14:20] then sil2100, if everything pass, mind publishing? [14:25] stgraber: was the top-level dir for customization agreed upon? [14:37] lool: not that I know of [14:51] is this symbol drop ok? https://bazaar.launchpad.net/~ubuntu-desktop/evolution-data-server/ubuntu/revision/188 [14:55] seb128, FYI alesage is looking into https://code.launchpad.net/~larsu/notify-osd/fix-1189281/+merge/168550 [14:56] seb128, indeed I'm looking into, will ping === m_conley_away is now known as m_conley [15:02] fginther, alesage: hey, thanks [15:02] didrocks: ACK [15:05] jbicha, usual rule is to check if the symbol was in a public .h, if it was you should grep rdepends of the lib to see if any use it at least [15:07] Shotwell suddenly starting failing to build within the hour http://paste.ubuntu.com/5755143/ [15:08] jbicha, seems like a doko issue, ask on #ubuntu-devel? === Ursinha is now known as Ursinha-afk [15:17] anyone looked at doing a transition to libical 1.0? [15:21] * Riddell takes that as a no and goes ahead [15:21] not that I know of [15:22] make sure you build test rdeps first ;-) [15:24] yeah that's what I'm doing now [15:25] about 20+ of them :( [15:25] dednick, hi [15:26] do you know if the new format for the indicator manifests is merged into libindicator? [15:27] charles_, ping [15:28] attente: it's merged into trunk... [15:28] larsu, oh... [15:29] thanks [15:30] Sweetshark, qengho, Laney, mlankhorst, tkamppeter, attente, desrt, larsu: hey, it's meeting time [15:30] YAY! [15:30] i love meeting!!! [15:30] ohai [15:30] oh, qengho is there this week ;-) [15:30] qengho, yay to you ;-) [15:30] Ahem. :P thpppt. [15:30] so it is [15:30] good that you are here I've a bug for you ;-) [15:31] let's get started [15:31] qengho, your turn ;-) [15:31] ooh meeting [15:31] * Trying to get chromium 27 released. To do: [15:31] - get #webapps' patches updated. Blocked. [15:31] - fix startup crasher on ARMHF. [15:31] * Getting feedback on an extension installer package. [15:31] EOF [15:32] qengho, one thing to add to your list ... chromium in saucy has no menu at al ... what happened to the patch attente gave you in London? [15:33] seb128, i told him it wasn't necessary because u-g-m hadn't landed [15:33] well, u-g-m has finally landed... [15:33] attente: did you plan to make a patch to do it The Right Way? [15:33] when can we expect the default browser flamefest? :-) [15:33] Laney: soon. [15:34] Laney: Like within hours. [15:34] * Laney yessssssss [15:34] qengho, yes, i still have to do it the Right Way, but i wonder if you can re-apply the patch in the mean time? [15:34] attente: yes, I will apply it to S v27. [15:35] attente: I will not plan to send it upstream, though, okay? [15:35] qengho, thanks, definitely agreed on that point [15:35] qengho, you don't plan to make an upload before v27 I guess? Not sure how long it will take to fix webapps and armhf and if we want to keep menus missing during that time [15:37] seb128: If it takes more than a few days, i'll get older updated. [15:37] attente: u-g-m? [15:37] qengho, thanks [15:37] Riddell, unity-gtk-module [15:37] Riddell, that's what replaces our hackish gtk patch for unity exported menus [15:38] I'm done. I hope everyone doesn't take as long as mine. [15:38] qengho, thanks [15:38] Laney, hey [15:38] yo [15:38] echo << EOF [15:38] • Finshed GLib upload; split out tests into libglib2.0-tests package. TODO: sync packaging back to experimental & package test runner if people think it would be useful (pitti?). [15:38] • Various bugfixes (wayland, nautilus, ...) [15:38] • One or two GNOME updates [15:38] • Fixed a git-annex regression we accidentally introduced in raring [15:38] • Fair bit of poking at system settings; integrated my previous appearance work with the panel. Pushed it to lp:~laney/+junk/appearance-panel with packaging. Should install and appear in system-settings (but not do anything yet) if you want to try it. Found some UI toolkit oddities / bugs / things I don't know how to do, such as ... [15:38] ... http://askubuntu.com/questions/306868/how-do-i-get-an-ubuntushape-to-transition-fade-between-different-images (help welcomed) [15:38] • Talked a bit about gstreamer 1.1 - I'm interested in taking it because it makes a lot (not all) of our plugin moves obsolete. [15:38] EOF [15:39] Laney, I will check out your panel for sure [15:39] * seb128 adds to todolist [15:39] it is mainly just QML stuff [15:40] I still have to make it nice and reusable and actually do things [15:40] but it's a start [15:40] Laney, where/with who did you discuss gstreamer1.1? what's their release schedule? [15:40] just chatted to slomo, and they don't really have one other than "release when ready" [15:40] need to update it in experimental first anyway [15:41] ok ... is that going to change apis/requiring porting for apps? [15:41] shouldn't do [15:41] cool [15:41] Laney, thanks [15:41] 1.x is suppose to be compatible within itself [15:41] mlankhorst, hey [15:41] getting nvd7 working on nouveau without requiring external firmware, stack in lts-raring, general sru's, attempting to make Xorg -gpu 1 work correctly (optimus mode), generic nouveau bugfixing [15:41] ^D [15:41] mlankhorst, thanks ;-) [15:41] tkamppeter, hey [15:42] seb128: it's compatible with 1.0, just adding new features [15:42] slomo, great, thanks ;-) [15:42] seb128: while 1.0.x only adds bugfixes [15:42] - Installed Saucy on a virtual and a real iron machine, the latter is my Lenovo Thinkpad Twist ultrabook with Raring on the built-in SSD and Saucy on a USB 3.0-connected SanDisk Cruzer Extreme USB 3.0 USB stick 64GB, the stick is nearly as fast as a built-in SSD. [15:42] - Packaged CUPS 1.7b1 and uploaded to my PPA for both Raring and Saucy for testing. Announced on ubuntu-devel. [15:42] - Updated Ricoh and OEM PPDs and packages on OpenPrinting [15:42] - Synced cups-filters and foomatic-db from Debian [15:42] - Checked existing patches for on-demand startup of CUPS (for systemd and xinetd) and asked authors for copyright agreement with Apple for upstream inclusion. [15:42] - Answered and triaged printing-related bug reports [15:43] tkamppeter, thanks [15:43] attente, hey [15:44] seb128, hi [15:44] finished indicator-keyboard svg generator [15:44] the recent ibus issue seems to be because of the gnome-desktop-3 update to 3.8 [15:44] working on targeting the region text entry panel to g-c-c and g-s-d 3.8, but introduces some other bugs (no shortcut IM switching, region panel crashes when trying to add an input source) [15:44] EOF [15:44] attente, what change in gnome-desktop that created the issue? [15:45] seb128, in libgnome-desktop, there were some functions removed from the api [15:45] hum, anything you need and that we should add back? [15:45] functions that g-s-d 3.6 needed [15:46] did we break g-s-d with that update? [15:46] seb128, i'm not sure what the better approach is here, to continue with 3.6 or 3.8 [15:46] for g-s-d/g-c-c [15:46] seb128, it only seemed that the region support with ibus broke from what i could tell [15:46] I would keep my recommendation for earlier in the cycle [15:46] get it to work on 3.6 [15:47] we are not close to update to 3.8 yet and we can't work on a moving target [15:47] seb128, ok, will do [15:47] I know jbicha and the GNOME guys want g-s-d/g-c-c 3.8 but that's just not there yet [15:47] so let's land that first, we can forward port later then [15:47] darkxst said yesterday he thought we could use g-s-d 3.8 with g-c-c 3.6 (with a few patches for like dbus changes) [15:47] that would be a good first step ;-) [15:48] let's settle down the current issues and try to get nautilus 3.8 in [15:48] then we can look at g-s-d/g-c-c [15:49] attente, what is missing for the indicator to work? (still need to try that, should be easier now that we got the new glib and your gdk/gtk backport in saucy) [15:49] nautilus has just 2 remaining issues (missing New Document from the right-click menu and figuring out desktop background handling with compiz) [15:49] jbicha, yeah, it's the background one that I wonder about ... maybe we can re-enable the g-s-d plugin and be done with it [15:49] need to test that [15:49] seb128, if we're sticking to g-c-c/g-s-d 3.6, then the only thing left is for me to fix this ibus issue [15:50] attente, ok, let's say that's the plan for now then [15:50] seb128, many *-tweak-tool users would appreciate having the g-s-d background plugin re-enabled ;-) [15:50] attente, thanks [15:50] robru, seems so indeed [15:51] attente, oh, and well done on finally getting u-g-m installed by default, it went well, I didn't see any complain yet [15:51] desrt, hey [15:51]