[07:43] <xnox> does CONFIG_ARCH_RANDOM enable usage of intel rdrand to seed /dev/random ?
[09:47]  * henrix will be out for a bit
[10:20] <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:21] <apw> tseliot, sounds nasty indeed
[10:24] <tseliot> apw: I'm getting this http://paste.ubuntu.com/5783212/
[10:25] <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:26] <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...
[11:48]  * ppisati goes out for a bit...
[12:04]  * henrix -> lunch
[13:27] <rtg_> henrix, rebooting gomeisa for misc updates
[13:27] <henrix> rtg_: ack
[14:01] <apw> henrix, ok ... cve tracker is happy again
[14:02] <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:03] <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:07] <smb> infinity, Did I ask you about looking at crash today?
[14:27] <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:40] <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:47] <rtg_> slangasek, python-dev depends on python (which contains python-config) whereas libpython-dev does _not_ depend on python
[14:48] <slangasek> rtg_: actually, python-config should be in python-dev, *not* in python; that seems to be the case here
[14:49] <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:50] <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:51] <slangasek> rtg_: 'debuild -uc -us -B -aarmhf'
[14:54] <rtg_> slangasek, 'do_tools	= false' for armhf.
[14:55] <rtg_> seems like I should fix that
[14:56] <slangasek> rtg_: ok :)
[15:00] <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:01] <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:02] <slangasek> right :)
[15:23] <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:24] <rtg_> see Documentation/timers/NO_HZ.txt
[15:25] <bjf> looking
[15:27] <bjf> rtg_, as i read that, it doesn't make sense for us to have CONFIG_NO_HZ_FULL=y
[15:28] <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:31] <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:32] <rtg_> bjf, right. its opt-in if  CONFIG_NO_HZ_FULL=n
[15:32] <bjf> ack
[15:33] <rtg_> bjf, so, disabling that config means the feature will get little testing. thats all I'm saying.
[15:34] <bjf> rtg_, agreed
[15:35] <rtg_> bjf, perhaps you should reach out to Fred about this. he might have some ideas
[15:40] <bjf> rtg_, i just don't see that option being viable for a general desktop kernel
[15:41] <rtg_> bjf, it seems like it would be the cat's meow if it worked.
[16:16] <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:21] <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:35] <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:36] <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:37] <rtg_> tahts better
[16:43]  * ogra_ sees a "export $(dpkg-architecture -aarmhf)" .... in the cross compile instructions ... might be that this is related ?
[16:45] <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:46] <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:47] <rtg_> I _am_ liking this cross compile stuff though. it hauls ass. 
[16:58] <ogra_> hehe, yeah
[17:01] <rtg_> ppisati, conf call ?
[17:01] <ppisati> yep
[17:50]  * rtg_ -> lunch
[18:56]  * apw calls it a day, and goes make a new travel laptop .. sigh
[19:40]  * rtg_ -> EOD
[20:07] <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