[13:54] <brendand> cr3 - further error after doing the workaround you suggested for the previous error: http://paste.ubuntu.com/644787/
[13:54] <brendand> i'm on Oneiric
[13:55] <cr3> brendand: dpkg -l launchpad-results-developer-dependencies, is it fully installed?
[13:56] <brendand> :/ perhaps not
[13:56] <brendand> brendand@brendan-6930p:~/src/launchpad-results/trunk$ dpkg -l launchpad-results-developer-dependencies
[13:56] <brendand> Desired=Unknown/Install/Remove/Purge/Hold
[13:56] <brendand> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
[13:56] <brendand> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
[13:56] <brendand> ||/ Name           Version        Description
[13:56] <brendand> +++-[13:56] <brendand> ii  launchpad-resu 0.3-1~ppa0.11. Meta-package for Launchpad Results developer
[13:59] <cr3> brendand: just the "ii" line would be enough :)
[14:00] <cr3> brendand: what about the python-psycopg2 package, is that fully installed? it should be a dependency of launchpad-results-developer-dependencies but we should make sure
[14:01] <brendand> cr3: sure is
[14:03] <cr3> brendand: interesting, in the source tree, run ./bin/py and then: import psycopg2
[14:04] <brendand> cr3: aha
[14:04] <brendand> Traceback (most recent call last):
[14:04] <brendand>   File "<stdin>", line 1, in <module>
[14:04] <brendand>   File "/usr/lib/python2.6/dist-packages/psycopg2/__init__.py", line 69, in <module>
[14:04] <brendand>     from _psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID
[14:04] <brendand> ImportError: can't import mx.DateTime module
[14:07] <cr3> brendand: might be a problem in oneiric then
[14:08] <cr3> brendand: you have the very latest packages from oneiric, right?
[14:11] <persia> If you have aptitude installed, the output of `aptitude search ~c` may reveal packages not quite in the ideal state.
[14:15] <cr3> brendand: do you have python-egenix-mxdatetime installed?
[14:16] <brendand> cr3: seem to
[14:16] <cr3> brendand: just to make sure, can you run ./bin/py and then: import mx.DateTime
[14:20] <brendand> cr3: can you run dpkg -L python-psycopg2 | grep tz
[14:20] <brendand> cr3: that import statement you asked me to run worked
[14:21] <cr3> brendand: /usr/share/pyshared/psycopg2/tz.py
[14:21] <brendand> cr3: ok, that's the same i have
[14:22] <cr3> brendand: can you pastebin the output of: ldd /usr/lib/python2.6/dist-packages/psycopg2/_psycopg.so
[14:23] <brendand> http://paste.ubuntu.com/644803/
[14:34] <cr3> brendand: thanks, I'll try installing oneiric and see if I can reproduce the problem with psycopg2
[14:38] <brendand> cr3: and conversely i'll boot up my natty system and make sure it does work there :)
[14:40] <cr3> brendand: awesome, thanks!
[15:24] <cr3> brendand: I suspect we're hitting a multi-arch support problem in psycopg2 on oneiric, let me know how it goes on natty and I'll submit a patch to psycopg2
[15:32] <brendand> cr3: hmm, for some reason i still get the same error i mentioned in the bug report on natty, even if i 'touch buildout-templates/placeholder.txt' and do make build again
[15:32] <cr3> brendand: did you touch placeholder.txt or placeholder.txt.in?
[15:32] <brendand> gah
[15:33] <brendand> forgot about the .in
[15:45] <brendand> cr3: you'll be glad to hear natty is okay
[15:49] <cr3> brendand: I reported bug #811115 against psycopg2 for now while I try to get an sbuild environment on oneiric for attempting to patch the package
[15:49] <ubot4> Launchpad bug 811115 in psycopg2 (Ubuntu) "[oneiric] ImportError: can't import mx.DateTime module (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/811115
[15:51] <jibel> Could anyone with privileges changes the topic to "Currently testing Lucid 10.04.3 LTS candidates | http://iso.qa.ubuntu.com | nVidia/ATI Proprietary Drivers | http://xorg.qa.ubuntu.com"
[15:52] <jibel> pedro_, are you allowed to do that ?
[15:53] <pedro_> not sure
[15:53] <pedro_> m nop
[15:54] <jibel> pedro_, :( thanks for trying
[15:54] <pedro_> " You are not authorized to perform this operation."
[15:54] <pedro_> np
[15:54] <patdk-wk> well, you have to be op'd first :)
[15:54] <pedro_> right that's why i've executed /msg chanserv op #ubuntu-testing
[15:54] <pedro_> and that was the output
[15:54] <patdk-wk> oh :)
[15:55] <patdk-wk> hungry
[15:59] <mvo> fwiw, the current failure in my auto-upgrader tester is that it can't find the rootfs when booting anymore
[16:00] <patdk-wk> 4 more hours till launchpad builds my packages :(
[19:26] <tamran> hi there.  I'm curious how I can change the lightdm theme to the unity one?  instructions are clear to test it but how do I make it boot into that theme?
[21:49] <njin> ubuntu-it-women


[12:06] <ahasenack> hm, on kinetic, is this upgrade combo safe? https://pastebin.ubuntu.com/p/Bwx8Tm3xyK/
[12:06] <ahasenack> apt is offering me to update grub-*, but not shim-signed


[00:11] <SpamapS> hrm.. libapache2-mod-wsgi is still python 2.6 only.. rebuild needed?
[00:17] <ebroder> SpamapS: it is? packages.u.c lists both a mod_wsgi.so-2.6 and a mod_wsgi.so-2.7
[00:19] <SpamapS> oh .. sorry my bad.. its just that if you install it you pull in 2.6
[00:20] <SpamapS> with the symlink pinted at -2.7
[00:20] <SpamapS> pointed even :-P
[00:34] <TheMuso> c
[00:40] <SpamapS> the letter you can swim in
[00:47] <RAOF> Ok, rather than trying to figure this out myself, time to be lazy: How do I get libtool to accept libdrm-nouveau1a as the SONAME for a library?
[01:18] <jono> anyone know how to file a bug in ubuntu-bug?
[01:18] <jono> it seems 'ubuntu-bug ubuntu-bug' doesn't work :-)
[01:18] <TheMuso> jono: you want ubuntu-bug apport
[01:18] <TheMuso> since apport has ubuntu-bug
[01:19] <jono> cool
[01:19] <jono> thanks TheMuso!
[01:19] <TheMuso> np
[01:19] <TheMuso> But yes, giving ubuntu-bug an executable and have it work out the package for you would be a nice to have.
[01:21] <RAOF> I thought that actually worked already?  man ubuntu-bug suggests it shouldn.
[01:23] <ebroder> RAOF: i bet it works if you give it a full path to an execuable
[01:23] <ebroder> *executable
[01:23] <RAOF> That might be it, yes.
[01:23] <ebroder> (note that ubuntu-bug appears to just dispatch between apport-{cli,gtk,kde}
[01:23] <ebroder> )
[02:07] <RAOF> How do I get libtool to accept libdrm_nouveau.so.1a as the SONAME for a library?
[05:43] <hyperair> say, what are the backports procedures these days?
[05:45] <micahg> hyperair: file a bug against the foo-backports project, test build, install, and run
[05:45] <hyperair> micahg: and how fast to those requests actually get through?
[05:46] <hyperair> iirc backports were a pretty slow process
[05:46] <hyperair> with an overly huge queue and overwhelmed folk handling it
[05:46] <micahg> hyperair: well, I haven't seen much recently, but there was a blueprint to improve things, I think the backporters are looking for people to help :)
[05:46] <hyperair> i'd like to help :)
[05:46] <hyperair> now where do i go to poke people about this..
[05:46] <micahg> hyperair: ok, talk to ScottK
[05:47] <hyperair> ScottK: so how do i help with backports?
[05:49] <micahg> hyperair: there's this to get you started: https://help.ubuntu.com/community/UbuntuBackports#How%20to%20Help
[05:49] <hyperair> ooh thanks
[05:52] <hyperair> micahg: hmm, it looks like ubuntu developers are allows to upload to -backports.
[05:52] <hyperair> this does speed things up
[05:54] <micahg> hyperair: yes, but one is not supposed to unless it's been approved and is not a straight backport
[05:54] <hyperair> micahg: approved by who?
[05:54] <micahg> hyperair: ubuntu-backporters
[05:54] <hyperair> micahg: you mean it isn't blocked by a backporting queue similar to -proposed?
[05:55] <micahg> hyperair: it is, but the process isn't to just upload like proposed
[05:55]  * hyperair groans
[05:55] <micahg> in most cases, an automated backport should be used
[05:56] <hyperair> alright
[05:59] <micahg> hyperair: what are you trying to backport?
[05:59] <hyperair> micahg: nothing at the moment, i was just trying to evaluate how much effort it would take to backport some of my packages
[06:00] <micahg> hyperair: so leaf packages are easier than libraries or packages that require newer versions of libraries as all the rdepends need to be tested
[06:01] <hyperair> yeah, i'm aware of that
[06:54] <dholbach> good morning
[07:36] <dholbach> pitti, heya - do we have any idea where the click/focus problem in natty comes from? was that the gtk update?
[07:43] <\sh> moins
[07:43] <\sh> can someone tell me, why we don't have any package (src/bin) of live-initramfs in maverick?
[08:43] <alkisg> Hi, a dbus upgrade has come to Lucid, and bug #552404 breaks its installation in chroots (e.g. LTSP).
[08:43] <pitti> Good morning
[08:44] <pitti> dholbach: "the click/focus problem"? Seems to work well here
[08:44] <dholbach> pitti, did you update and restart your session and use unity?
[08:44] <alkisg> Working around the bug is not trivial, it requires editing dbus.postinst to add a "|| true" to a dbus-send command. Is it possible to send another dbus update to Lucid with that "|| true" added?
[08:44] <zyga> pitti, click on titlebar but focus goes behind that window issue?
[08:44] <dholbach> I have funny problems where my clicks don't do anything at all
[08:45] <pitti> zyga: hm, maybe that doesn't happen with focus-follows-mouse
[08:45] <zyga> pitti, probably not, I don't like that setting, anyway - different issue
[08:45] <zyga> it still happens ~3 times a day for me
[08:57] <tkamppeter_> pitti, hi
[08:57] <pitti> hey tkamppeter_
[09:49] <seb128> @pilot in
[09:50]  * dholbach hugs seb128
[09:55] <pitti> seb128: happy piloting!
[09:56] <seb128> pitti, hey, thanks
[10:28] <tkamppeter> pitti, I have seen that you are heavily working on s-c-p. Are you planning that this should go into Natty?
[10:56] <\sh> pitti: any clue why we don't have any version of live-initramfs in maverick?
[10:57] <\sh> live-initramfs as source pkg or as binary pkg of live-boot in this case
[11:15] <ogra> is bzr branch lp:<something> refusing connections for anyone else ?
[11:15]  * ogra wonders if he missed a bzr downtime announcement
[11:16] <cjwatson> it's refusing here too
[11:23] <ara> yes, it is down for me as well, but I can't remember a scheduled down time
[11:23] <ogra> IS is inspecting
[11:23]  * soren upgrades to natty
[11:28] <soren> Wow. It wants to download 1763M.
[12:19] <cjwatson> SpamapS,jhunt: so I think I agree that we should include that restore-re-exec-code branch for 10.04.2, although I haven't read the code yet
[12:20] <cjwatson> SpamapS,jhunt: when you change umountroot, remember that you'll need a suitable Breaks on upstart, or some other handling to avoid the situation where umountroot is waiting for a re-exec that will never happen because upstart is too old
[12:24] <cjwatson> SpamapS,jhunt: I dropped one comment into the mp
[12:34] <elif> cjwatson: just to get a startup on howto build d-i for ubuntu, I mean create a .iso with the debian installer taled for ubuntu (rebranding, extra-features) is there a easy tutorial or somehow ?
[12:38] <cjwatson> elif: not AFAIK
[12:47] <cjwatson> doko_: I don't understand why bug 686263 is assigned to canonical-foundations; most of us can't do anything about it, since what it needs is MIR review?
[12:47] <Chipzz> pitti: hrrrm good example
[12:47] <Chipzz> I was trying to come up with an example where you would need libdbus but not dbus itself
[12:50] <tkamppeter> pitti, around?
[13:09] <pitti> tkamppeter: presumably not (just back from lunch)
[13:10] <pitti> tkamppeter: it'll still take a while to port stuff over, and it won't (easily) work with GTK2
[13:13] <sladen> cjwatson: that /etc/default/keyboard default brought up the textual debconf dialgoue again
[13:13] <cjwatson> yeah I know
[13:14] <cjwatson> I'm just about to try to whack that properly
[13:25] <tkamppeter> pitti, so it is better that I package 1.2.6 for now, to get up-to-date with the stable series s-c-p (and go 1.2.7+ if it comes before FF)_?
[13:26] <pitti> tkamppeter: yes, I think so
[13:26] <pitti> tkamppeter: I don't think that the gi stuff will land in 1.3, given that the version number already looks like "1.3 beta" (1.2.96)
[13:26] <pitti> tkamppeter: so we might switch to 1.3 eventually
[13:26] <pitti> tkamppeter: I'll send the current patch to Tim, and then we can discuss how to proceed
[13:31] <alkisg> >:o
[13:34] <tkamppeter> pitti, OK, so I wait for Tim's answer to you with the next package of s-c-p, but generally I will stay with 1.2.x or perhaps 1.3.x.
[13:36] <tkamppeter> pittim another problem is how s-c-p and jockey access the internet to download drivers via OpenPrinting. It does not support proxies. Can you fix that?
[13:38] <soren> ARGH. NATTY STOLE MY CAPS LOCK AND LEFT IT ON.
[13:38] <pitti> tkamppeter: I saw the email; I think urllib2 supports proxies
[13:38] <directhex> tkamppeter, i'm expecting a phone call from kyocera uk at some point today about providing a monolithic "all ppds" download for openprinting purposes
[13:38] <pitti> tkamppeter: I'll look into it, but not today
[13:39] <pitti> tkamppeter: I'm still on the GNOME hackfest
[13:41] <dholbach> soren, IZ GTK BOOG!
[13:42] <dholbach> SCNR
[13:42] <soren> SCNR?
[13:44] <dholbach> daniel@miyazaki:~$ wtf SCNR
[13:44] <dholbach> SCNR: sorry, could not resist
[13:44] <dholbach> daniel@miyazaki:~$
[13:46] <Chipzz> pitti: it does, but it doesn't support fetching https through proxies (if that would be relevant)
[13:50] <tkamppeter> pitti, OK, next week would be OK for that.
[13:56] <smb> pitti, Heya, I think we need to enable the same work-around in the power-management scripts in userspace (not sure it was a disable or rip out) we had  in Lucid for Maverick and even Natty. see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539467
[13:57] <smb> pitti, Unfortunately there still seem to be some combinations of controller and disks around that get corrupted when sata alpm is enabled
[13:57] <soren> dholbach: Any hints for a fix?
[13:58] <dholbach> soren, no, sorry - I was just joking around
[13:59] <soren> dholbach: Ah. Now I don't love you anymore.
[13:59] <dholbach> soren, that was quick - who did you leave me for?
[14:02] <soren> SOMEONE WHO CAN GIVE ME BACK CONTROL OVER MY CAPS LOCK KEY. :)
[14:05] <soren> dholbach: Sorry, I'm slow today. I see what you mean now :)
[14:06] <soren> dholbach: I didn't get it fixed until just now. My "no love" commen was written with my shift key held down :)
[14:07] <dholbach> :)
[14:10] <cjwatson> soren: edit /etc/default/keyboard; also edit /etc/default/console-setup; take the four commented-out XKB* lines at the end of /etc/default/console-setup, and replace the four XKB* lines in /etc/default/keyboard with those (uncommenting them in the process)
[14:12] <ari-tczew> seb128: could you sponsor it? https://code.launchpad.net/~om26er/ubuntu/maverick/nautilus/nautilus-fix-630512-maverick/+merge/45048
[14:13] <soren> cjwatson: Cool. Is that read at boot time or do I need to do something in particular to make it take effect?
[14:14] <cjwatson> soren: it's read at boot; you can use setxkbmap to fix things up in X
[14:16] <ari-tczew> seb128: please sponsor also https://code.launchpad.net/~om26er/ubuntu/maverick/empathy/empathy-fix-666288/+merge/45740
[14:17] <soren> cjwatson: Ah, right. Awesome, thanks.
[14:19] <directhex> tkamppeter, guy i spoke to from kyocera uk will try to convince central control at KM europe in germany to provide an "all ppds" download for easy use by openprinting
[14:22] <ScottK> hyperair: The information micahg gave you was good.
[14:22] <ScottK> hyperair: If there are backport requests that you think are ready for approval, please feel free to ping me with the bug number.
[14:23] <hallyn> are we supposed to be in a natty alpha2 freeze right now?
[14:24] <cjwatson> no
[14:24] <hallyn> aweseome
[14:24] <cjwatson> we're nearly two weeks away from alpha 2 yet
[14:24] <hallyn> woudl you mind taking a look at https://code.launchpad.net/~serge-hallyn/ubuntu/natty/qemu-kvm/qemu-kvm-kvmgrp/+merge/46993 ?
[14:24] <cjwatson> buried in plymouth right now - can you send me mail?
[14:24] <hallyn> yup, thanks
[14:31] <amitk> ebroder: bug 705912 filed against pango and subscribed you as requested
[14:35] <amitk> ev: ^^^ you don't think this is an installer bug, right?
[14:44] <ev> amitk: correct
[14:52] <anwar> hi guys .. i have a simple question
[14:54] <Proto> Hi guys. Quick question. How do you free memory that was allocated using the function readline from the gnu readline library? Thanks
[15:03] <cjwatson> Proto: free ()
[15:03] <cjwatson> Proto: the man page says it's allocated with malloc (), and the inverse of that is free ()
[15:05] <Proto> well I user free() but dmalloc tool that I am using reports that there is a memory leak. I only had two lines in my code. the readline and the free.
[15:05] <Proto> *used
[15:06] <anwar> i'm a web developer and i work on windows environment..  and i want to develop on ubuntu .. where do i have to start ? there are alot of resources in the wiki page and it's a bit confusing for me because i'm a regular user to ubuntu .. can u tell me where to start ?
[15:08] <Chipzz> anwar: pls ask in #ubuntu, your question is not appropriate for this channel
[15:09] <micahg> anwar: you could also try #ubuntu-server
[15:10] <anwar> thank u guyz .. sorry
[15:10] <Chipzz> micahg: hrrrrm not really
[15:10] <cjwatson> Proto: I'd suggest using valgrind and getting it to report the exact location of the leak
[15:10] <Chipzz> micahg: (at least I think so)
[15:10] <micahg> Chipzz: the apps needed for web dev on ubuntu are server apps :)
[15:11] <cjwatson> sometimes libraries allocate themselves a bit of persistent state on initialisation or something, which isn't generally worth worrying about
[15:11] <Chipzz> micahg: yes, but there's a difference between "I haven't bothered to read a 'how do I set up apache' tutorial" and "I have apache all set up, but this module doesn't work"/"there's a bug in this server package"
[15:12] <micahg> Chipzz: indeed, but #ubuntu-server is also ubuntu-server-support :)
[15:12] <Chipzz> micahg: yes, but even in support you can try to start somewhere yourself, like reading tutorials, before asking ;)
[15:13] <Proto> cjwatson: thanks. I'll look it up.
[15:21] <sladen> .wub
[15:33] <bcurtiswx> ping bazaar.launchpad.net is failing here.. anyone else confirm?
[15:34] <dholbach> bcurtiswx, http://identi.ca/launchpadstatus
[15:35]  * bcurtiswx adds that to his identica
[15:35] <bcurtiswx> thx dholbach
[15:35] <dholbach> de nada
[15:38] <hyperair> ScottK: alright, will do
[15:41] <apw> pitti, it seems code hosting is in a heap.  that seems to be stopping the work-items stuff updating as it starts with a bzr pull ... should i disable that bit for the time being
[15:42] <poolie> apw, http://blog.launchpad.net/general/code-hosting-offline
[15:43]  * apw screams at OSD ... let my X server show me things while you are lost and confused and waiting to display poolies message
[15:43] <apw> poolie, thanks
[15:44] <cjwatson> doko: any progress on bug 684703?  the last comment on the bug is ScottK asking you for how to provide the information you requested; did you discuss that outside the bug?
[15:45] <ScottK> cjwatson: No discussion outside the bug that I recall (if there was, I need a refresh).
[15:52] <SpamapS> cjwatson: ack, re upstart/sysvinit/etc. changes
[15:53] <cjwatson> ScottK: ok, logged that in the bug with a ping
[15:53] <doko> cjwatson, ScottK: are these non-virtual thunks referred to in other libs?
[15:53] <SpamapS> cjwatson: re adding a breaks.. I was going to have it time out after 5 seconds of waiting.
[15:53] <ScottK> doko: No.
[15:53] <SpamapS> cjwatson: though probably good to have both isn't it?
[15:54] <doko> sorry, s/libs/binaries/
[15:55] <ScottK> They are non-virtual thunk.
[15:55] <cjwatson> SpamapS: sounds plausible
[15:55] <doko> ScottK: then why add these to the symbols files at all?
[15:56] <ScottK> doko: It's what dpkg-gensymbols generates.
[15:56] <ScottK> c++filt _ZThn16_N11KDcrawIface12RExpanderBoxD0Ev
[15:56] <ScottK> non-virtual thunk to KDcrawIface::RExpanderBox::~RExpanderBox()
[15:56] <ScottK> That's in libkdcraw9.symbols
[15:56] <doko> ScottK: well, maybe ask buxy why he wants these mentioned in the symbols files?
[15:57] <SpamapS> cjwatson: so, upstart should have    Breaks: libc6 ( << $version_that_disables_telinit_u ) ..
[15:57] <ScottK> doko: They weren't different on different archs before.  Why now?
[15:57] <SpamapS> cjwatson: and sysvinit would need Breaks: upstart ( << $version_that_adds_re-exec )
[15:58] <buxy> I don't "pick" symbols, I take everything that's exported.
[15:58] <ScottK> doko: I'm not a build system expert, but right now I have to test build that package on all archs to get a package that builds.  That's not supportable.
[15:58] <ScottK> doko: See buxy's reply ^^^^
[15:59] <cjwatson> SpamapS: right
[15:59] <cjwatson> I think
[16:00] <SpamapS> cjwatson: that should just help apt decide the order to configure things, right?
[16:01] <cjwatson> yeah, it's not foolproof here
[16:01] <cjwatson> well, though the libc6 telinit u is at configuration time
[16:01] <SpamapS> postinst specifically
[16:01] <cjwatson> that's the bulk of configuration :)
[16:01] <doko> ScottK, buxy: well, symbols files shouldn't be used unreflected for C++ libs. Debian #605833 is another (unrelated) case
[16:01] <cjwatson> I'm more hoping that it will prevent some of the more basic partial upgrade mistakes
[16:02] <buxy> doko: true, but MoDaX has done such work there that it gets more common...
[16:03] <doko> buxy: which work?
[16:03] <SpamapS> cjwatson: right, I think at some point we have to accept that if you install the new upstart and somehow force the old postinst to run.. you have broken your system, not dpkg/apt/ubuntu devs.
[16:04] <buxy> doko: the possibility to map symbols by their demangled name
[16:04] <SpamapS> I'd say with a Breaks: line, that shold be sufficient, but I am certainly not an authority on how breaks works in the real world.. only how its worded. :p
[16:04] <buxy> and other similar stuff
[16:05] <cjwatson> SpamapS: in practice the thing I care about is that if you say 'apt-get install sysvinit' it'll upgrade upstart and libc6 tooo
[16:05] <cjwatson> *too
[16:05] <cjwatson> Conflicts is likely far too invasive
[16:07] <doko> ScottK, buxy: so if we agree that these thunks don't belong the interface, then maybe make them optional by default?
[16:09] <SpamapS> cjwatson: I'll test for that scenario right now.. :)
[16:10]  * SpamapS thinks it would be wise to always have a libc6 tree with the build step completed lying around.
[16:10] <buxy> doko: I have no idea whether they belong to the interface or not, and I don't think that I want to have lots of special-cases in dpkg-gensymbols, in particular when these are difficult to identify (I don't want to always run c++filt)
[16:11] <buxy> I rather suggest that the affected package uses the (c++) tag to match this symbol in arch-neutral way
[16:11] <doko> buxy: well, these "special cases" are defined. http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
[16:18] <bcurtiswx> cjwatson, remember the empathy build issues from yesterday?
[16:19] <cjwatson> bcurtiswx: yes
[16:19] <bcurtiswx> cjwatson, i have a new error i'd like to share with you and get some advice on
[16:20] <cjwatson> best share it with somebody else
[16:20] <cjwatson> I'm in a meeting and about to finish for the week after that
[16:20] <bcurtiswx> cjwatson, OK ignore email then
[16:20] <cjwatson> desktop people would be better
[16:21] <bcurtiswx> seb mentioned to talk to you if I could
[16:21] <bcurtiswx> i appreciate your time tho, have a good rest of day and weekend
[16:21] <cjwatson> oh, any particular reason?
[16:21] <cjwatson> I mean, I know the autotools, but lots of people do :)
[16:22] <bcurtiswx> cjwatson, src/Makefile.am: object `empathy-accounts-dialog.$(OBJEXT)' created both with libtool and without
[16:23] <bcurtiswx> seems one of the binaries added to empathy_chat_SOURCES causes autoreconf to complain
[16:23] <cjwatson> there's a section on that in 'info automake'
[16:23] <bcurtiswx> ok
[16:23]  * bcurtiswx looks
[16:23] <cjwatson> http://www.gnu.org/software/automake/manual/automake.html#Libtool-Issues
[16:23] <cjwatson> explains it better than I can
[16:24] <SpamapS> I notice that upstart was uploaded to lucid-proposed as an SRU back in August with the version 0.6.5-7 instead of 0.6.5-6.1  ...
[16:24] <SpamapS> should this SRU be -8 or -7.1 ?
[16:24] <ScottK> doko: I don't know enough to have an opinion of if they should be optional by default.  I just know it's a lot more effort to maintain symbols files if they vary per arch.
[16:25] <cjwatson> either is fine - it just needs to not clash with maverick, and maverick went from 0.6.5-6 to 0.6.6-1
[16:25] <cjwatson> SpamapS: ^-
[16:25] <cjwatson> see https://launchpad.net/ubuntu/+source/upstart/+publishinghistory
[16:25] <cjwatson> if it were me, I would follow the pattern and use -8
[16:25] <seb128> bcurtiswx, just built with --no-as-needed for now
[16:25] <doko> ScottK: sure, but you have to live with it
[16:25] <seb128> bcurtiswx, it will be easier
[16:25] <SpamapS> less confusing then to use -8 :)
[16:25] <ScottK> doko: Why?  I didn't have to live with it with gcc4.4.
[16:26] <SpamapS> cjwatson: ty
[16:26] <seb128> seems weird that to add new files to _source we need to list all the other files it uses to land in that issue
[16:26] <bcurtiswx> seb128, the info cjwatson gave says to add a empathy_chat_CFLAGS=$(AM_CFLAGS) i will try that
[16:26] <doko> ScottK: because types of parameters are mangled too
[16:26] <cjwatson> you've always had to list everything you use in _SOURCES, unless there's an internal library or something
[16:28] <doko> seb128: what has something missing in _SOURCES to do with the linker flag?
[16:28] <ScottK> doko: I'll add this discussion to the bug then.
[16:28] <seb128> cjwatson, ok, we have a new file from a distro patch, I though that we used to include only that one
[16:28] <seb128> not that one and all the files this source is using
[16:28] <seb128> in the right order
[16:28] <cjwatson> ordering may be new, but I doubt the rest is
[16:28] <cjwatson> the linker has never magically found symbols for you
[16:28] <seb128> doko, the initial issue was it complains about non found symbols
[16:29] <seb128> ok, not sure why bcurtiswx gets that error then after adding the sources in order
[16:29] <zyga> mpt, hi, do you have a moment?
[16:29] <mpt> zyga, yep
[16:30] <doko> seb128: is there a report open? imo, there should be for every case, where we use a workaround
[16:30] <seb128> bcurtiswx, I will try to debug that the day I've a config with the GNOME3 ppa to do test builds
[16:30] <zyga> mpt, what do you think of an idea to put "rate this application" or "go to software center" in the help menu of applications linked with launchpadintegration?
[16:30] <seb128> doko, no, it's for a ppa with unstable version, not for natty
[16:30] <doko> ok
[16:30] <seb128> which is what makes debugging hard, nobody but bcurtiswx has the packages installed to build it
[16:31] <bcurtiswx> seb128, i can share my .pbuilderrc as I have it working with GNOME3 PPA whenever you want.. that way its as "simple" as pbuilder-dist
[16:32] <seb128> bcurtiswx, I know how to set up a pbuilder or a vm thanks, I just don't have the bandwith to do a full GNOME install in a pbuilder right now
[16:33] <bcurtiswx> seb128, i figured you knew how to pbuilder/VM :P just offered my rc file
[16:33] <seb128> or rather it would slow down my internet enough and I'm using it for other things I work on
[16:33] <bcurtiswx> well good news so far, is it didn't fail at autoreconf
[16:33] <mpt> zyga, "Rate This Application" in an application's Help menu is plausible (though it isn't really anything to do with help), but that has nothing to do with whether the application is in the Ubuntu archive, and therefore I don't think it belongs in launchpad-integration. (I think launchpad-integration should die in a fire, but that's irrelevant for that reason.)
[16:34] <zyga> mpt, technical bits are not interesting to me, I just wonder how you'd think we can encourage (or if we should in the first place) users to rate applications
[16:34] <zyga> mpt, or allow them to install additional content
[16:37] <mpt> zyga, so, "Rate This Application" in the "Help" menu I'm ok with
[16:37] <mpt> avoiding the technical bits :-)
[16:38] <zyga> mpt, what kind of UI would you like there?
[16:38] <mpt> zyga, opening USC to the application's screen and automatically opening the review dialog, I guess
[16:38] <zyga> mpt, a dedicated rate window or direct hop to the software center?
[16:39] <mpt> hm
[16:39] <mpt> maybe it wouldn't be necessary to open the main USC window
[16:39] <zyga> mpt, I'm not familiar with that part, does the user need to be signed in to write comments? (think about the very-first-time-to-rate-anything)
[16:40] <mpt> zyga, yes they do. So going through <https://wiki.ubuntu.com/SoftwareCenter/RatingsAndReviews#reviews-reviewing> from the beginning.
[16:41] <zyga> mpt, great, that's the window I was thinking of
[16:41] <SpamapS> doko: are you working on the eglibc SRU to lucid btw? I did test it yesterday and it works well.
[16:41] <zyga> mpt, now to technical bits, who should I talk to?
[16:42] <doko> SpamapS: just that what I did prepare on p.c.c  or should the change about the restart issue backed out?
[16:44] <mpt> zyga, mvo or tremolux to start with, to add a command line or d-bus signal or something for "please start the review process for X"
[16:44] <mpt> to USC
[16:45] <SpamapS> doko: the one you had on p.c.c needs to go in before the upstart change.
[16:45] <SpamapS> doko: or at least, simultaneously now that I've added a breaks << that version
[16:49] <SpamapS> doko: the change to postinst to disable telinit u on upgrade is vital.
[16:49] <doko> SpamapS: are you ok with the eglibc upload during the freeze?
[16:49] <doko> cjwatson: ^^^
[16:49] <cjwatson> yes, per mail (were you cced on that?)
[16:49] <cjwatson> marjo has acked it
[16:50] <cjwatson> well, wait, what else is in the eglibc upload?
[16:51]  * SpamapS hears the ominous change in the music
[16:52] <cjwatson> mostly I just realised I didn't quite know what all I was acking
[16:52] <SpamapS>   * Fix issue #12077, __strncmp_ssse3 can segfault when it over-reads
[16:52] <SpamapS>     its buffer.  LP: #702190.
[16:56] <Tribaal> Hi folk, I'm trying to get uic to generate an implementation for my header file, but can't. I'm using "uic -impl myheader.h" and expect output to stdout (as the manpage suggests), but uic complains by giving me the usage text...
[16:57] <cjwatson> doko,SpamapS: bug 702190 is OK if you can provide a test case so that the QA team have some hope of validating it
[16:57] <zyga> mpt, thanks
[17:03] <doko> cjwatson: a test was added in the fix, so a rebuild on this hardware should show it
[17:04] <cjwatson> can we guarantee building on the appropriate hardware?
[17:04] <doko> no
[17:04] <cjwatson> perhaps the test can be extracted such that QA can run it externally
[17:06] <doko> ok, will do
[17:07] <SpamapS> doko: let me know if you need anything.
[17:22] <seb128> barry, doko, do you think you could review bug #695005 (sponsoring request)?
[17:23] <seb128> doko, especially since you had some concerns about it and the update seems non trivial
[17:31] <seb128> hum
[17:36] <seb128> so gdm has a deluser call in its postrm, which fails when gdm is running...
[17:36] <seb128> is there a standard way to deal with those issues?
[17:36] <seb128> seem quite some users try to uninstall gdm from a session started by gdm and report bugs
[17:36] <seb128> well apport report bugs because the postrm fails
[17:38] <ScottK> lamont: Can haz postfix 2.8 for Natty?
[17:47] <SpamapS> http://gyp.blogs.balabit.com/2011/01/using-upstart-in-a-chroot/
[17:47] <SpamapS> wow
[17:50]  * SpamapS thinks upstart-dummy needs to be packaged and maybe even integrated with schroot/sbuild... :-D
[17:54] <cjwatson> SpamapS:
[17:54] <cjwatson> https://code.launchpad.net/~canonical-scott/upstart/session-support
[17:55] <cjwatson> so "not planned to be fixed soon" is mistaken
[17:56] <Lopi> ogra: ping
[18:00] <SpamapS> cjwatson: as excited as I am for that bit of news, I doubt it will be backportable to lucid, and I have to wonder how we'll use it from a lucid chroot -> a newer upstart .. do we need to shim in a session-aware initctl?
[18:02] <cjwatson> dunno, I imagine a dummy thing is a reasonable stopgap for such environments
[18:02] <cjwatson> that problem will go away eventually
[18:04] <slangasek> bdrung: I wonder why libkibi needs a -dbg package in the archive
[18:06] <bdrung> slangasek: because libkibi in ubuntu is identical with the version for debian and IIRC debian does not have ddebs
[18:06] <slangasek> it does not, but why does this library need a -dbg package in Debian either?
[18:07] <slangasek> it seems to have few moving parts :)
[18:07] <bdrung> slangasek: to help debugging problems in the library. every program has at least one bug (or is outdated). ;)
[18:08] <slangasek> bdrung: yes, but -dbg libraries come with a cost to mirrors; I would hope the Debian ftp team would not accept such a -dbg package (but experience suggests to me they probably will)
[18:50] <micahg> I have a question about versioning for an SRU, I have xubuntu-docs at 9.10.1 in karmic and lucid, I'm about to upload to lucid, I was going to use 9.10.1+really10.04.1, but then karmic will be left with a version that can't be updated, I was originally going to use <IP_ADDRESS>.04.1, but that looked ugly, any ideas?
[18:53] <doko> cjwatson: are you ok with upstrart changes from SpamapS ?
[18:58] <SpamapS> micahg: wouldn't it be updatable as  9.10.1+really<IP_ADDRESS> ?
[18:58] <micahg> SpamapS: which?
[18:58] <SpamapS> micahg: you said it wouldn't be updatable with the +really10.04.1 tag .. but you could of course add things onto that.
[18:59] <micahg> SpamapS: no, I mean to update karmic, I'd have to do 9.10.1+really09.10.1
[19:00] <cjwatson> doko: the last version I saw was fine
[19:01] <doko> ok
[19:01] <cjwatson> doko: assuming that the libc6 version matches, which I haven't checked
[19:02] <micahg> cjwatson: any ideas about my versioning conundrum?
[19:03] <cjwatson> micahg: mm, you don't have a lot of room since maverick and natty are still on 9.10.x (!)
[19:03] <micahg> right :)
[19:04] <cjwatson> I think you're stuck with inventing something ugly that gives you enough space
[19:05] <micahg> cjwatson: the package has no depends, so maybe I should just bump to 10.04.1, updates are planned for maverick and natty later, but the changes in maverick even were not version specific
[19:05] <micahg> and the relavent changes were included in this update for lucid
[19:05] <cjwatson> you could update natty, then maverick, then lucid, then karmic
[19:05] <cjwatson> so that everyone's comfortable that version increase will be preserved
[19:06] <cjwatson> I'd be nervous of bumping lucid beyond maverick's version; it's all too easy to forget to clean up later
[19:07] <micahg> so I guess <IP_ADDRESS>.04.1 so that there's room to update karmic and it's pre-maverick
[19:08] <micahg> cjwatson: thanks
[19:21] <doko> cjwatson, SpamapS: eglibc and upstart uploaded
[19:21] <doko> SpamapS: same game for maverick?
[19:21] <SpamapS> cjwatson: oo, I just saw that your plymouth change to listen for upstart events came through. Very cool. :)
[19:22] <SpamapS> doko: yes I'll push that one momentarily
[19:22] <doko> plymouth ftbfs
[19:23] <cjwatson> doko: fixed a moment ago in ubuntu12
[19:24] <cjwatson> SpamapS: hope it works :)
[19:24] <cjwatson> doko: thanks, I'll review them a bit later this evening
[19:25] <cjwatson> SpamapS: it becomes fairly obvious that there hasn't been a terribly consistent policy on upstart job descriptions, mind you
[19:25] <cjwatson> we may have to revise some of them, or revise the bridge code
[19:25] <cjwatson> anyway, out for a bit
[19:27] <SpamapS> doko: do you happen to know the maverick eglibc version you'll be uploading?
[19:27] <doko> SpamapS: http://people.canonical.com/~doko/tmp/  2.12.1-0ubuntu10.2
[19:29] <SpamapS> doko: cool, will start a test build now
[19:58] <anwar> where can i find projects to contribute ? using Python ?
[21:20] <bcurtiswx> where would I search to see if XSendEvent is deprecated ?
[21:20] <bcurtiswx> and what to replace it with
[21:22] <bcurtiswx> im looking at http://paste.ubuntu.com/556660/
[21:26] <janimo_> bcurtiswx, what suggests that it is deprecated
[21:26] <janimo_> ?
[21:26] <bcurtiswx> janimo_, nothing.. just a guess
[21:26] <bcurtiswx> http://mail.gnome.org/archives/desktop-devel-list/2010-September/msg00025.html im looking there at an XSendEvent
[21:29] <janimo_> there XSendEvent is not replaced by something else
[21:56] <slangasek> james_w: whoo, habemus ramās!  Is that you fixing things so the udd branches work again? :)
[21:57] <james_w> slangasek, never!
[21:57] <slangasek> oh, well, /someone/ just fixed the import of the gourmet package :)
[21:58] <jelmer> slangasek: jam should be the target of your gratitude :-)
[21:59] <slangasek> jam: thank you :)
[22:00] <jam> slangasek: happy to
[23:06] <manjo> superm1, https://wiki.ubuntu.com/Kernel/Testing/UbuntuUEFI
[23:52] <ebroder> wow. somebody put a lot of work into the sponsor queue today. kudos to whoever it was


[21:20] <OvenWerks> Eickmeyer[m]: right... sorry
[21:20] <Eickmeyer[m]> OvenWerks: Also, when you get your new PS, would you mind testing latency with the generic kernel? There are a number of show-stoppers with the lowlatency kernel that have been reported that don't occur with the generic kernel.
[21:20] <OvenWerks> I have to check my autojack fix first.
[21:21] <OvenWerks> generic should work fine at 1024 :)
[21:21] <OvenWerks> To be honest that is what I run most of the time
[21:22] <Eickmeyer[m]> Ah. Well, then why are we even shipping the lowlatency kernel anymore?
[21:22] <OvenWerks> with proper monitoring 1024 or higher is fine for recording.
[21:22] <OvenWerks> if using the computer as a guitar effect or softsynth it is needed
[21:23] <OvenWerks> for guitar effects I find 128 is maximum I am comfortable with
[21:23] <OvenWerks> I can handle 256 for softsynth
[21:24] <OvenWerks> but use 64 or 32 by preference for guitar effects like guitarix
[21:24] <Eickmeyer[m]> Well, sure, but I'm wondering if the same can be done with the generic kernel. I've been noticing issues with my Nvidia computer and the lowlatency kernel, but we also have people having locking issues when using AMD hardware that don't exist with generic.
[21:24] <OvenWerks> wow. wonder what liquorix does that is different
[21:24] <Eickmeyer[m]> (and the kernel team has been helping very little with fixing those issues)
[21:25] <OvenWerks> that is historical
[21:25] <Eickmeyer[m]> Yeah, they seem uninterested, so it's an uphill battle.
[21:25] <OvenWerks> originally Studio got the lowlatency kernel running and the k team took it over once it was going
[21:26] <Eickmeyer[m]> Yeah, but I'm noticing the .diff between the generic and lowlatency kernels getting bigger.
[21:26] <OvenWerks> in other words we can make a change to what LL kernel is and pass it to them they will make the change, but they do not have the resources to actually fix it.
[21:27] <Eickmeyer[m]> Unfortunately, I don't know enough about kernel configs to do anything about it.
[21:27] <OvenWerks> remeber also that the nvidia driver is a blob
[21:27] <OvenWerks> same here
[21:27] <Eickmeyer[m]> Which is why, with the lowlatency optimizations hitting the kernel, if we should even bother anymore.
[21:29] <Eickmeyer[m]> Rather, I'm wondering if we should even bother anymore.
[21:29] <OvenWerks> we would need a wiki (unofficial maybe) that gives directions for getting liquoix then.
[21:30] <OvenWerks> Eickmeyer[m]: without ll or rt we loose credibility as an audio distro
[21:31] <Eickmeyer[m]> Well, that's because people are stuck in the past where you had to have the patches in the kernel, which hasn't been the case since 2.6, and Torvalds already approved the lowlatency patch, so it should all be in the generic kernel by now.
[21:33] <OvenWerks> Eickmeyer[m]: the generic kernel if started with the right comandline switches becomes lowlatency. I will (when I have time) play with kernel switchs to see if I can make any difference that way. My son's box has an nvidia card and so far has had no problems.
[21:34] <OvenWerks> Eickmeyer[m]: do we have documentation on the differences from generic to ll?
[21:34] <OvenWerks> Maybe we just need to change one of them
[21:35] <Eickmeyer[m]> OvenWerks: I did a .diff a while ago, and the diff is pretty big anymore. I might be able to do another one.
[21:35] <OvenWerks> any way, I have to go for a bit and get my Yf to work.
[21:35] <OvenWerks> maybe the diff is outdated then
[21:35] <OvenWerks> I think the original diff was against a 3.* series kernel.
[21:36] <Eickmeyer[m]> Probably. I'll try to generate a config diff now.
[21:36] <OvenWerks> When I get back I will have use of my Yf's computer where I started work on autojack.
[21:42] <Eickmeyer[m]> OvenWerks: Sounds good. Here's the diff: https://paste.ubuntu.com/p/4SRy8WjpXN/