[00:35] <lilstevie> marvin24, if you mean the blank console issue where you get no kmesg with fbcon enabled, no, it only affected us for 2.6.39, at least on the tf201, there isn't a good solid properly ported tf101 3.1 kernel yet to comment on, so it could possibly be a tegra2 bug
[02:20] <robclark> btw, anyone tried kde / kwin_gles?  It seems like /usr/lib/kde4/kcm_kwincompositing.so is linked against libGL.so instead of gles (this is w/ kde-window-manager-gles)
[03:07] <infinity> robclark: Patches welcome. ;)
[03:07] <infinity> robclark: The whole QT/GLES thing is a royal pain to mangle.
[03:24] <robclark> infinity, ok.. I was just chasing up a bug reported on pandaboard list from someone who had somehow enabled desktop fx... so was wondering if I had missed installing something..
[03:26] <infinity> robclark: To be fair, I have no idea what does and doesn't work, I try out KDE so very infrequently.
[03:27] <infinity> robclark: All I know is that the GL/GLES abuse between ARM and $everything_else makes all things QT and KDE a porting nightmare. ;)
[05:54] <janimo> ogra_, I tried the ac100 installer with a local kernel that has the NLS pieces built in. It goes on but it does not write the config boot image and boots into the initial one. There are errors saying init: abootimg not found
[06:18] <infinity> janimo: Which sounds a whole lot like abootimg isn't installed. :P
[06:44] <scientes> why arn't you guys running precise kernels on your buildds?
[06:46] <janimo> infinity, right, but I am not sure anything should have changed in the initrd generation, hence calling ogra :)
[06:46] <infinity> scientes: Because they're not all precise.  Did a build blow up due to kernel version?  Point me at it, and I can fix it.
[06:48] <infinity> scientes: The plan is to upgrade them all to precise/armhf over the next week or two, but it's a reinstall (since they were previously natty/armel), so a bit irksome.
[06:49] <scientes> infinity, well actually i did my research, and my package would need 3.4 to build with its current settings, i downgraded a try-execute test to a link-test, and never realized that gcc-4.7 has support for 8-byte atomics on arm
[06:49] <janimo> infinity, ABI bump needed for kernel modules/built-in changes or just strictly for actual changes in the signatures, data structs?
[06:49] <infinity> scientes: 3.4? Eh?
[06:50] <scientes> so the setting is incorrect, and next upload will hard code turning it off on armel
[06:50] <infinity> scientes: The atomic helpers in the kernel are in 3.1
[06:50] <janimo> I see skipabicheck and skipmodulecheck as different toggles, so I think that may be the case
[06:50] <scientes> <armv6k added kernel 64-bit atomic support in 3.4
[06:50] <infinity> scientes: Trust me.  Which package is this?
[06:50] <scientes> oh really
[06:50] <infinity> scientes: No, really.  Trust me. :P
[06:50] <scientes> i just used git describe
[06:50] <infinity> scientes: It'll build on sigbin.
[06:50] <scientes> ok kyotocabinet
[06:51] <infinity> Yeahp, that will build fine on sigbin.  I'll toss it there now.
[06:53] <infinity> janimo: Hrm?  abicheck is all about exported interfaces.  If a module is built-in, it wrong trigger it.
[06:53] <infinity> janimo: Of course, modulecheck will blow up if you're moving modules around from built-in to not (was that the question?), and yes, that should be an ABI bump.
[06:54] <infinity> janimo: Enabling something that wasn't previously on at all, however, would not be an ABI bump.
[06:54] <infinity> janimo: (unless it changes something else)
[06:54] <janimo> infinity, ok. Just did not know whether ABI change is a superset of drivers moving drom built-in to modules or vice-versa change
[06:54] <janimo> this is actually from modules to built-in
[06:54] <janimo> NLS modules for the installer to be happy
[06:55] <infinity> janimo: Strictly speaking, "ABI" was originally meant to just represent the module ABI, so ignored the modules themselves, but we now use it as a superset to also deliver guarantees of availability.
[06:55] <infinity> So, if a module disappears (or moves between image and modular), that's a break.
[06:55] <infinity> If one's added, that's perfectly fine.
[06:56] <infinity> And I think I'm being repetitive now, so I'll shut up. ;)
[06:56] <infinity> janimo: If in doubt, rev ABI.  It doesn't really hurt anything to be wrong in that direction.
[07:24] <janimo> infinity, the only thing it hurts is new binaries and meta needed
[07:41] <marvin24> janimo: pci-e is not used on ac100, I think I activated it sometime to shut down something (clock or pinmux), but I haven't measured power consumption yet
[07:41] <marvin24> lilstevie: I mean kernel oops with plymouth (not no splash)
[07:47] <roric> Hi all
[07:47] <roric> I just tried to install 12.04 on a pandaboard, did a dist-upgrade
[07:47] <roric> then tried to install the pvr driver via jockey
[07:48] <roric> it fails... it did a while back when I tried too
[07:48] <roric> any known workaround?
[08:35] <ogra_> janimo, ah, yeah, thats just a missing chroot call, abootimg isnt in the initrd, i changed the bootconfig handling to match with flash-kernel 3.0 but forgot that i need to call abootimg chrooted from the target partition
[08:36] <ogra_> i'm just preparing ext2 media here to do a test install
[08:52] <ogra_> janimo, fix uploaded
[09:12]  * ogra_ has oem-config :)
[09:14] <pershoot> hi guys.  have you all come across this: Couldn't open /sys/bus/nvhost/devices/host1x/syncpt/22/max  ?  is there a set of patch(es) which adds this interface in?
[11:08] <ogra_> grmbl
[11:09] <ogra_> flash-kernel always exits "1" on the ac100, no wonder it doesnt work
[11:20] <lilstevie> marvin24: the plymouth oops that locks up the whole system affects us too
[11:23] <ogra_> yay, fixed
[11:24] <ogra_> janimo, the next ac100 image shold be fully installable now (from ext2/3/4 media though)
[11:24] <ogra_> silly bug in flash-kernel
[11:25] <janimo> ogra_, great
[12:05] <marvin24> lilstevie: are you able to dump the oops?
[12:07] <marvin24> if not, does it look like this one http://paste.ubuntu.com/1095134/ ?
[12:11] <ogra_> marvin24, bug 1018907
[12:11] <ubot2> Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [High,Confirmed] https://launchpad.net/bugs/1018907
[12:11] <ogra_> try the rm /lib/plymouth/renderers/drm.so workaround
[12:12] <marvin24> ogra_: that's different I think
[12:12] <ogra_> well, it makes plymouth by default talk to the kernel sdrm interface
[12:12] <ogra_> *kernels drm
[12:12] <marvin24> you mean this could cause an oops?
[12:12] <ogra_> well, it would be a kernel bug, but yeah
[12:13] <marvin24> I'll test it later on but i doubt that's the reason
[12:13] <ogra_> i.e. on omap4 we have a drm device thats not connected to anything, there the plyouth output just gets /dev/null'ed
[12:14] <ogra_> who knows whats there on nvidia ... very likely no drm device :)
[12:14] <marvin24> tegra2 has no drm compiled into the kernel I think
[12:20] <janimo> ogra_, is that issue fixed in ac100 by blacklisting something?
[12:34] <lilstevie> marvin24, it does not look like that it just blacks out
[12:40] <ogra_> janimo, nope
[12:40] <ogra_> lilstevie, you should too try the workarouond from the bug above
[12:49] <lilstevie> ogra_, ok I will get to it eventually
[12:50] <ogra_> hmm, having the desktop defaulting to suspend on lid close but having the kernel break on suspend isnt really a great combo
[12:53]  * ogra_ tries the nvidia driver from the archive with todays image
[12:56] <lilstevie> haha
[12:56] <lilstevie> I wish my lid close sensor was working correctly
[12:58] <ogra_> BAH !
[12:59] <ogra_> "module ABI major version (11) doesn't match the server's version"
[12:59] <ogra_> GRMBL
[12:59] <ogra_> there are days where i hate progress
[13:02]  * LetoThe2nd hands ogra_ some i286 box.
[13:02] <lilstevie> heh
[13:02] <ogra_> *g*
[13:02] <ogra_> k, fixed
=== zyga is now known as zyga-afk
=== zyga-afk is now known as zyga
[15:33] <janimo> infinity, when adding a new package to a released series, what source does one file the SRU bug against?
[15:33] <janimo> trying to get in new packages into 12.04
[15:35]  * ogra_ would just file against the ubuntu product
[15:35] <ogra_> after all the ubuntu-sru team works by subscription. so the package name shouldnt matter a lot
[15:39] <janimo> ogra_, ok thanks
[16:25] <janimo> sigh, forgot to touch modules.ignore (or was it ignore.modules) now ac100 kernel FTBFS :(
[16:25] <janimo> I . HATE. PACKAGING
[16:25] <janimo> double hate kernel packaging
[16:26] <scientes> janimo, it wouldn't be such a pain if it didn't take so long to build
[16:27] <janimo> I actually mind the time it takes of my life not of the build machines :)
[16:27] <janimo> that is why I am sloppier about it than I would if we had some big timesharing server where we'd get limited cycles
[16:28] <scientes> but if feedback of mistakes was faster you would learn better
[16:28] <janimo> a conceptually simple change described in English as 'make NLS codepage 437 built in instead of module' which could be even terser in a special purpose language is a long series of error prone steps
[16:29] <janimo> scientes, it is not about learning. It is stuff I more or less know but practice not frequently enough to have it on autopilot :)
[16:38] <janimo> scientes, and it does not take that much when cross-building btw. On my fr from top of the line machine it is at most 20 min
[16:38] <janimo> s/fr/far/
[16:38] <scientes> janimo, except that when compiling on buildds you ARNT cross-compiling
[16:39] <janimo> not long enough to be prohibitive, but long enough for my attention-span to go out the window a few times in that interval
[16:39] <scientes> wow, i though a gcc compile was going to take forever, but not on a octo-core xeon ;)
[16:39] <janimo> scientes, most bugs I can catch cross-building I just did not cross-build the 3rd time today
[16:39] <janimo> forgot that crappy modules thing
[17:02] <infinity> janimo: Err, a new source that isn't in quantal?
[17:03] <jhobbs>  /wg 10
[17:03] <janimo> infinity, good point, completely forgot that requirement, as this was OEM/HWE driver for 12.04.1 images
[17:04] <janimo> I could upload to quantal now, with only a changelog bump right?
[17:05] <infinity> janimo: You could do, yes.  We'd definitely prefer to see the source NEWed to quantal first, then backported to precise.
[17:07] <janimo> infinity, shall I add a new changelog entry making it ubuntu2 - quantal and upload or something different? Not sure what a backport to precise should look changelog wise
[17:08] <infinity> janimo: Would make more sense for ubuntu1 to go to quantal, and ubuntu0.12.04 (or similar) to precise.
[17:09] <janimo> ah. ok. Please discard the 3 cedarview packages in NEW then
[17:09] <infinity> Done.
=== shadeslayer_ is now known as evilshadeslayer
[17:13] <janimo> infinity, actually these depend on kernel patches too which intel only provided for 3.2.0. tseliot reminded me, I completely forgot about before
[17:15] <infinity> janimo: Oh, you mean it literally can't be in quantal?  Fun.
[17:15] <janimo> infinity, yes, but I overlooked that.
[17:15] <janimo> maybe with a forward ported kernel patch but not at the moment
[17:15] <infinity> janimo: I'd still upload to precise as if it were a backport (so, with a "backporty" version number), but yeah, guess we'll have to NEW it into precise at some point.
[17:16] <janimo> is there any way of undoing the purge or do we need a new upload :D ? These need upgrade path from existing PPA version numbers so 12.04 may not work. Could you join #hwe ?
[17:17] <janimo> otherwise I keep proxying between you and the other cedarview packagers and I may add noise :)
[17:18] <janimo> infinity, so since I got confirmation that these won't work in quantal could you remove the vaapi upload to quantal of 5 min ago? thanks :)
[17:20] <infinity> janimo: Rejected from quantal.
[19:03] <janimo> marvin24, do nvidia take patches to their 3.1 tree? looks like quite a few of your paz00 patches could live there, the mach is in their tree already
[19:04] <janimo> I just out of curiosity rebased our current ac100 tree on nvidia's l4t/15. seems there are about 120 patches over it in your tree if I count correctly, and about 60 more Ubuntu packaging commits
[19:36] <marvin24> janimo: sure, I already forward some to them
[19:37] <marvin24> what patches do you refer to?
[19:37] <marvin24> ah, you mean to add full paz00 support to it?
[19:38] <marvin24> not a good idea ...
[19:38] <marvin24> the tree is only short living and who wants to take care of it?
[19:38] <marvin24> on the other hand, bugfixes are welcome I guess
[19:39] <marvin24> I already have enough stress to keep mainline up to date
=== zyga is now known as zyga-afk
[20:24] <janimo> marvin24, well yes full paz00 that you carry now which does not affect other machs and some of it is already in nvidia's tree. But you know better :)
[20:26] <marvin24> janimo: yes, not worth the effort IMHO
[20:27] <marvin24> btw, removing the plymouth drm.o think didn't fixed the console problem
=== calculu5 is now known as calculus
=== mythos is now known as brony
=== brony is now known as mythos
=== ndec is now known as ndec|away
[23:08] <cvanvliet_> the armhf SGX Ti binaries are available now?
[23:10] <cvanvliet_> for omap3
[23:17] <scientes> cvanvliet_, only the kernel is differn't between devices
[23:26] <cvanvliet_> scientes, the omap3 Ti SGX armhf binaries have not been available, and I just saw someone using them, and I was just following this up