=== jbicha is now known as Guest40326
=== tkamppeter_ is now known as tkamppeter
[06:20] <didrocks> good morning
[06:50] <pitti> hey didrocks, ca va?
[06:50] <didrocks> guten morgen pitti
[06:50] <didrocks> ça va bien, et toi? :)
[06:50] <pitti> je vais bien, merci!
[06:51] <pitti> some friends of us visited us over the weekend, was nice; we walked a looooot :)
[06:51] <didrocks> oh great :)
[06:51] <didrocks> I didn't get a really relaxing week-end as at the ubuntu-fr booth for 2 days, but next one will be a tireless-free one :)
[07:06] <glatzor> morning pitti
[07:07] <pitti> hey glatzor, guten Morgen!
[07:08] <glatzor> pitti, could you help me on a gobject problem: I want to to build the sphinx documentation of aptdaemon, but it fails with a failed import: from ._gi import _API, Repository. To reproduce just run python setup.py build_sphinx
[07:10] <pitti> glatzor: will try in a sec
[07:11] <pitti> error: invalid command 'build_sphinx'
[07:11] <pitti> oh, I still have my pkcompat-enhancements branch here, hang on
[07:13] <pitti> glatzor: hm, pulled trunk, still says that ^
[07:14] <glatzor> pitti you need to install python-sphinx
[07:14] <pitti> oh, silly me; doing
[07:14] <pitti> build succeeded, 29 warnings.
[07:15] <pitti> glatzor: right, I get the exception as well
[07:15] <pitti> glatzor: apparetnly it tries to import the old static "gobject", too, as the error says
[07:15] <pitti> ImportError: could not import gobject (error was: ImportError('When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject".',))
[07:18] <pitti> glatzor: my usual trick for this is to add raise ImportError("not static!") to /usr/lib/python2.7/dist-packages/gobject/constants.py
[07:18] <pitti> to get an exception at the time when the static module is imported
[07:18] <pitti> apparently it's done in __import__(self.modname), it probably takes that from the aptdaemon source?
[07:19] <pitti> glatzor: there are several imports of "gobject" in the source left, indeed
[07:19] <pitti> ./aptdaemon/client.py:    import gobject as GObject
[07:19] <pitti> and presumably from the old gtkwidgets.py
[07:20] <pitti> glatzor: with this trick I only have one error left: http://paste.ubuntu.com/1022653/
[07:21] <pitti> glatzor: which applies to "gtkwidgets" indeed; not much we can do about that, I'm afraid; I think it's okay to skip that old module from the docs, though?
[07:23] <glatzor> pitti, thanks that seems to be the trick. I just removed the old sources. I missed the import gobject warning although reading the error log several times ...
[07:23] <pitti> glatzor: gtkwidgets are gone now? \o/
[07:23] <glatzor> no just from the documentation :)
[07:23] <pitti> ah, good
[07:24] <pitti> glatzor: python-aptdaemon.gtkwidgets seems to have zero reverse dependencies left
[07:24] <pitti> python-aptdaemon-gtk still has two
[07:25] <Sweetshark> moin
[07:28] <pitti> hey Sweetshark, wie gehts?
[07:35] <Sweetshark> pitti: good, I had be to a party weekend in Schwerin. It had been really interesting: Schwerin is just an 1 hour drive from hamburg and its an different world altogether.
[07:39] <pitti> Sweetshark: indeed; we drove through on a bicycle tour a few years back
[07:47] <Sweetshark> pitti: also culture is different. and it is the capitol of McPomm with mere 100000 inhabitants. That drew a few snide remarks from Hamburg guys/gals ...
[07:51]  * pitti objects to "Mc" Pomm
[07:52] <Sweetshark> pitti: still, not being derogative: it is just different. Some are happy with the way things worked there and like the way life is. while other do not, esp. some of those would loudly claim to love it -- qui s'excuse, s'accuse.
[07:53] <Sweetshark> McPomm is how Mecklenburg expatriates in Hamburg call their home. And there are a lot of them.
[07:53] <pitti> wow, I didn't know that
[08:04] <Laney> morning
[08:06] <seb128> hey
[08:07] <RAOF> seb128: Good morning!
[08:07] <seb128> RAOF, hey, how are you?
[08:07] <RAOF> I'm the all-singing all-dancing compositor master!
[08:08] <RAOF> Also, I'm fine.
[08:08] <RAOF> ;)
[08:10] <pitti> bonjour seb128, hey RAOF
[08:10] <pitti> RAOF: nice, making progress with the system compositor?
[08:10] <seb128> RAOF, hehe, did you get something working?
[08:11] <RAOF> seb128: For sufficiently loose definitions of "working"
[08:11] <seb128> pitti, hey our qa friend, how are you? ;-)
[08:11] <RAOF> ie: the *compositor* (probably) works, but there aren't any clients that support it :)
[08:11] <pitti> seb128: I'm great, thanks! we had a nice weekend, some friends came to visit
[08:11]  * RAOF heads to pilates.
[08:12] <didrocks> salut seb128, Laney, RAOF!
[08:13] <seb128> lut didrocks
[08:13] <Laney> hola!
[08:13] <Laney> cómo estás?
[08:15] <Sweetshark> We should add a splash screen with RAOF singing and dancing on opening a unity3D session ...
[08:15] <seb128> Laney, hey, how are you?
[08:15] <seb128> hey Sweetshark
[08:15] <pitti> hey Laney
[08:15] <Laney> we had a wet weekend but there were some celebrations for the jubilee :-)
[08:15] <seb128> Laney, I saw your unity ftfbs bug, did you talk to didrocks about it? the dx guys have been looking at it for some days
[08:16] <Laney> didrocks already saw it
[08:16] <Laney> and rejected :P
[08:16] <didrocks> and already rejected the branches ;)
[08:16] <seb128> ok
[08:16] <Laney> I never saw that segfault though, strange
[08:16] <seb128> Laney, I need to reply at your email :-(
[08:16] <Laney> heheh
[08:16] <didrocks> Laney: reliable for me, between 0 and 2s after looging
[08:16] <didrocks> logging*
[08:16] <Laney> oh well, no worries if it's being worked
[08:16] <seb128> Laney, if we had waited on the q build to work those bug fixes would still not have been uploaded to the lts proposed
[08:17] <seb128> Laney, thanks for assuming we were ignoring issues :p
[08:17]  * Sweetshark doesnt like his precise notebook sometimes hanging on "checking battery state" during boot.
[08:18] <seb128> Sweetshark, don't pay attention to the message, that's likely not where it's hanging
[08:19] <Laney> ah, didn't mean to accuse, just saw those examples
[08:19] <Laney> maybe something else can be done there
[08:20] <Sweetshark> seb128: right, I even got a vt by ctrl-alt-F2, pstree showed lightdm running happily (even though I didnt saw anything of that). /etc/init.d/lightdm restart then gave me an X.
[08:21] <Sweetshark> s/didnt saw/didnt see/
[08:22] <seb128> Sweetshark, it does it only sometimes?
[08:22] <Sweetshark> seb128: yep.
[08:23] <seb128> Laney, well, the "It's not clear to me what we can do about people not test-building their uploads", I did the unity upload and I did test build and run it so it's a bit offensive
[08:24] <seb128> Laney, it just happens that I'm still on precise
[08:24] <seb128> Laney, where the build works
[08:25] <Sweetshark> it started a few days ago. Possible changes a) a recent softwate update b) I ran the notebook with battery pack and DVD-drive removed for the first time around that time too.
[08:25] <Sweetshark> seb128: ^
[08:25] <seb128> Sweetshark, I don't think we had any recent update that should impact on the boot sequence
[08:26] <Sweetshark> seb128: maybe its just this screen handover to X stuff?
[08:26] <seb128> could be
[08:28] <Sweetshark> nvidia-drivers do not work since ~January on oneiric on this machine. Nouveau and intel mostly work.
[08:28] <Sweetshark> so the X stuff is somewhat tricky on this machine anyway.
[08:40] <dupondje> Something changed with gnome-shell recently ? Having a really annoying issue, which I can't seem to solve, and occuring more frequently now
[08:40] <dupondje> If I login to the gnome-shell, it fails to load completely
[08:40] <dupondje> no errors, nothing :s
[08:45] <seb128> dupondje, precise,
[08:45] <seb128> ?
[08:46] <seb128> Sweetshark, could be bug #969489
[08:46] <ubot2`> Launchpad bug 969489 in lightdm "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
[08:47] <seb128> Sweetshark, see comment #19
[08:48] <dupondje> seb128: precise indeed
[08:49] <dupondje> had it once a week or so before
[08:49] <dupondje> since last week, almost every startup :s
[08:49] <dupondje> quite annoying :)
[08:49] <seb128> dupondje, dunno, I don't think many people here are using g-s, maybe ask jbicha when he's around ... did you try to look to .xsession-errors when that happens?
[08:49] <Sweetshark> seb128: could be. Also added a SSD recently so maybe I am just booting too fast
[08:49] <seb128> Sweetshark, can you try to change suggested in comment 19?
[08:50] <dupondje> seb128: no errors in .xsession-errors. Can fix it with just going to other console, kill -9 gnome-shell, and then it runs fine.
[08:51] <Sweetshark> seb128: yes, will do. I would need some reboot to see if things get better.
[08:51] <seb128> Sweetshark, just change it and see how it goes in the next weeks?
[08:52] <Sweetshark> seb128: yes
[08:57] <Sweetshark> lightdm has too many files called lightdm.conf
[08:58] <didrocks> changing machine enables to make test suite less machine-dependant :)
[08:59] <didrocks> just 3 remaining issues, all were due to the same logo-thingy
[09:21]  * mvo lols@weboob-qt - there is dating website optimizer in there
[09:25] <ogra_> speeding up speed-dating ?
[10:02] <seb128> pitti, do you know if there is a blueprint somewhere about the new media size and what images we are aiming at having for q?
[10:03] <pitti> seb128: no, I don't think it was discussed at UDS
[10:03] <seb128> pitti, not sure if there was a proper UDS session about that
[10:03] <seb128> ok
[10:03] <seb128> pitti, thanks
[10:03] <pitti> this mostly happened at "on the floor" discussions with Rick and Steve, AFAIR
[10:04] <seb128> pitti, the floor discussions are biting back :p
[10:04] <seb128> i.e no proper record of the plan or anything it seems
[10:04] <pitti> seb128: well, Rick already announced it by mail beforehand
[10:04] <pitti> "we will reduce our image count to 1"
[10:05] <seb128> pitti, right, but there is no proper place to check what is required before i.e we can drop alternate
[10:05] <pitti> I think that part (teach ubiquity about LVM etc.) should have a BP
[10:05] <seb128> pitti, don't worry, I was just checking there is nothing I didn't find before registering a blueprint
[10:06] <pitti> seb128: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-ubiquity-lvm-luks
[10:06] <seb128> pitti, thanks
=== MacSlow is now known as MacSlow|lunch
[11:15] <didrocks> mvo: just fixed the crash on linuxmint and other derivatives in software-center (on the oneconf side)
[11:15] <didrocks> will spam a little bit less errors.ubuntu.com
[11:16] <didrocks> the tests were the most difficult to write due to potential races :)
[11:17] <didrocks> this could have never worked, which means that elementary, linuxmint, and other derivatives never tested installing anything on a configuration or that they didn't care to get an apport crash at each package installation…
[11:28] <soren> didrocks: "installing on a configuration"? What does that mean?
[11:29] <didrocks> soren: I eat some words: "on a configuration different from an ubuntu one"
[11:29] <ogra_> hmm, does it really make sense to have mint and frineds on erros.u.c ?
[11:30] <ogra_> given that mint suporesses many SRUs and security updates it wouldnt stop reporting, even if a fix was uploaded in ubuntu
[11:30] <seb128> ogra_, not sure, it's probably a "how do you filter them out"
[11:30] <seb128> ogra_, mint is mostly stock ubuntu with a few of their packages added
[11:31] <ogra_> yeah, finding a fiter thats a common denominator between all derivatives might be hard
[11:31] <ogra_> seb128, and with things like xorg, compiz, kernel and grub blocked from updates in their hacked update manager
[11:32] <seb128> right, well that's not something different on the packages content
[11:32] <ogra_> ask mdeslaur, i think he was the one who did an analysis of that bit
[11:32] <seb128> not sure if they change their lsb infos, I guess they do
[11:32] <ogra_> no, its not, but they wont get fixes we upload
[11:32] <ogra_> which means whoopsie will go on collecting issues
[11:33] <seb128> well, whoopsie collects the version where it happens
[11:33] <seb128> so you can filter out old versions
[11:33] <ogra_> ah, yeah
[11:33] <seb128> but yeah, we should filter them out, that's just a missing feature
[11:33] <ogra_> right
[11:33]  * ogra_ will bring that up in the next foundations meeting
[11:37] <mvo> didrocks: very nice, thanks, I have a look in  a bit
[11:37] <mvo> didrocks: I assume you submited a MP?
[11:38] <didrocks> mvo: sorry, I wasn't clear, I succeed in making that on the OneConf side only, so you don't have to review anything, it was more a FYI :)
[11:39] <mvo> didrocks: ah, even better \o/
[11:40] <didrocks> alf_: hey, around?
=== Guest40326 is now known as jbicha
[11:43] <jbicha> dupondje: yeah I run gshell half the time, but I don't really use precise and haven't seen that bug
[11:43] <jbicha> good morning
[11:49] <mdeslaur> seb128: yes, they do change their lsb infos
[11:54] <didrocks> ogra_: do you have more time now to get some build time on an armel machine?
[11:55] <didrocks> ogra_: would be nice to be able to fix this compiz issue without me doing 10 uploads
[12:02] <ogra_> didrocks, i'm on it
[12:02] <didrocks> ogra_: thanks :)
[12:35] <dupondje> hi jbicha, weird, having it alot last week :(
=== ara_ is now known as ara
=== MacSlow|lunch is now known as MacSlow
=== zyga is now known as zyga-afk
[13:04] <dobey> Laney: so basically, you generally never need to vote on your own merge proposals, and only really need to resubmit them if there are very large/differeng changes from the original proposal :)
[13:04] <pitti> glatzor: for the install_signature MP, do you want to wait for your python-apt MP to get the AptAuth bits merged?
[13:05] <didrocks> micahg: hey, around?
=== m_conley_away is now known as m_conley
[13:39] <Laney> dobey: I see, thanks for the education
[13:40] <dobey> sure
[13:53] <micahg> didrocks: now I am
[13:58] <ogra_> didrocks, still fails :(
[13:59] <seb128> cyphermox, hey
[13:59] <seb128> cyphermox, could you look at https://code.launchpad.net/~penguin359/ubuntu/precise/network-manager/fix-for-1005091-precise/+merge/107545 ?
[14:00] <cyphermox> yes, working on it
[14:00] <ogra_> didrocks, trying with s/-Werror // now
[14:00] <cyphermox> seb128: I thought I had already commented on it though
[14:01] <seb128> cyphermox, you maybe commented on the bug? I was looking at the sponsoring queue and it has the mr
[14:01] <cyphermox> nah, it's because there are multiple merge requests
[14:01] <seb128> cyphermox, yeah, just saw that
[14:02] <cyphermox> wtf
[14:03] <cyphermox> seb128: ETOOMANY
[14:03] <seb128> hehe
[14:03] <cyphermox> ;)
[14:03] <glatzor> pitti, I don't want to block you. I will merge the changes after the python3 port is done. but in the meantime you could carry the changes as a patch (they don't work with python3 yet)
[14:04] <glatzor> pitti, so there isn't any basic objection against your changes.
[14:04] <pitti> glatzor: it's not that urgent; not sure when cyphermox wants to start with writing the UI side, but once he does, I can hand him some local branches to run against
[14:04] <pitti> cyphermox: ^ FYI
[14:04] <glatzor> pitti, hopefully I will get the python3 upload ready today or tomorrow
[14:04] <pitti> glatzor: cool, thank you!
[14:04] <cyphermox> pitti, glatzor: cool, thanks
[14:05] <Sweetshark> seb128: any news on the 3.5.4 SRU? I applied for MRE in the meantime (no reply yet), but still ...
[14:05] <seb128> Sweetshark, slangasek confirmed that the SRU team will not accept it until the TB approve the MRE
[14:06] <desrt> good morning, developers of the ubuntu desktop.  i hope you are all well.
[14:06] <didrocks> ogra_: still fail, like, more error?
[14:06] <ogra_> same error
[14:06] <didrocks> how did you fix it? added the virtual?
[14:06] <ogra_> i used your patch
[14:06] <didrocks> virtual keyword on the destructor
[14:07] <glatzor> pitti, I still see this message in the build log: "g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting". Do you have got any idea what is happening?
[14:07] <didrocks> ogra_: hum, I didn't send a patch, just the branch with compiz vanilla as I was thinking you were handling the gcc4.7 fixes :)
[14:07] <didrocks> ogra_: anyway, -Werror will be fine for now
[14:07] <didrocks> micahg: small question on the chromium build: I have no webgl support (no acceleration on the browser), my intel card is pretty descent, any idea?
[14:07] <ogra_> didrocks, you gave me a tree that has sed parsing CFLAGS and CXXFLAGS
[14:08] <pitti> glatzor: I haven't seen this before, no; I can vaguely remember a pygobject bug about gio being broken for async operations, though
[14:08] <ogra_> for gles arches
[14:08] <didrocks> ogra_: oh right
[14:08] <ogra_> thats what i tried building
[14:08] <Sweetshark> seb128: uploading libreoffice_3.4.5+really3.4.4-0ubuntu1 right now, btw ...
[14:08] <ogra_> but i think what you drop isnt enough
[14:08] <seb128> Sweetshark, ok
[14:08] <didrocks> ogra_: yeah, seems so
[14:08] <glatzor> pitti, I only see those when building on launchpad
[14:08] <pitti> glatzor: might be gnome bug 671139
[14:08] <ogra_> sadly Werror still shows up everywhere in the flags
[14:08] <ubot2`> Gnome bug 671139 in introspection "need (transfer async) for io stream buffers" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=671139
[14:09] <micahg> didrocks: not offhand
[14:09] <didrocks> micahg: from the google help, it seems they require mesa 7.9, but it's fine, isn't it?
[14:09] <didrocks> micahg: I had it for a while, but not since last week
[14:09] <micahg> it should be
[14:10] <micahg> didrocks: which build are you running?
[14:10] <seb128> didrocks, webgl is a configure flag in webkit, not sure if that's the case for chromium as well
[14:11] <ogra_> didrocks, it seems like cmake/CompizCommon.cmake has Werror hardcoded
[14:11] <didrocks> micahg: the one we have in quantal
[14:11] <seb128> didrocks, we didn't turn it on for the standalone webkit yet
[14:11] <pitti> glatzor: does that break the build?
[14:11] <pitti> glatzor: we still have a lot of buildds on hardy kernels, some on lucid
[14:11] <didrocks> seb128: it's built with it, but I have to use --ignore-gpu-blacklist
[14:11] <glatzor> mvo, pitti  I think have to admit that I cannot get the test suite of aptdaemon running on the build bot.
[14:11] <pitti> glatzor: glib acts up a lot on those old kernels
[14:11] <micahg> didrocks: hrm, maybe there's some bad detection logic there, or the GPU is blacklisted for some other reason
[14:11] <didrocks> seb128: I notice, some of my animations for the quickly html template are pretty slow to render :)
[14:12] <glatzor> pitti, now the packagekit tests fail again without any changes to them .... https://launchpadlibrarian.net/106846697/buildlog_ubuntu-quantal-i386.aptdaemon_0.43%2Bbzr830-0~ppa1_FAILEDTOBUILD.txt.gz
[14:12] <didrocks> micahg: who should I talk to?
[14:12] <didrocks> ogra_: argh, feel free to patch it then :/
[14:12] <ogra_> hmpf, k
[14:12]  * micahg would suggest checking for a bug on crbug.com
[14:13] <didrocks> ok, will have a look then
[14:13]  * ogra_ tries something different
[14:14] <pitti> glatzor: so that happens consistently on the buildds, or sometimes on the buildds, and never locally?
[14:15] <glatzor> pitti,  the test suits runs without any errors on my local system (in quantal and wheezy). in the build before another test was failing but the once reported to be failed in 830~ppa1 had been successfull.
[14:16] <pitti> glatzor: so either a race condition, or it depends on which particular buildd you catch?
[14:16] <glatzor> pitti, so I re-uploaded the same source now with an increased version number only to try another buildd
[14:16] <glatzor> pitti, I haven't yet looked at the names of the buildds
[14:25] <ogra_> didrocks, hacked the cmake file directly for this testbuild, seems with that Werror is gone now, will report back if it survives  the build now
[14:25] <didrocks> ogra_: excellent, thanks! :)
[14:25] <ogra_> well, but thats indeed not the right thing to do for a general upload
[14:33] <ogra_> didrocks, ok, survived ... i'm at 53% now (it used to die at 51)
[14:34] <ogra_> but i'm not sure how we should hack the file properly without affecting all builds
[14:35] <didrocks> ogra_: \o/
[14:35] <didrocks> ogra_: hum, I would say "don't worry for now" as the next version of compiz we will push will have the patch merged
[14:35] <didrocks> ogra_: so at some point, the real gcc4.7 fixes for the armel part will be neede
[14:35] <didrocks> needed*
[14:35] <ogra_> didrocks, well, i need a working binary "yesterday"
[14:36] <ogra_> compiz ftbfs makes all arm image builds fail
[14:36] <ogra_> which isnt so good for A1
[14:36] <ogra_> :)
[14:37] <didrocks> ogra_: indeed, so just push that version
[14:37] <ogra_> with the manually hacked cmake ?
[14:37] <ogra_> k
[14:37] <didrocks> ogra_: yep, sounds good to me ;)
[14:38] <ogra_> sigh ... though that will be really hard ... the gles patch will fail to apply then since it touches the same file to set the gles options ... i wonder if we shouldnt just disable the gles patch :)
[14:39]  * ogra_ tries that with another testbuild 
[14:40] <didrocks> ogra_: at this point, just do whatever is best for you :)
[14:40] <didrocks> (sorry, in a hangout)
[14:40] <ogra_> heh, indeed
[14:45] <didrocks> as you told me there is no driver ready yet for armel, the damage seems to be very low :)
[14:46] <ogra_> well, we dont care about armel ... but yeah, there is no driver for armhf yet :P
[14:46]  * ogra_ will waer an "armel is dead" T-shirt every day at the next UDS to get that change across :) 
[14:46] <ogra_> *wear
[14:50] <ogra_> GAH !
[14:50] <ogra_> without the gles patch it indeed tries to build crap like cube and dies there
[14:51]  * ogra_ curses, i'm supposed to work on totally different things today, sigh
[15:08] <seb128> mvo, hey, do you really need sponsoring for https://code.launchpad.net/~mvo/software-properties/fix-policykit-prompt-on-startup/+merge/104655 ? ;-)
[15:27] <mvo> seb128: code review I think or did someone do that?
[15:27] <seb128> mvo, oh ok, you do code review for those ... it's showing on the sponsoring queue, I was trying to help dholbach with the "there are over 100 items on the queue"
[15:31] <mvo> seb128: well, its not required, it just would be nice
[15:32] <seb128> mvo, ok, I guess it can stay on the sponsoring queue until that happens ;-)
[15:33] <glatzor> pitti, it was really a buildd issue. on mercury all builds fine
[15:33] <glatzor> yeah!
[15:33] <pitti> glatzor: I blame the hardy kernel then :)
[15:33] <pitti> good night everyone!
[15:34] <glatzor> mvo, pitti, you can now use ppa:aptdaemon-developers/python3 to port your software.
[15:34] <glatzor> pitti, good evening martin!
[15:35] <mvo> glatzor: awsome, when can I upload?
[15:42] <pitti> glatzor: \o/
[21:27] <sgringwe> jasoncwarner_, ping
=== m_conley is now known as m_conley_away
[22:32] <sgringwe> jasoncwarner_, ping
[23:24] <nsbig> Where do I download the shared library (.so) files for PAM? I tried 'sudo apt-get install pam-modules' and it installs, but pam_access.so is missing.
[23:29] <RAOF> nsbig: This isn't a support channel, but pam-modules (at least in Quantal, and I see no reason why this would have changed) is the package which contains pam_access.so.
[23:34] <nsbig> libpam-modules is the package.
[23:40] <RAOF> Yeah, that one.
=== scott_ is now known as Guest80684