[00:00] <robert_ancell> desrt, oh, putting a warning into it
[00:00] <robert_ancell> desrt, I can do that today
[00:04] <chrisccoulson> is jasoncwarner_ moonlighting? https://twitter.com/#!/jasoncwarner/status/190589693774147584
[00:05] <desrt> robert_ancell: docs updated
[00:05] <robert_ancell> desrt, yay \o/
[00:05] <robert_ancell> chrisccoulson, hah! owned
[00:05] <desrt> robert_ancell: i appreciate your help on my quest to have "ca.desrt" be the first item in everyone's dconf-editor!
[00:06] <robert_ancell> desrt, I'm going to register aaaa.ac and put some required Ubuntu schema into it
[00:07] <robert_ancell> actually just a .au would beat you :)
[00:07] <desrt> robert_ancell: au. seems like a rather obvious choice for you
[00:07] <desrt> indeed
[00:07] <robert_ancell> desrt, nah, two weeks and I'm outta here!
[00:07] <desrt> back to .nz?
[00:08] <robert_ancell> desrt, yup
[00:08] <desrt> nice.  christchurch?
[00:08] <robert_ancell> desrt, Auckland
[00:09] <desrt> seems a bit less exciting, but still nice :)
[00:18] <chrisccoulson> hmmm, i guess i'm going to have to set up a KVM instance with oneiric on it
[00:19] <lifeless> robert_ancell: you're from nz originally ?
[00:20] <robert_ancell> lifeless, yup, chch
[00:20] <lifeless> robert_ancell: TIL
[00:42] <RAOF> robert_ancell: Good morning!
[00:42] <robert_ancell> RAOF, hello
[00:43] <RAOF> Thinking about wayland experiments for 12.10?
[00:43] <robert_ancell> RAOF, yup, not sure if it has to be wayland but just general improvements there
[00:43] <robert_ancell> RAOF, what time is good for a chat?
[00:44] <RAOF> In an hour or so should be good.
[00:44] <RAOF> I'll have finished breakfast, etc :)
[00:44] <robert_ancell> RAOF, ok
[01:19] <RAOF> robert_ancell: So, how would you like to call?
[01:20] <RAOF> slash chat.
[01:26] <robert_ancell> RAOF, google?
[04:59] <pitti> Good morning
[05:07] <bkerensa> hi pitti
[05:17] <didrocks> good morning
[05:57] <pitti> robert_ancell: is there anything further to be done on bug 844044?
[05:57] <ubot2> Launchpad bug 844044 in unity-greeter "Unity Greeter - Add Network Login option" [High,Confirmed] https://launchpad.net/bugs/844044
[05:57] <pitti> robert_ancell: it's marked for precise
[05:57] <pitti> robert_ancell: is that going to stay a manually enabled admin option, or on again by default?
[05:58] <robert_ancell> pitti, it's manually enabled currently, but I still don't really know what design wants
[05:58] <robert_ancell> pitti, perhaps we should just close it and let a new issue be opened if the current solution is not working well
[05:58] <pitti> robert_ancell: yes, it seems the current implementation matches the description
[05:59] <pitti> and the title, too
[05:59] <pitti> robert_ancell: ok, please close then
[06:00] <pitti> robert_ancell: can you reproduce bug 870297?
[06:00] <ubot2> Launchpad bug 870297 in lightdm "Lightdm logins not being logged in wtmp" [High,Confirmed] https://launchpad.net/bugs/870297
[06:00] <robert_ancell> pitti, no, but others seem to be able to
[06:00] <pitti> it's working fine here
[06:00] <pitti> I'll drop the milestone, seems SRUable to me
[06:01] <robert_ancell> yeah, if anyone can work out what's going on
[06:03] <pitti> TheMuso: we can remove the at-spi source now, right?
[06:04] <TheMuso> pitti: I think so, yes.
[06:04] <pitti> -- precise/universe build deps on libatspi-dev:
[06:04] <pitti> gnome-mag
[06:04] <pitti> java-access-bridge
[06:04] <pitti> pyspi
[06:04] <pitti> TheMuso: oh argh, seems not :/
[06:05] <TheMuso> Yeah just double checking myself and saw those.
[06:05] <pitti> TheMuso: or could these be removed along?
[06:05] <pitti> TheMuso: binary depends look better
[06:05] <pitti> -- precise/universe i386 deps on libatspi1.0-0:
[06:05] <pitti> gnome-mag
[06:05] <pitti> python-at-spi
[06:05] <pitti> python-at-spi-dbg
[06:05] <pitti> python-at-spi is itself transitional now, isn't it?
[06:05] <pitti> ah no, that was python-pyatspi
[06:05] <pitti> this is from pyspi
[06:05] <TheMuso> No, thats different. Python-at-spi is some old old bindings that weren't even used in the latter at-spi v1 days.
[06:06] <pitti> pyspi can certainly go, too
[06:06] <TheMuso> at-spi source package builds python-pyatspi binary, which was used.
[06:06] <pitti> dogtail needs pyspi, meh
[06:06] <TheMuso> And yes, gnome-mag and java-access-bridge could be kicked too.
[06:07] <pitti> TheMuso: hm, at this point we need a removal bug to keep track, I think
[06:07] <TheMuso> Yeah.
[06:09] <pitti> RAOF: any idea about bug 827934 ?
[06:09] <ubot2> Launchpad bug 827934 in colord "colord crashed with SIGABRT in raise()" [High,Confirmed] https://launchpad.net/bugs/827934
[06:12] <RAOF> pitti: I looked into it, but didn't make a whole lot of headwind before being pulled away; it seemed to be associated with some other libdbus madness, but I couldn't see anything obvious.
[06:17] <robert_ancell> pitti, so for bug 949782 that would have to be SRU'd as well - do we drop the precise target?
[06:17] <ubot2> Launchpad bug 949782 in unity-greeter "No way to disable start-up sound" [Medium,Triaged] https://launchpad.net/bugs/949782
[06:17] <pitti> robert_ancell: you don't want to upload it to precise final?
[06:18] <robert_ancell> pitti, aren't we past final freeze?
[06:18] <pitti> robert_ancell: it doesn't change UI, it's just a config option, no?
[06:18] <robert_ancell> yes
[06:18] <pitti> robert_ancell: yes, but that just means we are cautious when reviewing patches
[06:18] <robert_ancell> pitti, oh, a "final" freeze :)
[06:18] <robert_ancell> ok, I'll upload it now
[06:18] <pitti> robert_ancell: today is the day when we originally meant to freeze the archive
[06:18] <pitti> but skaet wanted to do it a week earlier, for extra caution
[06:19] <pitti> robert_ancell: freeze == "all uploads are cross-checked by release team", not "nothing can go in any more"
[06:19] <pitti> in the latter case, we could just release :)
[06:19] <robert_ancell> ok
[06:20] <pitti> robert_ancell: hang on
[06:20] <pitti> robert_ancell: do you actually need the canberra context if this option is off?
[06:20] <robert_ancell> pitti, what happened to -proposed?  I'm confused now, should I put things in precise-proposed or precise?
[06:20] <robert_ancell> pitti, I guess not
[06:20] <pitti> robert_ancell: you can use -proposed if the package takes long to build or archive skew causes uninstallability
[06:20] <pitti> neither seems to be the case here, though
[06:39] <pitti> robert_ancell: question for you in bug 980532
[06:39] <ubot2> Launchpad bug 980532 in shotwell "Build with unity support" [Wishlist,Triaged] https://launchpad.net/bugs/980532
[06:40] <robert_ancell> pitti, yup
[07:44] <czajkowski> morning folks
[07:45] <czajkowski> 2 weeks to release and latest updates have left me with no dekstop on boot up, great start to the day  :(
[07:46] <chrisccoulson> good morning everyone
[07:48] <czajkowski> chrisccoulson: nothing good about this morning :(
[07:50] <seb128> hey
[07:50] <czajkowski> has anyone done updates yesterday and run into issues this morning
[07:50] <seb128> hey czajkowski, what sort of issues?
[07:50] <czajkowski> doing updates now again hoping I can get desktop back
[07:51] <czajkowski> seb128: machine boots up, login screen arrives, enter password, and it logsin in
[07:51] <chrisccoulson> hey seb128, czajkowski
[07:51] <seb128> did you do partial upgrades using proposed?
[07:51] <czajkowski> am then stuck looking at the wallpaper
[07:51] <seb128> hey chrisccoulson, how are you?
[07:51] <czajkowski> the  dasher and stuff doesnt load
[07:52] <czajkowski> update and dist-upgrade are being run now
[07:52] <chrisccoulson> seb128, yeah, not too bad thanks. had a bit of a panic last night though when i saw https://bugzilla.mozilla.org/show_bug.cgi?id=744847
[07:52] <ubot2> Mozilla bug 744847 in XPCOM "crash in nsAppShell::ProcessNextNativeEvent @ g_main_context_. with Linux kernel 3.0.0-18 on Ubuntu 11.10" [Critical,New: ]
[07:52] <chrisccoulson> huge spike in firefox crash volume for people on oneiric ;)
[07:53] <chrisccoulson> caused by us
[07:53] <seb128> czajkowski, dpkg -l | grep unity? did you uninstall unity by upgrading at a bad time with proposed enabled?
[07:53] <seb128> oh, gookd robert_ancell did the shotwell change, now I just have to convince pitti to ack the upload ;-)
[07:53] <seb128> czajkowski, see what I wrote before
[07:54] <seb128> chrisccoulson, what did you do to oneiric users?! ;-)
[07:54] <chrisccoulson> seb128, we uploaded a broken kernel to proposed which caused applications to crash
[07:54] <seb128> oh, kernel issue?
[07:54] <seb128> "nice"
[07:55] <chrisccoulson> yeah, they got over 2000 crash reports from the same 2 signatures since 2nd april
[07:56] <czajkowski> seb128: unity still there
[07:56] <seb128> czajkowski, can you pastebin your .xsession-errors?
[07:56] <seb128> chrisccoulson, is that a lot of them?
[07:56] <czajkowski> seb128: if you can tell me how sure :(
[07:56] <seb128> chrisccoulson, I'm surprised so many people run proposed, did that kernel hit upgrades?
[07:57] <chrisccoulson> seb128, it's a lot for linux. the 2 signatures are the #1 and #4 top crashes for all linux users
[07:57] <seb128> czajkowski, try to log in, when you get the empty background, ctrl-alt-f1, log in, cp .xsession-errors <somewhere> where somewhere is an usb stick or something
[07:58] <seb128> czajkowski, or somewhere is another dir, then sudo restart lightdm and log into a non unity session if you have one installed
[07:58] <czajkowski> dont have non unity installed
[08:02] <czajkowski> seb128: just waiting on upgrades to finsish than shall resrtart lightdm
[08:02] <czajkowski> thanks for the help
[08:05] <chrisccoulson> yay, we get a nice shiny new hire car today :)
[08:06] <czajkowski> seb128: after updates and reboot still stuck at login same when I restart the lighdm
[08:06] <czajkowski> *lightdm
[08:08] <seb128> chrisccoulson, new owned car or replacement ranted while you get yours fixed?
[08:08] <chrisccoulson> seb128, yeah, it's just whilst my car is repaired
[08:14] <seb128> czajkowski, can you get the log?
[08:14] <czajkowski> attempting to find a usb key to get it off machine to mail you
[08:14] <czajkowski> but at my folks house so trying to find this could be interesting
[08:15] <seb128> czajkowski, can you scp to chinstrap maybe?
[08:16] <seb128> czajkowski, i.e log to the vt and scp .xsession-errors chinstrap.canonical.com:
[08:18] <czajkowski> will try
[08:23] <bkerensa> seb128: are you available to review a merge proposal? :)
[08:23] <seb128> bkerensa, depends of what is to review?
[08:24] <bkerensa> seb128: change to the Landscape name in System Settings
[08:24] <bkerensa> to make it more precise and less vague
[08:24] <seb128> bkerensa, where is the diff?
[08:25] <bkerensa> seb128: https://code.launchpad.net/~bkerensa/ubuntu/precise/landscape-client/fix-for-962974/+merge/101839/+preview-diff/+files/preview.diff
[08:25] <seb128> oh
[08:25] <seb128> bkerensa, no way
[08:25] <bkerensa> ;p
[08:25] <seb128> bkerensa, string freeze was 3 weeks ago
[08:26] <bkerensa> seb128: we need a exception right and thats not happening?
[08:26] <seb128> we can't change it that late
[08:26] <seb128> bkerensa, correct
[08:26] <seb128> you would break all translations
[08:26] <bkerensa> seb128: yeah
[08:26] <seb128> mpt, ^
[08:27] <bkerensa> :P
[08:27] <seb128> (I saw you discussed it on #ubuntu-devel)
[08:55] <pitti> hey seb128
[08:55] <pitti> seb128_: shotwell> I'm mostly concerned about how much this has been tested
[08:56] <pitti> i. e. new crashers, regressions, UI weirdnesses, etc.
[08:56] <seb128_> pitti, hey
[08:57] <seb128_> pitti, it was on until yesterday
[08:57] <seb128_> oh, no, we lacked the build-depends
[08:57] <seb128_> pitti, well, that's the whole code: http://git.yorba.org/cgit.cgi/shotwell/commit/src/UnityProgressBar.vala?id=6199368a3b913c7ecc9d4664c96fc9d58b7fa337
[08:57] <seb128_> pitti, it's really a small enough function to display a progress bar over the launcher icon
[08:58] <pitti> ah, for imports?
[08:58] <seb128_> pitti, yes
[08:59] <pitti> seb128_: thanks for the pointer. updated bug, accepting
[08:59] <seb128_> pitti, the yorba guys have some rigourous testing as well usually, we have very few important issues with shotwell
[08:59] <seb128_> pitti, thanks
[09:00] <seb128_> brb, picking "suspend" rather than "log out" in my guest session screwed my IRC
[09:00] <seb128_> it won't reconnect to some servers
[09:03] <mvo> seb128, pitti: I put a possible "fix" for #938090 into the report, but its a feable attempt, I get hit by this in software-center too, so ideas are welcome
[09:05] <seb128> bug #938090
[09:05] <ubot2> Launchpad bug 938090 in apport "apport-gtk crashed with SIGSEGV in _gtk_icon_helper_get_storage_type()" [Medium,Confirmed] https://launchpad.net/bugs/938090
[09:05] <seb128> mvo, hey, wie gehts?
[09:05] <pitti> mvo: hallo! looking
[09:06] <seb128> mvo, oh, I remember we discussed that issue earlier in the cycle
[09:06] <pitti> mvo: oh, can you reproduce this crash?
[09:07] <mvo> seb128: hey, danke, gut!
[09:07] <mvo> pitti: well, not entirely easily, but sort of, is-cneeds to get closed at exactly the right time
[09:07] <mvo> s-c I mean
[09:08] <seb128> mvo, that's bug #911619 back right?
[09:08] <ubot2> Launchpad bug 911619 in gwibber "gwibber crashed with SIGSEGV in _gtk_icon_helper_get_storage_type()" [High,Fix released] https://launchpad.net/bugs/911619
[09:11] <mvo> yeah, I think so
[09:11] <seb128> mvo, bug #914393 quite some duplicates for s-c
[09:11] <ubot2> Launchpad bug 914393 in software-center "software-center crashed with SIGSEGV in _gtk_icon_helper_get_storage_type()" [Medium,Confirmed] https://launchpad.net/bugs/914393
[09:13] <seb128> pitti, mvo: well, it's probably a "use after unref" issue
[09:25] <pitti> mvo: I think I can reproduce
[09:25] <pitti> mvo: I think I can turn that into a test case in apport
[09:26] <mvo> pitti: woah, thats great, looking forward to see that
[09:26] <pitti> mvo: assuming it's related to the spinner (i also have that in apport)
[09:27] <mvo> yeah, in s-c as well
[09:28] <pitti> hm, doesn't seem to be reproducible in apport as easily as in s-c (where I have 100% hit rate)
[09:34] <pitti> mvo: so in both cases it's from calling image.set_from_pixbuf()
[09:37] <mvo> pitti: so not the spinner, but a explict call to that? is it happening on close for you as well? or is that unreleated?
[09:37] <pitti> mvo: I can reproduce the software-center crash, but not the one in apport
[09:37] <pitti> mvo: I'm currently trying to make it crash around that call
[09:41] <seb128> dpm, hey
[09:42] <dpm> heya seb128
[09:42] <seb128> dpm, how are you?
[09:43] <mvo> pitti: I found that in s-c its crashin in _update_app_icon() and there in self.icon.set_from_pixbuf() and it appears its happening when Gtk.main_quit() is called or while its processing outstanding events, looking further now
[09:43] <dpm> seb128, fine, thanks, and you? How are the final days of release going?
[09:43] <pitti> mvo: right, I suspect something like taht
[09:43] <pitti> mvo: in the apport trace I see an event handling for the "reopen" button, which closes apport
[09:43] <seb128> dpm, I'm good thanks, release seems on track ;-)
[09:43] <dpm> ;-)
[09:43] <seb128> dpm, do you have any clue about bug #978724
[09:43] <ubot2> Launchpad bug 978724 in ubuntu-translations "update-notifier needs to build translation template" [High,Triaged] https://launchpad.net/bugs/978724
[09:44] <pitti> mvo: but the icon is set way before that reopen button is even displayed, so I'm currently trying to figure out how this can happen
[09:44] <seb128> dpm, update-notifier ships a po/update-notifier.pot in source but it's not being imported by launchpad
[09:44] <seb128> dpm, do you know how to debug those issues?
[09:44] <mvo> pitti: it looks like I could work around it in s-c by simply calling sys.exit(0) after main_quit
[09:44] <seb128> dpm, the template was manually uploaded yesterday but the previous one was from 2011 still, the infos on https://translations.launchpad.net/ubuntu/precise/+source/update-notifier/+pots/update-notifier/+admin look fine though
[09:45] <pitti> mvo: yes, I'll do something similar, as otherwise the apport process hangs until all the other threads are done
[09:45] <seb128> dpm, is there anything special about sources that are not stripped from their translations maybe?
[09:45] <pitti> mvo: that'll fix the behaviour, but I'd still like to find out why this crashes
[09:45] <mvo> pitti: indeed, its just a workaround
[09:45] <pitti> good 'nuff, though
[09:45] <dpm> seb128, ah, I saw Steve's reply, but didn't look further. To debug these issues I generally build the package locally and look at the translations tarball (https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/RecipeVerifyingTranslationUploads) Let me have another look at the bug
[09:45] <seb128> mvo, pitti: the issue is not likely when the icon is "set", but rather when it's unrefed
[09:46] <seb128> dpm, thanks
[09:46] <pitti> seb128: really? https://launchpadlibrarian.net/89523197/Stacktrace.txt doesn't look like that
[09:46] <seb128> pitti, why is gtk_image_reset() called?
[09:46] <mvo> is there a way to get the refcount of it easily via pygi?
[09:46] <dpm> seb128, yeah now the https://translations.launchpad.net/ubuntu/precise/+source/update-notifier/+pots/update-notifier/+admin will look ok, as kelemengabor manually uploaded the template
[09:47] <pitti> seb128: not sure, GTK does that by itself; apport just calls gtk_image_set_from_pixbuf
[09:47] <pitti> mvo: myobject.__grefcount__
[09:47] <seb128> dpm, it was looking ok before as well, out of the import date
[09:47] <dpm> ah, I see
[09:47] <mvo> ta
[09:49] <seb128> pitti, mvo: http://pastebin.ubuntu.com/927656/ that was part of the discussion about that issue in gwibber earlier in the cycle if that's useful
[09:54] <seb128> dpm, so yeah, following that wiki, pkgbinarymangler doesn't create a _translations.tar.gz for packages on the "don't strip" list
[09:54] <dpm> seb128, I believe I see what happens: as u-n is being blacklisted in pkgbinarymangler, the package does not generate a translations tarball, so neither a .pot file generated during build (which is not created anyway) nor the .pot file included into the package are put in a translations tarball and given to Launchpad. pitti, does that sound about right for a package blacklisted in pkgbinarymangler? As much as I dislike keeping track of templates needin
[09:54] <dpm> g manual attention, one option is to manually upload the template
[09:54] <dpm> yeah, we got to the same conclusion :)
[09:54] <seb128> so pkgbinarymangler bug indeed
[09:55] <seb128> the "don't strip" doesn't mean "don't import"
[09:55] <dpm> ah, right
[09:55] <seb128> it just means "don't clean the binaries"
[09:55] <dpm> gotcha
[09:55] <seb128> dpm, thank for the wiki pointer, I learnt something
[09:55] <dpm> cool :)
[09:55] <pitti> dpm: the .pot generation should not be affected by this, only the stripping and translation tar build
[09:55] <dpm> ack
[09:56] <seb128> pitti, where is launchpad importing the pot from?
[09:56] <pitti> from the tarball
[09:56] <seb128> pitti, if there is no translation tar there is no import?
[09:56] <pitti> so I guess it should not be blacklisted, but u-m should instead set NO_PKG_MANGLE?
[09:56] <pitti> so that the tarball is still being built
[09:56] <seb128> pitti, what's the blacklist for then?
[09:57] <pitti> pkgbinarymangler will not touch blacklisted packages _at all_
[09:57] <seb128> that's the issue there
[09:57] <pitti> i. e. for packages which just don't want to use LP transltaions and langpacks
[09:57] <pitti> like language-pack* itself, dpkg, iso-codes, and apparently also apt and update-notifier
[09:57] <seb128> pitti, language-selector and update-notifier should probably be dropped from there then and just use NO_PKG_MANGLE?
[09:58] <pitti> yes
[09:58] <seb128> thanks
[09:58] <pitti> bug 562900
[09:58] <ubot2> Launchpad bug 562900 in update-notifier "Please include translations from Launchpad in the package" [Medium,Confirmed] https://launchpad.net/bugs/562900
[09:58] <dpm> Sweetshark, good morning! A translator pointed out to me that Quicklist items in LO are all in English. I haven't followed that, but he told me that at some point the translations were included in a patch, but dropped later on and the recommendation was to translate them upstream. While that's fair enough, my understanding is that upstream hasn't got any infrastructure to deal with quicklist translations, so there is no way translators can provide the
[09:58] <dpm> m.
[09:59] <dpm> So we end up with a regression: previously translated strings are now in English
[09:59] <seb128> pitti, why did you do it this way by then rather than using the variable?
[09:59] <dpm> Sweetshark, would it be possible to get the translations patch back?
[09:59] <seb128> pitti, sorry for keep you away from the gtk debugging, I'm almost done with questions ;-)
[09:59] <pitti> no special reason, I just merged the proposed change
[10:00] <pitti> but we can revert that, and use NO_PKG_MANGLE, of course
[10:00] <pitti> seb128: actually
[10:00] <pitti> NO_PKG_MANGLE will also not build a translation tarball
[10:00] <seb128> pitti, what do you recommend we do? I'm not sure to understand the pro and con enough to have an opinion
[10:00] <pitti> dpm: ^
[10:01] <seb128> pitti, the issue is that ideally po and pot should still be imported for those, we want the launchpad side to be uptodate even if we don't strip
[10:01] <pitti> so we don't currently have a way to say "build a translations tarball, but don't strip the mo files"
[10:01] <seb128> ok
[10:01] <seb128> pitti, so let's keep it as a pkgbinarymangler bug open for next cycle
[10:01] <pitti> well, in a way we do
[10:02] <seb128> we need to manually upload the translations and template meanwhile
[10:02] <pitti> you can ask LP to import the pot from the branch
[10:02] <pitti> I do that with apport and jockey upstream branches, it's quite nice
[10:02] <seb128> ah
[10:02] <seb128> pitti, thanks!
[10:02] <dpm> pitti, yes, but only for the upstream project, the Ubuntu package still needs a package upload
[10:02] <pitti> so the apport blacklist and NO_PKG_MANGLE are pretty much equivalent
[10:02] <pitti> for translations, anyway
[10:02] <seb128> apport->pkgbinarymangler?
[10:02] <pitti> the former is better for packages that we sync, as it avoids a packaging delta
[10:02] <pitti> err, yes
[10:03] <seb128> ;-)
[10:03] <pitti> Freudian slip
[10:03] <seb128> dpm, well I guess we should check packages not mangled to see if other templates need an update
[10:03] <seb128> I will do that
[10:04] <dpm> pitti, seb128 in that case, perhaps we keep the templates for those two manually updated and pkgbinarymangler needs a bug requesting a new feature to import templates but not strip .mo files?
[10:04] <pitti> dpm: right
[10:04] <seb128> dpm, while you are here, could you look at bug #979825 ? do you know how,when are ddtp datas syncs done?
[10:04] <ubot2> Launchpad bug 979825 in ubuntu-translations "Do a sync with Debian for Ubuntu 12.04 LTS" [Undecided,New] https://launchpad.net/bugs/979825
[10:05] <seb128> dpm, pitti: let's reuse bug #978724 for the pkgbinarymangler, I'm updating the title
[10:05] <ubot2> Launchpad bug 978724 in ubuntu-translations "update-notifier needs to build translation template" [High,Triaged] https://launchpad.net/bugs/978724
[10:05] <dpm> seb128, that would probably be a question for mvo. I know he does ddtp syncs every now and then, but I don't know how frequently ^^
[10:05] <dpm> seb128, ack on pkgbinarymangler bug
[10:05] <mvo> pitti: I guess you know this already, but I can confirm that "destroy" is called on self.icon so the priv->icon_helper is cleared but then the icon is used again
[10:06] <mvo> dpm: meh, it turns out its currently broken because debian moved to descriptionless packages files too
[10:06] <mvo> (or we did and that broke it)
[10:06] <mvo> I need to check, but last night when I triggered a sync of it I discovered its currently not finding translations
[10:07] <dpm> bummer
[10:12] <Sweetshark> dpm: noted
[10:12] <Sweetshark> dpm: yes, should be doable.
[10:13] <mvo> pitti: I put some more info in the bug, not sure what the right approach for the fix is though, ideas very welcome
[10:13] <dpm> Sweetshark, cool, do you think it'd be worth re-enabling the old wiki page containing the translations, do a final round call for translations and including them in the patch?
[10:14] <Sweetshark> dpm: upstream basically has the infra, its just that our quicklist l10n patch is very ugly and ad-hoc (which is likely why it broke), so it can not be upstreamed as is.
[10:15] <dpm> Sweetshark, right, but we shouldn't be sacrificing translations because of that
[10:15] <Sweetshark> dpm: sure, sure.
[10:17] <dpm> Sweetshark, np, thanks. So what do you think the next steps are? Do you think it's worth doing a new round call for translations and include them in a new patch, or do you prefer just reviving the old patch even if it means having less translations?
[10:18] <pitti> mvo: heh, I just attached a python reproducer :)
[10:18] <pitti> it's by and large the same
[10:18] <mvo> pitti: I think I have a idea, give me a minute to attach a patch that may or may not work and then I go for lunch :)
[10:19] <pitti> mvo: probalby easiest to just kill all pending signal handlers, or just sys.exit()..
[10:21] <Sweetshark> dpm: as for a final round call, I am abit hesitant. While that stuff is nice to have (and the patch needs to be fixed), I am unsure if I will be able to take care of that given the other issues on my todo list.
[10:21] <Sweetshark> dpm: fwiw the patch is in, it just doesnt work :(
[10:22] <dpm> Sweetshark, I understand, that's why I suggested the second option of just reviving the patch. Does that sound doable (assuming translations still apply)?
[10:22] <dpm> ah, bummer
[10:22] <dpm> seb128, I noticed you did the xdg-user-dirs upload with exported LP translations, thanks! We keep a list of packages that need translations exported on https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline (see "Rebuilding packages" section). Would it be possible that someone from the desktop team does the exports for language-selector, example-content, update-manager, yelp-xsl and (possibly later due to recent string changes) update-notifier? Wo
[10:22] <dpm> uld it be worth filing bugs for each one of those?
[10:23] <Sweetshark> dpm: so, I will try to fix it, but it does not have first priority sorry.
[10:23] <dpm> Thanks Sweetshark, I appreciate it
[10:23] <seb128> dpm, I can do those
[10:23] <seb128> dpm, well maybe mvo can do update-manager
[10:23] <seb128> dpm, but I will look at the list and do language-selector and yelp-xsl to start
[10:24] <dpm> seb128, excellent, thanks! Going forward we should enable translations and message sharing for all of those projects, which would save us from doing the manual exports, as translations would already land in the upstream packages
[10:24] <dpm> err, upstream *projects
[10:24] <seb128> dpm, right
[10:25] <seb128> dpm, well that wouldn't work for xdg-user-dirs shared-mime-info and yelp-xsl
[10:25] <mvo> pitti, seb128: I pushed a (untested) patch to https://bugs.launchpad.net/ubuntu/+source/apport/+bug/938090/comments/10 with some background, that maybe the solution, but I have to admit that I'm not too familiar with the lifecycle of the gobject stuff, so I may be off here
[10:25] <ubot2> Launchpad bug 938090 in apport "apport-gtk crashed with SIGSEGV in _gtk_icon_helper_get_storage_type()" [Medium,Confirmed]
[10:25] <seb128> but that would be good for stuff we maintain
[10:25] <mvo> seb128: what do I need to do? just upload?
[10:25] <dpm> seb128, correct. I meant the Ubuntu projects in LP only, sorry. I'll take a TODO to poke maintainers
[10:25] <seb128> mvo, having desrt's to review it would be good if you can wait after lunch
[10:26] <seb128> mvo, that still seems a bug in your code to me though ;-)
[10:26] <seb128> mvo, like you C snipped, don't clean an object after it has been destroyed...
[10:26] <mvo> seb128: I would argue that ;) but yeah, I added code in s-c to not trigger this condition, but at the same time, robustness++ if its not having other issues that I'm not aware of
[10:26] <seb128> mvo, but yeah,I understand bindings do that for you :p
[10:27] <mvo> seb128: right, the C snippet is for demo purpose only, its cleary buggy code, the question is what should happen (segv vs g-crtitiacal)
[10:27] <mvo> pitti: aha, very nice, your python demo is much better as its much close to the real-world case and will not make seb128 complain like my C ;)
[10:28] <seb128> mvo, let's wait for desrt but your patch seems fine to me
[10:30] <mvo> thanks, I put #11 in with a diff that actually compiles and get lunch now :)
[10:30]  * mvo waves
[10:32] <pitti> mvo: ah, very nice!
[11:24] <mvo> desrt: hey, when you are back it would be great if you could have a look at https://bugs.launchpad.net/ubuntu/+source/apport/+bug/938090/comments/11 and tell me if that makes sense (and maybe the rational for in in comment #10)
[11:24] <ubot2> Launchpad bug 938090 in apport "apport-gtk crashed with SIGSEGV in _gtk_icon_helper_get_storage_type()" [Medium,Confirmed]
[11:24] <mvo> seb128: so the patch appears to fix all the known cases of this crash, fingers crossed that its actually the right approach
[12:54] <pitti> dpm: can we arrange for a full precis export next Tuesday, right after the langpack translation deadline?
[12:54] <pitti> dpm: then I can build/upload the final packs next Wed
[12:58] <dpm> pitti, I'll have to arrange a one-off export with the LP guys, but it shouldn't be a problem, yes
[12:58] <pitti> dpm: FYI, we just got another daily set of packages
[12:59] <pitti> dpm: I disabled the cronjob now
[12:59] <dpm> pitti, ok, thanks
[13:02] <desrt> mvo: one comment: if the only thing that the vfunc now does is to chain up then stop overriding it
[13:02] <desrt> mvo: also: file/patch upstream please
[13:06] <desrt> mvo: in general, though, you should be vary of releasing things in finalize instead of dispose when it comes to gtk -- reference cycles creep in this way
[13:07] <mvo> desrt: oh, so should I use dispose instead of finalize? happy to do that, I'm pretty new to this
[13:07] <desrt> mvo: no.  that would not help in this case :)
[13:07] <desrt> mvo: really -- you should not access-after-destroy :)
[13:07] <desrt> (destroy is more or less equivalent to dispose, fwiw)
[13:07] <desrt> like gtk_widget_destroy() ends up calling g_object_dispose()
[13:08] <desrt> the trouble with unref in finalize is that if the thing you are unreffing has a reference to some part of the widget tree you could end up with a reference cycle
[13:08] <desrt> in this case i believe that to be unlikely
[13:08] <desrt> the way we usually deal with this is to try to make functions depending on the now-null value to be resiliant to it being null
[13:08] <mvo> desrt: aha, thanks! it seems its mostly a issue with the bindings AIUI, I will clean it up based on your suggestion and file upstream
[13:08] <desrt> which i think is a waste of time, personally :)
[13:08]  * desrt loves finalize
[13:09] <desrt> so ya... drop the destroy() vfunc override entirely and it looks good to me -- but maybe others have different things to tell you about it
[13:10] <mvo> ok
[13:14]  * mvo wonders idly why his almost_fixed_height patch in #607447 did not even got a single reply
[13:14] <ogra_> because it has almost in the name and people wait for the final version ? :)
[13:15] <desrt> mvo: it's on my list to tackle next cycle
[13:15] <seb128> mvo, nobody is actively maintained that part of GTK I think
[13:15] <seb128> maintaining
[13:15] <seb128> desrt, hey, happy friday!
[13:15] <desrt> mvo: the answer is (a) time constraints and (b) general fear of touching anything inside gtktreeview
[13:15] <desrt> seb128: i'm starting on the beer already :D
[13:16] <desrt> seb128: happy friday to you too
[13:16] <seb128> desrt, chrisccoulson is having a bad influence on you :p
[13:16] <desrt> chrisccoulson: come visit.  we'll have beers together.
[13:16] <chrisccoulson> heh :)
[13:17] <chrisccoulson> talking of beer, my beer delivery still hasn't arrived!
[13:17] <desrt> you have beer DELIVERY?
[13:17] <desrt> my god.. what is this technology?
[13:17] <chrisccoulson> desrt, yeah, i order beers that i can't find in local shops :)
[13:18] <desrt> is it a bad situation where you are or do you just have _really_ exotic tastes? :)
[13:20] <mvo> desrt: bug #674050 in bugzilla
[13:20] <ubot2> Launchpad bug 674050 in docky "Clicking CPU Monitor applet opens web browser when gnome-system-monitor isn't installed" [Undecided,Invalid] https://launchpad.net/bugs/674050
[13:20] <desrt> ubot2: stop that.  it's too early for those kinds of games.
[13:20] <ubot2> desrt: Error: I am only a bot, please don't think I'm intelligent :)
[13:20] <pitti> gnome bug 674050
[13:20] <pitti> there :)
[13:20] <ubot2> Gnome bug 674050 in gtk "Free image->priv->icon_helper in gtk_image_finalize instead of gtk_image_destroy" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=674050
[13:20] <desrt> ubot2: you're excused :)
[13:20] <ubot2> desrt: Error: I am only a bot, please don't think I'm intelligent :)
[13:21] <desrt> ubot2: have a botsnack
[13:21] <ubot2> Factoid 'have a botsnack' not found
[13:21] <desrt> a bot that doesn't enjoy botsnacks?!
[13:21] <chrisccoulson> lol
[13:25] <mvo> haha
[13:27] <mhr3> desrt, you just dont get bot-humor, clearly he already ate it ;)
[13:27] <mhr3> that's why it's not found
[13:45] <seb128> pitti, do you have a way to update language-selector translations than to ask for an export on launchpad, cp it by hand and commit?
[13:50] <JanC> hm, is nautilus leaking memory in 12.04?
[13:54] <seb128> JanC, not that we know about, it could be, or you could use an extension leaking memory
[13:57] <JanC> yeah, might be an extension
[13:57] <JanC> but nautilus is using 4x more RAM than Firefox with around 80 tabs open, so something must be wrong...   ;)
[14:07] <JanC> about 4 GiB virt, 2 GiB res...
[14:10] <seb128> JanC, likely, a valgrind log would be useful
[14:10] <seb128> if you can reproduce the issue
[14:19] <didrocks> hey Sweetshark, seems that some quicklist were added to libroffice, but as it's not translatable, there was no wiki or transition to get them translated by another way? bug #950825
[14:19] <ubot2> Launchpad bug 950825 in libreoffice "LibreOffice quicklists are not translated" [Undecided,Confirmed] https://launchpad.net/bugs/950825
[14:19] <mvo> didrocks: do you think you have time to look at bug #977456 ?
[14:19] <ubot2> Launchpad bug 977456 in software-center "oneconf does not sync installed packages across computers" [Undecided,New] https://launchpad.net/bugs/977456
[14:19] <didrocks> mvo: there are some 500 errors on the server, I pinged achuni on it
[14:20] <didrocks> yesterday
[14:20] <didrocks> not sure he had some time to look at
[14:21] <didrocks> mvo: talking about it on #software-center FYI ;)
[14:33] <chrisccoulson> is ia32-libs meant to be installable in precise?
[14:33] <ogra_> it should be a fake package but still be installable iirc
[14:45] <pitti> seb128: I don't have a better way, no; I didn't set up l-s to auto-import/export to bzr
[14:49] <seb128> pitti, ok
[15:00] <mterry> Why when upgrading from 11.10 to 12.04 do I get prompted about which services to restart for a libc6 upgrade?  Is that really a super-important question to ask?
[15:01] <seb128> mterry, I guess the important thing is to not restart things on that list without asking
[15:01] <seb128> mterry, well maybe it's not important for a desktop but I guess there could be some side effects on running services or downtime there ... though if you dist-upgrade you might expect something like that ;-)
[15:01] <mterry> Yar, you would  :)
[15:02] <seb128> that's an ok question though :p
[15:02]  * mterry thought our goal was no questions
[15:02] <mlankhorst> surprisingly my ubuntu feisty survived several dist-upgrades without a reboot. :P
[15:02] <seb128> the natty to oneiric upgrade on my parent box asked on what disk to install grub for some reason
[15:02] <seb128> with a list of disk
[15:03] <seb128> it's the sort of question I don't even know what to reply to :p
[15:03] <seb128> "just put it somewhere so my box keep booting please" ;-)
[15:05] <mlankhorst> of course windows doesn't ask and just overwrites everything :>
[15:07] <seb128> mterry, nice gvfs anti segfault effort this week btw!
[15:07] <jbicha> mterry: you used update-manager for that upgrade?
[15:08] <jbicha> I had to use the alternate disk for an upgrade this week because of that whole webcam bug and it did prompt about restarting those services
[15:08] <mterry> seb128, thanks!  Hopefully I didn't cause any leaks with all my g_object_refs  :)
[15:08] <mterry> jbicha, yeah
[15:08] <seb128> mterry, let's see ;-)
[15:08] <seb128> mterry, did you get at the bottom of your bugs list?
[15:10] <mterry> seb128, I guess?  I'm done with gvfs for now.
[15:10] <seb128> mterry, do you own a multi screen setup? like a laptop with an external screen? ;-)
[15:39] <pitti> seb128: would you like/have some time for bug 942539, or want me to look at it on Monday?
[15:39] <ubot2> Launchpad bug 942539 in nautilus "Ubiquity desktop icon text looks messy" [Medium,Triaged] https://launchpad.net/bugs/942539
[15:39] <pitti> it's the one bug in our list that isn't SRUable
[15:40] <seb128> pitti, I've no real clue about text wrapping in pango,nautilus
[15:40] <pitti> i. e. we need to teach it to not line-break on "." unless it's followed by a space
[15:40] <seb128> pitti, I can try to have a look but I fear it's an hard issue
[15:41] <seb128> pitti, well it works fine text entries in gtk, so I fear it's a bug somewhere in the nautilus stack that is going to be "fun" to debug
[15:41] <pitti> seb128: we can try and look into it together on Monday perhaps?
[15:41] <seb128> pitti, if you want sure
[15:46] <didrocks> IIRC, that ended with the \n fix in… was it hardy?
[15:46] <didrocks> well "fix" :p
[16:13] <seb128> pitti, still there?
[16:13] <pitti> seb128: just barely, about to head out
[16:13] <seb128> pitti, about that nautilus issue
[16:14] <seb128> do you have an opinion on whether we should change the code to never wrap after a "."?
[16:14] <seb128> or just special case "12.04"?
[16:14] <seb128> the comment
[16:14] <seb128> "				/* Ensure that we allow to break after '_' or '.' characters,
[16:14] <seb128> 				 * if they are not likely to be part of a version information, to
[16:14] <seb128> 				 * not break wrapping of foobar-0.0.1.
[16:14] <seb128> 				 * Wrap before IPs and long numbers, though. */"
[16:14] <pitti> no, I think it should only wrap after '.' if it's followed by whitespace
[16:14] <seb128> makes me not want to change the wrapping rules
[16:15] <seb128> pitti, well seems they did it on purpose so stuff like http://192.168.0.10 in the computer location would displaybetter
[16:15] <pitti> seb128: 12.04 is no different, it's the same intent
[16:15] <pitti> seems the patch is slightly broken?
[16:15] <pitti> but you wouldn't want to wrap an IP address either
[16:16] <pitti> if you have a string like "foo 1.2.3. next", it should be wrapped at "foo|1.2.3.|next", but not in between IMHO
[16:16] <seb128> right
[16:16] <seb128> I will just drop the " && ZERO_OR_THREE_DIGITS (p+1)" then
[16:16] <seb128> and see how it goes
[16:16] <seb128> pitti, thanks
[16:17] <seb128> I will try to have it in today
[16:17] <seb128> so we can get feedback during the w.e if it breaks stuff :p
[16:17] <pitti> seb128: don't we rather need somethign like && isspace(p+1) ?
[16:17]  * pitti assigns the bug to you then, thanks for picking this up
[16:17] <seb128> pitti, right, I meant dropping the special rules
[16:17] <seb128> pitti, I will do the classic unicode "wrap only if followed by a space"
[16:18] <pitti> indeed, ZERO_OR_THREE_DIGITS sounds bogus
[16:18] <seb128> it's a bad hack
[16:18] <seb128> pitti, thanks
[16:18] <seb128> pitti, enjoy your w.e!
[16:18] <pitti> and you!
[16:18] <pitti> good night everyone
[16:19] <pitti> seb128: http://reports.qa.ubuntu.com/reports/bug-fixing/canonical-desktop-team-precise-fixes-report.html
[16:19] <pitti> seb128: that one and two more! :-)
[16:20] <seb128> pitti, I just uploaded transmission with 3 bug fixed
[16:20] <seb128> bugs
[16:20] <pitti> oh, and language-selector
[16:20] <pitti> I have an upload in the pipe for upower
[16:20] <seb128> pitti, you will need two on monday :p
[16:20] <pitti> so I again I'm one behind
[16:20] <seb128> ok, one
[16:20]  * seb128 hugs pitti
[16:20]  * pitti hugs you back
[16:20] <seb128> we might manage to cross the line together
[16:21]  * ogra_ grins about the ever ongoing competition
[16:21] <pitti> it's fierce!
[16:45] <pitti> seb128: btw, did you notice today's image size? http://cdimage.ubuntu.com/daily-live/20120413/
[16:46] <seb128> pitti, \o/ how did we win so much?
[16:46] <seb128> 6mb?
[16:46] <pitti> seb128: bug 979887
[16:46] <ubot2> Launchpad bug 979887 in linux-firmware "Remove some obsolete firmware to reduce package size" [Undecided,In progress] https://launchpad.net/bugs/979887
[16:46] <seb128> oh, nice
[16:47] <seb128> I didn't see that was uploaded
[16:47] <pitti> hell, another fix like that, and we can put back French!
[16:47] <seb128> great
[16:49] <seb128> mvo, you got accept commit on gtk
[16:49] <seb128> mvo, I pinged upstream on IRC
[16:50] <mvo> seb128: very nice, thanks a lot!
[16:50] <seb128> mvo, yw
[17:26] <Darxus> seb128: I'm trying to build a gtk package from the branch that doesn't require cairo-gl.  I cloned the repo, extracted the debian tarball, ran "NOCONFIGURE=1 ./autogen.sh", seems to be going along pretty well, but I'm getting "make[3]: *** No rule to make target `ubuntumenuproxy.h', needed by `gtktypebuiltins.c'.  Stop."  Any tips on how to figure this out?  This is on precise, and your precise package builds fine.
[17:28] <Darxus> Maybe better in #gtk+ ...
[17:30] <seb128> Darxus, yeah, likely :p
[17:31] <seb128> Darxus, we don't have cairo built with gl in Ubuntu
[17:31] <Darxus> seb128: Sorry, doesn't depend on cairo-gl for enabling wayland.
[17:31] <seb128> Darxus, I moved that discussion out of #gtk+
[17:31] <dobey> that error seems like a half-applied patch
[17:32] <seb128> `ubuntumenuproxy.h', is a gtk patch
[17:32] <seb128> in ubuntu
[17:32] <Darxus> seb128: I get the same error when I cat /dev/null > debian/patches/series
[17:32] <seb128> Darxus, well, patches are applied when unpacking, and that source with "ubuntu" in the name doesn't exist upstream
[17:32] <seb128> so you might want quilt pop -a
[17:32] <seb128> then try again
[17:32] <Darxus> I somehow got the impression it was actually included upstream, rechecking.
[17:33] <Darxus> $ grep -r ubuntumenuproxy.h .
[17:33] <Darxus> ./gtk/Makefile.am:      ubuntumenuproxy.h
[17:33] <Darxus> Yeah, that's in robster's branch.
[17:33] <seb128> Darxus, I can guaranty you upstream has no source with "ubuntu" in the name :p
[17:33] <seb128> Darxus, he likely started from the ubuntu version then
[17:34] <Darxus> ...Huh.
[17:36] <Darxus> Okay, you're right, it's not in gtk master.  Thanks.  WTF did he do...
[17:54] <Darxus> The problem was that I had patches applied, and inappropriately believed that git clean -xfd would remove them.
[18:04] <Darxus> seb128: The gtk package's debian/rules has a few sets of enable args, which one do I add --enable-wayland-backend to?
[18:05] <Darxus> DEB_CONFIGURE_EXTRA_FLAGS?
[18:07] <Darxus> Yeah, pretty sure that should do it.
[18:08] <Darxus> cp: cannot stat `debian/tmp/docs/reference/gtk/gtk-update-icon-cache.1': No such file or directory
[18:08] <Darxus> So close.  What is that?
[18:08] <Darxus> dh_install: cp -a debian/tmp/docs/reference/gtk/gtk-update-icon-cache.1 debian/libgtk-3-bin/usr/share/man/man1/ returned exit code 1
[18:12] <Darxus> The file actually exists in a number of other places: ./debian/install/shared/usr/share/man/man1/gtk-update-icon-cache.1
[18:14] <Darxus> That's in "dh_install -plibgtk-3-bin", which I don't think it should be, since there's a separate "dh_installman -plibgtk-3-0".
[18:19] <Laney> I think gsd needs a give-back on armel
[18:20] <Darxus> Okay, there is no debian/tmp, why is it trying to copy from there?
[18:34] <dobey> because it should be in debian/tmp. what is debian/install/shared? that's different.
[18:36] <Darxus> dobey: Don't know.
[18:36] <Darxus> So maybe earlier in the output something said that putting it in debian/tmp/docs/reference/gtk/gtk-update-icon-cache.1 failed?
[18:36] <dobey> possibly
[18:37] <dobey> but you're modifying an apparently half-broken packaging branch of gtk, also
[18:37] <Darxus> Am I?
[18:37] <dobey> well, given all the comments you've made in here, i'd say so :)
[18:38] <Darxus> I re-cloned https://github.com/rbradford/gtk/tree/wip/wayland-render-changes to fix the problem with the half-application of ubuntu patches.
[18:38] <Darxus> It builds / works fine without ubuntu packaging.
[18:38] <Darxus> And I'd guess this source is relatively close to what the packaging was written for.
[18:41] <Darxus> debian/libgtk-3-bin.install:docs/reference/gtk/gtk-update-icon-cache.1 usr/share/man/man1
[18:41] <Darxus> Oh, that's what's calling it.
[18:53] <Darxus> It's not supposed to be in debian/tmp.  The other locations are flavors the package builds.  So somehow it's not pointing dh_install at the right flavor.
[18:57] <dobey> eh?
[18:58] <dobey> the ubuntu packages build fine presumably with the packaging info you've shoved into that branch. so why would it fail now unless you changed something relevant to the failure
[19:09] <Darxus> Well, clearly I did, by replacing the source.  But I have no idea what the problem is.
[19:09] <Darxus> >  /usr/bin/install -c -m 644 gtk-query-immodules-3.0.1 gtk-update-icon-cache.1 '/home/darxus/tmp/gtk/no-cairo/gtk+-3.4.0/debian/inst
[19:09] <Darxus> all/static/usr/share/man/man1'
[19:09] <Darxus> It's not installing into debian/tmp....
[19:09] <Darxus> It's installing into debian/install/static.
[19:12] <hyperair> can a patch that grants smooth scrolling to evince enter precise at this moment?
[19:13] <kenvandine> hyperair, i wouldn't be in favor of it
[19:13] <seb128> no
[19:14] <hyperair> alright
[19:14] <hyperair> i guess i'll just maintain it locally or put it in a ppa then
[19:15] <seb128> it's likely a small patch right? like just add an event mask or enable a flag?
[19:15] <seb128> it should be fine for a SRU
[19:16] <seb128> the change is no important enough for the installer ISO to ask a freeze exception
[19:16] <seb128> but tested as a SRU for some time it should be fine
[19:19] <hyperair> seb128: yeah it's pretty small. add an event mask, amend the handling of ctrl+scroll and shift+scroll a bit
[19:19] <seb128> yeah, should be fine for a SRU
[19:19] <hyperair> okay
[19:20] <seb128> it's a LTS, it will not be perfect but we will aim at having the fixes and improvement to get in if they are safe
[19:20] <seb128> .1 is when the update will be suggested for lts to lts upgrades
[19:20]  * hyperair nods
[19:20] <hyperair> i see
[19:22] <dobey> is anyone else using firefox on precise, and now no longer able to drag tabs around, or drag links out of the firefox window?
[19:23] <seb128> dobey, not me, I use precise and firefox and I can drag tabs or the url bar icon i.e to gedit to open the webpage in gedit
[19:24] <seb128> urls as well
[19:24] <dobey> hmm
[19:24] <hyperair> gedit can open webpages now?
[19:24] <seb128> well, it opens the content
[19:25] <seb128> like gedit opens the file over http, i.e you get the source of the page
[19:25] <seb128> i.e the html
[19:25] <hyperair> hmm it looks like it tries over here but doesn't actually work out
[19:26] <seb128> try to wait a second over gedit before relaxing the dnd?
[19:26] <seb128> it took me 2 tries, so maybe a timing issue
[19:27] <seb128> i.e wait to have the border displayed around the gedit textview to show the dnd target is on
[19:27] <hyperair> yeah it does
[19:27] <hyperair> it opens a tab
[19:27] <hyperair> but shows a little x like it can't load the file
[19:27] <seb128> ok, maybe your page is hitting a gvfs bug or something
[19:27] <hyperair> the url title and url does appear in the titlebar though
[19:27] <hyperair> yeah
[19:27] <seb128> but the dnd action is working ;-)
[19:28] <hyperair> or maybe it just doesn't work with chrome..
[19:29] <hyperair> woosh. evince now zooms in and out waay too quickly
[19:29]  * hyperair needs to figure out how to translate delta_x/y into zoom factors.
[19:30] <hyperair> seb128: do you know where i could look for this?
[19:30] <seb128> hyperair, try http://git.gnome.org/browse/nautilus/commit/?id=3d275a971132a41809a3b1e5b8ac683d264d6c35
[19:30] <seb128> or equivalent
[19:30] <seb128> that's how the nautilus guys did it
[19:30] <seb128> they had the same issue
[19:30] <hyperair> that's how i did it for evince. now it zooms way too quickly
[19:31] <seb128> weird
[19:31] <seb128> do you get the issue in nautilus?
[19:31] <hyperair> well nautilus is kind of different
[19:31] <hyperair> i think nautilus has discrete zoom levels
[19:31] <hyperair> whereas evince's zoom levels are continuous
[19:31] <hyperair> e.g. with utouch/libgrip you can pinch zoom
[19:32] <seb128> check with cnd maybe?
[19:32] <hyperair> cnd: ping
[19:32] <cnd> pong
[19:32] <hyperair> http://paste.debian.net/163168/ <-- for the time being, this is what i have
[19:33] <hyperair> cnd: i'm trying to implement ctrl+smooth-scroll for evince. how should i go about translating delta_x/y into zoom levels?
[19:33] <hyperair> (evince's is on a floating point scale where 1.0 = 100%)
[19:33] <cnd> that seems like a reasonable approach
[19:33] <cnd> does it work?
[19:33] <hyperair> it does.
[19:33] <hyperair> but each smooth scroll event bumps it up by 1.2
[19:34] <cnd> hyperair, what do you mean?
[19:34] <hyperair> cnd: as in.. scale_factor *= 1.2
[19:34] <hyperair> or /= 1.2
[19:34] <hyperair> whichever
[19:35] <cnd> oh
[19:35] <cnd> well, it looks like you need to do some more development so that it uses the smooth scrolling scroll values
[19:35] <hyperair> yeah
[19:36] <hyperair> but i'm not sure what would be considered a "good" way of translating delta_x/y into zoom_in_factor (which is #defined to 1.2 for the non-smooth-scrolling case)
[19:36] <seb128> nautilus did that
[19:36] <seb128> http://git.gnome.org/browse/nautilus/commit/?id=1a76e044a2c9b834d00c4ea30f1e3af3321d8cdd
[19:37] <seb128> i.e using gdk_event_get_scroll_deltas()
[19:37] <seb128> not sure if that's different from what you do
[19:37] <hyperair> it's the same actually
[19:37] <hyperair> results in a discrete bumping of zoom levels
[19:37] <seb128> ok, I was unsure
[19:37] <hyperair> i.e. no smooth zooming
[19:37] <seb128> weird, maybe it has to do with your device?
[19:37] <seb128> what does xinput list <device_number> list as increment?
[19:38] <hyperair> 100.000000
[19:38] <hyperair> or something
[19:39] <hyperair> but nautilus really doesn't have continuous zoom levels
[19:39] <seb128> ok, so not -1, so you should get valid increments
[19:39] <hyperair> yeah
[19:39] <seb128> well nautilus add increments until reaching 1 and emulate a increment then
[19:39] <hyperair> nautilus_view_bump_zoom_level (directory_view, 1); <-- this?
[19:39] <seb128> no
[19:40] <seb128> total_delta_y += delta_y;
[19:40] <seb128> if (total_delta_y >= 1) {
[19:40] <seb128> that
[19:40] <hyperair> hmmm
[19:40] <hyperair> interesting, i'll try looking into that.
[19:40] <seb128> cf http://git.gnome.org/browse/nautilus/commit/?id=3d275a971132a41809a3b1e5b8ac683d264d6c35
[19:40] <seb128> that's the first commit I pointed
[19:40] <seb128> you said you were doing the same
[19:41] <seb128> "/* try to emulate a normal scrolling event by summing deltas */"
[19:41] <hyperair> hmm i didn't see the first one.
[19:50] <seb128> desrt, there?
[20:10] <desrt> seb128: yup
[20:13] <seb128> desrt, you might be interested in https://bugs.launchpad.net/bugs/981053
[20:13] <ubot2> Launchpad bug 981053 in lightdm "Creating system dconf configuration crashes lightdm" [High,Incomplete]
[20:13] <seb128> desrt, https://launchpadlibrarian.net/101751425/gdb-unity-greeter.txt
[20:13] <seb128> desrt, no hurry though
[20:15] <seb128> desrt, I would appreciate you commenting on the bug though ;-)
[20:16] <desrt> seb128: this is upstream already
[20:16] <desrt> i plan to get to it in the 3.6 cycle
[20:17] <desrt> https://bugzilla.gnome.org/show_bug.cgi?id=662141
[20:17] <ubot2> Gnome bug 662141 in dconf "tolerate profile errors" [Normal,Unconfirmed]
[20:17] <seb128> desrt, great, thank you
[20:17] <Darxus> http://www.chaosreigns.com/wayland/dl/gtk-ubuntu-build.txt.gz  This is the full output of "dpkg-buildpackage -rfakeroot -b" with the non-cairo-dependant branch of gtk.  I'd still love suggestions on where to look for why it failed.
[20:17] <seb128> desrt, not sure what the google guys are trying to do, but seems they hit it in whatever they do
[20:18] <desrt> ya.  seems a bit odd to me.
[20:18] <seb128> desrt, which might just be "hack around trying to get their profile right"
[20:19] <desrt> i think so
[20:19] <seb128> desrt, can you maybe try checking out on the bug?
[20:19] <desrt> there's no valid situation where they should be in the state they describe
[20:19] <desrt> but there are lots of invalid situations that are easy to get yourself into
[20:19] <desrt> and the end result is that your system is utterly utterly fucked
[20:19] <desrt> so it ought to be fixed
[20:19] <seb128> right
[20:20] <seb128> Darxus, you have a bunch of "echo Man generation disabled.  Remove this file, configure with --enable-man"
[20:20] <seb128> Darxus, try building with --enable-man?
[20:20] <Darxus> seb128: Thanks.
[20:20] <seb128> uw
[20:21] <seb128> yw
[20:21] <desrt> seb128: included my comments on the bug
[20:22] <seb128> desrt, thanks
[20:32] <Darxus> Got the same error.
[20:35] <Darxus> One of the weird things I've noticed is that the ubuntu source package seems to run configure 6 times, and mine is only running it 3 times.
[20:46] <dobey> Darxus: yes, because ubuntu rebuilds gtk+ packages with most all of the backends enabled (x11, directfb, etc)
[20:47] <Darxus> dobey: But I haven't changed anything, I'm trying to build packages the same with a different branch.
[20:48] <dobey> Darxus: why aren't you generating a diff of that branch and upstream gtk+, and rebuilding the ubuntu package with that diff, instead?
[20:49] <Darxus> dobey: How would that be different?
[20:49] <Darxus> Oh, upstream gtk, not....
[20:49] <Darxus> Because this branch doesn't contain all the differences I want.
[20:49] <dobey> well you could start from a known-building package.
[20:49] <dobey> well then make more patches
[20:49] <Darxus> Yeah, maybe.
[20:49] <Darxus> Thanks.
[20:49] <dobey> that's what patches are for
[20:53] <Darxus> Yeah, but it would be nice to be able to just build what's in a branch.
[20:58] <dobey> it is. though it takes some effort. particularly if you want to build packages which integrate with the system.
[21:36] <Darxus> Huh, looks like 8 patches, the 7 so far applied cleanly.
[21:37] <Darxus> 8.
[21:52] <Darxus> Woo, that built!
[22:00] <hyperair> yay, finally perfected evince's smooth scrolling
[23:00] <Darxus> I see the gtk package build fails if you export new symbols.  Is there a way to tell it to expect that, or it necessary to build it the new way, copy over the new list of symbols, and build it again?
[23:00] <Darxus> hyperair: Thank you, smooth scrolling is nice :)
[23:01] <hyperair> Darxus: if you add new symbols you need to add it to debian/libwhatever.symbols
[23:02] <Darxus> hyperair: And the best way to do that is to build it once, let it fail, copy over the updated list of symbols, and build it again?
[23:02] <hyperair> yeah, something like that
[23:02] <Darxus> Okay, thanks.
[23:02] <Darxus> Does it also complain if I remove symbols?
[23:03] <hyperair> yes.
[23:03] <hyperair> that's the main purpose of the .symbols file
[23:03] <Darxus> Heh.  Damn security.
[23:03] <Darxus> Ahh.
[23:03] <hyperair> and please *don't* remove symbols
[23:03] <hyperair> if you do that, you break abi compatibility
[23:03] <Darxus> Heh, I wasn't planning to, just curious.
[23:03] <hyperair> then you have to bump the SONAME
[23:04] <hyperair> if you remove a symbol, an application or library that has been linked against libgtk previously will fail to load because it can't resolve the symbol. and with such a high impact package, your entire desktop environment is effectively disabled.
[23:04] <hyperair> well if you remove a high-impact symbol anyway
[23:05] <Darxus> I bet you could explain the situation with wayland build-time and run-time checks, vs. linking for me.
[23:06] <Darxus> If an application calls functions in the wayland backend of gtk, and properly wraps them in build-time and run-time checks, and that application is compiled against gtk libs that were built with wayland enabled, does that application then *need* to be run against a build of gtk with wayland enabled in order to avoid linking errors?
[23:07] <Darxus> Dude, it built.
[23:09] <hyperair> heh
[23:10] <hyperair> i guess all's fine now?
[23:12] <Darxus> Yeah, looks like it.  You could still answer my question though :)
[23:13] <Darxus> Also, I hate this:  dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../gtk+3.0_3.4.0.orig.tar.{bz2,gz,lzma,xz}
[23:13] <Darxus> :P
[23:22] <dobey> Darxus: put the upstream tarball in the correct location
[23:23] <dobey> Darxus: and the whole point of gtk+'s design with backends is that you shouldn't be using any of them directly, such that your app will work fine with any of them
[23:32] <Darxus> $ dput -u ppa:darxus/wayland-gtk *.changes
[23:32] <Darxus> Package has already been uploaded to ppa on ppa.launchpad.net
[23:32] <Darxus> Nothing more to do for gtk+3.0_3.4.0-0ubuntu5~wayland1_source.changes
[23:33] <Darxus> Does that take a while to show up in https://launchpad.net/~darxus/+archive/wayland-gtk/+packages or did I do something wrong?