[00:50] <jbicha> cyphermox: oh np, I could work on it if you haven't started with it
[00:51] <cyphermox> feel free, I'm doing paperwork for the SRU still
[00:51] <jbicha> ok
[00:54] <RAOF> robert_ancell_: So, display manager/system compositor communication. Got a moment?
[01:03] <cyphermox> jbicha: started? I'm uploading and then I'd be ready to play with e-d-s and all
[01:06] <cyphermox> uhoh
[01:14] <cyphermox> jbicha: started? I'm uploading and then I'd be ready to play with e-d-s and all
[01:14] <cyphermox> in fact, I got the branch and everything now
[01:21] <jbicha> oh, I didn't quite start yet
[01:36] <jbicha> it looks like the remaining diff is just the icedove/thunderbird switch and the nautilus epoch
[02:18]  * desrt wonders why we don't have the latest stable glib SRU'd yet
[02:30] <jbicha> cyphermox: ok, nautilus-sendto works here, so I'm going to go ahead and upload e-d-s, evolution & nautilus-sendto
[02:31] <jbicha> can you post the transition tracker?
[02:43] <cyphermox> jbicha: I can't, I'm not a DD
[02:43] <cyphermox> I can write the ben file, but I guess they already have one now
[02:44] <cyphermox> if you're going to upload evolution and e-d-s, I'll "track" it with the NBS that will show up, since I'm on +1 maint for now
[02:44] <jbicha> oh I meant http://people.canonical.com/~ubuntu-archive/transitions/ but I guess you don't have rights there either
[02:44] <cyphermox> nope
[02:46] <cyphermox> jbicha, anyway, thanks for looking at evo. that one is suffering a bit since I'm already pretty busy with NM
[02:47] <cyphermox> I'll check if it's in and look at it and test tomorrow; if you upload tonight. for now I'm going to bed
[02:48] <jbicha> cyphermox: I just uploaded it, I think I'll wait on nautilus-sendto until the morning so that evolution can build & get published first
[02:48] <cyphermox> sure
[02:48] <RAOF> desrt: I'm also wondering why there's not a stable glib SRU up; I rejected a smaller glib SRU earlier in the week because Seb said that the full stable SRU would be up this week.
[02:49] <desrt> maybe he meant friday :)
[03:07] <cyphermox> RAOF: if you have time, it would be very cool if you could review network-manager I just uploaded to precise-proposed; stgraber has been bugging me about it for a long while ;)
[03:07] <stgraber> ;)
[03:09] <stgraber> cyphermox: I'm just proxying the other peoples bugging me ;) the boot time race affected quite a few people (including mdeslaur), the wifi issue makes my grand-mother's laptop reconnect to wifi every 10min so that makes things like skype calls quite bumpy :)
[03:10] <cyphermox> yeah yeah, but nobody uses ipv6 ;P
[03:13] <cyphermox> stgraber: plz review the Test case and Regression potential for the boot race; just to be sure there isn't anything to add
[03:13]  * cyphermox logs off
[03:25] <stgraber> cyphermox: the regression potential is actually wrong, static-network-up will always be emitted, if you have a completely broken network, it'll be emitted by the failsafe job after 2 minutes
[03:58] <robert_ancell_> RAOF, hey
[03:58] <RAOF> robert_ancell_: Yo!
[04:00] <RAOF> robert_ancell_: Get the google doc?
[04:01] <robert_ancell_> just opening now
[04:04] <robert_ancell_> RAOF, so the trade off with starting the display manager from the compositor is we have to secure the VT switching
[04:06] <RAOF> Do we? The compositor can prevent VT switching itself easily enough.
[04:06] <robert_ancell_> RAOF, I mean "VT" switching, i.e. session switching
[04:06] <robert_ancell_> RAOF, can't the DM start the compositor and pass the compositor fd to the children via a pipe?
[04:06] <RAOF> Ah, which means that it needs to send events to the display manager for that. Right.
[04:08] <RAOF> It's possible for the DM to start the compositor; it's just a bit more work.
[04:08] <RAOF> But in the model presented there session switching is secure - only the display manager can talk to the system_compositor interface.
[04:09] <robert_ancell_> RAOF, I think that's worth it, because we end up with one process managing the display (the aptly named display manager) which has good security and simplicity implications.  The compositor also becomes an optional component that can vary as required (effects)
[04:09] <stgraber> cyphermox: Marked the ipv6 one verification-done as the official package works here and I don't expect it to behave any differently from the one in your PPA on the longer run. I also poked mdeslaur to validate the boot time race condition one.
[04:10] <robert_ancell_> RAOF, how does the compositor distinguish between the display manager or an X server talking to it (is it an ordering thing, i.e. the DM gets in first and claims the control connection before starting X servers)
[04:11] <RAOF> robert_ancell_: The fd that the compositor passes to the display manager is privileged; only a client on that fd can bind to the system_compositor interface.
[04:11] <robert_ancell_> and the clients use WAYLAND_SOCKET for communication?
[04:11]  * robert_ancell_ draws a diagram for himself to understand
[04:12] <RAOF> WAYLAND_SOCKET is actually an fd number that the client will communicate over.
[04:12] <pitti> Good morning
[04:12] <RAOF> Good morning pitti!
[04:13] <RAOF> robert_ancell_: Nothing that isn't spawned by the display manager can talk to the system compositor at all; there isn't a global socket for anything to connect to. Only clients that the display manager provides fds to can talk to the system compositor.
[04:14]  * RAOF also tries drawing a diagram
[04:15] <TheMuso> Morning pitti.
[04:17] <jasoncwarner_> pitti: uhm...what? why are you up at this time?
[04:18] <robert_ancell_> RAOF, so thinking about having the compositor above the display: a) It means that the DM is really not managing the display at all - the compositor could be stopped at any time and the DM would be completely stuffed.  b) The DM can't choose any of the properties of the display (e.g. the hardware it uses)
[04:19] <robert_ancell_> We really want the compositor to be as dumb as possible and just do what the DM tells it to do
[04:20] <robert_ancell_> RAOF, I copied the startup sequence to an "alternative sequence" section in the doc - It doesn't seem like there's anything particularly hard to do to start it in the other order.  The compositor just needs to be able to take a pipe as input and allow the DM to connect using wayland on that
[04:24] <RAOF> Yes.
[04:25] <RAOF> I don't think that'll be terribly hard. It does imply that the display manager needs to kill any existing compositor before starting a new one, but that's not terrible.
[04:28] <robert_ancell_> RAOF, yes, but it already has to manage a number of processes and cleanly exit them before it exits so that's already done
[04:30] <robert_ancell> RAOF, so you're OK to go with "Alternative sequence"?
[04:32] <RAOF> I think so.
[04:33] <RAOF> It's actually not terribly hard to switch over to the other sequence if it turns out that there's a deep problem we're missing, anyway.
[04:35] <robert_ancell> sure
[04:36] <robert_ancell> RAOF, so we might also want to consider if the compositor should become Plymouth aware and handle that transition
[04:38] <RAOF> Transition? I thought we were (a) ignoring the plymouth transition until (b) we start the compositor super-early and have a wayland plymouth client.
[04:39] <RAOF> I need to head to a dentists appointment; I'll start on that alternate startup sequence after that, and probably see you Monday?
[04:41] <robert_ancell> RAOF, sure
[04:41] <robert_ancell> RAOF, regarding the Plymouth transition we need to at least stop Plymouth, ideally as late as possible and the compositor is the part that grabs the DRM device so is probably better placed to do that
[04:42] <robert_ancell> currently LightDM does that before it starts X, but again, X is probably the better place to do it
[06:26] <tkamppeter> pitti, hi
[06:30] <pitti> hey tkamppeter
[06:36] <tkamppeter> pitt, first, great news of your new role. I always saw regressions the biggest problem of free software. Any contribution to OpenPrinting (cups-filters, foomatic-...) anmd to other printing-related projects are welcome.
[06:36] <tkamppeter> pitti ^^
[06:36] <pitti> tkamppeter: setting up some automatic regular testing for those certainly sounds like a good idea
[06:37] <tkamppeter> pitti, will you still approve SRUs before your switchover? Can you approve the CUPS SRU? It is very urgent.
[06:37] <pitti> tkamppeter: I guess the output of some filters can still be tested automatically, if it's in some non-binary-blob format?
[06:37] <pitti> tkamppeter: i. e. if they produce PS, or some well-known raster format?
[06:38] <pitti> tkamppeter: I formally left the SRU team, so from now on it's probably better to ask in #ubuntu-release, or ping RAOF/SpammapS about SRUs
[06:38] <tkamppeter> pitti, non-binary formats are rather rare. Only PostScript and text are non-binary, and with the PDF printing workflow PostScript gets one of the many printer-native formats.
[06:39] <pitti> tkamppeter: right, but perhaps some raster formats can be checked, too
[06:39] <pitti> http://www.easysw.com/~mike/rasterview/index.html
[06:40] <tkamppeter> pitti, so sorry for bugging you with CUPS SRU, so as the week is already over in AU it seems that it skipped over the weekend.
[06:40] <tkamppeter> pitti, yes I used the tool a lot.
[06:41]  * pitti looks at cups sru
[06:43] <tkamppeter> pitti, Ghostscript has a very sophisticated automated regression testing. Files attached to upstream bugs get usually into it. And #ghostscript on Freenode is open for any hint. Perhaps you could also do the other way around, learn from Ghostscript to get better regression testing into other projects.
[06:43] <pitti> tkamppeter: urgent> this is so utterly intrusive, this can't possibly go into -updates after just 7 days and two or three users giving feedback; this needs a wide range of tests on various USB and IPP printer setups
[06:44] <pitti> i. e. while it's fine for users to say "this bug is fixed now", that doesn't tell us much about regressing other models
[06:44] <pitti> or setups
[06:45] <pitti> anyway, accepted into -proposed
[06:47] <tkamppeter> pitti, the advance to the next upstream release is the attampt to get the IPP mess fixed, the more lightweight version had been stepping back to the IPP backend of CUPS 1.4.x (Natty) again.
[06:52] <tkamppeter> pitti, thank you very much.
[07:47] <seb128> hey
[07:48] <pitti> bonjour seb128
[07:48] <asac> hello
[07:48] <asac> pitti: hi
[07:48] <asac> sudo apport-retrace -S /tmp/sandbox -o /tmp/out /var/crash/_usr_bin_gnome-control-center.1000.crash
[07:48] <asac> /tmp/sandbox/Ubuntu 12.04/sources.list does not exist
[07:48] <seb128> hey pitti, asac, wie gehts? happy friday!
[07:49] <micahg> seb128: is anyone working on webkit in quantal?
[07:49] <asac> hey seb128 :) ... finally got around trying to retrace the "select bluetooth sound device and control center crashes" bug :)
[07:49] <pitti> asac: well yes, you actually need to create a sandbox configuratino file there (/tmp/sandbox/Ubuntu 12.04/sources.list)
[07:49] <seb128> micahg, no, nobody has been working on webkit in Ubuntu for cycle, I just took up on doing the updates previous cycle because they were stalling
[07:50] <pitti> asac: specify "-S system" to re-use the one from /etc/apt/sources.list
[07:50] <asac> cool
[07:50] <seb128> micahg, though we might be able to sync 1.9.2 from Debian experimental, I planned to look at that
[07:50] <asac> pitti: which directory will it produce the sandbox in?
[07:50] <micahg> seb128: do we need to take 1.10 for Q?
[07:50] <pitti> asac: in a temp dir
[07:50] <asac> oh cool
[07:50] <pitti> asac: unless you specify --sandbox-dir
[07:50] <pitti> man apport-retrace :)
[07:50] <seb128> micahg, "need to", I don't know but they follow the GNOME cycle and I would not be surprised if i.e epiphany requires 1.9
[07:51] <asac> pitti: i used man apport-retrace to get to the command line above :)
[07:51] <asac> but its certainly a problem in my brain being unable to properly consume good manpages
[07:51]  * asac should think about scrolling to the example
[07:53] <pitti> mvo: is there a trick to lure apt.Cache() into respecting $APT_CONFIG ?
[07:53] <micahg> seb128: ok, thanks, if you don't get to it by next week, I might take a look at syncing/merging 1.8.1 from unstable (would prefer you do it though :))
[07:53] <pitti> mvo: i. e. when I set up an apt sandbox and set APT_CONFIG, then "apt-cache show", "apt-get install", etc. all work, but apt.Cache() doesn't
[07:54] <seb128> micahg, does it mean you prefer not to go for 1.9? why?
[07:54] <pitti> mvo: I guess I could open APT_CONFIG and parse out Dir/RootDir
[07:54] <micahg> seb128: well, the idea was to support 1.8 for 5 years, if Q is on 1.8, that's one less extra thing to worry about
[07:55] <micahg> OTOH, if 1.10 doesn't have any ABI breaks, might be worth jumping
[07:55] <seb128> micahg, right, let's see what goes in 1.9 and if GNOME starts depending on it
[07:55] <seb128> micahg, I will let you know
[07:55] <micahg> seb128: thanks
[08:00] <pitti> mvo: ah, ignore me; the problem is somewhere else apparently
[08:04] <pitti> mvo: right, seems aptdaemon's test.py Chroot allows me to "apt-get install foo", but after that it doesn't consider foo as installed
[08:06] <pitti> mvo: right, it seems I need to set Dir::State::status in addition to Dir
[08:06] <asac> http://paste.ubuntu.com/1006079/ ... odd that there are no symbols for libsoundnua.so
[08:23] <asac> cyphermox: Program received signal SIGSEGV, Segmentation fault.
[08:23] <asac> 0x01492b92 in gvc_mixer_control_change_input (control=0x80115300, input=0x80380b50) at gvc-mixer-control.c:736
[08:23] <asac> 736	        if (g_strcmp0 (active_port->port, input_port) != 0){
[08:23] <asac> cyphermox: i guess that has something to do with: http://launchpadlibrarian.net/103280614/gnome-control-center_1%3A3.4.1-0ubuntu1_1%3A3.4.1-0ubuntu2.diff.gz ?
[08:26] <asac> cyphermox: maybe the assumption that is_output is equiv to !IS_MIXER_SOURCE is not correct?
[08:26] <asac> active_port = 0x0 btw
[08:28] <asac> cyphermox: i man ... i can switch to all inputs, but the bluetooth one ... maybe thats !GVC_IS_MIXER_SOURCE :)?
[08:28] <asac> i mean
[08:28] <asac> anyway ... thanks for checking :)
[08:31] <mvo> pitti: hi, sorry for the delay, yeah dir::state::status is set with a abosulte path usually so it does not honor dir::state as the prefix
[08:31] <pitti> mvo: ah, thanks
[08:48] <pitti> mvo: do you happen to know about https://wiki.ubuntu.com/SoftwareAndUpdatesSettings#drivers ?
[08:48] <pitti> mvo: this currently looks like software-properties-gtk
[08:49] <pitti> mvo: (which we have a -kde variant for)
[08:49] <pitti> mvo: will this move into software-center, or will we keep s-properties?
[08:55] <mvo> pitti: I don't know about this one, it looks like software-properties to me (or a hybrid between update-manager and software-properties given the "Software Channels tab"
[08:55] <mvo> pitti: mpt will know for certain :)
[08:55] <mvo> pitti: but it does not look like it will be software-center
[08:55] <pitti> mvo: ok, I'll call it softwrae-properties for now then :)
[08:55] <pitti> danke
[08:55] <mvo> yeah, that sounds like it
[08:57] <mpt> pitti, the options I presented during the UDS session were, in order of preference: (1) a tab of a "Software & Updates" panel in control-center (2) a standalone panel in control-center (3) changing the existing UI in software-properties-gtk.
[08:57] <mpt> That's why the title of the window is "System Settings", for example
[08:58] <pitti> mpt: understood;  but I guess as long as software-properties provides the control-center "software" settings, it should go there?
[08:58] <mpt> pitti, I don't know what you mean by "provides".
[08:59] <pitti> software-properties is the program which has the other two tabs ("software channels" and "updates"), not software-center
[08:59] <mpt> pitti, yes, that's option 3 above
[09:00] <pitti> and s-properties has a -kde variant, software-center doesn't
[09:00] <mpt> software-center?
[09:01] <mpt> Do you mean gnome-control-center?
[09:01] <pitti> mpt: I mean that for Kubuntu we could implement the third tab easily in software-properties-kde
[09:01] <pitti> but as Kubutnu doesn't use software-center, it would need something entirely new
[09:01] <pitti> I'll mail u-devel@ and the KDE guys about that
[09:01] <mpt> pitti, what does this have to do with software-center?
[09:01] <pitti> about teh option
[09:02] <pitti> mpt: I'm thinking what to replace jockey-kde with
[09:03] <mpt> KDE has a centralized System Settings too, right? I remember people being annoyed that Gnome used the same name
[09:03] <mpt> So the same three options would apply there.
[09:04] <mvo> mpt: I noticed some inconsitencies in the _Menuitem in software-center, AIUI we don't want to have the "_Close" etc at all? context is bug #744655
[09:04] <ubot2> Launchpad bug 744655 in software-center "a11y: "Deauthorize" and "Cancel" without accelerators" [Undecided,New] https://launchpad.net/bugs/744655
[09:09] <mpt> mvo, where does the string "Get private launchpad repositories" appear?
[09:16] <asac> cyphermox: bug 1004384
[09:16] <ubot2> Launchpad bug 1004384 in gnome-control-center "crashes when selecting bluetooth input device in sound control center" [Undecided,New] https://launchpad.net/bugs/1004384
[09:19] <chrisccoulson> happy friday everyone
[09:19] <seb128> chrisccoulson, hey, happy friday! how are you?
[09:20] <chrisccoulson> seb128, yeah, not too bad thanks, although i had a bit of a late night last night. i'm not going to rest until i can play angry birds in firefox again ;)
[09:20] <chrisccoulson> how are you?
[09:20] <seb128> asac, can you get a full stacktrace on that bug?
[09:20] <seb128> chrisccoulson, I'm good thanks
[09:20] <seb128> chrisccoulson, so it was not the hardening?
[09:21] <chrisccoulson> seb128, no, it must be a race condition, as it's turning on debug information which fixes it ;)
[09:22] <asac> seb128: the full backtrace i had from retracing was useless because it had no control center functions in and the rest was just callbacks and marshalls etc.
[09:23] <asac> seb128: the new backtrace i have has the gnome-control center bits in, but the rest not and i prefer to not install dbgsym
[09:23] <seb128> asac, ok
[09:23] <asac> anyway... i believe the null ref is clear enough
[09:24] <asac> i have one more step with symbols ... will attach that
[09:24] <seb128> asac, right, I don't know the code enough to know if having it being null is a bug by itself or not
[09:24] <asac> it is :)
[09:24] <asac> and its the code that was changed in the patch
[09:24] <asac> for last update
[09:24] <asac> so i think it should be fine
[09:24] <asac> ok attached the bt full
[09:25] <asac> well ... the part that had anything
[09:25] <seb128> asac, seems a bit similar to bug #981963
[09:25] <ubot2> Launchpad bug 981963 in gnome-control-center "[soundnua]: gnome-control-center crashed with SIGSEGV in gvc_mixer_control_change_input()" [Medium,Incomplete] https://launchpad.net/bugs/981963
[09:29] <chrisccoulson> hey asac, how are you?
[09:31] <asac> chrisccoulson: no bluetooth, no calls :) (j.k.)
[09:32] <asac> chrisccoulson: tomorrow flying to hong kong. not sure if i am happy about that (yet) :)
[09:32] <seb128> asac, living a real businessman live? ;-)
[09:32] <asac> and now firefox crashed :)
[09:33] <asac> seb128: not really... i skipped UDS for instance :)
[09:34] <chrisccoulson> asac - yeah, the bar ended up with a whisky surplus because you were not there ;)
[09:34] <asac> lol
[09:35] <asac> not exactly what a whisky surplus means. guess you say they had more at the end than in the beginning? i thought ogra would compensate
[09:35] <seb128> asac, we missed you at UDS!
[09:36] <mpt> mvo, I don't see any "_Close" in that patch, but I've reviewed it in the bug report.
[09:38] <asac> seb128: :(
[09:41] <mvo> mpt: very nice, thanks
[09:42] <mvo> mpt: i looks like we have some inconsitencies in the menu already, I will look at this
[10:32] <tkamppeter> pitti, I have a package which is not multi-arched (as it does not ship a lib) but it installs CUPS filters in /usr/lib/x86_64-linux-gnu/cups/filter/? Do I now have to explicitly suppress multiarching? It is printer-driver-ptouch, synced from Debian, but builds also incorrectly under Ubuntu.
[10:40] <seb128> pitti, mvo: is there a package description "freeze" for stable serie?
[10:41] <seb128> pitti, mvo: there is a SRU for "unity-mail" in the sponsoring queue which change the control description, I was wondering if that's allowed for a stable update
[10:42] <mitya57> seb128: the previous one was rendered in SC incorrectly
[10:42] <mitya57> seb128: but I can revert the change
[10:42] <seb128> mitya57, well, I don't discuss that, but package descriptions are translated so I'm asking for details
[10:43] <seb128> mitya57, it would help if that change had a bug reference or an explanation of the issue
[10:43] <mitya57> seb128: I thought that only short descriptions (those in app-install-data) are translated
[10:44] <mitya57> seb128: ok, I can file a bug for that
[10:44] <seb128> mitya57, thanks
[10:51] <seb128> mvo, tremolux: did you see https://errors.ubuntu.com/bucket/?id=/usr/share/software-center/software-center:IndexError:do_render:_render_summary:get_markup:capitalize_first_word ?
[10:52] <seb128> it's on top of errors.ubuntu.com today ... is that a regression from the SRU moved to updates yesterday?
[10:52] <seb128> mvo, tremolux: unping, seems one of the bugs fixed in the .1 update
[11:12] <mitya57> seb128: bug 1004433
[11:12] <ubot2> Launchpad bug 1004433 in unity-mail "The description is rendered incorrectly in the software-center" [Undecided,New] https://launchpad.net/bugs/1004433
[11:16] <seb128> mitya57, thanks
[11:31] <mvo> seb128: hm, we should probably fasttrace 5.2.2.1 to -updates then to avoid this, this is a bit unfortunate (i.e. miscommunication on our part)
[11:31] <mvo> eh, fasttrack
[11:31] <seb128> mvo, yeah, agreed
[11:32] <seb128> mvo, it shows up that errors.ubuntu.com is working nicely though ;-)
[11:33] <mvo> indeed it is
[11:34] <mvo> thanks for the heads up
[11:59] <pitti> good bye everyone, and have a nice weekend! have to leave a bit early today
[11:59] <pitti> I'll be off on Monday
[13:12] <cyphermox> asac: thx
[13:12] <cyphermox> asac: btw, connman is in Debian NEW now
[13:13] <cyphermox> but I guess you must have received the email
[13:15] <asac> cyphermox: did you help samoa?
[13:15] <asac> he pinged me this morning
[13:15] <cyphermox> I didn't talk to any samoa
[13:16] <cyphermox> was working with an Andrew Brouwers
[13:17] <seb128> cyphermox, hey, how are you?
[13:17] <seb128> cyphermox, the bug asac pointed already got handled
[13:17] <cyphermox> seb128: hey seb128, doing alright, and you?
[13:17] <seb128> cyphermox, I'm good thanks!
[13:17] <cyphermox> it's just really humid today outside, so it feels like it's a thousand degrees
[13:18] <seb128> weather is quite hot here as well this week
[13:19] <asac> cyphermox: i asked you a few weeks back to ping samoa who was looking for a sponsor/review, remember?
[13:19] <asac> seems you dropped the ball though :)
[13:19] <asac> cyphermox: sameo
[13:19] <asac> is his nick
[13:19] <asac> if he hasnt pinged you
[13:19] <asac> maybe ping him
[13:19] <asac> he might want to help in future
[13:20] <cyphermox> asac: on OFTC?
[13:20] <cyphermox> seb128: desktop branches == Maintainer: Ubuntu Desktop Team ?
[13:21] <seb128> cyphermox, usually yes
[13:21] <cyphermox> ok, I wasn't aware :)
[13:21] <asac> cyphermox: no on freenode
[13:21] <seb128> cyphermox, but it's a convention, we are not really picky about it
[13:21] <asac> cyphermox: or on both... not sure
[13:21] <asac> i talked through freenode
[13:22] <cyphermox> ok
[13:30] <cyphermox> asac: ok, I talked to Samuel, he's very happy and all. we'll just need to merge the current packaging with what Patrick Flykt did in his git tree
[13:31] <asac> cyphermox: ok. as long as he is happy, i am happy :)
[13:31] <asac> cyphermox: thanks for talking to him
[13:34] <asac> seb128: any idea why the apport-retrace stacktrace had no symbols for /usr/lib/control-center-1/panels/libsoundnua.so ... bug in our dbgsym packages?
[13:35] <seb128> asac, is that you local build? maybe md5sum difference ... what does gdb says about symbol loading when you start it?
[13:36] <asac> seb128: no... initially i did a apport-retrace for .crash file i got with latest packages
[13:36] <asac> only after that didnt have the symbols for /usr/lib/control-center-1/panels/libsoundnua.so i built the package locally
[13:37] <asac> just looks suspicious as its not in normal /usr/lib/ ...
[13:37] <seb128> asac, I don't know then, what version of gnome-control-center is installed for you?
[13:37] <seb128> asac, the path is not an issue
[13:37] <asac> 1:3.4.1-0ubuntu2
[13:37] <asac> ok
[13:37] <asac> well. maybe the build system manually strips those somehow
[13:37] <asac> or something else bogus
[13:38] <asac> lets not investigate :)
[13:39] <seb128> asac, they are usually fine, the retracing we got on launchpad were ok so far
[13:52] <seb128> cyphermox, btw not sure if you noticed but I assigned you bug #986991 some weeks ago, would be nice if you could have a look to see if that's an issue we should keep on our list
[13:52] <ubot2> Launchpad bug 986991 in gnome-control-center "Hostname left to "ubuntu-0" in Bluetooth settings after install from live cd" [Low,Confirmed] https://launchpad.net/bugs/986991
[13:53] <cyphermox> seb128: ah, I commented on another bug report about that issue
[13:53] <seb128> cyphermox, can you find out the number of the other bug and share it? ;-)
[13:53] <cyphermox> yeah
[13:58] <seb128> cyphermox, thanks ;-)
[14:09] <cyphermox> seb128: confirm, we still don't have a hostnamed helper?
[14:10] <seb128> cyphermox, no we don't
[14:10] <cyphermox> ok
[14:10] <seb128> but we should in q
[14:10] <cyphermox> so that's "part" of what the issue is for the bluetooth name
[14:10] <cyphermox> but for it to remain ubuntu-0, there must be something else.
[14:11] <seb128> ok, I knew that without it you couldn't change your hostname from the ui
[14:11] <seb128> but I didn't realize the installer was relying on that
[14:11] <seb128> cyphermox, well, bug #962369 is the "can't rename" bug
[14:11] <ubot2> Launchpad bug 962369 in gnome-control-center "Cannot set Device name (hostname) under Details section in System Settings on 12.04" [Wishlist,Triaged] https://launchpad.net/bugs/962369
[14:12] <cyphermox> yeah
[14:12] <cyphermox> and somehow someone thought it would be a good idea to cripple bluez to follow this setting for the device name
[14:18] <cyphermox> but I'm still unclear as to why it would be set to "ubuntu" anywhere; it's definitely working just fine here
[14:19] <tkamppeter> seb128, I have a small problem with multi-arch.
[14:20] <tkamppeter> seb128, I have a package which is not multi-arched (as it does not ship a lib) but it installs CUPS filters in /usr/lib/x86_64-linux-gnu/cups/filter/? Do I now have to explicitly suppress multiarching? It is printer-driver-ptouch, synced from Debian, but builds also incorrectly under Ubuntu.
[14:23] <tkamppeter> seb128, problem is that dh puts "--libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu" and I did not find a way to suppress it.
[14:25] <cyphermox> jbicha: if you still want to play with evolution, wanna rebuild/fix evolution-exchange?
[14:29] <jbicha> http://people.canonical.com/~ubuntu-archive/transitions/evolution3.4.html
[14:30] <jbicha> what does it mean when it says evolution-exchange is dependency level 2
[14:44] <cyphermox> jbicha: that's a very good question
[14:44] <cyphermox> Laney: ? ^
[14:46] <cyphermox> jbicha: if you want another good list; take a look at http://people.canonical.com/~ubuntu-archive/nbs.html, for libcamel, libebackend-1.2-1 and other libe*
[14:46] <jbicha> I guess it comes from depend on evolution-dev which is level 1 but ok now
[14:56] <cyphermox> seb128: rebuilding gvfs, anything to be done to it at the same time?
[15:02] <cyphermox> actually, it's not just a rebuild anymore
[15:02] <cyphermox> seb128: do you know how to test the volume monitors for gvfs? is it as simple as plugging in a removable drive and waiting?
[15:03] <seb128> cyphermox, why do you need to build it? is that q? no change planned
[15:03] <cyphermox> seb128: NBS
[15:03] <cyphermox> libgdu0 removed in the new gnome-disk-utility, replaced by udisks2
[15:03] <cyphermox> seb128: gvfs already can build (and does) build the udisks2 monitor, but it wasn't being installed
[15:05] <seb128> cyphermox, I read a comment from robert_ancell this morning saying he failed to drop libgdu from gvfs or it's still built with udisk1 and udisk2 but dropping udisk1 support make automount not work
[15:05] <seb128> cyphermox, usually gvfs-mount -li and plug a device
[15:06] <cyphermox> ok
[15:06] <cyphermox> I'm not really having to drop anything though
[15:07] <cyphermox> gvfs ftbfs as-is right now
[15:07] <seb128> cyphermox, ok, found it, https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1002556
[15:07] <ubot2> Launchpad bug 1002556 in gvfs "Update to 1.13.0" [Wishlist,In progress]
[15:07] <cyphermox> err
[15:08] <cyphermox> we alrady have gvfs 1.13.0 in quantal
[15:09] <seb128> cyphermox, right, he reopened the bug due to the udisk1 screwup, I guess it builds fine with the libgdu installed
[15:09] <seb128> cyphermox, which he probably had
[15:09] <cyphermox> oh, I see
[15:09] <seb128> cyphermox, lp:~robert-ancell/gvfs/ubuntu has the fixed packaging
[15:09] <seb128> cyphermox, but then mounting breaks apparently...
[15:10] <seb128> cyphermox, if you want to get out of the ftbfs issue for the w.e I would suggest just adding the bd back and ship with both backends until we sort why udisk2 doesn't work
[15:10] <seb128> which is likely a pitti sort of bug
[15:11] <cyphermox> seb128: well, it will work properly for now
[15:11] <seb128> cyphermox, right, still we should drop the udisk1 backend and get the udisk2 one to work
[15:11] <seb128> cyphermox, but no hurry for that
[15:12] <seb128> cyphermox, just get the build-depends back
[15:12] <cyphermox> well, I didn't touch anything
[15:13] <seb128> cyphermox, sorry, I'm starting again
[15:14] <seb128> cyphermox, I think robert_ancell intended to drop the udisk1 backend in 1.13 and dropped the build-depends on libgdu (which is used for udisk1)
[15:14] <seb128> cyphermox, just restore them and do a new upload if you want to fix the ftbfs
[15:14] <seb128> cyphermox, where we want to get is to merge lp:~robert-ancell/gvfs/ubuntu and figure why that version is buggy though, but that can wait
[15:14] <cyphermox> right
[15:15] <cyphermox> but I don't especially feel strongly about fixing the ftbfs
[15:15] <cyphermox> I *will* try out gvfs with robert's changes locally though, and debug it after EOD or over the weekend if I have time
[15:17] <seb128> desrt, hey
[15:17] <desrt> seb128: hello
[15:17] <seb128> desrt, you were using udisks2 iirc on precise and had issues similar to https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1002556/comments/2
[15:17] <ubot2> Launchpad bug 1002556 in gvfs "Update to 1.13.0" [Wishlist,In progress]
[15:17] <seb128> desrt, did you ever fix those?
[15:17] <desrt> seb128: i reported them to pitti and he said that he fixed them
[15:17] <seb128> ok
[15:18] <seb128> I will have to check with him next week
[15:18] <seb128> desrt, thanks
[15:18] <desrt> quite some time ago
[15:18] <desrt> seb128: btw: many are wondering: where is the glib SRU?
[15:18] <seb128> cyphermox, don't spend too much time on it, pitti knows those components better and he might know off hand what to check
[15:19] <seb128> desrt, coming, it was on my list for today, I didn't want to do both gtk and glib mixed together and gtk has user visible fixes so I did it first
[15:19] <seb128> was -> still is ;-)
[15:19] <desrt> seb128: glib has programmer-visible fixes :)
[15:19] <desrt> seb128: programmers are users too!!
[15:19] <seb128> yeah, iz coming ;-)
[15:19] <desrt> :)
[15:19] <seb128> I like annoying programmer, I can't get a good ranting from other users :p
[15:20] <desrt> it's true
[15:21] <desrt> programmers are better ranters, in general
[15:21] <desrt> and the more epic the programmer, the more epic the rants
[15:21] <seb128> ;-)
[15:21]  * desrt cites a few obvious examples that need not be named
[15:22] <seb128> desrt, btw you got another bug from your friends at google on dconf complaining about it aborting on profile lines > 80 chars ;-)
[15:22] <desrt> SERIOUSLY?
[15:22] <seb128> yes ;-)
[15:23] <desrt> are they reading the code and filing bugs about things that they think are slightly icky?
[15:23] <seb128> desrt, well the bug is a bit stupid, they have checksum comments in the profiles and the code has the same limitation for comment lines
[15:23] <desrt> or do they actually have a database with more than 80 characters in the filename?
[15:23] <desrt> ah.
[15:23] <desrt> okay.  that's legit.
[15:23] <seb128> ;-)
[15:24] <seb128> not a high priority issue, but I though you would like it :p
[15:25]  * desrt fixes the bug by removing possibility of comment lines :D
[15:26] <tkamppeter> seb128, did you see my messages?
[15:26] <seb128> tkamppeter, sorry, I was away when you wrote that and didn't read all the scrollback yet, reading
[15:28] <seb128> tkamppeter, is it using compat 9? that does multiarch by default with dh
[15:32] <seb128> tkamppeter, the package install in that dir in debian as well, so I would say Debian has the same bug
[15:32] <seb128> tkamppeter, you either need to move back the files in the dir in the rules or lower the compat to 8
[15:37] <seb128> tkamppeter, slangasek says to just override dh_auto_configure --libexecdir
[15:39] <tkamppeter> seb128, this implementation has a bug, only libraries (/usr/lib/lib*.so*) should be multi-arched, not any non-lib executables like for example CUPS filters.
[15:39] <seb128> tkamppeter, see #ubuntu-devel and what slangasek just wrote
[15:40] <tkamppeter> seb128, thanks.
[15:40] <seb128> tkamppeter, you're welcome
[15:56] <seb128> mterry, hey
[15:57] <seb128> mterry, did you try gnome-contacts with adwaita?
[15:57] <seb128> mterry, there is quite some specific css work to make it looks nice, it doesn't work well on light-themes
[15:57] <seb128> mterry, kenvandine has a workitem to import the app css in our theme for this cycle
[16:00] <mterry> seb128, hello
[16:00] <mterry> seb128, OK, haven't seen it in adwaita yet myself
[16:02] <seb128> mterry, I'm just saying since I saw you bounced back the bug to jasoncwarner_ (which by experience doesn't work well, you might want to try direct email rather)
[16:02] <mlankhorst> eod :-)
[16:02] <seb128> mlankhorst, eow
[16:03] <ogra_> meow
[16:03] <mterry> seb128, can you link me the bug?
[16:04] <seb128> mterry, 833383 you mean?
[16:04] <seb128> i.e the MIR?
[16:04] <mterry> seb128, ah yes!
[16:04] <mterry> seb128, now I'm on the same page
[16:05] <mterry> seb128, I'll email him
[16:05] <seb128> mterry, thanks
[16:05] <seb128> mterry, and maybe have a try with adwaita
[16:05] <seb128> or push kenvandine so he get the theming in light-themes and cross the workitem ;-)
[16:06] <seb128> cyphermox, bug #1004384 has a fix in proposed btw (the one you discussed with asac earlier)
[16:06] <ubot2> Launchpad bug 1004384 in gnome-control-center "[soundnua]: segfaults when selecting bluetooth input device" [High,Fix committed] https://launchpad.net/bugs/1004384
[16:07] <cyphermox> yeah I saw it earlier this morning in the queue
[16:07] <seb128> ok, on that I'm out for a bit, will read the backlog then and call it a week
[16:07] <seb128> bbiab
[16:52] <jbicha> cyphermox: could you rebuild folks?
[16:53] <cyphermox> jbicha: shortly, yes
[16:53] <cyphermox> is it rush?
[16:53]  * cyphermox would like to go out to eat soon
[17:06] <jbicha> cyphermox: no go ahead and eat!
[17:11] <cyphermox> Ok. I'll do it as soon as I'm back
[17:17] <kenvandine> seb128, i look at the theming stuff again real soon :)
[17:22] <kenvandine> mterry, there are two things we really need to do for gnome-contacts before we include it by default
[17:22] <kenvandine> add the styling we are missing to our theme
[17:22] <kenvandine> and reduce the noise, filter out "uncategorized contacts" by default
[17:23] <kenvandine> you end up with all the auto added contacts from gmail in there, which nobody wants to see :)
[17:25] <mterry> kenvandine, I thought the GNOME line on that was such entries are an accurate reflection of your contacts and the user should merge them as desired
[17:37] <kenvandine> mterry, i hadn't talked to anyone yet
[17:37] <kenvandine> but i think filter those out make sense
[17:37] <kenvandine> on android they are filtered out automatically
[17:37] <kenvandine> you can show them, but by default they aren't
[17:37] <kenvandine> they are really only there so auto-complete works for email :)
[17:39] <mterry> fair enough
[17:39] <kenvandine> i'll contact upstream on it and see what they think
[19:49] <cyphermox> jbicha: still working on evolution packages?
[19:51] <jbicha> cyphermox: not at the moment, I guess there's a few more I could grab though
[19:51] <cyphermox> I can look at evolution-exchange if you didn't do changes already
[19:53] <jbicha> cyphermox: I already did that one
[19:54] <jbicha> http://people.canonical.com/~ubuntu-archive/transitions/evolution3.4.html is up to date except I did empathy also
[19:55] <kenvandine> jbicha, cyphermox: i can do evolution-indicator
[19:55] <jbicha> kenvandine: cool because that one wouldn't build for me
[19:55] <kenvandine> yeah
[19:55] <kenvandine> still uses gconf
[19:55] <cyphermox> yeah, it's magic :)
[19:56] <kenvandine> but i don't think those settings have showed up in the UI in quite some time :)
[19:57] <cyphermox> hehe
[19:57] <cyphermox> ok, sorry, I thought I was still seeing -exchange in NBS
[19:59] <cyphermox> ah, I see, it's still in probs because there's a change missing (not your fault jbicha, I screwed that one up a few times myself)
[20:00] <cyphermox> jbicha: if you want to do another upload, check evolution-exchange Depends: it clamps the allowed evolution version to >3.2 <<3.3; should be >3.4 <<3.5
[20:00] <cyphermox> (or I'll do it)
[20:01] <jbicha> cyphermox: I can do that
[20:01] <jbicha> do we need the << line? won't that just cause more annoyance than help?
[20:03] <cyphermox> evolution-exchange might not work on a newer evo; but I tend to agree
[20:03] <cyphermox> I'd just leave it as-is to avoid further delta though
[20:06] <jbicha> what's the URL to that quantal problems page?
[20:08] <mterry> Is apport not working for anyone else?  (I say to report it and I never get a page opened in my browser)
[20:09] <cyphermox> jbicha: http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
[20:23] <achiang> hello, i'm playing around with lightdm and the greeter and am wondering -- is there anything wrong (other than speed) with calling /etc/X11/Xsession a 2nd time, *after* lightdm is started? will that break anything in terms of correctness?
[20:24] <achiang> all i really want to do is to source the files in /etc/X11/Xsession.d/* a second time, which Xsession seems to do for you
[20:24] <achiang> mterry: any thoughts there? ^^
[20:25] <mterry> achiang, I've never tried that...
[20:25] <mterry> achiang, don't those scripts launch something?
[20:25] <mterry> (i.e. the session)
[20:25] <achiang> mterry: i tried it yesterday and it *seems* to be ok, but wondering if there are pitfalls i'm unaware of
[20:25] <achiang> mterry: surprisingly, the Xsession script doesn't actually start anything
[20:25] <mterry> huh
[20:26] <mterry> achiang, then I guess it would be safe
[20:26] <achiang> mterry: ok, thanks
[20:37] <dobey> huh
[20:38] <dobey> bother. stuff in quantal is broken :(
[20:43] <cyphermox> dobey: what stuff?
[20:44] <dobey> looks like glib introduced a new #error, and liboauth broke linking
[20:44] <dobey> /usr/lib/x86_64-linux-gnu/liboauth.so.0: undefined reference to `curl_easy_cleanup@CURL_3'
[20:45] <cyphermox> fun; but at least this shouldn't be very hard to fix
[20:46] <dobey> doesn't have to be hard to be annoying/frustrating :)
[20:47] <cyphermox> indeed; but it's a dev release ;)
[20:48] <dobey> the glib thing is the really annoying one though. sacrificing compiler performance to force people to include a single header which includes all the others, including the 50 you don't need
[20:53] <dobey> oh well
[21:08] <kenvandine> jbicha, evolution-indicator is done... it really needs porting to gsettings too
[21:09] <kenvandine> but at least it builds and loads again :)
[22:07] <Laney> jbicha: the package names have tooltips