=== mcasadevall is now known as NCommander [06:08] http://pastebin.com/m54650694 [06:08] That error gets written to /var/log/messages constantly until my root drive is filled. [06:09] What does it mean for the 'swapper to be tainted' [06:09] ? [07:12] google is my friend [08:56] lukehasnoname, swapper isn't tainted, the swapper is running when the error occured. your kernel is tainted 'P' meaning it has proprietry binary blobs loaded into it [10:19] hi, will a sync(2) call cascade to the ATA layer so that the disk write cache is also flushed? [10:45] i thought that most ata drives were write through anyhow? [10:45] [ 151.346413] sd 8:0:0:0: [sdc] Assuming drive cache: write through === mcasadevall is now known as NCommander === doko__ is now known as doko [15:53] so pgraner_lt, apw: want to talk about where we put suspend/resume reports in launchpad? [16:13] sconklin, hi [16:13] apw: good afternoon. [16:13] i would think directly onto the linux package, with a tag of something like suspend-resume or something [16:13] moin [16:17] apw: the choices for reporting things against the kernel are Oops or panic - I should be able to get it to report as an oops with the special tag. It appears (after chatting with Leann) that apport oopses get tagged with "apport-kerneloops" and there aren't many bugs tagged with that. With an additional tag, it might be enough to manage work flow. [16:20] I'll cobble that in, test it, and mail the script around [16:21] sconklin: there is currently a "suspend" tag being used in launchpad so I'm not sure if you'd want to use that [16:22] sconklin: https://edge.launchpad.net/ubuntu/+bugs?field.tag=suspend [16:22] ls [16:23] sconklin, what limits us to oops and panic? those presumably are things in apport land? [16:24] i thought the point was it was very extensible, 'a few lines for a new report' [16:25] apw: yes. There are a few basic types of reports you can make. But - I'm looking at this now. The docs says you can make a report that's a generic "Bug", but I don't see support for that in the apport source. I'm going to do more looking and some experiments. [16:26] cool, i have got petes modified version of the sleep script and am going to merge that down tommorow with mine [16:26] and send it out to us all for testing [16:26] apw, sconklin: I was going to start tagging existing bugs about suspend or hibernate with their respective "suspend" and "hibernate" tags launchpad since those tags are already being used [16:26] ogasawara, sound plan in my mind, as those two are in use [16:27] is there also a resume one? [16:27] hrm, lemme check [16:27] apw: there is - https://edge.launchpad.net/ubuntu/+bugs?field.tag=resume [16:28] and can we check for all three at once? as long as we can do that we ahve the 'suspend-resume-broken' set [16:28] * sconklin needs to see how tags get set in bugs reported by apport [16:28] i would hope there is a tag entry in the python dictionary [16:29] * apw watches christmas creep up on him, yeeks [16:29] tags are set in the launchpad back end, not sure they're exposed in the UI - but I'll find a way :) [16:30] sconklin: I use python-launchpad-bugs [16:30] sconklin: I also think the new launchpad api will probably allow it, although I haven't done any testing with it [16:31] this needs to be on the user end, in apport tho [16:35] right, I meant on the apport end. [16:35] but I'll eventually end up on the other end too. [16:38] apw: you can check for multiple tags for ex https://edge.launchpad.net/ubuntu/+bugs?field.tag=suspend+resume however, that will show bugs tagged "suspend" || "resume" [16:40] tags are set automatically in the apport backend for launchpad from a small set, and aren't exposed from the reports. [16:43] ogasawara, or is what we want, any of the above [16:43] sconklin, well thats a bit pants isn't it? [16:43] apw: cool, then we're good [16:45] apw: this is all fun stuff to learn about, too bad it's due yesterday. :) [16:45] heh [16:45] we're not in _that_ much of a hurry [16:46] apw: I had hoped to at least have a firm plan before the break, but at least I know we can do it with the tools we have. [16:51] yeah [16:51] have you managed to report any bugs yet? [16:53] apw: well, I sent one up, and it vanished. I think it failed to get into launchpad because (for reasons I don't understand) it was reported against the linux-meta package. [16:53] heh, going to be a battle for sure [16:54] apw: I'm adding code to include the tags as a test, then I'll try again. It depends on whether launchpad will process multiple "Tag" tags in the mime data. [16:54] ah ok [16:54] * apw gets a reminder for his cancelled meeting [16:54] noting that the reminder even has cancelled in the text of the reminder!?! [16:55] Leann suggested reporting against staging.launchpad.com, but the URLs are hard-coded in the apport back end. I think I'll talk with pitti about that when he returns after holidays and submit a patch [16:55] yeah sounds like there is abunch of work needed on apport as well [16:56] sconklin: not a big deal to me if you can't use staging for testing purposes - I can ignore test bugs. [16:56] In general, I think it's really well written, we just want to extend it in ways pitti didn't think about [16:57] ogasawara: ok, thanks. If I can get arbitrary tags in there, this will be no big deal. [16:58] in this test script, every report also has a tag "Aattention: 'This is a test of apport report generation, please delete and do not process'" and "Originator: (me)" [16:58] Aattention is misspelled on purpose, to drive it to the top alphabetically [16:59] heh [17:03] sconklin, so are you going to expose the tags to the drivers here? [17:03] ie allow the report to add tags directly? [17:06] it looks like a two line patch to expose tags i think [17:06] apw: That's what I'm studying the code to test now. Using existing apport UI, I can add a second "Tags" to the mime info that's sent up during the launchpad submission. I can't add tags to the existing place where they're written. It will work as long as the launchpad end handles more than one "Tags". [17:07] Hi, does anyone know about the em28xx driver here? [17:07] if not we woul djust need to fix the apport to hdr['Tags'] += report.get('Tags') sort of thing [17:07] mrec, what you want to know about it? [17:07] maybe a solution should come up for ubuntu, the kernelstuff is just a mess and there won't be any official manufacturer support for it for some reason. [17:08] well there are 2 drivers available now [17:08] one which supports most devices and one which won't ever have support for the latest devices [17:08] I was providing debian packages for ubuntu for a while now [17:09] so what is wrong with the kernel as it stands, offering the wrong one of the two drivers? [17:10] yes they'll go their own way without official support. [17:11] I gave them the possibility to use the fully supported driver, but the v4l maintainer wants to go his own way [17:11] so I won't contribute to the linux kernel anymore. [17:11] thats a shame [17:11] some companies who we work with don't want everything opensourced anymore either. [17:12] well it's linux I acknowlidge it. [17:12] then they are going to find they can't offer their devices on netbooks and the like, so i guess people will have to use different hardware, their loss i guess [17:13] there are not that many possibilities available out there [17:13] and that company is likely market leader [17:13] main business is done with windows and OSX right now anyway [17:13] indeed, but if we can't use 'em then we can't use 'em, its not like we have a choice without a driver [17:14] so until it hurts them in the pocket book we have no pressure to put on them [17:14] it won't hurt since they pay me for adding support for it [17:14] is it open source? [17:14] but i thought you weren't doing it any more? [17:14] not everything. [17:15] I won't contribute to the kernel directly and only provide packages [17:15] but some devices can work without that proprietary stuff [17:15] so there's another delta ubuntu needs to maintain [17:16] I could help to maintain it for ubuntu [17:16] I provided driver packages earlier already right now [17:16] mrec, only binary packages? [17:16] my connection is a bit weak here.. [17:17] I prebuilt the sources which I are available right now [17:17] the upcoming devices will use the i2c-dev interface for configuring those proprietary DVB-C/DVB-T/ATSC chips [17:17] so nothing unusual actually [17:19] my personal goal is just to have those things work. Not one step further. [17:19] so I can work on the next project actually. [17:19] ok, not really sure what the question is [17:20] what it is you are proposing? requesting? [17:20] to add the current driver [17:20] http://mcentral.de/hg/~mrec/em28xx-new/shortlog/ [17:21] linuxtv is only developed by a few volunteers adding code now and then, that code has a dedicated development tree [17:22] that driver* [17:23] how does that linux-ubuntu-modules package actually work out? [17:23] especially the release cycles? [17:23] I usually build that module against the lum packages and make debian packages out of those binaries so people can just load the drivers [17:24] if I'd know when new packages will come out I could just prepare the packages [17:24] well l-u-m has gone as of intrepid [17:24] they are now integrated into the kernel package [17:24] ah great! [17:25] the linuxtv.org code updates the full media framework which makes it impossible to compile other drivers against it as soon as it's installed. [17:25] the code in that mcentral.de repository only installs the driver against the current kernel [17:25] When will smb come? [17:25] it won't touch any framework still while adding newer devices [17:27] ok, well i would think the right thing to do is to email the kernel-team mailing list with a request for it to be added as an ubuntu module. that would need to contain a justification on why we would want to carry it, why it is out of the mainline tree etc [17:28] it's just a bad situation, they told me to add my changes to the official module but I won't do that since I'm only working on adding newer devices to that code anymore. [17:28] I won't get paid for rewriting any code and I have alot more to do than to work for some "enthusiasts" [17:29] just as they won't work for me so it's a stuck situation [17:29] "i'm too lazy to submit my code properly so i'll just put the burden on the distros"? [17:29] no my code is properly [17:29] has been developed constantly [17:30] the reason is we won't replace another driver [17:30] submit smaller patches [17:30] This is the userspace tuner stuff? [17:30] I don't see that ever going upstream [17:30] no, but I'm going that way in future [17:30] but using i2c-dev [17:30] noone can complain because it already exists [17:30] and was made for such things [17:31] People can continue to complain [17:31] well i2c-dev is there [17:31] Yes, but that's not the point [17:31] and there's not even one player which works properly with those devices so I started another one. [17:31] I know alot about DVB and analogTV way more than this v4l maintainer [17:31] he's protecting his position nothing else but people don't see that. [17:32] That's really not the point [17:32] the point is that the code has been declined years ago [17:32] for no reason without any userspace stuff [17:32] When it's practical to write an in-kernel driver, pushing gobs of it out to userspace in order to facilitate non-free drivers isn't going to fly [17:32] by people who didn't commit any code to the kernel [17:32] I have an inkernel driver right now [17:32] and I had it at the first point [17:33] the userspace work was developed with the BSD idea in mind [17:33] BSD does tuning in userspace too [17:34] The BSDs have many design decisions that don't fit with how things are done in Linux [17:34] the linux DVB api hardlocked any machine a few years ago when unplugging USB devices till I submitted a patch [17:34] this never happened with BSD that way [17:34] there are good and bad things everywhere [17:34] my goal is to have that stuff work with the least resistance [17:35] and now noone can put a stone into my way anymore [17:35] there are alot people who never wrote any line of code who discussed that issue back then [17:35] Well, other than various distributions never shipping your code [17:35] I know the current issues about v4l and dvb too [17:36] and I won't have that issue. [17:36] I only need a few ones [17:36] I installed ubuntu recently, it didn't support that device either firmware was missing. [17:36] and no applications support audio either as mentioned [17:37] http://mcentral.de/wiki/index.php5/ISDB-T [17:37] I have this one now which detects and supports all the device modes for those devices [17:38] as I wrote there's only one goal for me to have those things work. [17:38] few people are contributing to the driver on mcentral.de too [17:42] there's not even a player available for ISDB-T right now [19:50] ogasawara: My testing has finally resulted in a test bug submitted for kernel. What's the best way to kill the bug, set to 'Invalid" or 'Wontfix'? [19:50] sconklin: Invalid [20:14] ogasawara: if suspend/resume reports were tagged like bug 310997, would that be adequate for helping manage workflow, do you think? [20:14] Malone bug 310997 in linux "Test - Ignore - should have tags this time" [Undecided,New] https://launchpad.net/bugs/310997 === asac_ is now known as asac [23:08] I know this may not be the right place, but I'm trying to install Ubuntu 8.04 on an old laptop. #ubuntu is useless, and #ubuntu-installer folks sent me here. I'm using the 386 netboot files and I get a crash while starting the process. Any tips? [23:09] 6.04 netboot files do start an install, but I was hoping for something more recent. [23:11] sconklin: re bug 310997 - I think tagging them like that would help [23:11] Malone bug 310997 in linux "Test - Ignore - should have tags this time" [Undecided,New] https://launchpad.net/bugs/310997 [23:13] Should I try #ubuntu-quality or #ubuntu-testing, perhaps? [23:13] Torgoton: if you can at least provide detail regarding _where_ in "starting the process", that would be useful [23:14] Torgoton: i'm happy to help you in #ubuntu until we can pinpoint the kernel/initramfs/udev as the culprit [23:14] crimsun: uhm... I'm using linld097 to load the linux and initrd.gz files. That starts, screens full of text fly by, and it ends with a call trace and Kernel panic - not syncing: Attempted to kill the idle task! [23:15] Torgoton: let's migrate (back) to #ubuntu [23:15] crimsun: Great. Should I move to #ubuntu then? [23:15] great. [23:48] (for those wondering, we worked around it by appending noreplace-paravirt to the command line)