[00:35] <jbicha> robert_ancell: you didn't start on nautilus 3.5.4, did you?
[01:13] <jbicha> the Ubuntu patches don't do well with Nautilus' menu reorg...
[01:14] <TheMuso> Sad that the go menu was removed... That was useful.
[01:18] <jbicha> oh wow, those monochrome sidebar icons are striking
[01:18] <jbicha> I hate how the gear menu on the far right has so many submenus with the arrows pointing right but opening left :(
[01:49] <robert_ancell> jbicha, nope
[01:50] <jbicha> I can get it to compile, but not without disabling several of the patches
[01:51] <robert_ancell> jbicha, ech
[01:52] <robert_ancell> jbicha, how is the gnome flavour going btw?
[01:53] <jbicha> robert_ancell: it's not going, it's a lot of work to understand how to build a CD
[01:54] <robert_ancell> jbicha, did you get anywhere. Is there a Wiki page or anything? I'd love to help if I can
[01:55] <jbicha> I did manage to hack a build a CD and get it to install
[01:56] <jbicha> the live environment didn't work though, I'm not sure what I need to change to get gnome to run instead of the ubuntu session
[01:56] <jbicha> the theming looked pretty bad too
[01:58] <jbicha> I'll look at it again later this week or so and let you see what it looks like
[02:01] <jbicha> ok, I'm done with nautilus for tonight, I pushed what I had to bzr
[02:01] <robert_ancell> jbicha, nice, thanks!
[02:02] <TheMuso> jbicha: From your above comments re GNOME flavour, Canonical aren't going to build it?
[02:05] <jbicha> the GNOME flavor is not an official Canonical project, it would be equivalent to Kubuntu or Xubuntu
[02:05] <TheMuso> Yes but Canonical builds those.
[02:06] <TheMuso> To be precise, Canonical offers build and hosting infrastructure for those.
[02:06] <jbicha> at this point it looks unlikely it will even be an official flavor for 12.10 but there's still time for that to change
[02:06] <TheMuso> Ok.
[02:06] <jbicha> the image has to work first, then we can apply to the Tech Board to be official
[02:07] <TheMuso> ...which means someone has to build it, which is not an easy task, if you want to take the ground up image build approach used by all official flavours.
[02:08] <jbicha> yeah, making the seed isn't too terribly difficult but getting all the pieces to work well together is more of a challenge
[02:09] <jbicha> oh, and some point we'll need to ask the GNOME Foundation about what we'll be allowed to name the thing
[02:09] <TheMuso> Yup, I know, I've set up the infrastructure here locally for another project myself.
[02:14] <robru> Hey guys, how is everybody tonight?
[02:16] <robru> I have a question about the way python modules are packaged in Ubuntu, you lot seem like you might know a thing or two about it ;-)
[02:18] <robru> Specifically, why are all the system python modules installed in 'dist-packages', and why does distutils try to install my module into 'site-packages', and is this a bug in the way distutils is packaged for Ubuntu? distutils works fine on Fedora but './setup.py install' doesn't work on Ubuntu.
[02:18] <robru> (in Fedora there is no dist-packages, only site-packages, and everything is happy that way)
[02:20] <robru> I see that Python's sys.path doesn't include any kind of site-packages directory at all, and I'm halfway through writing a workaround in which I manually add site-packages to sys.path, though it occurred to me that a more correct solution might be to patch distutils to install things into dist-packages instead. Seems odd that distutils by default would be installing modules into a place where python itself doesn't kno
[02:20] <robru> w to look for them. Hardly seems like my program's fault at all, in fact...
[02:55] <robru> distutils, naturally, has an option --install-layout=deb, that should pretty much be default on ubuntu but isn't, not sure if that's a bug then.
[03:30] <robru> Ah, https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/362570
[03:30] <ubot2> Ubuntu bug 362570 in python2.6 "Python distutils installs into 'site-packages' instead of 'dist-packages' when a prefix is set" [Wishlist,Fix released]
[03:30] <robru> hah, just found that right before you said it
[03:31] <robru> wait, bot.
[03:31] <robru> lol
[03:33]  * TheMuso was going to say something but...
[03:33] <TheMuso> :)
[03:33] <robru> if you hadn't noticed, I'm new here! Yaaaaay newbies!
[03:40] <TheMuso> No I haven't noticed. I see so many people joining/leaving, and I don't really pay attention to those status messages.
[03:41] <robru> Right, anyway. I don't suppose you have an opinion on the site-packages/dist-packages issue? I don't personally have a  preference either way, but the fact that the installed-to location is not in the default python search path is surely a bug? With the current behavior, when somebody runs 'sudo ./setup.py install', the resulting installation is broken (running the program raises ImportError because python can't find
[03:41] <robru> the thing that distutils just installed).
[03:43] <TheMuso> No sorry, I don't do alot with python so far as package install locations etc goes, I just go with the flow.
[03:45] <robru> https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/362570/comments/10 this is *exactly* the crux of the issue that I'm having. I've pushed a really hacky ubuntu-specific workaround to my users but it's quite ugly insofar as it involves having setup.py check that it's running on Ubuntu, and change the install prefix. distutils should be smarter than this, and my module's own setup.py shouldn't have to care what s
[03:45] <ubot2> Ubuntu bug 362570 in python2.6 "Python distutils installs into 'site-packages' instead of 'dist-packages' when a prefix is set" [Wishlist,Fix released]
[03:45] <robru> ystem it's running on.
[03:46] <TheMuso> You actually might want to ask in #ubuntu-devel, as that channel is more for that kind of stuff, this channel is mostly for desktop related development discussion.
[03:47] <robru> Ah. well now that I've found the bug I'll just comment on that.
[03:48] <TheMuso> Ok.
[04:14] <thumper> hi folks
[04:14] <thumper> have there been recent (like in the last day or two) updates to gdk/gtk?
[04:14] <thumper> in quantal?
[04:14] <thumper> we've hit some interesting bugs
[04:14] <thumper> unity crashing type bugs
[04:15] <thumper> seems to be gtk_widget_event from the mainloop
[04:15] <thumper> we're still investigating
[04:25] <Sarvatt> [
[04:25] <Sarvatt> oops, sorry
[04:33] <TheMuso> thumper: Lastest GTK3 upload was on July 11.
[04:36] <thumper> TheMuso: thanks...
[04:57] <thumper> hmm...
[04:57] <thumper> is there any way to see what changed in quantal in the last two days?
[04:57] <thumper> we're trying to track down changes in the system
[04:58] <RAOF> thumper: It's easy to tell what changed on your machine in the last two days; check out software centre.
[04:58] <thumper> does that tell you?
[04:58] <TheMuso> Ah. Was about to suggest also loking at the quantal-changes list archives.
[04:58] <RAOF> thumper: Specifically, the “History” button.
[04:58] <TheMuso> looking
[04:59] <RAOF> thumper: That'll give you the list of all the things you've installed/removed, or upgraded, their versions, and when it happened (it's grouped by day)
[04:59] <thumper> unfortunately not super useful for our test system
[04:59] <thumper> which boots a CD image and updates :)
[04:59] <RAOF> Aaah. Yeah, that's super unuseful.
[05:00] <TheMuso> Well I think quantal-changes archives is the next best thing.
[05:00] <TheMuso> Unless someone knows of something else that is better.
[05:00] <RAOF> Yeah, quantal-changes is probably the winner here.
[05:05] <pitti> Good morning
[05:18] <didrocks> good morning
[05:25] <pitti> bonjour didrocks, ca va?
[05:27] <didrocks> pitti: guten morgen, I'm fine, thanks! yourself?
[05:39] <pitti> didrocks: I'm quite fine, thanks
[05:39] <pitti> almost through with the morning mail flood, then getting back to u-d-c
[05:39] <didrocks> pitti: sweet! I have to change big chunks of code of software-properties anyway (looking at why it got so many crashes when starting policykit transactions…)
[05:42] <pitti> didrocks: but hopefully the new API should make it quite a bit easier on the client side?
[05:45] <didrocks> pitti: well, yeah, the issue is that a rewrite of the functionnality would be the best, all the UI and logic is melt in the current code, the handling of the transaction is ackward :/
[05:45] <didrocks> pitti: I'm wondering between patching and trying to get things back on shape… but if we want it in alpha3
[05:45] <didrocks> I don't want to spent 2 weeks to rewrite everything/clean that, I was just ask to help
[05:48] <pitti> didrocks: I thought eventually this would move into software-center anyway?
[05:48] <pitti> which would be a rewrite
[05:50] <didrocks> pitti: yeah, so maybe let's just try to get it working right now :/
[05:51] <didrocks> everything is hardcoded, starting from scratch would have been easier I guess
[05:51] <didrocks> not taken into accout that values can be refreshed
[06:54] <didrocks> pitti: ok, I think I just finished getting it in shape (meaning working, especially in tricky case). I simulated the "manually installed" driver case for now
[06:57] <pitti> didrocks: nice! I have the implementation half-done
[06:57] <pitti> for the manual_install flag, I mean
[06:57] <didrocks> pitti: \o/
[07:01] <didrocks> pitti: g+ addict! :-)
[07:01] <pitti> didrocks: my mobile was humming..
[07:02] <didrocks> heh :-) /me hugs pitti
[07:04]  * pitti hugs back didrocks
[07:07] <pitti> hah! test pass!
[07:08] <didrocks> great!
[07:27] <pitti> didrocks: I extended fake-devices-wrapper to look at e. g. FAKE_INSTALLED_KMOD=nvidia
[07:27] <pitti> didrocks: I figured an env var is easier than a command line option, as parsing that would interfere with command line options from the wrapped program
[07:27] <pitti> but I guess that's "good enough"
[07:27] <pitti> FAKE_INSTALLED_KMOD=nvidia ->
[07:28] <pitti> == /tmp/tmptk910i/devices/nvidiacard ==
[07:28] <pitti> modalias : pci:v000010DEd000010C3sv00sd01bc03sc00i00
[07:28] <pitti> manual_install: True
[07:31] <pitti> didrocks: u-d-common .66 uploaded, enjoy!
[07:34] <didrocks> pitti: \o/
[07:34] <didrocks> pitti: will use it right away with the env variable to ensure everything is working
[07:52] <didrocks> pitti: seems that find_cookie didn't find any of them to accomodate your coffee: https://launchpadlibrarian.net/110369564/buildlog_ubuntu-quantal-i386.ubuntu-drivers-common_1%3A0.2.66_FAILEDTOBUILD.txt.gz
[07:52] <didrocks> famous UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 32: invalid start byte
[07:52] <didrocks> even in python3 //
[07:53] <didrocks> pitti: if someone is discussing on g+ and the other answer on IRC, this will become tricky :)
[07:54] <pitti> didrocks: lol
[07:54] <pitti> I just saw this
[07:54] <pitti> regression from this night's python3.2 upload apparenlty?
[07:54] <pitti> (just said so in #u-devel)
[07:54] <didrocks> yeah, seeing that, thanks!
[07:54]  * pitti dist-upgrades
[07:54] <didrocks> I think I will never understand those utf-8 encoding/decoding errors
[07:54] <didrocks> seems easy on the paper
[07:54] <didrocks> but so many cases…
[07:55] <didrocks> and as you told, it seems that opening file isn't safe anymore? you still have to open them as bytes in python3?
[07:55] <pitti> but it's not even getting to my code yet, that's distutils
[07:55] <didrocks> indeed…
[07:55] <pitti> didrocks: well, that or explicitly add encoding='UTF-8' to the open() call
[07:55] <pitti> but that's not python2 compatible
[07:56] <pitti> otherwise it defaults to the locale's encoding
[07:56] <pitti> which makes sense in some way, but totally breaks with our build environments which insist on C
[07:56] <didrocks> ah, so all files are not ensured to be 100% UTF-8, I was thinking that it was something that python3 assured
[07:56] <didrocks> yeah
[07:57] <didrocks> will add encoding='UTF-8' I think ;)
[08:01] <seb128> hey desktopers
[08:01] <didrocks> salut seb128, ça va?
[08:01] <pitti> bonjour seb128
[08:02] <seb128> lut didrocks, guten tag pitti
[08:02] <seb128> how are you?
[08:02] <seb128> didrocks, ca va bien ! ;-)
[08:04] <didrocks> seb128: ça va bien ici aussi :)
[08:04] <seb128> ok, special offer today, I offer a webkit to whoever raise his hand first!
[08:05] <seb128> do we have any taker?
[08:06] <pitti> seb128: dude, you realy have to work on your marketing sk1llz
[08:06]  * pitti hugs seb128
[08:07]  * seb128 hugs pitti
[08:07] <pitti> Laney: were you meaning to sync the new glib 2.33.4?
[08:08] <seb128> I pushed the new webkit version to the ubuntu-desktop ppa yesterday evening thinking I would thinking I would wake up with debs
[08:08] <seb128> but I woke up with "cp: writing `debian/libwebkitgtk-1.0-0//usr/lib/libwebkitgtk-1.0.so.0.13.1': No space left on device"
[08:08] <seb128> not quite what I wanted :-(
[08:10]  * didrocks looks why using git trunk, the manual driver doesn't appear under the env variable
[08:10] <pitti> didrocks: how are you calling s-properties exactly?
[08:11] <didrocks> pitti: PYTHONPATH=".:/home/didrocks/work/software-properties/ubuntu-drivers-common:/home/didrocks/work/software-properties/ubuntu-drivers-common/tests" /home/didrocks/work/software-properties/ubuntu-drivers-common/share/fake-devices-wrapper ./software-properties-gtk --data-dir=data
[08:11] <seb128> Laney, congrats on being accepted coredev!
[08:11] <didrocks> pitti: I include the tests directory for the fakesysfs module FYI
[08:11] <pitti> didrocks: yeah, that's right
[08:11] <didrocks> and I exported: export FAKE_INSTALLED_KMOD=nvidia
[08:12] <pitti> hmm
[08:13] <pitti> $ FAKE_INSTALLED_KMOD=nvidia PYTHONPATH=.:tests share/fake-devices-wrapper ./ubuntu-drivers devices
[08:13] <pitti> didrocks: ^ that's what I ran in u-d-c's trunk
[08:13] <pitti> didrocks: does that work for you?
[08:14] <pitti> didrocks: package build fixed in git, so you can pull and git-buildpackage -us -uc -b
[08:14] <didrocks> pitti: let me try again, I tried ubuntu-drivers devices, let me change directory to see what happens :)
[08:15] <pitti> didrocks: with the new .debs, this also works:
[08:15] <pitti> $ FAKE_INSTALLED_KMOD=nvidia /usr/share/ubuntu-drivers-common/fake-devices-wrapper ubuntu-drivers devices
[08:15] <didrocks> pitti: http://paste.ubuntu.com/1097917/
[08:16] <pitti> hm, WTH
[08:16]  * pitti cancels his debcommit -ar
[08:16] <didrocks> I guess there is a global import somewhere?
[08:16] <pitti> no, it's done right in fake-devices-wrapper
[08:16] <didrocks> it sees the env variable
[08:17] <pitti> didrocks: what's the topmost commit in git log that you see?
[08:17] <pitti> (yay for git not having sane rev numbers..)
[08:18] <didrocks> pitti: I just pulled and tried with 86C702d68c
[08:19] <pitti> didrocks: what does that say:
[08:19] <pitti> FAKE_INSTALLED_KMOD=nvidia PYTHONPATH=.:tests share/fake-devices-wrapper which modinfo
[08:20] <didrocks> /tmp/tmpiyfh9t/modinfo
[08:20] <pitti> let's switch to privmsg for debugging
[08:20] <didrocks> yep
[08:28] <tkamppeter> Any LightDM expert around, I have a problem after repartitioning my HD
[08:30] <seb128> just ask your question we might be able to reply
[08:31] <tkamppeter> After repartitioning and adjusting some broken permissions I have the LightDM screen and when I log in the desktop does not come up, instead after some seconds of a black screen LightDM's login screeen appears again. If I start gdm I can log in normally, so my home dir seems to be OK.
[08:32] <tkamppeter> This happens to me on Precise.
[08:34] <seb128> tkamppeter, do you have a staled .Xauthority in your user dir?
[08:34] <seb128> does it work if you move it away?
[08:34] <tkamppeter> seb128, how can I check this? Out of GDM my desktop comes up correctly.
[08:35] <seb128> tkamppeter, ls -l ~/.Xauthority?
[08:35] <tkamppeter> -rw------- 1 root root 200 Jul 17 22:24 .Xauthority
[08:36] <tkamppeter> seb128, is it really correct that root is the owner of my .Xauthority?
[08:36] <seb128> tkamppeter, no, that's what I was saying, try to rm that file and see if that fixes lightdm
[08:40] <tkamppeter> seb128, thank you, that was it. Why does software not display decent error messages?
[08:40] <seb128> tkamppeter, because softwares are not perfect, e.g that's a known bug
[08:41] <seb128> tkamppeter, you're welcome
[08:41] <seb128> tkamppeter, it should be fixed at some point
[08:42] <tkamppeter> Another point, probably more for pitti, is that syncpackage stopped working for me, but not only on the box which I repartitioned, also on all the other boxes. I get http://paste.ubuntu.com/1097950/
[08:46] <seb128> not sure why that hits gnome-keyring's code
[08:50] <pitti> hm,  no offhand idea; perhaps the launchpad cookie got invalidated somehow?
[08:57] <tkamppeter> pitti, how can one recover that? And getting this ugly traceback is for sure a bug.
[09:06] <tkamppeter> pitti, removing the browser cache and all launchpad cookies and restarting the browser does not help.
[09:07] <jibel> Sweetsha1k, I fixed the problem with libservlet but now LO failed to build
[09:07] <jibel> In file included from /tmp/buildd/libreoffice-3.6.0~rc1/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx:32:0:
[09:07] <jibel> /tmp/buildd/libreoffice-3.6.0~rc1/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.hxx:43:22: fatal error: GfxState.h: No such file or directory
[09:08] <seb128> Sweetsha1k, hey
[09:10] <seb128> Sweetsha1k, so, http://pastebin.ubuntu.com/1097967/ ... bunch of universe build-depends with your libreoffice 3.6 upload, it's depwaiting, did you open MIRs yet?
[09:21] <pitti> tkamppeter: it's not browser cookies, it's somewhere in ~/.launchpad presumably
[09:25] <Sweetsha1k> seb128: arrgh, no. ^&$#ing java/reportbuilder madness
[09:25] <seb128> Sweetsha1k, reportbuilder?
[09:27] <Laney> pitti: testsuite failures :(
[09:27] <Sweetsha1k> seb128: yes, the libreoffice-reportbuilder needs all that java crap. And reportbuilder was disabled just because of that in precise, giving me angry and vocal users in bug 992232
[09:27] <ubot2> Launchpad bug 992232 in libreoffice "no libreoffice-report-builder in precise" [Undecided,Fix released] https://launchpad.net/bugs/992232
[09:28] <Laney> seb128: thanks! the power corrupts
[09:28] <seb128> Laney, what's the first thing you are going to break? :p
[09:28]  * Sweetsha1k needs a bulk MIR script.
[09:29] <seb128> Sweetsha1k, is that one easy to turn off until the MIRs are sorted?
[09:31] <Sweetsha1k> seb128: yes. OTOH I can blackmail jamespages to quickly help MIRing these as he need that update for his libservlet migration ...
[09:31] <Sweetsha1k> *hrhr*
[09:32] <seb128> Sweetsha1k, I've the feeling that writing that stack of MIRs and getting them review will not happen this week, but check with him first sure
[09:32]  * Sweetsha1k will do a one hour raindance of excuberant beauty, the day we killed java from libreoffice core.
[09:33] <Sweetsha1k> (shortly after we all run GNU Hurd)
[09:36] <seb128> Laney, pitti: speaking of glib there is a 2.33.6 follow up update to fix some breakage from .4
[09:39]  * pitti hugs didrocks for uploading software-properties
[09:39] <seb128> Sweetsha1k, ok, the component-mismatch is scary, you should probably turn off reportbuilder until things are sorted out
[09:39] <Laney> they skipped .5?
[09:39] <Sweetsha1k> seb128: yep.
[09:39] <Laney> anyway, I'm not here so much for the rest of the week so if someone can upload that it'd be nice
[09:39] <seb128> Sweetsha1k, thanks
[09:39] <seb128> Laney, yeah, dunno why
[09:40] <seb128> pitti, is there any chance you could finish the glib update in debian experimental this week and sync it over?
[09:40] <pitti> seb128: yeah, I guess I can
[09:40] <seb128> pitti, that would be great, thanks!
[09:40] <Laney> so I found out that if you comment out the last two TEST_NEW_FAIL tests in regex.c then it gets much further (on ppc)
[09:41] <Laney> it still failed, but I think that was something to do with "cancelled" so it may be fixed in .6
[09:43] <pitti> Laney: oh, are you talking about the regression galore in https://buildd.debian.org/status/package.php?p=glib2.0&suite=experimental ?
[09:43] <Laney> pitti: yeah :-)
[09:44] <Laney> there's a new test and one which was previously disabled, and it seems that they fail on some arches
[09:44]  * didrocks hugs pitti back :-)
[09:44] <Laney> i've got a built tree in my home directory on davis.c.c
[09:50] <ricotz> Laney, hey, maybe you are interested in this log https://launchpadlibrarian.net/110365975/buildlog_ubuntu-quantal-amd64.glib2.0_2.33.7~git20120717.2855b827-0ubuntu1~12.10~ricotz0_FAILEDTOBUILD.txt.gz
[09:51] <tkamppeter> pitti, I do not have ~/.launchpad but only ~/.launchpadlib. I moved this way but it does not help.
[10:11] <pitti> hm -- could anyone please run "grep -r __abort_msg /usr/include/" and tell me if you get any hits?
[10:12] <seb128> pitti, none
[10:13] <pitti> ah, scratch that, I know what's wrong
[10:13] <pitti> seb128: merci
[10:13] <seb128> pitti, de rien
[10:32] <seb128> didrocks, pitti: welcome done on finishing the jockey replacement!
[10:32] <pitti> seb128: thanks :) I guess there's still some stuff to mop up
[10:32] <seb128> pitti, well, it's a good step in any case ;-)
[10:32] <pitti> such as the system-config-printer driver lookup (which needs to move into s-c-p itself)
[10:33] <seb128> oh right, tkamppeter is working on that right?
[10:33] <pitti> but I'm quite happy about this
[10:33] <pitti> yes
[10:33]  * pitti -> lunch, bbl
[10:33] <seb128> pitti, enjoy
[10:33] <didrocks> seb128: thanks ;)
[10:33] <didrocks> enjoy pitti
[10:33]  * didrocks will go for a run
[11:33] <pitti> didrocks: was just trying s-p-gtk again, nice!
[11:34] <pitti> didrocks: I figure this should be somewhere in control-center, though?
[11:34] <pitti> didrocks: can you call it in a way to show the drivers tab by default?
[11:35] <didrocks> pitti: happy that you are happy :) Yeah, maybe it should be in control-center. If so, for showing the driver tab by default I think there is no such facility, right now, but clearly possible to easily implement that
[11:36] <didrocks> mpt: what's your tought? ^
[11:36] <mpt> BURN THEM ALL
[11:36] <didrocks> the additional hw spot to replace jockey is a good one :)
[11:36] <mpt> What was the question?
[11:36] <didrocks> ahah ;)
[11:36] <pitti> *chuckle*
[11:36] <pitti> didrocks: I'll change jockey-gtk to be a transitional package to software-properties-gtk, so that it disappears from control-center
[11:37] <pitti> we still need -kde, they don't have a replacement yet
[11:37] <didrocks> mpt: should g-c-c have some icon to run software-properties-gtk on the driver tab directly?
[11:37] <pitti> mpt: right now it still shows "Additional Drivers" to point to Jockey, but that's going away
[11:37] <didrocks> pitti: agreed :)
[11:37] <mpt> didrocks, I don't think that's necessary, one's enough
[11:37] <didrocks> one?
[11:38] <pitti> mpt: software-properties isn't in control-center either
[11:38] <pitti> it used to be
[11:38] <pitti> but at least I don't see it
[11:38] <mpt> didrocks, "Software & Updates"
[11:38] <didrocks> it's not anymore as far as I see
[11:38] <pitti> I don't have that, do you?
[11:39] <mpt> didrocks, so basically, that would replace the current "Additional Drivers" one
[11:39] <didrocks> mpt: system category I reckon?
[11:39] <mpt> didrocks, yes
[11:40] <didrocks> ok, let's do that then :)
[11:40] <pitti> a11y, users, "details" (leading to "about system"), backup, landscape, time&date
[11:40] <pitti> didrocks: hardware tab rather
[11:40] <didrocks> pitti: for upgrading softwares?
[11:40] <pitti> didrocks: first, it still has two slots (system doesn't)
[11:40] <pitti> didrocks: oh, for software sources in general, hm
[11:40] <didrocks> right, doesn't really make sense in hw :/
[11:40] <mpt> pitti, and second it's related to hardware. But I think that's the tail wagging the dog a bit.
[11:41] <pitti> that'll be a bit tricky layout wise
[11:41] <mpt> I have a plan for getting rid of Details
[11:41] <pitti> mpt: the drivers part is, but not the software updates part
[11:41] <mpt> yes
[11:41] <didrocks> zomg mpt has a plan :)
[11:41] <mpt> the drivers part is the tail
[11:41] <didrocks> (seems it's related to burn and fire) :)
[11:41] <ogra_> you could have a switch that hides all other tabs
[11:42] <mpt> heh
[11:44] <didrocks> mpt: so where your heart his? breaking the layout even more (I heard that we will add soon a new item in the first category anyway, so 2 rows), or putting software properties elsewhere?
[11:45] <mpt> didrocks, I suggest making the window wider for now, and we'll figure it out later (famous last words)
[11:45] <bcurtiswx> RAOF, Hey re bug #1018784, I don't understand your comment. I fixed a typo in the changelog that would have closed the wrong bug, which was fixed before
[11:45] <ubot2> Launchpad bug 1018784 in empathy "[SRU Precise] update to 3.4.2.3" [Wishlist,In progress] https://launchpad.net/bugs/1018784
[11:46] <didrocks> mpt: ok, I'll add it to the system one then, and we'll make g-c-c larger
[11:47] <mpt> ok
[11:48] <bcurtiswx> RAOF, if the upload was incorrect (and not reuploaded) I have no upload rights and my fixes would have had to be reuploaded by someone else
[11:48] <bcurtiswx> RAOF, once kenvandine gets in I'll have him reupload
[12:05] <tkamppeter> pitti, seb128, any other idea about the syncpackage problem? Moving away ~/.launchpadlib does not help.
[12:05] <pitti> no, no further idea I'm afraid
[12:07] <pitti> seb128: btw, WDYT about dropping 91_revert_schema_path_warning.patch from glib now?
[12:07] <pitti> -    g_printerr ("warning: Schema '%s' has path '%s'.  Paths starting with "
[12:07] <pitti> -                "'/apps/', '/desktop/' or '/system/' are deprecated.\n", id, path);
[12:07] <pitti> is that still something we want to allow in quantal, or fix?
[12:08] <seb128> pitti, robert_ancell fixed a bunch, I think it's fine to warn about that in quantal
[12:08] <pitti> seb128: ack
[12:09] <didrocks> wait maybe that I push the dconf load dconf dump migration script for unity? :)
[12:09] <didrocks> or we can spam for 2 days .xsession-errors I guess
[12:09] <pitti> I won't get it into quantal today
[12:10] <pitti> I'm doing this as a side-thing, and it shoudl build on a few arches in Debian first
[12:10] <pitti> :q
[12:10] <pitti> erk, focus, sorry
[12:10] <seb128> pitti, btw something broke gsettings command line completion in quantal
[12:10] <didrocks> perfect :)
[12:11] <didrocks> indeed
[12:11] <didrocks> ls /etc/bash_completion.d/gset*
[12:11] <didrocks> -> nothing
[12:11] <pitti> /usr/share/bash-completion/completions/gsettings
[12:12] <pitti> it seems bash completion has moved there now
[12:12] <seb128> hum
[12:12] <pitti> which indeed seems a lot more sensible than putting all of this into etc
[12:12] <seb128> but it doesn't seem to be picked up?
[12:12] <seb128> http://git.gnome.org/browse/glib/commit/?id=e9ec1ad0689dfbb1121e1c5fe5b1aedbe2de568f
[12:12] <didrocks> well, the 3 files in it doesn't complete :)
[12:13] <didrocks> so yeah, it's sensible, but not working!
[12:13] <seb128> bash-completion (1.90)
[12:13] <seb128>   * Layout change: everything is now in /usr/share/bash-completion/, rather
[12:13] <seb128>     than in /etc/.
[12:13] <seb128> on the upstream bug
[12:14] <pitti>  bash-completion | 1:2.0-1 | sid     | source, all
[12:14] <pitti> (also in wheezy)
[12:14] <didrocks> we have 1:1.3-1ubuntu8
[12:14] <pitti> someone didn't do their merges apparently :)
[12:15] <seb128> pitti, well, it's just "Debian & Ubuntu are behind on versions"
[12:15] <pitti> seb128: no, Ubuntu is
[12:15] <pitti> Debian has had 2.0 for quite a while (even in wheezy)
[12:15] <seb128> oh
[12:15] <pitti> cf. missing merges
[12:15] <didrocks> I wonder how painful will be the transition, seeing the number of packages shipping completion
[12:16] <didrocks> of course, desrt and gsettings are on edge! :)
[12:16] <pitti> the debian changelog looks like they took care of this
[12:16] <seb128> didrocks,
[12:16] <seb128> bash-completion (1:1.99-2) unstable; urgency=low
[12:16] <seb128>    * Make /etc/bash_completion a symlink to the new location, waiting
[12:16] <seb128>      for bash to update its scripts (Closes: #648319)
[12:16] <didrocks> ah good :)
[12:16] <mdeslaur> seb128: so, how does one migrate from /apps gsettings path to a more sane one? Is there an example somewhere?
[12:16] <seb128> mdeslaur, that's a question for didrocks
[12:16] <mdeslaur> didrocks: ^?
[12:16] <didrocks> seb128: I think you +1 on it :-)
[12:16] <seb128> ;-)
[12:17] <didrocks> mdeslaur as well +1 the g+ post :)
[12:17] <didrocks> mdeslaur: just ship a script for session-migration which can do: dconf dump /path dconf load /newpath
[12:17] <didrocks> mdeslaur: I'll do one for unity probably tomorrow
[12:17] <didrocks> so that will be the example
[12:18] <didrocks> :)
[12:18] <mdeslaur> didrocks: hrm, ok, that's great for quantal...any ideas for previous releases?
[12:18] <didrocks> mdeslaur: hum, you want to do that as a SRU? :)
[12:19] <didrocks> don't be crazy like that ;)
[12:19] <mdeslaur> didrocks: no, but I build for older releases in a PPA
[12:19] <didrocks> mdeslaur: I think you will need to ship session-migration in the ppa then and make a build-dep on it (should be backportable easilty)
[12:19] <mdeslaur> didrocks: I assume if I don't ship the old path in the gschema file, my app will explode when it attempts to load the old path?
[12:19] <didrocks> mdeslaur: otherwise, a script that you launch by any mean before the app starts
[12:19] <didrocks> making this dconf dump and dconf load
[12:20] <didrocks> mdeslaur: yeah, it will
[12:20] <mdeslaur> I hate gnome. :P
[12:21] <didrocks> desrt: I'm sure you can hug a happy user on segfault ^ :)
[12:26]  * didrocks was heading to take some chocolate with his tea, but an apple was on the way. So apple it will be :)
[12:26] <pitti> a healthy coincidence!
[12:26] <pitti> also, encodings suck
[12:26]  * pitti fighting with another python-distutils-extra bug in C locale
[12:27] <didrocks> pitti: I'm wondering on the coincidence or julie interfering yesterday evening on this plan :)
[12:27] <didrocks> urgh :/
[12:32] <pitti> Laney: ah, the gregex problem got fixed in pcre3 8.31, but we still have 8.30; I'll revert that then
[13:01] <ogra_> hmm, something in the desktop constantly loads the fuse module here
[13:01] <seb128> ogra_, gvfs-fuse?
[13:01]  * ogra_ wonders what that is, i havent see this in precise
[13:02] <ogra_> ah ! indeed
[13:02] <ogra_> doesnt it have a check to find out if fuse is loaded already
[13:02] <ogra_> ?
[13:02] <ogra_> it seems ot try to load it regardless which gets me an "Invalid Argument" message in syslog every time
[13:05] <seb128> seems like a bug yes
[13:06] <ogra_> n ote i'm testing on ac100 which uses a custom kernel ... not sure that also shows on x86
[13:06] <ogra_> thopugh i ddint have that message in precise on this device
[13:06] <desrt> didrocks: what's up?
[13:07] <bcurtiswx> good morning kenvandine
[13:07] <kenvandine> bcurtiswx, good morning
[13:07] <didrocks> desrt: oh was just kidding on the "move your schema meme" :)
[13:07] <desrt> oh
[13:08] <desrt> sorry :)
[13:08] <didrocks> desrt: heh, you will be happy next week, unity will not be in /desktop anymore!
[13:08] <bcurtiswx> kenvandine, can I task you with a few things this AM ?
[13:08] <desrt> didrocks: i'll be happier when unity is not in -desktop anymore ;)
[13:08]  * didrocks runs after desrt
[13:08] <kenvandine> bcurtiswx,  you can try :)
[13:09]  * desrt looks at the calendar
[13:09] <seb128> desrt, be ready to not be happier any time soon ;-)
[13:09] <desrt> damn.  it's not troll tuesday anymore
[13:09]  * desrt behaves
[13:09] <bcurtiswx> kenvandine, first bug #1018784 could you reupload my fix ?
[13:09] <ubot2> Launchpad bug 1018784 in empathy "[SRU Precise] update to 3.4.2.3" [Wishlist,In progress] https://launchpad.net/bugs/1018784
[13:09] <kenvandine> bcurtiswx, is that the one that got rejected?
[13:09] <desrt> any reports on new dconf yet?
[13:10] <bcurtiswx> kenvandine, yes
[13:10] <didrocks> "you broke shell completion!"
[13:10] <kenvandine> ha
[13:10] <kenvandine> typo :)
[13:11] <kenvandine> bcurtiswx, do you have that in a branch?
[13:11] <bcurtiswx> kenvandine, it's been fixed in my branch for a couple days now
[13:12] <bcurtiswx> i really just need to get upload rights..
[13:16] <kenvandine> bcurtiswx, done
[13:19] <bcurtiswx> kenvandine, thanks. Secondly, I had an issue with contacts showing (gabble) i had google talk contacts not showing and facebook contacts working... but for some reason the google talk contacts now work and i'm just going to ignore it.. but wouldn't be surprised with a bug or 10 about it
[13:20] <kenvandine> i'll keep an eye out for that
[13:20] <kenvandine> i haven't experienced it
[13:20] <kenvandine> bcurtiswx, is your branch ready to sponsor for 3.5.4?
[13:21] <bcurtiswx> kenvandine, I'm using it now on my macbuntu
[13:22] <bcurtiswx> kenvandine, is there a battery of tests I should perform before any official upload?
[13:22] <kenvandine> i just make sure chats, contact lists, and calls work
[13:23] <bcurtiswx> how do you test calls ?
[13:23] <kenvandine> between two of my gtalk accounts
[13:23] <kenvandine> computer to phone and phone to computer :)
[13:24] <kenvandine> and make sure notifications don't regress for inbound calls
[13:27] <jbicha> seb128: thanks for finishing nautilus :)
[13:27] <seb128> jbicha, yw, I don't get why you commented some of the patches, they were applying and building fine
[13:28] <seb128> jbicha, like the trivial .desktop patch which add an action group
[13:30] <jbicha> well it wasn't compiling, maybe it was the git patches that needed to be dropped
[13:33] <seb128> jbicha, right, only one patch was to drop, you comment like .desktop tweaks which was weird ;-)
[13:41] <pitti> seb128, Laney: FYI, uploading glib 2.33.6 to experimental
[13:41] <seb128> pitti, \o/
[13:46] <Sweetsha1k> seb128: rc2 uploaded to chinstrap and succeesfully completed local build
[13:46] <seb128> Sweetsha1k, \o/
[13:46] <seb128> Sweetsha1k, I will sponsor that
[13:47] <Sweetsha1k> seb128: be careful that your hands still receive some circulation if you keep them up there all the time ...
[13:47] <seb128> lol
[13:48] <Sweetsha1k> we need higher door on the next UDS so that tech lead with raised chearleading arms may still pass them ....
[13:50] <seb128> it has better to build or I will stop chearleading ;-)
[13:57] <micahg> seb128: I take it we need webkit 1.9.x in quantal for something?
[13:57] <seb128> micahg, yes
[13:58] <seb128> micahg, see https://bugs.launchpad.net/ubuntu/+source/libsoup2.4/+bug/1011473/comments/12
[13:58] <ubot2> Ubuntu bug 1011473 in webkit "Please update to latest libsoup 2.39.2" [High,In progress]
[13:58] <seb128> micahg, currently webkit is broken in quantal
[13:59] <seb128> micahg, that and epiphany and some other component will require 1.9 anyway
[13:59] <micahg> seb128: broken upstreams are frustrating, ok :)
[13:59] <seb128> right...
[14:00] <pitti> seb128: uploaded fix for bug 972436 to precise-proposed, as requested by you; hopefully helps to clean up errors.u.c. a bit
[14:00] <ubot2> Launchpad bug 972436 in apport "backend_helper.py crashed with UnicodeEncodeError in apport_excepthook(): 'ascii' codec can't encode character u'\xe8' in position 166: ordinal not in range(128)" [Critical,Fix committed] https://launchpad.net/bugs/972436
[14:00] <pitti> seb128: although in practice all those will now just become real crashes :)
[14:02] <seb128> pitti, thanks
[14:02] <tkamppeter> pitti, as syncpackage has died for me, can you sync c2esp from experimental for me?
[14:02] <seb128> pitti, well, that seems the best way out, get the real bugs reported and fix them
[14:02] <seb128> tkamppeter, you might want to ask on #ubuntu-devel about your syncpackage issues
[14:03] <pitti> tkamppeter: doing
[14:03] <pitti> tkamppeter: done
[14:07]  * bcurtiswx is working on MOTU application :)
[14:08]  * mlankhorst working on uploading enough packages to make his x1.13 tree mostly green :x
[14:35] <pitti> mterry: good morning
[14:35] <mterry> pitti, hello!
[14:35] <pitti> mterry: weren't you saying the other day that you fixed update-manager's autopkgtest in trunk? I don't see new commits
[14:36] <mterry> pitti, commit 2528 ?
[14:37] <pitti> ah that, sorry
[14:37] <pitti> mterry: I was only looking in debian/changelog
[14:37] <pitti> didn't occur to me to look into the bzr log
[14:37] <mterry> pitti, oh shoot, I forgot to make a changelog
[14:37] <mterry> will make one now
[14:38] <pitti> sorry for the confusion, thanks!
[14:39] <mterry> pitti, updated
[14:41] <pitti> mterry: cheers!
[14:55] <bcurtiswx> kenvandine, seb128 could I get endorsements from you for my MOTU Application? https://wiki.ubuntu.com/BCurtisWX/MOTUApplication
[14:55] <bcurtiswx> and anyone else who feels I deserve it should comment :) comments very welcome :)
[14:56] <seb128> bcurtiswx, noted
[14:56] <bcurtiswx> seb128, thanks
[14:58] <jbicha> bcurtiswx: it looks like all of your uploads were to main
[14:58] <jbicha> it might be a better fit for you to apply to ubuntu-desktop first before motu, like I did
[15:00] <bcurtiswx> jbicha, OK.
[15:00]  * bcurtiswx looks for ubuntu-desktop joining proceedure
[15:01] <seb128> collect2: error: ld terminated with signal 9 [Killed]
[15:01] <seb128> grrrr webkit
[15:01] <seb128> kenvandine, you don't want to maintain webkit do you?
[15:01] <seb128> kenvandine, you got training with chromium!
[15:01]  * kenvandine hides from seb128
[15:02] <bcurtiswx> jbicha, whats entailed in ubuntu-desktop application?
[15:06] <jbicha> bcurtiswx: https://wiki.ubuntu.com/DesktopTeam/Developers
[15:20] <seb128> Sweetsha1k, https://launchpadlibrarian.net/110388708/buildlog_ubuntu-quantal-amd64.libreoffice_1%3A3.6.0~rc2-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:20]  * seb128 shakes fist at libreoffice
[15:20] <seb128> "GfxState.h: No such file or directory"
[15:21] <bcurtiswx> ok ubuntu-desktop app submitted :)
[15:25] <micahg> seb128: FWIW, libreoffice seems like the type of thing that should go to -proposed anyways
[15:26] <seb128> micahg, why? it's not a rdepends of other things and should not create installability issues
[15:26] <micahg> seb128: aren't there arch:all packages built on i386 that can break the old amd64 binaries?
[15:26] <bcurtiswx> micahg, thanks for the FWIW :)
[15:27] <micahg> seb128: ISTR installability issues in the past
[15:27] <micahg> seb128: can happen if the build queue is backed up, less likely if it's not
[15:28] <seb128> micahg, could be indeed, noted for the next upload, that one failed to build accross the board so no issue
[15:57] <Sweetshark> seb128: /me is in acall
[16:19] <Sweetshark> seb128: GfxState.h? sounds like someone did an incompatible change in one of LOs deps since yesterday
[16:19] <Sweetshark> seb128: oh fun ....
[16:19] <seb128> Sweetshark, that would be weird, poppler didn't get an update in a while
[16:20] <seb128> oh
[16:20] <seb128> I wonder if mterry broke something
[16:21] <mterry> Heyo.  I do like breaking things
[16:21] <mterry> Sweetshark, LO breaking?
[16:22] <seb128> mterry, libpoppler-dev_0.20.2-2ubuntu1_i386.deb seems empty of its includes
[16:22] <Sweetshark> mterry: well, yeah. It builds my local pbuilder and in the PPA with update state of ~yesterday and now failed to build ...
[16:23] <mterry> curious about poppler.  Looks like several changes to it recently.  /me looks
[16:24] <Sweetshark> mterry: if you like breaking things, our upstream QA guys would love to have you onboard ;)
[16:24] <seb128> mterry, Sweetshark: seems like Debian moved those includes to libpoppler-private-dev
[16:25] <seb128> shouldn't libpoppler-dev depends on that as a transitional thing?
[16:26] <Sweetshark> mterry: ah, thats the stuff that seb128 commented on 'they are smoking crack' half a year ago.
[16:26] <mterry> Sweetshark, sounds like you don't want me, you want Debian  :)
[16:26] <seb128> mterry, the changelog had your name on the recent uploads ;-)
[16:26] <seb128> mterry, you break it you fix it!
[16:26] <seb128> :p
[16:26] <seb128> hum, in fact this upload is Laney's
[16:26] <Sweetshark> mterry: guess it is time to revert http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=7778c032bafef904b772b1f223be1fdd8a17f90d now ...
[16:27] <seb128> Sweetshark, seems so
[16:27] <seb128> still I wonder if libpoppler-dev shouldn't depends on the new -private-dev as a transitional thing
[16:28] <mterry> seb128, Sweetshark: what is libpoppler-dev even supposed to do?  How is that a usable package, without any headers...?
[16:28] <Sweetshark> seb128: it should IMHO, IIRC debian did so.
[16:28] <seb128> mterry,
[16:28] <seb128> "* Move the poppler private headers from libpoppler-dev to
[16:28] <seb128>      libpoppler-private-dev:"
[16:28] <seb128> mterry, libpoppler-dev was the dev with all the includes
[16:28] <seb128> mterry, the Debian guys decided to add a -private-dev and move things there
[16:29] <mterry> seb128, yeah, I get that some headers are considered private and unstable, but they moved all of them...  So is any part of poppler public and stable?
[16:29] <seb128> mterry, so things which need those .h and build-depends on libpoppler-dev don't get what they want
[16:29] <seb128> mterry, the glib and qt bindings one I think
[16:30] <mterry> seb128, I feel like a Depends on -private-dev is kind of defeating the purpose of the split, but it would help with the transition for sure
[16:30] <seb128> mterry, well as Sweetshark said, I though the Debian guys were on crack with that rename
[16:30] <seb128> I still think they are :p
[16:30] <seb128> but no point for us creating ourself extra work
[16:32] <Sweetshark> FWIW, reverted for LibreOffice for the next upload, but having a transitional you get this upload in would be nice.
[16:33] <Sweetshark> jibel: ^^ This is why jenkins broke on this. It wasnt your change -- it was the poppler update.
[16:34] <jibel> Sweetshark, good to know, thank
[16:35] <Sweetshark> jibel: building LibreOffice on a prebeta Ubuntu is like building a castle on the swamp ;)
[16:35] <seb128> mterry, what do you think about adding the Depends in a transitional way?
[16:36] <mterry> seb128, I'm fine with it.  As it is, there's no reason for anyone ever to build-depend on straight libpoppler-dev, so might as well make it useful to someone
[16:36] <mterry> seb128, I can do that
[16:36] <seb128> mterry, thanks
[16:37] <seb128> mterry, well there are, libpoppler-dev still has the .pc
[16:37] <seb128> that split is just dumb
[16:37] <robru> Hi, seb128 ;-)
[16:37] <mterry> seb128, a .pc that points to headers that don't exist?
[16:37] <seb128> robru, hey, how are you?
[16:38] <robru> I'm good. I actually do have time right now if you want to call.
[16:38] <seb128> robru, ok, give me 5 minutes
[16:38] <robru> no problem.
[16:38] <Sweetshark> seb128: it is has the .pc, but no headers? Like 'we will cheat your ./configure into thinking everything is there (with everything meaning nothing)'? ;)
[16:39] <Sweetshark> mterry: thanks indeed!
[16:40] <seb128> mterry, Sweetshark: hey, that's just weird, dunno why the Debian maintainer was thinking
[16:41] <mterry> seb128, well, if the headers are private and unstable, it makes some sense to discourage their use.  But this is a weird way, I agree
[16:41] <seb128> mterry, he could have moved the .pc to the -private lib as well...
[16:41] <seb128> robru, calling
[16:41] <robru> cool
[16:41] <robru> thanks
[16:41] <mterry> seb128, Sweetshark: uploaded
[16:42] <seb128> mterry, thanks
[16:42] <Sweetshark> seb128: can we just retry that build?
[16:42] <Sweetshark> mterry: awesome, thanks!
[16:43] <robru> seb128, my phone's not ringing, did something go wrong? ;-)
[16:43] <seb128> robru, 1 minute, I think I screwed up the international part
[16:44] <robru> hehe, ok. I've never called internationally before.
[16:44] <seb128> robru, hehe, I didn't for a while, let me sort that out :p
[16:47] <robru> seb128, if it's too much trouble do you want to just chat?
[16:59] <Sweetshark> micahg: I was initially supporting putting at least the first new major of LO into -proposed, but now I am against it: there is just too much crack in -proposed that might cause trouble on LO. Its better to build the package in a PPA and then upload directly to quantal main.
[17:00] <Sweetshark> micahg: the only thing to take care of there are MIRs and those are easier to handle than some weirdly broken package somewhere down the stack.
[17:01] <Sweetshark> micahg: and the package uploaded today in the morning was just that: in the ppa as is and already used by a few hundred users.
[17:02]  * didrocks waves good evening
[17:09] <micahg> Sweetshark: no, dev release proposed is a staging area to prevent installability issues
[17:10] <Sweetshark> micahg: which it is to instable to build LO in it.
[17:10] <Sweetshark> s/which/which is why/
[17:11] <micahg> Sweetshark: right, the issue is if the build queue is backed up, you'll get uninstallability
[17:11] <micahg> err...installability issues
[17:12] <micahg> and there shouldn't be a lot of crack in proposed (yes, lo might need to wait to migrate a few more hours or so)
[17:14] <Sweetshark> micahg: lo will find each and every crack there is. even on directly on main it has been broken for me inbetween the testbuild in a local pbuilder and the build on the buildd by kde, by libjpeg, by poppler and a dozen of others I cant remember.
[17:16] <Sweetshark> that timeframe is usually <24 hours. so either you guys have excellent timing in breaking things in the right moment ;) , or uploading to -proposed will just not fly.
[17:17] <micahg> Sweetshark: well, you should probably watch quantal-changes to see if there's anything uploaded that might affect you and then do another test build with that thing
[17:17] <micahg> *if there is something, do another test build
[17:18] <Sweetshark> micahg: the migration time isnt what bothers me. its building against an state of the distro that is not the release (and very well never will be)
[17:20] <micahg> Sweetshark: no, in the devel release, it's stuff that's meant to migrate as soon as itself or its rdepends are built, it's not for total crack AIUI
[17:20] <Sweetshark> micahg: I dont have to look at quantal-changes for that. in 24 hours, there always will be something in the >1000 package rdeptree of LO uploaded. Heck, even in the buildtime of LO (if I choose to do a rebuild everytime somebody uploads) there will be a new rdep (directly or indirectly) in.
[17:21] <Sweetshark> micahg: if it would be the same as main, there would be no point to it. it is different.
[17:22] <Sweetshark> micahg: see the PPA build as an 'isolated' -proposed: just LO to reduce the possible error sources.
[17:23] <micahg> Sweetshark: no, you're missing the point, if i386 builds and publishes  before amd64, you'll get installability issues
[17:23] <micahg> the side benefit is you have more a safe haven to deal with build failures
[17:26] <micahg> devel-proposed != stable-proposed
[22:23] <desrt> robert_ancell: hey.  new dconf package done up yet?
[22:24] <robert_ancell> desrt, nope, no-ones started it
[22:24] <desrt> seb said it's your job :)
[22:24] <robert_ancell> desrt, he always says that
[22:26] <desrt> robert_ancell: it's almost like he thinks he's the boss now
[22:27] <desrt> robert_ancell: in any case, i'm very highly interested in getting testing feedback
[22:51] <robert_ancell> desrt, hmm, trying to make https://bugzilla.gnome.org/show_bug.cgi?id=670493 still apply
[22:51] <ubot2> Gnome bug 670493 in general "Please make it possible to configure the system database path at runtime" [Enhancement,Unconfirmed]
[22:54] <bcurtiswx> anyone know what might cause: (empathy:2241): tp-glib-CRITICAL **: tp_connection_upgrade_contacts: assertion `tp_proxy_is_prepared (self, TP_CONNECTION_FEATURE_CONNECTED)' failed
[23:12] <robert_ancell> desrt, well, everything seems to be running as normal
[23:15] <bcurtiswx> whats the easiest way to get changelogs, seems apt-get changelog doesn't have some changelogs
[23:16] <TheMuso> Look at the source package... I think changelog sare trimmed from some packages to save on a bit of image space.
[23:17] <bcurtiswx> ah found launchpad.net/ubuntu/+source/<package>/+changelog
[23:17] <bcurtiswx> TheMuso, thx though :)
[23:22] <TheMuso> Yeah theres that too.
[23:22] <TheMuso> and np.
[23:27] <robru> ungh, having a really unhelpful error message with pbuilder
[23:27] <robru> running build_py
[23:27] <robru> error: No such file or directory
[23:27] <robru> doesn't say what file's missing. no idea how to fix this...
[23:28] <robru> pretty standard distutils package.
[23:29] <robru> I don't suppose this is an incredibly common pbuilder/distutils issue that one of you would just magically know the answer to...
[23:33] <jasoncwarner_> RAOF or bryceh do you happen to know what is going on with this bug? thumper just asked me about it. apparently it is causing quite a bit of pain https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/973096
[23:33] <ubot2> Ubuntu bug 973096 in nvidia-graphics-drivers "Nvidia driver causes xorg crash" [High,Triaged]
[23:35]  * bryceh looks
[23:38] <RAOF> That seems to have attracted a bunch of unrelated bugs, but the core seems to be a regression after nvidia 290.10.
[23:39] <bryceh> looks like NVidia is aware of it (comment #144 is from one of their engineers)
[23:39] <bcurtiswx> unrelated, http://paste.ubuntu.com/1099227/ seems my system does not know what is and is not installed
[23:40] <bryceh> wonder if this is fallout from that security fix
[23:41] <RAOF> It may well be.
[23:42] <RAOF> Urgh, that bug makes me think we should have a whitelist for commenting on a bug.
[23:42] <bryceh> heh
[23:42]  * bcurtiswx looks at bug
[23:42] <RAOF> No, you are *not* seeing this bug on your intel 3000HD system.
[23:43] <bryceh> yeah that make me chuckle
[23:43] <RAOF> I'm pretty sure there's at least three bugs in there, only counting the nvidia users.
[23:44] <bryceh> of course hardly anyone posts backtraces so impossible to know for sure
[23:45] <jasoncwarner_> RAOF and bryceh thanks :) I'll check with alberto on what is going on to with nvidia etc. thanks!
[23:45] <RAOF> jasoncwarner_: I think the upshot is - there's a bug in the nvidia driver, it looks like nvidia has all the information they need, and that they're working on it.
[23:45] <bcurtiswx> i see a lot of me too responses.. literally with "me too" lol, maybe the LP greasemonkey people can work something up
[23:45] <jasoncwarner_> RAOF, aye...that is what I saw as well.
[23:45] <bryceh> jasoncwarner_, anyway, so right before 12.04 released we got a security fix from nvidia which closed a memory hole that could be accessed by non-root.  However, their fix was hacky and not a complete fix, but it was enough to cause X to crash under various circumstances.
[23:46] <bryceh> they're aware of the issue but have said that fixing it is a big project, so they're targeting that to a future major release rather than a bugfix release
[23:48] <bryceh> bcurtiswx, actually I'd rather see Launchpad changed to not permit commenting by people with <10 karma
[23:48] <bcurtiswx> i was just noticing that. lol
[23:49] <TheMuso> We have the "mee too" feature, people still feel they have to comment.
[23:49] <RAOF> I'd like to see it locked down by backtrace; you can comment on any bug for which you've submitted a backtrace that matches the original one.
[23:51] <bryceh> RAOF, if this is due to the driver rather than something else in ubuntu, then the afflicted people should find they have the same bug in other distros that carry this version of nvidia
[23:52] <RAOF> That would be true.
[23:53] <bryceh> as a workaround I wonder if we could shove the older -nvidia into the x-retro ppa