| === smb` is now known as smb | ||
| xnox | does CONFIG_ARCH_RANDOM enable usage of intel rdrand to seed /dev/random ? | 07:43 |
|---|---|---|
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| * henrix will be out for a bit | 09:47 | |
| tseliot | apw: I'm facing a problem with 3.10 and fglrx but I'm not sure it depends on my work on the procfs calls | 10:20 |
| apw | tseliot, sounds nasty indeed | 10:21 |
| tseliot | apw: I'm getting this http://paste.ubuntu.com/5783212/ | 10:24 |
| apw | tseliot, i think i recall them using bios calls to get the BIOS out of the card, and sucking info out of it | 10:25 |
| apw | perhaps a change in interface there for making int10 calls | 10:25 |
| tseliot | apw: hah, one more error: Fail to open device PCI:1:0:0 | 10:26 |
| apw | oh :) | 10:26 |
| tseliot | which is the actual amd card... | 10:26 |
| * ppisati goes out for a bit... | 11:48 | |
| * henrix -> lunch | 12:04 | |
| rtg_ | henrix, rebooting gomeisa for misc updates | 13:27 |
| henrix | rtg_: ack | 13:27 |
| apw | henrix, ok ... cve tracker is happy again | 14:01 |
| apw | henrix, totaaly a bug, and only affecting handlng of linus tree markers ie upstream_source: not any of the visible versions | 14:02 |
| henrix | apw: great, thanks. why something has to break whenever i touch cve tracker? :) | 14:02 |
| apw | henrix, cause you are doing work so it has to changed things :) | 14:03 |
| * henrix shakes on every bzr push :) | 14:03 | |
| apw | henrix, what you are doing is just fine :) its the tracker that has mental problems | 14:03 |
| smb | infinity, Did I ask you about looking at crash today? | 14:07 |
| rtg_ | slangasek, using libpython-dev as a build dependency instead of python-dev causes a build failure, e.g., make cannot find /usr/bin/python-config. | 14:27 |
| rtg_ | Makefile:755: The path '/usr/bin/python-config' is not executable. | 14:27 |
| rtg_ | Makefile:755: *** Please set 'PYTHON_CONFIG' appropriately. Stop. | 14:27 |
| rtg_ | I've not encountered this problem, so I could use your input. | 14:27 |
| slangasek | rtg_: hmm, that's strange, it *cross*-built for me just fine; in that case, I guess more work is needed before we can make the package cross-build-friendly | 14:40 |
| rtg_ | slangasek, yeah, I was just drilling down through the dependency layers. | 14:40 |
| rtg_ | slangasek, python-dev depends on python (which contains python-config) whereas libpython-dev does _not_ depend on python | 14:47 |
| slangasek | rtg_: actually, python-config should be in python-dev, *not* in python; that seems to be the case here | 14:48 |
| rtg_ | well, until hat bug is resolved I'm gonna drop that part of your patch. | 14:49 |
| slangasek | rtg_: yep, sounds fine | 14:49 |
| slangasek | I'm still puzzled that the package didn't ftbfs for me when building cross | 14:49 |
| slangasek | either maybe that's a clue, or maybe it's a subtle bug | 14:49 |
| rtg_ | slangasek, you're sure it tried to build perf ? | 14:50 |
| slangasek | yep | 14:50 |
| rtg_ | dunno then | 14:50 |
| slangasek | but maybe I didn't clean the tree between attempts | 14:50 |
| rtg_ | slangasek, what incantation did you use ? dpkg-buildpackage --arch=armhf ? | 14:50 |
| slangasek | rtg_: 'debuild -uc -us -B -aarmhf' | 14:51 |
| rtg_ | slangasek, 'do_tools= false' for armhf. | 14:54 |
| rtg_ | seems like I should fix that | 14:55 |
| slangasek | rtg_: ok :) | 14:56 |
| rtg_ | slangasek, man, this multi-arch cross build works great forarmhf on saucy. I feel stupid for having used QEMU to do all the Nexus kernel development. this is blazing fast. | 15:00 |
| slangasek | :D | 15:01 |
| slangasek | rtg_: well, when poking at this, I was shaking my head in bewilderment that the cross-build wasn't in better shape and wondering what exactly you guys were doing for ARM kernel testing ;) | 15:01 |
| rtg_ | slangasek, mostly native building. | 15:01 |
| slangasek | right :) | 15:02 |
| rtg_ | bjf, By default, no CPU will be an adaptive-ticks CPU. The "nohz_full=" | 15:23 |
| rtg_ | boot parameter specifies the adaptive-ticks CPUs. For example, | 15:23 |
| rtg_ | "nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks | 15:23 |
| rtg_ | CPUs. | 15:23 |
| rtg_ | see Documentation/timers/NO_HZ.txt | 15:24 |
| bjf | looking | 15:25 |
| bjf | rtg_, as i read that, it doesn't make sense for us to have CONFIG_NO_HZ_FULL=y | 15:27 |
| rtg_ | bjf, well, given that its causing problems.... Otherwise with CONFIG_NO_HZ_FULL=n there is no change in behavior | 15:28 |
| rtg_ | its opt in | 15:28 |
| bjf | rtg_, it's not opt in if _ALL=y: "the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies that all CPUs other than the boot CPU are adaptive-ticks CPUs" | 15:31 |
| rtg_ | bjf, right. its opt-in if CONFIG_NO_HZ_FULL=n | 15:32 |
| bjf | ack | 15:32 |
| rtg_ | bjf, so, disabling that config means the feature will get little testing. thats all I'm saying. | 15:33 |
| bjf | rtg_, agreed | 15:34 |
| rtg_ | bjf, perhaps you should reach out to Fred about this. he might have some ideas | 15:35 |
| bjf | rtg_, i just don't see that option being viable for a general desktop kernel | 15:40 |
| rtg_ | bjf, it seems like it would be the cat's meow if it worked. | 15:41 |
| slangasek | ogra_: so dropping in the new kernel with the console fixes yesterday gives me a perfect, no-scrolly-text container-flipped boot on grouper... but when I try to launch apps, I'm getting the white canvas again, which I thought was fixed a while ago. Do you know what's going on there? | 16:16 |
| ogra_ | slangasek, there is a race in the platform-api/qtubuntu code, its known and being worked on, reboot a few times, one boot will have it working | 16:21 |
| slangasek | ok | 16:21 |
| slangasek | so nothing I need to worry about, thanks :) | 16:21 |
| rtg_ | slangasek, I figured out why cross compiling fell out of favor for me. dpkg-buildpackage was what I was using, but the installed package dependency check always failed, whereas debuild must be smarter. | 16:35 |
| slangasek | rtg_: debuild actually uses dpkg-buildpackage under the hood, so I think dpkg itself got smarter :) | 16:36 |
| slangasek | rtg_: you can also always pass '-d' to skip the dependency check if you know it's checking wrong, fwiw | 16:36 |
| rtg_ | slangasek, well, dpkg-buildpackage _still_ fails the dependency check | 16:36 |
| slangasek | hmm! | 16:36 |
| rtg_ | lemme try -d | 16:36 |
| rtg_ | tahts better | 16:37 |
| * ogra_ sees a "export $(dpkg-architecture -aarmhf)" .... in the cross compile instructions ... might be that this is related ? | 16:43 | |
| rtg_ | ogra_, I'm running in a clean saucy amd64 chroot with no environment changes. 'dpkg-buildpackage -d -aarmhf -B' works pretty well (except for tools) | 16:45 |
| ogra_ | ah, i never build tools ... | 16:46 |
| rtg_ | and frankly, I don't care about tools for test builds | 16:46 |
| * ogra_ always only builds binary-$subarch | 16:46 | |
| rtg_ | I _am_ liking this cross compile stuff though. it hauls ass. | 16:47 |
| ogra_ | hehe, yeah | 16:58 |
| rtg_ | ppisati, conf call ? | 17:01 |
| ppisati | yep | 17:01 |
| * rtg_ -> lunch | 17:50 | |
| * apw calls it a day, and goes make a new travel laptop .. sigh | 18:56 | |
| * rtg_ -> EOD | 19:40 | |
| infinity | ppisati: Can you re-do your ti-omap4/Q rebase to match the respin? (bug #1192805) | 20:07 |
| ubot2 | Launchpad bug 1192805 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1192805 | 20:07 |
| === adam_g_ is now known as adam_g | ||
| === hggdh_ is now known as hggdh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!