[05:16] <pitti> Good morning
[05:17] <pitti> Sweetshark: done
[06:43] <mlankhorst> Hello, world!\n
[07:02] <ochosi> morning desktopers
[07:03] <ochosi> who can i bribe to help us get a patch for gtk2 into trusty (that causes a lot of headache for xubuntu users)?
[08:21] <ochosi> morning seb128
[08:24] <seb128> good morning desktopers
[08:25] <seb128> hey ochosi
[08:26] <ochosi> what could i do to get a gtk2 bug fixed in trusty? (patch has already been applied upstream)
[08:27] <ochosi> it's a bug that affects xubuntu especially, as it crashes our file-manager a lot
[08:27] <seb128> ochosi, attach the patch to a bug, subscribe ubuntu-sponsors
[08:27] <ochosi> (the patch is tiny and trivial)
[08:27] <seb128> bonus point if you file the SRU info on the bug
[08:27] <ochosi> ok :)
[08:28] <ochosi> this is the bugreport with the patch, fyi: https://bugzilla.gnome.org/show_bug.cgi?id=723366
[08:30] <ochosi> thanks for the heads up seb128, will try to get that done
[08:32] <seb128> ochosi, thanks
[08:37] <skystar84> Hi. I have a question? When I trying burn disc with Ubuntu from Windows UltraISO, I getting one folder EFI. Thats repeat also with "Unetbootin".
[08:38] <skystar84> How can I write normally install iso to dvd disc?
[08:39] <skystar84> EFI folder size 2.294 has only 2.2 mb
[08:41] <seb128> hey, try #ubuntu for user questions
[09:30] <darkxst> seb128, hi
[09:31] <seb128> darkxst, hey
[09:32] <darkxst> seb128, bug 1316383
[09:33] <seb128> saw that, thanks
[09:33] <darkxst> logo patch was pita with gresources ;( but done now
[09:51] <ochosi> seb128: hey, i've never done a SRU before, would you mind taking a look whether this is ok or whether i messed up? https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1316509
[09:52] <seb128> ochosi, that looks great, thanks!
[09:52] <seb128> ochosi, just subscribe ubuntu-sponsors as well and you are gold ;-)
[09:53] <ochosi> seb128: great, thanks for taking a look!
[09:53] <seb128> yw!
[09:59] <darkxst> ochosi, that patch should really go upstream ;)
[09:59] <ochosi> darkxst: i agree, but what're you gonna do...
[09:59] <ochosi> i mean the patch was even written for gtk2 originally
[09:59] <ochosi> so meh
[10:00] <darkxst> ochosi, gtk-2 is still maintained to some extent
[10:00] <darkxst> you should file a bug on bugzilla.g.o with the patch
[10:00] <ochosi> did you look at the upstream bugreport i linked?
[10:00] <ochosi> it *was* filed there and against gtk2
[10:00] <ochosi> they just chose not to apply it
[10:00] <ochosi> instead here: https://git.gnome.org/browse/gtk+/commit/gtk/gtkmountoperation.c?h=gtk-3-12&id=05f2f634260519b5448ffd53e8883412c0251443
[10:00] <ochosi> don't think filing another bugreport is going to make them change their mind
[10:01] <darkxst> oh missed that
[10:01] <ochosi> i dunno, if you have good ties to gtk devs, it'd be nice if you could mention it again to them
[10:02] <ochosi> it's really a no-brainer, that patch and it would be nice if ubuntu wasn't the only distro carrying the fix
[10:02] <darkxst> ochosi, they did not reject the patch, they said to remove the comment!
[10:02] <ochosi> they did remove the comment in the commit i linked to above
[10:02] <ochosi> and they set the bugreport to "fixed"
[10:03] <darkxst> there is absolutely no reason why that can't be cherry-picked to gtk2
[10:03] <darkxst> just ask on the bug report!
[10:03] <ochosi> i will
[10:04] <ricotz> ochosi, darkxst, since mclasen accepted it he assumed the reporter can push it
[10:04] <ochosi> i'm not on a gtk-rant, but what i said still applies ;)
[10:04] <darkxst> ricotz, thats clear to me ;)
[10:04] <ochosi> the patch *was* written for gtk2 and only applied against gtk3
[10:06] <ochosi> i hope comments on bugreports that are marked as "fixed" are even read...
[10:06] <ricotz> ochosi, this happens just point it out, or ping mclasen and push it yourself
[10:06] <ochosi> sure, did already add a comment
[10:06] <ricotz> good
[10:06] <ochosi> s/did/have/ s/add/added/
[10:07] <ochosi> anyhoo, if any of you can help with SRUing this to trusty even before it gets merged upstream, that be extremely nice
[10:08] <ricotz> ochosi, btw, better add a proper patch with header to the sru bug
[10:08] <ochosi> it really severly affects xubuntu and ubuntu-studio users (as can be seen from the tons of duplicates the thunar bugreport has i linked to)
[10:08] <ricotz> e.g. a git format-patch
[10:08] <darkxst> ochosi, and it has to go through utopic first!
[10:09] <ochosi> well as i said before, this is my first SRU
[10:09] <ochosi> gotta have some patience with me :)
[10:10] <ochosi> ricotz: i'm not sure i know how to do a proper git patch against gtk2 unless you mean cloning the gtk2 repo (which would take forever, i'm behind a *really* slow connection atm)
[10:12] <ochosi> darkxst: but sponsors are already subscribed, do i need to do anything else for this to go to utopic?
[10:13] <darkxst> ochosi, unless you find a really nice sponsor, you should prepare a debdiff using the upstream (gtk3) patch
[10:14] <ochosi> darkxst: i don't even know how to prepare a debdiff, so i'll go on hoping for a really nice sponsor...
[10:14] <darkxst> ochosi, do you guys have any devs?
[10:15] <ochosi> not really :/
[10:15] <ochosi> that was our biggest trouble in the trusty cycle
[10:15] <ochosi> and why we had to push everything through the sponsors queue
[10:16] <ochosi> anyhoo, i can see whether i can find someone to do the debdiff if the "really nice sponsor" doesn't materialize out of thin air
[10:18] <ricotz> ochosi, did you test the gtk3 version of the fix
[10:19] <ricotz> ochosi, it applies cleanly on gtk-2-24 - http://paste.debian.net/plain/97737
[10:20] <ochosi> ricotz: no, gtk3 didn't affect us at all
[10:21] <ricotz> hmm, read again
[10:21] <ricotz> ochosi, what i mean the fix mclasen pushed to gtk3 works as it is on gtk2
[10:22] <ochosi> yes, i know
[10:22] <ricotz> at least it applies and compiles, so testing it would be nice
[10:23] <ochosi> ricotz: ali1234 is the one who dug this up
[10:23] <ali1234> o/
[10:23] <ali1234> i've been chaing this bug for months
[10:24] <ali1234> it's the biggest crasher in xubuntu by far... actually it's like 9 out of the top 10
[10:24] <ali1234> and it's in the top 10 for all ubuntu as well
[10:24] <ali1234> according to e.u.c
[10:24] <ali1234> and we've never been able to reproduce it because it's a really fiddly memory corruption
[10:24] <ali1234> but someone found a way yesterday
[10:26] <ochosi> ricotz: ali1234 also boiled the bug down to this little thingy here: http://paste.ubuntu.com/7403729/
[10:28] <darkxst> ochosi, ali1234 if you make a proper debdiff it will get sponsored no issues!
[10:28] <profesor__> hola
[10:28] <profesor__> me pica el pene
[10:28] <ali1234> darkxst: i can make a debdiff but i can't guarantee it will be "proper"
[10:29] <darkxst> ali1234, just make a debdiff with a changelog entry and the upstream patch (from gtk3)!
[10:30] <ali1234> okay. the upstream patch also fixes an unrelated memory leak in a nearby closely-related function. it's also trivial and i think we should sneak it in too...
[10:31] <profesor__> holi
[10:32] <profesor__> jaja
[10:32] <darkxst> ali1234, of course, but do test it first ;)
[10:33] <ali1234> right-o
[10:33] <profesor__> twitter?
[10:33] <profesor__> asdfghj
[10:38] <seb128> ochosi, ali1234: don't bother about the debdiff, I've it on my list
[10:38] <seb128> if pitti (who pilots tomorrow apparently) doesn't get to it first
[10:38] <ali1234> how long is the list?
[10:38] <seb128> today or tomorrow
[10:39] <seb128> if that's the question
[10:39] <ali1234> :)
[10:39] <ali1234> well, i need the practice anyway
[10:39] <ali1234> and we should probably actually test it anyway
[10:39] <ochosi> seb128, ali1234: thanks to both of you!
[10:39]  * ochosi bows
[10:40] <ochosi> seb128 = "really nice sponsor" (you can logically deduct that from the conversation above, so iit's official :))
[10:40] <seb128> yw!
[10:40] <seb128> ;-)
[10:51]  * darkxst bets seb128 is just filling is list with easy takings so he doesn't have to deal with my mammoth g-c-c merge ;) 
[11:26] <asac> seb128: will you tackle live installer image first or rather alternate?
[11:27] <ogra_> ??
[11:27] <seb128> asac, live installer, having a liveCD to boot to play with unity8 might be the most interesting thing at first
[11:27] <ogra_> what alternate ?
[11:27] <seb128> ogra_, speaking about unity8 desktop images
[11:27] <ogra_> we dont have alternate anymore since precise :P
[11:27] <seb128> not sure if we are going to do alternate
[11:27] <seb128> or what ogra_ says
[11:27] <seb128> I never really used/tracked those anyway :p
[11:27] <ogra_> yeah, dead and gone
[11:28] <ogra_> we have server images that use the texxt based installer ... but even these use debians live-installer internally ... plain alternate is only the netinst img  nowadays
[11:29] <seb128> xnox, do you plan to port ubiquity to Qt?
[11:29]  * ogra_ grins 
[11:29] <xnox> seb128: only after we get rid of qt4 of the desktop image.
[11:29] <seb128> I'm unsure what's even the plan for desktop installer
[11:29] <seb128> since I guess we are going to converge desktop to system images as well
[11:30] <asac> seb128: ubiquity is GTK isnt it? will that work on mir?
[11:30] <asac> e.g. do we have a backend yet
[11:30] <seb128> asac, yes yes no
[11:30]  * asac matches answers
[11:30] <seb128> it's GTK, getting a GTK backend for Mir is on our roadmap for this cycle
[11:30] <seb128> but it's not done yet
[11:30] <asac> seb128: so right now the installer wont work?
[11:30] <seb128> right
[11:30] <asac> or is there a bandaid/hack?
[11:30] <asac> ic ic
[11:31] <seb128> so first images are going to be liveCD environment you can play with
[11:31] <asac> seb128: so you think its feasible as a malta goal to have a demo image?
[11:31] <asac> ic
[11:31] <xnox> seb128: that is either write u1 plugin page for u-c-c / online-accounts or otherwise port it to qt5
[11:31] <asac> so no installer
[11:31] <asac> ack
[11:31] <seb128> a live image you can boot and use to test unity8 yes
[11:31] <seb128> no installer
[11:31] <xnox> seb128: i heard the plans were for unity8 session to start from an lxc container, thus a normal installer can still be used.
[11:31] <seb128> xnox, with is ubiquity depending on dropping qt4?
[11:32] <asac> seb128: so we cant run the installer tests then i guess?
[11:32] <seb128> not in a first time no
[11:32] <asac> (checking on what we just discussed as malta goal)
[11:32] <xnox> seb128: i mean personal / priority / size-constraints, although i guess we already ship both qt4 & qt5.
[11:32]  * asac scratches that then
[11:33] <seb128> xnox, we do ship both yes, webapps are using the qt5 stack at least
[11:33] <asac> maybe we can run the unity8 APs on the live session instead to have something on dash?
[11:33] <seb128> asac, that would work for me
[11:33] <seb128> boot the live image
[11:33] <seb128> run the ap tests
[11:33] <xnox> seb128: i can check how much work it would be to port kubuntu's qt4 frontend to qt5. But that won't be qml / ubuntu-components.
[11:33] <asac> seb128: i somehow sense that this live session is kind of close to a system image :)
[11:33] <seb128> xnox, that's fine, that would give use a qpa for Mir
[11:33] <asac> just saying
[11:33] <asac> e.g. its read only
[11:34] <asac> you install it through usb-creator
[11:34] <seb128> right
[11:34] <asac> maybe we could try using a proper RO partition instaed of the squashfs?
[11:34] <ogra_> why would we not want X btw ?
[11:34] <asac> think would be much faster to use then
[11:34] <asac> ogra_: X?
[11:34] <ogra_> i assume you will want XMir to be usable to run X apps
[11:34] <asac> there is no Xmir right now
[11:34] <ogra_> so having the old ubiquity running under X shouldnt be a prob
[11:35] <seb128> ogra_, is that working in current e.g trusty unity8 test session?
[11:35] <ogra_> did we drop XMir ?
[11:35] <ogra_> it was there for the last cycle
[11:35] <seb128> I don't think we dropped it
[11:35] <asac> ogra_: that effort was folded before saucy release, yes
[11:35] <xnox> asac: why usb-creator?
[11:35] <ogra_> ah
[11:35] <asac> its in the plans though
[11:35] <didrocks> seb128: asac: FYI, otto was doing that: booting the live system
[11:35] <didrocks> and running tests on it
[11:35] <ogra_> i thought it worked last cycle already
[11:35] <seb128> it did
[11:35] <asac> xnox: thats how you install the live cd on a usb stick, no?
[11:35] <seb128> ubiquity might just run fine on it then
[11:36] <ogra_> well, let the installer run on plain X ... thats tested and reliable ... only start using Mir on the installed system then
[11:36] <asac> would we want to move away and rather make ubuntu-device-flash the way to do that? i dont think so; somehow feel maybe usb-creator could become the next gen ubuntu-device flash :)
[11:36] <xnox> asac: use dd. usb-creator is specific to live/ubuntu-cd isos and doesn't reliably wipe usb-sticks.
[11:37] <asac> xnox: hmm. so you say usb-creator is a dead end? and if we wanted to do a UI for installing things like touch and unity8 with system image in the future we rather should do a new tool?
[11:37] <ogra_> usb-creator has a pretty bad reputation ...
[11:37] <asac> xnox: note that we are talkinga bout creating a livecd for unity8 as first step... feels matches what usb-creator does
[11:37] <ogra_> due to it having been so buggy in the past
[11:38] <asac> so a new UI tool has to arrive?
[11:38] <ogra_> it only got a lot better recently
[11:38] <xnox> asac: it's not currently actively maintained, and it has a few bugs.
[11:38] <asac> right, but should we invest in making that better or rather go for a new tool from scratch?
[11:38] <asac> or make dd our official end-user tool :P?
[11:38] <ogra_> a new name at least :)
[11:38] <xnox> asac: getting time on fixing it up, would be useful. but nobody is doing that at the moment. I saw a few bugs report from Timo about it, but no connection that there is high-priority work done that will rely on usb-creator.
[11:39] <asac> yeah
[11:39] <xnox> asac: making it better should be feasible.
[11:39] <asac> xnox: how gtk specific is the code? if the logic his highly coupled with GTK/UI logic, then guess a qt tool might be the way to go indeed
[11:40] <ogra_> we have no python QML bindings yet, do we ?
[11:40] <didrocks> s/the way to go/the way *in* go/ :)
[11:40] <xnox> asac: both ubiquity and usb-creator have backend code and frontends. both have gtk+ and a qt4 frontends.
[11:41] <xnox> ogra_: we do have qml python bindings, not in main however.
[11:41] <ogra_> ah, cool, that got better then
[11:43] <asac> hmm
[11:43] <asac> xnox: is that code at least py3 yet?
[11:44] <didrocks> it is
[11:44] <xnox> asac: all of it is py3. we ported that cycles ago (quantal?)
[11:44] <ali1234> ochosi: seb128 just uploaded the gtk2 patch to a ppa... https://launchpad.net/~a-j-buxton/+archive/gtk2mountop/+packages
[11:44] <asac> quantal was before my resurrection :P
[11:45] <ali1234> *i just uploaded...
[11:54] <seb128> ali1234, ok
[11:55] <ochosi> ali1234: thanks, i'll wait till it has built and then test it
[13:22] <pmcgowan> bregma, hey, nice work on the analysis of that touch bug, what exactly is the fix thats needed now
[13:22] <pmcgowan> its in the QPA from upstream?
[13:23] <bregma> yes
[13:23] <seb128> what's the bug number?
[13:23] <bregma> at the moment I'm rebuilding Qt with explicit tablet support disabled
[13:23] <bregma> to verify
[13:24] <pmcgowan> bregma, ok will stand by
[13:24] <bregma> if that fixes things, it goes upstream to Qt, otherwise it goes upstream to x.org
[13:24] <pmcgowan> seb128, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701
[13:24] <seb128> pmcgowan, thanks
[13:27] <mlankhorst> do we have people working on qt5?
[13:35] <pmcgowan> mlankhorst, as needed but not full time, we have made some bug fixes
[14:02] <seb128> bregma, hey, I'm playing with the unity8-mir session ... does that include xmir/a way to start X apps?
[14:09] <seb128> om26er, hey, could you help to figure out what's the issue with ubuntu-system-settings and CI, we get failures similar to https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/4451/? on the CI runs for some reason
[14:10] <om26er> seb128, in a call, will do that in a few minutes
[14:13] <seb128> om26er, no hurry, thanks
[14:26] <mlankhorst> pmcgowan: ok do you understand the input stack of qt?
[14:26] <pmcgowan> mlankhorst, no experience with it
[14:26] <pmcgowan> I suspect some of the unity8 guys are pretty aware
[14:27] <pmcgowan> Saviq, or greyback perhaps
[14:27] <mlankhorst> ok
[14:27] <greyback> mlankhorst: what do you need to know?
[14:30] <mlankhorst> greyback: it's for bug https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701 -- I don't completely understand the qt changes required for it
[14:31] <greyback> mlankhorst: ah, dandrader working on that as we speak. He can tell you more
[14:31] <greyback> will ask him to join this channel if you'd like
[14:32] <pmcgowan> greyback, bregma is doing a test now to disable tablet
[14:32] <seb128> kenvandine, hey
[14:32] <kenvandine> hey seb128
[14:32] <seb128> kenvandine, can you review https://code.launchpad.net/~laney/ubuntu-system-settings/data-roaming-disable/+merge/217965 ... it's a small change, just some sanity check
[14:32] <kenvandine> sure
[14:33] <seb128> kenvandine, thanks
[14:34] <pmcgowan> greyback, I think the issue is these folks are not familiar with Qt and may need some other eyes on the code
[14:36] <greyback> pmcgowan: ok. dandrader knows the Qt input handling code better than I do, and I know he's working on it. But if other opinion needed, let me know
[14:36] <pmcgowan> ok
[14:40] <mlankhorst> yeah asked him, but he's not touching it for this bug :(
[14:40] <mlankhorst> so I'll do it myself
[14:45] <greyback> mlankhorst: dandrader is definitely working on that bug right now. But he thinks the problem is somewhere in X11. If you disagree, I'm sure he's like to know your reasoning
[14:45] <greyback> s/he's/he'd/
[14:46] <mlankhorst> true, but the touch code is next to impossible to understand. :P
[15:02] <Trevinho> xnox: moving here...
[15:02] <Trevinho> Well, the gnome-keyring thing would be nice, but is it possible to get that in 14.04 as well?
[15:02] <seb128> Trevinho, gnome-keyring what?
[15:02] <Trevinho> xnox: the fact is that gnome-session is not reliable in restarting unity if it crashes, and this might cause security issues if it was locked...
[15:03] <Trevinho> seb128: it's fricking env variables...
[15:03] <seb128> oh, right
[15:03] <Trevinho> seb128: trying to move unity to upstart, causes some trobules
[15:03] <seb128> :/
[15:04] <Trevinho> seb128: basically I'm getting a terminal launched with ctrl+alt+t (thus fron unity-settings-daemon, I suppose) with all the env correctly set... but if launch one from the launcher/dash I miss some of the gnome keyring envs
[15:05] <Trevinho> seb128: for reference, sudo sed "s/compiz;//" -i /usr/share/gnome-session/sessions/ubuntu.session -> start your (guest) session and env | grep key will act differently
[15:06] <xnox> Trevinho: the way i move unity under upstart is different.
[15:06] <seb128> Trevinho, k
[15:06] <xnox> Trevinho: instead of removing compiz from ubuntu.session, i make compiz exec command to be "start compiz" and add appropriate job for it.
[15:08] <xnox> Trevinho: gnome-keyring env variables are missing, because of bug #1271591
[15:08] <xnox> which is solved in unicorn by now, but not yet in trusty. I will sru that change.
[15:08] <xnox> ubuntu bot is gone?
[15:08] <Trevinho> xnox: ah, nice...
[15:09] <Trevinho> xnox: what is the way you make compiz to run with upstart btw (I said that since it's the faster to try)
[15:09] <Trevinho> xnox: and... why these envs are applied to unity-settings-daemon job instead?
[15:10] <xnox> Trevinho: i don't understand "why these envs are applied to unity-settings-daemon job instead?" can you explain more, what you mean?
[15:10] <Trevinho> xnox: if you use ctrl+alt+t to run a terminal, it has all the keyring envs, even if it's still launched by upstart and not by g-s-
[15:12] <xnox> Trevinho: the bug about gnome-keyring is that it's agent environment variables are available to everything that's started by e.g. gnome-session, but those variables are not exported to upstart thus $ initctl list-env doesn't show them, and anything started by upstart doesn't have them.
[15:12] <xnox> Trevinho: echo "exec compiz" > ~/.config/upstart/compiz.conf
[15:13] <Trevinho> xnox: ok, that was my guss as well and what I would have done to fix it anyway...
[15:13] <xnox> Trevinho: and change /usr/share/applications/compiz.desktop "Exec= start compiz"
[15:13] <Trevinho> xnox: ah, ok... that's what happens already in unity7.conf if you remove the grep-check
[15:13] <xnox> Trevinho: the fix for gnome-keyring is in utopic....
[15:13] <xnox> Trevinho: look at the gnome-keyring job in utopic.
[15:14] <Trevinho> xnox: yep, I'm on it now
[15:14] <xnox> Trevinho: you can just copy it. E.g. pull-lp-source gnome-keyring; cp gnome-keyring-*/debian/gnome-keyring.conf ~/.config/upstart/
[15:14] <xnox> start gnome-keyring
[15:14] <xnox> and everything should be fixed.
[15:14] <Trevinho> xnox: altough while that fix is reasonable to me, I was worried about other possible generic g-s clients that might use its dbus interface to register env variables...
[15:15] <Trevinho> xnox: so, I was thinking if we should instead do something like that inside the callback of RegisterEnv variable of gnome-session dbus interface
[15:15] <xnox> Trevinho: what's that interface? we can grep the archive and check who / where does it.
[15:15] <xnox> Trevinho: instead of gnome-session dbus interface, one would set it via upstart instead e.g. initctl set-env FOO=bar
[15:16] <Trevinho> xnox: ok, sure, but you know it's not always the nicest thing to do when you might use a global fix instead :)
[15:16] <xnox> Trevinho: ideally i wouldn't be running gnome-session at all =) but we are not there yet.
[15:16] <Trevinho> xnox: indeed, but that will apply to all the apps already running (if that cames later)?
[15:16] <xnox> Trevinho: yes, it will apply to all the apps already running.
[15:17] <xnox> Trevinho: as it would set it for gnome-session as well.
[15:17] <Trevinho> xnox: thus, why not changing org.gnome.SessionManager.SetEnv to call it?
[15:17] <Trevinho> xnox: I didn't try yet, but for sure from my devbugging it gets called by the keyring-daemon
[15:17] <xnox> Trevinho: we could do that as a hook.
[15:18] <Trevinho> xnox: anyway from my tests "initctl set-env FOO=bar" doesn't ever apply to all the upstart started apps :/
[15:18] <Trevinho> no idea why
[15:18] <Trevinho> It did once, but now I fail to get it
[15:18] <xnox> it should be.
[15:18] <xnox> oh, --global.
[15:18] <Trevinho> yeah, also witht htat flag
[15:19] <xnox> hm.
[15:19] <xnox> this is odd, it should be modifying environment of all running jobs.
[15:19] <xnox> i'll follow up on that.
[15:20] <Trevinho> xnox: ok, anyway for now it would be nice if yo might sru the gnome-keyring-daemon change, so we can sru also the change at unity level
[15:21] <xnox> Trevinho: you are sruing running unity under upstart ?!
[15:21] <xnox> Trevinho: what's the bug number?
[15:21] <Trevinho> xnox: https://bugs.launchpad.net/unity/+bug/1308800
[15:22] <Trevinho> until I noticed that...
[15:23] <xnox> Trevinho: oh, it's not started by upstart in error....
[15:25] <Trevinho> xnox: what's the equivalent of initctl set-env *--global* using dbus? as it always seems to need the job name
[15:28] <xnox> Trevinho: there is dbus api for it - as initctl itself uses dbus api to actuall do everything.
[15:29] <Trevinho> xnox: yeah, I know, but what parameter should be used for "global"... as the first parametert needs the ["job", "instance"], thing...
[15:29] <KombuchaKip> Hey folks!
[15:29]  * KombuchaKip waves at seb128, brookswarner, and everybody else.
[15:29]  * KombuchaKip is working on two bugs, one in Thunderbird and the other in Eiciel.
[15:30] <seb128> KombuchaKip, hey
[15:30] <seb128> ok, it's meeting time
[15:30] <seb128> qengho, Sweetshark, mlankhorst, tkamppeter, desrt, attente, larsu, kenvandine, KombuchaKip: hey, it's meeting time ;-)
[15:30]  * kenvandine waves
[15:31] <qengho> Hey, y'all.
[15:31] <seb128> I hope everybody is doing well
[15:31]  * Sweet5hark runs from the beach and into the shade.
[15:31] <seb128> let's get started
[15:31] <seb128> qengho, hey
[15:31] <qengho> Just one item:
[15:31] <qengho> - in-progress: working on chromium bugs, mostly high-dpi popups, then tabs.
[15:31] <qengho> EOF
[15:32] <seb128> qengho, tabs being the session issue?
[15:32] <qengho> I looked a little at the tabs problem.
[15:32] <seb128> I saw some extra users joined in commenting they see the issue as well
[15:32] <mlankhorst> ohai
[15:32] <xnox> Trevinho: if instance is empty, it looks like global is auto-activated.
[15:32] <qengho> seb128: Yes. I found an interesting sorting function. I don't know if it' the cause yet.
[15:32] <seb128> xnox, Trevinho: can you move to another channel, we have a meeting starting
[15:33] <seb128> qengho, ok, I'm subscribed to the bug, so I'm going to watch it for comments if you found more ;-)
[15:33] <seb128> qengho, I can also do testing/provide debug info if needed
[15:33] <qengho> Yes. Thanks.
[15:33]  * xnox ducks
[15:33] <seb128> qengho, thanks
[15:34] <seb128> Sweet5hark, still on the beach?
[15:34] <Sweet5hark> nope, in the hotel.
[15:34] <Sweet5hark> - precise SRU tweaks and redtape
[15:34] <Sweet5hark> - a tiny bit more on the menu corner case
[15:34] <Sweet5hark> - othewise: was off on Thursday/Friday for holiday/vacation
[15:34] <Sweet5hark> EOF
[15:35] <seb128> Sweet5hark, give me a ping when you get that SRU ready for upload again
[15:35] <Sweet5hark> seb128: yep, going through the checklist right now.
[15:35] <seb128> good
[15:36] <seb128> Sweet5hark, thanks
[15:36] <seb128> mlankhorst, hey
[15:36] <mlankhorst> mostly working on the touch bugs, looks like we have a workaround at least..
[15:36] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701 and presumably https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1311828 being related
[15:37] <seb128> great
[15:38] <seb128> nice to see you guys have an handle on those issues
[15:38] <seb128> mlankhorst, thanks
[15:38] <seb128> tkamppeter, hey
[15:38] <mlankhorst> still waiting on my touch laptop :/
[15:38]  * KombuchaKip is working on https://bugs.launchpad.net/ubuntu/+source/eiciel/+bug/1315098
[15:38] <tkamppeter> - cups: Merged Ubuntu changes (socket-activated on-demand running of the daemon with Upstart, no hard dependency on avahi-daemon) to Debian so that Debian and Ubuntu packages can get synced again.
[15:38] <tkamppeter> - ghostscript: Updated to upstream version 9.14.
[15:38] <tkamppeter> - hplip, system-config-printer, ghostscript: Prepared SRUs for Trusty (all waiting for verification now)
[15:38] <tkamppeter> - cups-filters: Let cups-browsed do case-insensitive comparing of device URIs and CUPS queue names now, investigations for further bug fixes.
[15:38] <tkamppeter> - Started mentoring of GSoC students
[15:38] <tkamppeter> - Bugs.
[15:38] <seb128> KombuchaKip, it's not your turn yet, please wait for your name to be listed
[15:39] <seb128> tkamppeter, did you find anyone knowing ghostscript to ping/email about that libspectre issue?
[15:41] <tkamppeter> seb128, not yet, seems that I have to send a private e-mail to Marek Kasik.
[15:41] <seb128> tkamppeter, ok, thanks
[15:41] <seb128> desrt, hey, your turn
[15:42] <desrt> hey
[15:42] <desrt> was in berlin most of last week, doing the gtk hackfest
[15:42] <desrt> got a lot done there -- reached concensus on a lot of issues, including the introduction of a data model API in GLib
[15:42] <desrt> also talked about next steps on things like GProperty, epollification of mainloop, etc.
[15:43] <desrt> did some work on introspection and just landed the support for nullable parameters/return-types in master a few hours ago
[15:43] <desrt> that broke some stuff, so i'm currently in emergency-chase-down mode
[15:43] <desrt> that's all, really
[15:44] <seb128> desrt, did you discuss the headerbars and gtk/mir at the hackfesT?
[15:44] <desrt> yes
[15:45] <desrt> at least for the gtk/mir front, gtk is openminded, will accept patches, etc.
[15:45] <desrt> under the threat that it gets ripped out if we don't maintain it properly
[15:45] <desrt> about headerbars, larsu probably has more to say about this
[15:45] <desrt> one thing we did discuss was about the app-prefers-appmenu thing
[15:46] <desrt> gnome did some additional testing in this area and found that some small improvements increased the discoverability/usability of the app menu, so it seems that they will keep it
[15:46] <desrt> so the app-prefers-appmenu thing will go in now
[15:46] <seb128> ok, good
[15:46] <desrt> that gives a pretty simple mechanism for the menu story at least -- and apps may be able to use that to conditionalise headerbar
[15:46] <desrt> but i'm not sure that's desirable
[15:46] <desrt> larsu and i part a bit on this point....
[15:47] <seb128> ok
[15:47] <seb128> let's see how that goes, doesn't seem like a topic we need to resolve during the meeting
[15:47] <seb128> desrt, thanks!
[15:47] <desrt> :)
[15:47] <seb128> attente, hey
[15:48] <attente> hey seb128
[15:48] <attente> java non-latin shortcuts PPA, fixes Inkscape, Blender, IntelliJ, NetBeans, but breaks Eclipse and possibly other java apps. shift problem still exists under unity though, no progress there.
[15:48] <attente> work on https://bugs.launchpad.net/unity-settings-daemon/+bug/1315867, still in progress.
[15:48] <attente> gnome-shell/classic g-s-d modifier-only shortcuts hack, pushed this to the java non-latin shortcuts PPA.
[15:48] <attente> eof
[15:48] <seb128> ok
[15:49] <seb128> attente, let me know if you get anything ready for SRU or if you need help testing for something
[15:49] <seb128> I'm happy to organize landing for SRUs or help testing
[15:49] <attente> seb128, sure, thanks
[15:50] <seb128> yw!
[15:50] <seb128> attente, thanks
[15:50] <seb128> larsu, your turn ;-)
[15:50] <larsu> oh hey
[15:50] <larsu> talking to rishi right now about g-t
[15:50] <larsu> but that can wait I guess
[15:50]  * KombuchaKip will brb
[15:51] <larsu> I was at the berlin hackfest with desrt, talking about gtk things
[15:51] <larsu> trying to convince people that having gtk support !GNOME desktops is a good idea
[15:51] <larsu> with mixed results (as desrt already mentioned)
[15:51] <seb128> how did that go?
[15:51] <seb128> :/
[15:51] <larsu> in general, they're fine with it as long as somebody else does the work
[15:52] <larsu> but seem a bit reluctant about us in particular because it seems we're moving away from gtk in the mid-term
[15:52] <seb128> right
[15:52] <seb128> well our default desktop is
[15:53] <larsu> right
[15:53] <seb128> it doesn't mean app writers wouldn't be interested to have their apps work on our desktop
[15:53] <larsu> but there's even less active involvement from the other desktops
[15:53] <larsu> (upstream, I mean)
[15:53] <seb128> ok
[15:53] <larsu> right, that was the point I tried to make
[15:53] <larsu> and I think if we produce good patches they have a chance
[15:54] <larsu> Company in particular isn't a huge fan of headerbars anyway
[15:54] <larsu> and he dislikes the state of gtkwindow.c - so if we can clean that up a bit while adding support for traditional title bars, we might have a chance
[15:54] <seb128> ok
[15:55] <larsu> I'm still not sure which way is the better one for us to take
[15:55] <seb128> that's another topic we are not going to resolve during the meeting in any case ;-)
[15:55] <seb128> yeah, me neither, let's discuss it more in the next weeks
[15:55] <larsu> but I've looked into it the last days and I can say that going the headerbar-as-toolbar route is definitely much easer
[15:55] <larsu> *easier
[15:55] <larsu> as in, will take us less time to implement
[15:55] <larsu> which might be what we're going for this cycle
[15:55] <seb128> that should be good enough I think
[15:55] <larsu> (the other option would be to go csd ourselves)
[15:55] <seb128> sounds like a plan
[15:56] <seb128> it doesn't prevent us to do csd later if we want
[15:56] <larsu> seb128: right, especially since we won't have that many headerbarified apps anyway
[15:57] <larsu> I'm also not sure about the traditional menu bar patches I did
[15:57] <larsu> now that everything is going headerbar, they have less chances of getting in
[15:58] <larsu> I think that's eof for me - not much else was going on
[15:58] <larsu> (and desrt already talked about the hackfest)
[15:58] <desrt> larsu: you forgot the most important part
[15:58] <desrt> you may have caused me to overcome my club mate aversion
[15:58] <seb128> urg, club mate
[15:58] <desrt> seb128: it's an acquired taste, man
[15:59] <larsu> seb128: he loves it now
[15:59] <desrt> "love" is a bit strong...
[15:59] <desrt> but certainly the "urg" is gone
[15:59] <seb128> good for you? ;-)
[15:59] <seb128> larsu, thanks
[15:59] <seb128> kenvandine, hey
[16:00] <larsu> https://plus.google.com/u/0/photos/+ChrisK%C3%BChl/albums/6008888709869480017/6010050660182189954?pid=6010050660182189954&oid=107949128852701224835
[16:00] <kenvandine> yo!
[16:00] <Sweet5hark> (club mate is a suitable fallback if there is no fritz cola.)
[16:00] <larsu> Sweet5hark: haha, you're funny.
[16:00] <kenvandine> finished up work on the download manager integration with content-hub, adding snap decisions until we get a replacement for the transfer indicator
[16:01] <kenvandine> and worked on getting libphonenumber packaged up for utopic
[16:01] <kenvandine>  /EOF
[16:01] <seb128> kenvandine, the transfert indicator is not a thing anymore?
[16:01] <kenvandine> oh man... don't get me started :)
[16:01] <kenvandine> it's dead now...
[16:02] <Sweet5hark> larsu: not funny, just patriotic about softdrinks from my home town.
[16:02] <kenvandine> until we get designs for something else, we are using a snap decision
[16:02] <larsu> Sweet5hark: ;)
[16:02] <seb128> kenvandine, ok
[16:02] <seb128> kenvandine, thanks
[16:02] <kenvandine> sorry i'll miss you guys in malta!
[16:03] <seb128> kenvandine, feel free to ping me if you need an archive admin review for libphonenumber
[16:03] <kenvandine> seb128, you're on my hit list for today :)
[16:03] <seb128> kenvandine, oh right, you shifted to first week :/ let's see if we can get some beers anyway
[16:03] <kenvandine> just need to finish up the beloved debian/copyright
[16:03] <seb128> kenvandine, ;-)
[16:03] <seb128> kenvandine, when do you leave? friday? saturday?
[16:03] <kenvandine> early sat
[16:03] <kenvandine> like 5:30
[16:04] <kenvandine> seb128, when do you get in?
[16:04] <Scunizi> Trying to join #ubuntu results in "You must be invited".. What's up with that?
[16:04] <seb128> kenvandine, wednesday, take some vac days before with others
[16:04] <seb128> kenvandine, let's try to have beers on friday or something maybe
[16:04] <kenvandine> oh... so i will see you :)
[16:05] <kenvandine> cool!
[16:05] <seb128> anyway, not a meeting's topic
[16:05] <kenvandine> yeah, you know where i'll be :)
[16:05] <seb128> right ;-)
[16:05] <seb128> KombuchaKip, hey, your turn
[16:07] <seb128> ok, he seems to not be there
[16:07] <seb128> so my turn
[16:07] <seb128> (short week with may 1st holidays)
[16:07] <seb128> .
[16:07] <seb128> * still quite some bugs reading/triaging
[16:07] <seb128> * uploaded some bugfixes as trusty SRUs
[16:07] <seb128> * started looking at what the unity8/mir teams are planning for this cycle to know what is coming
[16:07] <seb128> * played with unity8/mir on desktop
[16:07] <seb128> * started reviewing the accumulated ubuntu-system-settings merge requests
[16:07] <seb128> * spend some time looking at work coming for next cycle/see how to prioritize/what to focus on

