=== bdefreese2 is now known as bddebian === astechgeek is now known as techgeek === nigel_nb__ is now known as stackedagainst [02:50] evening hggdh :) [02:51] evening stackedagainst [02:52] oh, its me nigel btw, just another nick [02:52] ;) [02:52] ah :-) [02:52] I still haven't got around to that PPA thing [02:52] but looks like there is a ppa bug filed [02:52] which one? [02:52] bug 497562 [02:52] Launchpad bug 497562 in digikam "On newest PPA beta (KDE 4.4beta1) digikam crashes every time at startup" [Undecided,New] https://launchpad.net/bugs/497562 [02:53] is that part of any announced testing? [02:53] not to my knowledge, but I do not follow KDE [02:54] the PPA name suggests a semi-official (or official) KDE PPA [02:55] does this response look okay? "Thank you for reporting this bug. As per the bug squad policy, this bug is being set to invalid but marked as a PPA bug. Please do not hesitate to report any other bug you may find. Thanks" [02:55] yes, it is -- https://edge.launchpad.net/~kubuntu-ppa [02:55] stackedagainst: hum [02:56] hold on [02:56] ok [02:56] let's try first to contact one of the dev in the PPA [02:56] #kde-devel? [02:56] nhandler: question on the kubuntu-ppa [02:57] seems to be away :( [02:57] #kubuntu-devel probably [02:57] The kubuntu devs use a stack of PPAs for testing stuff prior to upload, and may want to take action on the bug [02:57] stackedagainst: persia suggestion is good -- want to try there? [02:57] hggdh: will do [02:58] persia: this is what I was considering, after looking at the member list [02:58] (it's an invalid bug, but no reason not to highlight it to interested parties just because LP doesn't allow bugs against PPAs) [02:58] there you go [02:58] persia: it seems more and more like a valid bug [02:58] stackedagainst: Certainly a valid bug. Not a valid Ubuntu task unless uploaded to Ubuntu. [02:58] But that's just semantics, and having the Ubuntu task is a workaround for no-bugs-against-ppas [03:00] true, but this bug came to be after enabling the PPA [03:01] so it IS a ppa [03:03] Right. [03:03] but my doubt is, is it official enough to be *not set invalid* [03:03] hggdh: You had a question? [03:03] So, it's a bug in a package in a PPA. Therefore, the "Ubuntu" task is invalid. [03:03] *but* [03:04] That specific PPA happens to be used by the kubuntu developers. [03:04] which can be considered official? [03:04] As a result, if they don't see (and fix) it, the task will become valid when it gets uploaded. [03:04] What PPA ? [03:04] It's a gray area. [03:04] nhandler: bug 497562 [03:04] Launchpad bug 497562 in digikam "On newest PPA beta (KDE 4.4beta1) digikam crashes every time at startup" [Undecided,New] https://launchpad.net/bugs/497562 [03:04] nhandler: ~kubuntu-ppa [03:05] which means we have the long task of tracking down the devs and informing them when its an official ppa [03:05] persia: ^^ [03:05] There's no such creature as an "official PPA". [03:05] There's no means of indicating officialness for PPAs. [03:06] by definition, yes [03:06] I re-phrase [03:06] persia: ppa of a big ubuntu team :) [03:06] But the guys in #kubuntu-devel tend to be fairly responsive. I'm somewhat surprised you haven't gotten clarity in preferred handling there in this amount of time. [03:06] s/guys/folk/ (apologies) [03:07] persia: apparently, they can take bugs on PPA [03:07] I personally would consider this more of a limitation of LP. Many teams use PPAs as a way to get users to test their packages. However, LP currently does not provide a good way to give the feedback [03:07] I completely agree. [03:08] I think that LP *should* support bugs-on-ppas [03:08] nhandler: no questions there. I have tried, before to get a way of making PPA more official, but... failed [03:08] But without that it gets fuzzy. There's no easy well to tell if a given PPA represents something that will be uploaded to Ubuntu. [03:08] and not always the PPA is indicated in the bug [03:08] hggdh: I'm actually somewhat against making PPAs "official". [03:09] apparently, the kubuntu-ppa CAN take bugs :) [03:09] They are what they are, but when they have bugs, we need a way to communicate that to the users. [03:09] stackedagainst: Um, except LP doesn't offer a way to create those bug tasks. [03:09] persia: so am I. But we need a middle term [03:09] stackedagainst: So you're just talking about a specific social workaround to the technical problem. [03:09] persia: See #kubuntu-devel, I guess they got around to creating a project for it [03:10] persia: stackedagainst: We have a kubuntu-ppa project that takes such bugs, just move it there. [03:10] hggdh: So, when should something be in an "official" PPA that shouldn't just be in Ubuntu ? [03:10] stackedagainst: Ah, that's an interesting workaround :) That's not the PPA taking the bugs, that's just a confusingly named project taking bugs related to the PPA :) [03:11] persia: oh, sorry, my lack of knowledge [03:11] so u're right [03:11] I don't think we need "official" PPAs. The credibility of the PPA comes from who is maintaining its packages. I think the true solution is to be able to file bugs against a PPA [03:11] persia: its a a social work around to a technical problem [03:11] nhandler: +1 [03:12] nhandler: indeed. And this would (perhaps) solve part of the issue -- triagers would not look at them, only the PPA members [03:12] nhandler: Absolutely. [03:12] * nhandler goes to see if a bug has been filed requesting this functionality [03:12] hggdh: Well, there could exist triagers for the PPA, but at least Ubuntu triagers wouldn't have to deal. [03:13] what worries me is we are giving more and more emphasys to PPAs -- correctly --, and we still lack a way to effectively deal with them [03:13] persia: I am assuming that, by definition, the PPA members are the triagers [03:13] hggdh: the Ubuntu task in this case is invalid, right? [03:13] stackedagainst: Yes [03:14] thanks nhandler :) [03:14] hggdh: Well, depends on the size of the team. Same as in Ubuntu, not everyone is currently a triager :) [03:14] heh. And same as Ubuntu, they will lack triaging resources [03:15] Some of them, yes. [03:15] Ah, bug #179873 [03:15] Launchpad bug 179873 in malone "Can't report bugs on PPA packages" [Undecided,Triaged] https://launchpad.net/bugs/179873 [03:16] persia: Your LP bug searching skills are better than mine ;) I was still searching [03:16] yes, old one. Been subscribed to it for quite a while [03:16] nhandler: inside tip, use google rather Lp search ;) [03:16] stackedagainst: I was ;) [03:16] Actually, I got that quickly by searching for "PPA" on malone bugs. [03:17] Hmm...It looks like it fell off of their radar [03:17] Well, there's #launchpad :) [03:18] For that matter, there's code, if someone wants to do it. [03:18] But I have a suspicion that the semantics are somewhat complicated, and that they would probably suggest a fix to 245183 as a way to solve the issue (as was done with the kubuntu-ppa project) [03:21] Well, I know that they are going to be adding functionality to link a bzr branch revision to a PPA package (and make it easier to build a package that is stored in bzr). Hopefully, we can get this bug on their radar (as they will probably be more likely to fix it while they are working on the new ppa functionality) [03:22] * nhandler will try talking to a few people tomorrow about it [03:22] I suspect you're right. [03:22] thanks, nhandler, help is appreciated on this [03:24] hggdh: is bug 497490 a GTK bug? Isn't it a pidgin bug? [03:24] Launchpad bug 497490 in gtk+2.0 "Pidgin crashed with SIGSEGV in gdk_pixbuf_loader_eat_header_write()" [Undecided,New] https://launchpad.net/bugs/497490 [03:24] OR reported against GTK, I added pidgin. Is it okay to close the GTK task? [03:25] There are two bugs represented by that stacktrace [03:25] GTK shouldn't segfault, and pidgin shuldn't segfault. [03:25] so leave both of there? [03:25] Writing a small test program for an upstream GTK task would be awkward. [03:26] But upstream pidgin *rejected* the bug (see http://developer.pidgin.im/ticket/10990 ) [03:26] so there's no point in adding a pidgin (Ubuntu) task unless someone is going to write a local patch [03:26] aw :( why dont I READ [03:26] So, I'd recommend leaving it alone. [03:27] If you're up for doing the work to isolate the condition, and submit the upstream GTK bug, it's worth an upstream GTK task. [03:27] persia: I'm not that good with programming [03:27] Alternately, if you're up for doing the work to make pidgin not trigger the GTK bug, it's worth adding a pidgin (Ubuntu) task. [03:27] Fair enough :) [03:28] Point being that I don't think it's worth opening tasks when we don't have the information that would be required for someone to action them. [03:28] but a bt is good enough? [03:28] well, we need the versions, anyway [03:28] do we need an apport-trace? [03:29] We don't need an apport trace. The attachment is enough. We would benefit from information about the architecture, language, versions of pidgin and gtk, etc. [03:29] The bug needs lots of triage, just not new tasks :) [03:29] okay, so what all do I ask? [03:30] and the variables values at top-of-stack are quite interesting [03:30] e.g., len and buf [03:31] That's probably the source of the crash. [03:31] and len is under a pidgin function call... [03:31] buffer-overflow or soemthing. [03:32] certainly. I do not think there is a system with that much memory running pidgin (or running at all) [03:32] Well, could be a sparse buffer, or could be *very* heavily swapped. [03:33] But more likely to be an arithmetic error of some sort, or issue with type conversion. [03:33] (in pidgin) [03:33] yes [03:33] Still, IA__gdk_pixbuf_loader_write() shouldn't have crashed :) [03:34] Should just return some error condition reporting that it failed to load the buffer. [03:34] a library should never crash [03:34] Well, maybe. [03:35] In general yes, but it might be better to crash than to hang, if those are the only available choices. [03:35] (just because a crash tells the user something) [03:35] But that comes down to API design: one has to remember to ensure there is a way to report error conditions. [03:36] And some libraries *define* that mechanism as various sorts of crashes. [03:36] And expect the client to trap the crash and handle the condition (which is OK, as long as it's documented) [03:37] there I completely agree with you [03:37] For example, there's a function in OpenAL which is supposed to return a pointer to a structure that manages the audio output interface. [03:37] When OpenAL can't allocate such an interface, it crashes. [03:37] But callers are expected to then try alternate ways to initialise the interface. [03:38] Otherwise, the function would have to either allocate an invalid struct containing error information (which is awkward because the struct is populated based on investigation of the allocated device) [03:38] OR, the function would have to store an error condition in some address passed by the caller, and the caller would need to check. [03:38] Lots of languages even formalise this as "Exception Processing". [03:39] which I personally think is better [03:39] (the error condition being returned) [03:39] Personally, I prefer exceptions, but it doesn't really matter, as long as it's documented. [03:39] have you guys noticed evince making changes in the formatting of a pdf? [03:40] if you are talking to exceptions like in python (or, -- ugh -- java), yes [03:40] stackedagainst: no [03:40] not that many PDF opened lately [03:40] hggdh: Same thing. But the way exceptions are done in C looks exactly like a crash if the caller doesn't implement an exception handler :) [03:40] hggdh: bug 497175 [03:40] Launchpad bug 497175 in evince "This program do not read every pdf files. I can send an exemple. Give me an adress." [Undecided,Incomplete] https://launchpad.net/bugs/497175 [03:41] the screenshots of the same file in a different reader has some difference [03:43] hggdh: how do I add a tag? [03:43] I wanted to add a PPA tag to the earlier PPA bug and I couldn't :( [03:43] are you running 9.10? [03:44] yep [03:45] to add a tag -- click on the exclamation point to the right of the list of current tags === nhandler_ is now known as nhandler === asac_ is now known as asac [05:44] micahg: something is wrong with 5-a-day stats! , I joined the team only yesterday , but it seems to check user history too... yay , i ousted you from the second position ;p [05:45] mac_v: nice [05:45] hehe ;) [06:55] What might cause my screen to freeze and then fuzz up and reset my visual effects? It happens all the time. [06:56] echotone: Hi, if you're looking for support, please ask in #ubuntu, its the main support channel :) [06:56] i have been waiting for 15 minutes for a reply in that channel. [06:56] it sounds like a bug to me..i thought i would try [06:57] does it sound like anythng you would know? [07:04] maco2: any idea about ^^, I'm not friends with X :( [07:04] im not friends with X either. im flatmates with alsa :P [07:05] haha [07:05] dtchen: fixed your alsa btw? [07:05] oops, that came out wrong [07:05] maco2: did daniel fix your alsa [07:06] whats with the 2 nicks anyway [07:06] nah, its not alsa thats the issue. i have consolekit/policykit brokenness (my fault). but new laptop is back so once i swap hard drive back over and reinstall with amd64 and put the proper hard drive back in this one, itll all be good [07:06] I did unbreak it, however. [07:06] maco is on a quassel core which is having network issues, so i cant reliably reach it. im on irssi right now [07:07] hah yes [07:07] you did point out that i had no pulseaudio config file [07:08] maco2: that reminds me, I need to start my alter ego up [07:15] good morning bugsquad === Adri2000` is now known as Adri2000 === etali1 is now known as etali === YoBoY` is now known as YoBoY === ogra_ is now known as ogra [10:20] Is Nautilus responsible for drawing the background of the desktop as well? [10:22] qense, yes [10:22] why? [10:22] if it's running [10:22] g-s-d can do that too [10:23] There are a few people having problems with the slidehsow. It gets stuck after a while, with two backgrounds loaded over each other. [10:24] it's bug 472793 if you're interested [10:24] Launchpad bug 472793 in nautilus "GNOME background being imposed on another background" [Low,Confirmed] https://launchpad.net/bugs/472793 [10:24] I wanted to file it upstream to ask what they think of it [10:25] ok [10:25] I'll dig a bit further into the matter. === mac_v is now known as _ === _ is now known as _7hills === _7hills is now known as mac_v [10:53] Against what should bugs regarding security.ubuntu.com and other archives? [10:53] be reported [11:03] qense: What class of bug? Like "this mirror isn't working" or like "this security update is corrupt"? [11:03] persia: no IPv6 support for security.ubuntu.com [11:04] Hrm. I'm not sure about that at all. [11:04] You might try asking in #ubuntu-security to see if they know. [11:04] But it might be the sort of thing that needs an RT rather than a bug. [11:05] maybe indeed [11:05] anyway, I'll ask there. thanks! [11:05] Best of luck! [11:05] the channel is invite only! === c0p3rn1c is now known as copernic [11:48] qense: re: the PPA trend. I think that whereas before lots of people would spend time trying to get things into Ubuntu, now time is spent making it work in a PPA. [11:50] It gets less centralised, maybe. More from PPAs. less from the repository. It would be a shame if it would become the de facto default practise, but it has positive sides. [11:50] I'm not certain it hasn't become the de facto default process. [11:50] persia, qense: There already is an RT about ipv6 security.ubuntu.com and LP bug. [11:51] PPAs became popular around hardy [11:51] and we have *tons* of packages that we're planning to drop from Ubuntu because nobody looked at them since hardy. [11:51] jpds: where is it? In that case I'll mark the bug I mentioned as a dup. [11:51] But I remember that in gutsy and hardy, lots of people were trying to learn the Ubuntu processes just to get their apps into Ubuntu [11:51] I don't see that as much anymore. [11:52] putting it into a PPA is easier than getting someone to sponsor you to get it into main or universe. [11:53] RIght. [11:53] qense: bug 241305. [11:53] Launchpad bug 241305 in update-manager "security.ubuntu.com not accessible in IPv6 (AAAA record missing in the DNS)" [High,Invalid] https://launchpad.net/bugs/241305 [11:53] jpds: thanks! [11:53] But that means that fewer people are trying to maintain main and universe, which makes it harder, and we go into a spin. [11:53] Anyway, back to trying to ignore PPAs :) [11:55] don't let it get you down! [11:56] qense: As far as I understand it, there are no plans to introduce IPv6 support any time soon. [11:56] ok [11:56] I'll add that to my reply [11:56] where can I find the request tracker, actually? I never heard of it before. [11:57] rt.ubuntu.com - nothing terribly interesting there. [11:58] ok, thanks === ikonia_ is now known as ikonia [14:04] I'm afk, going to do some snow removal. === jamalta_ is now known as jamalta [15:40] Boo [16:27] hggdh: I've got another bug requesting to disable bash aliases for sudo and his friends like the bug #127116 you handled previously. (I'm talking about bug 368054.) What would you suggest to do with it? It's a bit more sensible than the one you did, but would banning aliases with the names of sudo, gksu, etc be a wise decision? [16:27] Launchpad bug 127116 in ubuntu "getting the root password through .bashrc and a fakesudo" [Undecided,Invalid] https://launchpad.net/bugs/127116 [16:27] Launchpad bug 368054 in ubuntu "privilege escalation by su/sudo/gksu/kdesu alias" [Wishlist,Confirmed] https://launchpad.net/bugs/368054 [16:28] qense: looking [16:29] qense: still opening the bugs, but -- generically -- prohibiting some alias is, in my view, of limited value [16:29] qense: about bug 490001, it seems like the user isn't restoring their previous X session with hibernate, but effectively shutting down, that's why I reassigned away from firefox per comment #5 [16:29] Launchpad bug 490001 in docky "Can't drag Network Manager plugin" [Wishlist,Confirmed] https://launchpad.net/bugs/490001 [16:30] oops, bug 492001 [16:30] Launchpad bug 492001 in firefox-3.5 ""Well, this is embarrassing" message appears often after shutdown and hibernate" [Low,Incomplete] https://launchpad.net/bugs/492001 [16:33] hggdh: slow internet connection? :S [16:33] qense: *very* slow, but finally opened both [16:34] good [16:34] micahg: OK, so it's actually an invalid bug? [16:34] qense: no, there's an issue with hibernation I think [16:35] qense: it is pretty much the same as the old bug -- someone took control of a logged in session, and added a trojan. End of story, the mechine is not yours anymore. [16:35] micahg: the hibernation issue *is* a security issue, and the consequence might be as described in the bug [16:36] hggdh: I was referring to the bug I mentioned, not the one you were previously discussing :) [16:37] I agree in general that prohibiting aliases is of limited value, although part of me thinks it is kinda too bad it su* commands were exempted from aliases since the beginning of time. I guess we need to start an education campaign that people wanting to trust their su* or pgp/gpg commands need to use a prefix (either \ or "command"). [16:37] hggdh: but if you get the user to execute something, like what happened with the infected screensavers at GNOME Look recently, and that thing edits the .bashrc file to point sudo to something malicious and then just installs the screensaver normally, then we'd have a security leak. We'd better make it as hard as possible to infect systems. [16:37] weren't [16:38] but indeed, prohibiting certain aliases may not be the best solution [16:41] qense: Yep. You remove the ability to alias certain commands, and the war will simply escalate to replacing /usr/bin/sudo or gpg. It comes down to two things: don't install untrusted software, and don't leave your computer unsecured. [16:42] I'll mark this as a Won't Fix then, mentioning the Ubuntuforums.org thread and the fact that we've had a small discussion about it to let him know we take his concerns seriously. [16:45] done. mrand, hggdh: thanks for your input [16:46] I started thinking of other ways to solve this, and there isn't one. It ends with Ken Thompson's "Trusting trust" concept. [16:48] If you can't trust anything anymore, everything's lost. ;) [16:48] Hehe. [16:48] ;] [16:53] qense: yeah, if you take this to its logical conclusion, you are correct - and that was his point. If you didn't write (from the compiler all the way up to the web browser and sudo), then you can't TRULY trust it. But for the sake of productivity, we have to. The question is where you draw the line on what you trust and what you don't. [16:54] We don't all have the time to run Gentoo and read all source code thoroughly before installing the software; we just have to trust the Ubuntu Developers that if I enter my bank account data on a web page in Firefox that they won't be stolen. [16:55] I do trust them [16:55] fortunately [16:56] there is a point here, but I am not sure how valid: critical security applications should check arg[0] to be the path they were supposed to be installed [16:56] but this would not solve a trojan, or keylogger [16:57] qense: please also mention bug 127116, since we have there a nice explanation [16:57] Launchpad bug 127116 in ubuntu "getting the root password through .bashrc and a fakesudo" [Undecided,Invalid] https://launchpad.net/bugs/127116 [16:58] I did [16:59] cool, thanks. I do think this should be more widely discussed, though. The alias approach is not good (and there are, as mrand pointed out, ways to bypass aliasing), but... I wonder... [17:00] What about raising the issue on a mailist? [17:01] yes, or bringing it to the #ubuntu-hardened [17:02] also there is another point -- the OR states 'alias ChangeUser='sudo su - user' is not a security issue. This is wrong. It is the *same* issue -- I would then (probably) have the logged-in user's password [17:02] during busy times an IRC channel would probably be a better medium since it allows direct responses, which is useful in a discussion of thsi kind [17:03] yes [17:03] want to get there now? [17:03] alright with me, I'm there already [17:03] just joined [17:04] Sorry, I'm overloaded as it is... I'm interested to hear the "conclusion". [17:05] (if there is one ;-) [17:06] heh. I do not think there will be one [18:23] bdmurray: I need a recommendation for something [18:23] https://bugs.edge.launchpad.net/ubuntu/+source/brasero/+bug/497853 [18:23] Launchpad bug 497853 in brasero "Support application indicators" [Undecided,New] [18:23] I need to file a bug for each affected package [18:24] is there a CLI way to do this so I can do it faster? ubuntu-bug isn't what I want, it's ...? [18:24] jcastro: okay and? === yofel_ is now known as yofel [18:24] well I imagine you could file the bug via e-mail or using launchpadlib [18:24] the tag, assignee and description will be the same for all of them [18:25] ooh, email, good idea [18:26] probably the easiest since I don't know of any lplib bug filing stuff [18:30] bdmurray: oh man, this is great. [18:32] jcastro: I'm disappointed that you are more bugs to the bug tracker though [18:32] adding [18:39] bdmurray: don't worry, they're assigned already! [18:40] xango,Haggadah [18:41] bloody hell [18:41] there goes my passphrase :-( [18:42] well, changed [18:50] It better be to something with letter(capitalises and non-capitalised), numbers and special characters! [18:55] qense: But be selective with your special characters, because some apps don't escape things! [18:56] indeed! I remember a bug in PolicyKit, disallowing anyone with a special character to unlock the GNOME settings. [18:56] (it was fixed) [18:59] well, it was -- a comma *is* a special char ;-) [18:59] There are a bunch of corner cases like that. For instance, gnome-screensaver is very restrictive about the sorts of characters one can enter to unlock the screen. [19:00] yes, since most of the times this is developed by the application/package [19:01] there should be a common lib/API for imposing passwords rules (yes, and I know this will never completely happen) [19:02] but there should be indeed === YoBoY is now known as sn === sn is now known as Guest15893 === Guest15893 is now known as YoBoY [19:59] well, there was PAM... [20:01] s/was/is/ [20:01] * David-T wonders why he thought pam was replaced [20:16] somewhere, lingering around [20:16] where do i submit a bug related to webcam? [20:16] idea! I propse... * tam, tam * AuthenticationKit [20:16] yoasif: what is the problem with your webcam? [20:17] (ie the cam worked fine in karmic, not working in ludid) [20:17] it's not detected anymore? [20:17] well, not sure about that, it doesn't work in cheese qense [20:17] could be caused by the transition from HAL to DeviceKit [20:17] qense, the device seems to be detected in preferences [20:18] (in cheese) [20:18] but i am not getting an image [20:21] yoasif: at first I would file a report against the kernel, 'linux', and provide sufficient details, maybe a screenshot of the situation in Cheese as well. I'd suggest to report the bug with the command 'ubuntu-bug linux' with the webcam connected (and if necessary, turned on) because that will generate a report with a lot of details. [20:22] qense, sure, it's a built in webcam, so im hoping it turns on when cheese is open [20:23] ooh, apport is recommending i try with the upstream kernel [20:24] really? That's new to me. :P [20:24] What does it exactly say? [20:24] yeah, new here too [20:24] Testing the upstream kernel can help isolate issues in Ubuntu kernel patches, discover a bug is fixed upstream, or confirm the issue exists upstream. Would you like to test the upstream kernel first before reporting this bug? [20:24] For information on testing the upstream kernel, refer to https://wiki.ubuntu.com/KernelTeam/MainlineBuilds [20:25] ill have to grab the mainline kernel before i submit a bug i guess, to provide a better report [20:25] you're running Lucid? [20:25] wait, i can't even do that [20:25] yeah [20:26] in that case you probably won't notice a bit extra instability ;) [20:26] but updating the kernel to something more unstable is not without risks [20:26] what's the output of uname -a on your system? [20:27] 2.6.32-8-generic #12-Ubuntu SMP Sat Dec 12 12:54:44 UTC 2009 x86_64 GNU/Linux [20:27] not sure which 32 kernel to get http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D [20:28] I suppose you could try http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32/ [20:29] rc8 is newer [20:29] and im guessing that is what i am running -- with ubuntu patches [20:30] well, in that case Apport could be wrong [20:30] worth a bug report? ;) [20:30] well rc8 is on the server http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc8/ [20:30] so im wondering if i should just try it with that [20:31] you could ask in #ubuntu-kernel -- that is the right channel, isn't it? -- for help [20:32] thanks, asking there now [20:33] yw [20:36] qense, ok the answer is -- use the .32, not rc8 [20:36] good [20:36] in case anyone else wants to know :) [21:31] What source package is responsible for generating/maintaining /etc/fstab? [21:33] qense: it doesn't seem to belong to any specific package in the dpkg DB [21:35] yes, that was the problem I had [21:35] qense: mount has an example file [21:35] util-linux seems to be it :) [21:36] micahg: OK, I'll change the bug package to that. Thanks! [21:55] qense: Which bug? [21:56] bug 480147 [21:56] Launchpad bug 480147 in util-linux "/etc/fstab mentions vol_id but that has been replaced by blkid" [Low,Triaged] https://launchpad.net/bugs/480147 [21:56] persia: it was about the comment in /etc/fstab pointing to the wrong command [21:59] I have a suspicion that the fstab is written by the installer [22:00] i turned wlan off in ubuntu and it cannot be turned back on. what can i do ? i am working on emachines notebook [22:01] persia: that would mean it would either be a Ubiquity bug, or -- if it works fine on new installs, but we want it to be corrected on upgrades -- an Update Manager bug [22:01] Is there a problem with signature verification failure in 9.10 .iso's? I've tried several versions and they all seem to have the problem [22:02] Catty: Which error do you get? [22:02] qense: We *really* don't want to have any programs touching /etc/fstab post-install. It's more likely to break stuff than help. [22:02] a debootrape creats an enpty fstab with: # UNCONFIGURED FSTAB FOR BASE SYSTEM [22:02] deboostrap [22:02] grrr, empty [22:03] Right, which it should. [22:03] without comment? [22:03] trying to install additional packages from the cdrom "E: Sub-process gpgv returned an error code(2)" "W: Signature verification failed for: /cdrom/dists/karmic/Release.gpg" [22:03] without comments [22:03] ok, thanks [22:03] Hrm? [22:03] It does have a comment. "# UNCONFIGURED FSTAB FOR BASE SYSTEM" [22:04] I meant the comment mentioning the vol_id --uuid versus blkid command. I could have been more clear ;) [22:05] qense: Check the changelog for partman-target 64ubuntu1 : it's already fixed for new installs. [22:05] (that was during karmic) [22:05] persia: I just wanted to check that, thanks! In that case the bug is Invalid. [22:06] Well, I think so, because I think it's more dangerous to progamatically monkey with /etc/fstab post-install than to expect users to read the manual or ask for help if something goes wrong. [22:06] vol_id doesn't exist anymore anyway, so they can't blow their systems up with it [22:07] But, do the UUIDs get transformed into blkids by some program on upgrade? [22:07] If so, that program ought to be changing the note as well. [22:07] If not, it doesn't matter. [22:07] There's probably lots of users in the awkward state, but I don't think it's worth fixing except in the case where someone is upgrading. [22:08] Which will be the case with the new LTS, we'll get users from Dapper and Hardy, which still have vol_id (or something older for Dapper?). [22:10] Good point. [22:10] jpds - any clue? as I said I get it with multiple cd attempts [22:10] I'll check the upgrade process before changing the bug status [22:12] qense: I don't see anything useful in `grep fstab /var/lib/dpkg/info/*` : I'm not sure what does that. [22:13] (or even if anything does) [22:15] If LP won't OOPS too often I'll dig through the code of the upgrade process to see if there is a hook for it. [22:19] I give up for now, LP won't load. Tomorrow is another day! I'll look again then. persia: thanks for your input [22:20]