=== gerald is now known as Guest34543
=== mwhudson is now known as zz_mwhudson
[06:51] <ppisati> moin moin
[07:24] <apw> moin
=== lag` is now known as lag
[08:30] <ppisati> i love the smell of kernel compilation in the morning...
[08:30] <zequence> Smells like...
[08:31] <smb> burning copper
[08:40] <apw> heh ...that's a good description
[09:12] <apw> smb, so what are you reproducing this on, is this your amd box ?
[09:13] <apw> smb, i wonder if i should be trying to repro it on my kit, to see if there is a type of kit link
[09:13] <smb> apw, One... its the dell 1521
[09:13] <smb> But in bug 1268906 jodh has seen it on an i7
[09:13] <ubot2`> Launchpad bug 1268906 in qemu-kvm (Ubuntu) "cpu soft lockup running kvm" [Medium,Confirmed] https://launchpad.net/bugs/1268906
[09:14] <apw> ok so that is intel and amd showing it?
[09:15] <apw> you should let peter know the extent of the h/w you have seen it on
[09:15] <smb> apw, IF only you would read mail
[09:15] <hvn2> question: if I cross-compile a patched vanilla kernel using make-kpkg, ending up with a linux-image and linux-header, and I install it using dpkg, will Ubuntu treat it as an Ubuntu kernel or does it take more to be treated as such ? 
[09:17] <hvn2> my problem is that I've tried for 6 times now, and each time I get the message that it won't be written into flash
[09:19] <apw> hvn2, what is the message you get
[09:19] <apw> smb, i have read email, once is enough, ever
[09:20] <smb> apw, Sometimes people do reply... :) So, yeah I did already let him know that
[09:21] <apw> smb, and _that_ one i am not even copied on!
[09:21] <jarkko_> what should i do i get multiple of these on dmesg
[09:21] <jarkko_> 7659.777995] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
[09:21] <jarkko_> its known issue
[09:21] <smb> apw, Hm, I thought I did a reply all to his...
[09:21] <hvn2> apw: the exact message is that "kernel <..> does not match your subarchitecture omap, therefore not writing it into flash." Of course I configured the kernel for omap.
[09:22] <smb> apw, So no, you are not on that, but the initial email you were not either
[09:23] <apw> smb, indeed and the search page on lkml does not auto update!
[09:23] <apw> so ner
[09:23] <smb> apw, stupid them then :)
[09:23] <apw> smb, i note you are starting this with very little memory, i presume that is what is triggering the need to ipi a lot
[09:24] <smb> apw, Would it not do the opposite since the host is under less pressure?
[09:25] <smb> apw, Note that it is the qemu task on the host that runs into this
[09:27] <smb> hvn2, what does "file <kernel file>" say about that
[09:27] <apw> smb, but it is the internel need for one cputhread in the guest to wake the other that triggers the need to add the TIF_ flag in the first place, so i would guess anything which makes CPU to CPU comms in the guest more comon would tickle this issue more
[09:29] <smb> apw, I don't think so. In some cases the softlockup happened even when still running isolinux or the bios which inside the guest is not SMP
[09:29] <hvn2> smb, that says "Debian binary package (format 2.0)"
[09:30] <smb> hvn2, That would be a deb package and not the kernel which I assume the flashing is right to refuse
[09:31] <hvn2> no, on the target I did "file" on the kernel I cross-compiled
[09:34] <ppisati> hvn2: so you have a .deb package, right?
[09:34] <ppisati> hvn2: my guess is that, the vmlinuz file and initrd were installed successfully, you can check it looking inside /boot for those two fiels
[09:35] <ppisati> *files
[09:35] <ppisati> hvn2: what is failing is flash-kernel, you are hitting the same bug as this one: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/721147
[09:35] <ubot2`> Launchpad bug 721147 in flash-kernel (Ubuntu Natty) "flash-kernel subarch check fails with Linaro OMAP kernels" [Undecided,Fix committed]
[09:36] <ppisati> hvn2: after vmlinux and initrd are installed, there's a trigger to turn them into uImage and uInitrd files that uboot can understand
[09:36] <ppisati> hvn2: problem is, every board/arch is different, is tretaed differently and thus therte's a specific piece of code that deals with it
[09:37] <ppisati> hvn2: in your case when flash-kernel is invoked it doesn't understand for which arch/board your kernel was compiled for, and thus doesn't know how to handle it
[09:37] <ppisati> hvn2: anyhow
[09:37] <ppisati> hvn2: you just said that's a patched kernel, did you manually try to boot it?
[09:37] <ppisati> hvn2: does it work?
[09:41] <hvn2> ppisati: on x86 it installed and works perfectly, on this board it's given this message each time. Also, last time I tried to boot from the first attempt, it booted into the standard kernel. Since then I didn't boot since I got this message.
[09:43] <ppisati> hvn2: read the lp bug that i mentioned above, you are hitting the same problem
[09:43] <ppisati> hvn2: installing a kernel on an arm board it's (usually) a two step process
[09:43] <ppisati> hvn2: 1) tou install it (and create initrd) in /boot
[09:44] <ppisati> hvn2: 2) those files are converted in uImage/uInitrd files and copied somewhere
[09:44] <ppisati> hvn2: your package installation is failing point 2
[09:44] <ppisati> hvn2: because flash-kernel doesn't know how to handle your package
[09:47] <hvn2> ppisati: ah ok..right now, I'm reinstalling my latest kernel version and will check on the uImage and uInitrd. Then will try to boot into it
[09:55] <hvn2> ppisati: I just check /boot, and the only files that have been created from this latest install are initramfs and initrd.img. From yesterdays attempt are System.map and vmlinuz. The fat32 partition does not contain new uImage or uInitrd.
[09:56] <hvn2> ppisati: So I guess I have to manually do step 2
[09:58] <hvn2> ppisati: yes, that my problem is clearly according to that bug
[10:29] <hvn2> ppisati: I just found this for Karmic: mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d ./vmlinuz-* ./uImage . Does this handle uInitrd as well ?
[10:29] <ppisati> hvn2: as the command says, it creates only uImage
[10:30] <ppisati> hvn2: if i would you, i would put some echo in flash-kernel and the reinstall an ubuntu kernel on that board
[10:30] <ppisati> hvn2: this way you can see what's going on
[10:36] <cking> apw, did you get my email wrt thermad
[10:36] <cking> ?
[10:39] <hvn2> ppisati: ok ty. I will check.
=== gerald is now known as Guest89674
[10:58] <apw> cking, yep saw it
[10:59] <apw> cking, i thin you are on the money, lets get it synced over
[11:00] <apw> cking, i assume we want -7 yes ?
[11:05] <cking> apw, yep 
[11:11] <caribou> Is our signed kernel that boots in secure mode a totally separate kernel or some thing that sits on top of the regular one ?
[11:12] <apw> caribou, it is exactly the same kernel, bit for bit, with a teensy signature attached
[11:12]  * caribou is just trying to confirm that our signed kernel has kexec disabled
[11:13] <apw> caribou, though it exercises different code during early boot if booted signed from efi
[11:13] <caribou> apw: ah, ok, hence the ./usr/lib/linux/vmlinuz-3.11.0-15-generic.efi.signature in the package
[11:13] <apw> caribou, kexec is enabled
[11:13] <caribou> apw: ah ok, thought it was not
[11:15] <apw> caribou, it is arguable if you have module signing enforced it should be, but it is not
[11:15] <apw> caribou, we did however just add the commit below
[11:15] <apw> commit 70a96bd309fc4ff7d07792057cda1ad89e647388
[11:15] <apw> Author: Kees Cook <keescook@chromium.org>
[11:15] <apw> Date:   Thu Jan 23 15:55:59 2014 -0800
[11:15] <apw>     kexec: add sysctl to disable kexec_load
[11:15] <apw>     
[11:15] <apw> which allows you to permenantly diable it on boot, this lets you load a crash kernle and then stop it being changed
[11:22] <caribou> apw: yeah, I remember asking about this one recently
[11:22] <caribou> apw: thanks for the info
[11:38] <apw> henrix, about to blow the autotriager into bits again
[11:38] <henrix> apw: ack
[11:48] <cking> apw, i may have to do one more thermald upload as I've just been given a some patches to make it work with systemd
[11:54] <apw> cking, thats fine, we can sync again, if -7 is worth having now
[11:55] <cking> well -8 won't add much for us, , so -7 is fine for the mo, but I will get -8 up sometime today once I've sanity checked it
[12:03] <apw> cking, ok that is sync'd, built, and pending publication
[12:06] <cking> ta
[12:07] <cking> apw, the next step I guess is to make it install on our kernel for x86 systems
[12:08] <apw> yeah i guess we make it an install dependancy of the kernel on x86, does it make sense anywhere else ?
[12:08] <cking> apw, nope, just for x86 
[12:19] <apw> ok, so we will trigger a component missmatch, so we need an MIR filing for that to get considered for inclusion
[12:25] <zequence> apw: So, I was able to narrow down one clue to linux-lowlatency not booting - as it seems to freeze because of at least one type of wifi driver. I was thinking of doing more testing, and thinking since the diff is so small, it should be easy to narrow it down even more. 
[12:25] <zequence> apw: So, I thought to try rebuild the kernel without the threadirqs parameter
[12:26] <zequence> But, maybe you guys already have an idea about what it could be?
[12:26] <apw> zequence, so joe has built kernels with preempt off, and you can test the thread thing by turning it off on the command line
[12:27] <zequence> apw: Right
[12:27] <zequence> Ok. Will do some testing this evening
[12:28] <apw> liase with jsaulisbury as he has all the kernels et
[12:28] <apw> etc
[12:29] <zequence> apw: Alright
[14:07] <rtg> cking, have you written a main inclusion request for thermald ?
[14:07] <cking> rtg, nope, how does one go about that?
[14:08] <rtg> cking, um, I have to figure it out every time 'cause I don't do it that often.
[14:08] <cking> https://wiki.ubuntu.com/MainInclusionProcess i guess
[14:08] <rtg> cking, that looks right
[14:24] <caribou> what value of /proc/meminfo would be good candidate to evaluate the memory available when booted in the kexec crash dump environment ?
[14:24] <caribou> I was thinking of MemTotal & MemFree
[14:37] <apw> caribou, yep, those are the ones i would start with
[14:38] <caribou> apw: ok, thanks. I'm hoping to define a set of scripts that can be easily replayed. If I get good results, I'll write a blog post about it
=== gerald is now known as Guest35371
[14:58] <jsalisbury> bjf, want me to apply the 3.11.10.4 updates to Saucy master-next ?
[14:59] <bjf> jsalisbury, yup, go for it
[14:59] <jsalisbury> bjf, cool.  I'll push them to my git repo on zinc again and send a pointer
[15:02] <jsalisbury> bjf, also, there was an update from the bug report on bug 1254091 but he didn't update the tags
[15:02] <ubot2`> Launchpad bug 1254091 in linux (Ubuntu Saucy) "intel_pstate no_turbo patch from upstream" [Medium,In progress] https://launchpad.net/bugs/1254091
[15:44] <hvn2> question: after installation of a custom built kernel and rebooting, the tracking data shows the kernel image has bad data crc. How can I check beforehand if this is the case ?
=== cmagina_ is now known as cmagina
[16:08] <jsalisbury> henrix, I was cross checking the v3.11.10.4 patches I'll be applying to Saucy with your emails for 3.11.10.4 -stable review.  
[16:08] <jsalisbury> henrix, It seems this one is not in v3.11.10.4:
[16:08] <jsalisbury> [PATCH 3.11 233/233] ftrace: Have function graph only trace based on global_ops filters
[16:08] <jsalisbury> henrix, was that dropped?
=== vmesons is now known as vmeson
[16:13] <lag> cking: Hey Colin
[16:13] <cking> lag, yup
[16:13] <jsalisbury> henrix, ahh, I think this explains it: http://www.spinics.net/lists/stable/msg34983.html
[16:15] <lag> cking: Just to let you know, there's been a slight change of plan
[16:15] <lag> cking: As your patch turned into a code clarity patch, rather than a BUG, I'm going to push it though -next instead of -fixes
[16:15] <cking> lag, ok, sure, that makes sense
[16:15] <lag> cking: As your patch turned into a code clarity patch, rather than a BUG, I'm going to push it though -next instead of -fixes
[16:16] <lag> Whoops, wrong window to do (up + return)
[16:19] <henrix> jsalisbury: yep, it has been dropped (as you've already found out :) )
[16:20] <jsalisbury> henrix, great, thanks.  Just wanted to confirm :-)
=== kamal__ is now known as kamal
[16:31] <sforshee> smb: do you know if it's possible to run xen in a kvm guest?
[16:32] <smb> sforshee, not done that but with nested enabled on host ... theoretically
[16:33] <sforshee> smb: just looking for a way to run xen without sacrificing a physical machine
[16:33] <plars> bjf: psivaa and I are still seeing this test_010_proc_maps failures, at least on non-precise runs. Was there anything specific about the fix for that to precise?
[16:34] <smb> sforshee, Its not so much sacrificing... you still can boot normally after..
[16:35] <smb> I  just would fear an unknown amount of "nobody  tried that before" when trying to run inside a kvm VM
[16:36] <bjf> plars, can you look in the ubuntu_qrt_kernel_security.tar.bz2 tar file and see what the latest revno reported in the bzr.log file in that tar file is?
[16:43] <bjf> plars, it should be this: http://paste.ubuntu.com/6920824/
[16:43] <plars> bjf: ah, that's not the results file
[16:44] <plars> bjf: I was looking in the wrong thing, I don't know if I have that after the run, but I could wait for one running right now to finish and see what it has
[16:44] <bjf> plars, you should be able to look in your git repo
[16:50] <plars> bjf: ok, at least in our tree that seems correct
[16:54] <bjf> plars, i'll add code to the tests so that shows up in the output results
[17:03] <bjf> sbeattie, it sounds like CI is still seeing issues with the security test. it looks like they are now running the latest version. i'll add code to the tests so they report what version they are running
=== bjf is now known as [home-bjf]
[17:18] <hallyn> apw: hi, did i scare you away with the user.overlay.* idea for overlayfs? :)
[17:39] <apw> hallyn, i thought you decided you could make a big mess with that, removingwhiteouts
[17:40] <hallyn> apw: I don't undestand, but I think the answer is no (i didn't decide that ,that is :)
[17:40] <hallyn> apw: to remove a whiteout, the user would have to find the file on the writeable layer
=== Trevinho_ is now known as Trevinho
[18:06] <jsalisbury> henrix, I noticed there may be a change missing in 3.11.10.4, which came in with patch: 
[18:06] <jsalisbury> [PATCH 3.11 148/233] mmc: sdhci-pci: Fix BYT sd card getting stuck in runtime suspend
[18:06] <jsalisbury> henrix: The sdhci_intel_mrst_hc1_hc2 struct is missing the addition of  .own_cd_for_runtime_pm = true,
[18:07] <henrix> jsalisbury: checking...
[18:07] <henrix> jsalisbury: ah, i see what you mean
[18:08] <henrix> jsalisbury: so, that structure is actually on a different place in 3.11
[18:08] <henrix> jsalisbury: it is defined in drivers/mmc/host/sdhci-pci.c instead of rivers/mmc/host/sdhci-pci.h
[18:09] <henrix> jsalisbury: so, the change is still there, but in a different place
[18:09] <henrix> jsalisbury: does this makes sense to you?
[18:09] <jsalisbury> henrix, hmm, I don't see the change in that file.  
[18:10] <jsalisbury> henrix, I see that you backported that struct into drivers/mmc/host/sdhci-pci.c, which I'll have to move back to drivers/mmc/host/sdhci-pci.h for Saucy, heh
[18:11] <henrix> jsalisbury: you're talking about commit d097d786191a4cd882d622479a742a90605004c6 (in the stable tree), right?
[18:11] <jsalisbury> henrix, I see the struct defined in drivers/mmc/host/sdhci-pci.c, but it seems to me missing the addition of own_cd_for_runtime_pm = true
[18:11] <jsalisbury> static const struct sdhci_pci_fixes sdhci_intel_mrst_hc1_hc2 = {
[18:11] <jsalisbury>         .quirks         = SDHCI_QUIRK_BROKEN_ADMA | SDHCI_QUIRK_NO_HISPD_BIT,
[18:11] <jsalisbury>         .probe          = mrst_hc_probe,
[18:11] <jsalisbury> };
[18:12] <henrix> hmmm....
[18:13] <jsalisbury> henrix, hmm, maybe a later commit dropped it?  
[18:14] <henrix> jsalisbury: ok, so 2 sdhci_pci_fixes struct instances are modified: sdhci_intel_mfd_sd and sdhci_intel_byt_sdio. correct?
[18:14] <hallyn> oh no.  is lvm in trusty supposed to be working?
[18:14] <henrix> actually, sdhci_intel_mfd_sd and sdhci_intel_mfd_sdio
[18:15] <henrix> gah! i'm confused :)
[18:15] <jsalisbury> henrix, for that commit, should be three:
[18:15] <jsalisbury> sdhci_pci_fixes, sdhci_intel_mrst_hc1_hc2 and sdhci_intel_byt_sdio
[18:16] <jsalisbury> wait
[18:17] <henrix> jsalisbury: sdhci_intel_mrst_hc1_hc2?
[18:17] <hallyn> lvcreate/lvremove on trusty kernel on precise host is taking a long time;  acting like it is trying to dd all 50G (creating a snapshot) and not killable
[18:17] <henrix> jsalisbury: i'm looking at the original commit (77a0122e0838663795651aa0beb2325156f98c09) and it this is not modified
[18:18] <hallyn> looks like udev rules are causing a hang
[18:18] <henrix> jsalisbury: ah, maybe you're looking at the '@@ -225,6 +225,7 @@ static const struct sdhci_pci_fixes sdhci_intel_mrst_hc1_hc2 = {' line?
[18:18] <jsalisbury> henrix, sorry, let me check again. 
[18:18] <hallyn> this rings a bell.
[18:18] <jsalisbury> henrix, yes, I think that is what I'm doing
[18:20] <jsalisbury> henrix, yeah, sorry to have caused the confusion.  I was looking at the wrong struct in the diff
[18:20] <henrix> jsalisbury: uff!  :)
[18:21] <hallyn> i bet slangasek remembers this...
[18:21] <henrix> jsalisbury: anyway, thanks for reviewing.  these sort of mistakes have happen in the past, so...
[18:21] <hallyn> maybe udev changelog will jog my memory
[18:23] <jsalisbury> henrix, that commit failed when applying to saucy.  It was due to the move of structs to the header file like you say.  mainline moved some structs to the header file, your 3.11.10.4 moves them back, then Saucy moves them back out.
[18:24] <jsalisbury> henrix, thanks for reviewing and helping un-cross my eyes, heh
[18:24] <henrix> jsalisbury: heh.. anyway, its odd saucy has the struct in a different place. i guess a SAUCE patch (probably cherry-picked from 3.12+) has done that
[18:25] <jsalisbury> henrix, yes, a SAUCE patch, cherry-picked from 3.14-rc1: 
[18:25] <jsalisbury> https://lists.ubuntu.com/archives/kernel-team/2014-January/038073.html
[18:27] <henrix> ah, ok.  that would explain it :)
[18:28] <hallyn> hm, was transient.  will wait till it happens again to open a new bug i guess
=== chuck_ is now known as zul
[19:23] <slangasek> hallyn: lvcreate/remove being slow doesn't ring a bell to me; there've been issues with udev rules in the past, but I think those were all resolved for precise
[19:24] <hallyn> slangasek: hm, thanks.  I remember the udev rule thing having to do with watershed;  but don't recall the details or what we fixed.
[19:25] <hallyn> I guess somehow I ended up having 'lvcreate' race with a udev rule for the lvm lock.  <shrug>  This is a trusty kernel on precise host, btw.
[19:25] <hallyn> i'll file a bug if/when it happens again
=== zz_mwhudson is now known as mwhudson
[20:14] <jsalisbury> bjf, sconklin, I finished applying the 3.11.10.4 updates to Saucy.  However, I'm getting an abi check error, when performing a test build:  
[20:14] <jsalisbury> https://pastebin.canonical.com/104737/
[20:15] <sconklin> looking
[20:15] <bjf> jsalisbury, is there a "start new release" after the previous release and before your changes?
[20:15] <jsalisbury> bjf, checking
[20:15] <sconklin> yeah, what he said
[20:16] <hvn2> question: how can I verify beforehand if a new uImage has a wrong crc ?
[20:20] <jsalisbury> bjf, sconklin It does'nt look like there was a "Start new release".  The last one was before Ubuntu-3.11.0-17.31.  Here is the tip of the saucy tree I used:
[20:20] <jsalisbury> https://pastebin.canonical.com/104739/
[20:20] <sconklin> jsalisbury: right.
[20:20] <bjf> jsalisbury, ok, run maint-start-new-release in that tree then rebase that down to just after the commit for the last release
[20:21] <jsalisbury> sconklin, bjf, ok, got it.  Thanks!
[20:21] <sconklin> That's something you didn't know to look for. There should always be a start-new-release right after a release on master-next, but you have to wait to do it until the packages are built.
[20:22] <sconklin> sometimes some patches get applied to master-next in that window, and you have to go back and reorder things in master-next to 'insert' a start new release commit
[20:22] <jsalisbury> sconklin, I knew to look for it when turning the crank, but not while applying stable updates
[20:22] <sconklin> ack, ok
[20:22] <jsalisbury> sconklin, now I know :-D
[20:23] <bjf> jsalisbury, it's all about bumping the abi
[20:24] <jsalisbury> bjf, abi == "aggravating binary interface"
[20:24] <jsalisbury> :-)
[20:42] <jsalisbury> bjf, sconklin, Hmm, do I need to do the 'start new release' before applying the stable updates?  It does'nt seem like it.
[20:42] <bjf> jsalisbury, no
[20:43] <jsalisbury> bjf, I'm getting an error doing the rebase.  I'll see if I can figure it out
=== SpamapS_ is now known as SpamapS
[20:58] <sconklin> hey joe, would you like for me to put the startnewrelease on and rebase that so you have a clean tree with the right ABI files to apply the upstream?
[20:59] <sconklin> jsalisbury: ^^
[21:03] <jsalisbury> sconklin, I don't think so.  I'll see if I can get it to work.  It will help me learn :-)  I'll ask you to do it if I can't get it to work.
[21:04] <sconklin> cool, that's probably the right answer
[21:04] <jsalisbury> sconklin, I'm going to grab some lunch, then start it from scratch to help memorize the steps.  I'll let you know if I get hung up.
[21:05] <sconklin> ok, np
[21:05] <jsalisbury> sconklin, thanks for the help!
[21:48] <bjf> sbeattie, did you see the earlier comment about the security test failing still?
[21:48] <sbeattie> bjf: I did not, sorry.
[21:48] <bjf> sbeattie, np
[21:49] <bjf> sbeattie, looks like we are now running the latest tests
[21:49] <bjf> sbeattie, plars has a test run he just recently did on saucy and it failed
[21:50] <sbeattie> bjf: got a pointer to the failure? I can never navigate the forest of jenkins servers you guys have
[21:50] <bjf> plars, ^
[21:51] <plars> sbeattie: https://jenkins.qa.ubuntu.com/job/sru_kernel-saucy-virtual_amd64-kvm-virtual/93/
[21:57] <plars> sbeattie: on the plus side, it does seem to be working ok on precise
[22:00] <sbeattie> plars: this looks like the same issue: either the QRT script is out of date, or else /usr/share/doc/linux-image-3.11.0-17-generic/changelog.Debian.gz doesn't contain a reference to CVE-2013-2929
[22:02] <plars> sbeattie: bjf just made some changes to have it show which rev of the qrt tests its running, I need to update our copy and rerun, but given that it's pulling from the same source that our precise tests are pulling from (which now work) I think we have an updated qrt now
[22:04] <sbeattie> well, it's the same failure, where a test is succeeding where it wasn't expected to, and the reason it's not expecting it to is because the kernel version is between a specific range and the test can't find that CVE number in the kernel's changelog.
[22:31] <sbeattie> plars: ohhhhh. the changelog gets reset each go around. Okay, I'm just going to assume that CVE-2013-2929's been fixed everywhere.
[22:34] <plars> sbeattie: I'm not sure I follow
[22:34] <plars> sbeattie: this is something you are scanning for in that changelog with qrt?
[22:36] <sbeattie> yes, I was changing the expectation of the test based on whether the kernel was claiming it had been fixed.
[22:37] <sbeattie> I'm ripping that out now, and will expect the test to pass.
=== psivaa is now known as psivaa-afk
[22:40] <sbeattie> plars, bjf: rev 2119 of QRT should cause things not to fail anymore.
[22:40] <sbeattie> plars: the saucy kernel should not be blocked on that test-kernel-security failure, if you don't want to re-run tests.
[22:41] <plars> sbeattie: ok, that's all that's failing on it so I'll mark it good then
[22:42] <plars> bjf: any further thoughts on the btrfs test at https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1267469? Given that the proc maps thing is resolved and the config_debug_rodata is a known issue, I think we can mark that one good as long as you are comfortable that the btrfs test failure was just a timing thing?
[22:42] <ubot2`> Launchpad bug 1267469 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.2.0-1443.62 -proposed tracker" [Medium,In progress]
[23:44] <miseria> "la verdadera felicidad de un ser humano, se logra cuando deja de ser esclavo, de la avaricia y la codicia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*