[02:06] <micahg> dobey: so, are there no more cil bindings for ubuntu one?
[06:20] <pitti> Good morning
[06:21] <pitti> desrt: ayan wanted to look into packaging it; I'll ping him and take over if he doesn't have time
[06:22] <desrt> pitti: that would be very awesome :)
[06:22] <pitti> since the last time I looked at it, the test suite now shows a fair number of regressions
[06:22] <pitti> so it'll need some work again
[06:22] <pitti> but that doesn't block us from packaging it, of course
[06:23] <desrt> pitti: did you see the mails on the distributor list?
[06:23] <pitti> desrt: yes, I read the thread
[06:23]  * desrt was happy to see them but a bit disappointed in the tone
[06:45] <smspillaz> pitti: do you know if its possible to override the vendor LDFLAGS in a package ?
[06:45] <smspillaz> -Bsymbolic-functions is causing problems for us
[06:49] <BigWhale> Good Morning
[06:51] <pitti> smspillaz: if the upstream build system unconditionally sets it, then no; we  usually add a patch to drop it from Makefile.{am,in}
[06:52] <pitti> smspillaz: more polite build systems do something like LDFLAGS?=, then you can set it in debian/rules
[06:52] <smspillaz> pitti: oh as in, the debian default flags contains -BsymbolicFunctions
[06:52] <smspillaz> err
[06:53] <smspillaz> pitti: oh as in, the debian default flags contains -Bsymbolic-functions
[06:53] <smspillaz> so I need to remove that from the debian flags
[06:53] <smspillaz> (but only for compiz)
[06:54] <pitti> smspillaz: ah yes, you can change that in debian/rules
[06:55] <smspillaz> pitti: cool. what is the flag to do it. I tried DEB_LDFLAGS_MAINT_OPTIONS=foo but that didn't work
[06:55] <smspillaz> err I think it was
[06:55] <pitti> smspillaz: export LDFLAGS= ... should work
[06:55] <smspillaz> DEB_LDFLAGS_MAINT_STRIP
[06:55] <smspillaz> ok, thanks!
[06:56] <pitti> there shouldn't be any particular magic
[06:56] <pitti> if it's not set, dpkg passes it in as default environment variable, but you should be able to override it normally
[06:59] <smspillaz> pitti: thanks!
[07:00] <smspillaz> that works :)
[07:00] <didrocks> good morning
[07:01] <pitti> bonjour didrocks
[07:01] <didrocks> guten mornen pitti
[08:36] <pitti> chrisccoulson: bug 857153 is "fix committed" for ages now, and "fix released" upstream, but neither seems to have landed in firefox 9 or 10; is that actually on track still?
[08:36] <ubot2`> Launchpad bug 857153 in firefox "Needs to get accessibility settings from GSettings" [High,Fix committed] https://launchpad.net/bugs/857153
[09:18] <seb128> hey
[09:19] <pitti> hey seb128
[09:19] <seb128> hey pitti, wie gehts? ;-)
[09:19] <pitti> gut, danke!
[09:24] <didrocks> salut seb128!
[09:24] <seb128> lut didrocks
[09:29] <pitti> rodrigo_: got g-c-c built in jhbuild now, but I don't see the region panel at all; I guess I'm missing some more bits in jhbuild?
[09:30] <chrisccoulson> hi pitti
[09:30] <chrisccoulson> yes, that fix is in aurora (firefox 11)
[09:30] <pitti> hey chrisccoulson, good morning
[09:30] <chrisccoulson> good morning :)
[09:31] <chrisccoulson> and aurora moves to beta next week
[09:31] <chrisccoulson> which means it will be in precise next week if i decide we stay on the beta for another 6 weeks
[09:37] <seb128> pitti, did you build from trunk?
[09:37] <pitti> seb128: yes
[09:37] <pitti> master for now, will switch to the wip/ branch in a bit
[09:37] <seb128> pitti, well you should have the normal region panel, but not rodrigo's changes
[09:37] <pitti> but I first wanted to see what's in master
[09:37] <pitti> I don't
[09:38] <pitti> in "personal" I just have brightness/lock, background, and online accounts
[09:39] <pitti> I do have libregion.so
[09:39] <pitti> ** WARNING **: Could not find settings panel "region"
[09:39] <pitti> ** WARNING **: Could not load setting panel "region": Unknown error
[09:39] <pitti> I suppose I need an additional module in jhbuild
[09:40] <seb128> weird
[09:40] <seb128> strace if and see if it tries to load the jhbuild or system one?
[09:40] <chrisccoulson> mmmmm, coffee
[09:40] <chrisccoulson> i so need that this morning
[09:41] <seb128> pitti, you can use "XDG_CURRENT_DESKTOP=GNOME gnome-control-center region" on the Ubuntu package to see it
[09:41] <pitti> 8539  open("/home/martin-scratch/gnome/lib64/control-center-1/panels/libregion.so", O_RDONLY) = 8
[09:41] <pitti> seems fine
[09:42] <pitti> seb128: hah, thanks
[09:42] <pitti> seb128: XDG_CURRENT_DESKTOP=GNOME jhbuild run gnome-control-center region
[09:42] <pitti> that was it
[09:42] <pitti> seems upstream only shows it in GNOME?
[09:42] <pitti> shell has a lot more now, too
[09:43] <pitti> now it just complains about invalid locales
[09:43] <seb128> pitti, it's using the .desktop files
[09:43] <seb128> pitti, so look at gnome-region-panel.desktop OnlyShowIn
[09:44] <pitti> seb128: right
[09:45] <seb128> right, region has GNOME only, not Unity
[09:51] <pitti> building rodrigo's branch now
[09:52] <pitti> meh, doesn't build due to wacom stuff
[09:52] <pitti> master does
[09:53] <seb128> pitti, you can probably hack the wacom dir out from the makefile or configure
[09:53] <seb128> pitti, I guess he didn't merge back the changes from trunk
[09:54] <pitti> I just merged trunk, builds now
[09:54] <pitti> I don't really block on this yet, I can implement the WhatProvides in aptdaemon with just testing through a gdbus call
[09:54] <pitti> but I'm curious nevertheless :)
[10:05] <glatzor> hello pitti, seb128 and mvo
[10:06] <pitti> hallo glatzor, wie gehts?
[10:06] <seb128> hey glatzor
[10:06] <glatzor> pitti, what happened to the work of rodrigo?
[10:06] <glatzor> pitti, fine. thanks
[10:06] <pitti> glatzor: he's still on it
[10:06] <pitti> glatzor: yesterday I finished the work on the language_support_pkgs.py logic and the aptdaemon plugin
[10:06] <glatzor> pitti, how are you?
[10:07] <pitti> glatzor: (which BTW works wonderfully! thanks for this ingenious plugin mechanism!)
[10:07] <glatzor> pitti, yeah. I have seen it. great work
[10:07] <pitti> glatzor: and today I wanted to start working on implementing WhatProvides in the aptdaemon PK compat layer
[10:07] <pitti> glatzor: would it be OK for you to do something liek
[10:07] <pitti> try:
[10:07] <pitti>    import language_support_pkgs
[10:07] <pitti> except:
[10:08] <pitti>    <raise not implemented error, as we do now>
[10:08] <pitti> glatzor: then this would work for Ubuntu, and not change any behaviour in Debian
[10:08] <glatzor> pitti, liek?
[10:08] <pitti> glatzor: or would it be relatively easy to add plugin support for WhatProvides?
[10:09] <pitti> glatzor: there is an existing PK_PROVIDES_ENUM_MODALIAS, whic we coudl also implement easily
[10:09] <pitti> and we want to add a new PK_PROVIDES_ENUM_LANGUAGE_SUPPORT for this
[10:09] <pitti> glatzor: s/liek/like/, sorry :)
[10:09] <glatzor> pitti, rodrigo pushes the work to packagekit?
[10:10] <pitti> glatzor: he was going to, yes; it's just adding the new enum for now
[10:10] <glatzor> pitti. it is ok. getting a reference implementation in the python apt backend of plugin should be easy too
[10:10] <pitti> glatzor: I'm more concerned how to integrate this into WhatProvides in aptdaemon now
[10:11] <glatzor> pitti, the whatprovides method hasn't been implemented yet since it wasn't required.
[10:11] <pitti> glatzor: right, it's just saying "not implemented" right now
[10:12] <glatzor> pitti, sessioninstaller does a better job. since it set a priorities to found packages
[10:12] <pitti> glatzor: but control-center can make use of WhatProvides "language-support" soon, and if we want to replace jockey in one of the next releases, having WhatProvides Modalias is handy, too
[10:12] <glatzor> pitti, it should be easy
[10:12] <pitti> glatzor: but that's session d-bus?
[10:12] <pitti> glatzor: the "easy" part is not the problem, it's the "ugly" for the try/except ImportError
[10:13] <pitti> glatzor: if what-provides could grow similar plugin support as cacheModifyAfter, we wouldn't need to "clutter" aptdaemon with code that uses language_support_pkgs.py or knowledge how dh-modalias adds the Modalias: headers to packages, etc.
[10:14] <glatzor> pitti, it is ok to go for the try/import approach. youjust have to raise a sane error in the case that it isn't available
[10:14] <pitti> glatzor: but if you don't like that, I'm happy to do the opportunistic import of language_support_pkgs if you agree
[10:15] <pitti> glatzor: it'd just continue to do self._fail_not_implemented, like it does now
[10:18] <glatzor> pitti, so aptdaemon.plugins.whatprovides_modalias ?
[10:19] <pitti> or whatprovides.<enum value>, but it doesn't really matter I guess
[10:19] <glatzor> pitti, right
[10:19] <pitti> glatzor: I'm not sure whether this stuff would be better as a plugin or in the core code
[10:20] <glatzor> pitti, having a plugin would allow to reuse the code easily in packagekit
[10:20] <pitti> glatzor: and I could keep both plugins in language-selector-common (or whereever it ends up later on)
[10:21] <glatzor> pitti, perhaps we could even thing about naming the plugins packagekit.backend.apt.plugins.whatprovides.modlias or something similar
[10:21] <glatzor> pitti, in the end you need a backend in packagekit which can handle the new functionality
[10:22] <glatzor> pitti, one of the reasons I revived the old python apt backend
[10:22] <pitti> glatzor: ah, so aptdaemon/pkcompat.py shouldn't implement it directly, but call a corresponding method in aptdaemon backend; and that would be the place to put the plugin or the code then?
[10:23] <glatzor> pitti, right. the apt backend of packagekit and aptdaemon would share the same plugins
[10:24] <seb128> didrocks, bug #922299 is for you
[10:24] <ubot2`> Launchpad bug 922299 in gnome-control-center "Mouse-wheeling "Launcher icon size" slider moves it the wrong way." [Low,Confirmed] https://launchpad.net/bugs/922299
[10:24] <glatzor> pitti, It would be a nice gesture to use the packagekit naming for the plugins
[10:24] <pitti> glatzor: the PK_PROVIDES_ENUM_* names, you mean? yes
[10:24] <didrocks> seb128: oh, interesting, please assign it to me if not already done :)
[10:24] <glatzor> pitti, it feels strange to promote changes to packagekit referring to aptdaemon.plugins :)
[10:25] <seb128> didrocks, done
[10:25] <glatzor> pitti, no. just the plugin names
[10:25] <didrocks> seb128: thanks
[10:25] <seb128> didrocks, thank you! ;-)
[10:25] <pitti> glatzor: how do you mean? the only change that we propose to PK itself is the addition of a new provides enum for LANGUAGE_SUPPORT
[10:25] <pitti> glatzor: I don't actually want to implement it in PK
[10:26] <pitti> glatzor: I think if we are going to land the control-center bits, we'll install python-aptdaemon.pkcompat, not packagekit?
[10:27] <glatzor> pitti, That is why I would reject your changes to packagekit (if I am the packagekit maintainer)
[10:28] <pitti> glatzor: rodrigo sayd yesterday that hughsie wouldn't mind adding the enum
[10:28] <glatzor> pitti, it feels strange to push changes to the reference implementation that cannot be used by it
[10:28] <pitti> glatzor: so, going back a step, what would you recommend instead?
[10:29] <pitti> glatzor: after all, most of the possible what-provides enums are not implemented in most backends
[10:34] <pitti> glatzor: anyway, it's relatively easy to implement it in packagekit itself, too
[10:34] <pitti> glatzor: so we could do (1) a packagekit patch which adds the enum and an apt backend implementation
[10:35] <pitti> glatzor: and (2) an aptdaemon patch which also implements this UI through a plugin
[10:35] <pitti> s/UI/API/
[10:41] <glatzor> pitti, right. and both aptdaemon and packagekit apt backend could share the same plugin.
[10:41] <pitti> glatzor: oh, packagekit has plugins, too?
[10:42] <glatzor> glatzor, oh. packagekit itself has got a plugin mechanism. But I would just add the same small plugin loading feature of aptdaemon to the apt backend of packagekit
[10:50] <glatzor> pitti,  you would just need the cache and the search string in plugin method? and return a list of apt.package.Packages
[10:56] <pitti> glatzor: right
[10:56] <pitti> glatzor: ok, I'll start with the PK patch then
[11:01] <glatzor> pitti, the enum one or also the plugin loading mechanism in the apt backend?
[11:01] <pitti> glatzor: both
[11:02] <pitti> glatzor: oh, not sure about plugin loading
[11:02] <pitti> need to figure out how that works
[11:03] <glatzor> pitti, so I can write the plugin mechanism at the weekend since I am on a train ride
[11:03] <pitti> as a first PoC it could just try: import language_support_pkg
[11:06] <mandel> any xorg expert aorung here whose brain I could poke?
[12:04] <pitti> glatzor: ah, just saw that implementing it in aptcc is tricky, as my library is in Python; we could call check-language-support, but that takes some more time
[12:04] <pitti> glatzor: aptcc is still our preferred backend, right?
[12:19] <mandel> pitti, have you guys seen this before: http://www.youtube.com/watch?v=E8Akda59yQI&feature=plcp&context=C3a6464bUDOEgsToPDskL-qb9lDdv7vlUubOt581D-
[12:19] <mandel> sorry for the scanner sound in the background..
[12:25] <mandel> more iteresting details, lightdm does not work correctly and I can just login as a guest, once a guest I can do su mandel and work as usual from the terminal
[12:28] <glatzor> pitti, no. the python apt backend is the cool one :)
[12:29] <glatzor> pitti, it is also the one with a test suite :)
[12:55] <pitti> glatzor: ah, I see, thanks
[14:08] <dobey> micahg: that's correct, for the time being.
[14:09] <chrisccoulson> crash reporter, why u no workee?
[14:09] <pitti> chrisccoulson: it can haz cookie?
[14:09] <desrt> dobey: hey.  you get your problem sorted yesterday?
[14:10] <chrisccoulson> pitti - i eated the cookies already
[14:11] <pitti> chrisccoulson: "eated" is too credible an error; you need to break the grammar more, c'mon, you can do it!
[14:11] <chrisccoulson> heh
[14:11] <pitti> chrisccoulson: I suppose it's mozilla's crash reporter, not apport?
[14:11] <desrt> pitti: he munged ya bizkitzz
[14:11] <dobey> desrt: the one with the changed interface, yeah
[14:11] <chrisccoulson> pitti - yeah
[14:11] <pitti> dobey: hungry it must be
[14:12] <pitti> err, desrt
[14:12] <chrisccoulson> i'm just wondering why the symbols for glib aren't being resolved, even though i'm building and submitting symbols for it now: https://crash-stats.mozilla.com/report/index/bp-ce02a26a-f396-490b-ae78-6eac62120127
[14:30] <pitti> glatzor, mvo: hm, packagekit seems to assume that app-install-data generates /var/lib/PackageKit/mime-map.gdbm, but it doesn't?
[14:30] <pitti> shoudl that be fixed, or should packagekit stop bombing out if it doesn't exist?
[14:31] <mvo> stop bombing - we don't do this since a long time
[14:35] <glatzor> pitti, the old apt backend code of what provides is just a piece of copy and paste from the old backend. it is quite old code
[14:36] <pitti> glatzor: ok, I'll stop bombing then
[14:36] <pitti> glatzor: and also implement what-provides ANY support, so that pkcon what-provides works
[14:37] <glatzor> pitti, I should perhaps make the code to find mime types and codecs in sessioninstaller more generic and also convert them into plugins
[14:38] <glatzor> pitti, mvo have a nice day! i am off
[14:39] <pitti> glatzor: and you, thanks for everything!
[15:10] <hallyn> i'm using the HUD ppa - but the launcher autohide has changed behavior?  if i have a fullscreened app and a small terminal, when the terminal is focused the launcher shows
[15:10] <hallyn> is that deemed a bug, or a new feature?
[15:10] <hallyn> (i'd call it a bug...  keeps me reading everything on my fullscreen browser)
[15:14] <micahg> chrisccoulson: I think I'd prefer if precise stayed on Beta through 11, that gives us about 12 weeks on the 11 code base to find any issues before release
[15:36] <seb128> mdeslaur, hey
[15:37] <seb128> mdeslaur, do you plan to do any work on the screen locking this case? i.e dropping your g-s-d patch to "always lock screen without respecting the user setting"?
[15:41] <mdeslaur> seb128: I was under the impression we were switching to locking with lightdm
[15:41] <mdeslaur> seb128: what was the issue? for people who autologin?
[15:42] <mvo> seb128: re the new webkit any idea about #922652
[15:42] <Daviey> Ugh, HUD seems to be stealing alt+a .. How can i change that?
[15:42] <desrt> seb128: can you change the status on https://bugs.launchpad.net/intltool/+bug/580526 ?
[15:42] <ubot2`> Launchpad bug 580526 in intltool "Add support for new gsettings simple schema format" [High,Fix released]
[15:42] <Daviey> oddly, not all the time.
[15:42] <seb128> mdeslaur, different sort of user who don't want to have to be bothered typing a password, i.e people using a netwook for browsing and suspend it
[15:43] <mdeslaur> seb128: so I should check if they auto login?
[15:43] <seb128> desrt, no, I'm not an intltool dev, dobey can
[15:43] <seb128> bug #922652
[15:43] <ubot2`> Launchpad bug 922652 in webkit "Sorting out a11y in Software-center I hit the following webkit error" [Undecided,New] https://launchpad.net/bugs/922652
[15:43] <desrt> dobey: poke
[15:43] <seb128> mvo, I hate code :p
[15:44] <desrt> dobey: did you see https://bugs.launchpad.net/intltool/+bug/580526 ?
[15:44] <ubot2`> Launchpad bug 580526 in intltool "Add support for new gsettings simple schema format" [High,Fix released]
[15:44] <seb128> mvo, without a stacktrace no clue no
[15:44] <dobey> desrt: it says fix released?
[15:44] <desrt> dobey: yes.  the status should be changed.
[15:44] <desrt> the patch that i submitted was rewritten, breaking it
[15:44] <seb128> mdeslaur, not sure, why do you enforce the locking to start? did we have any issue letting the indicator or gnome-settings-daemon lock when needed?
[15:45] <desrt> and the release was made with a broken 'fix'
[15:45] <mdeslaur> seb128: that was the issue, if you turn off the automatic lock after timeout, it wouldn't lock when you suspended either
[15:46] <seb128> mdeslaur, well maybe the option should be "don't lock the screen for me" ;-)
[15:46] <seb128> mdeslaur, is that the wording which is confusing?
[15:46] <mdeslaur> seb128: no, it's the setting that's stupid...turning off the automatic screensaver shouldn't turn off a password prompt when you suspend
[15:47] <seb128> mdeslaur, that setting has nothing to do with screensaver
[15:47] <mdeslaur> seb128: unless you're configured to autologin, in which case my patch is wrong
[15:47] <seb128> mdeslaur, we don't have screensavers anymore, we just have locking
[15:47] <mdeslaur> seb128: sorry, I meant turning off the auto screen lock shouldn't turn off the password prompt when you suspend
[15:48] <dobey> desrt: i guess you need to talk to danilo then.
[15:48] <seb128> mdeslaur, well that's why I suggest renaming the option "lock the screen for me", which is what it does actually
[15:48] <tkamppeter> pitti, hi
[15:48] <desrt> dobey: does he even irc anymore?
[15:48] <dobey> yes
[15:48] <seb128> mdeslaur, in fact the widget is below "locking"
[15:48] <dobey> desrt: as danilos
[15:49] <desrt> he's on gnome irc as 'danilo'.  odd.
[15:51] <mdeslaur> seb128: I'm not sure what you're asking me. Removing the patch doesn't make sense. Fixing the patch to check the autologin configuration makes sense.
[15:52] <mterry> kenvandine, heyo.  Do you have any good "make gtk animations run smooth" tips from gwibber?
[15:52] <seb128> mdeslaur, ok, I guess autologin would fix most of the cases
[15:52] <kenvandine> not really... njpatel worked that magic
[15:52] <seb128> mdeslaur, I still think the ui is confusing, the option should rather be labelled "never automatically lock the screen" or something
[15:53] <mdeslaur> seb128: ie: I want to turn off automatic screen locking because I often watch movies or give presentations, but I still want a password when I suspend and resume
[15:53] <seb128> mdeslaur, the presentations or video player should inhibit locking, that seems orthogonal cases
[15:53] <mdeslaur> seb128: let me think of the scenarios, and I'll write up a wiki page with them
[15:53] <seb128> mdeslaur, thanks, maybe check with mpt, I think he said he would look at the scenarios as well
[15:54] <mdeslaur> seb128: well, what's the use case of letting people turn off screen locking then?
[15:54] <seb128> mdeslaur, well, let's say you have a netbook you let around in your living room for easy internet browsing (sort of table usecase nowadays), why should you be bothered typing password on resume?
[15:54] <mdeslaur> mpt: If you're looking at the screen locking / login password scenarios, I'd like to help
[15:55] <seb128> mdeslaur, but agreed, those users will often have autologin set as well
[15:55] <mdeslaur> seb128: so, you want a password on login, but not on resume?
[15:55] <mdeslaur> seb128: seems inconsistent to me
[15:55] <tkamppeter> pitti, I have packaged cups-filters now but have some problems. It seems not to respect binary-post-install/<binary package>:: rules in debian/rules.
[15:55] <seb128> mdeslaur, no, in practice I think matching autologin should be fixing most of the cases where people are annoyed by the "always locking" we do currently
[15:56] <elvisd> Hi all,
[15:56] <seb128> hi elvisd
[15:56] <dobey> that was odd
[15:56] <elvisd> is there a PPA with latest version of ambiance theme?
[15:56] <tkamppeter> pitti, so I do not get a libcupsfilters1-dev package as "make install" does not install the dev files and I have to do it in debian/rules (will polish it upstream later).
[15:56] <elvisd> for Precise, i mean
[15:56] <tkamppeter> pitti, I mail you the package.
[15:56] <mdeslaur> seb128: ok, let me think about it and take a look
[15:56] <seb128> elvisd, no, the current versions are pretty much in precise itself
[15:57] <pitti> tkamppeter: ok; NB that I have release meeting now, so it might be a bit
[15:57] <elvisd> cause there are some bugs
[15:57] <RainCT> seb128: Hey. Just uploaded Zeitgeist alpha 2 to experimental :)
[15:57] <seb128> mdeslaur, having an usecase matrix would help, it might turn out that respecting autologing is good enough
[15:57] <pitti> tkamppeter: but you shoudn't use such rules if it can be avoided
[15:57] <seb128> RainCT, hey
[15:57] <elvisd> seb128, ok, thanx
[15:57] <seb128> didrocks, ^ you were on the zg case right? ;-)
[15:57] <mdeslaur> seb128: yeah, I'll talk to mpt and see if we can start by doing that
[15:57] <pitti> tkamppeter: have "make install" install into debian/tmp/, and then have debian/pkgname.install files to install the bits that you want for that binary
[15:58] <RainCT> seb128: err yeah that was for didrocks, sorry.. :P
[15:58] <didrocks> RainCT: awesome! did you get my message through mhr3 about the Replaces: ?
[15:58] <tkamppeter> pitti, I have overtaken debian/rules from cups and then edited it. It does "make install" install into debian/tmp/,
[15:59] <didrocks> RainCT: it's quite late to sync today from experimental though, not sure if it will be before or post alpha2 then ;)
[15:59] <mpt> mdeslaur, great, I started writing <https://wiki.ubuntu.com/SessionHandling>
[15:59] <mpt> mdeslaur, if there are any existing problems not yet described there, please add them
[15:59] <mdeslaur> mpt: ah, cool, let me catch up to that, and I'll let you know
[16:00] <RainCT> didrocks: Yeah, python-zeitgeist has Replaces and Breaks
[16:01] <RainCT> didrocks: I can mail you the files if you prefer uploading it now
[16:01] <RainCT> well it's in bzr too anyway
[16:01] <didrocks> RainCT: no, I think that can wait anyway, not found of syncing stuff before leaving :)
[16:01] <chrisccoulson> pitti - https://crash-stats.mozilla.com/report/index/bp-0e092710-dce1-4f62-b356-a05592120127
[16:01] <chrisccoulson> symbols \o/
[16:02] <RainCT> okay :)
[16:02] <didrocks> RainCT: but thanks for the heads up, let's see when the freeze will be on Monday morning :)
[16:02] <pitti> chrisccoulson: yay, what changed?
[16:02] <tkamppeter> pitti, package sent to you by mail. Problems are: binary-post-install/cups:: and binary-post-install/libcups2-dev:: in debian/rules not executed, therefore cups-filters package imcomplete and libcupsfilters1-dev without non-doc files; cups-filters-dbg contains only strange files, seems incomplete.
[16:03] <chrisccoulson> pitti - our symbols weren't being sync'd to the right place because the index file i was creating was named incorrectly
[16:03] <chrisccoulson> that was it ;)
[16:03] <pitti> tkamppeter: well, your package certainly doesn't build "cups" and "libcups2-dev" binaries?
[16:03] <tkamppeter> pitti, thanks, now I see that this I forgot to edit ...
[16:05] <seb128> chrisccoulson, you should probably drop the w.i you have to look at the elementary calendar and help them if possible I doubt that it will happen this cycle
[16:07] <jibel> pitti, about test_lts_upgrade_user.py, I believe it requires autologin to be fixed first because gsettings-data-convert is called on login ?
[16:07] <pitti> jibel: yes
[16:08] <pitti> jibel: ah, I see
[16:08] <jibel> pitti, is it valid is I run gsettings-data-convert as user ubuntu in the setup of the test instead of relying on autologin ?
[16:08] <pitti> jibel: so it doesn't actually start a desktop session yet after the upgrade?
[16:08] <pitti> jibel: it should be; but if you want to hack it, I'd rather sed /etc/lightdm/lightdm.conf and set autologin-user=ubuntu
[16:08] <jibel> pitti, no, because it's doing it with autologin and it is not preserved on upgade
[16:08] <pitti> until it's fixed in the packages
[16:08] <jibel> *upgrade
[16:09] <seb128> mdeslaur, I assigned you bug #869765
[16:09] <pitti> jibel: i. e. run the test_system.py first (so that it fails), then sed lightdm.conf, then have it start the session and run the user test?
[16:09] <ubot2`> Launchpad bug 869765 in gnome-settings-daemon "Screen locked on lid close, suspend, user switch" [Low,Confirmed] https://launchpad.net/bugs/869765
[16:09] <pitti> jibel: I'll open the migration bug, I'll try to fix it on Monday
[16:09] <jibel> pitti, ok, i'll do that
[16:09] <seb128> mdeslaur, feel free to consider it as a "should not lock the screen when autologin is used"
[16:10] <mdeslaur> seb128: thanks, I'll take a look
[16:10] <seb128> pitti, open a bug about what?
[16:10] <pitti> jibel: hm, I was sure there was an existing bug for this already
[16:10] <pitti> seb128: I mean open a tab for that bug, for me as a reminder
[16:11] <seb128> ok
[16:11] <pitti> jibel: ah, bug 854431 ?
[16:11] <ubot2`> Launchpad bug 854431 in lightdm "GDM automatic login is not transitioned to lightdm automatic login" [High,Triaged] https://launchpad.net/bugs/854431
[16:11] <jibel> pitti, bug 854431
[16:11] <jibel> :)
[16:21] <pitti> mvo: question; bug 850264 is marked for alpha-2; is that realistic to land by Monday, or should we postpone it?
[16:21] <ubot2`> Launchpad bug 850264 in apt "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix committed] https://launchpad.net/bugs/850264
[16:22] <tkamppeter> pitti, now it seems all to work. I will send you another version and have only 2 doubts left:
[16:23] <tkamppeter> pitti: 1. The strange content of cups-filters-dbg
[16:23] <tkamppeter> pitti: 2. Whether I put the correct Replaces/Conflicts/Breaks into cups-filters so that on an update the right thing happens.
[16:24] <mdeslaur> seb128: out of curiosity, on what kind of hardware were you still seeing the bug with user switching and fading?
[16:25] <seb128> mdeslaur, my e6410 (dell latitude i5 with ssd, intel video)
[16:25] <seb128> mdeslaur, I got it during the rally
[16:26] <mdeslaur> seb128: huh, ok, thanks
[16:26] <mvo> seb128: I will ask for a stacktrace
[16:26] <seb128> mvo, thanks
[16:26] <mvo> pitti: good question, its ready, but slangasek ran into a upgrade bug using it which we currently have no idea about
[16:43] <tkamppeter> pitti, I have mailed you the corrected cups-filters package.
[16:47] <tkamppeter> pitti, another mail with a small correction ...
[16:50] <dobey> man, apport is completely useless sometimes
[17:00] <pitti> tkamppeter: replied to the mail with some bits
[17:02] <pitti> tkamppeter: it could also be that the .build-id stuff is just a new way of doing things; I have heard about it, but never saw it in a Debian/Ubuntu package yet
[17:03] <pitti> tkamppeter: do we really still need this "sed" call on cupsfilters.convs in debian/rules? sholdn't this just be done upstream now?
[17:04] <pitti> tkamppeter: also, theh install call for the .ppd can just become an entry in cups-filters.examples
[17:08] <pitti> good night everyone!
[17:08] <seb128> 'night pitti, have a good w.e
[17:42] <seb128> ok, that works
[17:42] <seb128> time for some sport
[17:43] <seb128> bbl
[18:24] <mdeslaur> Is querying accountsservice the best way to determine if the currently logged in user has autologin configured?
[20:52] <cyphermox> yay, I can actually use ibus in Unity 5.0.0 again :D
[21:47] <dobey> anyone know if there is a way to make python-gi load from a specific typelib dir, as well as the system one?
[21:47] <broder> dobey: ooh, i've done this...one sec
[21:48] <broder> from gi.repository import GIRepository
[21:48] <broder> GIRepository.Repository.get_default().prepend_search_path("/usr/lib/mutter")
[21:48] <broder> then you can just do "from gi.repository import whatever"
[21:48] <dobey> is there a way to do it without shoving that in the code?
[21:48] <dobey> like an env var? :)
[21:49] <broder> no idea
[21:50] <dobey> ah ha!
[21:50] <dobey> GI_TYPELIB_PATH
[21:50] <dobey> thank you random wiki page on github