[00:21] <GunnarHj> jbicha: ping?
[00:28] <jbicha> GunnarHj: hi
[00:29] <GunnarHj> jbicha: Hi Jeremy!
[00:29] <GunnarHj> jbicha: Saw that you removed the gcc patch 52 (languages) from the blueprint. Was it a mistake, or how are you thinking?
[00:32] <jbicha> GunnarHj: uh I think the patch is unappliable with 3.8
[00:34] <jbicha> oh, never mind, darkxst refreshed it
[00:34] <GunnarHj> jbicha: It is as is. Some thinks have been moved to gnome-shell etc., but someone made those mods to make it work with Ubuntu GNOME 13.04.
[00:35] <GunnarHj> jbicha: Right, it was darkxst who did that refresh.
[00:36] <jbicha> have you tried our 3.8 packaging from https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+packages?field.series_filter=raring ?
[00:38] <GunnarHj> jbicha: Not yet. Have been on a hospital, etc., but as soon as my health issues are under control, I'll make myself involved.
[00:40] <jbicha> ah ok, I'm thinking we could go with the GNOME language panel this cycle if someone could get the time to write an indicator-keyboard
[00:41] <jbicha> Ubuntu Phone is keeping people busy this year though
[00:41] <GunnarHj> jbicha: Shouldn't the language installation/removal thing be resolved also? Laney has that on his todo list, I think.
[00:42] <darkxst> GunnarHj, I have mostly done that
[00:42] <GunnarHj> jbicha: You have?
[00:42] <GunnarHj> jbicha: Can it be seen somewhere?
[00:42] <darkxst> gnome3-staging
[00:43] <GunnarHj> darkxst: Is it a gcc patch, or something separate?
[00:43] <darkxst> gcc patch
[00:43] <darkxst> and gnome-desktop patch
[00:44] <GunnarHj> darkxst: Thanks, I'll take a look soon.
[00:45] <jbicha> it doesn't do language removal though
[00:47] <GunnarHj> Hmm... People want that. Would it be hard to add the reverse of installation?
[00:48] <darkxst> currently installation uses the PK dbus helper, but there is no such helper for removal
[00:48] <darkxst> so removal is a little more tricky, but still possible
[00:49] <GunnarHj> I guess that existing code in language-selector can be useful. Even if we drop the language-selector UI, parts of that package could serve in the background.
[00:51] <GunnarHj> But it's soon 3 a.m. here, and I'm going to get some sleep. See you guys!
[05:29] <pitti> thanks desrt (#701800)
[05:35] <didrocks> hey pitti, how was your week-end?
[05:36] <pitti> hey didrocks; quite fine indeed, thanks! did lots of gardening, some more maths videos, and enjoyed the sun
[05:36] <pitti> one of these rare weekends being at home :)
[05:36] <pitti> didrocks: and your's?
[05:37] <didrocks> pitti: was too short, but really good! Mostly walking within the city and a lot of cylcing when it was not running (meaning, before the evening as it started to rain both on Saturday and Sunday)
[05:45] <mitya57> Hi pitti!
[05:45] <mitya57> FYI, pkg-create-dbgsym does something weird with xenomai package — see build logs at https://launchpad.net/ubuntu/+source/xenomai/2.6.2.1-2ubuntu1
[05:45] <mitya57> (I've disabled stripping some files in -2ubuntu2 as a workaround)
[05:49] <desrt> pitti: comments welcome
[06:13] <darkxst> pitti, have seen these? GVFS-WARNING **: meta_journal_iterate: found short sized entry, possible journal corruption
[06:14] <pitti> darkxst: yes, and it's unnerving
[06:14] <pitti> darkxst: colin walters fixed it a few days ago in git
[06:14] <pitti> https://mail.gnome.org/archives/commits-list/2013-May/msg05639.html
[06:15] <darkxst> if hiding, is fixing! :)
[06:15] <pitti> https://git.gnome.org/browse/gvfs/commit/?id=eb62d9
[06:16] <pitti> right, it's fixed in 1.17.1
[06:16] <pitti> mitya57: hello
[06:16] <pitti> mitya57: would you mind filing a bug about it as a reminder?
[06:21] <mitya57> pitti: done, bug 1189342
[06:21] <ubot2`> Launchpad bug 1189342 in pkg-create-dbgsym (Ubuntu) "xenomai 2.6.2.1-2ubuntu1 FTBFS with pkg-create-dbgsym" [Undecided,New] https://launchpad.net/bugs/1189342
[06:22] <mitya57> (By the way that was a first upload I sponsored :D)
[06:58] <jibel> good morning
[06:58] <didrocks> salut jibel, bon week-end?
[06:58] <jibel> salut didrocks , ça a été et toi?
[06:59] <didrocks> jibel: trop court, mais bien! :)
[07:40] <Sweetshark> Moin!
[07:41]  * Sweetshark kepts his fingers crossed: LibreOffice 4.1.0~beta2 building in a ppa ...
[07:42] <didrocks> Sweetshark: I tried that for unity tests passing, with various rates of failures :p
[07:44] <seb128> good morning desktopers
[07:44] <seb128> hey Sweetshark didrocks
[07:44] <didrocks> hey seb128!
[07:45] <pitti> bonjour seb128
[07:45]  * Sweetshark gives didrocks a hug about test failures and waves good morning at seb128 ...
[07:45] <pitti> hey Sweetshark
[07:45] <seb128> hey didrocks  pitti Sweetshark
[07:45] <Sweetshark> pitti: heya
[07:45] <seb128> didrocks, congrats on getting the new unity in ;-)
[07:46] <didrocks> seb128: thanks for NEWing and reviewing all those stuffs! :)
[07:46] <seb128> yw ;-)
[07:46] <didrocks> and now, even the MIRs are cleaned, happy about this!
[07:46]  * didrocks hugs Sweetshark back and cross fingers for him :)
[07:51]  * pitti still eagerly awaits NEW processing of umockdev :)
[07:51] <pitti> (but it's not that urgent)
[07:53] <seb128> pitti, I can have a look (or did you upload to Debian?)
[07:53] <pitti> no, to Ubuntu for now
[07:53]  * pitti cannot upload to Debian ATM
[07:53] <seb128> they still didn't follow on the key change RT?
[07:54] <pitti> seb128: but really, it's not that urgent, I was just teasing
[07:54] <pitti> not sure how regular AA is being done these days, still with archive days?
[07:54] <pitti> seb128: no, not yet
[07:54] <seb128> I can still have a look once I'm done with w.e catching up there ;-)
[07:55] <pitti> thanks; should be easy, same license for all files, Canonical copyright, etc.
[08:03] <mlankhorst> pitti: are capital letters not allowed in test names?
[08:03] <Laney> ahoy there
[08:03] <pitti> mlankhorst: ah, apparently not
[08:03] <pitti> Test names are separated by whitespace and should contain only
[08:03] <pitti>     characters which are legal in package names, plus `/'.
[08:04] <pitti> mlankhorst: we never ran into this before
[08:04] <pitti> hey Laney, how are yoU/
[08:04] <pitti> erk
[08:04] <pitti> "you?"
[08:05] <mlankhorst> I think the / was giving issues when I tried it
[08:06] <mlankhorst> $ lintian ../xorg-integration-tests_0.0.1.20130523-0ubuntu1_source.changes
[08:06] <veebers> didrocks: ping
[08:06] <mlankhorst> W: xorg-integration-tests source: illegal-runtime-test-name lib.libX11
[08:06] <Laney> pitti: very well, thank you!
[08:06] <Laney> the pub had a mini music festival on saturday which was fun
[08:07] <didrocks> veebers: pong
[08:07]  * mlankhorst is tempted to ignore the warning
[08:08] <Laney> at least report a lintian bug on it
[08:10] <seb128> Laney, hey
[08:11] <Laney> hey seb128
[08:11] <Laney> how's it going?
[08:11] <seb128> like a monday?
[08:12] <Laney> happy and raring to go then
[08:12] <seb128> had a nice w.e, trying to kick back in "work mode" ;-)
[08:12] <pitti> yeah, nothing like starting the week with an hour of catching up with bug mail :)
[08:12] <seb128> indeed
[08:13] <seb128> pitti, btw I noticed that "doesn't respect lid setting" issue, and it's new since saucy for me
[08:13] <seb128> it was working in raring
[08:13]  * seb128 uses a docked laptop and closing the lid in raring was not suspending it
[08:14] <pitti> seb128: ah, that's something else then; that shouldn't happen regardless of the g-c-c setting
[08:15] <seb128> pitti, it should, the g-c-c setting as a a/c preference, that's what should be used when docked
[08:15] <pitti> seb128: it wasn't like that in raring, though
[08:16] <seb128> it was
[08:16] <pitti> even if you set both to "suspend" (as I usually do), it didn't suspend when it was docked
[08:16] <pitti> at least for me
[08:16] <pitti> and I think that's right
[08:16] <pitti> phone, brb
[08:16] <seb128> hum
[08:16] <seb128> that seemed buggy in the other way then ;-)
[08:16] <seb128> if there is an UI the choice should be respected
[08:21] <pitti> re
[08:21] <pitti> seb128: well, if the laptop is docked and there's an external screen, I don't expect it to suspend, ever
[08:21] <pitti> there was some code to figure that out
[08:22] <seb128> pitti, some user do, they use both the laptop screen and the external one and close the laptop lid on the evening when they cal l it a day (we received bug reports asking for that in the past)
[08:22] <pitti> it's just that our old g-s-d doesn't yet know about the current logind semantics of handling lid and power buttons by itself
[08:22] <pitti> seb128: hm, I got some bug reports in the past complaining about the suspend
[08:22] <seb128> yeah, that's why we have an option :p
 g-s-d <hard place>
