| === gerald is now known as Guest90138 | ||
| === zz_mwhudson is now known as mwhudson | ||
| miseria | "ajedrez batalla entre negros y blancos, al final del final el blanco no tendra peones y el negro prevalecera" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival* | 02:44 |
|---|---|---|
| === BruceMa is now known as BruceMa-afk | ||
| === BruceMa-afk is now known as BruceMa | ||
| ppisati | moin | 07:38 |
| === lag` is now known as lag | ||
| xnox | smb: i'll be uploading dmraid/mdadm into the archive today, blocked in proposed. I didn't manage to get migration from dmraid -> mdadm smooth yesterday. | 08:19 |
| xnox | (a) kpartx is not executed on mdadm assembled arrays, like it was on dmraid -> thus one doesn't get all partitions present. (and adding a kpartx run to udev rule, didn't do it for me =( ) | 08:20 |
| xnox | (b) and i didn't get compat symlinks for kpartx generated devices in above. | 08:21 |
| xnox | at least we'll drop dmraid45 dependency, and one can test mdadm assembly from the archive. | 08:22 |
| xnox | (i'll disable imsm and ddf assembly by mdadm with a config file) | 08:22 |
| smb | xnox, ok, I can check it out pulling the proposed versions. partitions... weird I have partitions on my test raid5 and beside of the downside of mdadm thinking the array is degraded I at least believe to have had partitions with mdadm | 08:36 |
| xnox | smb: i only get a device for container (/dev/md/imsm0 or /dev/md127) & the array (/dev/md/Volume1 or /dev/md126), but not partitions in the array. | 08:41 |
| xnox | smb: mdadm does think the array is degraded, even though that is a lie =) as containers never leave inactive state... and our check believed it was. | 08:42 |
| xnox | (or e.g. the array can be in-progress rebuilding) | 08:42 |
| smb | xnox, Hm, I have to check with the version you uploaded, but I got md127px devs, too | 08:42 |
| xnox | smb: interesting. | 08:44 |
| smb | xnox, Ok, so just to confirm, with the dmraid which has no support for ism at all plus old mdadm (+udev rule addition to act on isw_members), I currently get /dev/md126p? (not 127) and even /dev/md/Volume0p? symlinks. | 09:00 |
| xnox | smb: ok. I am using dmraid with ism support compiled, but disabled to not activate the devices, plus mdadm with rules to assemble isw_members, i only get naked devices/symlinks without partitions. | 09:02 |
| xnox | i wonder if i really should not compile isw in dmraid. | 09:03 |
| smb | xnox, odd... Well I will replace my versions with your uploaded ones and check whether this happens to me, too. | 09:03 |
| smb | I guess (iirc) if the script called by udev does not act on isw it should not matter whether dmraid supports things or not | 09:04 |
| smb | And I would guess that is where you handle the config setting | 09:05 |
| * apw hates rebasing... | 09:40 | |
| apw | morning | 09:40 |
| smb | apw, Morning, as long as its only a git tree and not yourself you rebase... | 09:41 |
| apw | yeah at least i can reset my tree on error | 09:45 |
| apw | sounds like fun is being had with mdraid | 09:46 |
| smb | apw, Software is always fun... changing software doubly so... :-P | 09:54 |
| psivaa | sbeattie: bjf: we have this failure in armadaxp SRU, with precise kernel: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/97/testReport/autotest/ubuntu_qrt_kernel_security/test_kernel_security_py/? | 09:58 |
| psivaa | i reran the test to confirm if it's persistent and it occurred during both runs. | 09:59 |
| cking | apw, do you mind syncing packages thermald and health-check some time today for me? | 10:08 |
| infinity | cking: sync from Debian? I can do that. | 10:13 |
| infinity | cking: Done. | 10:14 |
| infinity | cking: Hrm, powerpc, but no ppc64 or ppc64el? | 10:14 |
| * cking slaps himself, bad me | 10:15 | |
| infinity | cking: Do you have reason to believe it won't work with 64-bit userspace? | 10:15 |
| infinity | cking: (I assume with "powerpc", you're already assuming it works with 64-bit kernels...) | 10:16 |
| cking | infinity, no, I forgot to put those arches in, nnggg | 10:16 |
| cking | i guess another tweak and upload is now required... | 10:16 |
| infinity | cking: Well, I can fix it in Ubuntu right now for you, and you can fix it in Debian whenever. | 10:17 |
| infinity | cking: ppc64 is an unofficial arch in Debian, and ppc64el doesn't exist yet at all, so... | 10:17 |
| cking | infinity, if you can, that would be awesome, and I can fix it for the next time I do any other bug fixes | 10:17 |
| cking | can't believe I did the tricky part and screwed up the easy bit | 10:19 |
| infinity | cking: No arm64 yet? | 10:19 |
| cking | infinity, if I get access to H/W I can try it out.. and then add that too ;-) | 10:19 |
| infinity | Heh. | 10:19 |
| infinity | cking: Oh, also, you don't need all the "linux-" prefixes, it just clutters up the control file. | 10:19 |
| infinity | cking: "amd64" *is* "linux-amd64", there's no ambiguity. | 10:20 |
| cking | ah, ok | 10:20 |
| infinity | any-i386 == i386, hurd-i386, kfreebsd-i386, but i386 on its own is just i386, which is the Linux port. | 10:21 |
| infinity | So, I'll fix that up too while I'm in here, and you can sync it back when you care. | 10:21 |
| cking | ok, thanks, I remember that for next time I do anything so arch specific, like never I hope | 10:21 |
| infinity | Well, it would be perfectly reasonable, IMO, to just have it be "any" as well, if it'll FTBFS on unsupported arches. | 10:22 |
| infinity | It's only bad if it builds but is completely broken subsequently. | 10:22 |
| infinity | (or linux-any, if it's linux-specific) | 10:22 |
| cking | ok, but I hate seeing FTBFS on other arches when I know it won't work.. | 10:23 |
| infinity | Heh, fair enough. To each their own. | 10:23 |
| infinity | I like the red FTBFS items as a subtle reminder that I have things to fix. :) | 10:23 |
| cking | very true | 10:23 |
| infinity | cking: Uploading this: http://paste.ubuntu.com/6953727/ | 10:25 |
| xnox | now i'm enjoying UEFI which selects the wrong hard-drive to boot off... | 10:25 |
| infinity | cking: unless you have reason to believe x32 wouldn't work. | 10:25 |
| cking | infinity, well, I'm not 100% sure, it may just go horribly wrong, I can't recall what's required for x32 special cases | 10:27 |
| cking | let's see if it breaks, I can always fix it later :-) | 10:27 |
| apw | heh | 10:27 |
| infinity | cking: There's some syscall duplication, and, of course, not effing up your pointer sizes, but otherwise I expect anything that works on amd64 to Just Work on x32. | 10:27 |
| infinity | cking: Should be testable with gcc-multilib installed and gcc -mx32 | 10:28 |
| infinity | Anyhow, uploading for kicks. | 10:28 |
| cking | ok, I can give it a spin later today :-) | 10:28 |
| infinity | We don't build for x32 in Ubuntu anyway, this is more for the benefit of the unofficial Debian x32 port when you go and merge this back. | 10:29 |
| cking | yup, i've tinkered with that a while ago | 10:29 |
| infinity | cking: As for arm64 hardware, do you have access to batuan? | 10:30 |
| * cking checks, yep | 10:31 | |
| infinity | cking: ubuntu@10.229.32.99 from batuan, then. | 10:31 |
| cking | ack | 10:31 |
| infinity | cking: Password as insecure as you suspect it. Full sudo. Please make a user and work in your ~ | 10:32 |
| cking | shiney | 10:32 |
| infinity | Err, and there's a whopping 1.7G free. Let me see who needs slapping. | 10:32 |
| xnox | smb: i believe i had invalid half of GPT partition table (either primary or backup) recreating the array and recreating partition table, now results in proper md126p? and md/Volume1p? devices to appear. | 11:04 |
| smb | xnox, Errm, I hate to say I think you forgot a little "exit 0" in the dmraid-activate script as well | 11:04 |
| smb | Given that after install there is no (dm) raid for me and in the check for nomdmonddf looks odd too | 11:05 |
| smb | Oh its negated... | 11:06 |
| smb | but anyway exit 0 is just wrong | 11:06 |
| smb | xnox, Though maybe phrasing both as "mdadm xxx assembly disabled by boot option" would be less hm... strange? | 11:07 |
| xnox | smb: yeah missing exit 0. | 11:12 |
| xnox | correcting text. | 11:13 |
| smb | xnox, I guess it should be about what is default. But I catch myself going something disabled ... something enabled... wait were those options not both nomd...bla...? :) | 11:15 |
| xnox | =))) | 11:15 |
| xnox | smb: also the /etc/default/grub.d/dmraid2mdadm.cfg | 11:16 |
| smb | Oh, _there_ those come form | 11:16 |
| smb | I was already wondering... did we have a grub.d there ever before? | 11:17 |
| xnox | smb: that's fairly new. we have /etc/grub.d/ for template generators, /etc/default/grub for default "settings" and /etc/default/grub.d/ for sourced settings.... | 11:17 |
| xnox | e.g. kexec-tools uses the last one as well to set crashkernel= line | 11:18 |
| smb | xnox, Neat to know for me ... There might be some use for that for Xen... | 11:18 |
| smb | xnox, Ok, so the switch to md works for me and has partitions, too. | 11:29 |
| smb | So the only problem I saw was the "exit 0" | 11:30 |
| smb | And maybe but thats RTFRN the surprising source of the nomd* grub cmdline args | 11:31 |
| jsalisbury | apw, It looks like the amd64 kernel is missing for the 3.14-rc3 mainline build: | 14:19 |
| jsalisbury | http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc3-trusty/ | 14:19 |
| pkern | Is there an relatively easy way to add a suffix to the Ubuntu kernel version when compiling it? "DEB_BUILD_OPTIONS=parallel=14 AUTOBUILD=1 NOEXTRAS=1 /usr/bin/time fakeroot debian/rules binary-generic" is the current build command I use. |: | 14:44 |
| arges | jsalisbury: I was going to mention the same thing. : ) was just going to test with latest | 14:51 |
| jsalisbury | arges, I haven't tried to build manually yet, or search upstream to see if its a known issue. | 14:52 |
| arges | /bin/bash: line 0: cd: /home/apw/COD/linux/debian/build/tools-perarch/tools/hv: No such file or directory | 14:53 |
| arges | from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/BUILD.LOG | 14:53 |
| arges | apw: ^^^ might want to look | 14:54 |
| === JanC_ is now known as JanC | ||
| apw | jsalisbury, yep upstream does not build on that arch.... sucks to be it | 15:03 |
| jsalisbury | apw, whoops | 15:03 |
| apw | pkern, add your suffix to debian.master/changelog, to the first version entry there | 15:03 |
| apw | arges, meh mainline smainline | 15:03 |
| hallyn | smb: so I'm not sure if you were waiting for more info from me about the overlayfs-whiteout patch... pls ping me if you are | 15:08 |
| apw | hallyn, for me, i have not yet had a chance to think about why that one bit differs from the rest; why it is able to take the privs it needs elsewhere to copy up for instance, and yet does not do the trusted.* bit under the same elevatio | 15:13 |
| smb | hallyn, No, after realizing that the first part describes how whiteout is done right now, I understood the patch. Hm, oh just to make sure: this was targeted for some upstream. Or were you asking us (kernel-team) to apply it to Trusty? | 15:13 |
| rtg | apw, pushed 'UBUNTU: [Config] CONFIG_CGROUP_SCHED=y for ppc64el' after test build. There are a couple of other cgroup related configs that I'll make consistent as well. | 15:25 |
| pkern | apw: I wonder if AUTOBUILD=1 NOEXTRAS=1 does the ABI checks. So I tried -17gg.31 as a version but it did not pick 17gg as the ABI identifier. ;) I think I do want to diverge in the package name. So I'm not sure where to place the suffix. |: | 15:26 |
| ppisati | apw: what was the name of the pastebin cli tool? | 15:36 |
| apw | ppisati, pastebinit | 15:36 |
| ppisati | ah | 15:36 |
| ppisati | 10x | 15:36 |
| apw | pkern, no the abi on disk is always just the numeric prefix | 15:37 |
| hallyn | smb: there is no 'upstream' right now AFAIUI. I cc:d Miklos, but overlayfs is not upstream so... | 15:41 |
| hallyn | apw: the copy-up only requires write access to the writeable layer. That requires either uid equivalence, or *targeted* capabilities to the user namespace owning the inode | 15:41 |
| hallyn | apw: writing to trusted.* xattrs requires capabilities targeted to the *initial* user namespace | 15:42 |
| hallyn | that's the bit I'm changing, poking a hole just for trusted.overlay* | 15:43 |
| apw | hallyn, i mean to say overlayfs is already raiding its creds beyond the caller to do the copy | 15:52 |
| apw | hallyn, why is it not raising them to what it needs | 15:52 |
| jsalisbury | ## | 15:52 |
| jsalisbury | ## Kernel team meeting today @ 17:00 UTC in #ubuntu-meeting | 15:52 |
| jsalisbury | ## | 15:52 |
| hallyn | apw: it raises all creds. But the creds are targeted to cred->userns. Now I suppose we could look into changing the userns there. That may be deemed a 'correct' fix. not quite sure | 15:54 |
| === vmesons is now known as vmeson | ||
| bjf | arges, you around? | 16:23 |
| arges | bjf: yes | 16:23 |
| bjf | arges, did you SRU a netfilter: nf_conntrack commit for Precise ? | 16:23 |
| arges | bjf: yes | 16:23 |
| bjf | arges, it doesn't build :-( | 16:24 |
| arges | hmm... | 16:24 |
| bjf | arges, yeah, that's what i say | 16:24 |
| arges | bjf: so assuming by precise you mean 3.2 | 16:24 |
| rtg | amb, apw, are you both happy with '[PATCH 1/1] overlayfs, xattr: allow unprivileged users to whiteout' ? | 16:25 |
| bjf | arges, i can fix it but i'm grumpy. yes 3.2 | 16:25 |
| rtg | smb^^ | 16:25 |
| arges | bjf: i'll fix it. re-building/testing it now | 16:25 |
| apw | rtg, i am still thinking about it | 16:25 |
| rtg | apw, frankly, I don't know how to think about it. too inexperienced in that subsystem. | 16:26 |
| apw | rtg, i need to sit down and look at it and not had any "uninterrupted time" to think on it | 16:27 |
| rtg | apw, log off of IRC, that'll help :) | 16:27 |
| bjf | arges, /tmp/kernel-bradf-RBDocT6R/build.log on tangerine | 16:27 |
| hallyn | apw: override_creds vs. userns will probably need to be addressed more fully at some point, but it's not entirely clear how to best do that. | 16:34 |
| hallyn | i.e. if a thread is running as root and wants to switch to some uid or subuid, there is no good way for it to get a good userns | 16:35 |
| hallyn | now i guess in those cases it doesn't matter as much. the case where we care is override_creds to root | 16:35 |
| hallyn | so maybe an 'override_creds_to_init_root()' would be useful as a new helper; for nfs and overlayfs. but i'm guessing there'll be bikeshedding on that till summertime | 16:36 |
| psivaa | bjf: curious if you saw my previous message to you and sbeattie about the precise armadaxp test failure on the SRU. | 16:42 |
| psivaa | https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/97/testReport/autotest/ubuntu_qrt_kernel_security/test_kernel_security_py/? | 16:42 |
| bjf | psivaa, i had not seen it | 16:42 |
| psivaa | bjf: ack, this is holding the release of the armadaxp precise kernel | 16:42 |
| psivaa | bjf: i've run twice just to confirm if this is reproducible and it is | 16:43 |
| bjf | ppisati, do you have access to one of these armadaxp boards ? | 16:43 |
| ppisati | bjf: uhm no, i may ask on #hwe if needed | 16:44 |
| bjf | ppisati, is that ike's baby? | 16:44 |
| ppisati | bjf: hold on | 16:44 |
| ppisati | bjf: yep | 16:44 |
| ppisati | weird | 16:45 |
| ppisati | that's a compile time opt | 16:45 |
| ppisati | either it was changed in the last upload | 16:45 |
| ppisati | or i don't know | 16:45 |
| bjf | yeah | 16:46 |
| * apw finds it a little off that he can build "unstable" ok but the mainline 3.14-rc3 doesn't build ... | 16:55 | |
| apw | rtg, you didn't add any local patches did you ... hmmm | 16:55 |
| jsalisbury | ## | 16:56 |
| jsalisbury | ## Kernel team meeting in 5 minutes in #ubuntu-meeting | 16:56 |
| jsalisbury | ## | 16:56 |
| rtg | apw, other then the usual SAUCE and other ubuntization, I can't recall... | 16:57 |
| ppisati | psivaa: uhm | 17:05 |
| ppisati | [flag@luxor ubuntu-precise]$ git grep "config DEBUG_RODATA" | 17:05 |
| ppisati | arch/parisc/Kconfig.debug:config DEBUG_RODATA | 17:05 |
| ppisati | arch/x86/Kconfig.debug:config DEBUG_RODATA | 17:05 |
| ppisati | arch/x86/Kconfig.debug:config DEBUG_RODATA_TEST | 17:05 |
| ppisati | [flag@luxor ubuntu-precise]$ | 17:05 |
| ppisati | psivaa: and indeed, it's off in my omap4 branch | 17:05 |
| ppisati | psivaa: what do you do wrt omap4 for that test? does it run? or do you skip it? | 17:06 |
| ppisati | psivaa: i guess the second | 17:06 |
| ppisati | psivaa: and when the last time that test was run on the armadaxp kernel? | 17:06 |
| ppisati | *when was | 17:06 |
| psivaa | ppisati: so for omap4 with precise we run it manually, and i think it's skipped. but let me confirm it in a bit | 17:07 |
| psivaa | for armadaxp this was run yesterday | 17:08 |
| ppisati | psivaa: and it failed, right? | 17:08 |
| psivaa | ppisati: yes | 17:08 |
| ppisati | psivaa: i mean, last time it was run and it passed | 17:08 |
| ppisati | psivaa: because IMO, that test should never run for arm | 17:08 |
| ppisati | psivaa: at least in precise, maybe newer kernel have that | 17:09 |
| psivaa | ppisati: ack, let me check | 17:09 |
| psivaa | ppisati: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-precise-generic-armhf_omap4_armada1-serial/90/consoleText has that test passing | 17:11 |
| === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 25th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| psivaa | ppisati: the kernel tested was 3.2.0-1630.42 | 17:11 |
| ppisati | psivaa: that's impossible | 17:12 |
| ppisati | psivaa: [flag@luxor ubuntu-precise]$ grep RODATA debian/build/build-omap4/.config | 17:13 |
| ppisati | [flag@luxor ubuntu-precise]$ | 17:13 |
| ppisati | psivaa: that option is off in precise/omap4, so how can the test pass? | 17:13 |
| psivaa | ppisati: no idea but assume you've seen the above link :) | 17:15 |
| ppisati | psivaa: where is the code for the test suite? | 17:15 |
| psivaa | ppisati: we pull the code from git://kernel.ubuntu.com/ubuntu/autotest-client-tests | 17:16 |
| ppisati | psivaa: are you sure those are the test that you are running? | 17:21 |
| ppisati | psivaa: [flag@luxor autotest-client-tests]$ grep -Ri config_debug_rodata * | 17:22 |
| ppisati | kernbench/config:CONFIG_DEBUG_RODATA=y | 17:22 |
| ppisati | kernbench/config:# CONFIG_DEBUG_RODATA_TEST is not set | 17:22 |
| ppisati | [flag@luxor autotest-client-tests]$ | 17:22 |
| ppisati | psivaa: [flag@luxor autotest-client-tests]$ git grep KernelSecurityTest | 17:22 |
| ppisati | [flag@luxor autotest-client-tests]$ | 17:22 |
| ppisati | psivaa: bzr+ssh://bazaar.launchpad.net/%2Bbranch/qa-regression-testing/ | 17:27 |
| arges | apw: well 3.13.0-8-lowlatency locks up my laptop : ) | 17:28 |
| arges | time for -9 | 17:28 |
| psivaa | ppisati: i'm pretty sure we run the tests that's in the git repo. and i see exactly same output: | 17:28 |
| psivaa | usit@morgan:~/kernel-sru/branches/autotest-client-tests$ grep -Ri config_debug_rodata * | 17:29 |
| psivaa | kernbench/config:CONFIG_DEBUG_RODATA=y | 17:29 |
| psivaa | kernbench/config:# CONFIG_DEBUG_RODATA_TEST is not set | 17:29 |
| psivaa | usit@morgan:~/kernel-sru/branches/autotest-client-tests$ git grep KernelSecurityTest | 17:29 |
| psivaa | usit@morgan:~/kernel-sru/branches/autotest-client-tests$ | 17:29 |
| psivaa | ppisati: and that's what we run the test on.. not sure how/why the tests are not skipped | 17:29 |
| zequence | arges: Try using nothreadirqs boot parameter | 17:29 |
| zequence | arges: Also, try linux-generic with threadirqs boot parameter, to see if it freezes too | 17:30 |
| arges | zequence: ok. is there already a bug # for this issue? | 17:30 |
| zequence | arges: I myself have a problem only when having a wifi driver loaded, with threadirqs. That makes the kernel freeze | 17:30 |
| zequence | arges: Yes. A few bugs, that may be related | 17:30 |
| zequence | arges: bug: 1279081 | 17:31 |
| ubot2` | Launchpad bug 1279081 in linux (Ubuntu) "linux freezes with threadirqs parameter when rt73usb is loaded" [High,Confirmed] https://launchpad.net/bugs/1279081 | 17:31 |
| arges | cool subscribing | 17:31 |
| ppisati | psivaa: the actual test is not there, how can the test be there if grepping for any string doesn't return anything? | 17:34 |
| ppisati | psivaa: File "./test-kernel-security.py", line 672, in test_072_config_debug_rodata | 17:34 |
| ppisati | psivaa: can you find that file? no | 17:34 |
| psivaa | ppisati: let me see | 17:34 |
| ppisati | psivaa: the actual test is here: bzr+ssh://bazaar.launchpad.net/%2Bbranch/qa-regression-testing/ | 17:35 |
| ppisati | psivaa: flag@luxor qa-regression-testing]$ ls -la scripts/test-kernel-security.py | 17:35 |
| ppisati | -rwxrwxr-x 1 flag flag 63535 Feb 18 18:26 scripts/test-kernel-security.py | 17:35 |
| psivaa | ppisati: we dont use the qrt from bzr directly.. bjf may be able to give a better explanation for that | 17:36 |
| ppisati | psivaa: do you have a log from an omap4 kernel testing? | 17:37 |
| psivaa | ppisati: i dont see scripts/test-kernel-security.py in our test code. yes let me find the omap4 logs | 17:38 |
| henrix | ppisati: psivaa: iirc, those tests are actually inside a bz2 archive in the source tree. but it's been a while since last time i looked | 17:40 |
| psivaa | ppisati: https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/job/sru_kernel-quantal-generic-armhf_omap4_panda_ES-serial/163/consoleFull is the omap4 logs | 17:40 |
| ppisati | 21:39:16 ERROR| [stderr] test_072_config_debug_rodata (__main__.KernelSecurityTest) | 17:41 |
| ppisati | 21:39:16 ERROR| [stderr] CONFIG_DEBUG_RODATA enabled ... FAIL | 17:41 |
| ppisati | indeed that options is off | 17:41 |
| arges | bjf: hey, sent an updated patch. it builds and boottest works | 17:41 |
| psivaa | ppisati: this log has that test 'FAIL' although jenkins report at the end as no test failures. this has now been fixed | 17:41 |
| bjf | arges, thanks | 17:42 |
| ppisati | psivaa: as i said, DEBUG_RODATA is not available on arm in that kernel, so it's normal that the test fails | 17:44 |
| psivaa | ppisati: sorry i am confused. do you mean to say that it's expected that the test fails on omap4 *and on armadaxp boards since the kernel does not have DEBUG_RODATA? | 17:49 |
| bjf | arges, did you send that me directly? i'm not seeing it | 17:50 |
| arges | bjf: sent it to kteam ml | 17:51 |
| ppisati | psivaa: yes, either that test was skipped or no one noticed it since now | 17:51 |
| psivaa | ppisati: ok, the test is not skipped in our setup as we could see. right ( sorry i am trying to understand as we are going.. so bear with me :)) | 17:51 |
| arges | bjf: i just fwd it directly to you as well | 17:52 |
| bjf | thanks | 17:52 |
| bjf | arges, got it | 17:54 |
| * ppisati -> EOD | 17:58 | |
| kees | henrix, sbeattie: odd, ARM should not be testing for CONFIG_DEBUG_RODATA. that option doesn't exist yet there. | 18:04 |
| kees | the test should be skipping that check. | 18:04 |
| kees | also, how come jenkins output doesn't log correctly? the notes on tests (the stuff in ()s) isn't logged in the correct place. | 18:05 |
| henrix | psivaa: ^^ | 18:05 |
| psivaa | kees: i dont understand your comment. where is it wrong. | 18:08 |
| gQuigs | kernel 3.14 landing in 14.04 is not possible anymore? | 18:11 |
| kees | psivaa: the test itself should be detecting that it is an ARM kernel and not requiring the CONFIG_DEBUG_RODATA option. the test appear broken, but it's a harmless failure condition. | 18:17 |
| kees | psivaa: or did you mean the jenkins output? | 18:17 |
| manjo | rtg, what is the final kernel version for trusty? | 18:18 |
| psivaa | kees: i'm not really bothered about jenkins output issue if that failure is harmless :) | 18:18 |
| rtg | manjo, 3.13.x | 18:18 |
| psivaa | kees: just was talking to plars and there was already a bug opened for this: https://bugs.launchpad.net/qa-regression-testing/+bug/1190668 | 18:18 |
| ubot2` | Launchpad bug 1190668 in QA Regression Testing "FAIL: test_072_config_debug_rodata (__main__.KernelSecurityTest) on SRU kernel 3.5.0-226.39 omap4" [Undecided,New] | 18:18 |
| plars | yeah, we get the same failure on omap4 | 18:19 |
| plars | for a while now, and were told that the option needs to be disabled in the kernel iirc | 18:19 |
| manjo | rtg, thanks... is it too late to request a pull from 3.14-RCX? possibly one or 2 patches | 18:19 |
| rtg | manjo, not too late, but its obviously dependent on the content of the patch. send it on the list. | 18:20 |
| manjo | rtg, will do when it lands there | 18:20 |
| kees | plars: the option doesn't exist on ARM kernels. it's the test that needs to be fixed to not expect it | 18:21 |
| manjo | rtg, atm there was a one liner hack that was put into saucy to get guest kernels to boot and use serial ... hopefully ppisati carried that fwd. The real fix is landing upstream somewhere in 3.14.rc1 according to linaro ... so just checking when it lands we could replace the hack with real fix | 18:25 |
| rtg | manjo, 3.14 is already at -rc3 | 18:25 |
| manjo | rtg, right ... checking on it and will let ppisati know | 18:26 |
| === mwhudson is now known as zz_mwhudson | ||
| miseria | "cuantos millones de humanos perderian su trabajo si un miserable salario minimo fuera mandatorio en el planeta?" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival* | 20:36 |
| === zz_mwhudson is now known as mwhudson | ||
| nickez | anybody knows what is going on with the 64bit dailies? | 21:46 |
| === mwhudson is now known as zz_mwhudson | ||
| === zz_mwhudson is now known as mwhudson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!