[02:47] <darkxst> pitti, currently removing libpam-systemd breaks gnome-shell since the upstart script is still run, is there anything we can do about that?
[03:38] <pitti> good morning
[03:38] <pitti> darkxst: you mean if you remove it, but not purge?
[03:39] <darkxst> pitti, yes
[03:39] <pitti> darkxst: we could change the upstart job to check whether libpam-systemd is actually installed
[03:39] <darkxst> its on staging now, but requires the manual purge step if people want to remove it
[03:39] <thumper> pitti: isn't it around 5:30am for you?
[03:39] <pitti> thumper: yes
[03:39] <thumper> geez
[03:39] <thumper> crazy
[03:39] <pitti> darkxst: so, it's a relatively simple fix, but I think at this point it needs to become an SRU
[03:40] <thumper> pitti: oh, and hai
[03:40] <pitti> darkxst: if you can file a bug for it, I'll upload a fix
[03:40] <darkxst> pitti, ok, thanks
[03:40] <pitti> thumper: my wife gets up at 5, and now that it becomes summer I slowly adapt to getting up early, too :)
[03:40]  * thumper nods
[03:43] <lifeless> pitti: is she sadistic?
[03:43] <pitti> lifeless: not in general, just an early bird :)
[03:44] <darkxst> pitti, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1171691
[03:44] <ubot2> Launchpad bug 1171691 in systemd (Ubuntu) "Removing libpam-systemd (without purge) breaks system" [Undecided,New]
[03:47] <pitti> darkxst: thanks
[04:49] <mlankhorst> g'day
[05:39] <pitti> darkxst: I uploaded a fix
[05:43] <darkxst> pitti, great! thanks
[07:34] <darkxst> pitti, suspend on lid closed is handled in logind?
[07:35] <pitti> darkxst: yes; gnome-settings-daemon's power plugin can set an inhibitor in some cases, but generally logind does that
[07:35] <seb128> hey desktopers
[07:36] <pitti> bonjour seb128
[07:36] <seb128> lut pitti, ca va bie n?
[07:36] <didrocks> salut pitti, seb128!
[07:36] <pitti> seb128: oui, merci ! et toi ?
[07:36] <pitti> bonjour didrocks
[07:36] <seb128> lut didrocks
[07:36] <seb128> pitti, je vais bien, merci ;-)
[07:39] <darkxst> pitti, it should work? (beacuse it isnt)
[07:40] <pitti> darkxst: I haven't tested that yet; if it doesn't work, I guess that's something which again depends on systemd init, so we need a fallback
[07:40] <darkxst> right
[07:51] <darkxst> pitti, seems to use the same target as a normal suspend, but its not firing for some reason
[07:58] <darkxst> perhaps its being inhibited for some reason? but I can't see anything logged ;(
[08:00] <pitti> darkxst: you can try from gdm/lightdm, or from a VT
[08:02] <darkxst> pitti, nope doesnt work there either
[08:02] <pitti> so I guess it relies on systemd-init to send the actual event
[08:02] <Laney> bonjour mes amis!
[08:03] <pitti> Laney: bonjour Laney, comment vas-tu aujourd'hui ?
[08:03] <Laney> très bien merci, et tu?
[08:04] <pitti> je vais bien aussi
[08:04] <pitti> mais je souhaite le retour du soleil
[08:05] <didrocks> salut Laney!
[08:05] <highvoltage> it will be back soon :)
[08:05]  * didrocks apprécie le soleil ici
[08:06] <pitti> la semaine prochaine nous allons être à California :)
[08:06] <darkxst> pitti, possibly, g-s-d does see the lid close event, so I guess we deal with it there
[08:06] <pitti> darkxst: raring's g-s-d is built against CK, so it does do the lid handling itself, yes; I assumed you had your own 3.8 version built against logind?
[08:06] <darkxst> pitti, with a dbus call to org.gnome.logind1.suspend() perhaps?
[08:07] <Laney> aujourd'hui j'ai soleil ici :-)
[08:07] <pitti> darkxst: no, raring's g-s-d calls upower
[08:07] <darkxst> pitti, yes we are built against 3.8
[08:07] <seb128> Laney, salut
[08:07] <Laney> hallo seb128! wie gehts?
[08:07] <seb128> Laney, gut, danke! und dir?
[08:08] <Laney> prima! die Sonne scheint :-)
[08:09] <seb128> ;-)
[08:13] <Laney> darkxst: do a dbus-monitor while you suspend and see what calls are taking place
[08:14] <Laney> assuming you've correctly enabled logind everywhere, that is
[08:15] <seb128> darkxst, hey
[08:16] <seb128> darkxst, re. libgweather, I looked at it a bit last week while I was trying to fix indicator-weather, it doesn't seem to use an online service for the locations but rely on the woeid to be in the db
[08:16] <seb128> darkxst, e.g https://git.gnome.org/browse/libgweather/commit/data/Locations.xml.in?id=349f453c9ac8c8b464b631b6c53e1de30932bc77
[08:17] <seb128> but there is only 1 location tagged for example so far
[08:17] <seb128> so that's not really useful
[08:17] <darkxst> seb128, oh I see, gnome-weather actually uses the yr.no provider
[08:18] <darkxst> although I though it also used yahoo if available
[08:18] <darkxst> Laney, logind is enabled and working fine, I am not seeing any relevent dbus calls when closing lid
[08:18] <seb128> well, using the service is easy, indicator-weather was doing that and can keep doing it
[08:19] <seb128> it only requires somebody to own the project and ask for an appid key
[08:26] <czajkowski> seb128: jtv is about if you need to ask why a POT isn't importing, sorry catching up on reading mails just saw you comment on on on coe-doc
[08:26] <czajkowski> *core
[08:26] <darkxst> Laney, when I use the actual suspend key there is a call to "prepareToSleep" on the logind1 service
[08:26] <Laney> darkxst: that's logind telling you it's about to sleep
[08:27] <Laney> if it's prepareToSleep "true" that is
[08:27] <Laney> "false" is when it's just finished sleeping (failed or succeeded)
[08:27] <seb128> czajkowski, hey, thanks, I was going to ask dpm
[08:27] <czajkowski> usually I just fix the inport selection by sorting out the name if it's not there
[08:27] <Laney> darkxst: you should be able to see whatever it is calling the Suspend method on logind if that's what's happening
[08:27] <czajkowski> but I cant see those pages to help where as jtv will know in a second whats up
[08:29] <dpm> seb128, on a call, will look into it in a minute. Do you have more context, or is it on the scrollback comments?
[08:29] <darkxst> Laney, nope, all I see is that and "DelayInhibited"
[08:29] <darkxst> Laney, and when actually closing the lid, I see nothing
[08:29] <seb128> dpm, hey, no hurry
[08:30] <Laney> darkxst: What does "dbus-send --system --dest=org.freedesktop.login1 --type=method_call /org/freedesktop/login1 --print-reply org.freedesktop.login1.Manager.CanSuspend" give you?
[08:30] <seb128> dpm, https://code.launchpad.net/~seb128/ubuntu-docs/updated-translations/+merge/160106/comments/352944
[08:30] <darkxst> Laney, that would be 'true'
[08:30] <seb128> dpm, those have a label "No import target selected yet.", dunno why
[08:31] <Laney> should be 'yes' 'no' or 'challenge'
[08:31] <darkxst> and calling org.freedesktop.login1.Suspend works
[08:31] <Laney> right, so the problem must be in gsd somewhere then
[08:31] <darkxst> Laney, yes sorry the answer is 'yes'
[08:32] <darkxst> there doesnt seem to be anything in gsd that fires the event
[08:32] <darkxst> so I guess its back to pitti's theory that the event comes from systemd init
[08:33] <czajkowski> seb128: the templates aren't set I think
[08:53] <didrocks> pitti: petite question sur les WI! How much work would it be to have the WI tracker to support [nameA,nameB,nameC] blablabla: TODO
[08:54] <didrocks> pitti: this would duplicate the tracker status per person
[08:54] <didrocks> having just one status
[08:54] <didrocks> I think there is the blueprint bot parser as well as the launchpad side to change?
[08:54] <pitti> didrocks: I don't know about the LP side (for https://launchpad.net/people/+me/+upcomingwork), the parsing is all done in LP now
[08:55] <didrocks> pitti: oh? no more cron then?
[08:55] <pitti> didrocks: as for the DB side on status.u.c., it's a fundamental change as you would have to move from "a WI is assigned to a person" to "a set of persons"
[08:55] <pitti> didrocks: and rewrite the whole thing with that in mind
[08:55] <didrocks> pitti: well, internally, it can be duplicated in the db
[08:55] <pitti> so frankly, it's better to create a team and assign it to that
[08:56] <pitti> didrocks: that would lead to wrong counts, though
[08:56] <didrocks> ah?
[08:56] <pitti> as that would count as three WIs
[08:56] <pitti> whereas the intended meaning is certainly "this or that or that person should do it"
[08:57] <didrocks> pitti: it's more "this is a topic, and those people are working on it"
[08:57] <pitti> well, topic == BP, not WI
[08:57] <didrocks> pitti: right, but a weekly BP seems overkill, especially when you will have few WI
[08:57] <pitti> didrocks: so taking a step back, what is your interpretation of that syntax?
[08:58] <didrocks> pitti: nameA, nameB and nameC are working together on that task
[08:58] <didrocks> pitti: this would avoid having tons of WI like on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-delivering-touch-apps-to-raring
[08:58] <didrocks> pitti: those WI seems separated, but they are not
[08:59] <didrocks> and all is interleaved
[08:59] <didrocks> like transitionning to HUD2 is impacting a lot of components
[08:59] <didrocks> with "needs merge A, B and C"
[08:59] <didrocks> I think a WI for each is overkill
[08:59] <didrocks> especially that we maybe need to merge D and E, so need to add a WI for the purpose of adding one
[08:59] <didrocks> where fixing it will be few minutes
[09:00] <pitti> what's an example of duplication on that BP?
[09:00] <pitti> well, you don't have to create WIs for a three-minute thing
[09:01] <pitti> you can summarize them like "transition all ubuntu packages to libfoo2"
[09:02] <pitti> didrocks: so "working together" means "any of the persons can do it" (that would be a team), or "this one WI is really three WIs for each assigned person" (that would be syntactic sugar for just expanding them)?
[09:04] <didrocks> pitti: I think it would mean "those 3 persons are working together to get that WI done, but we don't know/care about the great each 3 minutes individual subitems to do it"
[09:04] <didrocks> pitti: duplicating the same items 3 times for each person won't give that intent of "working together to get X done"
[09:04] <pitti> didrocks: ok, so you mean the first interpretation
[09:05] <didrocks> yeah
[09:05] <didrocks> but it's not really a team as the ones we have per say
[09:05] <pitti> if it's such a trivial thing, why bother splitting it amongst n people?
[09:05] <didrocks> can involve some people from our team, PS, foundation
[09:05] <didrocks> pitti: the task itself is not trivial, it's made of trivial things
[09:05] <didrocks> but the total amount is a big task
[09:05] <didrocks> and we need tracking that one
[09:06] <didrocks> for instance
[09:06] <pitti> so, I guess LP could make up teams on the fly for such groups
[09:06] <pitti> but TBH I don't see that happening
[09:06] <didrocks> I won't put "touch into S" as such
[09:06] <didrocks> but "transitionning to HUD2" is a perfect target
[09:07] <pitti> I would just leave the items unassigned, and everyone grabs a bunch when they have time; or pre-assign them and allow people to reassign
[09:07] <pitti> that way you also always have someone who is accountable
[09:08] <didrocks> pitti: hum, this doesn't really give the intent though of some people working on parallel on that task
[09:09] <didrocks> pitti: but if it was translated to "tihs one WI is separated in 3 WI on the db", I wouldn't really mind
[09:09] <pitti> didrocks: but that is the second interpretation, where you just said that's the one you don't want?
[09:09] <pitti> (first = "or", second = "multiply")
[09:10] <didrocks> pitti: as long as it's not what is shown in the blueprint and there is only one status, I'm fine with it to be translated as 3 separates things
[09:10] <didrocks> pitti: it's not or, it's "and"
[09:10] <didrocks> "those 3 persons are working together to get that WI done"
[09:10] <pitti> that means each individual person has to have a separate status and flip it to DONE
[09:10] <pitti> which is essentially a multiplication, yes
[09:11] <pitti> but how would you do that, if there is only one line to change?
[09:11] <didrocks> pitti: yeah, but that it doesn't represent the exact same intent ;)
[09:11] <pitti> if you have [seb128,didrocks,Laney]: foo, and Laney does his part, but you didn't yet, what would the status be?
[09:11] <didrocks> pitti: well, those 3 people can only consider to have their work DONE once the whole item is DONE
[09:11] <didrocks> basically
[09:11] <didrocks> no, for those WI, there is not really "that's my part and I don't care of yours"
[09:11] <didrocks> it's the exact opposite intent I hope we can get ;)
[09:12] <didrocks> liek seb128, didrocks and Laney are working together to get foo done
[09:12] <didrocks> even if seb128 and Laney are pestering didrocks to do his part he's slacking on :p
[09:12] <pitti> ok, so everyone does their part, or it doesn't matter who in particular does that WI?
[09:12] <didrocks> pitti: right
[09:12] <pitti> right what? :-) (either-or)
[09:13] <pitti> sorry, but I don't think I understand this yet
[09:13] <didrocks> pitti: everyone participates to this WI
[09:13] <didrocks> pitti: but there is not real "delimited part"
[09:13] <pitti> didrocks: so when is that WI done?
[09:13] <pitti> i. e. would [seb128,didrocks,Laney]: foo expand to
[09:13] <didrocks> once "foo" is DONE? :)
[09:14] <pitti> [seb128] do seb's part of foo:
[09:14] <pitti> [Laney] do Iain's part of foo:
[09:14] <pitti> etc.?
[09:14] <pitti> (that would be multiplication)
[09:14] <didrocks> in some way… the idea is that if didrocks can't work on foo today, seb can cover him :)
[09:14] <pitti> or whoever of seb128, Laney gets to it first, flips it to DONE?
[09:15] <pitti> didrocks: well, if that's the idea, what's wrong with
[09:15] <pitti> [didrocks] foo
[09:15] <didrocks> pitti: so idea is that the task will have at least, even a small part done by everyone of them
[09:15] <pitti> and Laney steals the WI if he has time, or the tech lead balances?
[09:16] <jamesh> xnox: hi.  What would be the best way to do an archive-index run for data found in a PPA?
[09:17] <didrocks> pitti: right
[09:17] <xnox> jamesh: last time, I had to rsync the ppa, setup apt-archive to generate Contents file, then point archive indexer at it (hack it up a little) and then it generates an index.
[09:18] <didrocks> pitti: the hidden goal is to have Laney doing everything TBH, but shhhh :p
[09:18] <xnox> jamesh: I've done it once, and maybe can setup up again, but more permament on like people.c.c. Which PPA are you after?
[09:18] <jamesh> xnox: The unity experimental one
[09:18]  * Laney has been ignoring all of these hilights for a good reason ...
[09:19] <xnox> jamesh: there a few, can you point which one you want? =)
[09:19] <jamesh> xnox: http://ppa.launchpad.net/ubuntu-unity/experimental-prevalidation/ubuntu
[09:19] <didrocks> Laney: don't worry, that won't change you will have everything to do :p
[09:20] <xnox> jamesh: ack. I can't promise to do it today, but hopefully soonish (in the middle of raring release). When do you need it by? i should have some older packages with index somewhere, if this is for software-center testing.
[09:22] <jamesh> xnox: if you can point me in the right direction, I could do a scan myself.
[09:24] <jamesh> I've got the archive-index code here.  I hit the "missing Contents" file problem, so it is mainly "download the PPA" and "build a Contents" file that I need
[09:25] <xnox> jamesh: right. So one can use recursive wget on http://ppa.launchpad.net/ubuntu-unity/experimental-prevalidation/ubuntu/
[09:26] <dpm> seb128, ok, looking at it now...
[09:26] <xnox> jamesh: and then write an apt-ftparchive config file to generate Contents file. http://manpages.ubuntu.com/manpages/lucid/man1/apt-ftparchive.1.html let me give slightly better reference.
[09:27] <xnox> jamesh: something like http://debian.scribus.net/debian/apt-ftparchive.conf
[09:28] <xnox> jamesh: but twiddle it for your own paths. Please note that regexpes in archive scanner are very narrow, and expect to have copy-paste comments from the top of the file.
[09:28] <xnox> just like on archive.ubuntu.com
[09:29] <jamesh> thank you
[09:42] <mhr3> seb128, about the issue we discussed yesterday, do you know of any way to reproduce it?
[09:42] <mhr3> in any application
[09:42] <seb128> mhr3, no, it happens on my box once every second week...
[10:55] <cyphermox> good morning!
[11:37] <seb128> cyphermox, hey, how are you?
[11:38] <cyphermox> seb128: hey. good, you?
[11:38] <seb128> I'm good thanks
[12:57] <pstolowski> mvo: ping
[13:03] <mvo> pstolowski: pong
[13:13] <pstolowski> mvo: hey!
[13:14] <kenvandine> didrocks, i figured out how to version QML plugins https://code.launchpad.net/~ken-vandine/libhud-qt/versioned/+merge/160363
[13:15] <didrocks> kenvandine: \o/
[13:15] <kenvandine> didrocks, what do you think of qtdeclarative5-hud1-plugin for a versioned package name?
[13:15]  * didrocks is eager to see the diff :)
[13:15] <seb128> kenvandine, good morning
[13:15] <pstolowski> mvo: I'm looking at a long-standing issue in applications lens, where we don't have icons for some installable stuff in more-suggestions (until you run software-center)
[13:15] <kenvandine> good morning seb128
[13:15] <didrocks> kenvandine: hud1 is the soname, or rather, the import name?
[13:15] <didrocks> import version*
[13:15] <kenvandine> yeah
[13:15] <mvo> pstolowski: this is about on-demand-downloding of icons?
[13:15] <pstolowski> mvo: in general, yes
[13:15] <kenvandine> we could do hud1.0 there too
[13:16] <didrocks> kenvandine: it should match the "import x"
[13:16] <didrocks> so if it's 1.0 I think 1.0 would make sense :)
[13:16] <pstolowski> mvo: app-lens looks for icons for uninstalled stuff in ~/.cache/software-center/icons and in /usr/share/app-install/icons
[13:16] <didrocks> kenvandine: btw, why -plugin?
[13:16] <kenvandine> so you prefer qtdeclarative5-hud1.0-plugin
[13:16] <kenvandine> well, that's the convention we've been using already
[13:16] <kenvandine> i would prefer we drop that :)
[13:17] <kenvandine> qtdeclarative5-hud1.0
[13:17] <pstolowski> mvo: what exactly lands in app-install-data package? (and why not all the icons, just some ;))?
[13:17] <didrocks> kenvandine: let's use qtdeclarative5-hud1.0
[13:17] <kenvandine> great
[13:17] <didrocks> kenvandine: do you mind adding Replaces/Break/conflicts?
[13:17] <didrocks> kenvandine: for the transition
[13:17] <kenvandine> we shouldn't need to
[13:17] <kenvandine> since it is parallel installable
[13:17] <kenvandine> with the 0.1 version
[13:18] <didrocks> and with the version in the ppa right now?
[13:18] <didrocks> (the next ppaà
[13:18] <kenvandine> right
[13:18] <didrocks> you rename some file
[13:18] <kenvandine> different path
[13:18] <didrocks> but it's not parallely installable
[13:18] <didrocks> usr/lib/*/qt5/qml ?
[13:19] <didrocks> the file name are changing?
[13:19] <kenvandine>  usr/lib/*/qt5/qml /Ubuntu/Hud.1/
[13:19] <kenvandine>  usr/lib/*/qt5/qml/Ubuntu/Hud.1/
[13:19] <didrocks> ah ;)
[13:19] <kenvandine> i saw that is how qtquick.2 was named
[13:19] <kenvandine> it has to be a single directory though, we can't do Ubuntu/HUD/1.0/
[13:20] <kenvandine> maybe i should make it Ubuntu/HUD.1.0
[13:20] <didrocks> hum
[13:20] <didrocks> what's the "Ubuntu" directory means?
[13:20] <kenvandine> namespace
[13:20] <kenvandine> import Ubuntu.HUD 1.0
[13:20] <didrocks> ok, so we can have no namespace
[13:20] <didrocks> or one namespace
[13:20] <didrocks> but not more?
[13:21] <didrocks> so no import Ubuntu.Awesome.HUD 1.0
[13:21] <didrocks> for instance?
[13:21] <kenvandine> i think we can
[13:21] <mvo> pstolowski: the icons from software-center.ubuntu.com are downloaded on demand
[13:21] <didrocks> kenvandine: ah, so only no version in namespace?
[13:21] <kenvandine> right
[13:21] <kenvandine> that didn't work
[13:21] <kenvandine> i couldn't find docs on why though :)
[13:21] <kenvandine> it was trial and error :)
[13:22] <didrocks> and it's not possible to ship different qml file and having qml importing the HUD.qml, HUD1.0.qml?
[13:22] <mvo> pstolowski: they are more dynamic, I need to look if the data-provider downloads them currently, I vaguely remember it does, but I may be wrong
[13:22] <kenvandine> didrocks, it's a .so and no
[13:22] <kenvandine> there is a qmldir file in that directory
[13:22] <kenvandine> with the module name and plugin name
[13:22] <kenvandine> i tried versioning the .so
[13:22] <kenvandine> but that doesn't work
[13:22] <kenvandine> it expects it to be unversioned
[13:23] <kenvandine> but there is prior art for versioning the import dir
[13:23] <didrocks> kenvandine: and how does it do the mapping that Ubuntu.HUD 1.0 is Ubuntu/HUD.1.0/ for instance?
[13:23] <didrocks> kenvandine: there is no mapping?
[13:23] <didrocks> it's just happens that the dir name is having a .so file which exposes 1.0?
[13:23] <kenvandine> i think it is in the plugin
[13:23] <kenvandine> the dir name doesn't identify that
[13:24] <kenvandine> i knows the difference
[13:24] <didrocks> ok, it's weird that versionning the .so doesn't work
[13:24] <kenvandine> it doesn't find the plugin at all
[13:24] <kenvandine> when it's versioned
[13:24] <didrocks> kenvandine: it expects a hud.so file?
[13:24] <kenvandine> basically
[13:24] <kenvandine> libhud-qml.so
[13:24] <didrocks> ok, so lib<imported_component>-qml.so
[13:25] <kenvandine> and there can only be a single qmldir file in the directory
[13:25] <kenvandine> yeah
[13:25] <didrocks> kenvandine: what's the qmldir is for in it?
[13:25] <kenvandine> well, the name of the file is in the qmldir file
[13:25] <didrocks> kenvandine: sorry for my noobs questions :)
[13:25] <kenvandine> module Ubuntu.HUD
[13:25] <kenvandine> plugin hud-qml
[13:25] <kenvandine> is the contents
[13:26] <kenvandine> so plugin hud-qml == libhud-qml.so
[13:26] <didrocks> and I guess no way to put version in it?
[13:26] <kenvandine> nope
[13:26] <didrocks> that would have been cool
[13:26] <didrocks> like
[13:26] <kenvandine> yeah
[13:26] <didrocks> module Ubuntu.HUD\nplugin hud-qml1.0 1.0
[13:26] <kenvandine> i was hoping for something like plugin hud-qml1 version 1.0
[13:27] <didrocks> plugin hud-qml1.1 1.1
[13:27] <kenvandine> yeah
[13:27] <kenvandine> it doesn't do that :)
[13:27] <didrocks> to define a mapping version <-> so filename
[13:27] <didrocks> yep
[13:27] <didrocks> ok, I think you came with the right decision then
[13:27] <didrocks> dirname == soname
[13:27] <kenvandine> yeah
[13:27] <kenvandine> they did that with qtquick.2 already too
[13:28] <didrocks> hum
[13:28] <didrocks> but the import has to change?
[13:28] <kenvandine> no
[13:28] <didrocks> as we change the namespace?
[13:28] <didrocks> what magic? ;)
[13:29] <didrocks> ah
[13:29] <didrocks> module foo.bar
[13:29] <kenvandine>  /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick.2/
[13:29] <kenvandine> for example
[13:29] <kenvandine> yeah
[13:29] <kenvandine> exactly
[13:29] <didrocks> so, I don't know why it doesn't take
[13:29] <kenvandine> that module line identifies that
[13:29] <didrocks> ubuntu/HUD/1.0/
[13:29] <didrocks> seems to be a side effect, not a namespace issue :)
[13:29] <kenvandine> dunno... that was what i assumed :)
[13:30] <didrocks> kenvandine: However, I do prefer your dir-soname
[13:30] <didrocks> can you change to map it?
[13:30] <didrocks> as well as the package name?
[13:30] <didrocks> and maybe just a replace (no conflict) for the transition?
[13:31] <kenvandine> so you mean changing it to Ubuntu/HUD.1.0 ?
[13:31] <kenvandine> i wonder if HUD-1.0 would work
[13:31] <kenvandine> probably
[13:31] <kenvandine> or
[13:31] <kenvandine> HUD1.0
[13:31] <didrocks> kenvandine: yeah, the last one is the more readable
[13:32] <kenvandine> i'll give it  a swing :)
[13:32] <didrocks> great!
[13:32] <didrocks> kenvandine: do you mind coordinating with sil2100? I think we need to change the dep in a lot of places :)
[13:32]  * sil2100 turns into an ear
[13:32] <didrocks> kenvandine: sil2100 is doing the transition to the new HUD today, but I guess, you won't be enough of being two if you have time :)
[13:33] <sil2100> ;)
[13:33] <didrocks> sil2100: the HUD runtime package is going to be renamed
[13:33] <didrocks> sil2100: so need to change that in the MP for new hud as well autopilot runs :)
[13:33] <didrocks> (list of packages to install and so on…)
[13:33] <sil2100> didrocks, kenvandine: oh, is there a MR for the runtime package rename already?
[13:34] <kenvandine> for the qml package
[13:34] <kenvandine> i am tweaking it one more time now
[13:34] <kenvandine> https://code.launchpad.net/~ken-vandine/libhud-qt/versioned/+merge/160363
[13:34] <kenvandine> sil2100, ^^
[13:35] <sil2100> kenvandine: thanks!
[13:35] <kenvandine> didrocks, it doesn't work with a dash in that dir name... grrr
[13:36] <kenvandine> oh... i didn't want that either
[13:36] <didrocks> kenvandine: ahah, lost in the discussion? :)
[13:36] <didrocks> kenvandine: no dash in the dir, no -plugin in the package name! :-)
[13:36] <didrocks> (but a beer, please! ;))
[13:38] <kenvandine> ok, HUD1.0 doesn't work either
[13:39] <kenvandine> i wish i understood why...
[13:39] <didrocks> HUD.1.0? :/
[13:39] <kenvandine> trying that now :)
[13:40] <kenvandine> ok, that works ;)
[13:41] <kenvandine> actually i do need a R/B/C for libhud-qt -> libhud-qt1 transition
[13:41] <kenvandine> that does conflict in the ppa
[13:42] <didrocks> ok ;)
[13:45] <kenvandine> i do feel much better knowing we can version these qml packages
[13:45] <kenvandine> that's been stressing me out!
[13:46] <rickspencer3> hey guys
[13:46] <kenvandine> hey rickspencer3
[13:46] <rickspencer3> seb128, so, one of my computers isn't loading x this morning :/
[13:47] <rickspencer3> I seem to recall that there was something about telling plymouth to sleep or something to work around something racey
[13:47] <rickspencer3> sound familiar at all
[13:47] <rickspencer3> ?
[13:47] <mlankhorst> rickspencer3: just enable -proposed
[13:47] <mlankhorst> and steal the lightdm upload
[13:48] <Laney> what lightdm upload in proposed?
[13:48] <mlankhorst> https://launchpad.net/ubuntu/raring/+queue?queue_state=1
[13:48] <Laney> that's a queue, and it's plymouth only
[13:49] <didrocks> kenvandine: yeah, nice work! :)
[13:49] <Laney> (tjaalton asked for lightdm to be rejected earlier)
[13:49] <mlankhorst> ah
[13:49] <Laney> and advising people to enable proposed isn't really good
[13:49] <rickspencer3> Laney, I suppose he wanted me to test it
[13:50] <mlankhorst> well I guess it depends, i dont know what is needed atm, tjaalton might :-)
[13:50] <rickspencer3> mlankhorst, wasn't there some way that I could add a sleep to plymouth to work around it?
[13:50] <kenvandine> didrocks, thanks, i pushed my changes
[13:50] <kenvandine> can you give it a review?
[13:50] <mlankhorst> if you want the hack, just add sleep to lightdm.conf before the exec
[13:50] <mlankhorst> sleep 3 or so
[13:50] <didrocks> kenvandine: sure, doing
[13:50] <kenvandine> sil2100, the new package is qtdeclarative5-hud1.0
[13:51] <rickspencer3> mlankhorst, can you tell me more specifically where that file is?
[13:51] <mlankhorst>  /etc/init/lightdm.conf
[13:51] <mlankhorst> upstart job
[13:52] <rickspencer3> mlankhorst, it already says "sleep 5" in the post-start script
[13:52] <sil2100> kenvandine: ACK, see it - will prepare branches
[13:54] <didrocks> kenvandine: approved
[13:54] <kenvandine> sil2100, thanks
[13:54] <kenvandine> didrocks, thx
[13:54] <didrocks> sil2100: merge that with the porting branches if possible
[13:54] <mlankhorst> meh just post the xorg.0.log then
[13:54] <Laney> mlankhorst: rickspencer3: Not the main script?
[13:54] <Laney> post-start will run too late IIUC?
[13:54] <rickspencer3> Laney, I have no idea
[13:54] <kenvandine> we should do this with the other qtdeclarative5-*-plugin packages too
[13:54] <kenvandine> but i guess we can do that as they have api changes
[13:54] <Laney> try adding it just before 'exec lightdm'
[13:54] <mlankhorst> I didn't know lightdm had a post-start script though
[13:55] <Laney> yeah it runs clear /dev/tty7
[13:55] <Laney> with >
[13:55] <didrocks> kenvandine: agreed
[13:55] <sil2100> didrocks: those got already approved - I'll prepare additional merges, since it's a change that anyway is separate
[13:55] <rickspencer3> Laney in /etc/init/lightdm.conf ?
[13:55] <Laney> yeah
[13:56] <Laney> that'd be line 46 here
[13:56] <sil2100> didrocks: as pure packaging changes
[13:56] <didrocks> sil2100: ah, good then!
[13:56] <rickspencer3> Laney, and how long should I tell it to sleep for?
[13:56] <didrocks> sil2100: and then, changing cupstream2distro-config
[13:56] <didrocks> sil2100: for autopilot
[13:56] <sil2100> Yep :)
[13:56] <Laney> not sure - I'm not familiar with the bug - mlankhorst advised 3 earlier
[13:57] <rickspencer3> ok
[13:57] <rickspencer3> trying :)
[13:57] <Laney> I see bryce said 10 on bug #982889 though :P
[13:57] <ubot2> Launchpad bug 982889 in plymouth (Ubuntu Raring) "X trying to start before plymouth has finished using the drm driver" [Critical,In progress] https://launchpad.net/bugs/982889
[13:58] <mlankhorst> it's just a race with both running concurrently
[13:58] <rickspencer3> ok, 3 didn't work, trying 10
[13:58] <mlankhorst> just post the xorg log really, easy to determine if you're hit by that bug or not
[13:59] <rickspencer3> mlankhorst, sadly I am pinned down in calls starting in 1 minute
[13:59] <rickspencer3> but the sleep 10 didn't work :/
[13:59] <rickspencer3> maybe bryce can take a look in 4 hours
[14:00] <rickspencer3> mlankhorst, where's the log?
[14:00] <rickspencer3> I guess I can ftp it off of this machine in the meantime
[14:00] <mlankhorst>  /var/log/Xorg*.log, just grab the one with most recent timestamp
[14:04] <tjaalton> mlankhorst, rickspencer3: I've uploaded the fixed versions to ubuntu-x/x-staging, forgot to reupload lightdm to -proposed
[14:43] <tjaalton> ppa:ubuntu-x-swat/x-staging that is..
[14:45] <seb128> rickspencer3, hey, sorry I was out for some exercice, I see that tjaalton and mlankhorst helped you
[14:46] <rickspencer3> hi seb128 well, mlankhorst took a look at me Xorg.0.log and didn't see any errors :/
[14:46] <rickspencer3> and the sleep work around didn't work, so I don't think I am having the same issue
[14:50] <seb128> rickspencer3, is the issue persistant across reboots?
[14:50] <rickspencer3> seb128, indeed
[14:50] <seb128> rickspencer3, do you know what you updated since the previous reboot?
[14:50] <ogra_> "the sleep workaround" ? like go to bed, get up and have seb128 fixed it ?
[14:50] <mlankhorst> rickspencer3: xsession seems to be failing for some reason
[14:50] <mlankhorst> try .xsession-errors
[14:50] <rickspencer3> seb128, I did a dist-upgrade yesterday
[14:50] <seb128> rickspencer3, and when did you dist-upgrade/successfully reboot before that?
[14:51] <rickspencer3> seb128, yeah, so I booted my computer yesterday morning and did a dist-upgrade
[14:51] <rickspencer3> I don't recall if I rebooted right after that
[14:51] <seb128> rickspencer3, can you pastebin ~/.xsession-errors?
[15:03] <rickspencer3_> seb128, uh
[15:03] <rickspencer3_> I feel like a real dope
[15:03] <rickspencer3_> thanks for your help
[15:04] <Laney> go on ...
[15:04] <rickspencer3_> Laney, I installed a ppa that uninstalled unity last night
[15:04]  * rickspencer3_ self dope-slaps
[15:04] <Laney> ha
[15:05] <ogra_> heh
[15:05] <Laney> it's always distracting when you get the same symptoms as a high profile bug
[15:05] <seb128> rickspencer3_, yw, did it accept to reinstall ubuntu-desktop?
[15:05] <rickspencer3_> seb128, yeah, it listed a bunch of unity components
[15:05] <seb128> great
[15:05] <seb128> rickspencer3_, let we know if reboot works out after that
[15:06] <rickspencer3_> I said Y, and after I rebooted it work
[15:06] <Laney> did you use apt-get?
[15:06] <rickspencer3_> Laney, yes
[15:06] <Laney> to install the PPA originally
[15:06] <rickspencer3_> yes
[15:06] <mlankhorst> well that was the only option :-)
[15:06] <Laney> yeah ...
[15:06] <rickspencer3_> no
[15:06] <rickspencer3_> no I did not
[15:06] <Laney> ah
[15:06] <rickspencer3_> I downloaded the deb and used software center
[15:06] <mlankhorst> if xserver shuts down succesfully it's a session error ;P
[15:06] <Laney> I was going to resurrect an old suggestion to make apt list removed packages last
[15:06] <Laney> i.e. where you can see them
[15:06] <Laney> don't know how s-c presented it
[15:08] <seb128> Laney, the log shows "removing indicator-* unity unity-greeter ubuntu-desktop..."
[15:08] <seb128> in .xsession-errors
[15:08] <seb128> I wonder if s-c did it
[15:08] <seb128> in which case that seems pretty buggy from it
[15:08] <Laney> in xsession-errors?!
[15:08] <seb128> yes
[15:08] <seb128> I wonder if that's s-c through aptd
[15:08]  * seb128 tests in a vm
[15:09] <Laney> mmm
[15:11] <Laney> I get message "Conflicts with the installed package 'gedit'" and it refuses to let me install it
[15:11] <Laney> on raring that is
[15:29] <seb128> Sweetshark, qengho, didrocks, Laney, kenvandine, mlankhorst, cyphermox, mterry, robru, tkamppeter, attente, desrt: hey, it's meeting time
[15:29] <seb128> https://wiki.ubuntu.com/DesktopTeam/Meeting/2013-04-23
[15:29] <didrocks> hey!
[15:29] <Laney> the best time!
[15:29] <cyphermox> yo!
[15:30] <seb128> happy raring release week ;-)
[15:30] <kenvandine> :-D
[15:30] <seb128> reminder: clean your workitems, raring cycle is over
[15:30] <seb128> there are still some stuff there that should be postponed or closed or moved to a new spec for next cycle
[15:31] <seb128> on that note, let's get started
[15:31] <seb128> Sweetsha1k, hey
[15:31] <mlankhorst> ohai
[15:32] <seb128> no Sweetsha1k?
[15:32] <seb128> qengho, hey
[15:33] <mterry> heh
[15:33] <seb128> hum, no qengho either?
[15:33] <Laney> slackers!
[15:33] <seb128> luckily the next one is a safe bet!
[15:33] <seb128> didrocks, hey ;-)
[15:33] <didrocks> (I'm not there)
[15:34] <didrocks> :p
[15:34] <didrocks> ok:
[15:34] <seb128> (tsss)
[15:34] <didrocks> * define procedure to continue diverging branches on daily release
[15:34] <didrocks> * some small fixes on cupstream2distro
[15:34] <didrocks> * continue investigating some autopilot issues
[15:34] <didrocks> * working on the touch stack by reviewing/coordinating work and helping newcomers to check the procedure
[15:34] <didrocks> * planning some discussions for next week sprint
[15:34] <didrocks> ..
[15:34] <seb128> didrocks, thanks
[15:34] <tkamppeter> hi
[15:34] <seb128> Laney, hey
[15:34] <Laney> /quit
[15:35] <Laney> oops!
[15:35] <Laney> • Much more release work - reviewing/accepting/rejecting/discussing fixes. Thanks everyone for the hard work!
[15:35] <Laney> • Spent quite a bit of time finishing lightdm/indicator-session/indicator-datetime logind ports. Should be done now - all MPs proposed and reviews welcome.
[15:35] <Laney> • Some GNOME updates in Debian for us to sync next cycle.
[15:35] <Laney> • Community: some behind the scenes DMB discussions. ;-)
[15:35] <Laney> °
[15:36] <seb128> Laney, DMB ... do they start liking Sweetsha1k? ;-)
[15:36] <Laney> that's part of it
[15:36] <seb128> great
[15:36] <qengho> Dang!  I wasn't ready.
[15:36] <seb128> though I start liking him less since he doesn't show up at our team meetings :p
[15:36] <kenvandine> hehe
[15:37] <seb128> Laney, thanks, good work on release and logind, I hope we can get logind in landing state next week ;-)
[15:37] <Laney> yeah that'll be a fun sprint thing to do
[15:37] <seb128> qengho, hey, glad you are joining us ... ready now?
[15:37] <qengho> * Tested new Cr release and threw it over the wall to #security.
[15:37] <qengho> * Now updating libv8 packaging so we can own it and use it in Cr and elsewhere.
[15:37] <qengho> EOF
[15:37] <seb128> qengho, or should we come back to you at the end? ;-)
[15:38] <seb128> qengho, thanks
[15:38] <seb128> kenvandine, hey
[15:38] <kenvandine>  * Added API versioning to libhud QML bindings, we should use this practice for all QML binding packages going forward
[15:38] <kenvandine>  * Ported share-app to use new HUD API
[15:38] <kenvandine>  * Added uoa-create script to the daily touch images so users have a way to add online accounts until we have a proper settings interface for it
[15:38] <kenvandine>  * More work on signon-ui
[15:38] <kenvandine>  /EOF
[15:38] <seb128> kenvandine, thanks
[15:38] <seb128> mlankhorst, hey
[15:39] <mlankhorst> sru verification for libdrm, readying lts-raring backport stack in ppa (now ready to be uploaded to -proposed), mesa 9.1 testing, touch bug testing
[15:39]  * qengho blames full-screen terminal windows for his delay.
[15:39] <mlankhorst> and no tkamppeter, we fixed the crash but the touch bug is still open :P
[15:39] <Laney> lts-raring is backporting raring x stack to precise?
[15:39] <mlankhorst> yeah
[15:39]  * Laney nods
[15:40] <Laney> are you doing the same kind of renaming?
[15:40] <mlankhorst> for raring yes
[15:40] <mlankhorst> if we move to rolling, perhaps not
[15:41] <seb128> mlankhorst, thanks
[15:41] <seb128> cyphermox, hey
[15:41] <cyphermox> hey!
[15:41] <cyphermox> I'm tempted to just log off now :)
[15:42] <cyphermox> - Finished adding hud2.0 / libhud-qt to daily-release
[15:42] <cyphermox> - Some last minute releases of indicators/themes/oif landed.
[15:42] <cyphermox>   - With some smaller bamf changes left for SRU.
[15:42] <cyphermox> - Added qmenumodel (needs to be deployed) to the daily-release stuff for touch
[15:42] <cyphermox> - Adding indicators-client and indicator-network.
[15:42] <cyphermox> - Tested qmenumodel and indicators-client/indicator-network on Nexus 4
[15:42] <cyphermox> - Some draft planning for stuff that needs to happen for touch; re: bluetooth and wifi.
[15:42] <cyphermox> - Coordinating SRU updates in NM/nm-applet.
[15:42] <cyphermox> - Going to review Laney's merges for indicators.
[15:42] <cyphermox> \x00
[15:42] <Laney> you BEAUTY!
[15:42] <cyphermox> hahah
[15:43] <cyphermox> I meant to do it yesterday, and forgot to get back to it
[15:43] <seb128> cyphermox, waouh, lot of great work there (hud2 daily release, qmenumodel, bluetooth)
[15:43] <seb128> cyphermox, thanks
[15:44] <seb128> mterry, hey
[15:44] <mterry> here
[15:44] <mterry> hold on
[15:44] <seb128> mterry, want to go next?
[15:44] <mterry> - More work on LightDM support in the phablet greeter -- mostly fixing continuous merge conflicts from pace of trunk  :)
[15:44] <mterry> - Planning work for out-of-box-experience for the phablet images, like setting up user info plus future greeter work
[15:44] <mterry> - Helped get automerging working for various phablet packages
[15:44] <mterry> - Patch piloting, mostly SRUs
[15:44] <mterry> - Surviving Boston manhunt
[15:44] <mterry> - Housing desrt during his g* sprint
[15:45] <mterry> EOF
[15:45] <mterry> sorry, had some copy paste problems  :)
[15:45] <seb128> no worry ;-)
[15:46] <seb128> mterry, did you visit the g* sprint or just hosted desrt?
[15:46] <mterry> seb128, didn't visit yet
[15:46] <seb128> k
[15:46] <mterry> seb128, pretty low-level stuff
[15:46] <seb128> mterry, I'm glad you are safe, I hope everybody you know made it out of the Boston crazyness safely
[15:46] <seb128> mterry, thanks
[15:46] <mterry> yeah
[15:47] <seb128> robru, hey, up or too early for you?
[15:47] <robru> hey
[15:47] <robru> * Release unity-firefox-extension 2.4.7bzr13.04.15-0ubuntu1
[15:47] <robru> * Fix a bug preventing community-contributed Sohu network support from working.
[15:47] <robru> * Stopped the horrible notification spam on first run of Friends.
[15:47] <robru> * Improved efficiency of retweeting, removed superfluous HTTP request.
[15:47] <robru> * Started sphinx boilerplate in order to be able to publish nice documentation.
[15:47] <robru> * Stopped raising uncaught exceptions in the MainThread, fixing #3 error on errors.ubuntu.com
[15:47] <robru> * Finally fixed camera-app packaging, including hud1 port and getting autopilot tests passing locally.
[15:47] <robru> ^D
[15:47] <seb128> robru, thanks
[15:47] <seb128> tkamppeter, hey
[15:48] <tkamppeter>  - More testing for the mouse-button-stuck-down bug 1068994 on the Lenovo Thinkpad Twist, getting a partial success. Left click works reliably, right click (via onboard) still broken.
[15:48] <tkamppeter>  - Last check through the printing bugs before Final Freeze, nothing urgent or with enough info from the user to fix it.
[15:48] <tkamppeter>  - CUPS crash SRU for Quantal committed, bug 1086019.
[15:48] <ubot2> Launchpad bug 1068994 in OEM Priority Project raring "button1 gets stuck after a while" [High,In progress] https://launchpad.net/bugs/1068994
[15:48] <ubot2> Launchpad bug 1086019 in cups (Ubuntu Quantal) "cupsd crashes regularly (daily)" [High,In progress] https://launchpad.net/bugs/1086019
[15:49] <seb128> tkamppeter, thanks
[15:49] <seb128> attente, hey
[15:49] <attente> seb128, hi
[15:50] <attente> GIcon debugging, proposed for merging some changes to libindicator to use desrt's and larsu's new GIcon stuff
[15:50] <attente> did the g-c-c text entry panel re-design, incorporating some ibus settings
[15:50] <attente> EOF
[15:50] <seb128> great
[15:50] <seb128> get ready for next week, so you can show us that, and we also need to land the menu work this time, start of a cycle
[15:50] <seb128> ;-)
[15:51] <seb128> attente, thanks
[15:51] <attente> yes, thanks seb128 :)
[15:51] <seb128> desrt, hey, around or sprinting?
[15:52] <seb128> sprinting I guess
[15:52] <seb128> Sweetsha1k, still not around?
[15:53] <seb128> ok, did I forget anyone this week?
[15:53] <seb128> otherwise, me:
[15:53] <seb128> * Updated translations, in the desktop packages that don't use langpacks, for raring
[15:53] <seb128> * Raring testing and bugs fixing
[15:53] <seb128> * Investigated some of the most frequent raring issues on errors.ubuntu.com
[15:53] <seb128> * started looking at next cycle
[15:53] <seb128> * lot of small things, but mostly looked through some issues and bugs backlog
[15:53] <seb128>  
[15:54] <seb128> does anyone has other topics or questions?
[15:56] <seb128> seems not
[15:56] <seb128> thanks everyone
[15:56] <Laney> thanks!
[15:56] <seb128> oh, for the record I just registered https://blueprints.launchpad.net/ubuntu/+spec/desktop-gnome-3-8
[15:56] <seb128> Laney, pitti: ^
[15:56] <seb128> jbicha, ^
[15:56] <Laney> ah, rocking
[15:56] <seb128> that's to list known issue and organize work around GNOME 3.8
[15:56] <Laney> ricotz: ^
[15:57] <pitti> seb128: thanks, sub'ing
[15:57] <pitti> seb128: we'll get logind next week, so at least that blocker should soon be gone
[15:58] <seb128> pitti, yep, that's great
[15:58] <Laney> ah so we'll have to do what shell did in unity
[15:58] <didrocks> thanks ;)
[15:58] <seb128> Laney, or revert some commits for unity sessions
[15:59] <tkamppeter> Does the S series have a name and a release schedule page? Or will it get definitively rolling?
[15:59] <seb128> tkamppeter, https://wiki.ubuntu.com/SReleaseSchedule
[15:59] <seb128> no name yet
[16:00] <Laney> No, yes, no rolling
[16:00] <Laney> https://wiki.ubuntu.com/SReleaseSchedule
[16:02] <jbicha> seb128: thanks I'll add a bunch of notes, I'm thinking that I won't be around for the May UDS though
[16:02] <tkamppeter> Has the idea of rolling definitively died? Will we continue witb the usual releases and run out of letters in a few years?
[16:04] <Laney> tkamppeter: https://lists.ubuntu.com/archives/technical-board/2013-March/001566.html is what got discussed / approved
[16:06] <ogra_> and we will then just switch to greek or other cyrillic languages once the alphabet is through
[16:07] <tkamppeter> Laney, seb128, thanks.
[16:08] <seb128> jbicha, ok, thanks
[16:09] <seb128> Laney, pitti, jbicha: if you update the whiteboard please refresh before editing, blueprints don't handle edit conflicts well, and it's likely that this blueprint will get quite some edits in the next days
[16:09] <ricotz> seb128, nice, might be useful to mention the 3.10 bits there too which will probably land in S -- like glib, g-i, ...
[16:10] <seb128> ricotz, we didn't decide to land any 3.10 bits yet, I will add a note about that to the whiteboard
[16:10] <ricotz> seb128, alright
[16:21] <seb128> Laney, the bug from rick earlier, he seems to have a amd64 installed and tried to install an i386 deb
[16:22] <seb128> Laney, if you have an amd64 install and feel adventurous, wget https://launchpad.net/~stebbins/+archive/handbrake-releases/+build/3931765/+files/handbrake-gtk_0.9.8%2Bppa1%7Equantal1_i386.deb and try to install it with s-c
[16:22] <seb128> Laney, I tried to boot an amd64 iso but my 32bit kernel doesn't allow me to do that :p
[16:28] <davmor2> seb128: the error I get there is handbrake is depending on libwebkitgtk-1.0-0
[16:29] <seb128> davmor2, but nothing is uninstalling unity etc?
[16:29] <seb128> if you do sudo apt-get -f install things are fine?
[16:29] <Laney> seb128: ah yeah I made it do it
[16:29] <seb128> Laney, "do it"?
[16:29] <Laney> I used equivs to make an i386 package which depends on unity
[16:29] <Laney> and then installed that with s-c
[16:30] <Laney> it did error out but not until it had removed half of the system
[16:30] <seb128> ah
[16:30] <seb128> so you confirm the bug?
[16:30] <davmor2> seb128: nope I haven't done sudo apt-get -f that might remove unity as it will pull in libwebkitgtk-1.0-0:i386
[16:30] <seb128> right
[16:30] <seb128> that's what happened to rick
[16:30] <seb128> it seems like s-c should rather refuse to install the deb
[16:30] <seb128> than doing it at the cost of removing your desktop
[16:31] <davmor2> seb128: it can't because some are multiarched debs which work fine
[16:31] <seb128> can't what?
[16:33] <davmor2> seb128: there are lots of i386 apps that are multiarched so install on 64bit with no issues.  So it can't arbitrarily say no you are on amd64 so you can't install any i386 apps
[16:33] <seb128> well, I never said it should
[16:33] <seb128> I said it should say "that package conflicts with your desktop and require to uninstall half your system, can't do that"
[16:34] <seb128> if users really want to screw their system they can use the command line ;-)
[16:34] <davmor2> seb128: It does kinda
[16:34] <Laney> it can test if a package is installable
[16:34] <seb128> davmor2, hum, Laney said he had unity and stuff removed through s-c
[16:34] <seb128> or I misread?
[16:35] <davmor2> seb128: yeap but that was because of his system setup, mine is on a clean system
[16:35] <Laney> you sure?
[16:35] <Laney> let me upload the deb
[16:35] <seb128> that seems weird
[16:35] <seb128> your system being cleaned or not, s-c should never uninstall unity to install a random deb
[16:36] <seb128> e.g it shouldn't be that easy to break your system
[16:36] <Laney> http://people.canonical.com/~laney/fakepkg_1.0_i386.deb
[16:36] <Laney> try and install that with software-center on an amd64 system with multiarch i386
[16:37] <davmor2> seb128: this is the error I got http://paste.ubuntu.com/5595981/ so I would go to terminal and do apt-get install missing_dep:1386 and see what it did
[16:37] <Laney> The following packages have unmet dependencies. fakepkg:i386 : Depends: unity:i386 but it is not going to be installed
[16:37] <Laney> ^ apt-get install --dry-run fakepkg:i386
[16:38] <Laney> so you can test if it's installable before trying
[16:38] <seb128> hum, I'm a bit confused
[16:39] <davmor2> seb128: http://ubuntuone.com/1OeshOa0tUkGWGa8JXaEDG
[16:39] <seb128> Laney, if you can confirm a problem with s-c can you file a bug with the description of the steps you followed and what was the result?
[16:39] <Laney> I am doing already
[16:39] <seb128> davmor2, dpkg -l unity ?
[16:41] <mhr3> seb128, and once more about the dbus thing, perhaps it should mentioned in release notes, i think it'll end up affecting quite a lot of people
[16:41] <davmor2> seb128: http://paste.ubuntu.com/5596003/ ouch!
[16:41] <seb128> mhr3, well, it's only you and me so far
[16:41] <seb128> davmor2, so you do confirm the bug...
[16:41] <mhr3> seb128, unity AP tests beg to differ
[16:42] <seb128> mhr3, do we have any idea at what level the issue is?
[16:42] <seb128> dbus server?
[16:42] <seb128> glib?
[16:42] <davmor2> seb128: looks that way
[16:42] <seb128> davmor2, ok, but you said you didn't, that's quite confusing
[16:42] <seb128> but anyway, it seems it' confirmed
[16:42] <mhr3> seb128, i wish i knew
[16:43] <mhr3> but it's probably glib
[16:43] <mhr3> cause it's usually isolated to individual apps
[16:43] <seb128> right
[16:43] <seb128> when I see it, it's usually through gvfs
[16:44] <mhr3> hmm, yea, could be related to gvfs too
[16:44] <seb128> did you see it on non gvfs calls?
[16:44] <seb128> what do you see hanging when it happens?
[16:44] <mhr3> when it happens the app stops talking dbus completely
[16:44] <seb128> I wish I had kept a stacktrace, but last time I had the issue I had firefox which kept hanging and xchat
[16:45] <mhr3> in unity we always use async dbus, so it doesn't lock it up completely
[16:45] <seb128> they both blocked in sync dbus call
[16:45] <mhr3> but still no dbus
[16:45] <seb128> firefox in fact was unity-webapps
[16:45] <mhr3> seb128, well those do gdbus too
[16:46] <mhr3> although probably not gvfs
[16:47] <seb128> mhr3, we updated dbus from 1.6.4 to 1.6.8 this cycle, and we both updated glib and gvfs
[16:48] <seb128> mhr3, if the AP manage to trigger the issue often, is there any chance you could downgrade gvfs on the box and see if it keeps happening, to isolate it out?
[16:48] <seb128> mhr3, I'm not sure how to debug those issues :/
[16:49] <mhr3> seb128, any of those updates happened around the beggining of april?
[16:49] <davmor2> seb128: so I guess the issue is 3 fold, 1 the packaging doesn't make for a multiarch app, 2 apt-get -y will have the same issue so apt should trigger some error, 3 usc should ensure that it obeys apt's error report and not offer to install the app
[16:49] <mhr3> seb128, that seems to be when it started happening
[16:49] <seb128> mhr3, what is also weird is that when it starts happening it doesn't resolve itself by restarting the app, it should if the bug was in the glib/gvfs client code no?
[16:49] <seb128> glib/gdbus I mean
[16:49] <mhr3> seb128, it doesn't?
[16:50] <seb128> mhr3, I can kill firefox/unity-webapps and restart it, they keep hanging
[16:50] <mhr3> seb128, i didn't actually see it in a normal app, and when it happens in unity the only thing to do is logout really
[16:50] <seb128> mhr3, does it block for ever for you?
[16:50] <seb128> here things block for 15 seconds or so
[16:51] <seb128> I guess that's the timeout of the calls
[16:51] <Laney> seb128: bug #1171931
[16:51] <ubot2> Launchpad bug 1171931 in software-center (Ubuntu) "Installing multiarch debs can uninstall native arch packages" [Undecided,New] https://launchpad.net/bugs/1171931
[16:51] <mhr3> nope, as i said, we do async calls
[16:51] <seb128> Laney, thanks
[16:51] <seb128> mhr3, I wish I could reproduce that bug, I don't get it often
[16:52] <seb128> mhr3, I had it yesterday and I did some unity hacking and started the standalone dash a few times, and got some unity segfault during the day
[16:52] <seb128> dunno if that had to do with it
[16:52] <mhr3> seb128, i'm misusing our testing computer today and running the ap tests there the whole day, it didn't happen yet :/
[16:52] <seb128> :-(
[16:52] <seb128> mhr3, any debug hint for next time I run inot it?
[16:52] <mhr3> seb128, attach gdb and get a stacktrace
[16:53] <mhr3> for all threads
[16:53] <mhr3> it's likely that one of them will be stuck on some lock
[16:53] <seb128> well, last time I did that they were all ending in dbus sync calls
[16:53] <seb128> coming from gvfs
[16:53] <seb128> through gio calls
[16:53] <seb128> like "open that url"
[16:54] <seb128> or in unity the launcher doing usb key mounting
[16:54] <mhr3> seb128, i don't suppose you still have the trace somewhere?>
[16:54] <seb128> no :(
[16:54] <seb128> mhr3, btw, https://bugs.launchpad.net/bugs/1108056 is a bit similar
[16:54] <ubot2> Launchpad bug 1108056 in glib2.0 (Ubuntu) "fetching URLs freezes pidgin" [Undecided,Confirmed]
[16:55] <seb128> mhr3, having to do with SIGCHLD when gsettings calls exit
[16:55] <mhr3> hm, it should be pretty widespread
[16:55] <seb128> which seems an issue to be new from this cycle's glib
[16:56] <seb128> well, it was in pidgin
[16:56] <seb128> see the number of comments on the launchpad bug
[16:57] <seb128> mhr3, see https://developer.pidgin.im/ticket/15493#comment:25 as well
[16:58] <seb128> I wonder if that's desrt's fault again :p
[16:58] <seb128> desrt, ^ when you are around, please read this comment and the next one, that seems to have started with glib 2.35 for some reasons
[17:01] <seb128> rickspencer3, btw, in case you didn't follow, we confirmed that the deb from that ppa leads to have unity uninstalled, Laney opened https://launchpad.net/bugs/1171931 about it
[17:01] <ubot2> Launchpad bug 1171931 in software-center (Ubuntu) "Installing multiarch debs can uninstall native arch packages" [Undecided,New]
[17:01] <rickspencer3> thanks seb128
[17:01] <rickspencer3> and Laney
[17:01] <Laney> np
[17:01] <rickspencer3> I wasn't following
[17:01] <rickspencer3> you guys are so awesome
[17:01] <Laney> just have to strongarm someone into fixing it now ;)
[17:01] <rickspencer3> and thanks for not making fun of me ;)
[17:01] <mhr3> seb128, hmm, it's probably a different issue
[17:02] <seb128> mhr3, could be, I'm just wondering if they lead to a same glib underlining problem maybe
[17:02] <seb128> mhr3, like something with signals
[17:03] <seb128> mhr3, the pidgin issue seems also easier to reproduce so it could be an easier testcase to figure out what changed in glib that this bug started
[17:04]  * didrocks waves good evening
[17:04] <seb128> rickspencer3, btw, part of the issue is also because you tried to install the i386 deb from that ppa on your amd64 system, where there is an amd64 build
[17:04] <rickspencer3> d'oh
[17:04] <rickspencer3> I have 3 machines
[17:04] <mhr3> seb128, hard to say really, but yea, we'd need a way to reliably reproduce it
[17:04] <rickspencer3> and I forgot which one is 32 bit
[17:04] <rickspencer3> lol
[17:04] <rickspencer3> what a dope
[17:07] <davmor2> rickspencer3: name them like this Raring32 Raging64 that way you don't forget :)   that's how I started naming my non main machines :)
[17:08] <rickspencer3> good idea davmor2
[17:08] <desrt> seb128: if it's about pidgin hanging, it's colin's fault :)
[17:09] <jbicha> pitti: darkxst has added the logind packages to the gnome3-staging ppa so it should be getting a little more testing there
[17:09] <desrt> seb128: he's in the room with me now
[17:09] <desrt> and he says "wellllll... i _still_ think it's their fault"
[17:09] <seb128> desrt, do you know what's the issue?
[17:09] <desrt> yes
[17:09] <desrt> well, no
[17:09] <seb128> desrt, is that likely to affect other programs?
[17:09] <desrt> but i know which patch i can revert to fix it for sure
[17:09] <desrt> wanna try an upload?
[17:10] <pitti> jbicha: ah, good to know; I've been running logind+CK in parallel for the past few weeks, and before that exclusively logind, so I think it's not too broken
[17:10] <seb128> desrt, well, we got a pidgin uploaded that fixes it, so I'm not sure what to test on
[17:10] <pitti> jbicha: I didn't notice the "doesn't suspend on lid close", as in raring that's still done via g-s-d and upower
[17:10] <desrt> seb128: workaround or fix?
[17:10] <seb128> desrt, the discussion started because of the dbus issue mhr3 mentioned yesterday
[17:10] <pitti> jbicha: so please keep filing bugs about issues like that
[17:11] <seb128> desrt, https://hg.pidgin.im/pidgin/main/rev/161320946afd
[17:11] <desrt> seb128: https://git.gnome.org/browse/glib/commit/?id=ce0022933c255313e010b27f977f4ae02aad1e7e
[17:12] <seb128> desrt, I'm wondering if the "sometimes gvfs stops replying" that I see once a week could be due to it
[17:12] <seb128> desrt, I've stuff like xchat-gnome which hang in sync dbus calls when that happens, which go down to gvfs not responding it seems (happens for example when I click on an url and xchat tries to open it throughgio)
[17:13] <desrt> seb128: thanks for the link.  i now understand the problem perfectly
[17:13] <desrt> fighting with colin over if this is technically his fault or not :)
[17:13] <seb128> desrt, thanks for looking into it ;-)
[17:13] <seb128> desrt, let me know what's the outcome of the discussion
[17:13] <seb128> desrt, but I guess the dbus not replying is another issue :/
[17:13] <desrt> ya
[17:13] <desrt> i think this is unrelated
[17:14] <desrt> i'd love to see a backtrace
[17:14] <seb128> desrt, I was wondering if maybe they could have the same underlining cause
[17:14] <desrt> nah
[17:14] <seb128> will get one next time
[17:14] <desrt> all threads, plz :)
[17:14] <seb128> will do
[17:14] <seb128> or maybe I managed to get it next week and show you directly ;-)
[17:15] <mhr3> seb128, i can already how the machine where it happens will be sacred and you won't be allowed to restart nor do anything with it :)
[17:15] <mhr3> already see*
[17:15] <desrt> seb128: we're gonna revert the patch in glib
[17:16] <seb128> desrt, ok, I will backport the revert for my next upload, in case it affects other things than pidgin
[17:16] <desrt> seb128: it's not going to be a straight revert
[17:16] <seb128> mhr3, yeah, I better bring a spare laptop :/
[17:16] <desrt> but for you it's safe enough to do that
[17:16] <desrt> colin combined like 3 things into one patch
[17:16] <seb128> desrt, well, we are not going to change anything before release, so no hurry
[17:16] <desrt> and i want to keep 1 of the 3
[17:32] <desrt> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=698081#c14
[17:32] <ubot2> Gnome bug 698081 in mainloop "Pidgin hangs in g_spawn_command_line_sync" [Normal,Unconfirmed]
[17:33] <seb128> desrt, thanks
[20:32] <cyphermox> mterry: hey
[20:33] <cyphermox> wanna help with some quick reviews?
[20:37] <mterry> cyphermox, sure
[20:37] <cyphermox> mterry: https://code.launchpad.net/~mathieu-tl/qmenumodel/skip-powerpc/+merge/160489
[20:38] <cyphermox> https://code.launchpad.net/~mathieu-tl/indicators-client/skip-powerpc/+merge/160493
[20:43] <mterry> cyphermox, both done
[20:53] <cyphermox> mterry: thanks