[16:08] <seb128> (note that thursday is an holiday again here, end of ww2)
[16:08] <larsu> seb128: finally!
[16:08] <seb128> larsu, finally what? end of meeting? ;-)
[16:08] <KombuchaKip> seb128: Hey man. I'm working on two issues. One of them is a Thunderbird issue and the other is an ACL issue. The latter is here: https://bugs.launchpad.net/ubuntu/+source/eiciel/+bug/1315098
[16:09] <larsu> seb128: end of ww2
[16:09] <seb128> larsu, oh! :p
[16:09] <larsu> :P
[16:09] <seb128> larsu, you guys should have a it off as well
[16:09] <seb128> it's a win for everyone
[16:09] <larsu> I don't think we do
[16:09] <seb128> right
[16:09] <seb128> you should
[16:09] <larsu> right
[16:09] <seb128> oh well
[16:09] <larsu> we should have a holiday every week if you ask me
[16:09]  * larsu doesn't even care for the reason
[16:09] <seb128> larsu, sorry, my brain was not in "get the IRC jokes" mode :p
[16:09] <seb128> lol
[16:09] <larsu> hehe
[16:09] <seb128> KombuchaKip, ok, thanks
[16:10] <seb128> I think that's everyone
[16:10] <seb128> was there anything else to discuss?
[16:10] <KombuchaKip> seb128: np. I'm just the boring desktop guy.
[16:10] <seb128> KombuchaKip, you are not, those bugfixes are important ;-)
[16:10] <KombuchaKip> seb128: ;
[16:10] <KombuchaKip> seb128: ;)
[16:11] <seb128> ok, seems like we don't have other topics
[16:11] <seb128> thanks everyone!
[16:11] <Sweet5hark> larsu: we could start another one, on the offchance that we get a holiday for ending that one ...
[16:12] <larsu> lol
[16:12] <larsu> not sure the trouble would be worth it...
[16:13] <attente> seb128, would like to start the sru process for https://code.launchpad.net/~attente/unity/1291461/+merge/215848 and https://code.launchpad.net/~attente/unity-gtk-module/1208019-2/+merge/216964
[16:14] <attente> but not really sure how to proceed exactly
[16:17] <Sweet5hark> larsu: true. since france has nuclear stuff, we certainly shouldnt do it while at home. Maybe when we are in Malta. as that one will be rather quick, we could even do the peace talks with seb in the evening over a beer.
[16:17] <Sweet5hark> seb128: http://people.canonical.com/~bjoern/precise/3.5.7/ubuntu6/libreoffice_3.5.7-0ubuntu6_source.changes should be good for upload.
[16:18] <Sweet5hark> seb128: although ...
[16:19] <seb128> attente, unity, I guess it can be included in one for their SRU rounds once it's approved, check with bregma
[16:19] <mvo> tedg: if at some point you have time to have a quick look at https://code.launchpad.net/~mvo/upstart-app-launch/hide-apps-on-missing-framework that would be great, just if the general direction looks ok, its not quite ready for merging yet (one test failure, tests needs updating etc and I need to double check that I haven't added any leaks). no rush as I need to go for dinner anyway now :)
[16:20] <seb128> attente, the other one, can you update the bug to be SRU compliant (it needs rational/test case/regression potential info)
[16:20] <seb128> desrt, larsu, tedg: can you review https://code.launchpad.net/~attente/unity-gtk-module/1208019-2/+merge/216964 for attente?
[16:20] <attente> seb128, sure, thanks!
[16:20] <seb128> attente, yw!
[16:22] <tedg> mvo, No specific issue, but we don't get called again when the frameworks could get changed?
[16:22] <tedg> mvo, So it seems like we'd need some way to run on that case.
[16:22] <Sweet5hark> seb128: there was a -0ubuntu6 in precise-proposed already, wasnt it? I guess it wouldnt want a different upload with the same version then. well, if it fails as -0ubuntu6 just give me a ping, and tell me which version number it should have in the end.
[16:23] <tedg> attente, I think you have to put an action on the item that the submenu connects to. larsu ?
[16:23] <seb128> Sweetshark, 0ubuntu6 is fine, the same version can exist several times in the unapproved queue
[16:24] <attente> tedg, there's already an action on the submenu but it doesn't get activated
[16:24] <Sweet5hark> seb128: k, great.
[16:24] <tedg> attente, Hmm, that's weird. Do you know why that is?
[16:25] <larsu> attente, tedg: ya, it needs to be set as the "submenu-action" and have boolean state
[16:26] <tedg> larsu, If the app sets the value of that to true will the menu bar open the menu as well?
[16:26] <attente> larsu, tedg, oh ok. i didn't know about that
[16:26] <larsu> tedg: I don't think so, no
[16:26] <larsu> desrt knows the details ;)
[16:26] <larsu> attente: what is this code doing right now? Emitting show on everything to collect menu items?
[16:26] <tedg> Perhaps we could implement that in the QML implementation so we don't have to do all those global key watch hacks.
[16:27] <attente> larsu, yes
[16:27] <desrt> the menu should not automatically open based on submenu action
[16:27] <larsu> attente: craziness :)
[16:27] <desrt> there is no mechanism for menus that open themselves
[16:27] <larsu> desrt: nor should there be...
[16:28] <desrt> larsu: talk to ted ;)
[16:29] <larsu> attente: why is it not based on the submenu-action stuff? Because you didn't know about that yet?
[16:29] <larsu> desrt added it for that purpose (in LibreOffice)
[16:29] <attente> larsu, yeah, didn't know about it
[16:29] <attente> libreoffice is doing the same thing?
[16:31] <larsu> yes
[16:32] <larsu> I don't mind acking this for now if it's urgent thoguh
[16:32] <seb128> it's not "urgent"
[16:33] <seb128> but it's one of the issue that would be nice to see fixed
[16:41] <Sweet5hark> larsu, attente: I missed the context here. How did LibreOffice do something wrong, or how did you do something wrong to LibreOffice? ;)
[16:41] <attente> Sweet5hark, nothing wrong, just wondering how to make eclipse work as LO already does :)
[17:07] <Sweet5hark> seb128: thanks for uploading. I set the bug to "In Progress" and unsubscribed ubuntu-sponsors
[17:08] <seb128> Sweet5hark, sounds good, thanks
[17:08] <seb128> oh, and yw ;-)
[17:09] <Sweet5hark> seb128: I seem to remember that a bug used to be assigned or subscribed to ubuntu-sru, but cant find that in the docs anymore, so I didnt do anything to that point for now ...
[17:12] <seb128> Sweet5hark, right, they work from the queue so that's not required afaik
[17:12] <Sweet5hark> seb128: k, thanks.
[17:30] <Sweet5hark> pitti: ah, and thanks for the "affects precise" thing!
[18:41] <mvo> tedg: thanks for your feedback, i will look into this
[19:14] <tedg> mvo, I'm not sure how much we should worry about it or not, in general, I consider those desktop files just for legacy support. I think they'll go away in time.
[20:23] <mvo> tedg: thanks, when you say they are legacy, what will replace them? is that something worth talking about at the next sprint?
[20:30] <tedg> mvo, specific caches for the people who need that data. There's no need for a generic cache now that there's good hooks that everyone can use.
[20:30] <tedg> mvo, for instance the click scope could tokenize into it's core format when the app installed instead of on each login.
[20:32] <mvo> tedg: right, so we would need a separate hook on framework changes when this gets implemented
[20:33] <tedg> mvo, For building only the desktop files that have frameworks, yes. In general though, I don't expect new frameworks to get added much, but more in the "dpkg case" rather than the "image case".
[20:34] <tedg> mvo, So people who are using the desktop files (a Kubuntu or Xubuntu perhaps) are more likely to be dpkg based.
[20:35] <tedg> We need a better term there. Perhaps just read only image vs. read write.
[20:35] <tedg> Since the image is build from debs.
[20:36] <mvo> tedg: thanks! I will ponder a bit about it, I need to get used to the new-terms (and he new-world-order in general :)
[20:37] <tedg> mvo, Heh. BTW, that doesn't remove us discussing it at the sprint, that's a good idea too. :-)
[20:37]  * tedg isn't avoiding mvo
[20:38] <mvo> tedg: hehe :)
[20:38] <kenvandine> mvo!  new world order indeed!
[20:38] <tedg> In the new world order kenvandine is the beard saint.
[20:39] <kenvandine> tedg, that's not new :)
[20:39] <mvo> tedg: there is a "building click packages" on the agenda already, but it does not sound like its a perfect fit
[20:39] <mvo> hey kenvandine
[20:39] <tedg> kenvandine, I'm just surprised jcastro hasn't shaved you in your sleep ;-)
[20:39] <kenvandine> haha
[20:40] <kenvandine> i hide from his razors, they are scary