[08:23] <pitti> seb128: we don't have an option for dock behaviour, at least I can't see it?
[08:23] <seb128> well, g-c-c has a "what do to on lid close when on a/c" and docked is an a/c state
[08:23] <pitti> anyway, we should definitively fix the behaviour of these two (i. e. not suspend when not configured so in g-c-c)
[08:24] <pitti> that's why I asked about g-s-d 3.8 the other day, but seems we need to backport that behaviour only
[08:24] <seb128> right
[08:41] <darkxst> seb128, pretty sure 3.8 does support that
[08:43] <darkxst> but may well be done via inhibitors from g-s
[08:43] <seb128> by then federico tried to do the smart behaviour pitti described
[08:43] <seb128> e.g https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=6e17bc786f55f283f2c721249197e7740174fd43
[08:43] <seb128> but that probably changed in 3.8
[08:43] <seb128> pitti, btw, that's what I remembered: https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=f10c8922ef4ead58ac0389144c2d0b16e872067e
[08:44] <pitti> mlankhorst: FYI, debian bug 711844
[08:44] <ubot2`> Debian bug 711844 in autopkgtest "autopkgtest: Allow uppercase letters in test names" [Wishlist,Open] http://bugs.debian.org/711844
[08:45] <seb128> pitti, https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=9c2a401f9c92307bdb5ff2baeb82b8ecbf8eadf7 is the sort of issues we will need to watch for if we update to 3.8
[08:45] <seb128> "gnome-shell is now using a delay inhibitor to ensure locking happens before suspend."
[08:46] <seb128> not sure what happens if you don't run g-s
[08:46] <mlankhorst> pitti: I just opened that ;-)
[08:46] <Laney> he's showing you that it got reassigned
[08:47] <mlankhorst> oh that
[08:47] <Laney> i.e. that autopkgtest says your test name isn't allowed
[08:47] <mlankhorst> yeah I wasn't sure whether the bug was in lintian, the debian spec, or autopkgtest
[08:48] <darkxst> seb128, pitti add inhibitors to gnome-screensaver
[08:50] <seb128> is that a question?
[08:50] <seb128> or order? ;-)
[08:50] <darkxst> seb128, its already been done
[08:50] <darkxst> *added
[08:50] <seb128> oh, ok
[08:51] <darkxst> the only outstanding issue with g-s-d that I know of is the ibus stuff
[08:52] <darkxst> (3.8 that is)
[08:54] <seb128> can we update g-s-d without g-c-c ?
[08:54] <seb128> (I guess not)
[08:57] <pitti> yeah, we need to teach our 3.6 g-s-d power plugin about logind inhibitors
[08:58] <seb128> pitti, umockdev, would it make sense to b-d on valac rather than -0.18 | -0.16?
[08:58] <pitti> seb128: like, valac (>= 0.16.1)? can do, yes
[08:59] <pitti> I haven't tested with 0.20 yet, but I can make sure that upstream works with that
[08:59] <seb128> pitti, jbicha has been doing changes like that for some days to prepare the 0.20 transition
[08:59] <pitti> $ valac --version
[08:59] <pitti> Vala 0.18.1
[08:59] <pitti> ah, installing -0.20 doesn't change the default yet
[08:59] <Laney> yeah, that's part of the transition
[09:00] <pitti> ok, uninstalled 0.18, works now
[09:00] <seb128> pitti, umockdev NEWed
[09:00] <pitti> seb128: merci!
[09:00] <seb128> pitti, you can sudo update-alternatives --config valac to change the default as well
[09:00] <seb128> pitti, de rien
[09:01] <Laney> we should take this chance to use the same alternatives priorities as Debian do
[09:01] <Laney> that delta always annoyed me
[09:01] <seb128> those numbers are a bit random
[09:01] <Laney> yeah, it's only the ordering that matters
[09:01] <seb128> it's not really a delta
[09:01] <seb128> it's a matter of "we updated first and picked a number and they picked a different one"
[09:02] <Laney> in the sense that theirs is different to ours
[09:02] <seb128> right, I was just saying "feel free to drop the delta there" ;-)
[09:02] <Laney> yeah
[09:02] <Laney> I'll tell jbicha about it if/when he comes on later
[09:06] <seb128> pitti, libumockdev-dev should depends on glib-dev since it's .pc requires it
[09:06] <seb128> pitti, (doing binNEW review)
[09:09] <pitti> seb128: added that, thanks for spotting
[09:10] <seb128> yw
[09:10] <pitti> seb128: upstream needs some tweaking for vala 0.20, working on that
[09:10] <pitti> (posix_extra needs to drop some definitions, my patches went upstream in 0.20)
[09:10] <seb128> k
[09:10] <seb128> binNEW done
[09:10] <pitti> cheers!
[09:11] <seb128> didrocks, Laney: ubuntu-system-settings NEWed as well btw (I pre-review for Ken friday and he got the autolanding in place)
[09:11] <Laney> cool
[09:12] <Laney> I did some packaging for my work in progress on the appearance panel
[09:12] <didrocks> seb128: yeah, saw that, Thanks!
[09:12] <Laney> but we should decide on package/project names and stuff
[09:12] <seb128> Laney, we should also decide on what panels should be in the ubuntu-system-settings source
[09:13] <seb128> not sure it makes sense to split most of those
[09:13] <Laney> oh, I just kind of assumed it would be separate
[09:13] <Laney> didn't really consider it
[09:13] <seb128> it's like gnome-control-center, we have a few external panels where it makes sense
[09:13] <seb128> like ubuntuone might want to have their own tree with other part of their code
[09:13] <Laney> doesn't matter from a system point of view as all of the integration points can as well be used externally
[09:13] <seb128> or online accounts
[09:13] <seb128> right
[09:14] <pitti> seb128: fixed for vala 0.20 in https://github.com/martinpitt/umockdev/commit/681e6a04
[09:15] <seb128> pitti, danke
[09:15] <pitti> seb128: I'll do a 0.2.5 release, adjust the build dep, and upload
[09:15] <pitti> then both issues will be fixed
[09:15] <pitti> thanks for reviewing!
[09:15] <seb128> yw
[09:15] <seb128> thanks for the quick fixes ;-)
[09:15] <pitti> that'll also fix the autopkgtest
[09:15] <jibel> I get a crash in gnome-control-center with easy steps to reproduce, bug 1188826, could anyone confirm?
[09:15] <ubot2`> Launchpad bug 1188826 in gnome-control-center-unity (Ubuntu) "gnome-control-center crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,New] https://launchpad.net/bugs/1188826
[09:15] <pitti> seb128: no time like the present
[09:16] <seb128> jibel, no segfault here
[09:16] <didrocks> seb128: I get it as well
[09:16] <didrocks> jibel: ^
[09:17] <seb128> didrocks, great, you won the right the debug/fix it ;-)
[09:17] <didrocks> seb128: not really :p
[09:17] <didrocks> seb128: weird you can't reproduce it
[09:17] <seb128> is that only happening with appaerance?
[09:17] <darkxst> seb128, g-c-c 3.6 could work with g-s-d 3.8 but would require cherrypicking a few patches
[09:17] <didrocks> yeah, only appearance from the quick test I've done
[09:17] <seb128> darkxst, I wonder if we should do that to start, I need to look again at the number of UI changes to the new g-c-c
[09:17] <seb128> didrocks, (gnome-control-center:20295): gnome-control-center-unity-WARNING **: Could not fill pictures source: L'opération a été annulée
[09:18] <seb128> didrocks, I get that but no segfault
[09:18] <darkxst> might be easier to just finish g-c-c, there is nothing major blocking it
[09:18] <didrocks> (gnome-control-center:4305): GLib-GIO-CRITICAL **: g_file_new_for_path: assertion 'path != NULL' failed
[09:18] <seb128> darkxst, out of crap UI decisions
[09:18] <didrocks> (gnome-control-center:4305): GLib-GIO-CRITICAL **: g_file_load_contents: assertion 'G_IS_FILE (file)' failed
[09:18] <seb128> didrocks, I've those as well but no segfault, anyway I will debug
[09:18] <jibel> seb128, yes only appearance
[09:18] <seb128> I've another bug to fix in there
[09:19] <darkxst> seb128, most of the UI changes are in panels that ubuntu doesnt use
[09:19] <seb128> darkxst, like power? :p
[09:19] <darkxst> yes power has changed
[09:20] <seb128> darkxst, well anyway I need to find some time to look at it, we might just end up have 2 sources one for 3.6 with Ubuntu patches and a 3.8 stock upstream
[09:20] <darkxst> network, printers, region
[09:20] <seb128> which would make both Unity and GNOME edition happy
[09:21] <seb128> I would prefer to avoid have 2 g-s-d version though
[09:23] <darkxst> you could keep 3.6 panels as external modules?
[09:23] <seb128> we could, but depending on the number of changes we want/don't want in 3.8 we could as easily fork 3.6
[09:25] <mlankhorst> pitti: ignoring the autopkgtest warning, does https://launchpad.net/~mlankhorst/+archive/ppa/+packages xorg-integration-tests look good to you?
[09:36] <darkxst> seb128, well let me know once you have had a look at 3.8 then
[09:36] <seb128> sure
[09:36] <seb128> thanks for the work on it!
[09:37] <darkxst> np
[09:40] <pitti> mlankhorst: oh, it's just a warning, but works anyway?
[09:40] <pitti> mlankhorst: do you have that in VCS somewhere, or should I download and look at the .dsc?
[09:43] <pitti> mlankhorst: wrapped lines in debian/tests/control don't work AFAIR (or maybe jibel fixed that)
[09:44]  * pitti runs run-adt-test -p ppa:mlankhorst/ppa xorg-integration-tests
[09:44] <jibel> pitti, mlankhorst I fixed that. ipython uses it for example
[09:55] <mlankhorst> pitti: not in a public git yet
[09:56] <pitti> Unable to locate package xorg-integration-tests
[09:56] <pitti> oh, it's not built yet
[09:56] <pitti> so I can't run the tests
[09:56] <mlankhorst> oh darn
[09:57] <mlankhorst> it depends on newer inputproto, it can't run with x1.13, needs the 1.14 canonical-x/x-staging ppa enabled
[09:57] <pitti> set a PPA dependency?
[09:58] <mlankhorst> I ran the tests locally with the documentation, so I know that part works at least
[09:59] <mlankhorst> pitti: it sort of requires it at runtime too, i don't know if a dependency would handle that, i can copy it to the x-staging ppa though
[10:01] <pitti> mlankhorst: yeah, or do that
[10:02] <pitti> mlankhorst: so, LGTM except the wrapping (debian bug 695797 )
[10:02] <ubot2`> Debian bug 695797 in autopkgtest "Depends field in test control file cannot be folded" [Normal,Open] http://bugs.debian.org/695797
[10:02] <pitti> mlankhorst: but if you ran it with "sudo adt-run" and it worked, fine :)
[10:03] <seb128> stupid glib question
[10:03] <seb128> how do I set a pointer to NULL when the refcount of the object reachs 0?
[10:03] <seb128> that's harder that it should :/
[10:04] <pitti> g_clear_object() ?
[10:04] <pitti> oh, you mean as a kind of callback?
[10:04] <pitti> not sure whether that's possible
[10:04] <seb128> doesn't that set it to NULL in all cases?
[10:04] <seb128> not as a callback, notify-osd does unref objects
[10:04] <seb128> and then do IS_OBJECT(object)
[10:04] <seb128> that segfaults with the new glib
[10:04] <mlankhorst> once you unref, you shouldn't touch it any more..
[10:05] <seb128> I wall to set it to NULL but only if the ref reachs 0
[10:05] <seb128> it's refed over 1
[10:05] <pitti> ah, someone pinged me about that this morning
[10:05] <seb128> so if ref is 2 and it's unref-ed I don't want to NULL it
[10:05] <pitti> bug 1182140
[10:05] <ubot2`> Launchpad bug 1181324 in notify-osd (Ubuntu) "duplicate for #1182140 notify-osd crashed with SIGSEGV in bubble_get_id()" [Medium,Confirmed] https://launchpad.net/bugs/1181324
[10:05] <seb128> right
[10:05] <mlankhorst> seb128: sounds a bit abusive though :/
[10:05] <pitti> shakaran
[10:05] <seb128> I understand what happens and why, not sure how to fix it
[10:05] <pitti> seb128: so I think g_clear_object() is what you might want to use?
[10:06] <pitti> oh, that doesn't just do _unref() if the ref count  is > 1?
[10:06] <mlankhorst> either you control the refcount, and you know it will hit 0 or not in advance, or you don't but in that case you're no longer allowed to touch the object..
[10:07] <seb128> pitti, I think g_clear_object ==
[10:07] <seb128> g_object_unref + ptr =NULL
[10:07] <seb128> without consideration for the refcount
[10:07]  * seb128 checks
[10:07] <pitti> :/
[10:08] <mlankhorst> but checking if ref will become 0 seems racy to me :/
[10:11] <seb128> that code is a bit crazy
[10:11]  * seb128 doesn't want to spend hours to understand the notify-osd crazy memory management
[10:11] <seb128> they have a
[10:11] <seb128> 	if (stack_is_slot_vacant (self, slot))
[10:11] <seb128> 		self->slots[slot] = BUBBLE (g_object_ref ((gpointer) bubble));
[10:12] <seb128> so I guess the refcount can be > 1
[10:14] <mlankhorst> yeah but if you unref that slot is vacant :/
[10:15] <seb128> bah, I will just update the bug with the details of what is happening and let somebody who knows that code fix it
[10:21] <mlankhorst> pitti: woops, I also need xserver-xorg-input-wacom as a build-depend, and xorg-gtest is too old in saucy :/
[12:00] <noecc> I've updated from 11.10 to 13.04 via do-release-upgrade and now cannot login via gdm.  After entering user/pw the screen blanks for a few seconds and returns to the logon prompt.  Permission on /home are root:root 777.  Perms on /home/user are user:user 755
[12:01] <mlankhorst> have you checked .xsession-errors?
[12:05] <noecc> .xsession-errors is dated 6/6 with no timestamp in the log.  How would I know which errors are from today?
[12:08] <mlankhorst> zero it, retry logging in
[12:21] <noecc> mlankhorst: Nothing written to .xsession-errors, however, Changing the session type at the logon screen from Ubuntu (default) to Gnome was successful.  Also changing it back to Ubuntu (default) is also now successful.
[12:24] <mlankhorst> no idea then :/
[13:00] <sil2100> tedg: hello!
[13:00] <tedg> Good morning sil2100
[13:02] <sil2100> tedg: during daily-release testing, we noticed a hud issue with the HUD not returning any results for even the obvious queries
[13:02] <sil2100> tedg: let me show you a video
[13:04] <tedg> sil2100, Is this coming from an app?  We didn't have support for unity-gtk-module...
[13:04] <seb128> sil2100, is it working with firefox?
[13:05] <sil2100> tedg: ah! Ok, that would make sense - but I actually thought that was already in, as I saw a recent commit related to support of u-g-m
[13:05] <tedg> sil2100, That landed on trunk in r273
[13:05] <sil2100> tedg, seb128: ok guys, I'll check that, probably that's the reason
[13:05] <sil2100> Thanks!
[13:05] <tedg> sil2100, I'm not sure why it didn't get released, is that part of the autopilot stuff?
[13:06] <sil2100> tedg: I need to see what revisions are being used in the hud stack right now
[13:09] <seb128> sil2100, it seems like the indicator stack failed in jenkins because it installed packages that shouldn't be there?
[13:10] <seb128> sil2100, seems like a bug in the stack config...
[13:16] <sil2100> seb128: yes, I'm fixing that now, it seems we also had some leftovers from appmenu-gtk
[13:16] <seb128> sil2100, right, it's in the apt-get install command
[13:33] <tedg> sil2100, The issue there is that we have some branches that need to land in order from jbicha.  So that's why were waiting on the daily releases.
[13:34] <tedg> sil2100, It's not a big deal right now, but FYI.
[13:44] <seb128> Laney, tedg, larsu, didrocks: you might want join that team https://launchpad.net/~system-settings-touch membership ... it would be useful to have some people in there so we can have peer reviews, etc
[13:45] <Laney> seb128: ok, doing
[13:45] <seb128> Laney, thanks
[13:45] <didrocks> joined
[13:45]  * tedg thinks it needs a cooler icon...
[13:46] <larsu> seb128: will do
[13:46] <seb128> thanks guys ;-)
[13:46] <seb128> tedg, larsu: oh, and good morning and happy new week ;-)
[13:47] <tedg> Good morning seb128.  Tried that Texas wine this weekend, France is probably safe for another year or two...
[13:47] <seb128> tedg, haha, I'm glad to year ;-)
[13:47] <seb128> do
[13:47] <seb128> hear
[13:48] <seb128> dooh even
[13:48] <larsu> seb128: thanks, same to you!
[13:54] <jbicha> seb128: howdy
[13:55] <jbicha> I think we're ready to sync vala-0.20 from Debian (making it default); GNOME stuff should already work with it without problem
[13:56] <jbicha> and the things using vala-0.18 I've tested (like Unity pieces) also work with -.20
[13:56] <seb128> jbicha, hey, can you check with mhr3 and sil2100 if they feel like they are ready? mhr3 mentioned last week that we shouldn't rebuild the lenses with 0.20 because it has issues IIRC
	seb128, no, there are other issues with 0.20
