[00:14] <tj83_> apw, you want my results of the testing of the rtl8187 drivers? Bug #254438 :( 
[00:14] <ubot3> Malone bug 254438 in linux "realtek RTL8187B wireless card does not work properly. Loss of speed, Range, Reliablity." [Medium,Triaged] https://launchpad.net/bugs/254438
[00:16] <tj83_> Is there anyone willing and able to dissect some wifi drivers whom thousands of users are suffering from? Its beyond my skill level.
=== hggdh_ is now known as hggdh
=== bjf is now known as bjf-afk
[03:10] <Darxus> "fakeroot debian/rules binary-generic" is giving me "dh_installchangelogs: package linux-image-2.6.31-11-c70-generic is not in control info", etc..
[03:16] <ikepanhc> Darxus: try "fakeroot debian/rules debian/control" first?
[03:17] <Darxus> Thanks.
[03:24] <Darxus> Nope.
[03:24] <Darxus> "dh_installchangelogs: package linux-image-2.6.31-11-df6-generic is not in control info"
[03:25] <Darxus> I have "AUTOBUILD=1" in debian.master/rules.d/0*.
[03:49] <tj83> so Bug #254438 has this entry in December of 08' . the bug has a medium importance tag and triaged for status. But the problem persist now still. LP will allow me to change it but is it my place to change the status? I cant change the importance. I would like to see it as confirmed or new as it should be re-opened.
[03:49] <ubot3> Malone bug 254438 in linux "realtek RTL8187B wireless card does not work properly. Loss of speed, Range, Reliablity." [Medium,Triaged] https://launchpad.net/bugs/254438
[03:51] <tj83> bug opened Date: Sun Aug 3 18:46:33 2008 that is a LONG time ago now
=== lamont` is now known as lamont
[05:14] <MTecknology> You guys are really cranking out a few kernels today :P
[08:16] <apw> tj83, triaged is an open state
=== Whoopie_ is now known as Whoopie
=== ogra_ is now known as ogra
=== ogra is now known as Guest77653
=== Guest77653 is now known as ogra
[12:03] <mdz> apw, just wanted to draw attention to this newly-flagged regression: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/386468
[12:03] <ubot3> Malone bug 386468 in linux "Ethernet Atheros AR8131 (Acer laptops) not working" [Undecided,Confirmed] 
[12:04] <apw> mdz ... thanks
[12:17] <ubuntu> hey, how to file a system bug since the bug tracking wants me to use the application menu entries to track?
=== ubuntu is now known as erle-
[12:18] <erle-> ubuntu live cd swapped on my luks/dm-crypt!
[12:18] <erle-> i think this is very critical
[12:26] <apw> erle-, could you say that again with more detail
[12:27] <erle-> i bootet an ubuntu 9.04 live system
[12:28] <erle-> and it made my /dev/sda1 - which is a luks/dm-crypt/lvm thingy - a swap partition
[12:28] <erle-> and swapped on my data
[12:28] <erle-> without asking
[12:28] <erle-> the encrypted partition was set up by ubuntu installation, nothing exotic or special
[12:29] <erle-> what the hell was wrong with the guy who told the live system to make unknown partitions mkswap?
[12:30] <smb> erle-, You are positive that it was really swap and not some other corruption? Not that it would be less bad
[12:30] <erle-> i will try to reproduce it, when i get my system in a proper state
[12:31] <erle-> smb, yeah, it was mounted as swap
[12:31] <erle-> and there is a swap header in it
[12:31] <erle-> luckily it is not right at the beginnig of the partition
[12:31] <erle-> i still found my keys
[12:31] <erle-> but its pretty much screwed up, i have to recover the key by hand etc.
[12:33] <smb> erle-, ok, yeah. does not sound too good. Actually I would expect the live system to not use any swap... but I might be wrong
[12:33] <erle-> using swap is not the problem
[12:33] <erle-> doing mkswap is the problem
[12:34] <erle-> especially when the partition starts with magic "LUKS" string etc.
[12:34] <smb> well anything done to any real disk. definitely creating things amongst that
[12:36] <erle-> but then you have to avoid automount etc consequently
[12:38] <smb> erle-, True and that would impose some problems for wanting usb keys detected. So yeah auto mounting ok but not auto-create things
[12:38] <smb> erle-, Did you use the cd from beta or something from daily builds?
[12:55] <pgraner> apw: why does this have a karmic task? https://bugs.edge.launchpad.net/ubuntu/karmic/+source/linux/+bug/100110
[12:55] <ubot3> Malone bug 100110 in acpi "18 seconds ACPI delay while booting due to DSDT" [Undecided,New] 
[12:55] <pgraner> apw: we don't have dsdt in karmic?
[12:56] <smb> pgraner, But we might quirk the acpi driver to be smart about high sleep values
[12:56] <apw> pgraner, indeed and by not having dsdt override we prevent the users working round their broken machines in karmic, therefore they have a regression compared to jaunty
[12:56] <smb> pgraner, and we do not have the dsdt override patch in karmic
[12:56] <apw> the upstream fix is normally to quirk the issue in the kernel, and the karmic task is looking at that
[12:57] <apw> indeed that is what the test kernel starts looking at, i wonder if it got tested yet
[12:57] <pgraner> apw: ok, that not clear, given the age of the bug. 
[13:00] <erle-> smb, no, it was the regular 9.04 desktop - i downloaded it on monday
[13:00] <smb> csurbhi, apw Regarding those error messages we are supposed to remove
[13:00] <erle-> very recent
[13:00] <smb> erle-, ok, the cd or dvd (just want to download the right thing)
[13:00] <apw> pgraner, not clean in the least.  my bad will put some commentry in it
[13:01] <erle-> smb, cd, but i made a bootable usb stick with it
[13:01] <smb> apw, pgraner Given that it was part of the 40-50 bug review not very surprising
[13:01] <smb> erle-, Ok, I try to have something similar here then
[13:01] <erle-> amd64 by the way (core 2 duo cpu)
[13:02] <pgraner> apw: no worries
[13:04]  * erle- is afk for a while
[13:04]  * apw updates the description to include the karmic rider information
[13:05] <apw> smb, seems we have some feedback, all good ... excellent ... will try and do something which is only specific to the machine
[13:05] <smb> csurbhi, apw Looking at that the main problem is an overlay between acpi regions and drivers claiming the same
[13:05] <smb> apw, sounds excellent
[13:05] <apw> smb, meaning what exactly?
[13:06] <smb> csurbhi, apw The same memory or io region is defined/claimed by the acpi bios and would likely need an acpi aware driver to access this (which the driver does not)
[13:06] <smb> There is a "solution" to this though
[13:07] <csurbhi> but is not the bios wrongly assigning the same regions ? 
[13:07] <smb> When booting with acpi_enforce_resources=lax the driver will succeed and the error message will get turned into a warning
[13:07] <csurbhi> overlapping regions ?
[13:07] <csurbhi> also by doing "lax"
[13:07] <csurbhi> may be the SMBus shall read wrong information
[13:08] <csurbhi> as two separate drivers will be writing to the same address
[13:08] <smb> csurbhi, no
[13:08] <smb> the acpi bios just declares that region, not necessarily using it
[13:08] <csurbhi> ok
[13:08] <csurbhi> i thought that SMBus will be using it 
[13:09] <smb> I would think we got that parallel definitions well long time
[13:09] <smb> but only recently the acpi driver checks
[13:09] <csurbhi> aah ! thats what i was wondering
[13:09] <smb> it will be used by driver.
[13:09] <apw> as in we used to let the overlpa happen without whining or stopping it, now we do?
[13:09] <csurbhi> why this bug is a recent one
[13:09] <smb> before that there was no check
[13:09] <smb> now the default is check and deny
[13:09] <csurbhi> ok.. cool..
[13:09] <smb> while with lax the action is check warn and allow
[13:09] <csurbhi> i get it now
[13:10] <csurbhi> great !! sounds very good to me
[13:10] <smb> I have not gone around to check whether we can set this by a kernel compile option or
[13:10] <smb> need to add it to the default command lime
[13:10] <smb> line
[13:11] <csurbhi> so smb, if i understand it correctly, the BIOS claims it.. but does not use it.. and the ic2_piix4 is the only driver using it.. though it does go ahead check 
[13:12] <csurbhi> this check being added recently...which is why this bug was not reported in the earlier kernels
[13:14] <smb> roughly yes. I have not read deeply into how exaclty this is done but the acpi driver can reverse things and then gets notice if another driver wants the same resource (which is piix4 in that case). Then it can either allow or deny the second request which makes the driver fail now
[13:14] <csurbhi> but is that not what is happening ?
[13:15] <csurbhi> i mean, is not piix4 driver not getting inserted /
[13:15] <csurbhi> ?
[13:15] <smb> right because the default is deny. and before there was no check at all, so allow was the dafault
[13:16] <csurbhi> ok.. so by saying lax we let the module be inserted
[13:16] <smb> yes
[13:16] <tj83_> g'morning all
[13:17] <smb> So looking at osl.c there are two options: 1) we change the default in the code or 2) we take acpi_enforce_resources=lax as a standard option
[13:19] <csurbhi> one naive question
[13:19] <csurbhi> what  is a SOR1 region used for ?
[13:22] <smb> That SOR1 is just a name which can be freely chosen.
[13:22] <csurbhi> but what is it used for ? anything specific ? or why does the BIOS claim it ? is dedicated for some device/some work ?
[13:23] <smb> I have not seen the bios but it just might declare that region with a name or do something with it. And being resticted to 4 letters does not help the readablilty
[13:23] <csurbhi> so if the BIOS does something with it
[13:23] <csurbhi> and we let the piix4 use it too
[13:23] <csurbhi> then is that correct ?
[13:24] <smb> If you want to know for sure, ask for the "sudo acpidump -o acpidump.txt" then acpixtract that and iasl -d the dsdt and look into the disassemly :)
[13:24] <csurbhi> ok great idea
[13:24] <csurbhi> i will ask :)
[13:25] <smb> I just would say that, as there was no check for that before, things cannot go worse by now being lax with it ;-)
[13:25] <csurbhi> yeah.. but i was just being curious..
[13:25] <csurbhi> :)
[13:25] <smb> sure, I won't keep you from looking :)
[13:26] <smb> Just was sort of pragmatic about those nagings for the clean-boot thing. As being lax automatically makes a KERN_ERR to a KERN_WARNING, those will be happy too
[13:28] <tj83_> smb, can one not take a driver for a wifi chipset that has positive attributes  like speed and range, and another driver which speed and range is not good but other than that works great look at the code and merge the best of the two to come out with a working driver? I dont know how this works, I am no code hacker. really wish i were.
[13:29] <csurbhi> smb, thanks a lot for the acpi dump idea :)
[13:29] <tj83_> for the same hardware* i'm not saying off the wall drivers for other hardware... both drivers install and work on the hardware to a degree and are solely intended for it.
[13:29] <smb> tj83_, The problem is a) time and b) how does one know what the good parts are which leads back to a)
[13:30] <tj83_> yea, but the magnatude of the user base would seem to make the a) worth it.
[13:31] <tj83_> the b) i havent a clue
[13:31] <tj83_> where might i find someone willing to just attempt this? 
[13:33] <tj83_> wrote steve conklin about it. waiting to hear from him... you guys know him? i think he is on the kernel team. I met him at atlanta linux fest.
[13:33] <smb> It is surely worthwhile. And there has been a bit of discussion about it on the kernel-team mailing list. It would be a great thing if it would be possible for the guy that has the newer/working driver to get in contact with the guys working on the internal driver, and make the best happen
[13:33] <smb> tj83_, Sure know him
[13:33]  * smb was there too
[13:33] <tj83_> ah, :)
[13:34] <smb> and he is a colleague... :)
[13:34] <smb> but essentially he would give the similar answer
[13:34] <smb> unfortunately real world is not only about code but legal too
[13:34] <tj83_> well this guy with the drivers wants to help. so , shall I just give you his e-mail address?
[13:35] <tj83_> doesnt realtek release all their driver stuff as open source? where is the legal problem?
[13:35] <smb> Mine would not help that much, you refer to richell?
[13:36] <smb> there might be none or reuse is limited. But maybe its ok. that needs to be verified as well
[13:37] <tj83_> I am talking about Carl Richell he wants to help.... so i think he just needs to talk to the right people 
[13:37] <smb> tj83_, Ok, so someone from us has given him names from the upstream driver developers
[13:38] <smb> that would be the best approach when he could get into touch with them
[13:38] <smb> cause in the end this would benefit all users if we had only one working driver _in_ the kernel
[13:39] <tj83_> amen to that!
[13:39]  * tj83_ is sick of this issue
[13:40]  * smb understands, but cannot offer a better option, especially that late before the release
[13:41] <tj83_> so basically the ball is in Richell's court and wtf is he doing? is he helping or not? as far as the release, i know its making it into karmic as a fixed bug, but more important is getting the ball rolling and going someplace good for Lucid. after a year and half , one starts to wonder if it will be
[13:41] <tj83_> not making it*
[13:43] <tj83_> I wrote Richell back on my results of testing the drivers in question.... once he replies I will remind him he needs to push on with the driver developers. in case he doesnt have the information for the upstream driver developers, how does one obtain it?
[13:47] <tj83_> smb, honestly... I dont think there is anything to submit to them :( I tested his drivers.  sad to say i was not impressed. so it all comes back to square one where we need to make one product from two partial ones and its gonna take hacking the code to do it. :(
[13:47] <smb> tj83_, Whether it makes it into Karmic as a bug fix will depend on how simple it will be to understand/test this does not break other hardware which might be using the same driver. I only quickly scanned over the code but haveing a lot of renamed files makes it hard to tell.
[13:47] <smb> tj83_, Oh, so you say the claimed improvement was not visible to you that much?
[13:49] <smb> But sadly yes. The problem is often that these vendor drivers come up, twiddling bits and bites and no-one really knows what exactly is done by that. So merging things together is hard, even for those that work on the driver
[13:50] <tj83_> smb, my testing was crude, but I regret to say... I am not convinced his drivers are anything other than what is in mainstream release right now :( I need to do some more seriously controlled testing. and I intend to, outdoors measured distances and real fact datalogging.  but a quick "lets see how far this goes" said to me same. i mean on a dime drops connection same place as what we been using.  but let the man have his chance to answer to that. I 
[13:50] <tj83_> have called him out on it.
[13:51] <tj83_> smb, i mean down to +/- 3ft distance
[13:52] <tj83_> but someone like you can look in the code and see more than me.
[13:52] <smb> tj83_, I would say that chance should be given. And that he might get into touch with others that had more time to work on this special piece of driver. He also might be happy to have someone else with that hardware to test on. In different environments and so on.
[13:52] <tj83_> and the real resource is long forgotten... there are some hacked up drivers for 2.6.24 that have amazing distance and speed. those strengths need applied to current driver
[13:53] <tj83_> but i dont think anyone is looking at THOSE old drivers
[13:54] <smb> tj83_, The problem for me is, I can look at the code, and maybe I understand what it does on a instruction level, but I have no idea what writing or reading certain values from here and there does. I often have to be all over the place, so it is hard to dig into something deeply
[13:55] <tj83_> thats cool... I just dont know what a guy like me can do to help the situation either.
[13:56] <smb> Well as I said, you can provide feedback like you did and testing time. 
[13:57] <tj83_> yea this weekend i am going to build a major report on everything i know about this and testing from 8.04, 8.10, 9.04, and 9.10 compare what we have to work with and plead for someone's mercy in taking it to the next level. lol
[13:59] <smb> Heh yeah. At least that one guy seems willing and with a bit of encouragement might get things moving into the right direction
[14:03] <tj83_> smb can you help me with just one other thing.... how can I tell the version of the driver in use ? the kernel module name is just rtl8187 and is the same for all releases of ubuntu 8.10 to karmic
[14:04] <tj83_> so that i can accurately compare
[14:05] <smb> tj83_, mostly depends on the writers mercy. (putting in a version number). Let me quickly check whether there is something
[14:08] <mzeal> I have the kernel module crushing my system ( Hardy Heron) for the reasons unknown... Does the Ubuntu save system log in  the case of crush?
[14:10] <tj83_> mzeal, I'm newb but yea, i would certainly be checking logs dmesg, syslog, messages
[14:10] <smb> tj83_, There does not seem to be any version info in the code. :( So best bet is to use the uname -a of the kernel or the package version of backports modules if you are using those
[14:10] <tj83_> smb, thank you
[14:11] <smb> mzeal, It depends on whether there was time to write something to disk. Often there is nothing. 
[14:12] <smb> But when only a module crashed without the whole system hanging there should be something
[14:12] <mzeal> tj83_, i only can do it after the reboot, so dmesg, syslog belong to the session after the reboot
[14:13] <mzeal> smb: the whole system hangs... 
[14:14] <smb> mzeal, dmesg is completely new. /var/log/syslog contains the previous run as well. But in case of a complete system hang there isn't anything that could write that do disk
[14:14] <Womble2> mzeal: You can set up a 'netconsole' which sends kernel log messages to another machine over the network
[14:15] <smb> If you can repeat it, you might try to switch to a text console before doing the thing that causes the hang
[14:15] <smb> or what Womble2 said
[14:16] <smb> If you have a second computer to do that
[14:17] <Womble2> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/networking/netconsole.txt;hb=74fca6a42863ffacaf7ba6f1936a9f228950f657
[14:17] <mzeal> wouldn't be more helpful if i get crushdump?
[14:17] <Womble2> Do you mean an 'oops' message or a memory dump?
[14:18] <Womble2> The 'oops' should be sent over netconsole if you set that up
[14:18] <mzeal> memory dump with the stack trace
[14:19] <Womble2> mzeal: That's what I mean - everything sent to the local text console also goes over netconsole
[14:19] <Q-FUNK> smb: was the dmesg I pasted any useful?  there was at least one place where it showed which file inode_destroy acted upon.
[14:20] <smb> Q-FUNK, You pasted something new? If I can crawl out of that pile of bug reports, I need to take a look...
[14:21] <mzeal> womble2: ok, but how can i get the dump from kernel module in the first place? 
[14:21] <mzeal> i never done it for kernel module 
[14:21] <Q-FUNK> smb: :D
[14:22] <Q-FUNK> smb: https://bugs.launchpad.net/linux/+bug/396286/comments/112
[14:22] <ubot3> Malone bug 396286 in linux "2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] 
[14:22] <Womble2> mzeal: You said the system hangs... so presumably there is a dump, only it's on the text console where you can't see it
[14:26] <smb> Q-FUNK, Hm, at least it catched one filename. The others seem to be on delete without one available. What would be interesting is, whether you get more of these while running or whether it is purely limited to startup
[14:26] <mzeal> Womble2: well,  i mean core dump into the file. In the user mode you can enable it with 'ulimit', is there something similar for the kernel module? 
[14:26] <Q-FUNK> smb: I haven't noticed after boot.
[14:28] <Q-FUNK> smb: that first one seems to indicate some problem with an udev rule.
[14:29] <smb> Q-FUNK, maybe something during udev processing, but that is still a bit broad
[14:29] <Q-FUNK> smb: indeed. it just generally reports  <3>[    3.917314] ipath /lib/udev/rules.d
[14:30] <smb> Q-FUNK, right, which means the directory inode was corrupted, but you cannot say who and when
[14:32] <smb> Q-FUNK, Though, as we do not see it anywhere else, the assumption it must be something specific to the geode platform sounds appealing
[14:33] <Q-FUNK> smb: I'm still puzzled as to how this could be, though.
[14:34] <MTecknology> Is there an easy way to see what the kernel is loading and how to disable it?
[14:34] <Q-FUNK> smb: just as a test, I tried purging apparmor and rebuilding the initramfs image.  that didn't fix it, so I guess that we can cross that one out.
[14:35] <smb> Q-FUNK, right. so what else is around there? There are two usb devices, what are these?
[14:36] <Q-FUNK> smb: mouse and keyboard.  there is no legacy ps/2 port on this host.
[14:37] <Wellark> hi! does any package contain stock karmic vmlinuX image? I need one to investigate kdump elf-image..
[14:37] <smb> Q-FUNK, ok, that should be pretty normal/common things
[14:38] <smb> Wellark, have a look at things on http://ddebs.ubuntu.com/pool/main/l/linux/
[14:39] <Wellark> smb: thanks! looks promising
[14:41] <Q-FUNK> damn pidgin...  :(
[14:41] <Q-FUNK> smb: come again?
[14:41] <mzeal> anyway, netconsole seems to be a neat idea, i can try that
[14:42] <smb> Q-FUNK, Not sure what the last things were you got (<smb> Q-FUNK, ok, that should be pretty normal/common things)
[14:42] <smb> Q-FUNK, You still have the full log of that? If yes, please add it to the bug, so I can have a peek at the ...
[14:43] <smb> Q-FUNK, I prepare a rebase meanwhile
[15:00] <Q-FUNK> smb: added
[15:02] <smb> Q-FUNK, ok, thanks. rebase is building. I add a note when its done
[15:02] <Q-FUNK> smb: alright.
=== csurbhi is now known as csurbhi-afk
=== bjf-afk is now known as bjf
[15:18] <rtg> pgraner, does 2.6.31-41 continue to work wrt i915 issues? At least one guy is still complaining, but he's got a different problem, i.e.,  its not module load order.
[15:20] <pgraner> rtg: its working now on all the boxes that had the problem
[15:20] <pgraner> rtg: so works4me
[15:20] <rtg> pgraner, ack
[15:27] <apw> rtg do you have a prism2.5 wireless card you might be able to test?
[15:27] <rtg> apw, card yes, PCMCIA platform no.
[15:27] <rtg> and I'm not really sure I have a  card anymore
[15:28] <apw> hrm, bug #444801 reports they are broken in all karmic kernels, and we have a backported fix, and they reporter can't test... so i just wondered
[15:28] <ubot3> Malone bug 444801 in linux "prism 2.5 broke in 2.6.30.x (fixed upstream in 2.6.32)" [Unknown,Fix released] https://launchpad.net/bugs/444801
=== csurbhi-afk is now known as csurbhi
[16:10] <apw> smb, what wireless do you have in your AA1 ?
[16:11] <apw> smb, sorry which ehternet do you have in your AA1, and is it working?
[16:12] <smb> apw, "Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E" and yes
[16:12] <apw> smb, not the one i am looking for then
[16:14] <smb> sorry, you are looking for prism?
[16:16] <apw> Ethernet Atheros AR8131
[16:16] <apw> is what i am looking for, reported to be in Acer laptops
[16:17] <smb> apw, Hm, nothing else Acer around here
[16:17] <apw> me either
[16:34] <Wellark> btw, is there a particular reason why update-grub doesn't append crashkernel parameter to recovery entries also?
[16:37] <Wellark> *update-grub2
[16:39] <rtg> ogasawara_, whats going on with the Dell laptop rfkill bits?
[16:39] <ogasawara_> rtg: posted test kernel, feedback is looking good
[16:40] <rtg> ogasawara_, are you ready to get it on the list?
[16:40] <rtg> actully, have you asked mjg59 why its not upstream (or is it languishing on a tree somewhere) ?
[16:41] <ogasawara_> rtg: haven't talked with mjg59 or checked to see if it's in someother tree
[16:42] <rtg> ogasawara_, I think its worth posting your patch. I'd like to get it in the pipeline.
[16:42] <ogasawara_> rtg: ack, will send a pull request for review right now
[16:44] <ogasawara_> mjg59: just fyi, testing of some patches from you'd submitted resolve https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/430809/
[16:44] <ubot3> Malone bug 430809 in linux "[Dell Latitude D430, iwl3945] Wireless can't be activated after disabling kill switch" [High,Triaged] 
[16:44] <mjg59> Good
[16:45] <rtg> mjg59, is Linus pulling from you, or do you run your patches through Dave's tree?
=== csurbhi is now known as csurbhi-afk-away
[17:59] <mjg59> rtg: The platform stuff should be going via Len, I think
[18:00] <rtg> mjg59, thanks. I didn't realize until after I looked at your patches that it also involved input infrastructure. It looks benign if no filters register, so ought to be very testable.
[18:01] <mjg59> rtg: Oh, right
[18:01] <mjg59> rtg: The input stuff needs to be switched to using i8042 rather than the main input layer
[18:01] <mjg59> I've got that in Fedora and it's pretty benign, but Dmitry's right that it should be via i8042 instead
[18:02] <mjg59> Which also lets me hook the stuff from any of the other events that Dell sends that way
[18:02] <Kano> rtg: do you see 2.6.31.3 too?
[18:02] <rtg> mjg59, is the current incantation sufficient? I'd just as soon go with it as it is. I can drop it for Lucid in favor up upstream.
[18:02] <rtg> s/up/of/
[18:03] <mjg59> rtg: Yeah, it'll work fine
[18:03] <mjg59> But it's not "correct"
[18:04] <rtg> mjg59, ok, it'll do for now.
[18:04] <rtg> Kano, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=7434f5920d28328b94c58e17928138644376e61b
[18:04] <Kano> ok
[18:04] <Kano> no gspca patches
[18:05] <Kano> http://linuxtv.org/hg/~eandren/v4l-dvb/
[18:05] <Kano> i would add the top 3
[18:05] <rtg> bug #
[18:05] <rtg> ?
[18:08] <apw> rtg you were working on an rfkill userspace thingy in acpi-support i think
[18:08] <apw> bug #397698
[18:08] <ubot3> Malone bug 397698 in linux "isAnyWirelessPoweredOn in state-funcs always returns 1 in karmic" [Medium,In progress] https://launchpad.net/bugs/397698
[18:08] <apw> you posted a patch at the bottom, did that ever get tested?
[18:10] <apw> if not i could try and make a package with it applied
[18:10] <rtg> apw, nah, slangasek didn't like it.
[18:11] <rtg> we should get with him to see how he wants to fix it. I thought the package was going away
[18:11] <apw> yeah the ever ongoing saga of acpid going away
[18:12] <Kano> rtg: any specific wish as bugreport title to add this http://linuxtv.org/hg/~eandren/v4l-dvb/rev/3cf50d4a5aab
[18:12] <rtg> Kano, just something meaningful.
[18:12] <rtg> descriptive
[18:15] <apw> what do the patches help with, why do we wnat them
[18:15] <apw> so we can remember why we applied them in a years time
[18:15] <Kano> there is definite no slower server than launchpad...
[18:16] <apw> now i can't fault you on that
[18:16] <rtg> ain't that the truth
[18:17] <apw> and today its sucking more than normal
[18:18] <Kano> Sorry, something just went wrong in Launchpad. 
[18:18] <Kano> report yourself the bug
[18:18] <Kano> i dont like waiting till it works
[18:18] <apw> yet you want us to carry the patches without any reasons given ...
[18:19] <apw> without a bug we will forget in 10 mins, cause we have 100s of similar requests
[20:41] <Darxus> Wow, I actually got the ubuntu kernel package to make debs!
[20:41] <Darxus> I'll have something to try booting tonight!
[20:42] <Darxus> Now how do I do the equivalent of "debian/rules binary-generic skipabi=true" with debuild?  AUTOBUILD=1 I think is broken.
[20:44] <rtg> Darxus, why not just add ignore files to your ABI directories?
[20:45] <Darxus> rtg: I believe an ignore file is required for each module, and I don't know how to do that?
[20:45] <rtg> Darxus, no, only for each arch. you can also add ignore.modules for each arch.
[20:46] <Darxus> Although commandline options won't be useful for getting launchpad to build this.
[20:46] <Darxus> rtg: Cool, thanks.
[20:47] <Darxus> That doesn't seem to be documented.
[20:48] <Darxus> touch debian/abi/<previous version>/<arch>/ignore ... and what for modules?
[20:48] <rtg> Darxus, debian.master/scripts/module-check and debian.master/scripts/abi-check
[20:49] <rtg> Darxus, echo 1 > debian/abi/<previous version>/<arch>/ignore.modules
[20:49] <Darxus> Should I just gut those two scripts?
[20:49] <rtg> remember, git doesn't like empty files
[20:50] <Darxus> I don't think I'll be using git for this.
[20:50] <Darxus> But yes, I do get complaints about empty files, thanks.
[21:04] <Darxus> cd debian.master/abi ; for version in * ; do for arch in i386 amd64 lpia ia64 powerpc sparc ; do echo 1> ${version}/ignore ; echo 1> ${version}/ignore.modules ; done ; done
[21:05] <Darxus> Er, no.
[21:07] <Darxus> cd debian.master/abi ; for version in * ; do for arch in i386 amd64 lpia ia64 powerpc sparc ; do mkdir -p ${version}/${arch} ; echo 1> ${version}/${arch}/ignore ; echo 1> ${version}/${arch}/ignore.modules ; done ; done
=== TheMuso` is now known as TheMuso