[07:24] <apw> xnox, grouper with avahi really?
[07:34] <smb> morning .*
[07:39] <apw> smb, moin
[07:48] <smb> apw, Today's S at least lets you change time+date and privacy settings... win. :)
[07:49] <apw> smb, sounds like a big improvement :)
[07:50] <smb> Absolutely. I won't turn mad being in a different tz than my installation is. :-P
[10:05] <RAOF> Does anyone else find their kernel hanging processes in schedule() for minutes at a time?
[10:35] <RAOF> Ah. Probably not, because no one's crazy enough to btrfs.
[13:52]  * henrix_ -> really late lunch
[13:54] <apw> rtg, turns out it is linux-signed skew ... cause i cannot make one of those to match ... arrgle
[13:55] <rtg> apw, hmm, gotta love that. how come there is skew ?
[13:56] <apw> cause i am making a test kernel, and i cannot make a real signed one, ever
[13:56] <rtg> ah, doh! does it work OK with an archive kernel ?
[14:19] <henrix> rtg: bjf: the EFI patchset is now queued for 3.5.y. i'll probably be sending it out for review tomorrow or friday, so early next week i should have a release with them
[14:19] <rtg> henrix, ack
[14:19] <bjf> henrix, ack, sounds good
[14:40] <ppisati> bjf: no more -proposed for SRU kernels, just series name, right? (e.g. precise instead of precise-proposed)
[14:40] <bjf> ppisati, correct
[14:41] <ppisati> bjf: and, did you do any modification to kteam-tools/maintscripts/verify-release-ready?
[14:42] <bjf> ppisati, it should be fixed so that it doesn't require -proposed any longer
[14:42] <ppisati> bjf: but it complains here in another way
[14:42] <ppisati> bjf: http://paste.ubuntu.com/5861831/
[14:44] <bjf> ppisati, seems pretty obvious from that error message what your problem is :-)
[14:44] <ppisati> bjf: "Error: n"? :)
[14:45] <bjf> ppisati, which kernel are you working on ?
[14:45] <ppisati> bjf: i'm rebasing lucid/omap4 on top of lucid/master
[14:46] <bjf> ack
[14:51] <bjf> ppisati, when was the last time you worked on that?
[14:51] <ppisati> bjf: last release
[14:51] <ppisati> bjf: ~two weeks ago
[14:51] <bjf> not lucid
[14:51] <ppisati> bjf: sorry, i meant precise
[14:55] <bjf> ppisati, it "just works" for me
[14:56] <ppisati> bjf: let me try again
[15:35]  * apw has to run and do some family bits in about 5 m ... laters
[15:49] <rtg> ppisati, are you building bootable kernels for armhf with saucy gcc-4.8 ? None of the nexus kernels are being built with gcc-4.8
[15:50] <ppisati> rtg: actually i had problems yesterday with a kernel not booting, but i thought it was my mistake in the .config since i was compiling vanilla
[15:51] <rtg> ppisati, perhaps you should step back to gcc-4.7 ?
[15:51] <ppisati> rtg:  i can give it a try
[16:16] <zequence> apw: reminder about -lowlatency :)
[16:34] <ppisati> rtg: you are right, same kernel src&.config
[16:35] <ppisati> rtg: with 4.7 it boots, with 4.8 it hangs
[16:35] <rtg> ppisati, works with 4.7 ?
[16:35] <rtg> OK
[16:35] <ppisati> rtg: yep
[16:35] <ppisati> rtg: but my 4.7 was armel
[16:35] <ppisati> [    0.000000] Linux version 3.6.11 (flag@luxor) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #21 SMP Wed Jul 10 18:15:43 CEST 2013
[16:36] <ppisati> this is what i have:
[16:36] <ppisati> [flag@luxor linux-2.6]$ dpkg -l | grep gcc-arm-linux-gnueabi
[16:36] <ppisati> ii  gcc-arm-linux-gnueabi                         4:4.7.2-1                                  amd64        The GNU C compiler for armel architecture
[16:36] <ppisati> ii  gcc-arm-linux-gnueabihf                       4:4.8.1-1                                  amd64        The GNU C compiler for armhf architecture
[16:37] <rtg> ppisati, can you build with 4.7 armhf ? do you have the right HW ?
[16:37] <ppisati> rtg: if i can find the toolchain, yes
[16:38] <rtg> I'm pretty sure there is a 4.7 armhf in saucy
[16:38] <ppisati> funny
[16:39] <ppisati> [flag@luxor linux-2.6]$ which arm-linux-gnueabi-gcc
[16:39] <ppisati> /usr/bin/arm-linux-gnueabi-gcc
[16:39] <ppisati> [flag@luxor linux-2.6]$ dpkg -S /usr/bin/arm-linux-gnueabi-gcc
[16:39] <ppisati> gcc-arm-linux-gnueabi: /usr/bin/arm-linux-gnueabi-gcc
[16:39] <ppisati> [flag@luxor linux-2.6]$ arm-linux-gnueabi-gcc -v
[16:39] <ppisati> ...
[16:39] <ppisati> gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
[16:39] <ppisati> 4.7.3 gcc in a 4.7.2-1 gcc-arm-linux-gnueabi package
[16:40] <hallyn> apw: GAH!  middle of a git bisect upstream between 3.7 and 3.8, it suddenly dumped into a 3.1 version.  <rage>
[16:41]  * hallyn looks at git bisect log and tries to restart with last known good+bad
[16:45] <rtg> ppisati, so, does that mean the 4.7 cross compiler is not a hard float compiler ? does it matter for the kernel if its armel or armhf ?
[16:45] <ppisati> rtg: IIRC we are still using armel on mobile
[16:45] <ppisati> ogra_: ^
[16:45] <ogra_> ?
[16:46] <ogra_> the armel builds live in their own universe 
[16:46] <ogra_> (and use a bionic toolchain)
[16:46] <ogra_> i dont think we have any glibc armel cross compiler anymore 
[16:48] <ogra_> (there is gcc-arm-linux-androideabi, but thats not something anyone should use)
[17:06] <BenC> apw, rtg: This config check is failing on powerpc saucy 3.10.0
[17:06] <BenC> check-config: FAIL: (arch armel armhf &/ value CONFIG_GPIO_TWL4030 y) |   value CONFIG_GPIO_TWL4030 m |   !exists CONFIG_GPIO_TWL4030
[17:08] <rtg> BenC, I wonder why ? that option shouldn't even exist for ppc, does it ?
[17:08] <BenC> I've set CONFIG_GPIO_TWL4030=m to get around it, but it appears to be faulty nonetheless
[17:09] <BenC> Setting it to y/n gives the check failure though
[17:09] <rtg> BenC, right. start a bug and assign apw to it. the config checker uses a completely (to me) inscrutable language.
[17:10] <BenC> rtg: It prompts for all four flavours, but I wanted to set it to "is not set"
[17:10] <BenC> config checker is black magic that I fail to comprehend as well
[17:10] <rtg> BenC, you could always just patch that line out of the config checker. its not like it changes that much.
[17:11] <BenC> I'm perfectly happy not having to touch the enforce file, even if it means having a useless module enabled :)
[17:11] <rtg> yeah, it wouldn't ever get insmod'd anyways
[17:11] <xnox> ogra_: i believe we have all three cross-toolchains.
[17:12] <ogra_> xnox, i belive armel was dropped for arm64 
[17:12] <ogra_> (there might be a toolcahin, but i think there is no gcc for it anymore)
[17:12] <xnox> ogra_: right there is no 4.8 armel cross.
[17:14] <xnox> rtg: ppisati: ogra_: i believe that kernels for mobile are compiled natively using armhf toolchain, android userspace is compiled using armel-v5-bionic based toolchain. We have armel/armhf/arm64 4.7 cross compilers in saucy, and 4.8 armhf/arm64
[17:14] <xnox> https://launchpad.net/ubuntu/+source/gcc-4.7-armel-cross
[17:14] <xnox> https://launchpad.net/ubuntu/+source/gcc-4.7-armhf-cross
[17:14] <xnox> https://launchpad.net/ubuntu/+source/gcc-4.7-arm64-cross
[17:15] <xnox> ... and matching for 4.8
[17:15] <xnox> for mobile we are sticking with 4.7 for now, as kernels fail to boot / userspace gets borked with 4.8.
[17:15] <ogra_> yeah
[17:15] <rtg> xnox, the native gcc-4.8 armhf compiler does not produce a bootable kernel for any of the Nexus devices.
[17:16] <xnox> rtg: correct. so 4.7 one is used instead.
[17:16] <rtg> xnox, actually, we use 4.6 on at least one device
[17:16] <xnox>  /o\
[17:16] <xnox> rtg: it's a shame....
[17:17] <rtg> xnox, are we just gonna end up ignoring the fact that 4.8 is broken for this dev cycle ?
[17:18] <xnox> rtg: android open source project / cynogenmod / linaro should first make a toolchain & bring up bootable kernels with gcc-4.8. Until that happens, there is no intension to invest any engineering effort in doing this bring up.
[17:19] <xnox> rtg: linaro is supposedly working on 4.8 bring up, but they are still default to gcc4.7 across the board for "stable" stuff.
[17:19] <rtg> xnox, ppisati has pointed out that we can't use it for the distro kernels either.
[17:19] <rtg> distro armhf kernels*
[17:20] <xnox> rtg: well.... all of our distro armhf kernels are at various stages of decay. Is any one of those flavours at the same major version as amd64/i386 kernels?
[17:21] <rtg> xnox, of course. the omap series, vexpress, and some others. mostly those that use device tree blobs
[17:22] <xnox> rtg: "ignoring the fact that 4.8 is broken for this dev cycle" sounds a bit weird to me. "ignore the fact that old kernels do not support building with gcc-4.8, and target devices are not ported to newer kernels, and instead frozen in-time by their manufacturers"
[17:22] <rtg> damned if I know if they even work, though
[17:22] <xnox> rtg: I guess we should care to build armhf generic most recent kernel for calxeda and friends.
[17:23] <rtg> xnox, exactly. I think calxeda _does_ work, though I'd have to make sure with ppisati first.
[17:23] <xnox> rtg: we have two rigs available and before they go into production, could test kernels on them, I guess.
[17:24] <xnox> rtg: but i think, everyone now knows that it's fact of life that ac100/panda/$(nexus devices) are shipping old kernels and cannot be build with gcc4.8.
[17:25] <ppisati> rtg: correct, 4.7 arm[el|hf] are ok, 4.8 armhf is bad
[17:25] <rtg> xnox, agreed. Then I'm gonna mark ricardo's bugs complaining about gcc-4.8 "won't fix"
[17:25] <ogra_> it needs to be armhf in any case 
[17:25] <ogra_> we dont have an armel archive anymore :)
[17:25] <rtg> ppisati, gcc-4.8 fails even on calxeda ?
[17:26] <ogra_> you would have to do a lot of tricks to actually cheat that into the archive 
[17:26] <ppisati> rtg: didn't test calxeda, omap4 only
[17:26] <ogra_> what do you do with omap4 anyway ?
[17:27] <ogra_> we still use the quantal kernel for it 
[17:27] <ppisati> ogra_: i test toolchain :)
[17:27] <rtg> ppisati, well, I guess it makes no difference if it works or not. it fails on omap, so we have to use an older compiler regardless.
[17:27] <ogra_> and that wont change
[17:27] <ogra_> ah
[17:27] <ppisati> ogra_: btw, [flag@luxor ~]$ arm-linux-gnueabi-gcc -v
[17:27] <ppisati> ogra_: gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
[17:27] <ogra_> yeah, 4.7 
[17:27] <ppisati> [flag@luxor ~]$ dpkg -S arm-linux-gnueabi-gcc
[17:27] <ogra_> we dropped armel from 4.8 for arm64 
[17:27] <ppisati> gcc-arm-linux-gnueabi: /usr/bin/arm-linux-gnueabi-gcc
[17:28] <ppisati> ogra_: so we have bot armel and armhf for 4.7
[17:28] <ogra_> right
[17:28] <ppisati> ogra_: and armhf only with 4.8
[17:28] <ogra_> yeah
[17:28] <xnox> yes.
[17:28] <ppisati> ok so
[17:28] <ppisati> both 4.7 are good
[17:28] <ppisati> 4.8 armhf is bad
[17:28] <xnox> (and arm64 with both 4.7 & 4.8)
[17:28] <xnox> rtg: where is that bug? =)
[17:29] <rtg> xnox, bug #1176255 and #1181046
[17:29] <ubot2`> Launchpad bug 1181046 in linux-manta (Ubuntu) " linux-manta keeps rebooting when built with gcc 4.7 or 4.8" [Undecided,New] https://launchpad.net/bugs/1181046
[17:29] <ubot2`> Launchpad bug 1176255 in linux-mako (Ubuntu) "linux-mako fails to boot when built with gcc 4.8" [High,New] https://launchpad.net/bugs/1176255
[17:30] <rtg> I don't we bothered making a bug for the other platforms
[17:30] <ogra_> hmpf
[17:30] <ogra_> someone could at least have added the ram console dump 
[17:30] <xnox> rtg: mark those bug as affecting project "gcc-linaro" =)
[17:31]  * ogra_ needs to write a wikipage how to debug android boots without serial console 
[17:31] <rtg> I'll create a meta bug, make those other duplicates, and reference all of the relevant packages.
[17:32] <rtg> but first, I'm gonna eat lunch 'cause I'm starving.
[17:32]  * rtg -> lunch
[17:32] <ogra_> a ram console dump is the least bit that should be attached to kernel boot bugs
[17:34] <infinity> ppisati: Building the ARM generic kernel with 4.8 breaks, or do you mean that ti-omap4/3.5.0 breaks?
[17:34] <infinity> ppisati: The latter seems entirely reasonable, the former would be a bug.
[17:35] <ppisati> infinity: buidling a vanilla kernel (3.6 omap2_defconfig in this case) hangs on boot when cross compiled with 4.8 armhf
[17:36] <ppisati> infinity: same src & .config with 4.7 is ok
[17:36] <infinity> ppisati: I don't much care about 3.6, we've moved on to 3.10...
[17:37] <infinity> ppisati: Hence why I asked about the "ARM generic kernel".
[17:37] <ppisati> infinity:  i do care about a toolchain that can't compile a kernel, dunno about you
[17:37] <infinity> Old kernels need old compilers is not a new situation.  And could be cherry-picked to hell to fix, if we're still shipping ancient kernels in an LTS.
[17:37] <infinity> ppisati: Can't compile a kernel we don't ship?  We have no 3.6 omap kernels in the archive, last I checked.
[17:38] <infinity> No toolchain can compile all kernel sources.  The kernel plays pretty fast and loose with GCC misfeatures, and they tend to need to be of a similar vintage to be happy.  This has been true for literally decades.
[17:38] <ppisati> infinity: someone else reported that it can't compile a supported kernel with 4,8, isn't it enough?
[17:39] <xnox> ppisati: no.
[17:39] <infinity> ppisati: If we need to keep 4.6 to compile our crappy old Android kernels, so be it.
[17:39] <infinity> ppisati: If 3.10 compiles and boots fine with 4.8, that sort of proves the bug has been addressed upstream, and if we cared, we could cherrypick the kernel fixes to our Android kernels.
[17:40] <infinity> So, the question is, do we care?
[17:40] <infinity> In almost no way does any of this constitute a GCC bug.
[17:40] <ogra_> no, we dont 
[17:40] <ogra_> (for the android kernels)
[17:40] <infinity> ogra_: doko may disagree. :P
[17:40] <ogra_> then he can ask for it 
[17:40] <ogra_> from a phonedations POV we dont :)
[17:41] <xnox> ppisati: supported means - we will make a package available that will work. supported - doesn't mean we will backport frankenstein changes from recent kernels back to something 6 kernel releases back make it compile with optimized 4.8 toolchain, do benchmarks and conclude that it doesn't gain us anything.
[17:42] <xnox> infinity: doko, had a sad moment that 4.8 didn't work with kernels, and went on to upload 4.7 point release update into saucy.
[17:42] <infinity> Now, it's probably entirely valid that if the only toolchain that can cross these old kernels is 4.6, we might need to reintroduce the 4.6-cross packages.
[17:43] <xnox> infinity: well most work with 4.7 fine, one seems to need 4.6 (the oldest kernel).
[17:45] <infinity> Meh.  Kay, if it's just the one, people can suffer and build that natively.
[17:45] <infinity> I assume that's the platform still stuck on 3.1, for whatever reason.
[17:45] <xnox> infinity: it's not like that kernel will ever change though.... so it has already been build once......
[17:45] <infinity> xnox: You don't watch rtg's uploads, clearly.  He seems to upload Android kernels more often than mainline. :P
[17:45] <xnox> maguro: 3.0.0; grouper: 3.1.10; manta/mako 3.4.0
[17:45] <infinity> (But I suppose once the config syncing and other bits are sorted, he'll stop)
[17:45] <ogra_> infinity, 3.1 ? modern stuff :P
[17:45] <ogra_> maguro (omap4) uses 3.0 
[17:46] <ogra_> root@ubuntu-phablet:/# uname  -r
[17:46] <ogra_> 3.0.0-3-maguro
[17:46] <xnox> infinity: i guess it might make a little sense to poke the 4.6 one and see if can be patched up to use 4.7 (maybe somebody in cynogenmod et al did it already)
[17:46] <infinity> Ironic, given all the years we supported omap4.
[17:46] <ogra_> yeah
[17:46] <ogra_> well, its alll about the binary blobs
[17:49] <xnox> ogra_: by the way, I solved my fetching sources problem with: chdist + python-apt magic
[17:49] <ogra_> haha
[17:49] <ogra_> hacks FTW :)
[17:49] <ogra_> nice one though 
[17:50] <xnox> ogra_: it's slightly better than PULL_LP_BIN 
[17:50]  * ogra_ hopes nobody ever looks deeply into ubuntu-touch-initrd-generic 
[17:50] <ogra_> it does funny things too 
[17:50] <xnox> ogra_: cause, my hacks should work on the distro builder as well.
[18:00] <xnox> infinity: one can always compile those kernel in the last release that had gcc-4.6-cross and then copy up.....
[18:00]  * xnox hides
[18:33] <hallyn> apw: I plead for help.  http://paste.ubuntu.com/5862473/   
[18:34] <hallyn> does the fact that it was testing a merge point confuse git-bisect afterward?
[18:34] <hallyn> (I tested that on tangerine as well as my precise builder, so it's not just the git version)
[18:35] <rtg> hallyn, you can't bisect across a non-linear space. 
[18:36] <rtg> at least, not very easily
[18:36] <hallyn> I thought Linus' tree was supposed to always be bisectable
[18:36] <rtg> hallyn, Linus's tree is, but not Ubuntu
[18:36] <hallyn> ok - I'll take a different approach.
[18:36] <hallyn> this is on Linus' tree
[18:37] <rtg> hallyn, what is HEAD in your example ?
[18:37] <hallyn> at which point?
[18:37] <hallyn> right nwo it is c5482bbd9607bf38cbc952eacaa429e6ba3160a0
[18:37] <rtg> the starting value for 'git bisect start'
[18:38] <hallyn> rtg: that shouldn't matter right?  it's been different, but with the same result - it takes the git bisect good and bad values to start with
[18:38] <rtg> I guess it makes no difference really.
[18:38] <rtg> right
[18:38] <hallyn> all right - was hoping there was some magic pixie dust i didn't knwo about to fix it.  i guess i'll just focus on changes to kernel/{exit,signal}.c, which are few
[18:39] <hallyn> I've got my eye on af4b8a83add95ef40716401395b44a1b579965f4 pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed
[18:43] <rtg> hallyn, maybe its because those SHA1 IDs are merge commits
[18:45] <hallyn> rtg: I just would expect git bisect to DTRT...  (maybe it *did* do the right thing, but that's not how I see it)
[18:45] <rtg> hallyn, sometimes git still surprises me
[18:45] <hallyn> s/surprises/disappoints/ in this case :)
[18:46] <hallyn> rtg: thanks.  i'll track it down by hand - ttyl
[19:25] <hallyn> i was right, that's the bad commit.  
[19:25] <hallyn> apw: ^ the signal weirdness was introduced there (af4b8a83add95ef40716401395b44a1b579965f4 pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed)
[19:26] <hallyn> just fyi, since i KNOW you're losing sleep over it :)
[19:26] <FernandoMiguel> apw: Sarvatt: FYI been running 3.10 with intel_pstate=disable, so far no major problem detected and heat, cpu management , battery back to previous values
[19:26] <FernandoMiguel> thanks
[19:30] <Sarvatt> FernandoMiguel: I've been running a kernel using intel_pstate with the changes on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/comments/6 and not having any problems -- http://kernel.ubuntu.com/~sarvatt/intel_pstate/
[19:30] <ubot2`> Ubuntu bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix committed]
[19:30] <Sarvatt> but i haven't been tracking battery usage, just heat
[19:43] <hallyn> ah, maybe i see the problem
[19:57]  * rtg -> EOD
[22:08]  * cooloney waves at apw ogasawara smb bjf vanhoof
[22:11] <vanhoof> hi cooloney 
[22:11] <vanhoof> cooloney: bu yao! :)
[22:17] <cooloney> vanhoof: how's going? you're a busy man!
[22:19] <vanhoof> cooloney: not too bad, busy as always :) ... how about you?
[22:19] <cooloney> vanhoof: very good. i'm working on V4L2 camera stuff on Tegra.
[22:20] <cooloney> vanhoof: hope to meet you guys somewhere
[22:21] <vanhoof> cooloney: I'll be in the bay area later this month I think
[22:21] <vanhoof> cooloney: come pick me up from sfo :)
[22:21] <cooloney> cool, let's hangout.
[22:22] <vanhoof> +1
[22:22] <cooloney> sure, i will drive my lamborghini
[22:24] <vanhoof> cooloney: gucci leather?
[22:26] <manjo> cooloney, does the camera work ? 
[22:29] <manjo> cooloney, I hear Lamborghini's don't have AC ... 
[22:29] <cooloney> oh, manjo, you are always ask the key question
[22:29] <ohsix> they do
[22:30] <cooloney> vanhoof and manjo, you know, I mean there is a bus from SFO named Lamborghini, not that one you guys expect
[22:30] <manjo> lol
[22:30] <vanhoof> cooloney: don't toy with my emotions :)
[22:30] <manjo> why drive a 250k car when you can ride in a 1/2 mil bus
[22:31] <manjo> cooloney, now I see the logic in your v4l camera device 
[22:32] <cooloney> also I have bike named Maserati, if you guys wanna ride
[22:32] <manjo> motor or foot powered ? 
[22:32] <vanhoof> cooloney: with pedals?
[22:32] <vanhoof> :)
[22:32] <manjo> does it go ding ding ? 
[22:34] <cooloney> oh, one pedal works and the other not 
[22:36] <cooloney> manjo: it always goes dingding except the bell.
[22:36] <manjo> cooloney, you are always full of surprises !  
[22:37] <cooloney> manjo: will you come with vanhoof this time?
[22:37] <manjo> vanhoof, am I going with you to CA ?
[22:38] <manjo> cooloney, peons don't get to go I think ... 
[22:41] <manjo> cooloney, are you going to plumbers in NO this sept ? 
[22:52] <cooloney> manjo: probably not. if it is in bay area, i might go.