[00:12] hi all [00:12] can someone help me with this bug ? https://bugs.launchpad.net/ubuntu/+bug/223843 [00:13] i found out it have nothing to do with the xrdb error messages in .xsession-errors [00:13] but the bootchart shows me xrdb -> zombie [00:14] is this the right channel to ask ? === shadowxp2 is now known as shadowxp [00:42] i wish open week would publish required readings for talks instead of just duplicating the wiki over IRC [01:10] * lamont wonders what xivulon wanted [01:11] lamont: now you'll *never* know === golddragon24_ is now known as golddragon24 [01:11] To ask your hand in marriage. [01:11] lamont: the inquisition will haunt you for the REST of your life [01:11] jdong: nah [01:11] he didn't care enough to just ask the question, so... meh [01:11] deep down you really do care. you are dying to know [01:11] and it will only become apparent in your mid-life crisis :) [01:12] * jdong was told not to go into medical science for some reason :) [01:12] May I inquire whether I am allowed to ask whether it's okay to ask whether i can ask to ask a metaquestion? [01:12] jdong: I already sold my midlife-crisis car [01:13] ion_: not without asking first. [01:13] :-) [01:13] one of the more interesting bugs I've encountered when upgrading to feisty is that my left monitor has become intermittent [01:13] feisty??? [01:13] Well, it's probably fixed in Gutsy or Hardy. [01:13] dear me, why? [01:13] uh, sorry. Hardy! [01:13] no on an idea ? [01:13] It's 2AM, and I'm doing schoolwork. :) [01:13] or help to find the problem ? [01:13] am I allowed to ask whether it's okay to ask whether i can ask to ask a metaquestion? [01:14] Well, I'm on IRC, pretending to myself that I'm really doing schoolwork. It's complicated. [01:14] toresbe: I know that issue far too well. [01:14] :) [01:14] OTOH, it's 6PM here, and I'm about to head off to bed - exhausting afternoon [01:14] after upgrading, monitor 0 while using the evil unfree nVidia driver... [01:14] pfft bed at 6PM? [01:14] jdong: I roll out of bed at 5AM weekdays [01:15] and this afternoon I kinda played on an antenna tower for a while.. [01:15] lamont: that's typically when I roll into bed to prepare for 9AM classes :) [01:15] total of ~ 200 feet of vertical climb, up and down [01:15] max height above ground? 40 feet [01:15] lots of trips [01:15] oh, and manhandling a 70 pound section into place at the top of two of those climbs [01:16] * ion_ does % units 200feet m [01:16] ion_: 66m [01:16] and max height of ~13m [01:16] 60.96 :-) [01:16] iz wag [01:16] you only get 2 sigfigs [01:16] too tired to actually count what I climbed [01:17] we were short one person, so I climbed to do the upstairs prep, then down to help haul it up, then up to place it, then up/down/up 10 feet to migrate the pole to the top of the newly installed section, then down to do it all over again [01:17] fortunately only adding 2 sections to the tower [01:18] Heh [01:18] lamont: this sounds like the problem used to kick start our math discussion on recursive generator functions [01:18] so now my arms are starting to feel it. [01:18] I think you're supposed to move the bigger disc to pole 3 first [01:18] then move the next one to poll 2, then bring 3->2 [01:18] jdong: oh, it's definitely at least iterative, recursion would involve not coming down until it was done. [01:18] *ducks* [01:18] lol [01:19] just one stick [01:19] although if we grow it again, we'll have to take the top section down to put the new not-top section on before we can put the top back on... so it starts to feel like the tower of hanoi all over again [01:20] What's the difference between a recursive function and a recursive generator function? 'foo = 1 + foo' vs. 'foo = 1 : [ a+1 | a <- foo ]' (haskell)? [01:20] I may put the 20 foot mast (which would top out at 62' )long story), and slap a flag on that so that I can call it a flag pole. then light it from below so I don't have to take the flag down - because that'd suck [01:21] ion_: generator functions track state for you lazily, it's not your job to manage the state of the generator [01:21] ion_: which is useful for more complex generators [01:22] where you can just "yield" values at arbitrary points in execution [01:22] and the next time you need to generate a value the function "resumes" at that spot [01:22] Alright [01:23] So a recursive generator function is just that, but happens to be recursive. :-) That is, the latter example is precisely that. [01:23] s/recursive generator/generator function/ [01:23] Uh, scratch that. Too sleepy. [01:24] ion_: well a generator function in CS is different than a generator function in mathematical theory [01:24] a generating function in math theory is stupid ;) [01:24] pwnguin: but it's on the test next week! [01:24] heh [01:24] pwnguin: so I'm kinda out of options :) [01:25] i really cant see the utility in them versus learning more graph theory [01:25] * lamont takes a drive to go restart openvpn from the far end. sigh [01:45] Heya lamont. sgran has me using git now (on clamav), so there's hope for me yet. [01:46] oh my! [02:19] ScottK: heh. cool [02:19] ScottK: I bounce between git and bzr these days [02:20] So far I've encountered bzr nowhere outside of Ubuntu (I know it's used elsewhere, I just haven't run into it). Learning yet another VCS special for Ubuntu is low on my list. [02:22] ScottK: so you just need to get a git-bzr ;-) [02:57] mjg59: http://www.advogato.org/person/mjg59/diary/82.html <- the firmware bug is what exactly? that it defaults to parking at too low an idle time? [02:57] good morning [03:06] ScottK: likewise until I kinda picked up a business need to learn another one... [03:06] and I see benefits to both of them. and insufficient reason to switch between them for things that are already in one or the other [03:07] cvs/svn? definitely shoot it in the head and move to bzr or git. kthx [03:07] I wonder if I'd get shot for uploading to intrepid, or if it'll just wait until everything is ready for it [03:10] g'morning Hobbsee [03:10] I think we've proven recently that it's impossible to be fired from being a volunteer for Ubuntu, so no reason not to go for it. [03:12] It being frozen, the upload will likely sit in approved [03:12] s/approved/unapproved/ [03:15] persia: Did you see the message to debian-devel about README.Debian.source? [03:16] ScottK: Yes. I'm all in favor [03:16] got a question, anyone know how to use blktrace? [03:17] With luck, there will be defined rules in debian/rules in the future to for things like "edit-patch", "patch", etc. [03:17] persia: I'd suggest some updating of our documentation then so we can start pointing REVU victims at it. [03:17] "blktrace -d /dev/sda -o -" says "/sys/kernel/debug does not appear to be a debug filesystem" [03:17] ScottK: s/victims/users/ [03:17] anyone know how to make it work? [03:17] ScottK: Sounds like a good idea. You might want to write the suggestion to a mailing list [03:17] and util-linux_2.14~rc2-0ubuntu1 heads for intrepid [03:17] StevenK: There's a difference (It's Debian makes you care about the users, not Ubuntu)? [03:18] persia: Sure. [03:19] oh nm README.Debian tells me what to do :) [03:19] persia: Done. [03:23] * lamont really afk [03:42] * TheMuso is in favour of the README.source file as well. [03:43] For odd stuff, sure, but I don't see a point in a file that says "This package uses dpatch" and then goes on to explain using dpatch-edit-patch. [03:43] As with many things, it seems like a decent idea way overdone. [03:53] ScottK: As it says in that email, for a dpatch using package, it would likely just point to the dpatch info somewhere in /usr/share/doc/dpatch. On the other hand, it makes answering the question "How do I tell what patch system to use" as easy as "read README.source" [03:56] * ScottK doesn't see that as a significant improvment over looking at the build-deps and then reading man dpatch-edit-patch, but OK. [03:58] ScottK: For the case of an enumerable set of patch systems, I agree. In order to specifically support an arbitrary set of patch systems, it'd be nice to not have to explain how to check both debian/control, debian/rules, and possibly some random included makefile snippet from somewhere when someone wants to prepare a patch. [03:59] Right, but I think a "Don't bother if it uses dpatch, simple-patchsys, or quilt" rule would make sense. === dmb_ is now known as dmb [04:00] Well, also, as the set grows unboundedly, it becomes less clear if people would reliably remain familiar with those patch systems. [04:01] But keep in mind the described purpose of this is for the security team. [04:01] It's not meant for random developer wanna be's. [04:05] Well, it's useful for them. Anyway, even for the security team, consider the case where someone encounters one of the packages that has patches both applied to the source in diff.gz and stored in debian/patches for reference: these are annoying to update without documentation. As the set of systems grows, this becomes more of a problem. [04:05] At some point in the future, new entrants into the security team may rely on packages being in git or bzr tarballs as a regular course, and be somewhat stumped by someone's specialty dpatch that executes some logical analysis rather than just applying a simple patch. [04:06] Sure someday. [04:08] Right. For the common cases, it's just a "This package uses simple-patchsys: see /usr/share/doc/cdbs/simple-patchsys." in README.source. Not very difficult, yet future-proof. === greeneggsnospam is now known as jsgotangco [04:16] I'd prefer a machine-readable README.source, honestly. [04:16] better yet, common build rules. [04:16] but README.source is certainly a good first step. :) [04:30] kees: If you'd be up for documenting a model, it could be encouraged for use in REVU as a proving ground. [04:32] persia: I worry any attempt at this would just result in cdbs-edit-patch. ;) [04:35] kees: Maybe, but I'd agree with you that having more defined build rules is the way to go. I'd like to see "patch", "unpatch", and "edit-patch" be standards. Let the packager control how the rule is implemented, rather than trying to have some system that does the right thing (e.g. cdbs-edit-patch). [04:36] Set some standards, like "edit-patch must leave the user in a subshell, and save changes when complete", and it makes it easy for the updater. [04:37] persia: Perhaps we should define some kind of common debian build system? [04:37] ;-) [04:37] persia: yeah -- I would love that. :) [04:37] ScottK: sssh! ;) [04:37] I guess I don't know how hard this really is. [04:37] ScottK: We've had two. I'd rather have a defined interface, than defined code. This allows flexibility and change, without imposing behavious [04:37] s/s$/r/ [04:37] I fixed on one of manoj's packages just before release and even that wasn't that hard. [04:38] In case you don't know, manoj doesn't even use debhelper. [04:39] * ScottK goes to bed (really this time). [04:40] That's fine. I'm not even especially concerned if people don't use make (although I'm a big fan of make). I'd just like to see more required rules implemented, so that more standard package manipulation procedures could be automated. [04:41] I don't want to have to think about what to do when I want to a) check a new upstream, b) verify the patchset applied, c) apply patches, d) edit patches, 4) package a new upstream, 5) verify rebuild of generated files, etc. [04:41] Every package should have the same interface: `debian/rules foo`. Ideally, there should be different sets of deps in debian/control so I can always verify that I have the right environment in which to run the rule. [04:55] persia: I think we should start shipping packages with binary debian/rules, without source. === RAOF_ is now known as RAOF [04:58] * Hobbsee clubs wgrant [04:58] you spelled hugs wrong [04:59] * RAOF gives hugs [04:59] hey RAOF [04:59] Hey pwnguin. [05:01] random question: is the drm stuff nouveau needs going to be in mainline kernel any time soon? [05:01] Once they're reasonably certain they'll not need to change any interfaces, yes. [05:01] so still no firm date [05:01] or even soft date [05:01] That's one of the reasons why testing the randr12 codepath is being pushed right now. [05:02] No, AFAIK. [05:02] wgrant: That's a little extreme. I think we only have a couple binary debian/rules, but without source gets messy. [05:02] heh, progressQuest [05:02] Once there are no randr12 blocker bugs it gets enabled by default, then pushed to kernelspace, then pushed to mainline IIUC. [05:03] so what else uses that besides nouveau? intel? === dmb_ is now known as dmb [05:03] pwnguin: Yup. Intel will, but not quite yet I think. [05:03] pwnguin: Everything _will_, eventually. [05:06] Is TTM part of the new DRM, or not? [05:08] donno about that. [05:08] I think this depends on what you mean by "new DRM" :). I don't think that nouveau uses TTM yet, and I'm not sure whether intel does either, outside of git branches. [05:11] I _think_ that with a bunch of git builds you can get DRI2 on (what will be) Xserver 1.5 with Intel, and I'm pretty sure that requires TTM. So... [05:13] i wrote a patch to fix a bug (LP: #221661). would someone be willing to review it and tell me if it's OK? [05:14] bug 221661 [05:14] oh that's right. no more bots. [05:14] pfft [05:14] huh? [05:14] TheMuso: more IRC politics than you want to ever know about... [05:14] jdong: Whats this? [05:14] trust me. [05:14] TheMuso: you don't want to know. [05:15] * TheMuso sighs. So it is to our detriment then. [05:15] jdong: we have bots just none have that plugin or are as smart as ubotu [05:16] What? Why no ubotu? [05:16] a7x: I looked at the patch, I can't say much about it, I'm not conviinced that it's right or wrong [05:17] RAOF: nope no more [05:17] _!!!_ [05:18] ill brb my screen just went really small [05:18] thanks. what should my next step be? just let it sit until the package maintainer finds it? [06:13] Good morning === MacSlow_ is now known as MacSlow [07:23] Good morning [07:23] greetings [07:31] morning [07:32] ReiserFS: For when you need to partition your wife. :D [07:40] Nice silicium === carlos_ is now known as carlos [08:43] morning [09:32] Keybuk: hm, MoM seems to be out of date. e. g. it shows debhelper as 6.0.10 in Debian; that was from March [09:54] hmmmm, why translation import queue is so long, is there any hope for it to change? [09:54] yipee intrepid is now open for abuse :) [09:55] PecisDarbs: if intrepid is open, i imagine there's a whole ton of upstream translations being pulled in now? [09:55] ahhh I see [09:55] I doubt the autosyncer would have run yet. [09:56] As we have no new toolchain quite yet. [09:56] basefiles, binutils is there already and a few other things [09:57] I'll wait a few more days before I upgrade. [10:12] calc: will be a little while yet before it's open open [10:12] doko, cjwatson: FYI, debhelper merged, tested, fixed (sent to Debian), and uploaded, waiting in unapproved now [10:12] pwnguin: I rather doubt that intrepid is open for translations yet [10:13] pitti: do we want that in before gcc's done? I was thinking let the C toolchain build first [10:13] I don't mind [10:13] cjwatson: yes, that's fine; just mentioning to avoid double work [10:13] cjwatson: it's arch:all, so it doesn't matter, but I thought it would be good to have it readily available in the queue [10:14] * pitti merges cdbs now [10:15] pitti: Please either reference the changelogs bit in the changelog or drop it [10:15] persia: ECONTEXT? [10:16] pitti: For hardy, we carried a patch on CDBS that wasn't in the changelogs, which didn't autoinclude upstream changelogs in the binary package. [10:16] For intrepid, it would be my preference to either explicitly document this patch, or not carry it. [10:16] persia: oh, sure; I'll walk through the entire delta again anyway [10:17] pitti: Great. Just wanted to make sure that didn't get missed again: it wasn't worth a patch to fix the changelog, but confused a lot of REVU'ers [10:17] right [10:18] persia: why do REVU people look at cdbs changes? [10:19] seb128: Because people were getting the warning that they weren't including the upstream changelog from linda, and the CDBS documentation explicitly states that it should be autoincluded by CDBS. Without the reference in the changelog, several people spent time tracking down the cause to separately answer the question "Why doesn't it work they way it says it should". [10:19] ah, ok [10:20] Of course, more generally, there is the class of users who use apt-listchanges :) [10:22] Do we really need that patch anyway? It can't save that much space, and there's no longer an easy way to look for upstream changes. [10:22] There's also a heap of packages that work around it in one way or another [10:22] wgrant: oh, it saves a lot of space; upstream changelogs are often incredibly huge [10:23] they could go into libfoo-dev, but they shouldn't really be in all binaries [10:23] wgrant: the space doesn't matter that much on an install but it does on the cd for example [10:23] Given that only a subset of packages are on the CD, and not all of those use CDBS, might it make sense to patch those packages? [10:24] Xubuntu folks: do we still need cdbs' xfce.mk? AFAIK it's being phased out? [10:24] persia: That would appear to make the most sense. [10:24] no it doesn't [10:24] persia: it's still a waste of bandwidth and HD space for users [10:25] persia: we don't want to have the whole cd content carying ubuntu specific change for no good reason [10:25] pitti: I guess, but I've seen a lot of packages that work around it. Then again, I'm not in a good position to take an opinion based on bandwidth or disk space constraints. [10:26] bah, they should not [10:26] ... why not? [10:26] If we really want to strip them, it would make more sense to me to have a hook in the build system that pulled them at build-time, to hit all packages, rather than just CDBS packages. [10:26] we should fix those and explain to whoever does the change there is no reason [10:26] Upstream changelogs are a good thing. [10:26] they are not an user thing [10:27] seb128: We ship the Debian changelog why? [10:27] Why not? Users have to deal with the mnigration between versions when the upgrade. This is especially a concern for server-type packages. [10:27] Surely that's going to have even fewer user-visible changes. [10:27] * cjwatson hopes the REVU process isn't suggesting people use linda any more, BTW [10:27] it's officially phased out in Debian now [10:27] cjwatson: It does, but there's no linda. It will likely be dropped when the documentation is next refreshed. [10:28] persia: informations which should be displayed on upgrade should go in the README.Debian, not rely on users reading the upstream changelog for each package they update [10:28] seb128: YM NEWS.Debian? [10:28] or that ;-) [10:28] seb128: Do you mean NEWS.Debian? In that case, I have to echo wgrant's question: why do we ship any changelogs? [10:29] * persia reads every changelog for every package installed, but understands this is not a typical level of paranoia [10:29] persia: They're useful if something breaks or you're interested; they just shouldn't be essential reading for everyone. [10:29] persia: waouh, so when upgrading a box from dapper to hardy you read over 1000 changelog, I'm impressed ;-) [10:30] broonie: That makes sense to me. What doesn't make sense is specifically stripping changelogs from only CDBS packages that don't use the DEB_CHANGELOGS_ALL variable. [10:30] seb128: Well, I did it in stages, but yes. [10:30] persia: nobody said this change was perfect, it was required to win CD space and easy to do [10:31] seb128: Understood. Note my lack of complaint about it during the hardy cycle, and further that my request was that it was either dropped or documented. [10:31] persia: or you are welcome to suggest a better way which doesn't imply adding ubuntu specific changes to every packages on the CD [10:31] doko: #224110 for the java issue I mentionned yesterday [10:31] It's due to unionfs [10:31] Personally, I think a build-system hook is a better way to do it [10:32] what do you call "build-system hook"? [10:32] I agree with persia, but I fail to reconcile that maintainers want the changelogs shipped on the installed system and that the installed system is copied from the live CD [10:33] seb128: As an example, there could be a package that overrides dpkg-deb to strip /usr/share/doc/*changelog*/ when building binaries. [10:33] It would require network to e.g. reinstall the missing changelog files after a live CD install [10:33] persia: I though you didn't want to strip changelogs and now you want to do it for the whole archive, [10:33] ? [10:33] seb128: Only for CD builds I guess, as this is where we want to save space [10:34] seb128: I personally like changelogs. I understand they don't make sense for the CD. The current implementation of stripping in CDBS seems like a suboptimal solution to me. [10:34] persia: it is, as said it was easy and did the job [10:35] seb128: Sure. I'm not arguing the past decision. Only commenting as we're starting a new cycle, and this would be the time for such changes, if we wanted them. My main concern was that if we wanted to keep the changelog stripping in CDBS, it be documented in the CDBS changelog. [10:36] nobody argued against that and pitti said the he will do the change [10:36] I had the impression you were arguing against the change rather than asking to get it documented though [10:36] persia: already happened [10:45] pitti: have you seen http://liorkaplan.wordpress.com/2008/04/27/why-does-ubuntu-puts-firefox-transalation-in-gnomes-language-pack/#comments ? [10:45] (err, - #comments) [10:47] cjwatson: I didn't, looking [10:48] cjwatson: -gnome was actually a deliberate choice, since Riddell didn't want them on the Kubuntu CDs by default; the package description is indeed wrong, though; fixing in langpack-o-matic [10:49] there's a comment about upgrade path problems [10:51] it seems that we wanted the old m-f-locale-* packages to stick around for ffox2, instead of becoming transitional packages pointing to language-pack-gnome-XX [10:52] pitti: I can't speak officialy for Xubuntu, but a number of recent uploads have resynchronised on the Debian packaging, so it may well be on the way out. [10:53] james_w: I left it in for now [10:53] pitti: maybe they should depend on language-pack-gnome-XX as well [10:53] it's a bit ugly, but ... [10:53] at least it does upgrades 'more' correctly [10:53] asac: ^ WDYT? could be worth an SRU [10:54] pitti: whats the proposal? [10:54] Id love to move the translations to the real langpacks [10:54] asac: have m-f-locale-XX depend: on l-pack-gnome-XX [10:54] asac: to get an upgrade path [10:56] pitti: that would help upgraders, but not kubuntu users ... firefox is surely used by most kubuntu users as well. [10:56] asac: but that would DTRT for them? [10:57] cjwatson: I commented on the blog, thanks for the pointer [10:57] cjwatson: Did we enable the edd magic in the kernel by default for hardy? [10:57] asac: s/most/some/, but either way, if they install m-f-locale-XX on Kubuntu, they should get the langpack on upgrade to retain translations [10:58] cjwatson, doko: FYI, cdbs merged, tested, uploaded [10:58] any other quasi-toolchain packages which come to your mind? [10:58] make isn't significantly newer in Debian, that can go through auto-syncs === davmor2 is now known as davmor2_away [10:59] maybe autoconf/automake, I'll prepare python2.5 as well [10:59] ah, good point [10:59] both are syncs, though [10:59] so we can't hold them in unapproved; they should be synced after your toolchain bits built [11:02] soren: can't do so by default, but you can boot with edd=on to get it [11:02] soren: (it causes some machines to hang for a few minutes on boot, and I think may even cause some machines to fail to boot altogether) [11:02] cjwatson: Ok. I just noticed something about EDD fly by when I booted one of my machines. [11:03] pitti: yes that should do the right thing for upgraders. but given that most users likely indirectly installed m-f-locale-XX through language-support-XX i still think that the real bug is the -gnome demotion here. [11:07] pitti: Would it make sense to offer ddebs for ppas? [11:08] We use a ppa for ubuntu-mobile and I guess many development/testing happens in ppa; could be cool to have ddebs there too [11:08] lool: would certainly be nice, but it's (a) a question of storage space, and (2) a question where to process them [11:08] lool: I'd really like soyuz to support ddebs; the current hack is very brittle [11:08] and it's going to get much worse with more ddebs [11:09] * pitti sighs at apt-ftparchive being so ridiculously slooooooooow [11:09] macaroni.ubuntu.com is busy all day with updating the archive :/ (three runs a day) [11:10] pitti: apport doesn't work for me on mobile after I enabled it and rebooted it; I wondered whether amitk could check which bits wouldn't be enabled in the kernel, but he doesn't know which these are [11:10] pitti: Do you have the CONFIG_ flags in mind? Or perhaps we lack something [11:10] pitti: Let me guess - they're going to implement it post-2.0? [11:11] lool: it doesn't need anything particular from the kernel since 2.6.23 [11:11] amitk: ^ [11:11] wgrant: I don't know [11:11] amitk: So nevermind [11:11] pitti: What could explain that it doesn't save a crash on sigsegv? [11:11] lool: is apport set in /proc/sys/kernel/core_pattern ? [11:12] Yes [11:12] lool: I had no idea it ever required kernel support :) Learnt something new [11:12] lool: what does "/usr/share/apport/testsuite/test-apport kernel" say? [11:12] amitk: it did until feisty [11:12] * Check that empty core dumps do not generate a report [11:12] Traceback (most recent call last): [11:12] File "/usr/share/apport/testsuite/test-apport", line 174, in [11:12] assert app.wait() == 0, app.stderr.read() [11:12] AssertionError [11:13] /proc/sys/kernel/crashdump-size doesn't exist [11:13] Nor does it on my desktop though [11:15] lool: why should it exist? that's from edgy or feisty's Ubuntu kernel patch [11:15] lool: can you remove /var/log/apport.log, run the test again, and pastebin apport.log? [11:16] pitti: Nothing in apport.log [11:17] pitti: I just told you about /proc/sys/kernel/crashdump-size as I saw it pass while set -x-ing the apport init script; didn't know whether it was relevant or not [11:17] hm [11:17] lool: the init script just sets core_pattern [11:17] but the test suite complains if it isn't set, so that's fine [11:21] lool: what does this say? echo foo | sudo /usr/share/apport/apport $$ 42 0 [11:22] lool: erm, you can drop the sudo, sorry [11:23] apport (pid 5753) Tue Apr 29 10:23:06 2008: cannot create lock file (uid 1000): [11:23] pitti: Ok, owner/group issue with our user [11:23] pitti: thanks [11:25] pitti: Hmm actually the only difference in groups between my desktop user and the ume mobile user are powerdev and netdev [11:25] Hmm for some reason I see crashes in /var/crash now [11:26] pitti: Probably where you expected me to grab the log file I guess [11:26] lool: the log file is in /var/log [11:26] lool: ah, /var/crash was unwritable? [11:26] lool: powerdev/netdev are irrelevant, yes [11:26] pitti: I don't see a log file [11:27] lool: the command I gave you from above writes to stderr, not to a log [11:27] pitti: All it gave was that permission error [11:27] lool: right, so /var/crash/ is unwritable for you [11:27] lool: drwxrwxrwt 2 root root 4096 2008-04-29 12:22 /var/crash/ [11:27] ^ default in Ubuntu [11:28] (1777) [11:28] drwxrwxrwt 2 root root 4096 Apr 29 10:23 /var/crash/ [11:28] pitti: It's set by the init script [11:28] So should be ok here too [11:28] pitti: This is on unionfs [11:28] Should be similar to the live CD [11:28] lool: hm, what's wrong with /var/crash/.lock? [11:29] That one is root [11:29] -rwxr-xr-x 1 root root 0 Apr 29 09:59 /var/crash/.lock [11:29] pitti: it's rebuilding atm [11:29] lool: ah; please try to remove it [11:29] pitti: Shall I wipe it? [11:29] Sure [11:29] lool: otherwise the test suite and above command need to run as root [11:29] Keybuk: yay [11:30] apport (pid 6242) Tue Apr 29 10:30:23 2008: executable: /persistmnt/bin/cat (command line "/bin/cat") [11:30] apport (pid 6242) Tue Apr 29 10:30:23 2008: executable does not belong to a package, ignoring [11:30] pitti: Looks like an unionfs issue [11:30] pitti: Pathname is guessed wrong [11:30] Just like in #224110 [11:30] ah [11:30] I guess it's read from /proc [11:31] /proc/$$/exe symlink wrong then? [11:31] Is it working from Ubuntu live CDs? [11:31] lool: not 100% sure TBH [11:31] /proc/6231/exe: symbolic link to `/persistmnt/bin/bash' [11:31] Yes [11:31] lool: aah, it doesn't, but apport has a hack for this [11:31] if self['ExecutablePath'].startswith('/rofs/'): [11:31] self['ExecutablePath'] = self['ExecutablePath'][5:] [11:32] apport/report.py ^ [11:32] pitti: Too bad we don't use the same name for the mountpoint :-/ [11:32] lool: you can try changing report.py locally for the /persistmnt/ prefix [11:32] pitti: Also, packages which be installed afterwards, you should also allow the casper / rw one perhaps [11:32] pitti: it was killed by the debian ftp-master problems a while back [11:32] and it takes a while for bad data to leave it's head [11:33] apostrophe! [11:34] cjwatson: coffee! [11:36] pitti: So what would you think of apport parsing /proc/mounts looking whether / is unionfs and extracting the dirs= attribute from there as a list of prefixes to optionally strip? [11:37] lool: I think it'd be a nasty workaround for an unionfs bug :/ [11:38] I agree unionfs shall be fixed; I added a tasklet to this effect on the bug I mentionned earlier but TBH I'm not holding my breath [11:39] right; in the meantime, it's less intrusive and more robust to add particular prefix special cases to report.py IMHO [11:39] especially if we want to SRU this [11:41] What's the read-write partition on live CDs? /rwfs? [11:45] seb128: hm, re gphoto fs etc, why don't we get a fuse mount for gvfs virtual file systems like gphoto? eog, gthumb, CLI etc. could use that fuse mount then [11:46] seb128: (context: gnome bug 530371) [11:46] Gnome bug 530371 in general "fails to open pictures on gphotofs" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=530371 [11:46] lool: /rofs [11:46] err [11:46] sorry, misread. it's /cow but in practice not usually accessible as such from outside the initramfs [11:46] unless you boot with showmounts [11:47] cjwatson: Wont programs installed from the live CD return pathnames below /cow in /proc/self/exe? [11:48] maaaaaaybe [11:48] * cjwatson would not like to make bets without testing [11:48] I think so, as it happened to us in the UME unionfs [11:48] in any case I meant not usually visible as a mount point in the filesystem; I wasn't arguing with the /proc/self/exe problem [11:49] Thanks for the pathname [11:54] pitti: Could you check lp:~lool/apport/ubuntu from an apport upstream perspective and then as a SRU candidate? It now passes the kernel testsuite for me [11:54] (still pushing though) [11:54] cjwatson, depends .... [11:55] lool: can you also run the entire test suite? [11:55] /usr/share/apport/testsuite/run-tests [11:55] (pushed now) [11:55]