[13:58] <mhr3> seb128, it was about libunity, lenses might be fine, i didn't check them
[13:58] <seb128> mhr3, what's the issue for libunity?
[13:59] <mhr3> seb128, it just fails to build
[13:59] <seb128> mhr3, well in any case if libunity is having issue that's a good reason to hold on the version change, until we resolve it
[14:00] <jbicha> ah, yes libunity explicitly depends on valac-0.18 and doesn't built yet with valac-0.20
[14:00] <jbicha> seb128: see there's about 6 packages autosynced from Debian that won't build on Ubuntu because they need valac to be >= 0.20
[14:01] <seb128> shrug
[14:01] <jbicha> we can change the default without it affecting libunity
[14:01] <seb128> what do they force a version like that?
[14:01] <seb128> I'm sure those build with 0.18
[14:01] <seb128> but yeah, if you are tested and are sure it doesn't break unity, feel free to sync it
[14:02] <jbicha> yes, we could patch all of those packages but it didn't seem worth it
[14:02] <jbicha> like https://git.gnome.org/browse/gupnp/commit/?id=4870e
[14:03] <jbicha> seb128: ok, could you promote vala-0.20 to main then?
[14:03] <seb128> jbicha, ok
[14:04] <jbicha> speaking of vala bugs, unity-greeter won't build with vala-0.20 yet either, bug 1186058
[14:04] <ubot2`> Launchpad bug 1186058 in unity-greeter (Ubuntu) "fails to build from source with vala 0.20" [Undecided,New] https://launchpad.net/bugs/1186058
[14:05] <didrocks> better to get that fixed because syncing (no regression ;))
[14:05] <didrocks> or force the vala version meanwhile
[14:05] <jbicha> it's already been forced
[14:05] <didrocks> I know that libunity has bugs with 0.20
[14:06] <didrocks> mhr3 told it
[14:06] <didrocks> jbicha: you checked that every packages forced 0.18?
[14:06] <jbicha> yes, libunity has been pinned to 0.18
[14:06] <didrocks> (and vala scopes as well?)
[14:19] <jbicha> didrocks: I checked building but not running and I didn't check everything but I did test-build the non-gnome stuff in main that builds against just valac
[14:19] <jbicha> the gnome stuff should be fine since F19 has had vala 0.20 as default for months
[14:21] <jbicha> I think we can definitely drop vala 0.18 this cycle, libunity & totem-plugin-arte are the only 2 explicitly b-d-ing on it that don't work with 0.20
[14:23] <jbicha> .14 depends on Debian but we might keep .16 around a bit longer
[14:34] <sil2100> didrocks: ping!
[14:35] <didrocks> sil2100: pong
[14:35] <sil2100> didrocks: soo, I remember that when otto was being planned, one of the cool things about it was that we could take a snapshot of a given test run to see what was happening there
[14:35] <sil2100> didrocks: is that possible right now?
[14:35] <didrocks> sil2100: it is
[14:35] <didrocks> of course you need the same graphic card
[14:35] <didrocks> and architecture
[14:35] <sil2100> didrocks: since tedg would like to fetch some logs from the rootfs
[14:36] <didrocks> sil2100: you should have the delta attached in a .otto file referenced by the build
[14:36] <didrocks> (it's a tar delta file)
[14:38] <sil2100> didrocks: where can I find that file? (I found the file-name in the logs)
[14:38] <didrocks> sil2100: ok, so in the http archive published
[14:38] <didrocks> you have an archive/ directory
[14:38] <sil2100> Ah!
[14:39]  * sil2100 noticed the link at the end of the test log
[14:39] <sil2100> \o/ Thanks
[14:39] <didrocks> yw :)
[14:40] <didrocks> sil2100: not doc yet, just trying to see how clear this is without any :)
[14:41] <sil2100> didrocks: btw. when I redeployed a stack but no packages were added, can I re-run it with 'foo' (i.e. without rebuilding) or am I forced to rebuild everything from scratch?
[14:42] <didrocks> sil2100: depends on what you are trying to do :)
[14:42] <didrocks> sil2100: if this has nothing to do with trunk content, you can use "foo"
[14:45] <sil2100> didrocks: it's just the packages: list that changed
[14:46] <didrocks> sil2100: so fine once redeployed and ran with "foo" :)
[14:46] <didrocks> this famous famous foo package
[15:01] <tedg> didrocks, When we have the glib support for calling apport on gcriticals, will autopilot tests upload those to errors?
[15:01] <didrocks> tedg: I guess it's a question for thomi
[15:02] <didrocks> I would love to :)
[15:02] <tedg> Yeah, looking for the stack traces...
[15:02] <didrocks> tedg: if you need more info, we can add more logs to look at
[15:02] <tedg> Or atleast we could put the crash files in the artifacts.
[15:02] <mhr3> tedg, you want to reach bug number 10mil asap? :)
[15:03] <tedg> mhr3, Did sabdfl say 200M bugs or 200M users?  /me is confused
[15:03] <mhr3> lol
[15:04] <attente> seb128, hey
[15:04] <didrocks> ahah :)
[15:04] <attente> we're going to 3.8.2 of gnome-desktop3 and sticking with 3.6.4 of g-s-d?
[15:09] <mhr3> didrocks, jibel, still possible to look at the hang?
[15:11] <didrocks> mhr3: it's more than possible, it's advised :)
[15:11] <mhr3> didrocks, so... how? :)
[15:11] <didrocks> mhr3: what do you need to get access to exactly?
[15:12] <didrocks> mhr3: more logs, or ssh to the machine?
[15:12] <mhr3> didrocks, the machine where it's hanging
[15:12] <mhr3> ssh preferably
[15:12] <jbicha> attente: I believe it's unsafe to update g-s-d without updating g-c-c and g-c-c still needs a fair amount of work
[15:13] <didrocks> mhr3: we have tro relaunch the tests, nvidia is fine? (apparently, jibel can have that on saucy too)
[15:13] <didrocks> mhr3: let's wait for jibel, I think he has better direct access, I can relaunch the tests for failing meanwhile (as it's starting to slow down at test 100)
[15:13] <attente> jbicha, but the gnome-desktop3 is going to 3.8.2, and i think this is going to cause some problems for older g-s-d
[15:14] <attente> maybe not big problems, but it at least caused an ibus issue i was struggling with this week
[15:15] <mhr3> didrocks, k, i guess you already checked top etc and made sure it's not some huge leak again?
[15:16] <sil2100> didrocks: quick question -> do we need autopilot in main?
[15:17] <didrocks> cyphermox: sil2100: Mirv: kenvandine: the QA stack status will now be ignored for dependant stack (the result of the stack running, it will still block the other stack in case it's building)
[15:17] <didrocks> sil2100: not really, as we run that pre-publishing
[15:17] <didrocks> sil2100: maybe on the long term, would be a nice to have, but I don't think it should right now, why?
[15:17] <didrocks> mhr3: yeah, we are quite puzzled, we thought it was the nvidia driver
[15:17] <jbicha> attente: g-s-d and g-c-c is the most difficult part of GNOME to integrate into Ubuntu; if we had to wait for it to be ready first, maybe we'd never update GNOME?
[15:18] <didrocks> mhr3: as some memory are taken and not released, but jibel really investigated it
[15:20] <jbicha> attente: I believe 3.6 was the first GNOME with ibus integration so maybe there still would have been an issue since our 3.6 doesn't have that
[15:20] <sil2100> didrocks: just been thinking about the task in the spreadsheet "The dependency needs to be MIRed and reintroduced as a dep" for python-upa
[15:20] <sil2100> didrocks: not sure if anything besides autopilot-touch uses that package?
[15:20] <sil2100> didrocks: so, do we really need that to be MIR'ed?
[15:21] <didrocks> sil2100: oh sorry, no MIR needed, just NEWed
[15:21] <sil2100> didrocks: because autopilot is not in main, so it's not causing a problem
[15:21] <didrocks> had my brain broken :)
[15:21] <sil2100> Ok ;)
[15:21] <didrocks> sil2100: you put all the new components as DONE, but is there any cupstream2distro-config branch with them enabled already?
[15:21] <attente> jbicha, right, i'm running a g-s-d that drops the patch that disables ibus
[15:21]  * attente working on the indicator-keyboard
[15:22] <sil2100> Uuuh! Ok, now this is something I forgot, my brain is broken as well!
[15:22] <didrocks> ahah :)
[15:22] <sil2100> Let me do that and re-open that task ;)
[15:22] <didrocks> sil2100: please, before adding them, we need to preNEW I guess
[15:22] <didrocks> (so that we don't block on NEW)
[15:27] <Mirv> sil2100: ah, funny, I thanked you about changing maintainer address, but it was me actually locally - thomi's @ubuntu.com address should be used in the maintainer field, otherwise bzr bd complains
[15:28] <didrocks> Mirv: for those, I have to change my DEBEMAIL, which isn't fun :/
[15:28] <sil2100> Mirv: fixing! Didn't know bzr bd was actually saying things
[15:29] <sil2100> When the e-mail is liek that
[15:29] <didrocks> if you have an @ubuntu.com DEBEMAIL, it will :)
[15:29] <didrocks> (it's debuild actually)
[15:30] <Mirv> didrocks: ah so that's a workaround when wanting to build such a thing
[15:30] <sil2100> Mirv: thanks ;)
[15:31] <didrocks> Mirv: yep, not sure there is anything else than changing the maintainer otherwise
[15:31] <sil2100> Mirv: just approve and go rest ;p!
[15:32] <Mirv> sil2100: I won't approve since I seem to be getting lintian warnings ;) , but I'll put those to merge request and then I go back to evening activities
[15:32] <jbicha> attente: cool, ibus 1.5 & indicator-keyboard is perhaps the biggest blocker :)
[15:32] <Mirv> (lintian errors, even)
[15:33] <jbicha> attente: perhaps you should be targetting g-s-d 3.8?
[15:34] <attente> jbicha, you said that would probably need an update of g-c-c though, no?
[15:34] <jbicha> g-c-c's language panel changed quite a bit in 3.8 so I don't know how hard it would be for it to do both
[15:34] <sil2100> Mirv: it seems I missed the standards warning, not sure what to do with the native warning though
[15:34] <sil2100> Mirv: should I keep this package as a native package? didrocks ?
[15:35] <attente> jbicha, yeah.. all things considered, the input methods panel is already done for 3.6.4
[15:35] <jbicha> attente: yes but I think the other minimum changes for g-c-c 3.8 are doable this cycle
[15:35] <jibel> seb128, bug 1182307 is another crasher with trivial steps to reproduce
[15:35] <ubot2`> Launchpad bug 1182307 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_type_check_instance()" [Medium,Confirmed] https://launchpad.net/bugs/1182307
[15:35] <didrocks> sil2100: let's use split mode, like every other ones
[15:36] <didrocks> sil2100: just a question of standardization
[15:36] <attente> jbicha, ok, so you recommend moving the whole stack to 3.8?
[15:36] <Mirv> sil2100: https://code.launchpad.net/~sil2100/python-upa/packaging_review/+merge/168393/comments/373857
[15:36] <didrocks> and being able to backport patches easily
[15:36] <sil2100> Mirv: ohshit, I didn't get those
[15:37] <jbicha> attente: I think you should look at 3.8; it's in the staging ppa but you'll probably need to run with XDG_CURRENT_DESKTOP=GNOME as I haven't unhidden the language panel yet
[15:37] <sil2100> Mirv: some of them make no sense, hm
[15:38] <jbicha> the regressions are 1. while we can add languages, language removal hasn't been added yet 2. fallback languages (i.e. primary language Arabic, falling back to French)
[15:38] <attente> jbicha, sure, i'll take a look. i guess it's just that i'm not really aware of what the plan is for what will go into saucy
[15:38] <jbicha> I'm thinking those are minor issues
[15:39] <jbicha> attente: ideally your work would work with either g-s-d; I just don't know how much changed
[15:40] <attente> jbicha, ok, i'll try it with the 3.8 stack then
[15:40] <attente> thanks for your help
[15:41] <Laney> jbicha: btw, if you're planning on updating the default vala (heard a rumour you were), can you unify the alternate priorities between Ubuntu and Debian at the same time to zap a delta?
[15:43] <jbicha> Laney: I'm working on that (I read the backlog); by the way Debian set the priority for 0.18 fairly low (I guess because it was only experimental and has been dropped)
[15:43] <Laney> right
[15:43] <jbicha> I think that's ok because we should be able to drop 0.18 soonish
[15:43] <Laney> I was imagining we'd follow suit
[15:47] <jibel> mhr3, didrocks sorry was otp, so I re-ran the tests another time on an intel box, no dbus hang this time, just found a leak in gvfsd-http
[15:47] <jibel> so it's quite random
[15:49] <mhr3> "great"
[15:49] <didrocks> jibel: maybe we can give mhr3 access to the nvidia box?
[15:50] <didrocks> jibel: we can reproduce the mem explosion quite reliably here?
[15:51] <jibel> didrocks, sure
[15:51] <jibel> mhr3 don't you have access to the lab already ?
[15:51] <mhr3> jibel, if i do, i don't know about it :)
[15:53] <jbicha> Laney: could you sponsor http://paste.ubuntu.com/5752083/ ?
[15:53] <Laney> yes, once I learn how to type duration and unbreak this file
[15:53] <Laney> see, I can do it right in IRC. Got it wrong in code thrice
[15:54] <Laney> jbicha: what priority do we have on 14/18/20 currently?
[15:56] <jbicha> 20 is 100; 18 is 90 (Debian has 70); 14 (building now) is 94
[15:57] <jbicha> 18 might not be worth changing (it's not in the desktop or MOTU sets either)
[16:01] <sil2100> kenvandine: ping
[16:01] <sil2100> kenvandine: do you know why dee-qt is part of the friends stack?
[16:01] <sil2100> kenvandine: I think, since dee is in the unity stack, wouldn't it make more sense for it to be in the unity stack as well?
[16:02] <sil2100> didrocks: ^
[16:02] <didrocks> depends on what is going to depend on it
[16:03] <didrocks> I don't think friends needs to dep on unity
[16:03] <kenvandine> sil2100, friends was the only consumer at the time
[16:03] <didrocks> maybe more something like platform? wdyt?
[16:03] <kenvandine> makes sense
[16:03] <kenvandine> imo dee should be too
[16:03] <didrocks> agreed
[16:04] <didrocks> kenvandine: is dee-qt part of what apps would access directly?
[16:04] <kenvandine> shouldn't hold up those because we can't land unity :)
[16:04] <didrocks> if so, it can be even in the sdk
[16:04] <kenvandine> didrocks, apps and the shell
[16:04] <didrocks> maybe sdk or platform? I have no strong opinion :)
[16:04] <kenvandine> no strong opinion
[16:04] <kenvandine> dee-qt in sdk and dee in platform?
[16:04] <didrocks> sdk deps on platform?
[16:04] <didrocks> or it's the other way around?
[16:05] <kenvandine> it should :)
[16:05] <didrocks> (we don't want circular deps)
[16:05] <kenvandine> indeed
[16:05] <kenvandine> i would think sdk should depend on platform
[16:05] <kenvandine> not the other way
[16:05] <kenvandine> platform should be lower level than the sdk
[16:05] <didrocks> I agree
[16:05] <didrocks> kenvandine: let's do it that way! :)
[16:05] <kenvandine> ok
[16:05] <kenvandine> sil2100, ^^
[16:06] <didrocks> kenvandine: maybe then platform should run one or two unity tests
[16:06] <didrocks> (integration tests)
[16:06] <didrocks> to ensure dee isn't broken
[16:06] <didrocks> (the ones with scope tests)
[16:06] <kenvandine> perhaps
[16:06] <kenvandine> same should be true for sdk
[16:06] <kenvandine> sdk should run tests for some apps that use the sdk...
[16:07] <didrocks> kenvandine: more than agree, I asked for the sdk team to identify some of the apps tests :)
[16:07] <didrocks> but just need few, no need to run everything, just if it's obviously broken, we can see that quickly and reject
[16:07] <kenvandine> indeed
[16:13] <sil2100> kenvandine: will you make the switch when needed? ;)
[16:15] <sil2100> kenvandine: you can also re-enable daily_release for dee-qt now, as the packaging got reviewed and prepared
[16:15] <didrocks> sil2100: it needs to be pre-NEWed
[16:15] <didrocks> sil2100: so that we don't stuck it in NEW
[16:18] <sil2100> >_>
[16:18] <sil2100> <_<
[16:18] <sil2100> What's a pre-NEW..?
[16:18]  * sil2100 hides
[16:18] <kenvandine> didrocks, it isn't a new package
[16:18] <kenvandine> it's in universe
[16:18] <kenvandine> or main...
[16:19] <didrocks> kenvandine: oh ignore me then!
[16:19] <kenvandine> yeah, universe
[16:19] <didrocks> sil2100: a NEW pre-review ;)
[16:19] <kenvandine> :-D
[16:19] <kenvandine> sil2100, i can make the changes if you like
[16:19] <didrocks> kenvandine: ah, just a note, once you deploy, it doesn't remove old jenkins jobs in the old stack
[16:19] <kenvandine> gotta run to lunch now... bbiab
[16:19] <didrocks> kenvandine: it's not triggered, but just to clean the view
[16:20] <kenvandine> do we need to ping someone?
[16:20] <didrocks> kenvandine: you can remove that in the interface
[16:20] <didrocks> directly
[16:20] <didrocks> click on the job
[16:20] <kenvandine> cool
[16:20] <didrocks> you have "delete" or "remove"
[16:20] <didrocks> or whatever english word that is :p
[16:20] <sil2100> didrocks: ah, you mean the packaging review ;) ?
[16:20] <kenvandine> i'll go through my cruft this afternoon and clean them up
[16:21] <seb128> jibel, bah
[16:21] <seb128> hate new glib
[16:22] <seb128> larsu, desrt: hey, new glib is making things pretty unhappy (bugs in $things but still)
[16:22] <didrocks> sil2100: yeah, but not needed as kenvandine rightly pointed :)
[16:22] <seb128> larsu, desrt: do you know about new glib segfault when you try to so IS_OBJECT(obj) on a unrefed object? is that a feature (it used to not segfault)? can we get it back to be robust against those? ;-)
[16:23] <sil2100> didrocks: I anyway modified the packaging a bit last week for that one, for all components basically
[16:23] <kenvandine> seb128, like how robust abort on uninstalled schema is?
[16:23]  * kenvandine ducks
[16:23] <seb128> lol
[16:23] <didrocks> sil2100: for all the new ones though, please send me the list along so that I can review
[16:23] <seb128> kenvandine, don't give those guys crazy ideas
[16:24] <didrocks> kenvandine: at least, this code path is well tested in production :p
[16:24] <kenvandine> indeed
[16:24] <sil2100> didrocks: ACK! Will send it once I'm done with my current business ;)
[16:24] <didrocks> if it doesn't abort anymore, we'll know quickly :)
[16:24]  * kenvandine really leaves for lunch now
[16:24] <didrocks> enjoy!
[16:24] <didrocks> sil2100: sounds good!
[16:24] <seb128> kenvandine, have fun, you will have an update mr when you get back
[16:25] <larsu> seb128: nobody shold ever call anything on a dangling pointer in C
[16:26] <larsu> the fact that this didn't crash before can only have been a happy accident
[16:26] <seb128> larsu, :-(
[16:26] <seb128> larsu, I know, but an handy one, we have segfault at every corner
[16:27] <seb128> larsu, do you know if g_clear_object() is smart enough to do obj = NULL only when ref = 0?
[16:27] <larsu> seb128: yes it is (in fact, I was just about to propose that)
[16:28] <seb128> larsu, notify-osd as objects that are refed > 1 so I can't replace g_object_unref by...
[16:28] <seb128> oh I can
[16:28] <seb128> *great*
[16:28] <seb128> as->has
[16:28] <larsu> seb128: don't forget dereferencing the object when passing it in: g_clear_object (&object)
[16:28] <larsu> it will automatically set the pointer to NULL for you
[16:28] <seb128> larsu, but only if ref = 0 right?
[16:29] <larsu> no, always
[16:29] <seb128> larsu, if object has a ref of 2 it will just unref?
[16:29] <seb128> larsu, that was my question ... so I can't use it :-(
[16:29] <larsu> hm I don't understand
[16:29] <larsu> if you're done with the object, you don't want a pointer to it anymore, right?
[16:30] <seb128> I'm not done
[16:30] <larsu> because it might or might not be freed in the unref (depending on whether anyone else has a ref)
[16:30] <seb128> I might just drop one of ref
[16:30] <seb128> larsu, if ref = 2 and I call unref I'm not done
[16:30] <seb128> I'm just getting one step closer from being done
[16:30] <seb128> in which case I don't want to loose my pointer
[16:30] <Laney> the call site is done with it
[16:30] <desrt> seb128: you're kidding, right? :)
[16:31] <desrt> about: 12:22 < seb128> larsu, desrt: do you know about new glib segfault when you try to so IS_OBJECT(obj) on a unrefed  object? is that a feature (it used to not segfault)? can we get it back to be robust against those? ;-)
[16:31] <chrisccoulson> seb128, surely you should only call unref once you're done?
[16:31] <seb128> desrt, I wish, I got 3 people pinging me about new segfault in saucy today because of that
[16:31] <desrt> seb128: ya.... so i have a solution for this problem in the future
[16:31] <larsu> seb128: it sounds like that code is doing something wrong. Can you point me to the code that is causing trouble?
[16:31] <seb128> chrisccoulson, what if you call _ref twice?
[16:31] <desrt> we make criticals more visible :)
[16:31] <larsu> haha
[16:32] <seb128> larsu, https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/1189281 read my comment at the bottom
[16:32] <ubot2`> Ubuntu bug 1189281 in notify-osd (Ubuntu) "notify-osd sefaults in bubble_get_id() trying to access an unrefed object" [High,Confirmed]
[16:32] <larsu> seb128: don't call ref twice on the same pointer variable, that's bad form
[16:32] <Laney> open nautilus, click trash, close nautilus
[16:32] <Laney> that's an easy one to reproduce
[16:32] <desrt> but seriously.... obviously doing _anything_ with a pointer to a gobject after you call unref() the last time (thus freeing it!) is totally and utterly undefined
[16:32] <desrt> and always has been
[16:32] <seb128> larsu, I might just not understand what notify-osd is doing well, that code is a bit of a mess :/
[16:33] <desrt> just because it sometimes works to access memory after you free() it doesn't mean that you should rely on this behaviour
[16:33] <seb128> right, I'm not arguing you should
[16:34] <seb128> it would be easier if g_object_unref(obj) was just setting obj = NULL when ref = 0, so if(obj) in follow code would work :p
[16:34] <desrt> anyway.... in theory nothing changed about unref() at all
[16:34] <desrt> it's just that memory is aligned differently now... so that things that randomly used to work no longer will work
[16:34] <desrt> probably some new things that didn't used to work now randomly _will_ work :p
[16:34] <desrt> (but in any case, you should never rely on these things)
[16:35] <desrt> seb128: well... this is not possible in C
[16:35] <seb128> desrt, well, point is that we have a bunch of segfaults showing up since glib is getting less tolerant
[16:35] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/move_ofono_to_head/+merge/167344 <- this is all that is left to do, besides re-enabling dee-qt for daily_release
[16:35] <desrt> seb128: it didn't get less tolerant
[16:35] <desrt> just different
[16:35] <seb128> well, end result is less tolerance in practice
[16:35] <desrt> it's like if you take the train for a year and you notice that the ticket inspectors only come on tuesdays
[16:35] <seb128> it segfault where it was hitting warnings
[16:35] <desrt> so you learn that you can avoid paying for the train on days that are not tuesdays
[16:36] <desrt> then one day they change the schedule and start checking on fridays instead of tuesdays
[16:37] <desrt> this is effectively what happened....
[16:37] <seb128> well, when it has been 25 years this way people who don't read the written guide might thing what they do is the rule :p
[16:37] <desrt> so we had all of these fridays-bugs that were slipping through the cracks and are now being caught
[16:37] <seb128> I'm not arguing anyway
[16:37] <desrt> but the good news is that we can now have tuesday-bugs that nobody will notice
[16:37] <seb128> just saying we have a bunch of segfaults to fix that started showing up (rightly)
[16:37] <desrt> :p
[16:37] <seb128> like
 open nautilus, click trash, close nautilus
[16:37] <seb128> -> segfaul
[16:37] <desrt> fwiw, if people valgrinded their programs to begin with, this would not have been an issue in the first place
[16:38] <desrt> (nautilus:16000): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer
[16:38] <desrt> (nautilus:16000): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
[16:38] <desrt> yup....
[16:38] <seb128> https://git.gnome.org/browse/nautilus/commit/src/nautilus-trash-bar.c?id=3d278607782dffa724d91680f4278273583e3962
[16:38] <seb128> that's the fix I guess
[16:38]  * seb128 tries
[16:38] <Laney> already trying it
[16:39] <seb128> Laney, ok, I let it to you then ;-)
[16:39] <Laney> glad for the change after WTFing at qml for a while
[16:39] <seb128> the notify-osd one is more annoying
[16:39] <seb128> since the ref goes over 1 for those objects
[16:39] <seb128> I can't simply null after unref
[16:40] <larsu> seb128: that won't help you anyways, 'bubble' is a local variable
[16:40] <desrt> ==16198== Invalid read of size 8
[16:40] <desrt> ==16198==    at 0x3A4E03147D: g_type_check_instance (in /usr/lib64/libgobject-2.0.so.0.3600.2)
[16:40] <desrt> ==16198==    by 0x3A4E01ECD2: g_signal_handler_disconnect (in /usr/lib64/libgobject-2.0.so.0.3600.2)
[16:40] <desrt> ==16198==    by 0x462400: ??? (in /usr/bin/nautilus)
[16:40] <desrt> ==16198==    by 0x3A4E0154C0: g_object_run_dispose (in /usr/lib64/libgobject-2.0.so.0.3600.2)
[16:40] <desrt> says valgrind....
[16:41] <seb128> desrt, of course, it's an use after free ... as said I'm not arguing they are error
[16:41] <seb128> but for some reasons that was not causing straight segfault in raring
[16:41] <seb128> so we didn't notice them
[16:41] <desrt> indeed
[16:41] <seb128> but anyway, let's just fix those
[16:41] <desrt> seb128: this is why i've been arguing for more aggressively criticals for a long time...
[16:41] <desrt> because....
[16:41] <desrt> (nautilus:16198): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
[16:42] <desrt> if we paid attention to criticals, this bug would have been fixed as soon as it was introduced
[16:42] <seb128> desrt, I'm glad that you guys are working on reporting those without hitting users with abort()
[16:42] <desrt> but instead, it went unnoticed for years and then suddenly crashed due to an unrelated change
[16:43] <desrt> seb128: so i guess to address your primary underlying concern: 'hopefully this sort of thing will be less of an issue in the future'
[16:43] <desrt> but for now ya... we just gotta fix our stuff :/
[16:43] <seb128> desrt, yep
[16:43] <Laney> I lost track of why we haven't gone for nautilus 3.8 btw (where this would have been fixed, along with "various memory bugs" reported in the same one that this one was)
[16:43] <mhr3> ...or revert glib :)
[16:44] <desrt> mhr3: so that we can continue to ignore bugs in other packages? :)
[16:44] <seb128> Laney, mostly "Unity/Compiz really needs to handle drawing the desktop itself (when Nautilus doesn't)"
[16:44] <Laney> oh yeah, that stuff
[16:44] <desrt> didn't cosimo have some plan for splitting out the background handling stuff in a nice way for us?
[16:44] <seb128> desrt, well, they sort of did
[16:44] <desrt> or is this about the rgba root window thing?
[16:44] <jbicha> Laney: also bug 1130746
[16:44] <ubot2`> Launchpad bug 1130746 in nautilus (Ubuntu) "Update to nautilus 3.7.90" [Wishlist,Confirmed] https://launchpad.net/bugs/1130746
[16:45] <seb128> the rgba
[16:45] <desrt> right
[16:45]  * desrt is shocked that compiz still doesn't deal with this....
[16:45] <seb128> they kept the background drawing for the new fallback mode
[16:45] <mhr3> desrt, yep :) i like what you're doing here - making devs actually pay attention to ref counting issues, but in this case you just made all the apps that have an issue with it crash, and i'm not sure that's a nice thing to do
[16:45] <desrt> fwiw, i guess nautilus desktop drawing will be around for a while
[16:45] <seb128> yes, as long as the "classic" mode of gnome-shell is around I guess
[16:45] <desrt> mhr3: i didn't do it on purpose.... i did the equivalent of changing an algorithm in malloc()
[16:46] <mhr3> desrt, i know, you shuffled the structs around...
[16:46] <desrt> seb128: the classic stuff is pretty nicely done... i think they'll want to keep it for a while
[16:46] <larsu> seb128: you can't solve the notify-osd problem with setting bubble in stack_layout to NULL, because that's a different variable
[16:46]  * desrt tried it in f19 for a while
[16:46] <larsu> seb128: what you need is to g_object_ref(bubble) in stack_notify_handler (and the corresponding unref at the end)
[16:47] <chrisccoulson> yeah, i was just about to say, it sounds like the caller of stack_layout needs to hold a ref
[16:47] <larsu> seb128: so that in case the stack_layout unrefs it, you can still access it
[16:47] <larsu> seb128: that's a bit ugly, but the best I can come up with in that architecture
[16:48] <seb128> larsu, want to provide a patch or merge request? I'm mostly looking at it because MacSlow isn't and I want the segfault fixed but I've nfc about that code, out of that it does has very weird memory handling
[16:48] <larsu> seb128: nfc?
[16:48] <Laney> no fine clue
[16:48] <larsu> interesting, thanks Laney
[16:48] <Laney> or something ...
[16:48] <Laney> like...that...
[16:49] <larsu> seb128: I can do it. Do you have a way to reproduce this easily?
[16:49] <seb128> larsu, put something full screen and send a notification, I do it with f11 and "sleep 3; notify-send "bug""
[16:50] <seb128> larsu, thanks ;-)
[16:50] <larsu> seb128: thanks, will fix it after lunch
[16:50] <seb128> larsu: danke
[16:51] <larsu> de rien
[16:51] <seb128> larsu: I'm assigning you the bug ;-)
[16:51] <seb128> jbicha, "19_unity_open_location_xid.patch: Disabled, needs refactoring
[16:51] <seb128>   - What is the purpose of this patch" ...
[16:51] <seb128> did you check with Trevinho?
[16:53] <jbicha> Trevinho: ^
[16:53] <jbicha> seb128: now I have :)
[16:53] <seb128> hehe
[16:55] <Laney> yeah, that seems to fix it
[16:55] <Laney> i'll upload that
[16:56] <Laney> kenvandine: btw, looks like you forgot to push your second e-d-s upload
[16:56] <Laney> also, are those forwarded?
[16:57] <seb128> Laney, thanks
[16:57] <seb128> Laney, did you see that there is a mr to fix uoa not being listed?
[16:57] <Laney> no
[16:58] <Laney> does it add a desktop file?
[16:58] <Laney> can't see it
[17:01] <seb128> Laney, let me check where I saw it, it was this morning in my backlog
[17:01] <seb128> I don't find it in my emails, could have been sponsoring page or top of version...
[17:01]  * seb128 checks those
[17:01] <Laney> yes, linked from versions
[17:03] <seb128> versions for the win ;-)
[17:05] <Laney> jbicha: sorry, didn't get to vala - will do tomorrow
[17:06] <attente> jbicha, which bzr branches are the g-s-d and g-c-c of the gnome3 staging ppa based on?
[17:15] <jbicha> attente: we weren't using bzr branches :( but please use https://code.launchpad.net/~gnome3-team/gnome-control-center/ubuntu and https://code.launchpad.net/~gnome3-team/gnome-settings-daemon/ubuntu now
[17:15] <jbicha> darkxst: ricotz: ^
[17:16] <attente> jbicha, thanks
[17:16] <jbicha> attente: you don't need write access yet, right?
[17:17] <attente> jbicha, no, i can push it to a separate ppa
[17:28] <Trevinho> jbicha: about that patch, I need that for correctly and fully implementing the matching of devices and nautilus windows...
[17:30] <jbicha> Trevinho: when you get a chance, can you update your patch against nautilus 3.8? there's a branch attached to bug 1130746
[17:30] <ubot2`> Launchpad bug 1130746 in nautilus (Ubuntu) "Update to nautilus 3.8" [Wishlist,Confirmed] https://launchpad.net/bugs/1130746
[17:30] <kenvandine> Laney, oh yeah.. and yes it has already been merged upstream
[17:32] <kenvandine> Laney, pushed
[17:34] <rickspencer3> is anyone else seeing U1 sync daemon, bootchart, and apt-check going crazy in saucy?
[17:34] <rickspencer3> when I boot up these 3 processes take over my netbook
[17:35] <kenvandine> rickspencer3, not me
[17:36] <seb128> not me either
[17:36] <rickspencer3> weird
[17:36] <rickspencer3> seb128, why would bootchart even run?
[17:36] <seb128> because it's installed and run at boot?
[17:36] <seb128> that's its purposed, run at boot so it can chart the system start
[17:37] <kenvandine> sounds like it never sees that the boot is complete
[17:37] <seb128> does it keep running for ever?
[17:37] <seb128> it should stop after some minutes
[18:57] <Laney> rockin'
[18:58] <seb128> Laney, ?
[18:59] <Laney> seb128: @ ken ;-)
[18:59] <seb128> oh, k ;-)