[00:01] Daviey: go ahead, I'm afk for the evening as of about 30 sec ago [00:01] lamont, Okay, your PPA backport == the sid package? === dendro-afk is now known as dendrobates [00:07] * Daviey diffs === syn-ack is now known as Guest9209 === syn-ack_ is now known as syn-ack === Auv5 is now known as Guest27214 === dendrobates is now known as dendro-afk === Auv5[Alt] is now known as Auv5 [01:20] You have to ask the questions before they are AFK. [01:20] ;-) === dendro-afk is now known as dendrobates === asac_ is now known as asac [02:14] Daviey: ISTR that there might be a dpkg change that required a tweak to the package for lucid [02:14] Daviey: so I'd say grab the ppa. not just because that's what I tested [02:14] worst case, I should be able to do it tomorrow [03:05] why I am getting this error curl: (6) Couldn't resolve host 'people.canonical.com' on running rmadison kdeedu in natty chroot [03:12] Probably because you use dhcp and you got a new IP address since you created the chroot. [04:08] 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:08] Launchpad bug 662194 in Nautilus "Nautilus: 'Remember this application for ..." option should be made inactive by default" [Medium,New] https://launchpad.net/bugs/662194 [04:38] jdstrand: yes, go ahead :) [04:38] jdstrand: I don't have powers to do it, but probably dholbach has :) [06:04] Good morning [06:08] pitti, good morning :) [06:09] pitti, hey can you please help me with splitting packages? [06:09] what do you want to do? [06:10] pitti, I was working on bug 683439 [06:10] Launchpad bug 683439 in kdeedu (Ubuntu) "split kalgebra mobile" [Undecided,In progress] https://launchpad.net/bugs/683439 [06:10] pitti, its my first time and I dont know how to split, I did some steps but not sure I am right. [06:12] 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] 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: (<< your_new_version) [06:13] pitti, is there any manual available for splitting packages? [06:14] there isn't [06:14] it's not really different to adding a new binary package, or doing packaging in general [06:14] you need to know what debian/control does, and how dh_install works mostly [06:14] the only extra thing is teh Breaks:/Replaces: [06:15] pitti, ok, I'll look into dh_install first. [06:32] pitti, does dh_install comes under automake tools? [06:32] c2tarun: yes, well after; but the current package should already have it [06:32] c2tarun: there's (usually) no need to modify debian/rules for this [06:33] 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] c2tarun: dh_install uses debian/packagename.install to put the installed project files into the various binary packages [06:38] 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] 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] 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] c2tarun: not really about the source, but about the installed files [06:44] 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] pitti, do I have to move mobile folder out of kalgebra folder? I think it contains the source code. [06:51] 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] 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] StevenK, ok then I'll ping him on #kubuntu-devel thanks :) [06:58] hey folks [06:58] 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] I rebooted a few times and this happened, and I just rebooted now and X started fine [06:59] seems like some kind of odd race condition [06:59] is this a known bug? [06:59] good morning [07:00] hey didrocks [07:00] hey jono, how are you? [07:00] didrocks, good thanks :-) [07:06] jono: Do you get the default X crosshatch background and "X" mouse cursor then? [07:07] 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] Hrm, perhaps plymouth failed to hand off to X [07:08] Amaranth, the fact that it just booted fine could suggest something racey is going on [07:08] anything I can dig out in a log file to help? [07:09] jono: I don't exactly know how that part works so I wouldn't know what to look for [07:09] Perhaps RAOF would know [07:09] jono: i saw some discussion from bdrung earlier that there was an issue with gdm [07:09] possibly connected to some upstart config changes [07:10] broder, ahhh [07:10] i had to run before i saw any conclusion [07:12] Well, it seems his problem was caused by a fix for https://launchpad.net/bugs/436936 [07:12] Ubuntu bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] [07:13] 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] haven't really worked out the finer points of that, but feel free to run with it [07:23] jono: “slightly brighter shade of black”? You don't get the plymouth splash screen fading seamlessly into gdm (when gdm works ☺)? [07:24] RAOF, I see no Ubuntu image when my laptop boots [07:25] and then no gdm was loaded [07:25] but also no colored background [07:25] jono: bug #735805 [07:25] Launchpad bug 735805 in gdm (Ubuntu) "GDM fails to start" [Undecided,Confirmed] https://launchpad.net/bugs/735805 [07:26] jono: though i'm not sure that's the same as yours since you said it worked sometimes [07:27] yeah it worked the last time I booted, and I need to work tomorrow so I am not rebooting tonight :-) [07:27] haha [07:27] RAOF: ooc, what component handles that theoretical seamless fade anyway? is it supposed to be g-s-d or something? [07:28] broder: Nah, that's X. [07:28] oh really? fancy [07:29] sorry folks, I have to head to bed [07:29] 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] anything I can provide before I go? log files etc? [07:30] RAOF, ^ [07:31] /var/log/Xorg.0.log is always a good ideoa, as, in this case, might be /var/log/gdm/* [07:32] 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] ul. [07:32] right [07:32] I wasn't sure if I should see some errors somewhere [07:33] RAOF: my suspicion is that the gdm upstart job is running, but the script is short-circuiting [07:34] 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] And we know plymouth has quit? [07:35] I'm not sure what a short-circuted upstart script would look like, either :) [07:35] ok, I best head to bed [07:35] let me know if there is anything else I can help with [07:35] thanks RAOF, broder, Amaranth [07:45] good morning [08:03] https://launchpad.net/builders/ 10 hour delay for i386 :/ [08:04] has everyone decided to use their ppa all at once, or are there less builders or something for some reason ? [08:13] is mounting iso's with exec somehow disabled, since even running 'mount -o loop,exec foo.iso bar' doesn't work [08:14] well, it's still mounted noexec [08:14] exobuzz, Now 11 hours :) [08:15] yeh.. argh [08:18] exobuzz, it's known, seems they are being used for other purposes at the moment. [08:24] Daviey, thanks for the info. [08:25] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: Riddell === jjohansen is now known as jj-afk === manish_ is now known as manish [09:48] 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] Ubuntu bug 707075 in Bazaar 2.4 "[sru] lp-propose fails with a 404 error" [High,Fix released] [09:48] I want to start the SRU process for bzr but I'm blocked on this step [09:49] 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] vila: I see it just fine. [09:54] vila: I tried logging out and looking too [09:55] nigelb: wow, it works now 8-) Thanks [09:55] hmm [09:55] vila: you probably looked for nominate for release but its nominate for series [09:55] almost [09:56] I've got an oops saying: NominationError: Only bug supervisors or owners can nominate bugs. [09:56] slomo: where can i find gstreamer0.10-fluendo-mpegdemux to confirm bug 731711 ? [09:56] Launchpad bug 731711 in gst-plugins-bad0.10 (Ubuntu) "mkv files with dvdsub broken after installing Fluendo Complete Playback Pack" [Undecided,Fix released] https://launchpad.net/bugs/731711 [09:58] vila: arg, that isn't friendly, but you can go ahead with the process and one of us can nominate for you :) [09:58] nigelb: ok, will do that then [10:04] 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] slomo: thought so, but comment #1 suggests you are involved, which doesn't make sense, never mind [10:07] 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] yeah, I want to check the gstreamer0.10-fluendo-mpegdemux package to confirm it is unnecessary [10:10] Riddell: the files are named different and the symbol conflict is gone since many gst-plugins-bad releases [10:11] 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] dholbach: pong [10:14] cdbs, errr... pong? hello! :) [10:14] dholbach: I am ponging to your email [10:14] :) [10:14] ok [10:51] 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] wgrant: I'm sure you know this. [10:57] soren: We don't use system sbuild. [10:57] soren: It's hacked into launchpad's sbuild.. let me find a link. [10:57] wgrant: W00t. [10:59] soren: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/canonical/buildd/sbuild#L1181 [11:01] jhunt_, hi [11:01] seb128: hi [11:01] wgrant: Excellent, thanks! [11:01] jhunt_, the gdm patch you worked on seems to break some users [11:01] jhunt_, bug #735805 [11:01] Launchpad bug 735805 in gdm (Ubuntu) "GDM fails to start" [Undecided,Incomplete] https://launchpad.net/bugs/735805 [11:01] pitti, ^ one user confirmed downgrading the upstart job fixes it [11:01] seb128: ah, would you mind assigning to jhunt_ then? [11:19] 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] jhunt_: you only need the latter branch; lp:ubunt/gdm is not the branch you are looking for [11:20] 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] jhunt_: https://wiki.ubuntu.com/DesktopTeam/Bzr has the documentation [11:20] 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] Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936 [11:20] jhunt_, you are not on natty? [11:21] jhunt_: in short, it's "debcheckout gdm; cd gdm; bzr bd -- -b" (for binary paackage) [11:21] jhunt_, why do you need to build from the vcs? [11:21] 'bzr bd' knows how to glue the debian/ directory in VCS together with the .orig.tar.gz for everything else === m4n1sh_ is now known as m4n1sh [11:25] seb128, cjwatson: thx! [11:28] 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] builds on amd64 [11:29] jhunt_, btw why do you need to rebuild gdm to hack the upstart job? [11:30] 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] seb128: I don't for this bug, but wanted to know how to do it anyway for other purposes. [11:35] jhunt_, ok [11:35] jhunt_, bdrung gets the issue if you need details [11:35] jhunt_, he confirmed that reverting your job tweak fixes it [11:35] jhunt_: let me know if i need more information or when i should test something. [11:46] cjwatson, ev : ubiquity is broken this morning. bug 736060 [11:46] Launchpad bug 736060 in ubiquity (Ubuntu) "ubiquity crashed with DebconfError in command(): (10, "debian-installer/fallbacklocale doesn't exist")" [Undecided,New] https://launchpad.net/bugs/736060 [11:49] jibel: drat, thanks [11:49] well, I know why that would be, given the massive localechooser merge [11:49] I did test it, believe it or not :-/ === MacSlow is now known as MacSlow|lunch [12:28] ttx: hello :-) === Hobbsee` is now known as Hobbsee [12:30] abhinav-: will look into the branch in a few. next on my TODO. [12:38] 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] abhinav-: I confess I usually submit manually. But someone else here should ba able to help you. === njpatel is now known as njpatel_ [12:42] ttx: :-) Daviey submitted it for me last time [12:43] jhunt_: requested information attached to the gdm bug. [12:44] 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] Daviey, ok and no need to create a new changelog entry (I already created it for submitting to launchpad) ? [12:48] 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] Daviey, Thanks. I will play with it to learn more. :-) [12:52] abhinav-, good stuff! [13:05] 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] jhunt_: I have a set -x log from gdm.conf. would that help? [13:09] 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] abhinav-: i'll push it to debian-java SVN directly. No real need for a bug. [13:09] ttx: thanks :-) [13:11] jhunt_: I expect this happens if the other start conditions for gdm are satisfied before we enter runlevel 2 [13:30] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: RoAkSoAx, Riddell === mbarnett` is now known as mbarnett [13:33] abhinav-: done [13:38] ttx: Thank you :-) === dendrobates is now known as dendro-afk === MacSlow|lunch is now known as MacSlow === ogra_ is now known as ogra [13:57] slangasek: koffice compile has broken because libc moved out of /lib, how is that expected to be fixed? [14:03] 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] 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] it's looking for iconv which can be a standalone library or part of libc === tm_ is now known as tm [14:06] 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 === yofel_ is now known as yofel [14:17] 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 === dendro-afk is now known as dendrobates [14:18] Riddell: well, indeed, the best long-term solution is to not bypass the compiler's linker path when searching for libraries [14:22] Riddell: looks to me like this may need to be fixed in cmake; ./cmake/modules/FindIconv.cmake itself looks sensible [14:25] jibel: thanks a bunch for your script in 541595 [14:32] 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] Riddell: can CMAKE_LIBRARY_PATH be set in the environment? If so, I think that's the best way to handle this [14:37] mvo, you're welcome. [14:38] cjwatson: thx. I've updated bug 735805 with a possible fix [14:38] Launchpad bug 735805 in gdm (Ubuntu) "GDM fails to start" [High,Confirmed] https://launchpad.net/bugs/735805 [14:38] slangasek: I don't see why it couldn't [14:39] 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] 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] slangasek: what is the way to find the linker path? [14:40] mvo, btw this bug bit me yesterday during an upgrade from maverick to natty following a failure of libpango (bug 703230) [14:40] Launchpad bug 703230 in pango1.0 (Ubuntu Natty) ""rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory" when updating to 1.28.3-4" [High,Triaged] https://launchpad.net/bugs/703230 [14:40] mvo, so maybe it is reproducible [14:41] 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] slangasek: then how does autoconf do it? [14:42] 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] Riddell: it trusts the compiler like it ought to! [14:42] 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] 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] jibel: thanks, I'm having a look now. I'm going through the bugreport currently trying to gather clues [14:44] 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:44] Ubuntu bug 735441 in pango1.0 (Ubuntu) "package libpango1.0-0 1.28.3-4ubuntu1 failed to install/upgrade: pre-installation script returned error exit status 1 - rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory (dup-of: 703230)" [Undecided,New] [14:44] Ubuntu bug 703230 in pango1.0 (Ubuntu Natty) ""rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory" when updating to 1.28.3-4" [High,Triaged] [14:45] 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] so cmake could do the equivalent to that [14:46] 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] slangasek: is multiarch in or about to be in debian too? [14:48] abhinav-: hey! wanted to reply to your over-night ping [14:48] Riddell: about to be, yes [14:48] abhinav-: yes, you need to run current trunk on natty, maverick doesn't yet work with the pygi stuff [14:48] abhinav-: alternatively, run PYTHONPATH=. ubuntu-bug [14:48] slangasek: ok so I should discuss with KDE's cmake guru and debian about what to do [14:49] abhinav-: that will use the GUI from maverick, but the ui.py from trunk; that should work, and won't need pygi [14:49] abhinav-: it's not related to python-distutils [14:51] 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] 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] slangasek: you may be overestimating how well I plan KDE uploads :) [14:58] nothing planned but I expect uploads will happen [14:58] Riddell: well, it would be impolite of me to not at least /offer/ to coordinate ;) [14:59] 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] 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] 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] 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] Riddell: I mean, qt4-x11 is in ia32-libs, so it's on the list somewhere :) [15:01] wibble [15:03] 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] dpm: yes, on Monday I think [15:06] pitti, yeah, I can confirm, on Monday I sent the announcement that we'd be delaying testing the langpacks [15:07] anybody know what this ubuntu-sso-login is that keeps crashing but that I can't file a bug against through apport? === iulian_ is now known as iulian [15:15] pitti, I'm asking about it on #launchpad ^ [15:15] dpm: thanks [15:26] 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] 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] Launchpad bug 541595 in dpkg (Ubuntu) "[Master] package failed to install/upgrade: package is already installed and configured" [Medium,New] https://launchpad.net/bugs/541595 [15:29] jibel: ok [15:41] Daviey: what version string do you want for the bind9 upload? [15:49] lamont, I think it might need to be 1:9.7.0.dfsg.P1-1really9.7.3 ... which makes me sad. [15:49] lamont, what do you think? [15:52] ._. [15:52] what on earth is prompting that? [15:53] directhex, new upstream snapshot for lucid SRU... [15:54] should really be > 1:9.7.0.dfsg.P1-1 && < 1:9.7.1.dfsg.P2-2 [15:55] 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] 1:9.7.3.dfsg-1 [15:55] (I wasn't going to push for an SRU to Maverick, but we should do really) [15:56] Anyone else have any thoughts on that? [15:57] I'm +1 on maverick as well [15:57] 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] OTOH, thinking something like 1:9.7.3.dfsg-1~10.{04,10} [15:58] 1:9.7.3.dfsg-1~lucid1 or 1:9.7.3.dfsg-1~10.04 (as lamont just suggested) [15:58] sounds good to me [15:58] Daviey: and uploaded to {lucid,maverick}-proposed? [15:59] lamont, Yeah.. that sounds super. Do you have that covered? [15:59] yeah === jj-afk is now known as jjohansen [15:59] lamont, Make sure you grab me at UDS to redeem a beer token. [15:59] Daviey: and thanks for doing the lifting around process/etc === evilvish is now known as vish [16:00] * Daviey gets back to shovelling e-paper. === herton is now known as herton_lunch === deryck is now known as deryck[lunch] [16:12] pitti: it also doesn't work. it says no module named packaging_impl , http://pastebin.com/Ssx9Cky8 . [16:12] 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] abhinav-: ah, sorry [16:13] abhinav-: you need to do "./setup xx" once [16:13] abhinav-: (teh xx doesnt' really matter, just needs to run once) [16:14] oh ok :) [16:14] abhinav-: that will install the apt backend [16:15] pitti, it asks for python distutils 2.24 while maverick repository has 2.22 :( . [16:16] I have downloaded the latest source code revision of distutils. I will try to install that [16:17] abhinav-: cp backends/packaging-apt-dpkg.py apport/packaging_impl.py [16:17] abhinav-: then you can avoid running setup.py [16:19] Daviey: bind9 uploaded to {lucid,maverick}-proposed. happy paperworking === cmagina is now known as cmagina-lunch [16:20] pitti, running now. Thanks for helping :) [16:21] jhunt_: it doesn't work :( [16:23] bdrung: ack. I'll look in a sec... [16:26] abhinav-: cool [16:31] 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] 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] jhunt_, seems to be a race or something, didn't cjwatson's debug infos helped to understand what's going on? [16:33] I've applied jhunt's change for the next time I reboot, but I've been busy today [16:33] it seemed sensible to me [16:33] (the one in the bug report) [16:34] cjwatson, bdrung said he doesn't work as it should it seems [16:34] 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] I still have my debugging code in place - just below 'script': [16:34] exec 2>>/dev/.initramfs/gdm.log [16:34] set -x [16:34] 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] jhunt_, if gdm works in normal start I'm happy, should I just upload your suggested fix to natty? [16:35] jhunt_, so you can debug from there the remaining issue and people get a working gdm? [16:38] jhunt_: FWIW your 'possible fix' gdm.conf (complete with tmp file vulnerability) fixed gdm for me [16:39] seb128: I'd prefer you asked bdrung that one :) [16:39] 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] jhunt_, why? [16:39] elmo: yeah - debug, that's not for an actual system clearly :) [16:40] jhunt_, ok, I'm reverting the recent change for now [16:40] that seems like it's not going to sort today and we are screwing users [16:40] tseliot: you should be able to use the upstart-udev-bridge-generated event [16:40] we will put if back once it's sorted [16:43] jhunt_: so would udev have to emit an event when the device is created? === sforshee is now known as sforshee-lunch [16:44] 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] jhunt_, it seems likely to be a race [16:45] seb128: agreed. [16:45] jhunt_, but well unstable distro are for that in some way [16:45] elmo: tmp file vulnerabilities require an operating system that follows symlinks in world-writable directories. ;) [16:46] hehe [16:46] * jdstrand would still encourage people to *not* include them in their code though ;) [16:46] 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] jhunt_: oh, I'm dealing with Natty. Too bad [16:48] tseliot: ? [16:49] jhunt_: yes, I guess I'm better off with a udev rule to change the backlight permissions on boot in Lucid [16:50] 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] cjwatson, oops, thanks for closing the bug [16:54] cjwatson: never mind === bjf is now known as bjf[afk] [16:56] abhinav-: so with regards to the mail you sent me, is that start problem solved now? === deryck[lunch] is now known as deryck [16:57] pitti, yes it is running now. but the code I wrote isn't working :-| === herton_lunch is now known as herton === beuno is now known as beuno-lunch [17:07] jhunt_: feel free to ping me to get gdm upstart changes tested [17:07] bdrung, elmo: thx! [17:24] 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? === cmagina-lunch is now known as cmagina-afk === cmagina-afk is now known as cmagina [17:26] fta: do you have something in /var/log/apport.log about it? [17:27] pitti, nope [17:28] fta: /proc/sys/kernel/core_pattern points to |/usr/share/apport/apport? [17:28] fta: can you run that in the foreground, does it crash there as well? [17:29] # cat /proc/sys/kernel/core_pattern [17:29] |/usr/share/apport/apport %p %s %c [17:29] that's right [17:29] i see the crashes in dmesg [17:29] fta: usually it means that the program intercepts SIGSEGV (or whatever it is crashing with) itself [17:29] [463906.749929] milter-greylist[12390]: segfault at a0 ip 00c211e0 sp b5f81320 error 4 in libmilter.so.1.0.1[c17000+c000] [17:30] hm, it wouldn't leave an imprint in dmesg then, thuogh [17:30] not sure if greylist is doing that [17:31] it at least prints called for pid %s, signal %s very early on (into the log file) [17:31] fta: if you do: sh -c 'kill -SEGV $$' [17:31] fta: do you get a crash report? [17:31] (for dash) [17:32] yes, -rw------- 1 root root 17457 2011-03-16 18:31 _bin_dash.0.crash [17:32] ok, so that part works [17:33] fta: no "cannot create lock file" in the log either? [17:34] fta: so grep 12390 /var/log/apport.log returns nothing? [17:37] pitti, nope, nada. /var/log/apport.log just contains 3 lines for the dash crash you asked me to try [17:37] nada either in the older apport.log files [17:40] 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] pitti, it's a production server, with a lot of traffic :P [17:41] pitti, atm, i auto-restart it from cron, but it's far from ideal [17:41] so, I ran out of the obvious ideas; now we need to watch it crash, and see what happens [17:45] is there an archive containing all .debs ever released for Natty? I have a big regression in one of the drivers [17:46] nh2: I think you can access all debs on Launchpad [17:50] pitti, http://paste.ubuntu.com/581214/ [17:50] well, not the right one [17:50] fta: hmm [17:51] hold on [17:51] ah, you killed the upstart job [17:51] init.d script actually [17:51] 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] pitti, just "Segmentation fault", no crash file [17:52] and no log [17:53] fta: hm, is it possible that the program changes its core dump ulimit? [17:53] nothing obvious in the source [17:53] 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] fta: I see a "signal(SIGSEGV, SIG_IGN);" in the code [17:55] fta: which would be enabled if WORKAROUND_LIBMILTER_RACE_CONDITION is defined [17:55] 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] kklimonda: I checked it 4 days ago and am 100% sure that aptitude show said 2.5.99.something :/ [17:58] nh2: 2.6.0 has been released in january so unless you weren't updating your system it's unlikely. [17:59] kklimonda: yes, my last update was around newyear, and 4 days ago I aptitude show'd and then updated === beuno-lunch is now known as beuno [18:05] 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] i'm trying to update rsalveti's g-p-base package [18:06] pitti, but WORKAROUND_LIBMILTER_RACE_CONDITION is not set, so the signals are not diverted [18:07] fta: so if it just said "Segmentation fault" and not additionally "(core dumped)", then apport wasn't called at all [18:08] 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] so, my question is: what and why would remove GETTEXT_PACKAGE when using git-buildpackage? === bjf[afk] is now known as bjf === sforshee-lunch is now known as sforshee [18:34] pitti, apport 1.9.x requires Python 2.7+ ? [18:35] abhinav-: I'm not sure; does it fail with 2.6? [18:35] (I don't test it with 2.6) [18:35] no [18:35] but subprocess.check_output is available in 2.7 only [18:35] right [18:35] so it won't work on my default python [18:36] pitti: I changed the symlink to link /usr/bin/python to python3 then /usr/share/apport-gtk wont run with python3 [18:37] yes, it's not ported to py3 yet, at least not fully [18:37] abhinav-: so use subprocess.Popen() and communicate()? it's not much more difficult [18:37] ok. I will try that also :) [19:12] whoa...i didn't know about subprocess.check_output. that's amazingly useful [19:16] broder, its short and sweet :-) [19:16] 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] :-D yes it should have been added to python's batteries a long time ago [19:55]