[04:28] <TheMuso> c/c
[05:07] <pitti> Good morning
[06:12] <bkerensa> 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] <jbicha> bkerensa: bug 1188656
[06:13] <ubot2`> 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] <didrocks> thanks Mirv ;) (and hey!). What were the platform issues? (I saw the FTBFS, but didn't open)
[07:01] <Mirv> didrocks: hey! there was some random apt-get update has mismatch error that had stopped qtubuntu build before it started
[07:01] <Mirv> s/has/hash/
[07:02] <didrocks> Mirv: ok, so nothing that we can prevent?
[07:02] <Mirv> probably not, if it was some delicate archive update timing issue
[07:02] <didrocks> ok, thanks Mirv :)
[07:02] <Mirv> you're welcome
[07:10] <jibel> good morning
[07:11] <didrocks> salut jibel, ça va?
[07:12] <jibel> bonjour didrocks , ça va pas trop mal et toi?
[07:13] <didrocks> jibel: ça va bien :)
[08:01] <Laney> hey there
[08:03] <seb128> Laney, good morning, how are you?
[08:04] <Laney> pretty good
[08:04] <Laney> just watched an epic 20 minute bird fight take place outside my house, that's a fun way to start the day
[08:04] <Laney> you?
[08:05] <seb128> ahah
[08:06] <seb128> just finished my first coffee, let fun day start but useful one :p
[08:06] <Laney> 6 magpies!
[08:31] <sil2100> didrocks: so, the stack status:
[08:32] <sil2100> 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] <sil2100> didrocks: HUD is still basically 'blocked' on those two HUD failures, this seems like a real bug
[08:33] <sil2100> didrocks: Ted was looking into that but I did not get a report from him and his findings
[08:34] <sil2100> didrocks: I suspect it might be related to HUD <-> u-g-m support
[08:34] <sil2100> (even though Ted added support for that lately)
[08:34] <seb128> sil2100, ted set up some merge requests to fix hud issues yesterday
[08:34] <seb128> https://code.launchpad.net/~ted/hud/bamf-focus-fix/+merge/168539
[08:34] <seb128> https://code.launchpad.net/~ted/hud/proper-client-names/+merge/168518
[08:35] <seb128> sil2100, you should retry once those fixes are merged in
[08:35] <sil2100> seb128: will do, we'll have to get those reviewed first though
[08:35] <seb128> right, ping larsu/charles when they are online
[08:36] <sil2100> seb128: thanks for pointing those out
[08:36] <sil2100> didrocks: ^
[08:36] <seb128> yw
[08:37] <seb128> sil2100, can you approve https://code.launchpad.net/~seb128/gnome-control-center-unity/correct-async-calls/+merge/168620 ?
[08:37] <sil2100> didrocks: as for indicators... some prepare jobs failed, looks like a jenkins issue
[08:37] <sil2100> seb128: looking
[08:38] <seb128> 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] <seb128> sil2100, thanks for reviewing it ;-)
[08:48] <darkxst> Laney, https://bugzilla.gnome.org/show_bug.cgi?id=701964
[08:48] <ubot2`> Gnome bug 701964 in Misc. "evolution-data-server provider not displayed in UOA." [Normal,Unconfirmed]
[08:58] <Laney> darkxst: It seems to work with NoDisplay=true
[08:59] <darkxst> yeh sure, but upstream didnt seem to keen on adding a desktop file for e-d-s
[08:59] <Laney> it sounds like his concern is having it appear in launchers and stuff
[09:02] <darkxst> Laney, ok
[09:02]  * Laney commented
[09:21] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/qa_add_missing_package/+merge/168627
[09:24] <sil2100> didrocks: this would unblock qa
[09:25] <sil2100> didrocks: in the meantime, I go rest for some time
[09:28] <didrocks> sil2100: did you relaunch indicators?
[09:28] <didrocks> had*
[09:29] <didrocks> doesn't seem so
[09:29] <didrocks> I'll relaunch it with just indicator-datetime
[09:30] <didrocks> sil2100: not sure what's up in unity though, did you look?
[09:33] <sil2100> didrocks: I took a quick one, but it seemed like a lot of failures ;/
[09:33] <sil2100> No reason for those though
[10:05] <seb128> 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] <seb128> is it due to the coverity issues?
[10:16] <didrocks> seb128: I got similar issues with the medium job, I had to ask mmrazik/fghinter to disable it for another one
[10:17] <seb128> fginther, ^
[10:33] <didrocks> sil2100: I relaunched the QA stack FYI after deploying
[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] <didrocks> it's annoying, in that particular case :/
[11:57] <Laney> In [1]: lp.distributions['ubuntu'].main_archive.getPublishedBinaries(binary_name='dconf', status='Superseded')[0].binary_package_version
[11:57] <Laney> Out[1]: u'1.6-0ubuntu1'
[11:57] <Laney> didrocks: ^?
[11:57] <didrocks> Laney: I'm using the getPublishedBinaries over a source object
[11:59] <Laney> I don't see that the docs there claim that it takes a status parameter
[12:00] <didrocks> Laney: argh, Ctrl + F failure, I was on the one in the archive, didn't notice I changed section
[12:00] <Laney> heh :P
[12:00] <didrocks> (weird to have same function names, but different parameters support)
[12:00] <didrocks> but still… ok :p
[12:03] <maxb> 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] <maxb> Chrome works, fwiw
[12:03] <didrocks> qengho: hey, any hint? ^
[12:07] <maxb> oh, and I blew away my entire ~/.config/chromium/ to verify it's not some profile-related quirk
[12:09] <didrocks> Mirv: any news on python-ubuntu-platform-api? this starts to block jibel and I running otto on the phablet :)
[12:16] <Mirv> didrocks: the last fix to the packaging is now merged at lp:python-upa
[12:22] <didrocks> 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] <Laney> woot
[12:30] <seb128> didrocks, well done ;-)
[12:30] <didrocks> thx :)
[12:32] <Mirv> 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] <didrocks> Mirv: sure, will do :)
[12:38] <didrocks> Mirv: minor, but debian/copyright says 2012 and the headers are 2013 :)
[12:38] <didrocks> Mirv: however, more annoying: the project rename wasn't done?
[12:38] <didrocks> https://launchpad.net/python-upa
[12:38] <didrocks> and source package is python-ubuntu-platform-api
[12:38] <didrocks> IIRC, we agreed to that renamed
[12:40] <didrocks> Mirv: as I don't build on armhf, do you have somewhere the build logs + lintian?
[12:40] <didrocks> Mirv: this is all what I spotted on the source so far :)
[12:41] <desrt> word up, eurodudes
[12:41] <Mirv> didrocks: I was wondering about the project name as well, didn't know it was agreed to be renamed
[12:41] <didrocks> hey desrt, how is it going?
[12:42] <Mirv> didrocks: I've the pbuilder logs, I can put them up
[12:42] <didrocks> Mirv: oh, no worry, I'm stealing the autopilot ppa :)
[12:42] <Mirv> didrocks: so you want project name renamed, or source package renamed?
[12:42] <didrocks> binary-without-manpage -> we can ignore that :)
[12:42] <desrt> didrocks: great!!
[12:42] <didrocks> Mirv: wdyt? I think the source package name makes more sense to me
[12:42] <Mirv> didrocks: me too, ok
[12:42] <didrocks> Mirv: let's do that
[12:42] <didrocks> czajkowski: hey, around?
[12:43] <didrocks> 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] <didrocks> I'll coordinate with czajkowski about the launchpad side :)
[12:49] <Mirv> didrocks: ok, will do, I created https://launchpad.net/python-ubuntu-platform-api though with the same maintainer/driver already :(
[12:49] <Mirv> too fast
[12:52] <czajkowski> didrock back in a bit out at physio
[12:52] <didrocks> Mirv: let's see how we can deal with it, no worry! :)
[12:52] <czajkowski> didrocks ^^
[12:53] <didrocks> czajkowski: just ping me once you are available, no worry!
[12:53] <Mirv> 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] <didrocks> Mirv: we need to move bug reports
[12:54] <didrocks> hum, one fix committed bug
[12:54] <didrocks> it's tempting :)
[12:54] <didrocks> 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] <didrocks> sounds good?
[12:54] <Mirv> sounds good
[12:56] <Mirv> https://code.launchpad.net/~timo-jyrinki/python-upa/rename_project_update_copyright/+merge/168664
[12:58] <didrocks> Mirv: approved, just remain the cupstream2distro-config change and then redeploying the QA stack :)
[13:01] <Mirv> 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] <Mirv> 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] <didrocks> Mirv: yeah, I plan to do my patch pilot this week
[13:03] <didrocks> Mirv: but seeing how active the SRU team is :/
[13:03] <didrocks> Mirv: I'm afraid that the raring second publish SRU is going the same road than the first one, isn't it?
[13:03] <didrocks> Mirv: or did you see progress?
[13:03] <Mirv> ok.. and yes, that's another thing altogether (although precise queue is quite empty)
[13:04] <Mirv> 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] <didrocks> well, same people, so maybe they won't get to it as well…
[13:04] <didrocks> it's sad to have a fix for unity touching netbooks for a month and half and still no review :/
[13:04] <didrocks> Mirv: ok, keep me posted!
[13:04] <qengho> maxb: The Way to avoid profile interaction is to run "chromium-browser --temp-profile", btw.
[13:05] <Mirv> didrocks: I will
[13:05] <maxb> qengho: I'll bear it in mind for the future :-)
[13:05] <qengho> maxb: so, what are the versions of Chrome and chromium-browser?
[13:06] <maxb> 27.0.1453.110-r202711 and 25.0.1364.160-0ubuntu3
[13:06] <maxb> (This is on raring, with the http://dl.google.com/linux/chrome/deb stable main repo)
[13:10] <didrocks> qengho: btw, when can we get a new chromium? I need 26 for css transitions on pseudo elements :)
[13:10] <qengho> didrocks: Sorry, you're only getting 27.
[13:11] <qengho> didrocks: webapps patches aren't working right now, so once that's solved, it's in.
[13:12] <qengho> maxb: Hrm, okay. With a clean or temp profile, chromium doesn't offer to remember some passwords?
[13:12] <didrocks> qengho: I can live with 27 (but not sure what's new I would need) :p
[13:12] <mhr3> ogra_, stgraber, seb128 tells me you'd know about the operator-specific partition for customizations, is this specced out somewhere already?
[13:13] <maxb> 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] <ogra_> mhr3, not specced at all yet ... stgraber should know whats planned for image based upgrades though
[13:15] <qengho> maxb: fun. Let's test something.  $ chrome --user-data-dir=$(mktemp -d chromeXXXXXXXX)
[13:15] <mhr3> 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] <qengho> maxb: and then use that new Chrome browser to log in to those sites too.
[13:16] <maxb> 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] <qengho> maxb: "Trumped"? They should stack.
[13:17] <maxb> OK, in that case it's just not appearing at all
[13:17] <qengho> ...I think.
[13:17] <maxb> So, you'd like me to test chrome with a different --user-data-dir? not chromium-browser ?
[13:19] <qengho> 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] <maxb> OK, I'll try it, but all of the problems are with *HTTP* auth, so there shouldn't be any HTML involved?
[13:20] <qengho> maxb: oh.
[13:21] <qengho> Still, bare browsers, both and confirm.
[13:21] <maxb> google-chrome with --user-data-dir prompted and saved ok to gnome keyring
[13:22] <maxb> chromium-browser with --user-data-dir did not prompt
[13:22] <stgraber> 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] <qengho> maxb: Interesting!  That's definitely worthy of a bug report. Do you have a Launchpad account?
[13:22] <maxb> ~maxb
[13:23] <maxb> It is irksome that I've only managed to reproduce it with intranet sites
[13:23] <mhr3> stgraber, ok, how will that path be exposed to apps/libs? or will we just change one of the XDG_ dirs?
[13:23] <qengho> maxb: agreed.   :(
[13:24] <stgraber> 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] <qengho> maxb: care to capture the headers on the response that signals auth is needed?
[13:24] <mhr3> stgraber, who is that someone? :)
[13:24] <Mirv> 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] <Mirv> 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] <stgraber> 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] <mhr3> lool, ping? :)
[13:26] <mhr3> stgraber, is at least the path already well known?
[13:26] <stgraber> mhr3: no
[13:26] <qengho> maxb: okay, never mind.  It looks like this is a bug that's fixed in v27.
[13:26] <maxb> Oh, heh
[13:26] <qengho> maxb: the upcoming update will fix you.
[13:27] <stgraber> 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] <maxb> OK then. What was the factor that was somehow affecting only some sites?
[13:27] <qengho> maxb: no idea.
[13:27] <qengho> maxb: https://code.google.com/p/chromium/issues/detail?id=174199
[13:28] <mhr3> stgraber, and do you know who is speccing it out?
[13:28] <stgraber> mhr3: wish I knew, lool is really your best bet at this point I think
[13:29] <didrocks> Mirv: did we have any other update in bamf 0.4 since the 13.05.31?
[13:29] <Mirv> didrocks: unfortunately yes
[13:29] <mhr3> stgraber, k, will bother him once he's him, thx for help so far
[13:29] <mhr3> s/him/here/
[13:29] <qengho> maxb: As a workaround TRY putting your username in the URL.  http://maxb@skunkworks.internal/hax0r
[13:29] <Mirv> 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] <didrocks> Mirv: hum, so yeah, manual upload in that case and MP to get that back in the 0.4 branch
[13:30] <Mirv> didrocks: ok
[13:30] <maxb> 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] <qengho> maxb: okay.  Thanks for asking.
[13:31] <Trevinho> jbicha: hi, could you please check if lp:~jbicha/bamf/have-dev-depend-on-gir still merges with trunk?
[13:32] <lool> mhr3: pong
[13:33] <mhr3> lool, i'm trying to figure out if the operator-specific partition/image is specced out somewhere?
[13:34] <Mirv> 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] <lool> 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] <didrocks> 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] <didrocks> Mirv: so they are both pros and cons…
[13:36] <Mirv> didrocks: true. just a thought in the air.
[13:37] <didrocks> 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] <lool> stgraber: Ah I see now why mhr3 went to you, there are 2 efforts / projects which customizations will affect
[13:51] <lool> stgraber: on one side e.g. unity teams for unity customization points (obviously)
[13:51] <lool> stgraber: but on the other side there's the question of supporting customizations in the images
[13:51] <lool> stgraber: right now our answer would be to build custom images and a custom distribution channel
[13:52] <lool> 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] <ogra_> define overlay ...
[13:54] <didrocks> ogra_: got a keyword on it? :p
[13:54] <ogra_> we noticed that loop mounting images gives us a big performance hit
[13:54] <lool> completely open for discussion  :-)
[13:54] <lool> I wouldn't want fs overlays I think
[13:54] <ogra_> so we cant really use that
[13:55] <ogra_> the other option i see for an overlay would be copying stuff in at boot time
[13:55] <ogra_> which will make the boot slow
[13:55] <lool> only the first boot though, yeah that could work
[13:55] <didrocks> first boot only?
[13:55] <lool> depends whether you copy stuff in the user data partition or in the system partition
[13:56] <ogra_> 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] <stgraber> 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] <ogra_> stgraber, and how would youput that in place ?
[13:58] <stgraber> 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] <ogra_> ah, at install time
[13:58] <ogra_> sounds more clever than first boot
[13:58] <stgraber> 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] <lool> 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] <lool> stgraber: if not, I guess we could followup on this discussion and capture the workflow
[14:00] <stgraber> 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] <lool> stgraber: I think it's something we need to define along factory reset
[14:00] <stgraber> 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] <lool> stgraber: that's the thing, I'm not sure the tarball would be shipped
[14:01] <stgraber> lool: won't affect factory reset as the data is stored on the system partition and so won't get wiped
[14:01] <lool> stgraber: it might just be something we have somewhere at factory flash time, and then gets updated forever
[14:02] <stgraber> 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] <lool> stgraber: so basically the approach is that we are careful to never mkfs, even when installing a full image, yes?
[14:03] <stgraber> 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] <stgraber> 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] <stgraber> in which case, we never reformat as we never have full images
[14:08] <lool> stgraber: sorry, I think the use case I was describing wasn't clear
[14:08] <lool> stgraber: currently we say that OEMs need custom images
[14:09] <lool> 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] <lool> stgraber: that is, there would be OEM customizations in the factory image, and then the device would get Ubuntu touch updates
[14:09] <stgraber> lool: I never sayed and never thought we'd use custom images for OEMs
[14:10] <lool> stgraber: so we'd point at two locations in the device OS updater config?  one for OEM tarball and one for Ubuntu?
[14:11] <stgraber> 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] <lool> stgraber: so we'd know about every single OEM-ed / customized combination?
[14:12] <stgraber> lool: for any device that uses our update server, yes
[14:13] <lool> 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] <mdeslaur> seb128, didrocks: have you guys managed to get an alternate keyboard layout in the touch images?
[14:14] <didrocks> 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] <mdeslaur> didrocks: oh! we're using maliit? i thought it was onboard...ok, thanks, I'll poke some more
[14:15] <lool> 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] <stgraber> 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] <lool> it doesn't change how customizastions themselves would be implemented anyway
[14:15] <didrocks> mdeslaur: I'm 95% sure we are using maliit :)
[14:16] <stgraber> 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] <lool> stgraber: I had conflicting reports there
[14:16] <lool> 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] <lool> 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] <lool> stgraber: was this on some list?
[14:17] <lool> stgraber: I guess we ought to settle this and put it on the wiki
[14:17] <stgraber> lool: right, but there are legal/liability concerns and that's where we're stuck at for now
[14:17] <ritz_> seb128  https://bugs.launchpad.net/ayatana-design/+bug/723864  , this dialog has been removed from gnome-keyring
[14:17] <ubot2`> 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] <lool> 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] <didrocks> Mirv: sil2100: ok, renaming done, I'll add it to the QA stack, redeploy and rerun the stack
[14:20] <didrocks> then sil2100, if everything pass, mind publishing?
[14:25] <lool> stgraber: was the top-level dir for customization agreed upon?
[14:37] <stgraber> lool: not that I know of
[14:51] <jbicha> is this symbol drop ok? https://bazaar.launchpad.net/~ubuntu-desktop/evolution-data-server/ubuntu/revision/188
[14:55] <fginther> seb128, FYI alesage is looking into https://code.launchpad.net/~larsu/notify-osd/fix-1189281/+merge/168550
[14:56] <alesage> seb128, indeed I'm looking into, will ping
[15:02] <seb128> fginther, alesage: hey, thanks
[15:02] <sil2100> didrocks: ACK
[15:05] <seb128> 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] <jbicha> Shotwell suddenly starting failing to build within the hour http://paste.ubuntu.com/5755143/
[15:08] <seb128> jbicha, seems like a doko issue, ask on #ubuntu-devel?
[15:17] <Riddell> anyone looked at doing a transition to libical 1.0?
[15:21]  * Riddell takes that as a no and goes ahead
[15:21] <Laney> not that I know of
[15:22] <Laney> make sure you build test rdeps first ;-)
[15:24] <Riddell> yeah that's what I'm doing now
[15:25] <Riddell> about 20+ of them  :(
[15:25] <attente> dednick, hi
[15:26] <attente> do you know if the new format for the indicator manifests is merged into libindicator?
[15:27] <olli_> charles_, ping
[15:28] <larsu> attente: it's merged into trunk...
[15:28] <attente> larsu, oh...
[15:29] <attente> thanks
[15:30] <seb128> Sweetshark, qengho, Laney, mlankhorst, tkamppeter, attente, desrt, larsu: hey, it's meeting time
[15:30] <qengho> YAY!
[15:30] <desrt> i love meeting!!!
[15:30] <mlankhorst> ohai
[15:30] <seb128> oh, qengho is there this week ;-)
[15:30] <seb128> qengho, yay to you ;-)
[15:30] <qengho> Ahem.  :P   thpppt.
[15:30] <Laney> so it is
[15:30] <seb128> good that you are here I've a bug for you ;-)
[15:31] <seb128> let's get started
[15:31] <seb128> qengho, your turn ;-)
[15:31] <Riddell> ooh meeting
[15:31] <qengho> * Trying to get chromium 27 released. To do:
[15:31] <qengho>   - get #webapps' patches updated.  Blocked.
[15:31] <qengho>   - fix startup crasher on ARMHF.
[15:31] <qengho> * Getting feedback on an extension installer package.
[15:31] <qengho> EOF
[15:32] <seb128> 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] <attente> seb128, i told him it wasn't necessary because u-g-m hadn't landed
[15:33] <seb128> well, u-g-m has finally landed...
[15:33] <qengho> attente: did you plan to make a patch to do it The Right Way?
[15:33] <Laney> when can we expect the default browser flamefest? :-)
[15:33] <qengho> Laney: soon.
[15:34] <qengho> Laney: Like within hours.
[15:34]  * Laney yessssssss
[15:34] <attente> 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] <qengho> attente: yes, I will apply it to S v27.
[15:35] <qengho> attente: I will not plan to send it upstream, though, okay?
[15:35] <attente> qengho, thanks, definitely agreed on that point
[15:35] <seb128> 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] <qengho> seb128: If it takes more than a few days, i'll get older updated.
[15:37] <Riddell> attente: u-g-m?
[15:37] <seb128> qengho, thanks
[15:37] <attente> Riddell, unity-gtk-module
[15:37] <seb128> Riddell, that's what replaces our hackish gtk patch for unity exported menus
[15:38] <qengho> I'm done. I hope everyone doesn't take as long as mine.
[15:38] <seb128> qengho, thanks
[15:38] <seb128> Laney, hey
[15:38] <Laney> yo
[15:38] <Laney> echo << EOF
[15:38] <Laney> • 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] <Laney> • Various bugfixes (wayland, nautilus, ...)
[15:38] <Laney> • One or two GNOME updates
[15:38] <Laney> • Fixed a git-annex regression we accidentally introduced in raring
[15:38] <Laney> • 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] <Laney> ... http://askubuntu.com/questions/306868/how-do-i-get-an-ubuntushape-to-transition-fade-between-different-images (help welcomed)
[15:38] <Laney> • 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] <Laney> EOF
[15:39] <seb128> Laney, I will check out your panel for sure
[15:39]  * seb128 adds to todolist
[15:39] <Laney> it is mainly just QML stuff
[15:40] <Laney> I still have to make it nice and reusable and actually do things
[15:40] <Laney> but it's a start
[15:40] <seb128> Laney, where/with who did you discuss gstreamer1.1? what's their release schedule?
[15:40] <Laney> just chatted to slomo, and they don't really have one other than "release when ready"
[15:40] <Laney> need to update it in experimental first anyway
[15:41] <seb128> ok ... is that going to change apis/requiring porting for apps?
[15:41] <Laney> shouldn't do
[15:41] <seb128> cool
[15:41] <seb128> Laney, thanks
[15:41] <Laney> 1.x is suppose to be compatible within itself
[15:41] <seb128> mlankhorst, hey
[15:41] <mlankhorst> 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] <mlankhorst> ^D
[15:41] <seb128> mlankhorst, thanks ;-)
[15:41] <seb128> tkamppeter, hey
[15:42] <slomo> seb128: it's compatible with 1.0, just adding new features
[15:42] <seb128> slomo, great, thanks ;-)
[15:42] <slomo> seb128: while 1.0.x only adds bugfixes
[15:42] <tkamppeter>  - 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] <tkamppeter>  - Packaged CUPS 1.7b1 and uploaded to my PPA for both Raring and Saucy for testing. Announced on ubuntu-devel.
[15:42] <tkamppeter>  - Updated Ricoh and OEM PPDs and packages on OpenPrinting
[15:42] <tkamppeter>  - Synced cups-filters and foomatic-db from Debian
[15:42] <tkamppeter>  - 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] <tkamppeter>  - Answered and triaged printing-related bug reports
[15:43] <seb128> tkamppeter, thanks
[15:43] <seb128> attente, hey
[15:44] <attente> seb128, hi
[15:44] <attente> finished indicator-keyboard svg generator
[15:44] <attente> the recent ibus issue seems to be because of the gnome-desktop-3 update to 3.8
[15:44] <attente> 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] <attente> EOF
[15:44] <seb128> attente, what change in gnome-desktop that created the issue?
[15:45] <attente> seb128, in libgnome-desktop, there were some functions removed from the api
[15:45] <seb128> hum, anything you need and that we should add back?
[15:45] <attente> functions that g-s-d 3.6 needed
[15:46] <seb128> did we break g-s-d with that update?
[15:46] <attente> seb128, i'm not sure what the better approach is here, to continue with 3.6 or 3.8
[15:46] <attente> for g-s-d/g-c-c
[15:46] <attente> seb128, it only seemed that the region support with ibus broke from what i could tell
[15:46] <seb128> I would keep my recommendation for earlier in the cycle
[15:46] <seb128> get it to work on 3.6
[15:47] <seb128> we are not close to update to 3.8 yet and we can't work on a moving target
[15:47] <attente> seb128, ok, will do
[15:47] <seb128> 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] <seb128> so let's land that first, we can forward port later then
[15:47] <jbicha> 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] <seb128> that would be a good first step ;-)
[15:48] <seb128> let's settle down the current issues and try to get nautilus 3.8 in
[15:48] <seb128> then we can look at g-s-d/g-c-c
[15:49] <seb128> 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] <jbicha> nautilus has just 2 remaining issues (missing New Document from the right-click menu and figuring out desktop background handling with compiz)
[15:49] <seb128> 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] <seb128> need to test that
[15:49] <attente> 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] <seb128> attente, ok, let's say that's the plan for now then
[15:50] <robru> seb128, many *-tweak-tool users would appreciate having the g-s-d background plugin re-enabled ;-)
[15:50] <seb128> attente, thanks
[15:50] <seb128> robru, seems so indeed
[15:51] <seb128> 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] <seb128> desrt, hey
[15:51] <attente> seb128, thanks for landing that
[15:51] <desrt> seb128: hey
[15:51] <desrt> worked on the critical reporting stuff
[15:52] <desrt> and also pretty close to getting larsu's platform data hooks stuff landed (so we can get gdk out of the indicators)
[15:52] <desrt> finally got the gapplication-implement-freedesktop-dbus-api spec stuff done
[15:52] <desrt> and also landed the GAppInfo side of that as well
[15:53] <desrt> also did a patch for the desktop action specification (those extra items when you right-click in the launcher) in GIO which is pretty close to landing, so we can drop our copy of that API in libindicator
[15:53] <desrt> that's about all
[15:54] <seb128> great
[15:54] <seb128> desrt, thanks
[15:54] <seb128> larsu, hey
[15:54] <larsu> hey seb128
[15:54] <larsu> I fixed a couple of issues in my gio platform data hooks patch (thanks to the review and help from desrt)
[15:54] <larsu> ted reviewed a lot of my outstanding branches (i-messages, libido,libindicator), some fixes there as well
[15:54] <larsu> some more small fixes: notify-osd crash, libindicator crash and test failures
[15:54] <larsu> and meanwhile, my ongoing work:  indicator-sound/ng and moving media player widget into libido, expect to land it this week
[15:54] <seb128> landing \o/
[15:55] <larsu> oh, and I just talked to popey and zsombi about an alarm api in the sdk, and what would be needed from the backend
[15:55]  * larsu needs someone to ping about for upstart-support of that
[15:55] <seb128> we are a bit behind on the new indicators it seems, will be nice to see stuff finally aligning and being testable
[15:55] <larsu> seb128: yes, lots of little issues last week, but we're making progress
[15:56] <seb128> larsu, talk to James Hunt if you need something from upstart (he's jodh on #ubuntu-devel when he's online)
[15:56] <larsu> okay, thanks
[15:56] <larsu> that's all from me, then
[15:56] <seb128> larsu, thanks
[15:56] <seb128> Sweetshark, hey
[15:56] <Sweetshark> seb128: hey
[15:56] <Sweetshark> - started building LibreOffice 4.1 beta2 - failed with internal liborcus copy as its autoconf/configure wasnt bright enough to find boost system
[15:56] <Sweetshark> - switched to external liborcus - that configure was fine, but the generated makefiles then failed to build properly against boost system
[15:56] <Sweetshark> - deepened my profenssional hate for autotools
[15:57] <Sweetshark> - using a hotpatched liborcus was able to build locally
[15:57] <Sweetshark> - building in a ppa failed with 'no space left on device' once
[15:57] <Sweetshark> - second try still running: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-3-4/+build/4660465 https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-3-4/+build/4660464
[15:57] <Sweetshark> - preparations for Hamburg Hackfest, of which I inherited the organizer status by not duck-and-covering quick enough as Thorsten (original organizer had to pass it on because of family work: https://wiki.documentfoundation.org/Hackfest/Hamburg2013
[15:57] <Sweetshark> - preparing for LibreOffice 4.0.4 build for raring (should most likely be SRUed
[15:57] <Sweetshark> EOF
[15:57] <desrt> 'deepened my profenssional hate for autotools'
[15:57] <qengho> +1
[15:57] <desrt> how is this different from any other week?
[15:57] <larsu> desrt: it's stronger on some weeks...
[15:57] <Sweetshark> desrt: this week has a typo in proffessional for your entertainment.
[15:58] <desrt> the rate of increase is always changing... but it's always positive, and never zero :)
[15:58] <larsu> definitely
[15:58] <qengho> monotonically increasing, even.
[15:58] <desrt> qengho: the level of hate, yes
[15:58] <Laney> you meanies
[15:58] <seb128> Sweetshark, thanks
[15:58] <desrt> strictly monotonically increasing, except on holidays
[15:58] <desrt> but the rate of increase is highly variable
[15:58]  * seb128 hates less autotools since looking at qml stuff using qmake
[15:59] <seb128> well at less I know autotools, qmake is chinese for me
[15:59] <desrt> seb128: i never claimed there exists anything better than autotools :p
[15:59] <larsu> ya, qmake gets quite a few things right
[15:59] <Laney> tried to debug some cmake last week
[15:59] <larsu> it's also missing 90% of the features of autotools
[15:59] <Laney> that was ... yeah
[15:59] <seb128> hate build systems... ;-)
[15:59] <seb128> Sweetshark, thanks
[15:59] <desrt> bake!!!
[15:59] <seb128> so me
[15:59] <larsu> Laney: ya, cmake is the same shit in green
[15:59] <Laney> reminded me of cdbs except harder to read the source to find out what's going on
[15:59] <seb128>  * worked on system-settings for touch, got a first iteration for the "about this device" panel commited/landed in saucy (doesn't do much yet but it's a start)
[15:59] <seb128>  * some desktop updates and bug fixes
[15:59] <seb128>  * chassed some use-after-free issues made visible by the new glib
[15:59] <seb128>  * reviewed packages in NEW for the new unity and ubuntu touch landing from last week
[16:00] <qengho> qmake needs some mysterious M4 layer to be more awesome.
[16:00] <seb128> that's it
[16:00] <seb128> is there any question/comment?
[16:00] <seb128> otherwise we are just on time for didrocks' part of the meeting
[16:00] <Laney> nop
[16:00] <didrocks> lateeee! :)
[16:01] <didrocks> not on time, 1min!
[16:01] <didrocks> can't live with it ;)
[16:01] <seb128> lol
[16:01] <didrocks> thanks seb128 :)
[16:01] <didrocks> ok, hey Mirv, sil2100, kenvandine, robru, cyphermox! How are you guys?
[16:01] <seb128> didrocks, enjoy ;-)
[16:01] <seb128> (thanks everyone)
[16:01]  * kenvandine waves
[16:01] <larsu> thanks seb128
[16:01] <Mirv> back from some exercise, good
[16:01] <didrocks> Mirv: just in time?
[16:01] <cyphermox> could be better. no closer to fixing battery and policykit issues on touch w.r.t wifi
[16:02] <cyphermox> (yet anyway)
[16:02] <robru> walking upright today!
[16:02] <Mirv> didrocks: about, I timed my run so that I'd be back for this
[16:02] <didrocks> robru: \o/
[16:02] <Mirv> robru: whoo
[16:02] <didrocks> Mirv: great ;)
[16:02] <robru> ;-)
[16:02] <cyphermox> robru: \o/
[16:02] <didrocks> robru: nice to see you back dude!
[16:02] <sil2100> Hi!
[16:02] <didrocks> hey sil2100 :)
[16:02] <sil2100> I'm sicky sicky
[16:02] <sil2100> robru: ! welcome back ;)
[16:02] <didrocks> sil2100: hope that's going to be better tomorrow :/
[16:02] <robru> thanks guys! great to be back
[16:02] <didrocks> ok, so let's start
[16:03] <didrocks> I think the big news of the week is having unity 7, 100 scopes and most of touch in distro now!
[16:03] <robru> sweeet
[16:03] <sil2100> I hope so, I have an appoitment with the doctor in an hour, so I guess I'll know more then
[16:03] <sil2100> \o/
[16:03] <didrocks> no more "next" ppa. You can tell everyone using "daily-build-next" or "next" how wrong they are :)
[16:04] <didrocks> we had some copyright issues when prenewing
[16:04] <didrocks> but basically it's done
[16:04] <didrocks> however, when reviewing the NEW packages, seb128 and I had some comments
[16:04] <didrocks> and it would be good to clean those with the help of upstream
[16:04] <didrocks> http://paste.ubuntu.com/5741741/
[16:05] <didrocks> so I would suggest everyone looks at his stacks
[16:05] <didrocks> and see what's impacted by this
[16:05] <didrocks> note the global "check if the package should be multiarched as well"
[16:05] <robru> didrocks, I see some of my stack in there... ;-)
[16:06] <Mirv> that's probably good to for all, it's going to be a pain if there's a need for multi-arch noted later on..
[16:06] <didrocks> robru: glad you are back to clean those :p
[16:06] <didrocks> Mirv: exactly!
[16:06] <didrocks> I added the "Clean all new packages" (line 20) https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=0
[16:06] <didrocks> fine with everyone?
[16:06] <Mirv> no libindicator multi-arch either still I guess..
[16:06] <kenvandine> yup
[16:06] <robru> didrocks, ok, should this be my priority for the day then?
[16:06] <Mirv> yes, thanks, bookmarked that pastebin as well
[16:07] <didrocks> robru: I think it can be, that and making your stack read!
[16:07] <didrocks> green*
[16:07]  * didrocks switches brain on
[16:07] <kenvandine> hehe
[16:07] <kenvandine> lets all make our stacks red
[16:07] <robru> didrocks, oh yeah, what happened there? it's in manual publishing mode? I tried to read the status but it didn't make a lot of sense to me
[16:08] <didrocks> kenvandine: that's the default it seems :)
[16:08] <robru> kenvandine, that's too easy ;-)
[16:08] <didrocks> robru: ah, we can look together if needed :p
[16:08] <sil2100> Yep
[16:08] <didrocks> speaking of which, so everyone, please look at your stacks
[16:08] <didrocks> cyphermox: you have some manual publishing for instance
[16:08] <didrocks> now that we landed everything and had everything green, the sooner we catch and fix issues, the better
[16:08] <didrocks> kenvandine has a rebuild in progress
[16:08] <didrocks> and sil2100 handled hud/indicators
[16:09] <didrocks> (Mirv did the manual publish)
[16:09] <robru> didrocks, yeah, I think I need some 1on1 to help me catch up. after the meeting?
[16:09] <didrocks> so let's try to keep that trend and have everything dealt promptly as first task of the day
[16:09] <didrocks> robru: fine with me!
[16:09] <sil2100> didrocks: I'll have to re-run hud now, since all the fixes landed
[16:09] <didrocks> sil2100: \o/
[16:09] <didrocks> on that note, 2 announcement on cupstream2distro for this week:
[16:09] <didrocks> - the QA stack status don't impact the other stacks
[16:10] <didrocks> so basically, all other stacks wait for QA to finish (as any dep on other stack)
[16:10] <didrocks> but if the QA stack failed and your tests pass, why blocking?
[16:10] <sil2100> That makes sense
[16:10] <didrocks> so it won't block anymore or set to manual publication (only for that QA stack with a special attribute)
[16:11] <didrocks> - second annoucement is that the ack for "not building on powerpc" is not needed anymore
[16:11] <didrocks> for at least… 5 hours :p
[16:11] <didrocks> so if you cross new packages/packages you are updating
[16:11] <didrocks> you can revert to arch: any
[16:11] <didrocks> instead of arch: i386 amd64 armhf
[16:11] <sil2100> \o/
[16:11] <sil2100> ;)
[16:11] <mhr3> seb128, do you know if we'll have ubuntu-online-accounts on the phone?
[16:12] <didrocks> (basically, it's looking at the destination if there was a build succeeded for that arch, and if not, it will ignore it for archs we don't care about)
[16:12] <didrocks> mhr3: meeting :p
[16:12] <robru> what about powerpc? it's been disabled?
[16:12] <mhr3> didrocks, ask him on the meeting ;P
[16:12] <didrocks> robru: no, it's just smarter to not block, as I told "we don't really care about that arch" ^
[16:12] <didrocks> (in fact, it's a list of archs in case things are moving later on)
[16:13] <robru> oh, ok. great
[16:13] <didrocks> sil2100: Mirv: so, you can ignore my comment now on the "arch" part on the new packages
[16:13] <didrocks> sil2100: Mirv: but you still have quite a lot to fix, isn't it? continuing this?
[16:13] <sil2100> didrocks: yep, I'll probably work more on this tomorrow
[16:14] <kenvandine> mhr3, yes
[16:14] <sil2100> didrocks: everything that's pointed out in the e-mail ;)
[16:14] <Mirv> yes
[16:14] <didrocks> Mirv: sil2100: everything but "archs". Thanks!
[16:14] <sil2100> Sorry about today, I tried to work but it's a bit _difficult_
[16:14] <didrocks> no worry ;)
[16:14] <didrocks> Mirv: anything to share on the SRU and Qt parts?
[16:14] <mhr3> kenvandine, even with an app where you can actually set everything up?
[16:14] <kenvandine> mhr3, for saucy we will :)
[16:14] <seb128> mhr3, let's discuss on #ubuntu-touch, meeting ongoing
[16:15] <sil2100> didrocks, Mirv: since we're talking about SRU's, bschaefer had a few fixes he'd like to release for precise for unity
[16:15] <bschaefer> Hello
[16:15] <sil2100> So I would be o/ for a new precise SRU once the old one (with steam fixes) gets out
[16:15] <Mirv> didrocks: it all reads there (or the Qt document), but some patches are pending testability on saucy device, and saucy on device is a bit hard to test right at the moment. that relates to backports to 5.0.2
[16:15] <didrocks> sil2100: I'll probably do it in my patch pilot shift that I delayed to that week
[16:16] <Mirv> didrocks: raring SRU, I added a (slightly old fashioned) .dsc file link to the doc now, for the requested bamf with a fixed changelog
[16:16] <didrocks> Mirv: excellent! yeah, I think we'll get the saucy touch image quite soon, that will make things easier :)
[16:16] <Mirv> sil2100: yeah, I told didrocks the next SRU is about to knock on the door after this one gets in
[16:17] <Mirv> didrocks: and in general we talked during last week that it's probably good to stick to 5.0.2 + backports for some time, and consider Qt 5.1 maybe around 5.1.1 or so
[16:17] <sil2100> \o/
[16:17] <sil2100> Mirv: awesome ;)
[16:17] <didrocks> Mirv: I like that plan, sounds a safe option :)
[16:18] <didrocks> ok, next bullet on the spreadsheet, cyphermox, while releasing touch to saucy, we did get some issues with indicators-clients and indicator-network, we added that to the spreadsheet, any other thing to share?
[16:18] <Mirv> but as told before, 5.1 beta is available for saucy for people who absolutely require to test some new feature from there
[16:18]  * Mirv is done speaking
[16:18] <didrocks> thanks Mirv!
[16:20] <didrocks> no cyphermox it seems… let's move while he's catching up (but would be great to have everyone on the meeting so that we can keep it short)
[16:20] <cyphermox> I'm there
[16:20] <didrocks> cyphermox: ah, did you see my comment? would you have time to work on it?
[16:20] <cyphermox> certainly not
[16:21] <didrocks> what do you propose then?
[16:21] <cyphermox> and it was working fine prior to that, I did build this manually without issues
[16:21] <cyphermox> indicator-network shouldn't even make use of indicators-client
[16:21] <didrocks> prior to what?
[16:21] <cyphermox> prior to adding indicators-client to daily-release
[16:21] <didrocks> cyphermox: even without indicators-client, indicator-network is making the unity panel segfaulting
[16:21] <cyphermox> that's interesting
[16:21] <cyphermox> is there a bug for it?
[16:22] <cyphermox> tedg: ^
[16:22] <didrocks> cyphermox: not that I know of
[16:22] <cyphermox> ok then I'll give it a shot here and see what we can do
[16:22] <didrocks> thanks :)
[16:22] <tedg> cyphermox, I don't think so, but we weren't debugging it until the new libindicator landed as it has a bunch of changes there.
[16:22] <cyphermox> right
[16:23] <didrocks> probably a bad interaction, it was just surprising the day we tried to release :)
[16:23] <cyphermox> meh
[16:23] <cyphermox> indicator-network is nowehere near ready to be used
[16:23] <tedg> No :-(
[16:23] <cyphermox> (unfortunately)
[16:23] <didrocks> tedg: cyphermox: we shouldn't daily release it yet then?
[16:23]  * tedg wants HUD to be DONE
[16:23] <cyphermox> didrocks: well, it's no loss
[16:23] <tedg> didrocks, No reason not to.
[16:23] <didrocks> it is, we can't test it :)
[16:23] <cyphermox> i mean, then we can notice issues like the above and fix it
[16:24] <didrocks> or can't test it doesn't break the default user experience :p
[16:24] <cyphermox> next daily will fix this
[16:24] <didrocks> like if anyone install it, he can't use unity
[16:24] <didrocks> ok, if this is fixed, even if it's a few use, I'm happy :)
[16:24] <cyphermox> that's a risk with any indicator, tbh
[16:24] <didrocks> I know that well ;)
[16:24] <cyphermox> ted will fix it :)
[16:24] <didrocks> heh
[16:24] <cyphermox> or I
[16:25] <tedg> Well, it should get better.  No plugins.
[16:25] <tedg> Plugins just suck for lots of hard to determine reasons.
[16:25] <didrocks> thanks cyphermox, tedg, just reenable it whenever you can. I'll prereview for NEWing as well.
[16:25] <cyphermox> well, this is getting off-topic, is there more to discuss?
[16:25] <didrocks> ok, last topic (a middly big one)
[16:26] <didrocks> now that we have everything's in, I guess it's time to sanity check what we don't daily release
[16:26] <didrocks> so I would say:
[16:26] <didrocks> 1. go over everything in head which will still have daily_release: False  (shouldn't be a lot)
[16:26] <didrocks> 2. go over the ones in phablet/ and see if they need to stay there or not
[16:26] <didrocks> I thought 3 people on that task would be great
[16:26] <didrocks> as Mirv and sil2100 are already doing some new packaging and I'm doing the pre-NEWing, we can get on that, wdyt?
[16:27] <didrocks> (and I'll add robru to the mix so that he can grow on packaging as well)
[16:27] <didrocks> so that by the end of the cycle you 3 can have upload rights to a package set in ubuntu
[16:27] <didrocks> does that make sense?
[16:27] <robru> yeah! I will fix up the *-app packages today
[16:27] <Mirv> makes sense
[16:28] <didrocks> who wants to lead that effort? :)
[16:28] <didrocks> (that will use emails for us 3 to contact robru ;))
[16:29] <Mirv> I'm away after this week, so I'd rather not take that in my name at this point, unless only until end of this week
[16:29] <didrocks> so maybe sil2100 or robru?
[16:29] <didrocks> robru: interested in taking that ownership?
[16:30] <robru> didrocks, ehhhhh... what is entailed by ownership?
[16:31] <Mirv> robru: that you kick us if nothing happens
[16:31] <didrocks> exactly :)
[16:31] <kenvandine> :)
[16:31] <robru> hmmmm, ok.
[16:31] <didrocks> \o/
[16:31]  * didrocks marks robru's name down :)
[16:31] <didrocks> ok, any other question? anything else to mention?
[16:31] <robru> didrocks, just 1on1 with you
[16:32] <Mirv> just that since I got qtquicklayouts into PPA yesterday (a new module in Qt 5.1), I marked the 5.1 beta item now done and moved qtlocation to the 5.0.2/backports section
[16:32] <Mirv> (qtlocation is not part of 5.1 but just a snapshot module at this point)
[16:32] <didrocks> robru: yeah ;)
[16:32] <didrocks> Mirv: do you want that in saucy?
[16:32] <didrocks> or we wait for 5.1.1?
[16:32] <Mirv> didrocks: definitely not, the 5.1 beta, it's a "PPA only" work item
[16:33] <didrocks> (for both qtlocation and qtquicklayouts)
[16:33] <didrocks> ok :)
[16:33] <Mirv> qtlocation maybe, a newer snapshot, but would need fixing compiling and testing as the rest of the 5.0.2/backports/snapshots
[16:33] <didrocks> ok, keep me posted if you need sponsoring
[16:33] <Mirv> mzanetti promised to check what's going on in there
[16:33] <Mirv> I will
[16:33] <didrocks> nice work everyone! Keep the spreadsheet update please :) (I'll again move what's done tomorrow morning to the archive section)
[16:33] <didrocks> have a good week
[16:34] <sil2100> \o/
[16:34] <kenvandine> will do
[16:34] <Mirv> thanks all
[16:34] <kenvandine> good night Mirv :)
[16:34] <kenvandine> Mirv, and let me know when you look at qtfeedback
[16:34] <Mirv> kenvandine: hehe, in an hour or two :)
[16:34] <Mirv> kenvandine: will do
[16:34] <kenvandine> thx
[16:45] <seb128> alesage, fginther: still looking at this notify-osd merge request?
[16:45] <alesage> seb128, sorry just returning to :/ a few min pls
[16:46] <seb128> alesage, no hurry, but if you could get it sorted today that would be good, so we can have the fix landing in saucy tomorrow morning
[16:47] <alesage> seb128, can do, will update
[16:47] <seb128> alesage, thanks
[16:47] <seb128> brb, session restart to test intel fix for image corruption problems
[16:54]  * didrocks waves good evening
[16:59] <seb128> yeah, image corruptions in firefox on my intel i5 are fixed with that git commit \o/
[17:00]  * desrt loves how the media is reporting that the ps4 has "no drm"
[17:00] <desrt> what the hell has gone wrong with the world?
[17:00] <desrt> frog in hot water much?
[17:01] <desrt> "let's turn DRM up to 11... that way, when we dial it back down to 10, people will say that it's perfect!"
[17:01] <seb128> yeah...
[17:56] <seb128> mterry, hey, how are you?
[17:56] <mterry> seb128, hello!  Good, what's up?
[17:56] <seb128> mterry, I've a quick g-c-c-unity question for you if you have a minute
[17:56] <seb128> mterry, did you "clean" the code when you imported it as a new component?
[17:56] <seb128> or fix some deprecations on the way?
[17:57] <seb128> mterry, the color picker here uses GdKRGBA where all the upstream versions I can find use GdkColor, I'm wondering where that's coming from
[17:57] <mterry> seb128, I don't recall, but I doubt it.  I try to do such things in a separate branch so that they don't get lost in the original import
[17:58] <mterry> seb128, maybe I did
[17:58] <seb128> ok
[17:58] <seb128> bzr blame says it's there since r1
[17:58] <mterry> seb128, what do you mean by upstream version?  Distro is upstream right?
[17:58] <seb128> well, anyway, going back to the deprecated GdkColor since that's what libgnome-desktop use and the conversion breaks picking of solid colors
[17:59] <mterry> Oh I guess you mean GNOME background panel
[17:59] <mterry> seb128, OK, sounds good.  Sorry if I was responsible for some pain
[18:00] <seb128> mterry, that code is an import from the old gnome-control-center code + distro patch right? I looked to the precise/quantal packages and didn't find any trace of rgba use in the upstream code or patches
[18:00] <seb128> mterry, no worry, I was just trying to understand the history
[18:00] <seb128> the api has
[18:00] <seb128> "gtk_color_button_new_with_color has been deprecated since version 3.4 and should not be used in newly-written code. Use gtk_color_button_new_with_rgba() instead."
[18:00] <seb128> so I guess somebody tried to be a good citizen
[18:00] <seb128> it just doesn't play nicely with the gnome-desktop side which has not been ported
[18:01] <seb128> mterry, no worry, I've a fix, I was just looking for a bit of background before submitting it
[18:01] <seb128> mterry, thanks ;-)
[18:49]  * Sweetshark quietly begins to sob -- which grows into a hysteric crying.
[18:51] <Sweetshark> seb128: I cant testbuild LibreOffice 4.1 on the ppas as they always crap out on lack of memory. I could reduce the kind of LibreOffice even more (from a 'release' build more to a 'developer build'), but that kinda defeats the purpose (read: testing what I want to push to the repo as close as possible).
[18:52] <Sweetshark> s/lack of memory/lack of storage/
[18:56]  * Sweetshark mumbles "LibreOffice -- based on technology breaking your toolchain since 1985" ...
[18:56] <seb128> Sweetshark, is your ppa a devirtualized one?
[18:56] <seb128> I though those were using archive builders
[18:56]  * seb128 has an air of deja vu
[18:57]  * Sweetshark shakes an angry old man fist at feeble launchpad and reads gumpily starts reading http://wiki.debian.org/HowToSetupADebianRepository ...
[18:57] <seb128> (I think there was a discussion previous cycle on how much buildd that would take)
[18:59] <seb128> jbicha, hum, I'm not sure I agree with that push to kick uoa out
[18:59] <seb128> that's sort of the border between distro identity and desktop one
[18:59] <seb128> it's like trying to kick upstart out because GNOME prefers systemd
[18:59] <Sweetshark> seb128: that limit in the ppa build is AFAIK restricted by the hardware (like real hardware in a rack) and there was "nothing to be done about it unless decommissioning those machines".
[18:59] <seb128> Sweetshark, does it happen with archive builds as well?
[19:00] <Sweetshark> seb128: I think the discussion was about virtualization of arm builders -- thats a different can of worms.
[19:00] <seb128> tjaalton, thanks for the -intel upload
[19:00] <Sweetshark> seb128: it didnt so far.
[19:00] <tjaalton> seb128: yw
[19:00] <seb128> Sweetshark, I don't think it is
[19:00] <jbicha> seb128: other flavors aren't shipping UOA; you can't really say that UOA is Foundations
[19:00] <seb128> Sweetshark, if you get devirtualized you are on archive builders, that includes arm ones
[19:01] <seb128> jbicha, no other flavor is shipping shotwell?
[19:01] <jbicha> this is just about the default, you can still use UOA on Ubuntu GNOME
[19:02] <jbicha> you don't need UOA to publish photos online from Shotwell; (also Ubuntu Studio includes Shotwell)
[19:02] <seb128> jbicha, well, those are two duplicated technologies and I would be in favor of kicking goa out in Ubuntu the same way we kick systemd init out
[19:02] <jbicha> seb128: that's ridiculous
[19:02] <seb128> why?
[19:02] <seb128> that's not a difference in user experience
[19:02] <seb128> it's a difference in technologies which provide a somewhat similar service
[19:04] <jbicha> for one, nobody has cared to fix bug 1062449
[19:04] <ubot2`> Launchpad bug 1062449 in gnome-documents (Ubuntu) "Please add UOA support for GNOME Documents" [Wishlist,Confirmed] https://launchpad.net/bugs/1062449
[19:04] <seb128> well, rather than trying to kick uoa out of the required depends you could try to fix that one ;-)
[19:05] <jbicha> I'm not really a programmer
[19:05] <Sweetshark> seb128: Im not even building in the "libreoffice ppa" as that would be a pain for everyone (e.g. amd64 succeeding and i386 not and lots of broken deps abound -- but even barring such a scenario: am64 finishing first and i386 taking a few hours longer and lots of broken deps abound.) -- so I am building on ppa like this one https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging and copy to the end user visible ppa, if it is su
[19:05] <seb128> sorry, that was not addressed specifically at you
[19:05] <seb128> but yeah, I understand they are issues
[19:05] <jbicha> shipping 2 webkits isn't that great either
[19:05] <seb128> but still that seems a border line depends between distro identity and desktop identity
[19:06] <seb128> we ship 2?
[19:06] <jbicha> the qt and gtk versions
[19:06] <seb128> Sweetshark, you cut at "if it is su"
[19:06] <seb128> Sweetshark, but yeah, agreed, you should ask for a non-virtual ppa maybe for your builds
[19:07] <Sweetshark> if it is successfully finished there (with copying binaries) ...
[19:07] <seb128> Sweetshark, though seems like you got pushback from the buildds team last time because of the limited resources
[19:07] <seb128> jbicha, right, the security team is looking at addressing the duplicated webkit
[19:07] <jbicha> there's a few minor issues with yanking out UOA for Ubuntu GNOME (the broken Publish feature in Shotwell and https://bugzilla.gnome.org/701903)
[19:07] <ubot2`> Gnome bug 701903 in UOA "If built with --enable-ubuntu-online-accounts, accounts dialog always opens the UOA one" [Normal,Unconfirmed]
[19:08] <jbicha> but generally speaking, GOA meets our user's needs and UOA isn't quite there yet
[19:08] <Sweetshark> seb128: so essentially my libreoffice-ppas have their own private "-proposed" ;)
[19:08] <seb128> jbicha, the webkit plan from vUDS was to have our own webkit wrapping and port main to that (e.g branch from webkit master, add our binding, maintain api compat for that and security)
[19:08] <jbicha> it's not too hard to switch back to UOA if the balance changes
[19:09] <seb128> jbicha, "our" being for the GNOME edition I guess ... fair enough, as long as goa doesn't get into the default unity install
[19:10] <seb128> jbicha, but it's getting trickier when e.g shotwell doesn't put uoa integration in a separate file
[19:10] <jbicha> seb128: yeah, this work is just creating alternate dependencies which Ubuntu GNOME can opt into
[19:10] <jbicha> seb128: UOA was never merged upstream into Shotwell so that's an oversight in the Ubuntu patch
[19:10] <seb128> it's not an oversight
[19:11] <seb128> and we might get extra uoa integration this way in the futur
[19:11] <seb128> GNOME refuses to have build-time options for things that are not part of GNOME
[19:11] <seb128> I'm not sure why we should
[19:11] <seb128> that's why I'm saying that is border desktop-distro line
[19:11] <seb128> imho the online account provider is part of the distro, like the init system
[19:12] <seb128> and you shouldn't get to swap those
[19:12] <seb128> it's making everybody's life harder
[19:12] <jbicha> on the other hand, it's a bit much to be requiring GNOME apps to depend on the Qt stack
[19:12] <seb128> it's only a lib...
[19:12] <seb128> but yeah, I get your point
[19:13] <seb128> I guess you don't have ubuntuone either on the GNOME edition then?
[19:13] <jbicha> too bad it's not just a few MB we're talking about
[19:13] <jbicha> we have some Ubuntu One libraries but not the GUI
[19:13] <seb128> well, good luck fighting against qt depends in the futur
[19:13] <seb128> those are not going to decrease
[19:14] <jbicha> I'm not opposed to having Ubuntu One included but...the design... and the failure to fix UI bugs I reported as soon as it landed by default in Ubuntu
[19:15] <seb128> yeah, I was not arguing about U1
[19:15] <seb128> but Qt is main part of where Ubuntu is going
[19:15] <seb128> so I guess that's going to get harder over time to kick it out
[19:15] <jbicha> isn't it more likely that Ubuntu will just start replacing GNOME apps with your new mobile-capable apps?
[19:15] <seb128> so are long run battles and I'm not sure they are worth it
[19:16] <seb128> sure
[19:16] <seb128> but it means you stop getting stuff like update-manager
[19:16] <seb128> software-center
[19:16] <seb128> ubuntuone
[19:16] <seb128> software-properties
[19:16] <jbicha> so the divergence might help
[19:16] <seb128> if you don't care about all the Ubuntu tools sure
[19:16] <seb128> but you might wonder then why you use Ubuntu
[19:17] <desrt> hi guys.  what's up?
[19:17] <jbicha> Ubuntu is about more than just Unity and I'm not sure that Unity is all that much more popular than GNOME Shell is
[19:18] <seb128> I'm not speaking about unity
[19:18] <seb128> I never argued about the desktop choice
[19:18] <jbicha> things get worse for Ubuntu if GNOME developers stop caring about Ubuntu
[19:18] <seb128> just about the difficulty about swapping underlining technologies
[19:18] <seb128> difficulty of*
[19:19] <seb128> desrt, hey, nothing interested, you can ignore that channel for the rest of the day ;-)
[19:20] <jbicha> we'll re-assess things as we go along, UG 12.10 used gnome-packagekit for instance; and we've always shipped all that extra Qt stuff until now and maybe we will again if the features we need are there
[19:21] <jbicha> I don't think the GNOME Software guys care about integrating support for installing proprietary apps which makes USC look pretty attractive
[19:21] <desrt> jbicha: i think seb has some pretty good points...
[19:23] <desrt> (at least the canonical part of) ubuntu has come to the rather logical conclusion that unity is the only ubuntu that's worth putting substantial effort into... it's hard to argue against that conclusion, considering how reasonable it is...
[19:23] <desrt> going forward i seriously doubt that there is going to be a lot of time spent on considerations for making the lower levels of ubuntu work particularly well for non-unity cases
[19:24] <desrt> i don't think there will be any active blocking... but you're going to be left with a heavier and heavier bag to carry as time goes on
[19:27] <walters> personally i've always found it surprising that Ubuntu hasn't more aggressively referred people who wanted "something else" to Debian
[19:28] <desrt> walters: or fedora? ;)
[19:28] <seb128> well, there is a demand for some "GNOME experience on Ubuntu"
[19:28] <seb128> but imho wanting to clean that out of any "Ubuntu" is a mistake
[19:28] <desrt> seb128: it's an interesting point though... what does that even mean anymore?
[19:28] <seb128> if you go that far you can as well use another distro
[19:29] <desrt> if the software centre is taken away, for example... what part of ubuntu are we still benefiting from?
[19:29] <seb128> desrt, don't ask me, I support a gnome-shell UI on Ubuntu (which means with Ubuntu integration included)
[19:29] <seb128> I'm not sure what's the point of trying to get a version without the Ubuntu integration
[19:30] <jbicha> seb128: we're not trying to clean UG of Ubuntu; UG is a hybrid - I believe we would have been the only other desktop flavor to include Ubuntu One if it didn't look so out of place)
[19:30] <desrt> seb128: i think the point is that a lot of the features that jbicha is trying to 'get rid of' are kinda half-baked
[19:30] <desrt> seb128: and (importantly) gnome purists tolerate half-baked features from upstream gnome, but get upset when it's some canonical tech that's ruining their day
[19:30] <seb128> desrt, I don't think "gnome-contacts doesn't support uoa" is a reason to call uoa "half-baked"
[19:31] <seb128> desrt, read aseigo posts on http://blog.yorba.org/jim/2013/02/the-garden-of-the-forking-paths.html
[19:31] <seb128> the meego online stack is used by meego/kde/ubuntu/...
[19:31] <desrt> i try to avoid reading aseigo whenever possible :)
[19:31] <jbicha> users complain about the confusing double Online Accounts; users complained about not including GNOME Documents; they aren't complaining yet about not enough integration into Unity
[19:31] <seb128> right
[19:32] <seb128> but "gnome-contacts doesn't support uoa" doesn't mean that uoa is half baked
[19:32] <seb128> I object with the statement ;-)
[19:32] <seb128> I understand why it is this way though
[19:32] <desrt> seb128: uoa being included in gnomebuntu, however, _is_ very half-baked
[19:32] <seb128> right
[19:33] <desrt> (i don't feel like debating the other point... i have problems with both uoa and goa)
[19:33] <seb128> so gnomebuntu could try to fix it ;-)
[19:33] <seb128> but yeah
[19:33] <seb128> it's a sucking situation
[19:33] <seb128> but it's not as easy as "ubuntu provided an half baked solution again"
[19:33] <desrt> well, honestly that's sort of what we do
[19:34] <desrt> the difference is that we seem to get more flack for it than everyone else who is doing the same
[19:34] <seb128> I disagree with that
[19:34] <seb128> we don't get flack from anyone for uoa
[19:34] <desrt> well
[19:34] <desrt> let me give you some flack, then :)
[19:34] <seb128> out of GNOME users on Ubuntu because we didn't port GNOME apps to it
[19:35] <seb128> you could give some flacks to GNOME because they don't support uoa the same way
[19:35] <desrt> we're getting dangerously close to "which came first and who failed to talk to whom" again
[19:35] <seb128> sure
[19:35] <seb128> meego was there first
[19:35] <seb128> and that's what we use
[19:36] <seb128> it was discussed on d-d-l before goa started
[19:36] <seb128> while I usually agree with you, I don't think that one is an in the same case as most mistakes
[19:36]  * desrt honestly hates all of these techs
[19:37] <seb128> well, anyway, arguing over that is not going to resolve the issues
[19:37] <seb128> in an ideal world everybody would use the same techs
[19:37] <seb128> but we are not sure
[19:38] <seb128> shrugh
[19:38] <seb128> but we are not *there*
[19:38] <seb128> so good luck to the GNOME edition guys to patch out Ubuntu bits is the best I can say...
[19:39] <desrt> seb128: and, apparently, to question their sanity for attempting to do so...
[19:39] <desrt> (which is a pretty legitimate concern...)
[19:39] <jbicha> desrt has long thought I was crazy for doing the Ubuntu GNOME thing :)
[19:39] <seb128> desrt, well, I don't "question their sanity", I just warn them it's an uphill battle
[19:39] <seb128> if they are wanting to fight it, good for them
[19:40] <seb128> I would have more of a mixed approach  to the issue
[19:40] <seb128> but that's me ;-)
[19:41] <desrt> seb128: you'll be happier if you eat ice cream
[19:41] <seb128> hum, ice cream
[19:41] <seb128> where is larsu?
[19:41] <desrt> see?  it's working already
[19:41] <desrt> he's in the biomed building at U of T
[19:41] <seb128> larsu, alter! ice cream!!!
[19:41] <larsu> ICE CREAM!
[19:41] <seb128> ;-)
[19:42] <desrt> larsu: loblaws!!
[19:42] <larsu> desrt: now?
[19:42] <seb128> what is "loblaws"?
[19:42] <desrt> we forgot last night :(
[19:42] <larsu> (yes, I'd be up for that)
[19:42] <seb128> ignore that, I'm not sure I want to know :p
[19:42]  * seb128 prefers to stay on the ice cream line
[19:43] <larsu> seb128: a supermarket with an especially awesome ice cream vendor inside
[19:43] <seb128> oohhh
[19:43] <larsu> seb128: just two words: Mango Sorbet.
[19:43] <seb128> ;-)
[19:43] <seb128> larsu, you guys should go!
[19:43] <larsu> do I need to read any scrollback?
[19:43]  * desrt is approx 1 hr. away
[19:43] <seb128> larsu, no
[19:44] <desrt> larsu: just the usual debate over gnome vs. ubuntu
[19:44] <larsu> seb128: too far, and I'm in the middle of the sound widget stuff (oh man that code is ... bad)
[19:44] <seb128> larsu, boring argument on uoa vs goa
[19:44] <desrt> until i forcefully changed the topic to icecream
[19:44] <desrt> larsu: too far?!?
[19:44] <larsu> good choice.
[19:44] <desrt> i mean... i know it's the other side of yonge street and stuff....
[19:44] <seb128> larsu, complaining about the code? get some notify-osd hacking... ;-)
[19:44] <desrt> but like, 15 minutes walk?
[19:44] <larsu> desrt: ya, like 10 minutes by foot
[19:44] <larsu> seb128: hehe
[19:45] <larsu> seb128: this is slightly better, but only slightly
[19:45] <seb128> larsu, yeah, Conor was new to Gworld as well
[19:46]  * desrt ponders loblaws
[19:46] <larsu> desrt: if you go we'll come
[19:46] <desrt> larsu: you're recommending i don't see this movie tonight, right?
[19:46] <larsu> desrt: have you seen the other two
[19:46] <desrt> no
[19:46] <larsu> then: definitely not
[19:49] <larsu> seb128: attente is trying to find the source package that sets a particular dconf key. Do you know of any way?`?
[19:49] <desrt> larsu: guess that the dconf path will correspond roughly to the gsettings schema name and that the schema file is named in the standard way
[19:50] <desrt> apply apt-file
[19:50] <larsu> desrt: thanks.
[19:50] <seb128> larsu, what key?
[19:50] <seb128> oh you mean code wise
[19:51] <seb128> I though you meant "what package is setting that default"
[19:51] <attente> what if the schema is just in gsettings-desktop-schemas
[19:51] <desrt> attente: rdepends!!!!!
[19:51] <seb128> what key is that?
[19:51] <desrt> attente: good luck :)
[19:51] <larsu> desrt: you're missing a 1 there
[19:51] <larsu> desrt: rdepends!!!!!!!!1
[19:51] <seb128> we set most of the distro defaults in "ubuntu-settings"
[19:52] <seb128> that's the "override of defaults values over upstream for Ubuntu"
[19:52] <attente> seb128, switch-input-source in org.gnome.settings-daemon.plugins.media-keys
[19:52] <larsu> sound like gnome-settings-daemon to me...
[19:52] <seb128> but otherwise just grep for the key in /usr/share/glib-2.0/schemas/
[19:53] <seb128> well if that's a default
[19:53] <seb128> if it's runtime, grep the archive
[19:53] <desrt> seb128: do we have source archive grep?
[19:53] <attente> i know g-c-c modifies it, i'm wondering what's reading it
[19:53] <seb128> desrt, no :-(
[19:54] <seb128> desrt, we have scripts doing it that people can run in the datacenter though
[19:54] <jbicha> desrt: but dpkg -S *filename* will at least tell you what package provides a file
[19:54] <desrt> jbicha: only if it's installed...
[19:54] <desrt> jbicha: apt-file is the general case of this
[19:56] <jbicha> yeah but apt-file isn't installed by default
[19:57] <larsu> desrt: are you on your way yet? :P
[19:58] <jbicha> Laney: libcamel's rdepends still build so e-d-s is ready for upload when you are
[20:10] <Laney> jbicha: just waits for a solution on the desktop file thing; feel free to solve that in packaging if you want
[20:10] <Laney> at least from my pov
[20:13] <Laney> (upstreamable patch preferable of course)
[23:57] <TheMuso> wwww/c