[00:01] <lamont> Daviey: go ahead, I'm afk for the evening as of about 30 sec ago
[00:01] <Daviey> lamont, Okay, your PPA backport == the sid package?
[00:07]  * Daviey diffs
[01:20] <ScottK> You have to ask the questions before they are AFK.
[01:20] <ScottK> ;-)
[02:14] <lamont> Daviey: ISTR that there might be a dpkg change that required a tweak to the package for lucid
[02:14] <lamont> Daviey: so I'd say grab the ppa.  not just because that's what I tested
[02:14] <lamont> worst case, I should be able to do it tomorrow
[03:05] <c2tarun> why I am getting this error curl: (6) Couldn't resolve host 'people.canonical.com'  on running rmadison kdeedu in natty chroot
[03:12] <ScottK> Probably because you use dhcp and you got a new IP address since you created the chroot.
[04:08] <psusi> ok... I have proposed tasks for lucid and maverick for bug #662194, backported the one line patch from natty to maverick and lucid, pushed the bzr branches to lp, proposed they be merged, linked them to the bug report, subscribed unbuntu-sru and ubuntu-sponsors... did I miss anything?
[04:38] <nigelb> jdstrand: yes, go ahead :)
[04:38] <nigelb> jdstrand: I don't have powers to do it, but probably dholbach has :)
[06:04] <pitti> Good morning
[06:08] <c2tarun> pitti, good morning :)
[06:09] <c2tarun> pitti, hey can you please help me with splitting packages?
[06:09] <pitti> what do you want to do?
[06:10] <c2tarun> pitti, I was working on bug 683439
[06:10] <c2tarun> pitti, its my first time and I dont know how to split, I did some steps but not sure I am right.
[06:12] <c2tarun> pitti, I moved the mobile folder from kalgebra outside it and renamed it as kalgebra-mobile. In file kalgebra.install there is one line related to kalgebramobile so I copied that line to another file name kalgebra-mobile.install, I added lines for kalgebra-mobile in debian/control but dont know how to fill some fields. :/
[06:13] <pitti> c2tarun: roughly, you have to add the new package to debian/control, then update all affected debian/pacakgename.install to install the files to the new package instead, and finally the new package needs a Breaks:/Replaces: <package which previously shipped the files> (<< your_new_version)
[06:13] <c2tarun> pitti, is there any manual available for splitting packages?
[06:14] <pitti> there isn't
[06:14] <pitti> it's not really different to adding a new binary package, or doing packaging in general
[06:14] <pitti> you need to know what debian/control does, and how dh_install works mostly
[06:14] <pitti> the only extra thing is teh Breaks:/Replaces:
[06:15] <c2tarun> pitti, ok, I'll look into dh_install first.
[06:32] <c2tarun> pitti, does dh_install comes under automake tools?
[06:32] <pitti> c2tarun: yes, well after; but the current package should already have it
[06:32] <pitti> c2tarun: there's (usually) no need to modify debian/rules for this
[06:33] <c2tarun> pitti, you said to add new pacakge to debian/contro, and then update all affected debian/pacakgename.install, I actually didn't get the second part.
[06:35] <pitti> c2tarun: dh_install uses debian/packagename.install to put the installed project files into the various binary packages
[06:38] <c2tarun> pitti, this question might sound silly, but how am I going to find affected packagename.install, I mean do I have to look into each *.install file and see if it is using kalgebramobile?
[06:39] <pitti> c2tarun: well, that's the main point of the exercise -- determining the files you want to ship in the new package, i. e. teh parts you want to split out :)
[06:41] <c2tarun> pitti, well thats kind of tricky, dont you think one have proper knowledge of the source code in order to determine the files.
[06:44] <pitti> c2tarun: not really about the source, but about the installed files
[06:44] <pitti> and yes, it is not a simple task for a large package like kdeedu
[06:46]  * c2tarun i thought its not simple task for any package ;(
[06:46] <c2tarun> pitti, do I have to move mobile folder out of kalgebra folder? I think it contains the source code.
[06:51] <c2tarun> pitti, if you have some time please get the source code of kdeedu and please instruct me, this will help me in learning something important :/
[06:52] <StevenK> c2tarun: I'd suggest you'd be better off asking Riddell what he had in mind to split out. The source code doesn't help in this case at all.
[06:53] <c2tarun> StevenK, ok then I'll ping him on #kubuntu-devel thanks :)
[06:58] <jono> hey folks
[06:58] <jono> I just had a weird experience, I am running current Natty and I rebooted and it looks like X started but nothing loaded
[06:59] <jono> I rebooted a few times and this happened, and I just rebooted now and X started fine
[06:59] <jono> seems like some kind of odd race condition
[06:59] <jono> is this a known bug?
[06:59] <didrocks> good morning
[07:00] <jono> hey didrocks
[07:00] <didrocks> hey jono, how are you?
[07:00] <jono> didrocks, good thanks :-)
[07:06] <Amaranth> jono: Do you get the default X crosshatch background and "X" mouse cursor then?
[07:07] <jono> Amaranth, no, it just looked like the display was turned on (you know how it goes a slightly brighter shade of black before the background is drawn)
[07:07] <Amaranth> Hrm, perhaps plymouth failed to hand off to X
[07:08] <jono> Amaranth, the fact that it just booted fine could suggest something racey is going on
[07:08] <jono> anything I can dig out in a log file to help?
[07:09] <Amaranth> jono: I don't exactly know how that part works so I wouldn't know what to look for
[07:09] <Amaranth> Perhaps RAOF would know
[07:09] <broder> jono: i saw some discussion from bdrung earlier that there was an issue with gdm
[07:09] <broder> possibly connected to some upstart config changes
[07:10] <jono> broder, ahhh
[07:10] <broder> i had to run before i saw any conclusion
[07:12] <Amaranth> Well, it seems his problem was caused by a fix for https://launchpad.net/bugs/436936
[07:13] <broder> Amaranth: rough theory: the gdm upstart job is triggering, which also triggers the plymouth-quit job, but something is keeping gdm from actually starting
[07:13] <broder> haven't really worked out the finer points of that, but feel free to run with it
[07:23] <RAOF> jono: “slightly brighter shade of black”?  You don't get the plymouth splash screen fading seamlessly into gdm (when gdm works ☺)?
[07:24] <jono> RAOF, I see no Ubuntu image when my laptop boots
[07:25] <jono> and then no gdm was loaded
[07:25] <jono> but also no colored background
[07:25] <broder> jono: bug #735805
[07:26] <broder> jono: though i'm not sure that's the same as yours since you said it worked sometimes
[07:27] <jono> yeah it worked the last time I booted, and I need to work tomorrow so I am not rebooting tonight :-)
[07:27] <broder> haha
[07:27] <broder> RAOF: ooc, what component handles that theoretical seamless fade anyway? is it supposed to be g-s-d or something?
[07:28] <RAOF> broder: Nah, that's X.
[07:28] <broder> oh really? fancy
[07:29] <jono> sorry folks, I have to head to bed
[07:29] <RAOF> Plymouth leaves its image in the framebuffer, the X drivers copy said images into a pixmap and use it as the root window.
[07:29] <jono> anything I can provide before I go? log files etc?
[07:30] <jono> RAOF, ^
[07:31] <RAOF>  /var/log/Xorg.0.log is always a good ideoa, as, in this case, might be /var/log/gdm/*
[07:32] <RAOF> Although if upstart isn't even trying to start gdm, those would be useless, and I'm not sure what logs *would* be usef
[07:32] <RAOF> ul.
[07:32] <jono> right
[07:32] <jono> I wasn't sure if I should see some errors somewhere
[07:33] <broder> RAOF: my suspicion is that the gdm upstart job is running, but the script is short-circuiting
[07:34] <broder> that's the only explanation i have for why plymouth would quit without gdm actually starting, since the plymouth-quit job gates on the gdm job
[07:35] <RAOF> And we know plymouth has quit?
[07:35] <RAOF> I'm not sure what a short-circuted upstart script would look like, either :)
[07:35] <jono> ok, I best head to bed
[07:35] <jono> let me know if there is anything else I can help with
[07:35] <jono> thanks RAOF, broder, Amaranth
[07:45] <dholbach> good morning
[08:03] <exobuzz> https://launchpad.net/builders/ 10 hour delay for i386 :/
[08:04] <exobuzz> has everyone decided to use their ppa all at once, or are there less builders or something for some reason ?
[08:13] <tjaalton> is mounting iso's with exec somehow disabled, since even running 'mount -o loop,exec foo.iso bar' doesn't work
[08:14] <tjaalton> well, it's still mounted noexec
[08:14] <Daviey> exobuzz, Now 11 hours :)
[08:15] <exobuzz> yeh.. argh
[08:18] <Daviey> exobuzz, it's known, seems they are being used for other purposes at the moment.
[08:24] <exobuzz> Daviey, thanks for the info.
[08:25] <Riddell> @pilot in
[09:48] <vila> can someone reminds me why I don't see a 'Nominate for release' button for https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075 ?
[09:48] <vila> I want to start the SRU process for bzr but I'm blocked on this step
[09:49] <vila> ISTR someone did this for me (just creating the bugtask, I followed the process myself from there) last time but I don't remember *why* I can't do it myself
[09:53] <nigelb> vila: I see it just fine.
[09:54] <nigelb> vila: I tried logging out and looking too
[09:55] <vila> nigelb: wow, it works now 8-) Thanks
[09:55] <vila> hmm
[09:55] <nigelb> vila: you probably looked for nominate for release but its nominate for series
[09:55] <vila> almost
[09:56] <vila> I've got an oops saying: NominationError: Only bug supervisors or owners can nominate bugs.
[09:56] <Riddell> slomo: where can i find gstreamer0.10-fluendo-mpegdemux to confirm bug 731711 ?
[09:58] <nigelb> vila: arg, that isn't friendly, but you can go ahead with the process and one of us can nominate for you :)
[09:58] <vila> nigelb: ok, will do that then
[10:04] <slomo> Riddell: i don't know, ask your colleagues :) it's part of the fluendo codec pack, the free debian/ubuntu package was removed after lucid/before squeeze
[10:05] <Riddell> slomo: thought so, but comment #1 suggests you are involved, which doesn't make sense, never mind
[10:07] <slomo> Riddell: i did the original package which was in debian/ubuntu, maybe they reused it for the codec pack... oh and that bug was about an unnecessary conflict in gst-plugins-bad
[10:08] <Riddell> yeah, I want to check the gstreamer0.10-fluendo-mpegdemux package to confirm it is unnecessary
[10:10] <slomo> Riddell: the files are named different and the symbol conflict is gone since many gst-plugins-bad releases
[10:11] <cdbs> Final Exams over, marking the end of my 4 month long study leave. This was my last leave, and so full steam ahead!
[10:13] <cdbs> dholbach: pong
[10:14] <dholbach> cdbs, errr... pong? hello! :)
[10:14] <cdbs> dholbach: I am ponging to your email
[10:14] <dholbach> :)
[10:14] <dholbach> ok
[10:51] <soren> Where can I find info on the /CurrentlyBuilding file that we see on the buildd's. I can't seem to spot any mention of it in the sbuild package.
[10:57] <soren> wgrant: I'm sure you know this.
[10:57] <wgrant> soren: We don't use system sbuild.
[10:57] <wgrant> soren: It's hacked into launchpad's sbuild.. let me find a link.
[10:57] <soren> wgrant: W00t.
[10:59] <wgrant> soren: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/canonical/buildd/sbuild#L1181
[11:01] <seb128> jhunt_, hi
[11:01] <jhunt_> seb128: hi
[11:01] <soren> wgrant: Excellent, thanks!
[11:01] <seb128> jhunt_, the gdm patch you worked on seems to break some users
[11:01] <seb128> jhunt_, bug #735805
[11:01] <seb128> pitti, ^ one user confirmed downgrading the upstart job fixes it
[11:01] <pitti> seb128: ah, would you mind assigning to jhunt_ then?
[11:19] <jhunt_> seb128, pitti: hmm, I can only conclude that the bracketing of the start on is the problem, but can't recreate it atm. I'd really appreciate it if someone could either wikify or send me details of how to set up the multiple branches(lp:ubuntu/gdm + lp:~ubuntu-desktop/gdm/ubuntu?) required to rebuild gdm fully.
[11:19] <pitti> jhunt_: you only need the latter branch; lp:ubunt/gdm is not the branch you are looking for <jedi wave>
[11:20] <pitti> jhunt_: but you don't even need to build the branch, I guess you can just change /etc/init/gdm.conf for experiments
[11:20] <pitti> jhunt_: https://wiki.ubuntu.com/DesktopTeam/Bzr has the documentation
[11:20] <jhunt_> pitti: that's what I did for the change on bug 436936. However, the desktop branch only includes the debian/ directory, so how do I build?
[11:20] <seb128> jhunt_, you are not on natty?
[11:21] <pitti> jhunt_: in short, it's "debcheckout gdm; cd gdm; bzr bd -- -b" (for binary paackage)
[11:21] <seb128> jhunt_, why do you need to build from the vcs?
[11:21] <cjwatson> 'bzr bd' knows how to glue the debian/ directory in VCS together with the .orig.tar.gz for everything else
[11:25] <jhunt_> seb128, cjwatson: thx!
[11:28] <Laney> has something changed with libffi on i386? http://launchpadlibrarian.net/66490258/buildlog_ubuntu-natty-i386.ghc6_6.12.3-1ubuntu6_FAILEDTOBUILD.txt.gz
[11:29] <Laney> builds on amd64
[11:29] <seb128> jhunt_, btw why do you need to rebuild gdm to hack the upstart job?
[11:30] <seb128> jhunt_, if you don't have the issue maybe just ask for details on the bug, the users who have it will reply
[11:34] <jhunt_> seb128: I don't for this bug, but wanted to know how to do it anyway for other purposes.
[11:35] <seb128> jhunt_, ok
[11:35] <seb128> jhunt_, bdrung gets the issue if you need details
[11:35] <seb128> jhunt_, he confirmed that reverting your job tweak fixes it
[11:35] <bdrung> jhunt_: let me know if i need more information or when i should test something.
[11:46] <jibel> cjwatson, ev : ubiquity is broken this morning. bug 736060
[11:49] <cjwatson> jibel: drat, thanks
[11:49] <cjwatson> well, I know why that would be, given the massive localechooser merge
[11:49] <cjwatson> I did test it, believe it or not :-/
[12:28] <abhinav-> ttx: hello :-)
[12:30] <ttx> abhinav-: will look into the branch in a few. next on my TODO.
[12:38] <abhinav-> ttx, no problem :-)  I was wanting to ask what to do on the first screen of submittodebian ? it opens the diff in a text editor but no changes shown in debian/changelog
[12:39] <ttx> abhinav-: I confess I usually submit manually. But someone else here should ba able to help you.
[12:42] <abhinav-> ttx: :-) Daviey submitted it for me last time
[12:43] <bdrung> jhunt_: requested information attached to the gdm bug.
[12:44] <Daviey> abhinav-, In the text editor, trim the patch down to stuff you just care about (maintaining the +++ and ---) lines.. other entries, clear out
[12:45] <abhinav-> Daviey, ok and no need to create a new changelog entry (I already created it for submitting to launchpad) ?
[12:48] <Daviey> abhinav-, Yeah, the Debian Maintainer will craft their own changelog entry.  But it's a good idea to have near the same contents in the actual bug report... which IIRC submittodebian helps with
[12:50] <abhinav-> Daviey, Thanks. I will play with it to learn more. :-)
[12:52] <Daviey> abhinav-, good stuff!
[13:05] <abhinav-> pitti, Hi, I am running Maverick and it has Python Distutils 2.22, perhaps this is the reason I am not able to run :(
[13:08] <cjwatson> jhunt_: I have a set -x log from gdm.conf.  would that help?
[13:09] <cjwatson> jhunt_: http://paste.ubuntu.com/581088/ - looks like the previous runlevel is unknown so it decides it's now in single-user mode and gives up
[13:09] <ttx> abhinav-: i'll push it to debian-java SVN directly. No real need for a bug.
[13:09] <abhinav-> ttx: thanks :-)
[13:11] <cjwatson> jhunt_: I expect this happens if the other start conditions for gdm are satisfied before we enter runlevel 2
[13:30] <RoAkSoAx> @pilot in
[13:33] <ttx> abhinav-: done
[13:38] <abhinav-> ttx: Thank you :-)
[13:57] <Riddell> slangasek: koffice compile has broken because libc moved out of /lib, how is that expected to be fixed?
[14:03] <slangasek> Riddell: koffice is expected to use the linker path instead of looking for a hard-coded path to libc. Is there a build failure I can look at in LP for this?
[14:03] <Riddell> slangasek: https://launchpad.net/ubuntu/+source/koffice/1:2.3.3-0ubuntu1/+buildjob/2324333/+files/buildlog_ubuntu-natty-i386.koffice_1%3A2.3.3-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:03] <Riddell> it's looking for iconv which can be a standalone library or part of libc
[14:06] <slangasek> Riddell: right - but it shouldn't need to hardcode a path to libc to do this, it should simply link against '-lc'.  I can take a look in a bit
[14:17] <Riddell> slangasek: if I change the cmake file to just use libc instead of searching for any of the various libraries it works ok, but I'm not sure that's the best long term solution
[14:18] <slangasek> Riddell: well, indeed, the best long-term solution is to not bypass the compiler's linker path when searching for libraries
[14:22] <slangasek> Riddell: looks to me like this may need to be fixed in cmake; ./cmake/modules/FindIconv.cmake itself looks sensible
[14:25] <mvo> jibel: thanks a bunch for your script in 541595
[14:32] <slangasek> Riddell: it makes me unhappy to see what cmake's FIND_LIBRARY() is doing internally.  autoconf got this right 20 years ago, I don't know why cmake had to go and reinvent poorly the search for libraries at buildtime
[14:32] <slangasek> Riddell: can CMAKE_LIBRARY_PATH be set in the environment?  If so, I think that's the best way to handle this
[14:37] <jibel> mvo, you're welcome.
[14:38] <jhunt_> cjwatson: thx. I've updated bug 735805 with a possible fix
[14:38] <Riddell> slangasek: I don't see why it couldn't
[14:39] <slangasek> Riddell: well, I can't tell from the code I'm looking at whether setting that in the environment does any good - I guess looking at the documentation would be better :)
[14:39] <slangasek> actually, this ought to be fixed in cmake because a lot more libraries are going to be moving out of /lib, /usr/lib soon
[14:40] <Riddell> slangasek: what is the way to find the linker path?
[14:40] <jibel> mvo, btw this bug bit me yesterday during an upgrade from maverick to natty following a failure of libpango (bug 703230)
[14:40] <jibel> mvo, so maybe it is reproducible
[14:41] <slangasek> Riddell: for the stuff that's being done in cmake, it seems we want the runtime linker path, so the only reliable way for cmake to get that is by recursing /etc/ld.so.conf* (which it shouldn't do)
[14:41] <Riddell> slangasek: then how does autoconf do it?
[14:42] <slangasek> Riddell: for an env workaround, CMAKE_LIBRARY_PATH=/usr/local/lib/$(DEB_HOST_MULTIARCH):/usr/lib/$(DEB_HOST_MULTIARCH):/lib/$(DEB_HOST_MULTIARCH) would be correct
[14:42] <slangasek> Riddell: it trusts the compiler like it ought to!
[14:42] <psusi> cjwatson: finally read that war story.. I had a very similar experience debugging the ReactOS boot loader several years ago... was using bochs instead of qemu I think though, and getting gdb to connect to it was a lifesaver
[14:42] <slangasek> there's no good reason for cmake to be rooting around in runtime library directories and looking at sonames and all this other stuff
[14:43] <mvo> jibel: thanks, I'm having a look now. I'm going through the bugreport currently trying to gather clues
[14:44] <jibel> mvo, the logs from the failed upgrade are there https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/735441/+attachment/1909981/+files/dist-upgrade.tgz
[14:45] <slangasek> Riddell: for fixing this centrally in cmake, here's a command that would let you grab /gcc's/ search path at runtime and iterate through: for dir in $(gcc -print-search-dirs | cut -f2- -d'=' |sed -e's/:/\n/g'); do readlink -f $dir; done | uniq
[14:45] <slangasek> so cmake could do the equivalent to that
[14:46] <slangasek> or else since cmake is arch-dependent, it could just have the multiarch paths hard-coded
[14:46]  * amitk swears at ubuntu-sso-login
[14:48] <Riddell> slangasek: is multiarch in or about to be in debian too?
[14:48] <pitti> abhinav-: hey! wanted to reply to your over-night ping
[14:48] <slangasek> Riddell: about to be, yes
[14:48] <pitti> abhinav-: yes, you need to run current trunk on natty, maverick doesn't yet work with the pygi stuff
[14:48] <pitti> abhinav-: alternatively, run PYTHONPATH=. ubuntu-bug
[14:48] <Riddell> slangasek: ok so I should discuss with KDE's cmake guru and debian about what to do
[14:49] <pitti> abhinav-: that will use the GUI from maverick, but the ui.py from trunk; that should work, and won't need pygi
[14:49] <pitti> abhinav-: it's not related to python-distutils
[14:51] <slangasek> Riddell: ok - if they can get the multiarch dirs prepended to cmake's built in search path, that would be great - /usr/local/lib/$(DEB_HOST_MULTIARCH):/usr/lib/$(DEB_HOST_MULTIARCH):/lib/$(DEB_HOST_MULTIARCH) should do the job (note, we need to be able to pass this in from the environment because $DEB_HOST_MULTIARCH != $DEB_HOST_GNU_TYPE on i386)
[14:57] <slangasek> Riddell: do you have other, pending KDE uploads right now that don't depend on koffice?  I have more libraries to "break" wrt cmake this week, but I don't want to set you back unnecessarily - I can schedule those uploads around any builds you have queued
[14:58] <Riddell> slangasek: you may be overestimating how well I plan KDE uploads :)
[14:58] <Riddell> nothing planned but I expect uploads will happen
[14:58] <slangasek> Riddell: well, it would be impolite of me to not at least /offer/ to coordinate ;)
[14:59] <slangasek> but if it's undefined what's going to get uploaded when, I think I need to continue with my bootstrapping and we just need to get a cmake fix soonest
[15:00] <Riddell> slangasek: but this doesn't break everything that uses cmake does it?  only packages which directly look for libc or other multiarch libraries
[15:01] <slangasek> Riddell: yes, but bear in mind that by the end of the cycle a *lot* of libraries are going to be multiarch libraries
[15:01] <pitti> dpm: hm, shouldn't I have a new base export at https://translations.launchpad.net/ubuntu/maverick/+language-packs by now? usually they finish in the morning
[15:01] <slangasek> Riddell: I mean, qt4-x11 is in ia32-libs, so it's on the list somewhere :)
[15:01] <Riddell> wibble
[15:03] <dpm> pitti, did you request the export before Tuesday 14:00? Otherwise the export will be scheduled for next week - https://dev.launchpad.net/Translations/LanguagePackSchedule
[15:03] <pitti> dpm: yes, on Monday I think
[15:06] <dpm> pitti, yeah, I can confirm, on Monday I sent the announcement that we'd be delaying testing the langpacks
[15:07] <amitk> anybody know what this ubuntu-sso-login is that keeps crashing but that I can't file a bug against through apport?
[15:15] <dpm> pitti, I'm asking about it on #launchpad ^
[15:15] <pitti> dpm: thanks
[15:26] <seb128> jibel, mvo: if you want to fix the pango bug please just do it and forward the patch to debian, it should be trivial, just try to rmdir in the preinst or ignore errors, not sure why there is a directory there for some users
[15:29] <jibel> seb128, we were talking about bug 541595 which is very common in dpkg and I said I got it and it was triggered by the pango bug.
[15:29] <seb128> jibel: ok
[15:41] <lamont> Daviey: what version string do you want for the bind9 upload?
[15:49] <Daviey> lamont, I think it might need to be 1:9.7.0.dfsg.P1-1really9.7.3 ... which makes me sad.
[15:49] <Daviey> lamont, what do you think?
[15:52] <directhex> ._.
[15:52] <directhex> what on earth is prompting that?
[15:53] <Daviey> directhex, new upstream snapshot for lucid SRU...
[15:54] <Daviey> should really be > 1:9.7.0.dfsg.P1-1 && < 1:9.7.1.dfsg.P2-2
[15:55] <Daviey> Saying that.... If it's SRU'd to Lucid, Maverick and already in Natty - it could just be the same version string as Natty.
[15:55] <Daviey> 1:9.7.3.dfsg-1
[15:55] <Daviey> (I wasn't going to push for an SRU to Maverick, but we should do really)
[15:56] <Daviey> Anyone else have any thoughts on that?
[15:57] <lamont> I'm +1 on maverick as well
[15:57] <stgraber> so you'll need to append the ubuntu version number / release name so you have different version strings for lucid, maverick and natty
[15:58] <lamont> OTOH, thinking something like 1:9.7.3.dfsg-1~10.{04,10}
[15:58] <stgraber> 1:9.7.3.dfsg-1~lucid1 or 1:9.7.3.dfsg-1~10.04 (as lamont just suggested)
[15:58] <Daviey> sounds good to me
[15:58] <lamont> Daviey: and uploaded to {lucid,maverick}-proposed?
[15:59] <Daviey> lamont, Yeah.. that sounds super.  Do you have that covered?
[15:59] <lamont> yeah
[15:59] <Daviey> lamont, Make sure you grab me at UDS to redeem a beer token.
[15:59] <lamont> Daviey: and thanks for doing the lifting around process/etc
[16:00]  * Daviey gets back to shovelling e-paper.
[16:12] <abhinav-> pitti: it also doesn't work. it says no module named packaging_impl , http://pastebin.com/Ssx9Cky8 .
[16:12] <abhinav-> pitti,  I will try to ask someone who is running natty to try my branch or I will download the latest build of natty myself overnight  :)
[16:13] <pitti> abhinav-: ah, sorry
[16:13] <pitti> abhinav-: you need to do "./setup xx" once
[16:13] <pitti> abhinav-: (teh xx doesnt' really matter, just needs to run once)
[16:14] <abhinav-> oh ok :)
[16:14] <pitti> abhinav-: that will install the apt backend
[16:15] <abhinav-> pitti, it asks for python distutils 2.24 while maverick repository has 2.22 :( .
[16:16] <abhinav-> I have downloaded the latest source code revision of distutils. I will try to install that
[16:17] <pitti> abhinav-: cp backends/packaging-apt-dpkg.py apport/packaging_impl.py
[16:17] <pitti> abhinav-: then you can avoid running setup.py
[16:19] <lamont> Daviey: bind9  uploaded to {lucid,maverick}-proposed.  happy paperworking
[16:20] <abhinav-> pitti, running now. Thanks for helping :)
[16:21] <bdrung> jhunt_: it doesn't work :(
[16:23] <jhunt_> bdrung: ack. I'll look in a sec...
[16:26] <pitti> abhinav-: cool
[16:31] <seb128> jhunt_, should I revert your gdm changes so people get back a starting system or do you think you will get a fix today?
[16:32] <jhunt_> seb128: maybe a revert would be sensible. My concern is that I am not able to reproduce the issue which makes testing somewhat tricky :(
[16:33] <seb128> jhunt_, seems to be a race or something, didn't cjwatson's debug infos helped to understand what's going on?
[16:33] <cjwatson> I've applied jhunt's change for the next time I reboot, but I've been busy today
[16:33] <cjwatson> it seemed sensible to me
[16:33] <cjwatson> (the one in the bug report)
[16:34] <seb128> cjwatson, bdrung said he doesn't work as it should it seems
[16:34] <jhunt_> seb128: I based my proposed change on it. I suspect the bug was actually in the original gdm.conf but I'm exposing it.
[16:34] <cjwatson> I still have my debugging code in place - just below 'script':
[16:34] <cjwatson>     exec 2>>/dev/.initramfs/gdm.log
[16:34] <cjwatson>     set -x
[16:34] <jhunt_> seb128: well, we've got gdm working, but gdm starting from recovery mode (which was the whole point of my change) still isn't seemingly working.
[16:35] <seb128> jhunt_, if gdm works in normal start I'm happy, should I just upload your suggested fix to natty?
[16:35] <seb128> jhunt_, so you can debug from there the remaining issue and people get a working gdm?
[16:38] <elmo> jhunt_: FWIW your 'possible fix' gdm.conf (complete with tmp file vulnerability) fixed gdm for me
[16:39] <jhunt_> seb128: I'd prefer you asked bdrung that one :)
[16:39] <tseliot> cjwatson: do you know what condition I should use in an upstart job to make sure that the backlight device is available in sys before I execute the script?
[16:39] <seb128> jhunt_, why?
[16:39] <jhunt_> elmo: yeah - debug, that's not for an actual system clearly :)
[16:40] <seb128> jhunt_, ok, I'm reverting the recent change for now
[16:40] <seb128> that seems like it's not going to sort today and we are screwing users
[16:40] <jhunt_> tseliot: you should be able to use the upstart-udev-bridge-generated event
[16:40] <seb128> we will put if back once it's sorted
[16:43] <tseliot> jhunt_: so would udev have to emit an event when the device is created?
[16:44] <jhunt_> seb128: that sounds like a good plan to me. It does raise the issue of how we test such changes as I tested on 3 releases in various scenarios and did not hit this issue.
[16:44] <seb128> jhunt_, it seems likely to be a race
[16:45] <jhunt_> seb128: agreed.
[16:45] <seb128> jhunt_, but well unstable distro are for that in some way
[16:45] <kees> elmo: tmp file vulnerabilities require an operating system that follows symlinks in world-writable directories. ;)
[16:46] <jdstrand> hehe
[16:46]  * jdstrand would still encourage people to *not* include them in their code though ;)
[16:46] <jhunt_> tseliot: See the manpage for upstart-udev-bridge in natty. But from what I can see, you might be able to "start on backlight-device-added"
[16:47] <tseliot> jhunt_: oh, I'm dealing with Natty. Too bad
[16:48] <jhunt_> tseliot: ?
[16:49] <tseliot> jhunt_: yes, I guess I'm better off with a udev rule to change the backlight permissions on boot in Lucid
[16:50] <elmo> jhunt_: fwiw, it doesn't seem like a race to me, I rebooted 3-4 times trying to figure out what was broken, so if you want to test fixed scripts, I'm fairly confident I can reproduce the brokeness
[16:53] <ogra> cjwatson, oops, thanks for closing the bug
[16:54] <tseliot> cjwatson: never mind
[16:56] <pitti> abhinav-: so with regards to the mail you sent me, is that start problem solved now?
[16:57] <abhinav-> pitti, yes it is running now. but the code I wrote isn't working :-|
[17:07] <bdrung> jhunt_: feel free to ping me to get gdm upstart changes tested
[17:07] <jhunt_> bdrung, elmo: thx!
[17:24] <fta> pitti, hi, i have a problem with apport on lucid. on one of my servers, milter-greylist is crashing randomly, i have apport enabled, but i never get anything in /var/crash, any idea?
[17:26] <pitti> fta: do you have something in /var/log/apport.log about it?
[17:27] <fta> pitti, nope
[17:28] <pitti> fta: /proc/sys/kernel/core_pattern points to |/usr/share/apport/apport?
[17:28] <pitti> fta: can you run that in the foreground, does it crash there as well?
[17:29] <fta> # cat /proc/sys/kernel/core_pattern
[17:29] <fta> |/usr/share/apport/apport %p %s %c
[17:29] <pitti> that's right
[17:29] <fta> i see the crashes in dmesg
[17:29] <pitti> fta: usually it means that the program intercepts SIGSEGV (or whatever it is crashing with) itself
[17:29] <fta> [463906.749929] milter-greylist[12390]: segfault at a0 ip 00c211e0 sp b5f81320 error 4 in libmilter.so.1.0.1[c17000+c000]
[17:30] <pitti> hm, it wouldn't leave an imprint in dmesg then, thuogh
[17:30] <fta> not sure if greylist is doing that
[17:31] <pitti> it at least prints called for pid %s, signal %s very early on (into the log file)
[17:31] <pitti> fta: if you do: sh -c 'kill -SEGV $$'
[17:31] <pitti> fta: do you get a crash report?
[17:31] <pitti> (for dash)
[17:32] <fta> yes, -rw------- 1 root root 17457 2011-03-16 18:31 _bin_dash.0.crash
[17:32] <pitti> ok, so that part works
[17:33] <pitti> fta: no "cannot create lock file" in the log either?
[17:34] <pitti> fta: so grep 12390 /var/log/apport.log returns nothing?
[17:37] <fta> pitti, nope, nada. /var/log/apport.log just contains 3 lines for the dash crash you asked me to try
[17:37] <fta> nada either in the older apport.log files
[17:40] <pitti> fta: can you run the program from a terminal (if it isn't running right now), and send it a killall -SEGV milter-greylist?
[17:40] <fta> pitti, it's a production server, with a lot of traffic :P
[17:41] <fta> pitti, atm, i auto-restart it from cron, but it's far from ideal
[17:41] <pitti> so, I ran out of the obvious ideas; now we need to watch it crash, and see what happens
[17:45] <nh2> is there an archive containing all .debs ever released for Natty? I have a big regression in one of the drivers
[17:46] <kklimonda> nh2: I think you can access all debs on Launchpad
[17:50] <fta> pitti, http://paste.ubuntu.com/581214/
[17:50] <fta> well, not the right one
[17:50] <pitti> fta: hmm
[17:51] <fta> hold on
[17:51] <pitti> ah, you killed the upstart job
[17:51] <pitti> init.d script actually
[17:51] <nh2> kklimonda: hmm. http://changelogs.ubuntu.com/changelogs/pool/main/x/xserver-xorg-input-evdev/xserver-xorg-input-evdev_2.6.0-1ubuntu10/changelog shows a version 2.5.99, but I cannot find that one on https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev or one of the links there
[17:52] <fta> pitti, just "Segmentation fault", no crash file
[17:52] <fta> and no log
[17:53] <pitti> fta: hm, is it possible that the program changes its core dump ulimit?
[17:53] <pitti> nothing obvious in the source
[17:53] <nh2> kklimonda: the 2.5.99 is not even in this changelog: https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+changelog so the changelogs must be different ones
[17:55] <pitti> fta: I see a "signal(SIGSEGV, SIG_IGN);" in the code
[17:55] <pitti> fta: which would be enabled if WORKAROUND_LIBMILTER_RACE_CONDITION is defined
[17:55] <kklimonda> nh2: 2.5.99 come from debian, and was probably never released in ubuntu, you can check full publishing history to get a definite list of releases that were made in Ubuntu
[17:56] <nh2> kklimonda: I checked it 4 days ago and am 100% sure that aptitude show said 2.5.99.something :/
[17:58] <kklimonda> nh2: 2.6.0 has been released in january so unless you weren't updating your system it's unlikely.
[17:59] <nh2> kklimonda: yes, my last update was around newyear, and 4 days ago I aptitude show'd and then updated
[18:05] <mrc3_> hello! every time i try to build gst-plugins-base i get GETTEXT_PACKAGE removed from po/Makefile.in.in: http://pastie.org/1679467
[18:05] <mrc3_> i'm trying to update rsalveti's g-p-base package
[18:06] <fta> pitti, but WORKAROUND_LIBMILTER_RACE_CONDITION is not set, so the signals are not diverted
[18:07] <pitti> fta: so if it just said "Segmentation fault" and not additionally "(core dumped)", then apport wasn't called at all
[18:08] <mrc3_> the missing GETTEXT_PACKAGE wouldn't bother me except for the fact that .mo files are being installed without a name such as /usr/share/locale/ro/LC_MESSAGES/.mo
[18:09] <mrc3_> so, my question is: what and why would remove GETTEXT_PACKAGE when using git-buildpackage?
[18:34] <abhinav-> pitti, apport 1.9.x requires Python 2.7+ ?
[18:35] <pitti> abhinav-: I'm not sure; does it fail with 2.6?
[18:35] <pitti> (I don't test it with 2.6)
[18:35] <abhinav-> no
[18:35] <abhinav-> but subprocess.check_output is available in 2.7 only
[18:35] <pitti> right
[18:35] <abhinav-> so it won't work on my default python
[18:36] <abhinav-> pitti: I changed the symlink to link /usr/bin/python to python3 then /usr/share/apport-gtk wont run with python3
[18:37] <pitti> yes, it's not ported to py3 yet, at least not fully
[18:37] <pitti> abhinav-: so use subprocess.Popen() and communicate()? it's not much more difficult
[18:37] <abhinav-> ok. I will try that also :)
[19:12] <broder> whoa...i didn't know about subprocess.check_output. that's amazingly useful
[19:16] <abhinav-> broder, its short and sweet :-)
[19:16] <broder> abhinav-: i'm sure. i think i've added something effectively the same as that function to a project's utility library at least 5 different times
[19:17] <abhinav-> :-D yes it should have been added to python's batteries a long time ago
[19:55] <blueyed> 736367, too.
[19:55] <blueyed> cjwatson: re the ctags update, and given that you are good in C/debugging, you might want to include a fix for bug 736367, too.
[20:01] <cjwatson> blueyed: will look, thanks, have been waiting 'til I can carve out a bit of Debian time
[20:05] <blueyed> cjwatson: would be awesome if you could add a fix for this. It's probably trivial, and has good test case, but my gdb foo is not so good. Might be a matter of minutes for you. Thanks also again for looking into the snapshot itself.
[20:05] <cjwatson> doesn't sound hard, no
[20:14] <nh2> cnd: hi! It looks like the Xinput 2.1 support broke some touch screens. Could you tell me if that might be the case? (https://bugs.launchpad.net/ubuntu/+bug/573006?comments=all)
[20:14] <cnd> nh2, I'll take a look
[20:14] <nh2> cnd: thanks
[20:15] <cnd> nh2, the bug is old and is from lucid
[20:15] <cnd> I'll take a closer look
[20:15] <cnd> but it makes me wonder if it's xi 2.1 related
[20:15] <nh2> cnd: I just bisected that (last 2 comments)
[20:16] <cnd> nh2, did you bisect the linux kernel?
[20:16] <nh2> cnd: no, the evdev part
[20:16] <cnd> oh I see now
[20:17] <cnd> nh2, which tree did you bisect?
[20:17] <cnd> git.debian.org?
[20:17] <nh2> cnd: I used debians repository, yes
[20:17] <cnd> or something elsewhere?
[20:17] <cnd> ok
[20:18] <nh2> cnd it was broken on Maverick, then fixed on Natty in the beginning of January for some time, and is now broken again
[20:18] <cnd> heh
[20:24] <cnd> nh2, I left a comment with instructions
[20:25] <nh2> cnd: awesome. Shall I do it with the latest Natty .deb?
[20:26] <cnd> nh2, it doesn't matter what version of evdev you have
[20:26] <cnd> you can leave it at a previous version if you need
[20:26] <barry> rickspencer3: hi. allison said you have a question for me?
[20:30] <directhex> where are ppc64 build logs?
[20:44] <RoAkSoAx> @pilot out
[20:46] <nh2> cnd: ok, done
[20:46] <nh2> the replay tool is indeed nice
[20:48] <cnd> yep
[20:58] <bryceh> launchpad down?
[21:06] <ScottK> bryceh: http://www.downforeveryoneorjustme.com/launchpad.net
[21:30] <sladen> Permission denied (publickey).
[21:30] <sladen> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[21:30] <sladen> is that just me, or are other people seeing that suddenly?
[21:32] <mrc3_> bryceh == bryce harrington of inkscape fame?
[21:32] <lifeless> rumour has it
[21:32] <mrc3_> and tedg == ted gould of inkscape fame as well?
[21:33] <mrc3_> boy, everyone is in here!
[21:33] <sladen> mrc3_: welcome to Ubuntu!  ;-)
[21:33] <tedg> mrc3_, Yes :)
[21:33] <tumbleweed> would a core dev please accept the nominations on bug 642913 (bonus points for sponsoring the uploads)
[21:33] <mrc3_> i used to cross-compile inkscape for windows three times a day some time ago
[21:33] <lifeless> sladen: no, and its working for me, if you are talking about lp
[21:41] <sladen> lifeless: ta.  dead ssh-agent
[21:41] <sabdfl> mrc3_: you have both fame, and infamy, in the room
[21:42] <mrc3_> sabdfl, of mine? gee, i've only been here for a day!
[21:42] <sabdfl> i'd like to say "your reputation precedes you", but...
[21:44] <sladen> tumbleweed: do you have an easy unittest/10 line test case that is broken before and works after?  Since I don't know the back-history this would make me happier to valid it
[21:45] <tumbleweed> sladen: comment 5
[21:46] <bryceh> mrc3_, yep heya
[21:46] <sladen> tumbleweed: one line test case is even better ;-)
[21:47] <mrc3_> hope you guys can show me around, because this ubuntu world is rather big
[21:47] <tumbleweed> sladen: my pleasure :)
[21:48] <mrc3_> i'm currently fighting the packaging. i'm losing.
[21:48] <sladen> mrc3_: and a mere fraction of what it might be in a few more years.  After UDS in Paris I gave up having any hope of knowing who everyone was
[21:55] <sladen> mrc3_: what paricular patr of packaging
[21:56] <mrc3_> sladen, git-buildpackage removes a GETTEXT_PACKAGE variable from po/Makefile.in.in (for gst-plugins-base), and thus it installs some files as ".mo" instead of "gst-plugins-base.mo"
[22:05] <Riddell> @pilot out
[22:22] <hallyn> cjwatson: should i be able to just 'fakeroot debian/rules binary' in a grub2 package tree, or is grub2 special?  (I was able to fakeroot debian/rules build, but binary complains)
[23:02] <TheMuso> Is it possible to add more modified files to a patch when refreshing with quilt? If so how?
[23:03] <TheMuso> nvm answered my question.
[23:09] <sladen> mrc3_: don't sure I have a good answer for you.  is it definitely git-buildpackage rather than a particularly fragile makefile?
[23:10] <mrc3_> sladen, this must have worked for rsalveti, since i'm trying to update his package
[23:10] <mrc3_> this is basically gst-plugins-base + ti's patches for hardware-accelerated video encoding/decoding
[23:13]  * sladen tries building the one of the archive first
[23:15] <mrc3_> it must have been something i did while refreshing the patches, i guess. i'll do it all over again
[23:25] <sladen> mrc3_: I don't know yet, it's still building
[23:31] <kees> Keybuk: around? I'm curious about why ureadahead leaves /var/lib/ureadahead/debugfs mounted on most of my systems
[23:50] <mrc3_> sladen, it's behaving better now: i reimported the upstream dsc, readded the patches, used --git-pristine-tar, and now `git diff po/` is showing nothing!
[23:57] <dylan-m> Hey, any Unity folks about? I'm trying to figure out why something is how it is :)
[23:58] <dylan-m> Best just say it: I'm wondering why PanelMenuView::OnWindowRestored uses bamf_matcher_get_active_window instead of using the xid that is passed as an argument