| === smb` is now known as smb | ||
| * smb yawns | 07:08 | |
| _ruben | good idea | 07:10 |
|---|---|---|
| cooloney | smb: morning | 07:12 |
| smb | cooloney, morning | 07:13 |
| TomGLU | hi I came across a ext4 bug (returning too large d_off values) in the 3.4.4 kernel | 07:16 |
| TomGLU | where should i report this? | 07:16 |
| smb | TomGLU, start a report by running "ubuntu-bug linux". From there it depends ... If you got something that can produce the error on demand, make sure to describe it as well as possible. | 07:19 |
| TomGLU | its something we cam across that trigger problems in glusterfs | 07:28 |
| TomGLU | one of there developers could replicate it on a KVM iameg using the same kernel | 07:28 |
| TomGLU | because we used linux-image-3.4.4-030404-generic not precise it saids "The problem cannot be reported:" | 07:30 |
| TomGLU | *not=on | 07:30 |
| TomGLU | "This is not an official Ubuntu package." but we got the image from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.4-quantal/ | 07:31 |
| _ruben | those aren't official ;) | 07:31 |
| _ruben | when it comes to support that is | 07:32 |
| smb | Right, it should be reproducible with the official one | 07:32 |
| smb | Though it can be that it might become a regression. Any reason to run mainline kernels? Those should only be used to narrow down issues... | 07:32 |
| smb | TomGLU, Anyway you should try to reproduce it with a current quantal kernel | 07:34 |
| smb | (which would also make sure it is still there) | 07:34 |
| TomGLU | used because we needed a libvirt kernel bug fix that wasn't included in the default precise kernel | 07:35 |
| TomGLU | and i don't need support I just want to let the ubuntu kernel team know so it might be fixed or can be checked in more recent versions | 07:37 |
| TomGLU | so were do I submit this so I can detail what the issue is and maybe others can reproduce in other versions | 07:38 |
| * apw yawns | 07:43 | |
| smb | Support here rather as in what kernel versions to considered as supported. There is already a lot of complexity trying to maintain the official kernels. Its just impossible to consider self-compiled ones. Thanks for telling us about it. It would be great if you (or whoever did reproduce it in a kvm) could do the same with a quantal install with the up-to date official kernel and report this. | 07:44 |
| smb | As said before, that would allow to see whether this is possibly already fixed upstream (as the quantal kernel is really close to that) | 07:45 |
| smb | apw, Morning | 07:45 |
| cking | morning apw | 07:46 |
| TomGLU | I'll try if i can do it on a VM as we can't try it on the original machine, | 07:46 |
| * apw waves | 07:47 | |
| TomGLU | and ubuntu-bug linux is the only way to report it or si there an bug system i can submit the issue manually? | 07:47 |
| apw | https://bugs.launchpad.net/ubuntu/+source/linux/+filebug | 07:47 |
| smb | TomGLU, Sure, that would be awesome. And also it would allow the ubuntu-bug submission. It is also possible, but ubuntu-bug also automatically gathers a lot of machine information and log files. | 07:48 |
| apw | in an emergency you can file it that way, but the bots willhastle you for lots of information | 07:48 |
| smb | But you can do manually as apw says | 07:48 |
| TomGLU | ok I'l investigate it in a VM first then and try to report it with ubuntu-bug | 07:49 |
| smb | Thanks. I did a quick glance over the recent ext4 commits and (while certainly not in depth) it did not look as something similar was worked on. So I would believe that it would still exist. | 07:56 |
| cooloney | apw and cking, morning | 07:58 |
| ppisati | moin | 07:59 |
| cooloney | ppisati: morning | 08:01 |
| apw | cooloney, ppisati, moin | 08:01 |
| apw | recursive hello death | 08:01 |
| apw | smb, xen-blkfront breaks in -rc6 something to do with the compute node performance thing we are carrying for EC2, it looks easy to fix but it will need a test after i push it | 08:04 |
| smb | apw, Hm yeah, that was something we wanted to look at anyway. But sure I can test it when you have a kernel (or I do one after the push) | 08:05 |
| apw | it looks trivial to fix, so i suspect it'll be fine, but knowing we've tested and are alive is always good | 08:07 |
| smb | Oh I agree. You never know what else broke... | 08:11 |
| cooloney | apw: if an config option's policy is =m, but we found this config option is mostly useless, can we change the policy? like CONFIG_GPIO_EM | 08:17 |
| cooloney | it is 'Say yes here to support GPIO on Renesas Emma Mobile SoCs' | 08:17 |
| apw | cooloney, if it is patenty useless on everything i can annotate it so | 08:18 |
| apw | sounds liek something which should be just 'n' across everywhere indeed | 08:18 |
| caribou | smb: morning | 08:19 |
| smb | caribou, Hey Louis | 08:19 |
| cooloney | yeah, for CONFIG_GPIO_EM is only for Renesas ARM Emma Mobile SoCs, so we are safe to set it as =n for everyone | 08:19 |
| caribou | did you get any further with your kdump issue ? | 08:19 |
| apw | cooloney, yes for things which are useless building a module nothing can load is definatly dumb | 08:19 |
| caribou | smb: I'm downloading the Quatzal daily to test on the latest version | 08:19 |
| apw | cooloney, want me to annotate that =n now ? | 08:20 |
| cooloney | apw: yeah, thanks, i just found it is red in our review wiki page. | 08:20 |
| cooloney | and it because the policy is =m, but we got everyone =n as we expect | 08:20 |
| smb | caribou, Right, I just tried with crashkernel=128M and that seems to solve the problem | 08:20 |
| apw | cooloney, CONFIG_GPIO_EM right ? | 08:21 |
| smb | caribou, The current cmdline would only use 64M as I got only 2G | 08:21 |
| caribou | smb: cool. I will still need your help to explain to me how this crashkernel memory is populated | 08:21 |
| caribou | I have a case where, even with 384Mb reserved, the kernel still doesn't load & OOM kicks in | 08:22 |
| smb | caribou, Knowing that to be the problem I can look at that more closely now | 08:22 |
| cooloney | apw: yeah, that's it | 08:22 |
| caribou | smb: my guess is that, depending on which module gets loaded, the memory requirement inflate | 08:23 |
| apw | caribou, it is populated in two parts, 1) by kexec in the normal running kernel which loads an executable kernel into the gap, and 2) it represents the whole memory space for that kernel once we have jumped into | 08:23 |
| smb | caribou, I had the feeling I saw a slight textual corruption on boot on my machine. Maybe things load into places that may be used differently | 08:23 |
| cooloney | apw: and for CONFIG_GPIO_SYSFS, our policy is =n because it is experimental. only highbank =n, others are all =y. looks like it is quite usefule | 08:23 |
| cooloney | *useful | 08:23 |
| caribou | apw: yeah, I got that part figured out, what I'm missing is what gets loaded in as the kernel boots up | 08:23 |
| cooloney | oh, powerpc also set it as =n. | 08:24 |
| apw | caribou, it is a full kernel boot, in that limited space, so whatever normally loads during early boot | 08:24 |
| smb | apw, So basically faking a full mem of xM | 08:24 |
| caribou | apw: then the more modules gets loaded, the more memory will be required. | 08:25 |
| dileks | hi | 08:25 |
| apw | mostly we don't start much just get the disk mounted and then run the memory copier, then reboot | 08:25 |
| smb | apw, The other question I see is: what region gets used for that xM actually and may it hit bios reserved memory? | 08:25 |
| apw | smb, in theory its a chunk out of bootmem, and again in theory taken after the reserved regions are taken | 08:26 |
| caribou | apw: this goes back to the /etc/initramfs/initramfs.conf MODULES= setup that you once told me about | 08:26 |
| dileks | apw: any progress on ovl-v13 against 3.5-rcX as rc6 is released (in your overlayfs.git repo)? | 08:26 |
| apw | caribou, right, a very small initrd is preferable as that is extracted into the memory space reserved | 08:26 |
| smb | apw, Right, so that was where I thought I should look more closely. IT surely seems to be placed as high (as in the end of bootmem) | 08:27 |
| caribou | smb: afaik, it fits above the first 32M of RAM | 08:27 |
| apw | smb, i suspect that is more about it being aligned than anything, its probabally maximally aligned ie aligned at its size | 08:28 |
| smb | apw, Hm, so maybe the unpack could have some issue as well. | 08:28 |
| smb | caribou, apw In my case its placed at 800M (or 7xx with crashkernel=128M) | 08:29 |
| apw | smb, well in the past we had a massive initrd, so you need the kernel, the packed inird, and the unpacked initrd in the space for a short period and that can go pop | 08:29 |
| apw | no idea if that got fixed or not, but we should be using an '=needed' type initrd for kexec | 08:30 |
| smb | apw, Ok, that explanation makes a lot of sense | 08:30 |
| smb | The compressed initrd is 14M... | 08:31 |
| smb | uncompressed 38M | 08:32 |
| smb | ... and the kernel code alone about 7M | 08:34 |
| TomGLU | just tested it in a KVM with Ubuntu 12.10 (Quantal Quetzal) Alpha 2 and still high d_off | 08:34 |
| TomGLU | which ubuntu image should i use though cause it still says: | 08:38 |
| TomGLU | *** Problem in linux-image-3.5.0-2-generic | 08:38 |
| TomGLU | This is not an official Ubuntu package | 08:38 |
| apw | i am sure we got someone to test using =needed or whatever it is and that helped a lot, someone need to make kexec actually do that | 08:40 |
| smb | TomGLU, Hm, weird though it could be because the latest 3.5 kernel was 3.5.0-3 or even -4 (there is a lot of change in the development release, so it is always a good idea to run update/dist-upgrade after installing) | 08:46 |
| TomGLU | ok i'll try the diet-upgrade | 08:46 |
| smb | Saying its not official is a bit confusing, though | 08:46 |
| TomGLU | indeed | 08:47 |
| TomGLU | its distupgrading to 3.5.0-3 now | 08:47 |
| TomGLU | ok now it is sending the report | 08:50 |
| smb | TomGLU, Great. If you can post the bug number here we can have a look | 09:03 |
| === ailo_ is now known as ailo | ||
| TomGLU | smb: 1022500 | 09:15 |
| smb | TomGLU, Thanks, hm you might add how to easily obtain those values. I would not immediately know. debugfs? | 09:23 |
| dileks | http://www.heise.de/open/news/foren/S-Castle-of-AArch64/forum-232679/msg-22087233/read/ | 09:23 |
| dileks | http://www.youtube.com/watch?v=GEcvSq4SDkc | 09:23 |
| dileks | I would tend to arm64 than aarch64 | 09:23 |
| smb | Never to miss the opportunity to refer to the Pythons... | 09:25 |
| dileks | aah monty pythons | 09:26 |
| TomGLU | smb: got a small C script from the cluster developer that prints the d_off for a given directory | 11:01 |
| TomGLU | *cluster=Gluster | 11:01 |
| * ppisati -> lunch | 11:36 | |
| apw | ogasawara, pushed a v3.5-rc6 rebase for you, had to fix 'UBUNTU: SAUCE: Improve Amazon EBS performance for EC2' so we need to get smb to test that functionality. | 11:48 |
| smb | apw, ack will have a look | 12:02 |
| ogra_ | diwic, yo, do you happen to be around ? | 12:12 |
| === emma is now known as em | ||
| diwic | ogra_, let me check....yes, I actually am! | 12:13 |
| ogra_ | haha | 12:13 |
| ogra_ | diwic, so i built myself this new desktop machine ... shiny thing with hda soundcard onboard and two ati graphics cards ... | 12:13 |
| ogra_ | and apparently the cards both have hda intel codecs on board ... i know sound worked at some point during my fiddling (but i constantly used a BT headset ...) yesterday i though i should try to make analog sound work and set up my 2.1 system but somehow i'm not able to squeeze the smallest sound ou of the system | 12:15 |
| diwic | ogra_, okay, se let's start with an alsa-info: https://wiki.ubuntu.com/Audio/AlsaInfo so I know what kind of hardware you got | 12:16 |
| ogra_ | diwic, any idea what that could be ? pavucontrol shows all three devices with alsamixer -c1 i can see all hda controls for the analog audio | 12:16 |
| ogra_ | ok | 12:16 |
| ogra_ | diwic, http://paste.ubuntu.com/1082642/ | 12:17 |
| ogra_ | i wouldnt be unhappy if the HDMI devices didnt show up at all btw | 12:18 |
| diwic | ogra_, hmm, that ALC892 is unusual, I remember there was someone with that codec also who had some problems with it | 12:19 |
| ogra_ | well, i know i did a smoke test at some point during assembling that thing and sound worked just fine back then | 12:20 |
| ogra_ | (about a week ago or so) | 12:20 |
| diwic | ogra_, so if you run "speaker-test -c 2 -D plughw:PCH -t wav", do you get any sound out of either headphones or line out? | 12:20 |
| ogra_ | is teher any way to tell the driver to ignore the two hdmi cards ? | 12:20 |
| ogra_ | nope, from neither | 12:21 |
| diwic | ogra_, I guess the easiest way would be to blacklist snd-hda-codec-hdmi, but I'd be surprised if that solved the problem | 12:21 |
| ogra_ | that i did already for a test | 12:21 |
| ogra_ | didnt change a thing | 12:21 |
| ogra_ | (well, apart from pavucontrol not showing the graphics cards anymore) | 12:22 |
| diwic | I guess you can also work with the pci unbind stuff, which I hardly know how to do | 12:23 |
| diwic | if you want to ignore it even more | 12:23 |
| caribou | smb: FYI, I'm not able to get Quantal to trigger a kernel dump. kexec doesn't wanna kick in | 12:23 |
| ogra_ | oh, thats something i didnt think about yet | 12:23 |
| ogra_ | well, i'd like to keep the graphics output :) | 12:23 |
| diwic | ogra_, hmm but I think the audio has a separate PCI ID | 12:23 |
| ogra_ | yeah, it should | 12:24 |
| diwic | ah wait, the other one was a ALC898, not ALC892. Still unusual codecs though | 12:24 |
| ogra_ | well, its all pretty new HW | 12:25 |
| smb | caribou, Ok, so that needs more investigation then. Thanks for the info. I guess this should go into some new bug then to keep track of it. Feel free to assign it to me | 12:25 |
| caribou | smb: ok, I want to check a few more things, then I'll create a bug | 12:26 |
| smb | caribou, Ok, sure and thanks | 12:26 |
| diwic | ogra_, a quick grep through the reports for ALC892 show plenty of people having playback issues, but not all. | 12:26 |
| ogra_ | hmm, ok | 12:27 |
| diwic | ogra_, I did have a look at the alsa info but nothing popped out as being wrong in the setup. | 12:28 |
| ogra_ | right, i can even see the meters in pavucontrol work once i play back the test sound from the gnome sound applet | 12:28 |
| ogra_ | it just doesnt come out of the speaker | 12:28 |
| diwic | ogra_, hmm, it looks like automute is enabled so make sure headphones are not plugged in when you're testing the speakers | 12:29 |
| ogra_ | yep | 12:29 |
| diwic | ogra_, that said there should still be sound in the headphones... | 12:30 |
| ogra_ | i also tested with automute disabled before just for the record | 12:30 |
| diwic | ogra_, you said the last time it worked was during assembly. | 12:30 |
| ogra_ | i have some humming in the speakers (electric noise) and get a crackling sound on plug/unplug so there is definitely power | 12:31 |
| ogra_ | well, i'm still in assembly, since last weekend | 12:31 |
| ogra_ | it worked some time through the last week | 12:31 |
| diwic | ogra_, based on that, would there be any difference if you unplug the HDA front cable from the motherboard? | 12:31 |
| diwic | ogra_, or rather, do you know if it was connected when it last worked? | 12:32 |
| ogra_ | it was connected before i powered up for the first time | 12:32 |
| ogra_ | but i added the second graphics card only later | 12:32 |
| ogra_ | bug 982635 looks intresting | 12:33 |
| ubot2 | Launchpad bug 982635 in alsa-driver "Playback working randomly with Intel ALC892" [Undecided,New] https://launchpad.net/bugs/982635 | 12:33 |
| ogra_ | though with that i would assume to have at least once sound in 50 reboots or so | 12:33 |
| ogasawara | apw: ack, thanks | 12:33 |
| diwic | ogra_, out of curiousity, what is the mainboard's name? | 12:35 |
| ogra_ | asus P8 H67-M Pro | 12:35 |
| diwic | ogra_, there is bug 1002480 for P8P67 | 12:36 |
| ubot2 | Launchpad bug 1002480 in pulseaudio "[Asus P8P67, Realtek ALC892, playback] Underruns, dropouts or crackling sound" [Undecided,Confirmed] https://launchpad.net/bugs/1002480 | 12:36 |
| ogra_ | heh, that somewhat assumes you have some sound to hear it become crackly :) | 12:37 |
| diwic | ogra_, according to that report removing .pulse directory helped, but, a test with "speaker-test -D plughw:PCH" should have disabled anything pulse so... | 12:37 |
| ogra_ | yeah, i removed ~/.pulse like 100 times already | 12:38 |
| diwic | ogra_, seems like you've tried it all! :-) | 12:38 |
| ogra_ | i even deinstalled it to play plainly with alsa | 12:38 |
| ogra_ | i aslo think on the pluse side everything is fine | 12:39 |
| diwic | ogra_, hrm, did you update alsa drivers also? | 12:39 |
| ogra_ | must be some lower layer | 12:39 |
| ogra_ | from the PPA ? | 12:39 |
| ogra_ | not yet | 12:39 |
| diwic | ogra_, the dkms drivers could be worth a try, but I was also making sure that you haven't tried home-compiling them. That could be a source of error as well | 12:39 |
| ogra_ | ah, no | 12:40 |
| ogra_ | i tried an upstream fglrx package but even that one is reverted to the archive one now | 12:40 |
| diwic | ogra_, btw, you have uninstalled pulseaudio you say, but still you have ~/.asoundrc.asoundconf pointing to it. | 12:41 |
| ogra_ | well, i used -D plughw in aplay for testing | 12:42 |
| diwic | ogra_, btw, I saw somebody trying different jacks and were able to get sound that way - could you try, while running "speaker-test -D plughw:PCH -c 2 -t sine", the other rear jacks as well? | 12:43 |
| diwic | ogra_, maybe there is sound in the grey jack or something. | 12:43 |
| diwic | ogra_, and try the DKMS drivers in ubuntu-audio-dev ppa. | 12:44 |
| diwic | ogra_, that's my long shots at the moment. | 12:44 |
| ogra_ | all jacks tried, nothign | 12:44 |
| ogra_ | i'll try the dkms drivers ... | 12:44 |
| ogra_ | its not the end of the world if i have to go on using BT for a while, but it would be nice to get it working some day | 12:45 |
| diwic | ogra_, btw, you should turn off "Line Playback Volume", that's for line-in to line-out loopback | 12:46 |
| ogra_ | ah, k, i was wondering what that is :) | 12:46 |
| diwic | you probably don't want that, just leads to background noises in worst case | 12:46 |
| ogra_ | (doesnt make any difference if its off or on) | 12:46 |
| diwic | ok | 12:47 |
| ogra_ | what do you want me to try, just the PPA or the alsa-daily stuff ? | 12:47 |
| diwic | https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS | 12:48 |
| ogra_ | ah, daily :) | 12:48 |
| * ogra_ reboots | 12:51 | |
| ogra_ | diwic, no change with the dkms modules ... if i have a lazy day i'll try to remove both grapics cards and see what changes then ... | 13:02 |
| ogra_ | for now i'll juts live with BT | 13:02 |
| ogra_ | *just | 13:03 |
| diwic | ogra_, yeah, I wonder what's with those cards really. It does look like an unusual amounts of ALC892 fail in one way or the other | 13:03 |
| diwic | ogra_, or if I'm just seeing patterns where there aren't any. | 13:03 |
| ogra_ | well, i'm pretty surprised to see the cards using the intel driver really | 13:04 |
| ogra_ | i thought there was a special radeon driver for that ... | 13:04 |
| diwic | ogra_, all hdmi audio use snd-hda-intel + snd-hda-codec-hdmi drivers these days. | 13:05 |
| ogra_ | ah, k | 13:06 |
| ogra_ | well, i found some bugs where people were told to boot with radeon.autio=0 or so | 13:06 |
| ogra_ | *audio | 13:06 |
| ogra_ | so i thought the radeon driver somehow manages audio too | 13:06 |
| diwic | radeon.audio=0 is the default for kernels >= 3.0 | 13:07 |
| ogra_ | right | 13:07 |
| ogra_ | (doesnt help with fglrx though) | 13:07 |
| ogra_ | i tested with a quantal livedcd too already ... same result | 13:07 |
| ogra_ | s/livecd/live udb key/ | 13:07 |
| ogra_ | *usb | 13:08 |
| diwic | they had too many problems with audio=1 (people getting visual problems) so they turned it off | 13:08 |
| ogra_ | *sigh* | 13:08 |
| * ogra_ wants to learn typing one day | 13:08 | |
| rtg | apw, 'UBUNTU: [Config] built-in CONFIG_MICREL_PHY as other PHY drivers for all flavours' is going to cause build failures for the arches that have a module go missing, e.g. "git grep micrel debian.master/abi" | 13:21 |
| apw | rtg, bah yeah will sort it n | 13:22 |
| rtg | apw, I did an update locally already. shall I just push it ? | 13:22 |
| apw | sure | 13:22 |
| apw | its going to be a rough week alreadyb | 13:23 |
| rtg | apw, done | 13:25 |
| apw | rtg, thanks ... sigh | 13:26 |
| rtg | jsalisbury, bouncing gomeisa for kernel update | 13:26 |
| jsalisbury | rtg, is it ok to use gomeisa now? | 13:50 |
| rtg | jsalisbury, yeah, its back | 13:50 |
| jsalisbury | rtg, cool, thanks | 13:50 |
| smb | apw, ogasawara Ok, on a quick (5 iterations) bonnie test on 32 and 64 bit PV guests I did not see any problems with the rc6 rebase + apw's blockfront fixups | 14:00 |
| ogasawara | smb: great, thanks | 14:01 |
| apw | ogasawara, feel free to squash that fix sometime, perhaps after the next upload | 14:11 |
| ogasawara | apw: ack. I'm hoping to get in an upload today after wading through my inbox. | 14:12 |
| apw | ogasawara, sounds good, let me know when you have a tag and i'll get ll together over it | 14:12 |
| ogasawara | jsalisbury: any progress on bug 1018020 by chance? it's apparently affecting most of the QA team. holler if you need help. | 14:18 |
| ubot2 | Launchpad bug 1018020 in linux "Logitech webcam not working" [High,Confirmed] https://launchpad.net/bugs/1018020 | 14:18 |
| jsalisbury | ogasawara, just tested -rc6 and it still exists. I'm still bisecting. I ran into a few test kernels that would panic and a few commits that would not build, but still making progress. | 14:19 |
| ogasawara | pgraner: ^^ just fyi | 14:20 |
| jsalisbury | ogasawara, it's my top priority for today, and I have hardware to reproduce. | 14:20 |
| jsalisbury | ogasawara, pgraner, I confirmed this bug was introduced in v3.5-rc1, just working on finding the exact commit. | 14:21 |
| pgraner | jsalisbury, cool let me know when you have a kernel I'll run it on my boxes that are failing | 14:22 |
| jsalisbury | pgraner, will do | 14:22 |
| * ogasawara back in 20 | 15:00 | |
| ogasawara | rtg: bah, stupid permission denied build error again on gomeisa. it seems to always trigger in the i386 chroot. | 15:24 |
| rtg | ogasawara, paste it ? | 15:26 |
| ogasawara | ccache: FATAL: Could not create /home/ogasawara/quantal-i386/ccache/8/2/1834a73ab5ad0e3ffbed95e7a26d38-1830488.o.tmp.stdout.gomeisa.3990 (permission denied?) | 15:26 |
| ogasawara | make[7]: *** [drivers/net/ethernet/intel/ixgb/ixgb_main.o] Error 1 | 15:26 |
| ogasawara | make[6]: *** [drivers/net/ethernet/intel/ixgb] Error 2 | 15:26 |
| ogasawara | make[6]: *** Waiting for unfinished jobs.... | 15:26 |
| rtg | ogasawara, but amd64 works OK ? | 15:28 |
| ogasawara | rtg: yep. amd64, armhf, and amel were all ok | 15:29 |
| rtg | ogasawara, have you tried without ccache ? | 15:29 |
| ogasawara | rtg: I haven't | 15:29 |
| rtg | ogasawara, this doesn't seem like a chroot issue | 15:31 |
| ogasawara | rtg: lemme clean things up and try again | 15:31 |
| rtg | ogasawara, I think you're better off without ccache. I found that it took longer to resolve the hash then it did to just recreate the file, especially when you have several thousand files. | 15:32 |
| * ppisati -> gym (see u later) | 16:09 | |
| * herton -> lunch | 16:16 | |
| * henrix -> brb | 16:28 | |
| === rtg is now known as rtg-lunch | ||
| * henrix -> EOD | 18:24 | |
| === rtg-lunch is now known as rtg | ||
| bjf | arges: issue #1 on why a hotfix should be used it true means that you are going to be the sole supprt for that kernel and all future versions of it ? seems like at that point you should engage with OEM. | 18:39 |
| bjf | arges, also you are re-inventing the build instructions. you should look at the stable team build instructions and all you need to do is hae a different version string | 18:40 |
| === arges__ is now known as arges_ | ||
| * rtg -> EOD | 20:13 | |
| jsalisbury | ogasawara, pgraner, I'm pretty close on the bisect for bug 1018020 I should have a test kernel withing an hour or two. | 20:25 |
| ubot2 | Launchpad bug 1018020 in linux "Logitech webcam not working" [High,Confirmed] https://launchpad.net/bugs/1018020 | 20:25 |
| ogasawara | jsalisbury: awesome, thanks for digging into it | 20:25 |
| jsalisbury | ogasawara, np. It was a good learning one. Plenty failed kernels during the bisect that needed fixing up :-) | 20:26 |
| jsalisbury | The early release candidates can be a pain to bisect :-) | 20:26 |
| pgraner | jsalisbury, coolio | 20:35 |
| jsalisbury | pgraner, I'll update the bug and send email when the test kernel is ready | 20:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!