=== _LibertyZero is now known as LibertyZero [07:50] * apw grumbles about waking up too early === smb` is now known as smb [08:21] * smb couldn't be bothered before [08:22] hey guys [08:22] morning apw [08:24] mornig [08:26] how goes it [08:27] busy as always [08:35] apw, So compat_vdso is only i386 and is said only to be needed with old (<2.3.3 glibc) which is ok in hardy (2.7.x). Normal boot in a vm looks ok and the testcases then pass. Just want to start up one instance to be even more convinced. [08:35] smb, sounds good, perhaps we can get one of the buildd peeps to test one [08:36] really when we push a hardy kernel into -proposed that should happen every time [08:36] apw, Questrion is whether they run anything i386 [08:37] probabally not, but worth asking, if not then we really are off the worry pile [08:37] Right, seeing it depends on libc, the version being ok, being able to boot already got me off it quite a bit [08:38] Just for completeness I will do a domU and push that kernel to ec2. If that all works I just push out the change for review [09:04] smb, sounds good to me [09:41] cking, moin [09:45] apw, hiya [09:47] apw: has the 2.6.38-9 natty kernel been rolled out as an update yet [09:58] eagles0513875: it's been superceded [09:58] on natty O_O by what though [09:58] 2.6.38-10-generic [09:58] for natty or for the next release [09:58] I'm still on Natty [09:59] I might have proposed enabled... [09:59] I suspect eagles0513875 means 2.6.38.9, rather than 2.6.38-9? [09:59] Ah, my mistake, if so [09:59] ya thats what i meant sry [10:00] eagles0513875, no -9 had regressions and was replaced with -10 [10:00] Though, 2.6.38.8 is the latest 'stable' as per lkml... [10:01] And twitter.com/gregkh [10:01] hi, experiencing g #397096 in up-to-date natty, does anyone know something about it? [10:01] "#Linux 2.6.38.8 kernel released. Last 2.6.38 kernel, it is now end-of-life, move to .39-stable." [10:03] apw: how come my netbook then in the ppa that had 9 in it is still on 9 and has not been upgraded [10:03] eagles0513875, which ppa are you using [10:04] apw: let me look it was the one you gave me when i was having atheros wifi issues [10:04] pre-proposed apw [10:06] eagles0513875, no idea why you haven't got an update unless you don't also have -proposed enabled [10:06] as the version in the pre-proposed ppa is [10:06] linux - 2.6.38-10.44pre201106070902 [10:06] let me cfheck [10:07] apw: proposed would be pre-released-updates in software sources [10:08] now i got it apw :D === Daviey is now known as Da === Da is now known as Daviey [11:29] apw: im upgrading my netbook to the ocelot lol [11:30] eagles0513875, good luck with that! [11:33] hows it looking so far [11:33] eagles0513875, not really running anything other than the kernel myself [11:33] shaky :) [11:35] great thank god i have nothing on this netbook lol [11:35] if a reinstall is in order so be it [11:41] not *that* shaky :) [11:42] * ppisati -> out to get some stuff [11:44] apw, how long does it take to build a debug kernel package - it's taking forever in dpkg [11:44] 15mins or so === chuck_ is now known as zul [11:45] on tangerine [11:45] owchy ouch ouch ouch [11:45] unless you _need_ them you can turn them off [11:45] I _need_ it - otherwise I would not be needlessly burning CPU cycles :-( [11:45] why is it *so* slow? [11:45] then, forever yes, its .5GB and dpkg has to compress it [11:46] ah [11:46] parallelized compression is required [11:47] you complain about 15min for a ddeb build [11:47] * apw suspects about an hour on armel [11:47] at least [11:47] * ogra_ thiks we really need to force cking into a 6month arm team rotation to develop more patience :P [11:47] noooooooooooooooo [11:48] * cking pretends to forget his ARM knowledge [11:48] heh [11:56] heh, takes less time to download than to create [13:06] herton, the mvl-dove rebase ... as it is you guys who put in the final tracking bug and actually close the release i suspect you are going to want to do that rebase... i've spent some time sorting out the rebase script so it works the same as the update-to-natty-master we use in the natty and maverick backports [13:07] * ogra_ doesnt get why we still have to maintain that kernel ... [13:08] apw: hmm ok, isn't ppisati running the script and pushing that to us? [13:14] herton, well we can do that, but its one of those silly round trips currently [13:14] he makes the open branch, pushed it, you close it for lucid [13:15] then he has to pull it, move it into maverick and push it again, then you have to change the tracking bug and check it and push it [13:15] * ogra_ shakes his head [13:15] as its a direct 100% copy of whats in lucid, it doesn't seem that sensible to ping-pong it like that ... to me anyhow [13:16] what you say makes sense. Is the script update-from-lucid-mvl-dove ? [13:32] herton: yes, it's that done [13:33] herton: i did the lucid->maverick once [13:33] herton: but it's not only about this script... ufff... [13:33] wait [13:35] we should really drop the maverick dove kernel ... it doesnt fulfill any purpose or has any users [13:37] ogra_, dunno mate, but when we talked before it had support for 18m and so we had to support it [13:38] apw, not for dove ... [13:38] ppisati, i pushed an updated script to the branch which actually works ... [13:38] the maverick dove support we did was solely for oem to make sure userspace works on dove ... the kernel they use is totally uncompatible to ours [13:38] herton, yes thats the one [13:39] ogra_, but it seems to be marked as supported in the support matric [13:39] apw: ok [13:39] ppisati, i tried to use it this morning and it ate my tree, so i fixed it up [13:39] apw, userspace ... i'll talk to david next week if we can drop the maverick dove kernel [13:39] lucid is still supported for 18 months though, there you are right [13:39] i remeber i had to do some git reset and then launching the script [13:39] ogra_, ok thanks, mostly its 100% the same as lucid, so [13:40] but if it works out of the box now, is much better [13:40] but having to go on with dove once lucid on arm is EOL is just insane [13:40] ppisati, right should just work now, it was always meant to [13:40] ogra_, indeed a fair point [13:42] ppisati, i feel that if it works as well as the lts ones, and it should, then it might be most expediant for herton to run it just cause he closes the lucid one and verifies that [13:42] herton: btw, what was the problem yesterday with the lucid/mvl-dove kernel? i mean, the create-tracker script [13:42] apw: ack [13:43] ppisati: the kernel tools looks at the git branch, and looks for changelog at debian., well that was the problem I had [13:43] just renamed the branch to what it was expecting [13:44] herton, which tools do that, really they should look at debian/debian.env to find out the 'branch name' [13:45] apw: create-release-tracker, which uses ktl/debian.py [13:45] herton, i think that should be fixed to use debian/debian.env if it exists [13:45] and actually now that karmic is gone if there isn't one then its debian [13:46] yep, or having a possible command line switch to override [14:14] regarding the buglink in the commit message of cve patches [14:14] some of them point to a real but ticket [14:15] e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601226 [14:15] Ubuntu bug 601226 in linux-fsl-imx51 "Unable to handle kernel NULL pointer dereference in ppdev module" [Undecided,In progress] [14:15] others point to the tracker bug of the release that contained that fix [14:15] e.g. [14:15] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/731226 [14:15] Ubuntu bug 731226 in linux "Lucid update to 2.6.32.32.14 stable release" [Undecided,Fix released] [14:15] but i guess we want just the first case, right? [14:17] hi: #397096 happens with 2.6.38-10, but with 2.6.38-9 does not, on my machine [14:20] ppisati: I think it should point to the cve tracking bug? [14:21] ppisati, CVE patches that we develop or integrate should have their own bug report, whereas stable updates are batched in one giant bug report. We often get CVE patches via stable updates, so we just need to mark the stable update tracking bug as having a CVE vulnerability. [14:22] tgardner: ok [14:22] tgardner: so the one pointing to a tracker bug, means we got them via stable update [14:23] ppisati, when you notice that a stable update solves a CVE, you should also note it in the changelog. [14:23] ppisati, yes [14:24] ppisati, apw has developed a script that pairs stable updates and CVE commits from mitre.org and has cleared out some of our backlog of CVE notices. [14:24] tgardner: ok, but then that particular patch that i cherry pick won't poing to "real" launchpad bug page, and thus i cannot add any $release/$branch to it [14:25] s/poing/point/ [14:26] tgardner: i mean, you told me that every CVE entry that i pushed should have the correspective $release/$branch in the launchpad bug page [14:26] tgardner, ok the 'final' 3.0 / 3.0.0.0.0 kernel / meta are built in my red ppa: https://edge.launchpad.net/~apw/+archive/red/+packages (as ~pre2) as its irrevocable if i get it wrong i wonder if you might review the packages produced for numbering etc [14:26] tgardner: but what if they point to a cve tracker? [14:26] ogra_, ^^ [14:26] ppisati, if you're doing a wholesale rebase against master then you can likely just add a package task (linux-fsl_imx51) to the original stable update tracker bug. Otherwise you should create a new stable update tracker bug. [14:26] sorry, tracker bug [14:27] tgardner: ok === pgraner is now known as pgraner-afk === pgraner-afk is now known as pgraner [14:28] apw, looking... [14:29] * tgardner wonders if pgraner is in a noisy air-conditioned space [14:29] meant to be around now i think [14:30] tgardner: and for every bug that get a new launchpad bug, i should push again to update the buglink, right? [14:30] apw, the east coast is having a heat wave, so it might be good place to be. [14:30] ppisati, yeah. you can just edit the commit logs and I can reset to your HEAD [14:31] tgardner, a heads up ... i've respun all the update-to-foo scripts in the lts-backports and in the maverick/mvl-dove branch to basically be the same script and fixed up a bunch of issues [14:32] tgardner, and i have been wondering if we should rename the files to debian/scripts/misc/update-to-my-upstream [14:32] apw, do they now all have a common ancestor in the debian repo ? [14:32] in all of them, so that there is a trivial way to tell if the branch has scripted updates and you know already what it is called [14:33] apw, never mind. ack to your last comment. [14:33] tgardner, good point, will do that now [14:33] i'll start a thread on u-k-t for that, so that stable is aware ... [14:35] tgardner, can we turn the emerald raid into jbos and try raiding it higher ... wonder if that might help [14:35] apw, I tried that on my emerald. didn't seem to make a difference [14:35] so its just a crap controller, thats poor [14:35] i.e., I exposed both drives as used LVM [14:36] s/as/and/ [14:38] poor indeed, hrmph [14:39] apw, push your packaging changes to oneiric master-next so I don't have to download the whole source package from your PPA. [14:44] tgardner, got any other solid use cases for overlayfs other than livecd ? [14:45] tgardner, trying to help shore up the request to merge [14:45] apw, hmm, its not really my domain of expertise :) [14:55] uhm [14:59] tgardner, other than the closing commit the master-next branch is up to date on linux [14:59] tgardner, and linux-meta master-next has the latest bits [15:04] apw: i can't switch to master to find the sha since i'm in a rebase in fsl-imx51 but [15:04] apw: http://markmail.org/message/dy5bldezg6e55tl7#query:+page:1+mid:4oi2w3bs76nwuxxw+state:results [15:04] apw: the buglink points to CVE 3875 and not 3876 [15:05] apw: but in any case, both of them are not that commit [15:05] wait [15:05] apw: 3876 is the correct one, nevermind [15:05] ppisati, ok [15:06] apw, what exactly did you want me to see when you pointed upwards ? [15:06] some patches fix more than one but get applied for hte first [15:06] ogra_, i suspect i wanted ogasawara to see something [15:06] heh [15:06] k [15:06] apw: yeah, i was fooled by the but description, thought it was the commit msg [15:06] s/but/bug/ [15:06] * ogasawara scrolls back [15:06] ogasawara, ok the 'final' 3.0 / 3.0.0.0.0 kernel / meta are built in my red ppa: https://edge.launchpad.net/~apw/+archive/red/+packages (as ~pre2) as its irrevocable if i get it wrong i wonder if you might review the packages produced for numbering etc [15:07] apw: yep, will look right now [15:07] tgardner, ok i've pushed the close out as well for master-next on ubuntu-oneiric for completeness [15:07] once you two are happy i'll hit the upload buttons [15:08] O_o how many zeros? [15:08] smb, 5 [15:09] smb, 5 digits on meta, as 3.0.0.1.5 < 3.0.1.5 ... so for meta we need to use 3 digits till we decide and for the kernel we need to use 2, in order to keep our options open [15:10] apw, update Vcs-Git to point to the correct repo [15:10] ahh right will do [15:11] 5 digits! [15:11] apw, well, it looks right as far as I can tell. [15:11] I though Linus wanted to reduce one digit [15:11] apw, the meta package bodge should work [15:12] amitk, 5 digits is just for meta package versioning [15:12] Seems in order to reduce we need to increase before being done [15:12] amitk, the meta package has alays had 5, it may reduce to 4 if we stick with the 2 digit kernel numbering [15:13] amitk, a number of tools are just not expecting the version number to stop being 3 digits, like ps, top, depmod [15:13] and till those are fixed we are in a difficult plac [15:13] x.y.z-abi.upload [15:13] thats the kernel numbering [15:13] which is x.y-abi.upload in the current package [15:13] apw, Oh right, meta was always strange. It just was not that obvious without that many zeros [15:13] we are hedging out bets [15:13] I small step for Linus, I giant step..... [15:14] :) [15:14] apw: looks good here [15:14] s/I/One [15:14] our bets, by taking the side which allows us to upgrade to the other, for the kernel 3.0 -> 3.,0.0 just fine and not the other way, for meta 3.0.0.1.5 -> 3.0.1.5 but not the other, so we are splitting our selves for now [15:15] FYI: It seems all recent proposed uploads of the kernel images strangely ended up in the universe of proposed... [15:15] as in not in main ? [15:15] linux-image-2.6.35-30-server | 2.6.35-30.53 | maverick-proposed/universe | amd64 [15:15] piti is trying to fix [15:16] nothing is going right is it [15:16] weird, how did that happen [15:16] maybe another we fix lp issue... [15:17] But that was the thing I noticed yesterday about uninstallable kernels [15:17] Just thought that to be delay on my side [15:18] ogasawara, fyi, if you have broken history and printchanges doesn't work (like it doesn't as we switch 2.x -> 3.0) you can now do fdr prev_release=2.6.39-3.10 insertchanges to override the search [15:18] (on the oneiric tree) [15:18] Oooo nice [15:19] * apw got sick of doing it by hand [15:21] tgardner, was that the only issure or are you still poking [15:22] apw, nah, I'm on to a support escalation bug. [15:22] so, I guess I'm done [15:22] tgardner, fun [15:22] hopefully not _that_ bug again... [15:23] smb, nope, its one of your DRM stable updates methinks. time will tell. [15:23] yiek [15:37] tgardner, which kernel is that escalation bug against? [15:37] bjf, lucid [15:38] bjf, sconklin, quick heads up, i've updated the update-from* scripts in the lts backport branches ... makes them quicker and easier on your repositories [15:38] just like to say that systemtap rocks [15:39] bjf, sconklin, i have also fixed up the one on the maverick mvl-dove so that it actually just works like the ones on the lts branches [15:39] apw, thanks [15:40] sforshee, bjf With that escalation bug. Be extra careful about versions. At least for the last few proposed uploads things seemed to have gone into proposed/universe instead of proposed/main [15:40] * ogasawara back in 20 [15:51] sconklin - i'm wondering why the tracking bugs for Maverick and Natty SRU's haven't been invalidated yet - aren't they being respun? [15:51] brendand, working on it [15:52] brendand, at this very moment as a matter of fact [15:52] bjf - correct me if wrong, but can't they be invalidated as soon as it's known there will be a replacement? [15:53] brendand, yes [15:53] git show Ubuntu-lts-2.6.38-10.44 [15:55] tag Ubuntu-lts-2.6.38-10.44 [15:55] UBUNTU: Ubuntu-2.6.38-10.44 [16:20] what is this? [ 1.356136] acpi device:4e: hash matches [16:20] I have 2 HP EliteBook 8530w laptops. 3 firewire EC cards work on one but not the other. I am trying to look for differences. I booted both, dmesg>d.txt, diff, that line is in one but not the other. [16:24] CarlFK, that is a piece of debugging which only has meaning if you had suspend debugging turned on, suspended and then hard booted out of suspend. [16:24] CarlFK, any other time it appears it is just random fluke... litereally some part of your clock matched something in the kernel and triggered that message [16:25] CarlFK: sounds more like the other fw card is just broken...does it even show in lspci and does the driver detect it? [16:25] it suspend debugging turned on in oneiric ? [16:26] CarlFK: and does the card work in another system? [16:26] BenC: 3 cards, they all work in one but not the other [16:26] and actually 3 cards work in 1, not work in 3 other boxes. [16:26] CarlFK: I'm a little ambiguous on what you mean... [16:26] 3 cards are all same make/model. [16:27] And they all work on one computer, but not another computer? [16:27] BenC: you should be becuase it doesn't make sense :) [16:27] yep. [16:27] thus my quest for what makes the one box special [16:27] CarlFK: and the other computer has the same kernel, same mobo, same cpu, etc? [16:27] yep [16:27] Then sounds like the other computer is broken :) [16:28] same BIOS version? [16:28] maybe reset the BIOS [16:28] I don't want to mess with the box where they work. else I may never get it back to that state, which would make me sad :) [16:28] But if you're not seeing any difference in dmesg other than that one line, it sounds like the BIOS is POSTing the same, else you'd see difference values for the PCI detection [16:29] CarlFK: reset the BIOS in the box that doesn't work [16:29] Or at least check the BIOS versions to see if they match [16:29] BenC: not a bad idea [16:30] biosdecode is the same on both, but it doesn't print much - not sure what that proves. [16:35] bios reset, fw (firewire) still broken. [16:36] CarlFK, not by default you have to ask for it on the kernel command line [16:38] apw, When installing a 3.0 kernel on Natty I get this message (as expected): 'dpkg: dependency problems prevent configuration of linux-image-3.0-0-generic: [16:38] linux-image-3.0-0-generic depends on module-init-tools (>= 3.13-1ubuntu1)' [16:39] this is gonna cause a huge pain in the ass for LTS backports. [16:39] unless we update m-i-t in Lucid [16:39] tgardner, yes either we'll have to use 3.0.0 there (as has been suggested) or we have to fix m-i-t in lucid [16:39] probabally the same patch could be applied, ie not update it much [16:39] and then have the right dependancy on the backoprt [16:40] apw, right, just something to keep in mind when you make the final version decision [16:40] tgardner, and the kernel won't boot if you install it without the right tools [16:40] yep i have a lits of known problem packages.. [16:40] tgardner, do we have cross compilers for oneiric yet? [16:41] (for tangerine chroots) [16:41] apw, should be. [16:41] make[4]: arm-linux-gnueabi-gcc: Command not found [16:41] lemme check, I'm sure I saw that upload go by [16:42] i386 seems to have half of it, no gcc frontends [16:43] apw, still seems borked: The following packages have unmet dependencies: [16:43] gcc-arm-linux-gnueabi : Depends: gcc-4.6-arm-linux-gnueabi (>= 4.6.0-8) but it is not going to be installed [16:43] bah, ok thanks [16:43] kees, smb, can you each add a comment to bug 788843 giving your input on there being a regression or not [16:43] Launchpad bug 788843 in linux "linux: 2.6.24-29.90 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/788843 [16:45] bjf, done [16:47] apw, try again. I updated and the package problems magically disappeared. [16:50] seems apw also disappeared magically. :-P [16:50] tgardner, looks better thanks [16:50] tgardner, did you do amd64 as well? [16:51] apw, both [16:51] tgardner, excellent [16:56] Grrr... so have all my window decorations after unity-window segfaulted... [16:56] smb, run unity again on VT1 [16:57] apw, That helped. Ta [17:03] wtf is up with launchpad today? it times out on everything [17:03] tgardner, They updated it === ogasawara_ is now known as ogasawara [17:04] smb, well, its freaking unuseable [17:05] tgardner, the topic in #launchpad seems to indicate they are aware of an issue and are working it [17:07] Hrmpf, as useful as unity shitting its pants just because I try to use a java-ikvm [17:13] tgardner, its been broke for most of the last 20 hours, no idea why the don't roll it back [17:45] apw, whoo hah! [ubuntu/oneiric] linux 3.0-0.1 (Accepted) [17:45] let the carnage begin. [17:45] /me waits for all the fallout [17:45] :) [17:45] yeah [17:47] right that'll take some hours so i am going to go drink some bubbles :) [17:47] apw, cheers. see you in a week [17:51] tgardner, have fun! [17:53] apw, ppisati: I run the updated script to update maverick mvl-dove, worked fine. I'm preparing it for pushing to the repo/create packages. [17:55] why are these different? < yenta_cardbus 0000:86:09.4: ISA IRQ mask 0x0cb8, PCI irq 22 > yenta_cardbus 0000:86:09.4: ISA IRQ mask 0x0c98, PCI irq 22 [17:59] bjf: done [18:01] kees, thanks [18:02] np :) [18:04] tgardner, will I run into you when I try to apply my cve patch to hardy? [18:06] smb, figuratively speaking ? [18:07] tgardner, or virtually. I was about to commit it but I saw some activity there. [18:07] smb, I've pushed apw's CVE patch, so you should be OK [18:08] tgardner, Ok cool. Just wanted to avoid both of us trying to push at the same time. :) [18:38] apw: fwiw, I've added linux-lts-backport-natty to uct. [18:43] tgardner, apw, the carnage has began, i have script failure due to version regex [18:56] * tgardner --> lunch [19:41] * tgardner --> server room [19:42] * jjohansen reboots :\ [20:05] * jjohansen -> lunch [20:19] bjf, is this indicative of an LP timeout ? [20:19] rtg@lochsa:~/ubuntu/ubuntu-lucid$ ~/kteam-tools/stable/create-release-tracker [20:19] https://bugs.launchpad.net/bugs/795219 [20:19] Traceback (most recent call last): [20:19] File "/home/rtg/kteam-tools/stable/create-release-tracker", line 281, in [20:19] app.main() [20:19] File "/home/rtg/kteam-tools/stable/create-release-tracker", line 237, in main [20:19] Ubuntu bug 795219 in linux-fsl-imx51 "linux-fsl-imx51: 2.6.31-609.26 -proposed tracker" [Medium,In progress] [20:19] t.assignee = self.lp.launchpad.people[taskAssignments[task]] [20:19] AttributeError: can't set attribute [20:19] tgardner, no, that can be an indication that you need to update your lpltk [20:20] bjf, how do I do that ? [20:20] bjf, it wasn't in a package, was it ? [20:20] no [20:21] you have to get the bzr repo and then run the setup.py script as root [20:21] i have a package in my ppa if you want to try it [20:21] tgardner, ^ === elmo__ is now known as k [20:21] https://launchpad.net/~brad-figg/+archive/kteam [20:21] tgardner, ^ === k is now known as Guest82647 === Guest82647 is now known as elmo [20:29] * ogasawara lunch === yofel_ is now known as yofel [21:10] tgardner: what are you doing with the fsl-imx tracking bug? Almost all status changes are automated and should be made by the bot, and if anything, you should be changing prepare-package after it's built in a PPA? I'm confused [21:12] sconklin, I didn't do anything but create it. LP is so freaking slow today that I haven't been able to make _any_ state changes. [21:15] tgardner: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/795219 perhaps it's issues with timeouts and LP UI that caused the status changes while you were trying to poke at it, sorry for griping, but that's the way it looked [21:15] Ubuntu bug 795219 in linux-fsl-imx51 "linux-fsl-imx51: 2.6.31-609.26 -proposed tracker" [Undecided,In progress] [21:15] tgardner, did the script complete? non of the assignements got done so i'm thinging it blew up [21:15] bjf, sconklin: no, the script didn't complete, not did the package install correctly. [21:15] nor* [21:16] then I got distracted chatting w/Pete [21:16] sconklin, i think that one is going to need some human love [21:16] tgardner: oh, yeah I hate when that happens. I usually just invalidate everything in the bug nd keep rerunning the script until it all completes. It's too easy to screw it up when you do stuff manually. [21:16] I'll fix it up. [21:17] sconklin, cool. I'm outta here. see you next week. [21:17] and eventually I'll write a "validate and fox" script [21:17] later! [21:17] tgardner: sorry! [21:17] (it is, quite literally, all my fault) [21:17] * tgardner thinks lifeless is buying beers next time :) [21:18] well, other folk have done a heap on the things we've improved - I am not taking their credit :) - but I will wear all the blame [21:18] its been working well until this morning (for me at least) [21:19] tgardner: so we add.d... [21:29] jjohansen: any luck with the wireless on the 3.0 kernel? [21:30] jcastro: haven't tried yet. I was going to try to give it a run tonight [21:31] jjohansen: either way I'm going to snag a dongle before ireland, and possibly bring a backup laptop on top of that. [21:31] jcastro: yeah, definitely [21:32] jcastro, one laptop, 2 partitions: part 1: natty; part 2: oneiric [21:33] bjf: the driver causes hard lockups in both. [21:33] ouch [21:34] jjohansen: don't bother putting an intel card in the minipci-e slot, I already tried that, heh. [21:35] jcastro: :( For dublin I was actually considering just getting a new battery and bringing my x61t [21:36] its a better machine to work from anyways [21:47] jjohansen: our bug got duped to this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/749871 [21:47] Ubuntu bug 749871 in linux "Attempt to Use Realtek RTL8192CE Wireless Causes Computer to Freeze" [Undecided,Confirmed] [21:47] but I have an RTL8188CE, should that matter? [21:53] jcastro: it might I am not sure, but it might. I need to dig more into the rtl drivers, and what the diff versions are [21:53] they have a newer driver for RTL8188CE than RTL8192CE on their website, might be worth a try - http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true [21:55] Sarvatt: indeed, thats one of the reasons I need to dig more into what drivers to what chipset etc [21:55] err guess i was looking at RTL8188CE-VAU [21:57] Sarvatt: I couldn't get the linux one building in oneiric. [21:57] Sarvatt: the point being they do have newer stuff, and I need to dig into the whole mess === Quintasan_ is now known as Quintasan [22:51] apw: still not drinking beer?