[06:08] <lukehasnoname> http://pastebin.com/m54650694
[06:08] <lukehasnoname> That error gets written to /var/log/messages constantly until my root drive is filled.
[06:09] <lukehasnoname> What does it mean for the 'swapper to be tainted'
[06:09] <lukehasnoname> ?
[07:12] <lukehasnoname> google is my friend
[08:56] <apw> 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] <sim__> hi, will a sync(2) call cascade to the ATA layer so that the disk write cache is also flushed?
[10:45] <apw> i thought that most ata drives were write through anyhow?
[10:45] <apw> [  151.346413] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[15:53] <sconklin> so pgraner_lt, apw: want to talk about where we put suspend/resume reports in launchpad?
[16:13] <apw> sconklin, hi
[16:13] <sconklin> apw: good afternoon.
[16:13] <apw> i would think directly onto the linux package, with a tag of something like suspend-resume or something
[16:13] <apw> moin
[16:17] <sconklin> 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] <sconklin> I'll cobble that in, test it, and mail the script around
[16:21] <ogasawara> 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] <ogasawara> sconklin: https://edge.launchpad.net/ubuntu/+bugs?field.tag=suspend
[16:22] <zul> ls
[16:23] <apw> sconklin, what limits us to oops and panic?  those presumably are things in apport land?
[16:24] <apw> i thought the point was it was very extensible, 'a few lines for a new report'
[16:25] <sconklin> 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] <apw> cool, i have got petes modified version of the sleep script and am going to merge that down tommorow with mine
[16:26] <apw> and send it out to us all for testing
[16:26] <ogasawara> 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] <apw> ogasawara, sound plan in my mind, as those two are in use
[16:27] <apw> is there also a resume one?
[16:27] <ogasawara> hrm, lemme check
[16:27] <ogasawara> apw: there is - https://edge.launchpad.net/ubuntu/+bugs?field.tag=resume
[16:28] <apw> 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] <apw> i would hope there is a tag entry in the python dictionary
[16:29]  * apw watches christmas creep up on him, yeeks
[16:29] <sconklin> tags are set in the launchpad back end, not sure they're exposed in the UI - but I'll find a way :)
[16:30] <ogasawara> sconklin: I use python-launchpad-bugs
[16:30] <ogasawara> sconklin: I also think the new launchpad api will probably allow it, although I haven't done any testing with it
[16:31] <apw> this needs to be on the user end, in apport tho
[16:35] <sconklin> right, I meant on the apport end.
[16:35] <sconklin> but I'll eventually end up on the other end too.
[16:38] <ogasawara> 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] <sconklin> tags are set automatically in the apport backend for launchpad from a small set, and aren't exposed from the reports. 
[16:43] <apw> ogasawara, or is what we want, any of the above
[16:43] <apw> sconklin, well thats a bit pants isn't it?
[16:43] <ogasawara> apw: cool, then we're good
[16:45] <sconklin> apw: this is all fun stuff to learn about, too bad it's due yesterday. :)
[16:45] <ogasawara> heh
[16:45] <apw> we're not in _that_ much of a hurry
[16:46] <sconklin> 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] <apw> yeah
[16:51] <apw> have you managed to report any bugs yet?
[16:53] <sconklin> 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] <apw> heh, going to be a battle for sure
[16:54] <sconklin> 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] <apw> ah ok
[16:54]  * apw gets a reminder for his cancelled meeting
[16:54] <apw> noting that the reminder even has cancelled in the text of the reminder!?!
[16:55] <sconklin> 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] <apw> yeah sounds like there is abunch of work needed on apport as well
[16:56] <ogasawara> sconklin: not a big deal to me if you can't use staging for testing purposes - I can ignore test bugs.
[16:56] <sconklin> In general, I think it's really well written, we just want to extend it in ways pitti didn't think about
[16:57] <sconklin> ogasawara: ok, thanks. If I can get arbitrary tags in there, this will be no big deal.
[16:58] <sconklin> 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] <sconklin> Aattention is misspelled on purpose, to drive it to the top alphabetically
[16:59] <apw> heh
[17:03] <apw> sconklin, so are you going to expose the tags to the drivers here?
[17:03] <apw> ie allow the report to add tags directly?
[17:06] <apw> it looks like a two line patch to expose tags i think
[17:06] <sconklin> 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] <mrec> Hi, does anyone know about the em28xx driver here?
[17:07] <apw> if not we woul djust need to fix the apport to hdr['Tags'] += report.get('Tags') sort of thing
[17:07] <apw> mrec, what you want to know about it?
[17:07] <mrec> 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] <mrec> well there are 2 drivers available now
[17:08] <mrec> one which supports most devices and one which won't ever have support for the latest devices
[17:08] <mrec> I was providing debian packages for ubuntu for a while now
[17:09] <apw> so what is wrong with the kernel as it stands, offering the wrong one of the two drivers?
[17:10] <mrec> yes they'll go their own way without official support.
[17:11] <mrec> I gave them the possibility to use the fully supported driver, but the v4l maintainer wants to go his own way
[17:11] <mrec> so I won't contribute to the linux kernel anymore.
[17:11] <apw> thats a shame
[17:11] <mrec> some companies who we work with don't want everything opensourced anymore either.
[17:12] <mrec> well it's linux I acknowlidge it.
[17:12] <apw> 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] <mrec> there are not that many possibilities available out there
[17:13] <mrec> and that company is likely market leader
[17:13] <mrec> main business is done with windows and OSX right now anyway
[17:13] <apw> 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] <apw> so until it hurts them in the pocket book we have no pressure to put on them
[17:14] <mrec> it won't hurt since they pay me for adding support for it
[17:14] <laga> is it open source?
[17:14] <apw> but i thought you weren't doing it any more?
[17:14] <mrec> not everything.
[17:15] <mrec> I won't contribute to the kernel directly and only provide packages
[17:15] <mrec> but some devices can work without that proprietary stuff
[17:15] <laga> so there's another delta ubuntu needs to maintain
[17:16] <mrec> I could help to maintain it for ubuntu
[17:16] <mrec> I provided driver packages earlier already right now
[17:16] <apw> mrec, only binary packages?
[17:16] <mrec> my connection is a bit weak here..
[17:17] <mrec> I prebuilt the sources which I are available right now
[17:17] <mrec> the upcoming devices will use the i2c-dev interface for configuring those proprietary DVB-C/DVB-T/ATSC chips
[17:17] <mrec> so nothing unusual actually
[17:19] <mrec> my personal goal is just to have those things work. Not one step further.
[17:19] <mrec> so I can work on the next project actually.
[17:19] <apw> ok, not really sure what the question is
[17:20] <apw> what it is you are proposing?  requesting?
[17:20] <mrec> to add the current driver
[17:20] <mrec> http://mcentral.de/hg/~mrec/em28xx-new/shortlog/
[17:21] <mrec> linuxtv is only developed by a few volunteers adding code now and then, that code has a dedicated development tree
[17:22] <mrec> that driver*
[17:23] <mrec> how does that linux-ubuntu-modules package actually work out? 
[17:23] <mrec> especially the release cycles?
[17:23] <mrec> 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] <mrec> if I'd know when new packages will come out I could just prepare the packages
[17:24] <apw> well l-u-m has gone as of intrepid
[17:24] <apw> they are now integrated into the kernel package
[17:24] <mrec> ah great!
[17:25] <mrec> 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] <mrec> the code in that mcentral.de repository only installs the driver against the current kernel
[17:25] <ion_> When will smb come?
[17:25] <mrec> it won't touch any framework still while adding newer devices
[17:27] <apw> 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] <mrec> 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] <mrec> I won't get paid for rewriting any code and I have alot more to do than to work for some "enthusiasts"
[17:29] <mrec> just as they won't work for me so it's a stuck situation
[17:29] <laga> "i'm too lazy to submit my code properly so i'll just put the burden on the distros"?
[17:29] <mrec> no my code is properly
[17:29] <mrec> has been developed constantly
[17:30] <mrec> the reason is we won't replace another driver
[17:30] <mrec> submit smaller patches
[17:30] <mjg59> This is the userspace tuner stuff?
[17:30] <mjg59> I don't see that ever going upstream
[17:30] <mrec> no, but I'm going that way in future
[17:30] <mrec> but using i2c-dev
[17:30] <mrec> noone can complain because it already exists
[17:30] <mrec> and was made for such things
[17:31] <mjg59> People can continue to complain
[17:31] <mrec> well i2c-dev is there
[17:31] <mjg59> Yes, but that's not the point
[17:31] <mrec> and there's not even one player which works properly with those devices so I started another one.
[17:31] <mrec> I know alot about DVB and analogTV way more than this v4l maintainer
[17:31] <mrec> he's protecting his position nothing else but people don't see that.
[17:32] <mjg59> That's really not the point
[17:32] <mrec> the point is that the code has been declined years ago
[17:32] <mrec> for no reason without any userspace stuff
[17:32] <mjg59> 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] <mrec> by people who didn't commit any code to the kernel
[17:32] <mrec> I have an inkernel driver right now
[17:32] <mrec> and I had it at the first point
[17:33] <mrec> the userspace work was developed with the BSD idea in mind
[17:33] <mrec> BSD does tuning in userspace too
[17:34] <mjg59> The BSDs have many design decisions that don't fit with how things are done in Linux
[17:34] <mrec> the linux DVB api hardlocked any machine a few years ago when unplugging USB devices till I submitted a patch
[17:34] <mrec> this never happened with BSD that way
[17:34] <mrec> there are good and bad things everywhere
[17:34] <mrec> my goal is to have that stuff work with the least resistance
[17:35] <mrec> and now noone can put a stone into my way anymore
[17:35] <mrec> there are alot people who never wrote any line of code who discussed that issue back then
[17:35] <mjg59> Well, other than various distributions never shipping your code
[17:35] <mrec> I know the current issues about v4l and dvb too
[17:36] <mrec> and I won't have that issue.
[17:36] <mrec> I only need a few ones
[17:36] <mrec> I installed ubuntu recently, it didn't support that device either firmware was missing.
[17:36] <mrec> and no applications support audio either as mentioned
[17:37] <mrec> http://mcentral.de/wiki/index.php5/ISDB-T
[17:37] <mrec> I have this one now which detects and supports all the device modes for those devices
[17:38] <mrec> as I wrote there's only one goal for me to have those things work.
[17:38] <mrec> few people are contributing to the driver on mcentral.de too
[17:42] <mrec> there's not even a player available for ISDB-T right now
[19:50] <sconklin> 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] <ogasawara> sconklin: Invalid
[20:14] <sconklin> ogasawara: if suspend/resume reports were tagged like bug 310997, would that be adequate for helping manage workflow, do you think?
[20:14] <ubot3> Malone bug 310997 in linux "Test - Ignore - should have tags this time" [Undecided,New] https://launchpad.net/bugs/310997
[23:08] <Torgoton> 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] <Torgoton> 6.04 netboot files do start an install, but I was hoping for something more recent.
[23:11] <ogasawara> sconklin: re bug 310997 - I think tagging them like that would help
[23:11] <ubot3> Malone bug 310997 in linux "Test - Ignore - should have tags this time" [Undecided,New] https://launchpad.net/bugs/310997
[23:13] <Torgoton> Should I try #ubuntu-quality or #ubuntu-testing, perhaps?
[23:13] <crimsun> Torgoton: if you can at least provide detail regarding _where_ in "starting the process", that would be useful
[23:14] <crimsun> Torgoton: i'm happy to help you in #ubuntu until we can pinpoint the kernel/initramfs/udev as the culprit
[23:14] <Torgoton> 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] <crimsun> Torgoton: let's migrate (back) to #ubuntu
[23:15] <Torgoton> crimsun: Great. Should I move to #ubuntu then?
[23:15] <Torgoton> great.
[23:48] <crimsun> (for those wondering, we worked around it by appending noreplace-paravirt to the command line)