=== cyphermox_ is now known as cyphermox
=== mhall119_ is now known as mhall119
[07:22] <ricotz> racarr, hi :)
[07:22] <ricotz> racarr, do you think you could make bamf's dependency on libunity-webapps optional?
[07:44] <jbicha> hey, we have an issue with yesterday's unity update
[07:44] <jbicha> because of the fix for bug 1055019, deja-dup, empathy, nautilus, & shotwell depend on libunity9 which depends on unity-common which depends on compiz-gnome
[07:44] <ubot5> Launchpad bug 1055019 in libunity (Ubuntu) "libunity9 should depend on unity-common" [Medium,Fix released] https://launchpad.net/bugs/1055019
[07:44] <jbicha> but the Ubuntu GNOME Remix doesn't ship compiz...
[08:08] <Mirv> jbicha: uh oh :( so you had already libunity9 installed, but now the deps bring compiz as well? that's indeed not pretty
[08:09] <sil2100> This is hm, indeed problematic
[08:14] <sil2100> I think the dependency to compiz-gnome is due to unity-common including the setting migration files
[08:15] <sil2100> seb128: hi!
[08:15] <seb128> sil2100, hey, how are you?
[08:16] <sil2100> seb128: rather fine, thanks, how about you?
[08:20] <seb128> sil2100, I'm good thanks
[08:23] <jbicha> I filed bug 1062099
[08:23] <ubot5> Launchpad bug 1062099 in libunity (Ubuntu) "libunity9 now depends on unity-common which depends on compiz" [Undecided,New] https://launchpad.net/bugs/1062099
[08:24] <jbicha> Mirv: I mean we'd prefer not to include libunity9 either but that's not possible (at least not this release)
[08:27] <seb128> jbicha, Mirv: I guess the easiest way out for this cycle is to revert the Depends and make the code bail out nicely when the schemas is missing
[08:31] <jbicha> unity-mail should check if the schema exists before trying to call it
[08:34] <seb128> it doesn't call it, it just uses libunity which uses a key from the schemas
[08:50] <mhr3> it should be fixed in libunity, it's a foreign schema, it should deal with it not being there
[08:51] <didrocks> sil2100: so, you did ping upstream? I think we should fix that quickly
[08:52]  * didrocks is concerned to not see things being act on here, apart from the great mhr3 always watching :)
[08:52] <didrocks> mhr3: I have a simple recipe to detect the schema, but I'm not confortable with the side effect of not setting a preference value
[08:52] <didrocks> mhr3: so I think you would be the best to do the change
[08:53] <didrocks> I think you know about the "list_schemas" hack?
[08:53] <mhr3> i'll have to fix tests as well anyway, they expect the schema is there too
[08:53] <didrocks> (I think we should really have an upstream glib call for it)
[08:53] <mhr3> +1
[08:53] <didrocks> I'm having this hack in 6 places already :/
[08:54] <mhr3> whose idea was it that crashing an app is better than using a GError? :P
[08:54] <mhr3> hmm desrt?
[08:54] <didrocks> yep :)
[08:54] <didrocks> and he's quite adamant for it
[08:57] <sil2100> didrocks: once mhr3 is ready with a fix, should we distro-patch it?
[08:57] <didrocks> yeah
[08:58] <didrocks> thanks mhr3 for noticing it yourself. I was excepting you would be warned by the integration team (and was waiting on that)
[08:59] <popey> didrocks, we were just discussing it before you arrived
[09:00] <didrocks> popey: since 10h10? :/
[09:01] <didrocks> and where the discussion was going on? should be on this channel, isn't it?
[09:01] <popey> it wasn't here no
[09:01] <didrocks> it should though
[09:01] <didrocks> and 50 minutes to discuss about pinging upstream seems to be quite serious…
[09:01] <popey> i was actually waiting for you to get off your hangout to ping you, but you saw it first
[09:02] <didrocks> popey: well, I saw it at 9:30
[09:02] <popey> great.
[09:02] <didrocks> then, I told jbicha to ping you guys here
[09:03] <didrocks> then first answer 24 minutes after the concern was raised, and no upstream ping in 50 minutes, I'm concern about the effectivness TBH
=== mmrazik is now known as mmrazik|lunch
[09:43] <mhr3> sil2100, didrocks, proposed the libunity branch
[09:44] <didrocks> sweet! we need someone testing it without having the schema installed (and so not compiled, removing the schema is not enough)
[09:45] <mhr3> fwiw i tried by just settings XDG_DATA_DIRS to something weird
[09:46] <didrocks> that should work, as long as the app using it doesn't have schema installed :)
[09:46] <mhr3> otoh didn't try to call any of the methods in that case
[09:47] <mhr3> but since all just lookups into empty hashtable they should just return false
[09:48] <didrocks> mhr3: maybe trying with empathy and other from the list above? ^
[09:48] <didrocks> nautilus is a good one
[09:48] <didrocks> IMHO
[09:51] <mhr3> didrocks, i don't think nautilus is one of those apps that can survive without any schemas :)
[09:51] <didrocks> yeah, that's why rm schema + recompiling them
[09:51] <didrocks> mhr3: who is reviewing your branch?
[09:51] <mhr3> didrocks, ehm, you? :)
[09:52] <didrocks> as the integration team will probably prepare the distro-patch, I think they will test it at the same time, so they should?
[09:53] <mhr3> sil2100, ^
[09:53] <didrocks> I must admit that it's more elegant that in C :)
[09:53] <didrocks> schema in Settings.list_schemas ();
[09:53] <didrocks> :)
[09:54] <mhr3> hmm... why didn't i do that?
[09:54] <mhr3> i guess i like extra variables :P
[09:55] <didrocks> seems so :)
[09:55] <didrocks> to show you know the "unowned" :p
[09:56] <mhr3> right, what if vala copied the array in that case? that would be horrible waste of cpu and memory :P
[09:57] <didrocks> heh
[09:57] <didrocks> mhr3: so vala copies everything by default?
[09:57] <mhr3> would surely waste at least 3nanoseconds
[09:57] <mhr3> not in that case :)
[09:58] <didrocks> yeah, but if it's not unowned?
[09:59] <jokerdino> hey, unity dash looks weirdish with no blur. is that a known bug?
[09:59] <mhr3> then yea, string[] arr = get_something_unowned(); will copy the array
[09:59] <sil2100> ugh, sorry, I was busy copy-pasting some bugs
[09:59] <didrocks> interesting
[09:59] <sil2100> Looking at the merge request
[09:59] <didrocks> mhr3: but string a = b;
[10:00] <mhr3> didrocks, that too
[10:00] <didrocks> and if I want to share the same ref? it needs to be unkowned on a?
[10:00] <mhr3> yep
[10:01] <didrocks> but then, you need b to go out of scope after a
[10:01] <mhr3> exactly
[10:01] <didrocks> there is no way to still have automatic freeing generation with b going out of scope before a? and they still share the same reference?
[10:01] <mhr3> so unowned needs to be used with care
[10:02] <mhr3> didrocks, well what would you do in that case?
[10:02] <didrocks> counting the number of reference :)
[10:02] <mhr3> the reference is invalid if b gets out of scope
[10:02] <didrocks> yeah, but there can be a "magic" keyword telling a = b target the same ref
[10:02] <mhr3> yea, of course for ref-counted objects Obj a = b; just increases the refcount
[10:02] <didrocks> ok, just not on basic types?
[10:03] <didrocks> as string a = b; triggers a copy
[10:03] <mhr3> string is always special :) int a = b also doesn't need references :)
[10:03] <didrocks> ok, it's only for the basic types :)
[10:03] <mhr3> and structs
[10:03] <didrocks> I was starting to think it was for everything
[10:04] <didrocks> hence my "getting scared" :)
[10:04] <mhr3> no worries, it's sane :)
[10:05] <didrocks> heh
[10:10] <sil2100> davidcalle: ping
=== mmrazik|lunch is now known as mmrazik
[10:29] <davmor2> popey: can you confirm a bug for me please.  from a fresh start on quantal flick through the dash lenses how many of the See more results arrows are pointing down instead of right? I'll go grab you the bug number
[10:30] <popey> sure
[10:32] <davmor2> popey: nevermind bug got duped so is already confirmed https://bugs.launchpad.net/unity/+bug/1053047
[10:32] <ubot5> Ubuntu bug 1053047 in unity (Ubuntu) "Dash - Category expander arrow is in expanded mode no metter if category is actually expanded." [Medium,In progress]
[10:32] <popey> FINE!
[10:32] <popey> :)
[10:33] <davmor2> popey: I was looking at mine rather than the dupe and wondering why it wasn't confirmed
[10:34] <davmor2> popey: I blame my cold
[10:34] <jokerdino> popey: have you found any bug with dash and no blur setting?
[10:35] <davmor2> popey: although gdocs is still desparate to download the spreadsheet I want to interact with as a pdf :D
[10:48] <popey> jokerdino, can you be more specific?
[10:55] <Mirv> wasn't there this "jumping" of background with no blur?
[10:56] <Mirv> I think it was mentioned, but I'm not sure if a bug was filed
[10:58] <dandrader> the launcher in my desktop only comes up if I press the super key. It no longer shows up when I push the pointer against the left screen edge. I'm in Quantal. How can I fix it?
[11:00] <popey> dandrader, nvidia?
[11:00] <dandrader> yes
[11:00] <popey> bug 1057000
[11:00] <ubot5> Launchpad bug 1057000 in xorg-server (Ubuntu) "[Ubuntu 12.04.1/12.10] nVidia drivers 304.51 prevent autohidden Unity launcher from revealing" [High,Triaged] https://launchpad.net/bugs/1057000
[11:00] <popey> probably
[11:01] <dandrader> popey,  hmm, ok. I'll have a look at it. Thanks!
[11:01] <popey> jokerdino, bug 1058391
[11:01] <ubot5> Launchpad bug 1058391 in unity (Ubuntu Quantal) "[no blur] Desktop rolls over unity panel vertically when i open the dash or hud" [High,Confirmed] https://launchpad.net/bugs/1058391
[11:01] <popey> Mirv, that one? ^
[11:04] <Mirv> popey: yes, that one
=== MacSlow is now known as MacSlow|lunch
[11:24] <jokerdino> sorry and thanks popey. i think that's the bug i was looking for
[11:26] <popey> np
=== dandrader is now known as dandrader|afk
[12:20] <didrocks> sil2100: Mirv: is libunity backported and tested now?
[12:28] <sil2100> didrocks: tested - yes, backported - no... but I'll do that in a moment, just need 5 more minutes
[12:30] <didrocks> tested without the schema installed, right?
[12:30] <didrocks> backporting then is just a 2 min manipulation…
=== dandrader|afk is now known as dandrader
[12:37] <sil2100> didrocks: I know, I should have done it ASAP once the testing was done, just picked up something else to do in the meantime ;(
=== MacSlow|lunch is now known as MacSlow
=== _salem is now known as salem_
[12:40] <didrocks> sil2100: didn't I say this one would be urgent and ask for working on it since this morning? :/
[12:41] <didrocks> TBH, I think there are some priotization issue on your team (one hour to start pinging upstream… 30 minutes to tell "oh it's vala, we should get someone else to review it" and right now, more than one hour and 20 minutes since it's merged upstream and still not backported)
[12:41] <didrocks> so it will soon be too late to push it for the week-end
[12:48] <sil2100> https://code.launchpad.net/~sil2100/libunity/ubuntu_6.8.0-2
[12:48] <sil2100> Packaging with the cherry-pick
[12:48] <sil2100> I removed the unity-common dep as well
[12:49] <Mirv> thanks sil2100, cherry-pick is the right way to go atm so that it's gotten in as soon as possible
[12:50] <didrocks> sil2100: thanks, looking
[12:51] <didrocks> sil2100: did you try your cherry-pick?
[12:53] <sil2100> didrocks: the cherry-pick I just posted was test-built, but its almost the same thing as what I tested basically
[12:54] <didrocks> sil2100: test-built but not tested, right?
[12:54] <sil2100> I can re-test it without the schemas now again
[12:54] <didrocks> well, you should
[12:54] <didrocks> because from what I can see it's wrong
[12:55] <didrocks> I'm sure mhr3 can find quickly what's wrong :)
[12:58] <didrocks> sil2100: still don't get it? I clearly showed the issue at the integration sprint with vala projects…
[13:01] <sil2100> didrocks: still looking, give me a moment more
[13:16] <Daviey> wait, didrocks.. you know the cause of a problem, and there is wasted effort in trying to duplicate the discovery ?
[13:17] <didrocks> Daviey: well, popey's teaùm
[13:17] <didrocks> Daviey: want to progress
[13:17] <Daviey> didrocks: and you know the answer, and haven't shared it?
[13:17] <didrocks> Daviey: the issue already happened 3 times in the past and I did showed it
[13:17] <Daviey> SO you are proving a point now?
[13:17] <didrocks> Daviey: so it's some kind of training for them to find it until they ask
[13:18] <didrocks> Daviey: hence his "give me a moment more"
[13:18] <tsdgeos> any idea how to unit test https://code.launchpad.net/~aacid/unity/do_not_reuse_menus_on_order_change/+merge/128243 ?
[13:18] <Daviey> This is a total waste of time didrocks
[13:18] <tsdgeos> Trevinho: ↑
[13:18] <seb128> Daviey, some people seem to not learn when you don't let them think by themself about the issue for a while
[13:19] <Daviey> seb128: Have they requested this sort of support?
[13:19] <Trevinho> tsdgeos: for the change in Indicator::GetEntry there are unit tests
[13:19] <seb128> Daviey, what "support"?
[13:19] <Trevinho> tsdgeos: just integrate them with your api change
[13:20] <tsdgeos> Trevinho: i'm more concerned about the dbus one
[13:20] <Daviey> seb128: exactly.
[13:21] <Trevinho> tsdgeos: there are still no tests for that...
[13:21] <Trevinho> tsdgeos: I started doing it some time ago, but it was too long and I didn't continue due to other priorities
[13:21] <Trevinho> tsdgeos: however, you can use Autopilot, or.... (much better) would be adding a new test suite to test-gtest-dbus
[13:21] <Trevinho> tsdgeos: basically you need to add a fake unity-panel-service there
[13:22] <Trevinho> and use DbusIndicators to connect to that
[13:22] <Trevinho> tsdgeos: at that point you can test everything you want
[13:22] <tsdgeos> ok, that's going to be a hard exercise :D
[13:23] <Trevinho> tsdgeos: however, imho instead of changing Entry::Ptr Indicator::GetEntry, imho it's better to add Indicato::EntryIndex method
[13:23] <Trevinho> tsdgeos: yeah :)
[13:23] <Trevinho> tsdgeos: more boring than hard
[13:23] <tsdgeos> Trevinho: well, never done any of that dbus stuff, so i need to do some c&p and be lucky ;-)
[13:24] <tsdgeos> Trevinho: well, the think is that i want both the entry and the index
[13:24] <tsdgeos> feels a bit silly doing the loop twice
[13:24] <Trevinho> tsdgeos: yeah, I know.. but it should not really impact a lot
[13:24] <tsdgeos> or you mean that EntryIndex should return both the entry and the index as my modified GetEntry ?
[13:24] <mhr3> didrocks, can i? i see it properly cherrypicked
[13:25] <didrocks> mhr3: vala man, vala when shipping c…
[13:25] <tsdgeos> Trevinho: ok, i'll add the new function
[13:25] <mhr3> didrocks, we changed the build system, no more .c files ;)
[13:25] <didrocks> mhr3: we still have them in the packaging dir
[13:25] <mhr3> didrocks, at least not in tarball
[13:25] <didrocks> mhr3: so until we remove them…
[13:25] <Trevinho> tsdgeos: or another clean way would be to set the index inside an entry since it looks like that you want an entry to only have a specific index
[13:25] <didrocks> (we should do that for R)
[13:26] <mhr3> didrocks, i actually think the build system should pick it up properly
[13:26] <didrocks> mhr3: was it tested?
[13:26] <didrocks> mhr3: I'm quite afraid by that
[13:26] <mhr3> but maybe i'm wrong, i don't see into the packaging build
[13:26] <tsdgeos> Trevinho: i can do what you prefer :-)
[13:26] <didrocks> sil2100: so, if the build system is covering this right now, I may be wrong, it just needs a double check
[13:27] <didrocks> sil2100: but remember what I told about .vala files trick -> when we have .c files, they are not always regenerated (because of vala ignoring timestamps)
[13:27] <mhr3> sil2100, if you have your pkg installed do `XDG_DATA_DIRS=/home python -c "from gi.repository import Unity; print Unity.LauncherFavorites.get_default();"
[13:28] <mhr3> sil2100, if it crashes it's bad :)
[13:29] <mhr3> if there are two warnings it's good
[13:29] <sil2100> mhr3: just get a warning
[13:29] <sil2100> mhr3: (process:28044): libunity-WARNING **: unity-launcher.vala:373: Schema "com.canonical.Unity.Launcher" is not installed!
[13:29] <didrocks> sil2100: ok, in that case, I'll take it
[13:30] <sil2100> mhr3: I just tried it on tests too, no crashes
[13:30] <didrocks> sil2100: I'll just downgrade it to Suggests, but that's a personal nitpick
[13:30] <sil2100> didrocks: ok, thanks
=== salem_ is now known as _salem
[13:33] <mhr3> didrocks, see how nice we made vala behave with debs now ;)
[13:33] <didrocks> mhr3: is that for every projects you did that?
[13:33] <mhr3> at least in libunity, still a problem everywhere else :P
[13:33] <didrocks> mhr3: so that I don't do sil2100 searching something for nothing :p
[13:34] <mhr3> sil2100, keep in mind ^
[13:35] <sil2100> .o>
=== _salem is now known as salem_
[13:36] <didrocks> mhr3: so lenses have this build system enhancement?
[13:36] <mhr3> <mhr3> at least in libunity, still a problem everywhere else :P
[13:36] <didrocks> ok, everywhere like everywhere :)
[13:37] <didrocks> sil2100: can you note that down? ^ something good to note for next cycle "converting vala lenses to not ship .c file" ^
[13:37] <mhr3> but ultimately it's a matter of getting .c away from tarballs
[13:37] <mhr3> patches for that welcome :)
[13:38] <mhr3> took me like a week to tune the build system in libunity to do that (and distcheck pass) :P
[13:38] <didrocks> mhr3: if you have the commits rev handy, can be useful to have it :)
[13:41] <mhr3> didrocks, the most important part of it is 153.3.8
[13:44] <didrocks> sil2100: ^
=== mmrazik is now known as mmrazik|otp
[13:45] <mhr3> i have to note that i still like x.y.z revnos better than a hash of every commit :P
=== dpb_ is now known as Guest72485
[13:52] <mpt> To whom it may concern: The most common unfixed crash in Q is currently http://launchpad.net/bugs/1062037 in unity-lens-video
[13:52] <ubot5> Error: ubuntu bug 1062037 not found
[13:52] <mpt> ubot5, try harder
[13:52] <didrocks> sil2100: working fine for me, pushing it to quantal! Thanks (just added the suggests).
[13:53] <didrocks> mpt: I guess this one was fixed yesterday evening
[13:53] <didrocks> I backported an additional commit for it
[13:53] <mpt> great
[13:56] <mhr3> i think crashes of binaries should have bigger weight on errors.ubuntu.com
[13:56] <mpt> mhr3, bigger weight than what?
[13:57] <didrocks> mhr3: errors.ubuntu.com is just about crashes :)
[13:57] <mhr3> it's just full of python exceptions
[13:57] <mpt> mhr3, only unhandled exceptions, though, right?
[13:57] <mhr3> yes, but that doesn't mean fatal ones
[13:57] <mhr3> or does it?
[13:58]  * mpt doesn't know
[13:59] <mhr3> still i think a separate view with most common sigsegvs would be useful
[14:00] <mpt> We'd like to make it more personally useful in general
=== mmrazik|otp is now known as mmrazik
[14:00] <mpt> Show you just the kinds of errors you are good at fixing yourself
[14:00] <mpt> for example
[14:01] <mpt> It already does individual packages, a next step would be package sets e.g. "Ubuntu Desktop" or "Xorg"
[14:02] <mpt> and classifying by error type e.g. sigsegv would be interesting too
[14:03] <mhr3> the problem is that we don't get anything else than segfaults for non-interpreted apps
[14:03] <mhr3> freezes could be useful, but that's not that simple to detect
[14:04] <mhr3> possible though :)
[14:15] <didrocks> sil2100: around?
[14:32] <popey> didrocks, he's on a late lunch
=== dandrader is now known as dandrader|lunch
[14:36] <didrocks> popey: ok, no hurry anyway, or maybe do you want us to discuss about what's needed for a SRU?
[14:53] <sil2100> didrocks: what's up?
[14:53] <didrocks> sil2100: so, I wanted to discuss with you about SRU/prioritization, do you have a minute?
[14:54] <didrocks> if you don't today, that can wait on Monday
[14:55] <popey> didrocks, how about a call with you me mirv and sil2100  first thing on monday morning?
[14:55] <popey> (your first thing, not mine)
[14:55] <didrocks> popey: sounds good to me
[14:55] <popey> ok I'll set it up
[14:55] <didrocks> thanks!
[14:56] <sil2100> didrocks, popey: ok, so let's do it on Monday then
[14:56] <didrocks> sil2100: it will be more an opened question on how to organize as I can only showed you what we did in the past and what worked (and rather what didn't really work)
[14:57] <didrocks> sil2100: so if you can think on some way to organize the SRU until then, please come with suggestions :)
[14:57] <popey> sil2100,  you okay to start at 06:00 UTC?
[15:00] <popey> I think he fainted.
[15:01] <didrocks> :)
[15:01] <didrocks> you should maybe consider later for him then :)
[15:01] <didrocks> (especially on a Monday)
[15:01] <popey> heh
[15:02] <popey> done
[15:03]  * didrocks likes how thunderbird is condering popey's mail as a spam and doesn't want me to click on "accept" the invitation
[15:03] <sil2100> didrocks: ACK
[15:03] <sil2100> popey: I'm okay with anything
[15:04]  * popey moves it to 03:00 UTC
[15:04] <sil2100> HEY
[15:04] <sil2100> Maybe not *anything*
[15:04] <sil2100> ;)
[15:04] <didrocks> ahah
[15:04] <didrocks> sil2100: too late!
=== dandrader|lunch is now known as dandrader
[15:58] <tsdgeos> Trevinho: uploadded the unittest to https://code.launchpad.net/~aacid/unity/do_not_reuse_menus_on_order_change/+merge/128243
[15:58] <tsdgeos> hope that is what you suggested :D
[15:58] <tsdgeos> aaaaaaand weekend time
[15:58] <tsdgeos> enojy all
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== yofel_ is now known as yofel
=== Arm is now known as Guest78888
=== salem_ is now known as _salem