[00:00] slangasek: you normally see them on your desktop also if so [00:00] ah - yes, but it wasn't clear to me that this uses fuse [00:00] those use gio/gvfs [00:01] but you can grab the fuse path out of the GFile object as well and have it use fuse instead [00:01] since they weren't working properly using the native gio/gvfs i wrote a patch to pull out the fuse path [00:02] not too much trouble if you know what you are doing but took me a while since i had never done anything with gio/gvfs before, heh [00:08] * calc wishes debian would update to current bzr on bzr.d.o [00:09] is bzr.d.o even running a smartserver? [00:09] last I checked, I don't think it was [00:09] it is over ssh [00:10] it constantly complains to me that it needs to be upgraded but that has to be done on the server side :\ [00:11] and debian doesn't have current bzr packaged in unstable last i checked [00:11] it does now [00:11] james_w: ah ok [00:11] but alioth runs stable [00:11] james_w: oh [00:11] it will be upgraded to lenny at some point presumably [00:12] so bzr on bzr.d.o is currently 0.11? [00:16] 1.5 [00:16] stable = lenny no? :-) [00:17] Correct Nafallo [00:17] james_w: alioth is probably still running oldstable [00:17] yes, it is [00:19] so it didn't use "stable" in sources.list then ;-) [00:20] * Nafallo have heard horror stories about that one :-P [00:23] slangasek: ah so it is running 1.5 so repos could be upgraded i guess? [00:23] they could be upgraded to the 1.5 level, at least :) [00:30] too bad the error messages don't tell you the minimum bzr revision needed to make the messages go away [00:53] hm. can anyone determine why a package was rejected from NEW, if no explanation seems to have been sent? in theory it was done on tuesday, which means Riddell was on archive duty [00:53] directhex: there was a mono package that had two versions, I think I rejected the older one and accepted the newer one [00:57] Riddell, there were two debugger plugins for monodevelop - one for mdb (mono debugger, for mono apps) and one for gdb (um... gdb is gdb) [00:58] Riddell, the mdb plugin was accepted, the gdb plugin was rejected [01:00] I updated the roadmap-wiki with a link to the alpha 6 site. Hope it will trigger a few downloads. [01:04] directhex: ok I think I messed up due to soyuz's annoying name trunkating bug [01:04] directhex: I've accepted it now [01:05] Riddell, oh, you can do that without a re-upload? thanks! [01:05] :( [01:05] I hope I can, let me know if it doesn't appear [01:05] alpha-6 still has the hardlock-on-login bug [01:05] Riddell, mildly amusing circumstances, but thanks ;) [01:05] directhex: One can acept from rejected. [01:05] accept even. [01:05] bryce_: Are there any known bugs with GMA950 hardware hardlocking X when compiz tries to start? [01:06] I am reproducing this with Jaunty AMD64, on login it simply hangs where I'd expect compiz to be started [01:06] jdong, don't know offhand, try looking in launchpad [01:07] ScottK, handy! [01:07] bryce_: heh I tried looking through and couldn't tell if I had a dupe of an existing Jaunty intel problem or a new one... [01:09] hmm I think bug 259385 sounds right [01:09] Launchpad bug 259385 in compiz "[i845] Intrepid Compiz hangs on login for i830MG, i845, (and i945GM?) video cards" [Medium,Fix released] https://launchpad.net/bugs/259385 [01:09] wrong release though :-/ [01:10] jdong, if you're asking is it worthwhile to file a bug report about the issue, almost certainly yes [01:10] bryce_: alright, I'll do so then [01:10] * ScottK tosses fta a reminder about mozilla-devscripts and python2.4.... [01:11] jdong, see the troubleshooting page off of http://wiki.ubuntu.com/X/ as well [01:11] the reporting page is good to review too, else your bug may just get lost in the noise [01:12] bryce_: will do; it seems upstream; I've been able to reproduce this on Fedora 10 too... [01:13] jdong, if you also file it upstream, that would help a lot. I'm way behind on -intel and probably won't catch up on newly filed stuff any time soon. [01:16] ok [02:06] If apt-get -f install (after installing a local .deb via dpkg) wants to pull in more packages than apt-get install all the depends (python2.4 and python2.4-minimal), any suggestions on where to look for trouble? [02:40] ScottK: they aren't recommends? [02:47] JanC: Nope. [02:48] After I let it install once I tried aptitude why python2.4 and it didn't know why. [02:49] I guess sometimes "-f" tries to be too clever then ;) [02:52] I think I'm going to guess environmental leakage from the base Intrepid system into the chroot. [03:07] ScottK: heh, so even trying to build python-4suite against python2.6 fails miserably here, consuming RAM and never doing anything - but that's not the problem reported upstream? [03:12] slangasek: I don't recall the exact problem. The apt-get -f install problem I was whining about earlier is a different package. [03:13] * ScottK has also been up for 18 hours after 3 hours of sleep, so don't expect great coherency. === cody-somerville_ is now known as cody-somerville [04:01] ever been up for 24 hours or more? [04:07] Certainly. [04:07] last time I did that was probably before/after a UDS, I think [04:08] * ScottK too. [04:08] if i just want fuse paths passed to my application (OOo) should i change the .desktop file to %F instead of %U ? [04:08] * ScottK has done 96 hours on 3 hours of sleep too, but doesn't recommend it. [04:08] for the exec line [04:08] Mavericks: at around 36hr i am not good for anything [04:09] Mavericks: my wife was awake for around 500hr [04:09] Mavericks: hint... being awake 500hr is NOT good [04:10] ScottK: excellent. although you can definitely beat those 3 hrs to go 99 - real fun ;) [04:11] I was also in the military and we were expending ordnance (for training) at the time, so it was a mix of extreme fatigue and high explosives. [04:11] calc: *Time for high school questions* fill in the blank - 500 hr is putting _____ at jeopardy. [04:11] Mavericks: when even high level insomnia drugs don't work you can't do much about it :-\ [04:11] ScottK: oof [04:12] Mavericks: they _attempted_ to a sleep study but she failed... due to lack of sleep [04:12] calc: Nice - haha - Stay away from ______. Ta daaaa. [04:12] calc: for a minute I thought you must had made a typo & meant 50 hours, but 500? ouch [04:12] ajmitch: yea roughly 3 weeks without sleep [04:13] I give. She wins. [04:13] ajmitch: even with the drugs they put her on she could only sleep maybe 1hr before popping back up [04:13] i'm not sure what actually ended up fixing the issue, or if it just resolved itself [04:14] Longest I've gone straight was ~50 hours. Slept once I realized the people giving me advice on the programming project were hallucinations. [04:17] so no one knows about %F vs %U in desktop files? [04:17] * calc thinks he will leave it at %U since it seems to work, though %F is probably more correct [04:18] * ScottK votes for working over correctness. [04:19] it works both ways but with %U it seems that burn:// urls are passed to OOo still [04:19] i don't know if switching it to %F will cause any problems though [04:22] * ScottK also favors leaving well enough alone. [04:26] uploading new OOo now with gnome-vfs disabled and set to use gvfs fuse :) [04:31] anyone have an idea on how to go about debugging X, in that it freezes regularly in jaunty on an r300 card (T42p laptop w/ firegl card) [05:16] good morning [05:37] dholbach, good morning [05:37] hiya cooloney [08:31] Good morning [08:32] good morning [08:36] hello [08:36] I have some issues with evolution in jaunty. [08:36] it says I can't get imap since there's no provider available. [08:36] is that normal jaunty behaviour and I should just wait for a fix, or something is off with my local system? [08:37] (had some nastiness during updates/upgrades, so it might be that some packages weren't completely installed) [08:39] james_w: did you thoroughly test bzr 1.13 already? [08:49] pitti: have you thought about privilege escalation for apport? I'd like to do a package hook for apparmor, but one of the things I'd like to collect requires root privs. [08:53] sbeattie: right, for some cases we need hooks which run when the program crashes, not when you report it [08:56] pitti: hrm, that, too. But I'm thinking more along the lines of including the output of apparmor_status, which requires root equivalent access. === tkamppeter_ is now known as tkamppeter [08:59] sbeattie: right, if you do "ubuntu-bug" as user, you can't have that [08:59] sbeattie: if you ask people to "sudo ubuntu-bug", it'll work [09:32] pitti: ls -l `locate coreutils.mo` [09:32] pitti: do you know what is to blame for that? [09:33] doko: ^ or you [09:33] seb128: the symlinks you mean? [09:33] pitti: the broken ones yes [09:33] seb128: they are shipped in coreutils [09:33] indeed, they should point to locale-langpack/ [09:34] they look pretty weird in the first place, though [09:41] thekorn: FYI, I uploaded a new p-lp-bugs with another fix for parsing duplicates [09:41] thekorn: and yesterday night I hacked a lot on the launchpadlib branch (just to avoid duplicate work by you) [09:45] mvo, ping === mpt_ is now known as mpt [09:54] pong [10:02] * asac still wonders which package could have broken his nfs mount :( [10:03] pitti, yes, I've seen your bug mails, thanks for the upload [10:03] no problem [10:13] asac: is it something that you mount manually? If yes, go to System/Administration/Authorisation and check that you have the authorisation (for policykit) to mount [10:17] tseliot: no its a /etc/fstab setup mount [10:17] asac: ah, ok [10:17] it worked for a decade ... now its gone. and i cannot read email anymore :( [10:17] :-/ [10:18] hmm ... saw strange modprobe issues during this boot [10:18] output looked similar to what you get when you run modprobe without any module (e.g. --help) [10:21] tseliot: but a good idea. any idea where i setup such a manual mount ;) [10:21] * asac found Network [10:23] thats not it ... [10:23] asac: sorry but I've never used nfs therefore I have no idea [10:46] seb128: if the gdm transition code is available, what's left for https://blueprints.edge.launchpad.net/ubuntu/+spec/gdm-upgrade ? [10:47] pitti: updating that was on my todo I just tested the transition code to make sure it worked before going to bed this night and I wanted to update the blueprint today, let me do that now [10:48] seb128: ah, no hurry; I'm just updating the ReleaseStatus page (release meeting today) [10:48] seb128: yay [10:49] pitti: changed to implemented [10:49] pitti: should I upload gdm-new to universe now? or is that late in the cycle? [10:49] seb128: fine for me [10:49] ok, let's do that [10:49] few people find the ppa and it has other cracks too now [10:50] tseliot: what's left for https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-options-editor ? [10:51] pitti: just a UI cleanup, which won't take place in Jaunty [10:51] Riddell: can you please update the status of the kubuntu jaunty specs? [10:52] tseliot: can you please update the status of the spec, and separate the remaining UI bits, e. g. into bug reports? Or do you think it's incomplete enough so that we have to pull it? [10:54] pitti: I think it's usable, it just doesn't have the best looking UI ever created. I'll update the status of the spec and file a bug report. [10:54] ok [10:54] tseliot: thanks; please then refer to the bug report and set it to implemented, if all the functionality in the spec is covered now [10:54] Riddell: thanks [10:55] pitti: ok [11:18] pitti: done [11:19] tseliot: cheers [11:19] pitti: :-) [11:30] doko: Is it intentional that python-support always makes public modules available for the current version, regardless of what pycompat says? [11:38] thekorn: adding/removing tags on staging doesn't seem to work for me with p-lp-bugs; did you happen to notice that as well? [11:38] thekorn: I tried for half an hour to find the bug in my test suite, but it really just gets swallowed, it seems [11:38] thekorn: trying with launchpadlib now [11:39] pitti, no, can have a look at it in a bit [11:40] does it work on edge [11:40] thekorn: no, just asking [11:40] thekorn: haven't checked edge yet, let me try [11:41] >>> b = Bug(89040) [11:41] >>> b.tags [11:41] ['apport'] [11:41] >>> b.tags.append('testsuite') [11:41] >>> b.commit() [11:42] thekorn: shouldn't that work? [11:42] thekorn: ^ edge now [11:42] pitti, yes, this should work this way [11:42] thekorn: hang on, perhaps for adding it stumbles over that silly new dialog box which asks you about "new tag OMG!" for every new pacakge [11:42] but removing tags should work.. [11:43] hm, doesn't work on edge either [11:43] seb128: ^ I think this is serious enough that we have to stop the retracers; otherwise they'll just retrace the same thing over and over [11:43] * pitti checks the logs [11:43] pitti, removing works for me on edge [11:43] pitti: ack [11:44] hm. according to my figures, jaunty is 44 meg smaller than intrepid [11:44] excluding a kernel [11:45] thekorn, seb128: hm, it seems to work on ronne [11:45] WTH? [11:45] pitti, adding too, [11:46] thekorn: ok, thanks for checking; must be something on my end then [11:46] if you would like to add a 'new' tag, you can use b.commit(force_changes=True) [11:46] oh, should I always use that? [11:47] thekorn: anyway, I now have the test suite succeed in the launchpadlib branch, so I'm going to switch over soon anyway [11:47] just figuring out why the last set of tests I wrote fails [11:47] yuhu [11:58] what should be prerequisites in terms of prog languages that one should hv to start ubuntu developing?? [11:59] panesar_sandeep: it depends on the software you want to work on [12:00] That's not really a meaningful question - Ubuntu is a combination of so many pieces of software. You need to know the languages used in the bits you intend to work on. [12:00] much of the core of Linux is written in C [12:00] ok but still, i am intrested in debugging, but am not able to workout gdb well [12:00] various add-on pieces use Perl or Python, and Bourne Shell is a must [12:01] Desktop environments might use something like C# (GNOME pieces) or C++ (KDE) [12:01] cjwatson: any news about the cleanup of the buildd chroots? [12:02] where can i get help/docs about using gdb or debugging in ubuntu... [12:02] bigon: no [12:02] panesar_sandeep: gdb includes its own manual [12:02] panesar_sandeep: install gdb-doc and run "info gdb" [12:02] panesar_sandeep, this isn't really the channel for learnign to program with ubuntu, as stated in /topic [12:02] keybuk, thnx :) [12:02] keybuk, sory too [12:02] :) [12:03] or use monodevelop-debugger-gdb! \o/ [12:03] gotta test that === davidm_ is now known as davidm === asac_ is now known as asac === sabdfl1 is now known as sabdfl [12:47] pitti: I run bzr.dev, as do many people. There have been a few issues arise during testing this week, with fixes being cherry-picked to the release branch. [12:48] james_w, we have monodevelop-debugger-gdb now, tested & working [12:48] I saw, thanks [12:48] hm, that was meant to be in #ubuntu-motu [12:48] well, I didn't see it was tested and working, so even better :-) [12:53] james_w, by "tested and working" i mean "setting breakpoints in a 10-line hello world app works" [12:53] ditto for hello.cs with monodevelop-debugger-mdb [12:54] directhex: there's still no way to import an existing project though? [12:54] If you are skilled enough to write more than 10 lines of C you shouldn't need a debugger anyway [12:57] Keybuk, no. but it's already buckets sexier than monodevelop 1.0 was [12:57] Keybuk, that might even be a gsoc suggestion - autofoo import wizard [13:04] directhex: it's a complete mystery to me how to even start a new autofoo C project in monodevelop [13:10] hi people, tracker won't be installed by default in Jaunty anymore? [13:12] Keybuk, i can't see how to do it fully. makefile stuff is under project options, but i get an error when i enable it & click ok. might be a bug. i'll ask upstream [13:32] pitti, did you already touch the new notify-osd release? [13:33] MacSlow: did you see my comment on #dx? [13:33] MacSlow: where I was asked if we should look at updating notify-osd in jaunty [13:34] seb128, sure I've done a 0.9.3 release which includes the fixes for the kerneloops-applet issue and the "epiphany-download" crasher [13:34] MacSlow, pitti: ok, I'm looking at the update [13:34] seb128, btw https://edge.launchpad.net/notify-osd/trunk/0.9.3 [13:35] thanks [13:35] seb128, where do I indicate on LP that other packages are affected by changes to notify-osd? [13:35] MacSlow: "Also affects distribution" [13:35] MacSlow: And then find the package from there. [13:35] MacSlow: open bugs on those or add task by click the "also affect" below the table [13:59] seb128: re from lunch; shall I do the update, or are you on it? [13:59] pitti: notify-osd? I'm on it [13:59] seb128: okay; have release team meeting now [14:00] pitti: feel free to tackle some other sponsoring request if you want, I cleaned some yesterday but there is still a few pending ones and 2.26 is due next week [14:00] seb128: check if the packaging branch already has 0.9.3 first; if so, please merge from that, instead of just updating the ubuntu branch yourself [14:00] seb128: right; bit crammed today [14:00] pitti: no hurry don't worry, will do for the notify-osd update === azeem_ is now known as azeem [14:09] cjwatson, Keybuk ... do we already have a bug for the 1970 prob and useradd ? [14:25] ogra: I didn't file one [14:25] I'd suggest the bug is actually in useradd not adduser [14:25] ogra said useradd ... [14:25] so he did [14:25] thats why i said so :) [14:25] sorry, dunno how I read that wrong ;) [14:25] (and I agree) [14:26] * ogra has to run out for 1h [14:34] ttx: it may be better to just upload/merge samba 3.3.2 [14:37] I don't wanna be a nag but why is gFTP still unavailable with compiled SSL? It's no prob for me to do it but the n00bs out there probably can't. You think I should file that on launchpad? Yes, no, maybe? :-) [14:37] Aquina, yes [14:40] mathiaz: looking... [14:41] ttx: there are a couple of major bug fixes included in 3.3.2 [14:43] mathiaz: yes... but it's a bigger change, then [14:43] ttx: right - however most of the change seem to be bug fixes only. [14:44] ttx: may at we should include the patches for the main issues? [14:44] Keybuk: hey [14:44] ttx: may *be* [14:45] Keybuk: about bug #339612, which console? there's usplash so I don't see anything *g* [14:45] Launchpad bug 339612 in upstart "[jaunty] poweroff doesn't work, but halt does" [Low,Incomplete] https://launchpad.net/bugs/339612 [14:45] mathiaz: probably makes more sense to move to 3.3.2. I won't have time to pull it off before the end of the day though. [14:47] ttx: sure. [14:48] mathiaz: I guess we need an Ffe for that move as well. [14:50] ttx: why? [14:50] ttx: it seems that this is a bug fix only release [14:51] mathiaz: hm, yes, indeed. [14:56] mvo: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/ looks sort of out of date. Does it do any testing with more recent releases? [14:57] mvo: (and should we add something to NewReleaseCycleProcess to remind you to update it?) [15:01] Would anyone mind if I added "karmic" to the list of acceptable distributions in vim's debchangelog syntax file now? It's always bugged me that it doesn't work when we get started on a new release. [15:01] * soren glances at cjwatson [15:02] soren: if we do it, it should be done in debchange and lintian as well IMHO [15:02] pitti: Indeed. [15:02] and for the record, I wouldn't mind [15:04] anyone know of a reliable way to add a pre-depends package or a pre-depends line with package to a control file if the line doesn't exist? [15:04] i have a way to add it without checking but that isn't very good [15:04] eg: sed -i '/^Architecture:/a Pre-Depends: dpkg (>= 1.14.12ubuntu3)' debian/control [15:04] calc: you mean with seddery? [15:04] pitti: yea or something similarly automated [15:04] calc: I was using the same [15:05] \j #vartakblogs [15:05] pitti: i dropped my pre-depends for lzma because i needed another pre-depends on a package but need it still since soyuz still does the check [15:05] shit [15:05] soren: fine by me [15:05] cjwatson: Cool. [15:06] pitti: so now for one of my packages in OOo there is already a pre-depends line so the second pre-depends line causes an error [15:10] calc: you could run above once, and then vi over it, searching for /\nPre-Depends:.*\nPre-Depends/ ? [15:11] pitti: I just committed a small but important fix to jockey, will that be uploaded sometime before beta? [15:12] pitti: automated or do you mean to manually fix it up? [15:12] Riddell: yes, I need to fix some things anyway [15:12] pitti: manual would probably work since i have a bug open on soyuz already [15:12] calc: manually; I guess there won't be that many pre-depends duplications? [15:12] pitti: yea just one [15:14] pitti: hmm couldn't i do something like the above to merge the two lines in sed? [15:16] calc: well, it's not that reliable, since it's not guaranteed that existing Pre-Depends: fields are always directly below Architecture: [15:16] calc: there's certainly some seddery to do that, with using its buffer [15:16] but my sed fu isn't that great, I'm afraid [15:17] ok [15:18] pitti: Thanks for reminding me of debchange. I wouldn't have thought of that one. I've uploaded all three (vim, devscripts, and lintian) now. [15:18] soren: yay koalas! [15:21] Go go gadget dput! [15:29] Keybuk: did you open bugs about those "don't do fading effect on login" changes btw? [15:32] seb128: not yet, perfecting the patches [15:32] Keybuk: ok, would be nice to get before beta if you can get those ready for next week [15:32] RainCT: boot without "splash" > [15:32] seb128: yeah, definitely will :p [15:32] cool [15:33] Keybuk: heh ok.. [15:38] mvo: aaah! mystery in bug 315571 solved [15:38] Launchpad bug 315571 in python-apt "[jaunty] causes random Launchpad timeouts with python-apport" [High,New] https://launchpad.net/bugs/315571 [15:52] ScottK,doko: bug 342335 is the ICE blocking KDE on powerpc [15:52] Launchpad bug 342335 in gcc-4.3 "ICE compiling qt4-x11 on powerpc" [Undecided,New] https://launchpad.net/bugs/342335 [15:54] cjwatson: I'll have a look tomorrow. does lowering optimizations help? using gcc-snapshot? [15:55] haven't yet tried gcc-snapshot, I'll ask for that to be installed on davis [15:55] * calc did the crappy edit a generated file way to fix the problem [15:56] doko: -O2 -> -O1 does make it go away, so I'll try to bisect optimisations [15:57] doko: from the source it appears to be something to do with PLT generation in PIC mode [16:00] cjwatson: works with 4.4 [16:04] -foptimize-sibling-calls appears to be relevant [16:04] I'll lower optimisation for now [16:21] pitti: yeah, it should be fixed [16:22] lazynet, I have a question: are ubuntu binaries built using BuildIDs? (e.g. if you do readelf -n /bin/sleep is there a build ID note)? [16:23] Doesn’t apt-cache policy coreutils suffice? [16:25] ion: long story short: no. [16:25] gdb (in RHEL/Fedora at least) uses the build IDs to get debugging symbols from files with unique filenames [16:26] launchpad resolves the debugging symbols, it seems to work well. [16:26] retracing the debugging symbols server-side requires sending core dumps to a third party [16:26] that does not fly for me, or Fedora, or RHEL [16:27] so back to my simple yes-or-no question: can someone run readelf -n /bin/sleep and thus tell me if there's BUILD_ID notes in the binaries? [16:28] wwoods: no, is that a specific Fedora patch? [16:28] wwoods: you may want to propose a discussion for UDS about doing retracing the fedora way... [16:29] wwoods: assuming the features needed are available it probably wouldn't be too hard to implement if people can come to a consensus this a better way [16:29] calc: AFAIK it's in upstream ld but I might be wrong - still doing research, and I figured I could answer "does Ubuntu already use --build-id"? quickly [16:30] wwoods: it appears jaunty does not have build id in sleep [16:30] readelf -n /bin/sleep [16:30] Notes at offset 0x00000254 with length 0x00000020: Owner Data size Description GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag) [16:30] that is all that it returned for me [16:31] does ld --help mention build-id at all? [16:31] yes [16:31] I don't follow how that has anything to do with server-side retracing, though [16:31] I'm trying to eliminate server-side retracing [16:32] retrace on the client-side by downloading only the required debuginfo data over the internet [16:32] yeah, it's pretty irrelevant for server-side retracing, since the problem isn't the debug symbols but the core dump [16:32] if you have unique build IDs it's trivial to determine exactly which individual files are necessary to retrace a core [16:32] wwoods: that's actually one of apport's long-term wishlist bugs [16:32] wwoods: yea ld has build-id support [16:32] wwoods: but since debugsyms are so terribly huge, there's not a lot of interest in it [16:33] wwoods: it's already trivial because you already know what libraries are loaded, what packages they come from, and what versions those packages are at [16:33] sooo if you have, say, a webdav share with all the debugging data for every binary [16:33] so you just install the corresponding -dbgsym packages [16:33] slangasek: installing the entire package is insanely wasteful [16:33] typically 95% of the installed data goes unused [16:33] not to mention the overhead of doing all the metadata parsing [16:33] package database updates [16:33] etc === amitk_ is now known as amitk [16:34] so instead you have a webdav share with all the debugging data on it - they all have unique filenames, so you can have debugging data for multiple versions of the same package [16:34] the client mounts that share at /usr/lib/debug/.build-id, gdb only pulls the files it needs [16:35] voila - full retraces, client-side, without installing anything [16:35] wwoods: that sounds like a fine idea [16:35] wwoods: is the build ID any more fine-grained than the package version? [16:36] pitti: each individual binary gets its own UUID [16:36] so each bin in coreutils has its own build-id [16:36] how does that help, though? [16:36] since in a package build, all binaries get built at the same time anyway? [16:37] well, you need to be able to discern which file corresponds to /bin/sleep and which one is /bin/ls [16:37] I've got a working (albeit experimental) implementation of this in Fedora [16:37] wwoods: right, I figured that would end up as something like /debugsyms/coreutils/1.2.3-4/bin/ls [16:37] it's one of the big roadblocks that keeps us from attempting to use Apport [16:38] wwoods: are the build IDs a checksum, or a really uniqye number? [16:38] really unique [16:38] wwoods: with a checksum I see the benefit of sharing identical files, but with UUIDs we could just as well use the package version? [16:39] or is it just to avoid figugring out all the package versions? [16:39] AFAICT, anyway. [16:39] mostly it's such that gdb doesn't need to try to read the rpm database to figure out what version a package is [16:39] to figure out where to look for its debuginfo [16:39] anywya computer is freaking out, I will be back in a little bit [16:39] but you might ask google to give you the fedora wiki pages on buildid [16:39] wwoods: anyway, I could see this getting abstracted in apport/packaging.py, such as a function that maps an ELF in the system to an URL for its debugging symbols [16:39] and debuginfofs [16:40] wwoods: right, intersting idea; thanks! [16:43] doko: so is this site-packages -> dist-packages change in python the same in Debian? === mkrufky is now known as mkrufky-away === DRebellion is now known as ssb_ === robbiew1 is now known as robbiew === fader is now known as fader|lunch [17:23] bryce_: right [17:23] Keybuk: what? [17:23] why does it take 5 seconds to get to the userspace for Ubuntu [17:23] but only 1s in Moblin [17:23] that's kinda the question really [17:24] something about their X server makes it start a hell of a lot faster than ours :-/ [17:24] Keybuk: did you see my email where I discussed this? [17:25] Keybuk: it looks to me like hal is delaying things [17:25] it isn't [17:25] I can put a sleep 10 there, and X still takes that long to start [17:26] Keybuk: well there's nothing in the X log between like 2.7 sec and the 5.8 sec mark. I don't think X is doing anything during that period. [17:26] Keybuk: _I don't know_ what's going on during that period, but I don't think it's X doing anything particular [17:27] 2.7s is still twice as long as Moblin ;) [17:28] I don’t know if that’s relevant, but it seems X changes the screen mode to something, then switches back to the virtual console for a second, then changes the screen mode again and keeps doing that a couple of times, and then finally shows a cursor and gets to GDM. [17:28] ...greeter [17:29] Keybuk: have some time? need help debugging "inaccessible DVD" problem again. Totem/VLC/Mplayer both complain and I have libdvdcss installed. [17:30] ion_: it doesn't do that here [17:30] slytherin: doesn't sound like I'm the right person [17:31] unless you're getting Permission Denied [17:31] Keybuk: yes, totem says "you may not have permission to view". I thought this might have something to do with udev. [17:32] most likely HAL [17:32] udev doesn't assign permissions a user is expected to have [17:33] Keybuk: hmm. About a month ago we discussed similar issue, the device for DVD drive is /dev/hdc. [17:34] and at that time we concluded that the group for the device was set wrong by udev [17:34] or hal as you say [17:35] slytherin: what does ls -l /dev/hdc say? [17:35] Keybuk: brw-rw----+ 1 root cdrom 22, 0 2009-03-13 22:29 /dev/hdc [17:35] looks right to me [17:35] slytherin: getfacl /dev/hdc [17:35]