| JanC | maco: that sounds like broken hardware to me | 00:12 |
|---|---|---|
| === Tim-away is now known as TimStarling | ||
| maco | JanC: yes, i know it sounds like broken hardware. the confusing bit is that he says on two separate motherboards, there were no problems at all until he installed ubuntu. | 01:54 |
| maco | i cant figure how changing OSes could do that, but I figured if anything has the hardware access necessary, it'd be the kernel | 01:59 |
| JanC | on my previous job we had on average 2 PCs or laptops dying like that every week, and there was only Windows on those systems ;) | 02:00 |
| JanC | (but of course there were a couple of thousand systems there) | 02:00 |
| JanC | also, changing OS causes a lot of stress on a system | 02:01 |
| JanC | most systems are idling 99% of the time, and then suddenly it has to do real work | 02:04 |
| maco | so you think the install process overtaxed a low-quality system? | 02:06 |
| JanC | maco: I think the system was already dying, but just got the last push | 02:22 |
| JanC | of course there is no proof that ubuntu didn't cause this, but if it did, it clearly only happens under some rare conditions | 02:24 |
| dtchen_ | some of these conditions aren't so rare | 03:01 |
| dtchen_ | twiddling the registers on an entire revision of sigmatels shipping in Creative Sound Blaster Lives can brick the card | 03:02 |
| JanC | dtchen_: what I meant was that their occurence must be very low | 03:04 |
| JanC | it's not like you'll twiddle those registers on purpose ツ | 03:06 |
| dtchen_ | but you would if you ever set the Tone control. | 03:08 |
| JanC | you mean this bricking is built-in feature of that card | 03:08 |
| dtchen_ | it's worked around in the Windows drivers by explicitly disabling ever turning off the Tone control ;) | 03:08 |
| JanC | fun | 03:09 |
| JanC | but if that happens often there will be lots of bug reports / blog posts / etc. | 03:11 |
| JanC | not 2 people with 3 dead systems that don't even show the same symptoms | 03:12 |
| smb_tp | The problem currently is that the only visible hint with that "black screen" issue is that it seems those affected got multiple ACPI: Video entries with the -12 kernel but only one with the -13 | 09:25 |
| smb_tp | I have not found anything directly touching this. There has been one change that adds instances in the VGA case but that is not changing things. | 09:26 |
| smb_tp | I tried to see whether it could possibly be the acpi integer change that converts that type to 64 bit, but the only response how that changes things is a bit fuzzy | 09:27 |
| smb_tp | It would be helpful to know what NVidia changed from 173 to 180 but they are not very specific what exactly changed | 09:28 |
| smb_tp | The only other changes to acpi/video* have been backlight issues and IIRC there are reports from desktop system as well. And I think its unlikely those got _BCL entries | 09:30 |
| apw | smb_tp, don't suppose they do have _BCL no | 09:31 |
| apw | so which mainline updates are in that -12 -> -13 transition? | 09:31 |
| smb_tp | Quite a few. But mostly other areas. Lemme check | 09:32 |
| apw | Ubuntu-2.6.27-12.282.6.27.13 | 09:32 |
| apw | Ubuntu-2.6.27-13.292.6.27.18 | 09:32 |
| apw | (from leanns list http://kernel.ubuntu.com/~ogasawara/kernel-version-map.html) | 09:32 |
| smb_tp | Yep, those are the ones in the changelog as well | 09:33 |
| apw | so there are loads in there, so it would be entirly legitimate to ask people to try the mainline kernels 14, 15, 16, 17, 18 | 09:33 |
| smb_tp | You have lrm for those? | 09:33 |
| smb_tp | But ok, for intrepid its a dkms package for nvidia and ati | 09:34 |
| apw | no | 09:34 |
| smb_tp | It looks very much as those binary drivers are having problems | 09:34 |
| apw | and they will fail dismally as the ABI is a mad number i assume | 09:35 |
| apw | right ... i guess i will drop off now and reboot into this kernel and see if it hits me | 09:35 |
| smb_tp | It might work, but you would need the headers for that mainline kernels, I guess | 09:38 |
| smb_tp | Ok | 09:39 |
| apw | smb_tp, ok that kernel was fine on my intel based laptop so ... no help there | 09:50 |
| apw | smb_tp, we do have headers for the mainline kernels | 09:51 |
| smb_tp | Ok, thanks anyways. I try mine here. So it might be an option. I have to fight one of my systems up and then whethher ths works | 09:52 |
| apw | smb_tp, hehe always a nightmare ... work damn you machine | 10:23 |
| smb_tp | apw, Well I am not innocent. There is never a good time for some maintenance... Got it up now. But I pretty much think this system is just too old for being affected. There is no acpi video driver entry for me and all wrks charmingly _with_ the 177 nvidia driver. :-/ | 10:30 |
| apw | so we are out of test kit basically for that, down to the bug submitters now | 10:35 |
| smb_tp | Look like it. Got some new gear coming but that won't be today | 10:38 |
| smb_tp | Darn, there is one other thing different. The good case uses VT7 the bad case VT9. At least for the one reporter were I got logs | 10:44 |
| === thegodfather is now known as fabbione | ||
| apw | VT9 ? | 11:07 |
| apw | who uses VT 9 for anything ever | 11:07 |
| Keybuk | I use VT14 | 11:08 |
| === elmargol_ is now known as elmargol | ||
| apw | Keybuk, hey you replied on my ifupdown upload that i had missed an update, and essentially need to do it again | 11:51 |
| Keybuk | apw: I did, can you remember what I said? :p | 11:51 |
| apw | where might i have found that in order to avoid that happening again | 11:51 |
| Keybuk | you mean the -Q thing? | 11:51 |
| apw | Note that the next upload of modprobe removes -Q entirely | 11:51 |
| apw | So you might want to take that into account with your upload ;) | 11:51 |
| Keybuk | ahh | 11:51 |
| apw | oh its modprobe, hrm | 11:51 |
| Keybuk | only by following the IRC discussion ;) | 11:51 |
| apw | so thats module-init-tools | 11:52 |
| Keybuk | yeah | 11:52 |
| apw | so i couldn't have known hmmm | 11:52 |
| apw | got a bug number for that one? | 11:52 |
| Keybuk | no? | 11:52 |
| Keybuk | it's not a bug | 11:52 |
| Keybuk | it's a patch we had which was rejected upstream | 11:52 |
| Keybuk | after some discussion I decided that upstream was right | 11:52 |
| Keybuk | I'll just fix the packages that still use -Q as I go | 11:52 |
| apw | hrrmmm ... -Q was discarded ... ok ... so whats the approved form | 11:52 |
| Keybuk | modprobe -b <module name> | 11:53 |
| apw | and the output? do we want that? | 11:53 |
| Keybuk | if you don't want output | 11:53 |
| Keybuk | modprobe -q -b <module name> | 11:53 |
| apw | isn't that what -Q brought? | 11:53 |
| Keybuk | -Q was like -q but more so, the correct solution was just to fix -q ;) | 11:53 |
| Keybuk | turned out the main error we cared about was just the blacklist one, which was added by a patch! | 11:53 |
| Keybuk | you'll want || true if you want to ignore failures, of course | 11:54 |
| apw | yeah -Q is -q + more slicence | 11:54 |
| Keybuk | but then at this point I'd start asking why you're calling modprobe at all | 11:54 |
| Keybuk | I didn't actually ask that before | 11:54 |
| Keybuk | userspace should never need to call modprobe | 11:54 |
| apw | i didn't ask that either! | 11:54 |
| Keybuk | it looks like it's doing it for ipv6 | 11:54 |
| Keybuk | which we build in <g> | 11:55 |
| apw | yep, to pull in ipv6, not sure if that might be reasonable | 11:55 |
| apw | as in reasonable to probe | 11:55 |
| apw | well i think it is built in now | 11:55 |
| Keybuk | (and if you didn't build it in - it'll be automatically pulled in anyway because ipv6 has a net-pf-10 alias) | 11:55 |
| Keybuk | ie. socket(PF_INET6, ..., ...) results in the _kernel_ calling modprobe ipv6 | 11:55 |
| Keybuk | well | 11:55 |
| Keybuk | modprobe pf-net-10 | 11:55 |
| Keybuk | which translates to ipv6 | 11:55 |
| apw | but its reasonable to probe it, builtin or not, if its resonable to probe it when its a module at least | 11:55 |
| apw | i can see how this might be a reasonable place to do that as its making new interfaces and the like | 11:56 |
| apw | hrrm | 11:56 |
| apw | how to tell is the question | 11:56 |
| === pgraner-afk is now known as pgraner | ||
| Keybuk | ifupdown (0.6.8ubuntu3) feisty; urgency=low | 12:00 |
| Keybuk | 12:00 | |
| Keybuk | * ifupdown.nw: modprobe ipv6 before configuring it. | 12:00 |
| Keybuk | (Closes LP: #7091) | 12:00 |
| Keybuk | -- Fabio M. Di Nitto <fabbione@ubuntu.com> Fri, 30 Mar 2007 08:54:50 +0200 | 12:00 |
| Keybuk | that modprobe call is an Ubuntu patch to begin with | 12:00 |
| apw | bah | 12:01 |
| Keybuk | I suspect looking briefly at this that Fabio's debugging was wrong | 12:01 |
| Keybuk | the real problem was that the old modprobe.d "alias net-pf-10 ipv6" line got commented out around the same time | 12:02 |
| Keybuk | but hadn't turned up in the kernel yet | 12:02 |
| Keybuk | certainly removing ipv6 | 12:02 |
| Keybuk | and running ifconfig | 12:02 |
| Keybuk | brings the module back | 12:02 |
| apw | could you send me an strace output of that happening | 12:04 |
| apw | i'd like to know why its doing that before i rip out the call | 12:04 |
| apw | (thanks) | 12:04 |
| Keybuk | how do you mean? | 12:07 |
| apw | i meant re-remove ipv6 and then strace the ifconfig which brought it back | 12:08 |
| apw | ifconfig source still claims: | 12:08 |
| apw | "ifconfig eth0 add ..." does not currently auto-load the IPv6 module. | 12:08 |
| apw | but its sounding like its wrong | 12:08 |
| apw | wanted to 100% confirm its loading for the right reason | 12:09 |
| Keybuk | hmm, let me try this harder | 12:10 |
| Keybuk | it may have come back for other reasons (ie. running apps) | 12:10 |
| apw | or incoming packets or all sorts | 12:10 |
| Keybuk | yeah, maybe | 12:11 |
| apw | was one reason i left it in, even so | 12:12 |
| apw | now we are checking tho | 12:12 |
| Keybuk | if we still need it, then that line should be | 12:15 |
| Keybuk | modprobe -q -b ipv6 || true | 12:15 |
| apw | right | 12:16 |
| apw | a agree with that | 12:16 |
| apw | if only i could tell if we need it at all | 12:16 |
| apw | arrgg | 12:16 |
| Keybuk | ok | 12:16 |
| Keybuk | best way to debug this ;) | 12:16 |
| Keybuk | move the ipv6 module out of the way | 12:16 |
| Keybuk | and reboot | 12:16 |
| Keybuk | without any network | 12:16 |
| Keybuk | then put the module back | 12:16 |
| Keybuk | wait and see if it loads itself | 12:16 |
| Keybuk | if not, then do an ifconfig | 12:16 |
| apw | and for that i'd need a kernel which doesn't have it in ... pththth | 12:17 |
| * Keybuk remembers to stop NM | 12:17 | |
| * apw guesses Keybuk is testing | 12:20 | |
| Keybuk | ok, interesting | 12:24 |
| Keybuk | ifconfig will only open an AF_INET6 socket if /proc/net/if_inet6 exists | 12:25 |
| Keybuk | so it specifically doesn't allow autoloading | 12:25 |
| Keybuk | which is a bit odd | 12:25 |
| apw | i saw that pathname in it | 12:25 |
| apw | ok ... so thats _stupid_ | 12:25 |
| apw | but for the purposes of this fix, it should stay i guess | 12:25 |
| Keybuk | it makes kooky sense | 12:25 |
| Keybuk | ifconfig is just written wrong | 12:26 |
| apw | does seem so doesn't it | 12:26 |
| apw | so for the bug i am fixing would you be happy with it being in there | 12:26 |
| Keybuk | it doesn't know what the address is until it knows what support there is in the kernel | 12:26 |
| Keybuk | because you don't _say_ inet6 in the ifconfig invocation | 12:26 |
| Keybuk | ::1 could be several different types of addresses | 12:26 |
| apw | no point in me doing the upload if you are going to be unhappy :) | 12:27 |
| apw | hmmm so is it checking for ipv6 to see if the addy should be ipv6 sort of thing | 12:27 |
| apw | thats vile. the bug is that you don't say | 12:27 |
| apw | ifconfig eth0 ipv6 ;:1 | 12:27 |
| Keybuk | even if you say, it doesn't assume ;p | 12:27 |
| apw | nnnng | 12:28 |
| apw | thats pure-evil | 12:28 |
| Keybuk | anyway | 12:28 |
| Keybuk | yes | 12:28 |
| apw | ifconfig-cryptonite | 12:28 |
| Keybuk | that modprobe has to say ;) | 12:28 |
| Keybuk | stay | 12:28 |
| Keybuk | do you want to do that upload or shall I? | 12:28 |
| apw | ok will respin that debdiff and get back to you | 12:29 |
| apw | good practice | 12:29 |
| apw | Keybuk, there is little enough reason for a kernel dev to do other packages, so its worth me getting my hand in | 12:38 |
| apw | Keybuk, ok i've attached a new debdiff to the bug: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/107432 | 13:18 |
| ubot3 | Malone bug 107432 in ifupdown "modprobe -Q is not 'silent enough' / ifup is too picky about return status." [Medium,In progress] | 13:18 |
| apw | has been tested in my ppa on a box i have setup for this bug | 13:19 |
| === mnem0 is now known as mnemo | ||
| Keybuk | apw: you didn't patch inet6.defn? | 13:29 |
| apw | no that file is generated from the .iw file | 13:29 |
| * apw goes reconfirm | 13:30 | |
| Keybuk | ah, I can't remember which way round that is ;) | 13:30 |
| Keybuk | you're probably right | 13:30 |
| apw | let me make absolutly sure | 13:30 |
| apw | yeah it seems to be rebuilt when i do a -b | 13:33 |
| apw | but i wonder why its in the package at all if its generated | 13:33 |
| apw | Keybuk, this whole package is full of voodoo magic, this spec to .c converter is majorly vile | 13:38 |
| Keybuk | I'd run a build and then make the source after the build | 13:39 |
| Keybuk | just to make grep happy | 13:39 |
| apw | ok ... | 13:39 |
| apw | hrm, thats thrown up something odd | 13:40 |
| apw | a change gone away, /me investigates | 13:41 |
| apw | Keybuk, ahh ok, Jamesw didn't commit the changes to the generated files when he did his changes in 0.6.8ubuntu11, so my diff becomes poluted by those | 13:45 |
| apw | i assume you are happy with that pollution | 13:45 |
| apw | (or i guess i could hand hack it off) | 13:46 |
| Keybuk | yeah I'm happy with that ;) | 13:48 |
| apw | Keybuk, ok its attached to the bug ... hope this one is good :) | 13:52 |
| Keybuk | you want sponsorship for that? :) | 13:52 |
| apw | heheh please | 13:53 |
| Keybuk | apw: uploaded | 13:58 |
| apw | Keybuk, you are a scholar and a gentleman | 13:59 |
| Keybuk | np :p | 13:59 |
| mjg59 | Keybuk: http://kernel.ubuntu.com/git?p=scott/ubuntu-jaunty.git;a=commit;h=6c505f59997e6099535e2ea5409fececdaa87a57 - cdc_acm is a USB driver. How would you ever get a situation where the device node and hardware exist, but the module isn't loaded? | 14:50 |
| Keybuk | mjg59: I was just being thorough | 14:50 |
| Keybuk | there was a char-major-166-* for that one in every single distro's modprobe.conf files | 14:51 |
| Keybuk | I'm perfectly happy for ANY of those to be rejected on the grounds of "no, we really don't need that" | 14:51 |
| mjg59 | I don't think many of them make sense in a udev world | 14:51 |
| Keybuk | which serves as equal justification for removing the line from modprobe | 14:51 |
| Keybuk | I agree | 14:51 |
| Keybuk | but the kernel still has them for most drivers | 14:51 |
| Keybuk | in fact, there seems to have been attempts to put them all in where they were missing where the driver has a hardcoded device major | 14:52 |
| Keybuk | I figured someone in the moblin world or similar was doing it | 14:52 |
| mjg59 | Heh | 14:52 |
| mjg59 | Well, it's all harmless enough | 14:52 |
| Keybuk | reminds me that I need to rebase those onto my linux-2.6 tree and send those that don't fall out to lkml, etc. | 14:52 |
| mjg59 | And they're the kind of trivial patches that can probably just be pushed to Andrew | 14:52 |
| Keybuk | (not the option ones at the top, obv) | 14:53 |
| mjg59 | The PnP table stuff for floppy is also sensible | 14:53 |
| Keybuk | yeah | 14:53 |
| mjg59 | Oh, ugh, I was going to fix wacom today | 14:54 |
| * mjg59 goes to do that | 14:54 | |
| Keybuk | "fix" wacom? | 14:54 |
| mjg59 | input-hotplug-wise | 14:55 |
| mjg59 | The driver's basically beyond redumption, but still | 14:55 |
| Keybuk | *nods* | 14:55 |
| kirkland | rtg: hey, tyhicks just popped in for a bit | 16:27 |
| kirkland | rtg: i told tyhicks that we'd like to get the jaunty kernel's ecryptfs sync'd | 16:27 |
| rtg | kirkland: I've a conf call in 3 mins | 16:27 |
| kirkland | rtg: fun ;-) | 16:27 |
| kirkland | rtg: circle back around in a bit? | 16:28 |
| rtg | A list of the missing commits would be nice | 16:28 |
| kirkland | tyhicks: can you drum that up? | 16:28 |
| kirkland | *tyhicks has git magic that kirkland lacks | 16:28 |
| rtg | I didn't see much delta in fs/ecryptfs between Jaunrt and Linus tree | 16:28 |
| tyhicks | rtg: missing commits from the current jaunty kernel to what's in the current rc tree? | 16:28 |
| rtg | tyhicks: right, at least those that make sense | 16:28 |
| tyhicks | rtg: will try to come up with a list | 16:29 |
| rtg | tyhicks: thanks | 16:29 |
| kirkland | tyhicks: i really want to get dmesg totally clean of ecryptfs errors before kernel freeze | 16:31 |
| kirkland | tyhicks: https://wiki.ubuntu.com/JauntyReleaseSchedule, April 9th | 16:31 |
| tyhicks | kirkland: when is kernel freeze? | 16:31 |
| tyhicks | ok :) | 16:31 |
| tyhicks | kirkland: I'd also like to slip in the umount_sigs patch that I'm just about ready to send upstream | 16:32 |
| kirkland | tyhicks: okay, the exact nature of that is to .... | 16:33 |
| kirkland | (I think I know the behavior, just want to make sure) | 16:33 |
| tyhicks | kirkland: from the kernel side, we have access to a usage counter in the key struct | 16:33 |
| tyhicks | kirkland: when userspace inserts a key, it increments the counter | 16:34 |
| tyhicks | kirkland: My best solution is to check to see if the unlink_sigs flag is set at umount, if so, decrement the usage counter twice for the keys used for the mount | 16:34 |
| kirkland | tyhicks: my preference would be to leave this out of Jaunty, and let it bake upstream for a bit | 16:35 |
| kirkland | tyhicks: i'm happy with the key clearing in the shell script wrapper, and the documentation in the manpages | 16:36 |
| tyhicks | kirkland: Ok, I keep forgetting that you are doing this in the shell script | 16:36 |
| kirkland | tyhicks: yeah | 16:36 |
| kirkland | tyhicks: the kernel stuff will be good stuff | 16:36 |
| kirkland | tyhicks: but we're really in bug-fix mode only | 16:36 |
| kirkland | tyhicks: feature freeze was several weeks ago | 16:36 |
| tyhicks | kirkland: understandable | 16:36 |
| kirkland | tyhicks: everything else in the diff between current jaunty and current rc is bugfixes, as i recall | 16:37 |
| kirkland | tyhicks: that's mostly what we're looking for now | 16:37 |
| Keybuk | rtg: any reason we don't just include fuse in the kernel by default? | 16:53 |
| Keybuk | we force load it from /etc/modules anyway | 16:54 |
| rtg | Keybuk: it didn't occur to me that was part of the startup. what uses it? | 16:55 |
| Keybuk | rtg: GNOME | 16:55 |
| Keybuk | and KDE | 16:55 |
| Keybuk | e.g. ~/.gvfs | 16:56 |
| Keybuk | if it were built into the kernel, it'd help us with a tricky issue of mounting /sys/fs/fuse/connections ;) | 16:56 |
| Keybuk | plus we load it anyway, so it saves some boot work | 16:56 |
| rtg | Keybuk: I've no real objections, but then I'm not real smart about fuse. Its just a file system driver much like ecryptfs, right? | 16:57 |
| Keybuk | right | 16:59 |
| Keybuk | ok I'll do a patch | 16:59 |
| === thunderstruck is now known as gnomefreak | ||
| Keybuk | rtg: you may pull from the usual place (along with the other outstanding patches) | 17:12 |
| Keybuk | I'll update userspace | 17:12 |
| rtg | Keybuk: will we have /lib/modules/`uname -r` support for modprobe options in karmic? | 17:15 |
| Keybuk | how do you mean? | 17:16 |
| rtg | Keybuk: I assume you're going to remove all of the current modprobe options in favor of your kernel patches, (HPA for example). I'd like to revert that patch for Karmic in favor upstream, yet retain the ability to change defaults (such as a modprobe option that is specific to a kernel version) | 17:18 |
| Keybuk | rtg: change defaults by patching the kernel | 17:19 |
| Keybuk | that way, when the kernel options change name or parameters, or the module goes entirely, it'll show up as a merge conflict | 17:20 |
| Keybuk | and if people build that module into the kernel, they'll still keep the changed default | 17:20 |
| rtg | Keybuk: agreed, as well as remove superfluous settings from /etc/modperobe.d | 17:20 |
| Keybuk | users can still override the options if they wish | 17:20 |
| Keybuk | but we shouldn't ship anything that does | 17:20 |
| rtg | Keybuk: is there a reason upstream doesn't like the MODULE_ALIAS stuff? It appears benign to me. | 17:21 |
| Keybuk | how do you mean? | 17:22 |
| Keybuk | the series of patches in my repo that add them? | 17:22 |
| Keybuk | I'm going to send them upstream shortly | 17:22 |
| Keybuk | they're more like SALT than SAUCE | 17:22 |
| Keybuk | ie. don't add if they're already there, but don't take away :p | 17:22 |
| rtg | I guess I'm wondering why it didn't happen long ago. | 17:22 |
| Keybuk | oh | 17:22 |
| Keybuk | I suspect they're just maintained by slightly inactive maintainers | 17:22 |
| Keybuk | most of the modules have them | 17:22 |
| Keybuk | and nobody had caught these ones up | 17:23 |
| rtg | ok, then I'm gonna apply them to Jaunty. I had to muck with the 'Auto-load esp module when device opened.' to get it to compile. | 17:23 |
| Keybuk | really? | 17:25 |
| Keybuk | I did a test compile | 17:25 |
| rtg | Keybuk: it was missing a header file | 17:25 |
| Keybuk | odd | 17:25 |
| rtg | I just pushed, how about rebasing your tree before I pull again | 17:25 |
| rtg | for the FUSE patch | 17:26 |
| Keybuk | ok let me try that ;) | 17:28 |
| Keybuk | rtg: you didn't pick up the mwave one? | 17:29 |
| rtg | Keybuk: hmm, don't know why not. | 17:30 |
| rtg | Keybuk: I did an interactive rebase a couple of time, maybe I accidentally dropped it. | 17:31 |
| Keybuk | ok | 17:31 |
| Keybuk | my branch updated | 17:31 |
| rtg | Keybuk: pushed the mwave patch. do you really want to build in fuse on the armel flavours? I'm not sure they all use Gnome. | 17:36 |
| rtg | I'll ask amitk or ogra | 17:36 |
| Keybuk | I think we do | 17:36 |
| Keybuk | there's so little overhead if it's not used | 17:36 |
| === maco_ is now known as maco | ||
| Keybuk | rtg: pulled, rebased and pushed again | 18:07 |
| Keybuk | all that's on top now is the fuse change | 18:07 |
| amitk | rtg: they do plan to use gnome | 18:40 |
| kirkland | rtg: did you ever com back around? | 19:57 |
| kirkland | tyhicks: did you get rtg those commits? | 19:57 |
| tyhicks | kirkland: working on it, today is not the best day for me, but I'm getting there | 19:57 |
| kirkland | tyhicks: okay, cool | 19:57 |
| tyhicks | kirkland: unfortunately, they are mostly changes that touch more than just ecryptfs | 19:57 |
| kirkland | rtg: is this going to make next week's alpha? | 19:57 |
| kirkland | tyhicks: oh | 19:58 |
| rtg | kirkland: it could if ready by Monday | 19:58 |
| kirkland | tyhicks: is that doable? | 19:58 |
| rtg | and if there are no ABI bumpers in the patches | 19:58 |
| kirkland | tyhicks: can we shoot for Friday, just to be safe? | 19:58 |
| kirkland | tyhicks: know of any abi bumpers? | 19:59 |
| tyhicks | kirkland: not sure just yet, still trying to just compile the list | 19:59 |
| kirkland | tyhicks: k | 19:59 |
| tyhicks | kirkland: I think I can have a list by Friday, but I won't be able to do any backporting that is required | 20:00 |
| kirkland | tyhicks: k | 20:05 |
| === Nicke_ is now known as Nicke | ||
| TheMuso | pgraner: Re the beep situation with your notebook, if I was to send you the patch I got from fedora, are you able to build your own kernel and test? If not, I can put one up somewhere for you. | 21:52 |
| pgraner | TheMuso: sure won't get to it until Sat... I'm slammed tomorrow *sigh* | 21:55 |
| pgraner | TheMuso: just post the patch to the bug and I'll get to it soonest | 21:55 |
| TheMuso | pgraner: I'll attach it to the bug then. | 21:55 |
| pgraner | TheMuso: :-) | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!