| === bjf is now known as bjf[afk] | ||
| === kentb is now known as kentb[out] | ||
| amitk | morning all | 07:18 |
|---|---|---|
| ikepanhc | amitk: good morning | 07:19 |
| jjohansen | morning amitk | 07:21 |
| amitk | hi ikepanhc, jjohansen | 07:21 |
| ikepanhc | jj never sleep... | 07:21 |
| === ivoks_away is now known as ivoks | ||
| amitk | security people never can... | 07:22 |
| amitk | ikepanhc: I hope you meant vacation instead of vocation in your email. Vocation is just more work :) | 07:24 |
| ikepanhc | eh..... | 07:25 |
| ikepanhc | ahley | 07:25 |
| ikepanhc | I must need more coffee | 07:25 |
| ikepanhc | next time I will write "day off" | 07:25 |
| ikepanhc | I sent two mail because after push the sent, I found my phone number is wrong... seems not only number is wrong | 07:26 |
| amitk | heh | 07:28 |
| smb | morning all | 08:37 |
| RAOF | Good morning. | 08:38 |
| AceLan | good morning | 08:38 |
| RAOF | Hm. Has the kms-disablement sauce for i8xx chips got lost somewhere in the Maverick changes? | 08:41 |
| smb | Guess we would need to use the SOURCE for that. :-P | 08:43 |
| RAOF | Perhaps I could phrase that in a slightly less passive way: Hm. The kms-disablement sauce appears to have got lost somewhere in the Maverick changes. Is this intentional? | 08:43 |
| smb | I probably can find out who committed the change, but I would not remember (if I ever knew) why. | 08:45 |
| === ivoks is now known as ivoks_away | ||
| smb | RAOF, So those rather seem to have vanished in either a rebase or rework of the tree. I think the best option here is to ask ogasawara when she comes online. | 09:01 |
| RAOF | Will do. Thanks. | 09:01 |
| jjohansen | smb: what do we need to do to kick the mainline builds? | 10:23 |
| smb | jjohansen, We should not need to do anything. Do we miss one? | 10:24 |
| jjohansen | smb: hrmm, I'm not sure. I am trying to figure out what is meant by "due to the kernel-package in ubuntu being broken once again, I can't build myself" | 10:25 |
| jjohansen | https://bugzilla.kernel.org/show_bug.cgi?id=16711 | 10:25 |
| ubot2 | bugzilla.kernel.org bug 16711 in ext4 "Oops with 2.6.36-rc1" [High,New] | 10:25 |
| smb | jjohansen, Need to look at the bug, maybe meaning the source package... | 10:25 |
| jjohansen | right maybe | 10:26 |
| smb | jjohansen, Is he really comparing 2.6.35-rc2 with 2.6.36-rc1??? | 10:27 |
| jjohansen | smb: I believe so | 10:27 |
| jjohansen | he report 36 rc1 and rc2 fail | 10:28 |
| smb | cannot see 36 rc2 from the upper level (if not hidden in the links) | 10:29 |
| jjohansen | smb: yeah mean neither I assum he did something manual for rc2 | 10:29 |
| * jjohansen questions the rc2 bit altogether | 10:30 | |
| smb | Well on the rc2 side of it is 35 not 36 | 10:30 |
| smb | at least in the text | 10:30 |
| smb | what he may mean is probably different | 10:31 |
| jjohansen | his last comment he mentions both rc1 and rc2 oopsing | 10:31 |
| jjohansen | first comment .35-rc2 works | 10:31 |
| smb | ah I see in the jpeg | 10:31 |
| jjohansen | yeah | 10:31 |
| jjohansen | I'll get him to clarify what is broken with the ppa | 10:31 |
| jjohansen | better than wasting time guessing | 10:32 |
| smb | I would not really be worried about a -rc1 oopsing, I rather be surprised it boots at all | 10:32 |
| smb | I thought apw changed it to have patches | 10:32 |
| smb | but let me check | 10:32 |
| smb | jjohansen, mainline build -rc2 is actually there | 10:33 |
| jjohansen | smb: well I am not particularly worried, I pretty much ignore anything before -rc3 | 10:33 |
| jjohansen | ah cool, I haven't really poked | 10:33 |
| jjohansen | My first concern was potential AA bug | 10:33 |
| jjohansen | second was kernel packaging being broken in some way | 10:34 |
| jjohansen | I would much rather him do the bisecting on something broken than us :) | 10:34 |
| smb | No I guess its "how can I compile the same" | 10:34 |
| smb | It should be possible with git and the patches that now are added | 10:34 |
| smb | Andy removed the source package as that was often useless | 10:34 |
| jjohansen | hrmm, /me is going to have to look into the packaging changes sometime | 10:36 |
| smb | jjohansen, Basically from the BUILD.LOG you get the sha1 -> 76be97c1fc945db08aae1f1b746012662d643e97 | 10:36 |
| smb | (which is Linus -rc2 commit in this case) | 10:36 |
| jjohansen | ah, sha1 for upstream kernel is good :) | 10:36 |
| smb | Then there are now 5 patches to add debian packaging and configs and whatnot. | 10:36 |
| jjohansen | gah, /me needs to look into overheating I've had my laptop shutdown twice today because of it | 10:38 |
| jjohansen | and the one time I had the cpu locked to low 800 MHz | 10:38 |
| smb | jjohansen, nast, you may be the hero of akgraner then. She got that too | 10:39 |
| jjohansen | heh, only if I figure it out | 10:39 |
| jjohansen | at least its easy to replicate | 10:39 |
| smb | Do fans at least try to cope with it or do they remain on low speed? | 10:40 |
| jjohansen | just let the flash player run :( | 10:40 |
| jjohansen | it seems they are remaining low speed | 10:40 |
| jjohansen | at least the time that I had the cpus locked to their lowest freq | 10:40 |
| smb | If the temp goes up I would expect them to go faster | 10:41 |
| jjohansen | yes, I would too | 10:41 |
| smb | Can be fun to track that. I think there have been cases which were a sde effect of accessing the ec the wrong way | 10:42 |
| jjohansen | yeah, it can be bios (unchanged), ec, acpi, ... | 10:42 |
| jjohansen | every stupid machine is different | 10:43 |
| smb | Yes, sadly | 10:43 |
| jjohansen | These are the frightening messages I get | 10:45 |
| jjohansen | Aug 25 18:49:20 ortho kernel: [ 5178.678361] Critical temperature reached (128 C | 10:45 |
| jjohansen | ), shutting down. | 10:45 |
| smb | At least thermal shutdown happens at some time. Though 128 seems a tad too high | 10:46 |
| jjohansen | yeah, quite hot | 10:46 |
| === yofel_ is now known as yofel | ||
| === smb is now known as smb-afk | ||
| === smb-afk is now known as smb | ||
| jpds | ls | 13:32 |
| === diwic is now known as diwic_afk | ||
| === kentb[out] is now known as kentb | ||
| guest1 | I got a problem running kernel 2.6.35 in Ubuntu 10.04 | 14:23 |
| smb | guest1 It might help to say what the problem is... | 14:26 |
| guest1 | PS/2 Keyboard and PS/2 Mouse dont work with X window system after I boot with 2.6.35 (custom compiled). | 14:26 |
| smb | Have you tried the backport 2.6.35 driver that is pre-compiled? In the kernel-ppa I believe | 14:27 |
| smb | https://launchpad.net/~kernel-ppa/+archive/ppa has a linux-maverick | 14:28 |
| smb | Actually I meant kernel when saying driver | 14:29 |
| guest1 | No. Actually I have an AMD Athlon II 245 system. Ubuntu work just perfect with the default kernel i.e. 2.6.32-24-generic. I downloaded kernel 2.6.35 from kernel.org and recompiled. Everything works fine in text mode. After running X, KB and mouse wont work. | 14:30 |
| * smb wonders why someone would compile a kernel when the default system works | 14:31 | |
| smb | And using a custom compile you may end up with options set differently which mean probably some drivers not configured... | 14:32 |
| guest1 | But I want to try Ubuntu with 2.6.35. Plz help. | 14:32 |
| smb | See ppa | 14:32 |
| smb | That is a 2.6.35 kernel | 14:32 |
| === simar__mohaar is now known as simar | ||
| guest1 | Ok. I will check that out. Thanks for the help. | 14:35 |
| === ivoks_away is now known as ivoks | ||
| === JFo is now known as JFo-swap | ||
| === amitk is now known as amitk-afk | ||
| === bjf[afk] is now known as bjf | ||
| === diwic_afk is now known as diwic | ||
| === sconklin-gone is now known as sconklin | ||
| === kentb is now known as kentb_dell | ||
| jcrigby | tgardner, just got your email | 15:46 |
| jcrigby | tgardner, when is drop dead time for sending you different update | 15:47 |
| tgardner | jcrigby, that really has more to do with the beta freeze rules from Linaro | 15:48 |
| jcrigby | ok | 15:48 |
| jcrigby | let me look and see if I can figure out what went wrong with the merge | 15:48 |
| jcrigby | I'll get back to you | 15:49 |
| tgardner | jcrigby, ok | 15:49 |
| jcrigby | what is lirc btw? | 15:49 |
| tgardner | jcrigby, infrared controller | 15:50 |
| jcrigby | ok, I saw some noise about that on kernel team list | 15:50 |
| ogasawara | RAOF: hi, just want to confirm with you the kms-disablement patches you're referring to are the following 6 patches - http://pastebin.ubuntu.com/484007/ | 16:14 |
| ogasawara | RAOF: as they do indeed appear to have been dropped from Maverick, now to investigate/remember why | 16:15 |
| jcrigby | tgardner, I just did a git diff of my head and don't see any missing debian stuff. http://pastebin.ubuntu.com/484025/ | 16:57 |
| jcrigby | tgardner, sorry diff of my HEAD and Ubuntu upstream | 16:58 |
| tgardner | jcrigby, I have 2 trees; Linaro-2.6.35-1003.7 and Ubuntu-2.6.35-19.25 checked out into separate directories. diff those to see what you come up with. | 17:00 |
| jcrigby | ok, maybe I sent you a bad pull request the linaro version should be 1004.8 | 17:03 |
| tgardner | jcrigby, or maybe I forgot to 'reset --hard FETCH_HEAD'. doh! | 17:05 |
| tgardner | diffing again.... | 17:05 |
| jcrigby | I was wondering about that. How to format a pull request that is a complete rebase | 17:05 |
| tgardner | jcrigby, ok, my bad. I totally screwed the pooch. its looks good to me. | 17:09 |
| jcrigby | tgardner, wonderful | 17:10 |
| jcrigby | tgardner, that is great news | 17:10 |
| jcrigby | and yes it did boot on beagle | 17:10 |
| jcrigby | tgardner, btw do you guys stop rebasing now | 17:11 |
| jcrigby | for maverick that is | 17:11 |
| tgardner | jcrigby, thats a bit up to ogasawara, but usually we won't reorder anything after Beta that has a tag. | 17:12 |
| jcrigby | ok, just hoping to avoid another mega rebase for awhile:) | 17:12 |
| ogasawara | tgardner, jcrigby: I actually have taken the approach to still rebase onto any upstream 2.6.35.y stable release | 17:13 |
| jcrigby | thats, fine. It gets easier each time I do this | 17:13 |
| tgardner | jcrigby, besides, rebases are good for the soul. it forces you to look at conflicts. | 17:13 |
| jcrigby | good point | 17:14 |
| jcrigby | I suppose I should try out git rerere so I can remember confict resolutions automatically | 17:15 |
| bjf | is there a way to look at the buildd queues, i'm curious to why it's taking so long before my source uploads are building | 17:21 |
| tgardner | bjf, you're meaning the PPAs, right? | 17:22 |
| smb | httos:launchpad.net/builders | 17:22 |
| smb | errr | 17:22 |
| smb | https://launchpad.net/builders | 17:22 |
| tgardner | hmm, thats kind of a handy link | 17:24 |
| bjf | tgardner: yes, and smb, thanks for the link | 17:25 |
| smb | welcome | 17:25 |
| bjf | smb, is there a link that shows the amd64 ppa job queu (so I can see exactly where I am in the queue right now)? | 17:38 |
| smb | bjf, I don't know a good one, only the general build score, but that does not really mean much | 17:40 |
| bjf | smb, ack | 17:40 |
| smb | maybe lamont knows some magic that apprentices can use | 17:40 |
| lamont | bjf: the ppa queue is not exposed in the api... /ubuntu/maverick/amd64/+builds (or maybe /u/a/m/+b) is the queue for a given distroarchseries | 17:42 |
| lamont | and laggy in a meeting | 17:42 |
| jdstrand | smb, jjohansen, lamont, elmo: fyi, I just unembargoed the fix for xen | 17:42 |
| lamont | jdstrand: woot. I'll kick them ppas shortly | 17:43 |
| smb | jdstrand, Cool | 17:43 |
| jdstrand | smb: nice work. I know that was rather painful | 17:44 |
| jdstrand | smb: and thank you again :) | 17:44 |
| * lamont remembers to wait for the publisher run | 17:44 | |
| jjohansen | jdstrand: thanks, and smb yes very nice work | 17:45 |
| smb | Sort of a Murphy issue, anything that could be wrong was wrong. o_O | 17:45 |
| smb | tgardner, About the packaging, maybe we should ask about that. Probably the replaces is not needed because the 35 package is not an upgrade path to the 34 package. But maybe I have not grasped the whole concept | 17:48 |
| tgardner | smb AFAIK the conflicts forces you to remove the conflicting package _first_ before you are able to install the new package. thats the primary behavior I'm interested in. | 17:49 |
| smb | Right and the Replaces causes the old one to get actually removed when you are updated via the meta files. I just want to prevent us showing the next package and being told of again | 17:51 |
| tgardner | smb, I'm reading the Debian policy manual... | 17:52 |
| tgardner | smb, but there is no meta file upgrade path. you'll have to explicitly change from compat-wireless-2.6.34 to compat-wireless-2.6.35 | 17:54 |
| tgardner | smb, another issue with replaces is that it only replaces files, not packages. | 17:55 |
| smb | right, that would be point to have that requirement only for compat-wireless-2.6.34 as that will upgrade | 17:55 |
| smb | hm, I probably should read the manual myself | 17:56 |
| ogasawara | lag: I'm adding your SOB to the arm patches for 613855 | 17:56 |
| tgardner | yes, so I think the current combination of conflicts and replaces is correct. | 17:56 |
| tgardner | smb, http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces | 17:56 |
| lag | ogasawara: That would be fine, thank you | 17:56 |
| smb | So thats the 7.6.2 usage | 17:57 |
| tgardner | I think so, though I don't really understand the mail-transport-agent example | 17:59 |
| smb | Its a bit complicated because its for virtual packages | 18:00 |
| smb | But I think it declares to provide bla and conflict and replaces it. So when you install this packages it would uninstall all other packages that provide bla | 18:01 |
| tgardner | well, I think I want the behavior to be explicit. no automatic replacement, etc. you'll have to explicitly remove the conflict. | 18:02 |
| smb | Most of the time yes, so the only time this should happen is when I have lbm-wireless-generic installed and the new meta package points to lbm-compat-wireless-... | 18:03 |
| tgardner | smb, correct. | 18:04 |
| smb | Which is what is done so you were right that only the conflicts is needed for the other package | 18:04 |
| smb | I got it now as well | 18:04 |
| tgardner | once we're on to the next ABI series, then this is no longer a problem | 18:04 |
| smb | right, if people want to change, they should make that decision knowingly | 18:05 |
| smb | And I think that would be all we were asked to. I would just take what you had pushed and make the adaption for the conflicts and buglink | 18:06 |
| tgardner | don't I have a public buglink? or did I get the wrong one? | 18:07 |
| smb | No I thought you said you forgot to add a buglink on the latest patch | 18:07 |
| smb | I mean yes you have the public bug in the mail | 18:07 |
| tgardner | I amended and re-pushed | 18:07 |
| smb | ah ok | 18:07 |
| smb | Then lets do lbm try 3 | 18:08 |
| achiang | can someone help me to understand kernel package names vs. the actual kernel binary? output from dpkg -l gives, e.g. linux-image-2.6.32-24-generic 2.6.32-24.41, | 18:18 |
| achiang | so from that, i understand that 24 is the ABI version and .41 is the build number | 18:18 |
| tgardner | achiang, so far, so good. | 18:19 |
| achiang | my question is, in practice, do we ever increase the build number without also changing the ABI? | 18:19 |
| achiang | e.g., would we ever ship a 2.6.32-24.42 ? | 18:20 |
| tgardner | achiang, no, though the build number is completely arbitrary, the ABI number is not. | 18:20 |
| tgardner | oh, lemme back up a littlwe | 18:20 |
| smb | But we increase the build number without abi bum | 18:20 |
| tgardner | yeah, what smb said | 18:20 |
| smb | In fact we know should have an 2.6.32-24.42 in proposed | 18:21 |
| tgardner | bump* | 18:21 |
| smb | yep | 18:21 |
| achiang | ok, i think i understand. all kernel updates that do *not* require an ABI bump will simply have an increased version number, which dpkg --compare-versions would understand to be greater, right? | 18:22 |
| achiang | and that's how apt would know to pull down and install the new, updated package? | 18:22 |
| tgardner | achiang, correct | 18:22 |
| smb | yep | 18:22 |
| tgardner | achiang, and when the ABI bumps, then we update the meta package so that it references the _new_ package | 18:23 |
| achiang | is there any way to get the ubuntu version number out of vmlinuz? or is that only stored in the debian packaging? | 18:23 |
| smb | The build/upload number _always_ increments, though not always by 1 | 18:23 |
| achiang | nod | 18:23 |
| smb | You see it in uname -a | 18:23 |
| tgardner | and in /proc/version_signature | 18:23 |
| achiang | smb: no, you only see the package name, not the version string | 18:24 |
| smb | Linux maximegalon 2.6.32-25-generic #43 | 18:24 |
| achiang | maybe my terminology is messed up | 18:24 |
| achiang | oh! | 18:24 |
| achiang | duh | 18:24 |
| smb | So this is 2.6.32-25.43 | 18:24 |
| achiang | darn, i can't pass an arbitrary kernel path to uname | 18:25 |
| smb | err, why would you want to do that? | 18:26 |
| achiang | tgardner: smb: ok, thank you for the explanations, they make sense. | 18:26 |
| achiang | smb: i am doing some evil stuff for an OEM customer's customized system update tool. don't ask, it's horrible. | 18:27 |
| * smb puts his fingers into his ears | 18:27 | |
| achiang | smb: well, conceptually, i want to know: "is this kernel newer than that kernel?" | 18:29 |
| * smb still cannot hear achiang | 18:29 | |
| achiang | where "this kernel" might live somewhere in the filesystem (not /boot/) and "that kernel" is typically the one in /boot/ | 18:30 |
| smb | But yeah, basically you can compare version numbers, newer always inclrements. With the + and ~ magic of course | 18:30 |
| achiang | but the version numbers don't really live anywhere, except in the debian packaging; or by combining some fields from uname | 18:31 |
| smb | so 2.6.32-24.41~pre1 comes before 2.6.32-24.41 | 18:31 |
| smb | Well that information is in the kernel image too. If you boot you see it. In dmesg | 18:32 |
| achiang | but certainly, if you saw /boot/vmlinuz-2.6.32-24-generic you could not figure out if it was newer or older than /my/special/path/vmlinuz-2.6.32-24-generic | 18:32 |
| smb | not from that filenames alone | 18:33 |
| achiang | because the kernel in /my/special/path might have a greater version number, but it's not easy to figure out. unless maybe you use strings and grep | 18:33 |
| smb | right strings and grep will work | 18:34 |
| achiang | is there a case to be made for incorporating the version number into the file name (instead of merely package name) for generic ubuntu? or is my use case truly unique? | 18:34 |
| achiang | obviously not for this cycle, but for future cycles | 18:35 |
| smb | no, as the parts that are used now are used for modules dir and we certainly don't want separate directories for each upload | 18:36 |
| achiang | i guess basing the filename on package name makes life a little easier in the non-ABI change case | 18:36 |
| achiang | ah, that makes sense too, re: modules | 18:36 |
| smb | I guess this is just a very special usecase, but I tried strings/grep and it looks quick and simple (as long as you are not truely evil and want to do the same for old releases like Hardy ;-)) | 18:38 |
| achiang | smb: actually, yes, i sadly do need a solution for hardy as well | 18:40 |
| * smb runs away | 18:41 | |
| achiang | smb: hm, strings seems to work on a hardy kernel | 18:44 |
| achiang | strings vmlinuz-2.6.24-27-lpia | grep '2\.6\.'2.6.24-27-lpia (buildd@midyim) #1 SMP Thu Apr 8 18:04:46 UTC 2010 | 18:44 |
| achiang | oops, the output is garbled | 18:44 |
| achiang | there should be a newline after grep '2\.6\.' | 18:44 |
| smb | no it does not. its aways #1 | 18:47 |
| achiang | urk | 18:48 |
| * achiang runs to wherever smb is running | 18:48 | |
| * tgardner lunches | 18:51 | |
| === bjf is now known as bjf[afk] | ||
| * jjohansen -> lunch | 19:50 | |
| ogasawara | tgardner: when beta freeze lifts next week, could I get you to help me upload pciutils (just need to update the pci.ids file). | 20:08 |
| ogasawara | tgardner: it's for bug 601079 | 20:08 |
| ubot2 | ogasawara: Bug 601079 on http://launchpad.net/bugs/601079 is private | 20:08 |
| tgardner | ogasawara, funny you should mention taht. I uploaded pciutils about 20 minutes ago | 20:09 |
| ogasawara | heh awesome | 20:09 |
| ogasawara | tgardner: I'll just mark that fixed then | 20:09 |
| tgardner | ogasawara, yep, I think thats a safe move | 20:10 |
| tgardner | ogasawara, are you subscribed to maverick-changes@lists.ubuntu.com ? | 20:10 |
| ogasawara | tgardner: I'm not at the moment, but I'll subscribe now so I see the notices | 20:11 |
| tgardner | its a good way to survey what kind of development activity is going on | 20:12 |
| === bjf[afk] is now known as bjf | ||
| * ogasawara lunch | 20:21 | |
| === ivoks is now known as ivoks_away | ||
| DJAshnar | Any plans to incorporate the kernel patch for the damn Toshiba Sattelite ACPI/DSDT bug causing us to be forced to turn of ACPI and then only run ONE cpu core? http://bugzilla.kernel.org/attachment.cgi?id=23958 | 20:56 |
| * DJAshnar hears crickets | 21:00 | |
| * DJAshnar stomps on em | 21:00 | |
| bjf | DJAshnar: it looks like that patch is already in maverick | 21:14 |
| bjf | DJAshnar: though not in the form of the link you gave | 21:14 |
| DJAshnar | on my Sattelite c655d s5057, it hangs on ACPI on boot unless I use the older patched kernel | 21:15 |
| DJAshnar | booting the generi kernel in maverick just leaves me a blank screen. I have a radeon 4250 chipset if that helps | 21:17 |
| bjf | DJAshnar: that's likely a different issue | 21:17 |
| bjf | DJAshnar: try rebooting, hold down the left shift key to get into grub and remove "quiet spash" from the boot command line | 21:18 |
| DJAshnar | no joy | 21:20 |
| achiang | DJAshnar: well, do you now get debug output on your screen? | 21:21 |
| DJAshnar | no | 21:21 |
| achiang | DJAshnar: were you able to get into grub and edit the kernel command line? | 21:22 |
| DJAshnar | yup | 21:23 |
| achiang | DJAshnar: hm, weird. try repeating, and add "ignore_loglevel earlyprintk=vga" | 21:25 |
| achiang | so "quiet splash" should go away and the other two should be added | 21:25 |
| DJAshnar | just a black screen... | 21:26 |
| achiang | DJAshnar: hm, maybe the earlyprintk argument was wrong. maybe just remove it completely, actually | 21:30 |
| achiang | but do keep ignore_loglevel | 21:30 |
| DJAshnar | no luck | 21:42 |
| achiang | that seems rather bad, and i'm out of ideas, sorry | 21:52 |
| kees | I love the daily upstream kernel debs. very handy! | 21:54 |
| DJAshnar | how can I update the kernel daily? | 21:55 |
| tgardner | kees, I've opened the natty repo, but I've not really advertized it yet | 21:55 |
| kees | tgardner: oh! very cool. I guess I should start rebasing nx-emu and yama... | 21:55 |
| tgardner | kees, I dropped the nx emulation patches for now. had some conflicts, so I need to get back to it | 21:56 |
| kees | tgardner: okay, I'll go poke at it. | 21:56 |
| DJAshnar | cannot reserve MMIO region... wth? | 21:59 |
| \_^_\ | bjf: We chatted recently about bug #616501 and you told me that this will be part of some review by kernel team. Do you know what came out of this review? | 22:34 |
| ubot2 | Launchpad bug 616501 in linux (Ubuntu) "Kernel > 2.6.32-20 doesn’t boot, /dev/disk/by-uuid/... not found (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/616501 | 22:34 |
| bjf | \_^_\: yes, i'm embarrassed to say it didn't happen, we will do it monday a.m. | 22:45 |
| bjf | \_^_\: it's on our list, we just need to talk about it | 22:45 |
| \_^_\ | bjf: OK, thanks a lot. :) | 22:46 |
| bjf | \_^_\: np | 22:46 |
| === sconklin is now known as sconklin-gone | ||
| === bjf is now known as bjf[afk] | ||
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!