[14:27] <ogra_> infinity, help !
[15:20] <infinity> ogra_: ?
[15:20] <ogra_> infinity, i have a linker issue and wasted my whole day on it already :(
[15:21]  * ogra_ is super frustrated 
[15:21] <ppisati> squashfs?
[15:21] <ogra_> nah
[15:21] <ogra_> tegra driver
[15:21] <ppisati> quantal-server-armhf+omap.squashfs
[15:21] <ppisati> i just noticed it
[15:21] <ogra_> 10 min update ... 6h hunting  the linker
[15:21] <ppisati> i feel sorry for you :)
[15:22] <ogra_> infinity, so libGLESv2.so isnt versioned ... the package installes it to /usr/lib/nvidia-tegra and sets an ld.so.conf.d option ot use that path
[15:22] <ogra_> during package build i create a proper symlink libGLESv2.so.2
[15:23] <ndec_> ogra_: well... you should just ditch your tegra...
[15:23] <ogra_> using ldconfig in quantal i get libGLESv2.so -> libGLESv2.so.2
[15:23] <ppisati> ndec_: besides, any news on the omap5 panda side?
[15:24] <ogra_> now running es2_info i get a lib not found error
[15:24] <infinity> ogra_: If it's not versioned, I'm not sure what you think the symlink will accomplish.
[15:24] <infinity> ogra_: If the ELF header doesn't have the versioned SONAME in it, you're fighting a losing battle there.
[15:24] <ogra_> infinity, if i set LD_LIBRARY_PATH it works, if i copy the whole set of libs to /usr/lib or /lib ir works too
[15:24] <ndec_> ppisati: any news?
[15:25] <ogra_> and it worked with the same packaging in precise
[15:25] <ndec_> it's coming soon.
[15:25] <ogra_> infinity, so why do /usr/lib and /lib as well as setting the var just work then ?
[15:25] <ogra_> (and why did it just work in precise as is)
[15:27] <infinity> ogra_: Dunno.  Don't we use update-alternatives for GL/GLES in all the other packages?
[15:27] <ogra_> i could make the package just install to /usr/lib indeed but i would like to know why that works if a subdir doesnt
[15:27] <ogra_> infinity, we do ... doesnt help if ldconfig is so stict though
[15:27] <infinity> ogra_: And I can't say for sure why yours doesn't work without seeing the package.
[15:27] <ogra_> apt-get source nvidia-tegra
[15:27] <infinity> (ldconfig hasn't changed at all since precise, so you're barking up the wrong blame tree there)
[15:28] <ogra_> is there any way to get something readable out of objdump so that i can check what ldconfig actually sees ?
[15:29] <alex-ac100> Hello All
[15:29] <alex-ac100> janimo: Are you available&
[15:29] <alex-ac100> ?
[15:29] <janimo> alex-ac100, yes
[15:30] <janimo> alex-ac100, I was just told by fly-away about the issue
[15:30] <alex-ac100> Sorry for bother you, but just would like to let you know that last linux-meta-ac100 build is not correct
[15:31] <alex-ac100> Ah OK, no issues
[15:32] <alex-ac100> janimo: I was not awaire that have to talk with you on THIS channel, looking for you on #ac100 since yesterday evening
[15:32] <janimo> ogra_, if you run ldd /usr/bin/es2_info do you get the paths that should be found?
[15:33] <janimo> alex-ac100, best use the mailing list I guess. I am not on #ac100. I mostly do a kernel update from time to time since noone else does it, but do not use the ac100 otherwise
[15:33] <ogra_> janimo, yes, and ?
[15:34] <janimo> ogra_, are the libGLES ones missing?
[15:34] <ogra_> janimo, its not about the app, its about the lib
[15:34] <ogra_> the app asks ld and gets the wrong info ... unless the lib lives in /lib, /usr/lib or i gave the proper path with LD_LIBRARY_PATH
[15:35] <janimo> alex-ac100, ah wait the meta build? fly-away told me about NV_SOMETHING option needing turned off or hw accel does not work
[15:35] <janimo> is this a different issue?
[15:35] <ogra_> in these three cases it works fine
[15:35] <janimo> ogra_, is the rel16 tarball putting the files in the same place as rel15?
[15:35] <ogra_> yes
[15:36] <ogra_> its exactly identical, just other binaries and a few changes to udev rules and the xorg.conf snippet
[15:36] <infinity> ogra_: What do you mean "not about the app, it's about the lib"?  What does "ldd /usr/bin/es2_info" say?
[15:37] <alex-ac100> janimo: looks like in kernel from linux-metaac100 has CONFIG_TEGRA_NVAVP=y in config. This is totally wrong, as this is for Tegra3 only, while ac100 is Tegra2 based
[15:37] <janimo> ogra_, I know the order of the lines ld.so scripts created/appended to by the postint mattered
[15:37] <janimo> I know I hated those parts of the package too
[15:37] <janimo> but I hoped they should all work from now on if we do not touch them anymore
[15:38] <alex-ac100> janimo: For this reason video playback is broken with this kernel build
[15:38] <rsalveti> ogra_: do you know if the libs are providing a valid SONAME?
[15:38] <janimo> alex-ac100, right. So you mean the new kernel package not the meta?
[15:38] <janimo> the latter just says which is the actual kernel image deb and does not have any config settings
[15:38] <ogra_> rsalveti, how do i find out ?
[15:39] <alex-ac100> janimo: I mean this one https://lists.ubuntu.com/archives/quantal-changes/2012-September/010128.html
[15:39] <ogra_> rsalveti, i definitely see the wrong name being used in ldconfig
[15:39] <ogra_> rsalveti, but that didnt change vs precise ... thats my issue
[15:39] <rsalveti> ogra_: objdump -x lib | grep SONAME
[15:39] <janimo> alex-ac100, ok, the config issue. I was just confused by you mentioning meta (the namings are confusing for newcomers too so no problem)
[15:39] <ogra_> the lib is the same way broken as in the former version
[15:40] <rsalveti> ogra_: were you using update alternatives at the previous version?
[15:40] <ogra_> yes
[15:40] <ogra_> its the same package, i only replaced the binary blobs
[15:40] <alex-ac100> janimo: Sorry, I'm not familar with terminology, so my mistake
[15:40] <janimo> alex-ac100, yes, no prob, as I said confusing package names :)
[15:41] <rsalveti> ogra_: by default the gl applications will look for the .so.xx libs, but I suppose you already got the links in place, right?
[15:41] <ogra_> rsalveti, yep
[15:41] <rsalveti> just because I saw a few gles libs just providing the .so one in the past
[15:41] <rsalveti> and that caused run time issues
[15:41] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ objdump -x usr/lib/libGLESv2.so |grep SONAME
[15:41] <ogra_>   SONAME               libGLESv2.so
[15:41] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0
[15:42] <rsalveti> the problem with the lack of sonames is more if you decide to build something with it
[15:42] <rsalveti> yup, no version there
[15:42] <ogra_> wait
[15:42] <ogra_> gets better
[15:42] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ objdump -x usr/lib/libGLESv2.so |grep SONAME
[15:42] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$
[15:42] <infinity> The lack of proper SOVER will confuse the crap out of ld.so
[15:42] <rsalveti> infinity: even at runtime?
[15:42] <ogra_> so apparently ld works fine if there is no SONAME at all
[15:43] <infinity> rsalveti: Yes, cause ld won't map the symbols correctly.
[15:43] <rsalveti> hm, it might be the case that having SONAME but without version might be causing issues there
[15:43] <ogra_> ye, it does
[15:43] <ogra_> but why is just the link used if there is no SONAME ?
[15:44] <ogra_> the lib lives in the same taret place in both packages
[15:44] <ogra_> *target
[15:44] <ogra_> with the same linakge
[15:44] <rsalveti> infinity: could be, but I believe it'd probably work in this case
[15:44] <ogra_> *linkage
[15:44] <rsalveti> the libs are supposed to be fully compatible :-)
[15:45] <infinity> ogra_: ldconfig sets up links based on SOVER.
[15:45] <ogra_> also why does it work in  /usr/lib ?
[15:45] <infinity> ogra_: Working in /usr/lib is probably a red herring, but let me look at this in a bit.
[15:46] <rsalveti> ogra_: at the pvr-omap4 one I also had to remove the rpath from the libs
[15:46] <rsalveti> to get it to work properly
[15:46] <infinity> Oh, if it has an RPATH, that would explain the /usr/lib thing.
[15:46] <ogra_> well, i think i would break the license if i touched the binary
[15:47] <rsalveti> ogra_: can you list the rpath available at your library?
[15:47] <rsalveti> not necessarily
[15:48] <infinity> ogra_: chrpath -l lib.so
[15:48] <rsalveti> I think at the pvr-omap4 case it had /usr/lib in it
[15:49] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so
[15:49] <ogra_> `usr/lib/libGLESv2.so' probably isn't a 64-bit LSB-first ELF file.
[15:49] <ogra_> elf_open: Exec format error
[15:49] <infinity> (And yes, that probably violates the letter of the license to change/remove the rpath but, hey, I used to hex edit GL libraries in linux-restricted-modules) :P
[15:49] <ogra_> GRRR
[15:49] <ogra_> one sec
[15:49] <janimo> alex-ac100, btw are you sure this is for tegra3 only? The kernel  config system should not allow it to be set in that case
[15:50] <rsalveti> ogra_: please try 'find usr/lib -maxdepth 1 -iname "*.so*" -type f -exec chrpath -d {} +'
[15:50] <rsalveti> and see if it works better
[15:50] <rsalveti> infinity: well, we're just removing stuff from the library :P
[15:50] <rsalveti> not adding anything hehe
[15:50] <ogra_> ogra@sabre:~/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so
[15:50] <ogra_> usr/lib/libGLESv2.so: no rpath or runpath tag found.
[15:51] <rsalveti> ogra_: for all libs?
[15:51] <rsalveti> check the libEGL one
[15:52] <infinity> rsalveti: Removing things is still altering them (but yes, I don't much care either, and back when I used to hex edit the bejesus out of nvidia and ATI's libGL, both upstreams told me they didn't care)
[15:52] <infinity> That said, the nvidia upstream for the x86 drivers is a completely different group than for the ARM ones.
[15:52] <infinity> For reasons I'll never understand.
[15:53] <ogra_> rsalveti, yes, for all libs
[15:53] <rsalveti> infinity: hehe, true
[15:53] <ogra_> so now the 1mio $ question ... is there a way ro wipe the SONAME ?
[15:53] <ogra_> *to
[15:54] <rsalveti> the interesting thing is that it's working on the /usr/lib and /lib paths
[15:54] <ogra_> right
[15:54] <alex-ac100> janimo: well  not 100%, but when this nvavp option is activated, kernel tried to looad some firmware file
[15:54] <alex-ac100> load
[15:54] <rsalveti> ogra_: I think there might be a way to wipe it out
[15:54] <janimo> alex-ac100, then maybe we just need to package that firmware file too?
[15:54] <lilstevie> it should be fwiw
[15:54] <alex-ac100> This firmware is not include in R16 package
[15:55] <janimo> alex-ac100, at least this does not sound scary from the description:
[15:55] <janimo> http://paste.ubuntu.com/1254125/
[15:55] <alex-ac100> janimo: and this firmware in not necessary
[15:55] <ogra_> alex-ac100, that will likely be in the codecs package
[15:55] <janimo> ogra_, should we package those too?
[15:55] <rsalveti> ogra_: what is the issue specifically, you're not able to find it at runtime?
[15:55] <ogra_> janimo, i would like to :)
[15:55] <janimo> put them in linux-firmware?
[15:55] <rsalveti> ogra_: even when forcing the ld path?
[15:55] <ogra_> rsalveti, right
[15:56] <alex-ac100> janimo: ogra_ no, I tested with some custome kernel build without this config settings
[15:56] <ogra_> as said above it works with LD:LIBRARY_PATH (which likely just overrides ld here and uses the links)
[15:56] <alex-ac100> Hardware Video playback worked fine on that build
[15:56] <ogra_> k
[15:56] <alex-ac100> WITHOUT that file
[15:57] <alex-ac100> Also one guy tried to provide such firmware file, it was included in some nvidia codec pack, not sure which platform. System hanged after loadin it
[15:58] <alex-ac100> loading
[15:59] <stuw> janimo, marvin removed nvavp from paz00_defconfig (https://gitorious.org/~marvin24/ac100/marvin24s-kernel/commit/925a5b3d7ab784fc50b4d1edc4a78fa064e7eb0e). nvavp doesn't work for us (checked on android and linux).
[15:59] <janimo> stuw, ok I will remove it from the next upload
[16:00] <stuw> janimo, thx
[16:00] <infinity> ogra_: I'm stuck tethering this morning, but I'm downloading things as fast as I can to have a quick poke around. :P
[16:00] <ogra_> infinity, i'll push the r16 package somewhere too for comparison
[16:01] <infinity> ogra_: Oh, yes, please do.
[16:01]  * ogra_ wants a chsoname tool :P
[16:02] <infinity> That may not be the issue.  Especially if, as you claim, it works with different paths.
[16:02] <infinity> But I want to look at it all first.
[16:02] <infinity> (Well, it may not be the only issue... It *is* an issue that the library has a broken SONAME, but...)
[16:02] <ogra_> well, the former oversion doesnt have a SONAME at all and works :)
[16:03] <rsalveti> ogra_: did you try running with LD_DEBUG to see if that would help?
[16:03] <ogra_> ah, no, not yet
[16:04] <ogra_> what should i run that way ? ldconfig or es2_info
[16:04] <rsalveti> es2_info
[16:04] <ogra_> k
[16:05] <rsalveti> LD_DEBUG=files
[16:05] <rsalveti> LD_DEBUG=init
[16:05] <rsalveti> and others as well
[16:06] <infinity> I still kinda want to know what the output of ldd is/was.
[16:07] <infinity> But meh.  Give me packages, and I can debug myself.
[16:07] <ogra_> infinity, http://people.canonical.com/~ogra/tegra/nvidia-graphics-drivers-tegra*
[16:08] <ogra_> so with ÖD_LIBRARY_PATH set i see direct_opencount=1 for libGLES
[16:08] <ogra_> without the var set it properly tells me it cant find the lib
[16:08] <infinity> Can't find the lib is a bit odd, since mesa installs one.
[16:08] <infinity> So, something's gone horribly wrong.
[16:09] <infinity> Also, installing the 15.1.0-0ubuntu1 version in my chroot just failed...
[16:09] <ogra_> err, no, we have overriden the mesa install path from ld with an alternative
[16:10] <infinity> update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory
[16:10] <infinity> update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory
[16:10] <infinity> Brilliant.
[16:10] <infinity> Also, double-paste.  Bleh.
[16:10] <ogra_>  http://paste.ubuntu.com/1254162/ http://paste.ubuntu.com/1254166/
[16:10] <ogra_> first is without, second with LD_LIBRARY_PATH set
[16:11] <ogra_> (ldd output)
[16:11] <infinity> ogra_: So, uhm.  This package is missing a dependency...
[16:11] <ogra_> infinity, werid, no idea wheer that comes from
[16:11] <ogra_> oh ?
[16:12] <infinity> ogra_: Likely on xorg-video-abi-13.
[16:12] <ogra_> the r16 package has it
[16:12] <ogra_> 15 didnt, right
[16:12] <infinity> Ahh, kay.  So, fixed in future. :P
[16:12] <ogra_> yeah :)
[16:12] <infinity> Let me install an xserver and try again.
[16:12] <ogra_> precise didnt complain about that ...
[16:12] <ogra_> (lintian didnt)
[16:13] <ogra_> iirc now it does
[16:13] <infinity> No, but installing in a bare chroot sure complains.
[16:13] <infinity> (See above)
[16:13] <ogra_> yeah
[16:14] <infinity> Oh, still broken.
[16:14] <infinity> Your package should probably also ship the /usr/lib/xorg/modules/drivers/ directory...
[16:15] <infinity> Otherwise, the postinst only works if one has other X drivers installed. :P
[16:15] <infinity> Which is a bit silly.
[16:15] <ogra_> btw http://paste.ubuntu.com/1254177/
[16:16] <ogra_> ldd with the lib in /usr/lib
[16:16] <ogra_> infinity, hmm, the tarball does, weird i thought the package would just use that ... i'll add it to .dirs
[16:17] <infinity> ogra_: Also, while I'm nitpicking, arm-linux-gnueabi_EGL.conf should be gnueabihf_EGL
[16:17] <ogra_> infinity, r16 ;)
[16:17] <ogra_> already fixed
[16:17] <infinity> That could be where your problem lies.
[16:17] <ogra_> no, i'm installin on a virgin ac100
[16:18] <infinity> Since eabihf_EGL is an alternative shared by mesa.
[16:18] <infinity> The other one wasn't.
[16:18] <ogra_> eabi_EGL was until precise
[16:18] <ogra_> but only on armel :)
[16:18] <ogra_> for which we dont build
[16:18] <infinity> (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# ls
[16:18] <infinity> arm-linux-gnueabi_EGL.conf  arm-linux-gnueabihf.conf  arm-linux-gnueabihf_EGL.conf  libc.conf
[16:18] <infinity> Yes, well.
[16:19] <infinity> My point is that in the above scenario, we get arm-linux-gnueabi_EGL.conf parsed first (which has what you want in it).
[16:19] <infinity> Once you set up the correct alternatives, it may be doing something you didn't expect.
[16:19] <ogra_> right, but that file is gone in r16
[16:19] <infinity> But I'll find out once I build your binaries.
[16:19] <infinity> ogra_: I know the file should be gone in r16, I'm saying that might be your problem. :P
[16:19] <ogra_> oh. i can push my binary for you as well ...
[16:20] <infinity> ogra_: Too late, sbuild's finished installing build-deps. :P
[16:20] <infinity> I assume the build itself is a few seconds.
[16:20] <ogra_> yep
[16:20] <ogra_> pretty niosy about the symbols :)
[16:21] <ogra_> just for completion, there is no arm-linux-gnueabi_* file in my /etc/ld.so.conf.d (and never was on this install)
[16:22] <ogra_> (helps to have three ac100's :) )
[16:25] <ogra_> marvin24, ohhh, intrestin, with the plain kernel video driver i always need to switch to console and back after DPMS, using the tegra driver it just wakes up fine
[16:26]  * ogra_ glares at http://paste.ubuntu.com/1254177/
[16:27] <ogra_> intresting that it loads all the other libs from /usr/lib/nvidia-tegra ... just not EGL and GLES
[16:29] <alex-ac100> ogra_: yes, wake up works better with tegra drivers
[16:32] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ for file in $(ls usr/lib/*.so);do  objdump -x $file|grep SONAME;done|grep .so |wc -l
[16:32] <ogra_> objdump: usr/lib/libnvrm_impl.so: File format not recognized
[16:32] <ogra_> 0
[16:33] <ogra_> ...
[16:33] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ for file in $(ls usr/lib/*.so);do  objdump -x $file|grep SONAME;done|grep .so |wc -l
[16:33] <ogra_> 57
[16:33] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$
[16:33] <ogra_> so it seems nvidia tried to be nice and added SONAMEs all over the place ...
[16:33] <ogra_> just that they didnt add any versioning ...
[16:33] <ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ for file in $(ls usr/lib/*.so);do  objdump -x $file|grep SONAME;done|grep .so. |wc -l
[16:33] <ogra_> 0
[16:39]  * ogra_ thinks he should just install libEGL.so and libGLESv2.so (and their links) to /usr/bin and be done
[16:39] <ogra_> or link them there or so
[16:40] <ogra_> the mesa ones wont be used because we override the alternative
[16:41] <ogra_> infinity, ^^^ do you think that could cause any havoc ?
[16:43]  * ogra_ goes to find some coffee
[16:43] <rsalveti> ogra_: would probably cause issues with any gles software you might build there
[16:43] <rsalveti> remember that once you built with a wrong SONAME, things get messy
[16:44] <ogra_> i would be fine with that and a release note for ac100 ... and the possibility that nvidia fixes it in 3 months or so to SRU it
[16:44] <ogra_> it wont make the release if i dont get it in somehow
[16:45] <ogra_> and that would be a shame ... took 2 years to get nvidia to a point where they are on the same ABI and have a working driver released in time for us
[16:45] <ogra_> rsalveti, also wouldnt builds use mesa anyway ?
[16:46] <infinity> ogra_: Uhm, your alternatives still seem broken here.
[16:46] <ogra_> infinity, in what way ?
[16:46] <infinity> ogra_: In that I still have a arm-linux-gnueabi_EGL.conf with the r16 package.
[16:47] <rsalveti> the broken soname would affect us even with the right and multi-arch compatible path
[16:47] <ogra_> http://paste.ubuntu.com/1254227/
[16:47] <ogra_> thats how it looks for me
[16:47] <rsalveti> so I don't think there's any easy way out here
[16:47] <ogra_> did you uninstall r15 ?
[16:47] <infinity> ogra_: I just built and installed from your sources.
[16:48] <rsalveti> we should probably just try to get this working with multi-arch and update-alternatives and get it to the archive
[16:48] <ogra_> rsalveti, but how without hacking the SONAME ?
[16:48] <rsalveti> we first need to understand if that's really the issue
[16:48] <rsalveti> we currently don't know what is happening :-)
[16:49] <ogra_> well, its the obvious difference between r15 and r16
[16:49] <infinity> (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# update-alternatives --list arm-linux-gnueabihf_egl_conf
[16:49] <infinity> /usr/lib/arm-linux-gnueabihf/mesa-egl/ld.so.conf
[16:49] <ogra_> r15 no SONAME, apps follow the links ... r16 SONAME but wrong, ldconfig caches the wrong soname, apps fall over because the wrong SONAME is provided
[16:50] <infinity> Before we faff about SONAMEs, let's address this business. :P
[16:50] <infinity> ogra_: Are your local sources different from the ones you pointed me at?
[16:50] <ogra_> just checking that
[16:51] <ogra_>  --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/nvidia-tegra/ld.so.conf 9000
[16:51] <ogra_> thats in my current postinst
[16:52] <infinity> Yeah, that's not what I have here.
[16:52] <ogra_> ah, super sorry
[16:52] <infinity> Also, your prerm will need to both remove the old and new ones, but maybe it does in your version.
[16:52] <ogra_> not yet, but i'm aware
[16:53] <infinity> Let me do this by hand and see where it lands me.
[16:55] <infinity> Alright, that gets me to your breakage now.
[16:57] <infinity> Hrm.
[16:57] <infinity> ln -s /usr/lib/nvidia-tegra/libGLESv2.so.2 /usr/lib/
[16:57] <infinity> ^-- That really shouldn't work.
[16:57] <infinity> But it does. Grr.
[16:58] <infinity> And LD_DEBUG=all just shows that it's not using /usr/lib/nvidia-tegra in the search path at all.
[16:59] <infinity> So, not necessarily the SONAME to blame here.
[17:00] <ogra_> werid, because ldconfig -v just lists the libs fine
[17:01] <ogra_> i get: libGLESv2.so -> libGLESv2.so.2
[17:01] <ogra_> (note the wrong order due to the SONAME)
[17:01] <infinity> I don't...
[17:01] <infinity> I don't get it listed at all.
[17:01] <infinity> Or, I can't type.
[17:01] <ogra_> well, i do, probably your alternatives are still wonky ?
[17:02] <infinity> The thing is, linking it in /lib doesn't change the wonkiness of that so -> so.2 thing.
[17:02] <infinity> It just starts showing up in searched.
[17:02] <ogra_> with LD_DEBUG i see that libGLESv2.so.2 gets directly loaded when in /usr/lib
[17:02] <infinity> seaches*
[17:02] <ogra_> right
[17:03] <ogra_> it will make binaries work :)
[17:03] <infinity> Yeah, but.  That doesn't tell me anything about what's wrong.
[17:05]  * infinity compares a chroot with r15 to one with r16 to sort this out.
[17:05] <ogra_> nothin is worng (apart probably from being able to force loading of a lib if i put it in /usr/lib)
[17:05] <ogra_> ld does the right thing
[17:05] <infinity> Which right thing is that?
[17:05] <ogra_> using the SONAME and caching the lib info with it
[17:06] <ogra_> its not ld's fault that the SONAME has no version number
[17:06] <infinity> Well, yes, that's the right thing, but that shouldn't relate to search paths.
[17:06] <ogra_> oh, still taht
[17:06] <ogra_> sorry, thought you solved that bit yet
[17:07] <infinity> No, if it was searching the path, it would work.
[17:07] <infinity> That's how it finds it when it's in /lib
[17:08] <ogra_> oh, inbtresting ... ldconfig -v with the lib in both places shows me the SONAME issue for both even
[17:08] <infinity> ogra_: Yeah, I said that earlier.
[17:08] <ogra_> ah
[17:14] <infinity> Okay, so looks like two bugs.
[17:14] <infinity> One is the library having the wrong SONAME, which means it won't land in the cache.
[17:14] <ogra_> right
[17:15] <infinity> The other is that ld.so doesn't search the extended path, only ldconfig.
[17:15] <ogra_> oh
[17:15] <ogra_> and that changed since precise ?
[17:15] <infinity> So, ldconfig will search the path and add "correct" libraries to the cache.  But our library is broken, so it doesn't get cached.
[17:15] <infinity> Later, ld.so searches the cache, finds nothing, and then walks the built-in directories it knows about.
[17:15] <infinity> No, it didn't change.
[17:15] <infinity> The r15 library gets cached.
[17:16] <infinity> And found from the cache.
[17:16] <infinity> So no walking required.
[17:16] <ogra_> it doesnt have a SONAME
[17:16] <infinity> Yes, which is apparently better than having an incorrect one. :P
[17:16] <ogra_> lol
[17:16] <ogra_> yeah
[17:16] <ogra_> obviously
[17:16] <ogra_> so do you know any trick to wipe the SONAME field (or ven fix it)
[17:17] <ogra_> *even
[17:17] <infinity> If there's padding in the ELF header, you could fix it.
[17:17] <infinity> Check with a hex editor.
[17:20] <ogra_> padding would be zeros ?
[17:21] <infinity> Yeah.
[17:21] <ogra_> hexedit doesnt really show anything usable on the right ...
[17:21] <ogra_> and there seem to be no zeros at the start of the file
[17:23] <ogra_> GCC: (crosstool-NG hg_unknown@20110628.165246) 4.5.3
[17:23] <ogra_> heh
[17:23] <ogra_> 4.5
[17:24] <infinity> Boom, easily fixed.
[17:25] <ogra_> ??
[17:25] <infinity> There's a bunch of nulls after GLIBC_2.4
[17:25] <ogra_> yep, i see them
[17:25] <ogra_> e_match.__cxa_call_unexpected.libGLESv2.so.GLIBC_2.4................
[17:25] <infinity> So, you replace libGLESv2.so\0GLIBC_2.4\0\0 with libGLESv2.so.2\0GLIBC_2.4
[17:25] <infinity> And it all magically works.
[17:26] <infinity> The same needs to be done for libEGL.so.1 as well.  And who knows what else.
[17:26] <infinity> A quick binary patching script to fix it up in the build wouldn't be much effort.
[17:26] <ogra_> only the two to make binaries work at least
[17:26] <infinity> And would be the more "correct" fix anyway.
[17:26] <infinity> As annoying as it is.
[17:27] <ogra_> >/me has never done somethin like this, do you know odf an example ?
[17:29] <ogra_> (i manage editing with hexedit indeed, but have no idea how i would have to script that)
[17:31] <infinity> sed -i -e 's/libEGL.so\x00GLIBC_2.4\x00\x00/libEGL.so.1\x00GLIBC_2.4/' /usr/lib/nvidia-tegra/libEGL.so
[17:31] <ogra_> you can sed that ?!?!?!
[17:31] <ogra_> geez
[17:31] <infinity> ^-- That seemed to DTRT for my libEGL, cook as appropriate for others.
[17:32] <infinity> ogra_: Requires GNU sed (\x00 is a GNU extention), but we don't ship any other POSIX seds anyway, so whatever.
[17:32]  * ogra_ wouldnt have thought of sed ... probably some dd and cat weirdnesses, but not sed :)
[17:33] <infinity> Hrm, that might not have worked actually.  sed may have broken it.
[17:33] <infinity> Was good enough for ldconfig, not good enough for ld.so. :P
[17:33] <infinity> (While hand-editing was good enough for both...)
[17:33] <infinity> There was a nice C-based binary patches in LRM, back when LRM still existed.
[17:33] <ogra_> yeah, i'm still poking bytes here
[17:33] <infinity> I can try to dig it up in a bit.
[17:34] <infinity> Oh wait.  Hahaha.
[17:34] <infinity> No, it's not that sed broke it.
[17:34] <ogra_> well, worst case i change it while repackaging the updatream tarball
[17:34] <ogra_> *upstream
[17:34] <infinity> It's that other libraries are linked to libEGL.so, which doesn't exist once I've done that.
[17:34] <ogra_> i have to do that anyway to match the format of the package
[17:35] <infinity> So braindead.
[17:35] <ogra_> oh, indeed, all libs use the broken sonames :)
[17:36]  * infinity head -> desk.
[17:36] <infinity> So, monkey-patching the SONAMEs won't work, since while that fixes all OUR binaries, it breaks all of THEIRS.
[17:36] <infinity> Brilliant.
[17:36] <ogra_> btw, is there any particular reason that ld doesnt search additional dirs ?
[17:37] <infinity> Other than it being painfully slow to make ld.so parse a conf.d directory for run-time configs, no.
[17:37] <infinity> It's meant to trust the cache.
[17:37] <ogra_> k
[17:37] <infinity> Which would work, if the cache was caching libraries that weren't insane.
[17:37] <ogra_> heh
[17:39] <infinity> Do you have a good enough rapport with upstream to just get them to fix their SONAMEs?
[17:39] <infinity> Cause this is going to end up on our end with either a mess of incorrect symlinks, or monkeypatching and a few incorrect symlinks.
[17:39] <infinity> Neither is pretty.
[17:39] <ogra_> not in time
[17:39] <infinity> And neither is correct.
[17:40] <infinity> Cause you're going to have to ship "dev" symlinks (/usr/lib/*.so) to make this work, even after patching the binaries to be unbroken.
[17:40] <infinity> Well, maybe you could patch the NEEDED section in everything too...
[17:40] <ogra_> well, as i said in the beginning, i would just install EGL and GLES to /usr/lib
[17:41] <infinity> Yeah, or that.  Still broken. :/
[17:41] <ogra_> all others arent versioned at all and are only used by these two
[17:41] <ogra_> yes, but once there is a fix i wont have to fiddle with symlinks ...
[17:41] <ogra_> the files would just move to lib/nvidia-tegra and ldconfig woudl pick up the change
[17:42] <infinity> I'd still like to talk to upstream about doing it right.
[17:42] <ogra_> i'll surely poke srwarren about it but he's despite being my contact not the maintainer
[17:42] <mjrosenb> do you guys have plans for firefox-18?
[17:43] <infinity> mjrosenb: When it's the current version, sre.
[17:43] <infinity> s/sre/sure/
[17:44] <ogra_> damned, now how do i save a file in hexedit ...
[17:44] <mjrosenb> infinity: that turns on ionmonkey, which is not armhf friendly
[17:44] <ogra_> pressing a key tells me F1 for help ...
[17:44] <ogra_> F1 indeed gives me the gnome terminal help :P
[17:45] <infinity> ogra_: I dunno, I use ghex, which appears to have sane menus.
[17:45] <infinity> ogra_: That said, sed was doing the right thing for me.  It was just the NEEDED sections in OTHER libs that were still broken.
[17:45] <infinity> (As in, some of the little support libs are linked against "libEGL.so")
[17:46] <infinity> mjrosenb: I've not looked into it or heard much about it.  How not friendly is it?
[17:46] <ogra_> ah, ctrl-x
[17:47] <mjrosenb> infinity: it should need minimal modifications, but I'm considering leaving that up to a student/contributor, which means it may never get done
[17:48] <infinity> rsalveti: ^-- Something for your team to poke at?
[17:50] <infinity> janimo: You around?
[17:50] <janimo> infinity, yes
[17:51]  * janimo wonders what he broke now
[17:51] <infinity> janimo: precise armadaxp.  It's an ABI bump, but no meta.
[17:51] <janimo> ah, the SRU right?
[17:51] <infinity> janimo: Also, don't set promote-to-proposed tasks to Fix Released if you do the copy yourself.  Cause, well.  It's in the queue, and not done. :P
[17:52] <infinity> janimo: Yes.
[17:52] <janimo> ok, I usually waited to see the package building before uploading the meta
[17:52] <infinity> janimo: (Really, no need to do the copy yourself anyway, I notice when they need to be done, and I need to babysit them anyway)
[17:52] <infinity> janimo: Erm, "see it building"?  You already copied it to the archive!
[17:52] <janimo> infinity, ok. I think when I did the first SRUs at the beginnning of Q I was told I should copy them
[17:52] <janimo> or they'd languish there
[17:52] <infinity> Yeah, you were lied to. ;)
[17:53] <infinity> (You can copy if you like, but it just ends up in the queue and someone needs to manually do overrides anyway, I prefer to do it all when I know what's going on)
[17:53] <janimo> ok, I will not copy from now on, not sure why I was asked too
[17:54] <infinity> janimo: Anyhow, copying yourself or not, please never do the copy until after all support packages (only meta in your case) are also done, so they can all copy together.
[17:54] <janimo> infinity, ok. I always thought it's ok to have the linux-image package there without meta
[17:54] <infinity> janimo: Since promote-to-proposed assumes the whole thing as a block (lbm/linux/meta/etc)
[17:54] <janimo> as it does not get  upgraded to anyway until meta is there no?
[17:55] <janimo> ah, I had no idea about that promote contract
[17:55] <janimo> it makes sense, just I did not encounter it so far
[17:55] <infinity> janimo: Even in devel releases, I prefer if it happens this way, but for SRUs, we have a pretty strict way of doing things.
[17:55] <infinity> janimo: For devel releases, I'd still rather see kernel/meta go to proposed together, instead of this "we have two kernels in the archive, and one's NBS" thing.
[17:57] <infinity> janimo: Anyhow.  meta the PPA up for me, if you please.  I'm going to reject the current copy for the sake of my own sanity and reset the task, and I'll do the whole thing together later.
[17:57] <janimo> infinity, ok, will do
[17:57] <infinity> Oh, feh.  I can't reset the task.
[17:58] <infinity> I'll just reassign it to me and remember to do it later. :P
[18:13] <ogra_> hmm, so i manage to empty the SONAME field, but i cant make it vanish
[18:14] <ogra_> oh, and an empty SONAME really makes ld dizzy :)
[18:21] <ogra_> infinity, <srwarren> We do have a bug to add (correct) sonames to the libraries, and it's also possible we half-implemented it but with bogus values. anyway, I'll track down the bug and put comments there indicating the problem.
[18:21] <ogra_> (from #ac100)
[18:22] <janimo> infinity, meta built in ppa
[18:22] <infinity> janimo: I noticed, thanks.
 swarren no chance to use cmake or autotools with libtool?
 woglinde, no, we build the libraries with the same tools for Android, Linux etc.
 and hence someone developed custom makefiles for it all.
[18:22] <ogra_> now thats lovely
[18:23] <infinity> Meh, if they figured out how to put some sort of SONAME in there, they can figure out how to make it right. :P
[18:23] <infinity> Not rocket science.
[18:23] <ogra_> heh, indeed
[18:23]  * janimo is tempted to save the backlog of the past hours of conversation on this list for future historians who may be interested in the ways people at the beginningof 21st century struggled to convey straightforward things  due to error prone and inexpressive tools at their disposal
[18:24] <janimo> to computers
[18:24] <ogra_> infinity, well, i told him if he manages to get me a rebuild til thu it will make it in (given there are no other bugs)
[18:24] <ogra_> lets see
[18:24] <ogra_> he is very concerned
[18:25] <ogra_> (srwarren is a good guy ... he's also active on cross-distro )
[18:43] <ogra_> infinity, given that the driver works just fine and only the libs are affected i'm pondering to upload as is ... while GLES doesnt work then, HDMI works and xorg only uses 1/10h of ram
[18:43] <ogra_> *1/10th
[18:44] <ogra_> that should also make SRUing an upstream fix easy
[18:45]  * ogra_ will put the current package on the shelf for thu ... if nvidia manages i can still update the tegra_bins tarball quickly
[20:59] <alex-ac100> janimo: I'm afraid, but this ac100 3.1.10-5-ac100 #8 kernel build is not correct again
[20:59] <janimo> alex-ac100, what is missing?
[21:04] <alex-ac100> janimo: TEGRA_AVP_KERNEL_ON_MMU=y
[21:04] <janimo> alex-ac100, can you clone the git tree and build the package yourself?
[21:04] <janimo> did you build marvin's ?
[21:05] <ogra_> TEGRA_AVP_KERNEL_ON_MMU=y is correct, no ?
[21:05] <janimo> no idea
[21:05] <alex-ac100> it is, but not set in last build
[21:05] <ogra_> well, afaik it is
[21:05] <janimo> they have  many cryptic config names which I do not know what they stand for
[21:05] <ogra_> ah
[21:05] <alex-ac100> same here
[21:06] <ogra_> well, fly-away isnt here, he fiddled with all that multimedia playback stuff
[21:06] <ogra_> (he is in #ac100 though)
[22:47] <rsalveti> ogra_: infinity: I don't think sed would work there
[22:47] <rsalveti> because the size is different
[22:47] <rsalveti> and the elf headers stack size would probably change
[22:47] <rsalveti> breaking some other stuff
[22:48] <rsalveti> so I believe the easiest way to handle that is to handle the pain of having the libs at the standard locations
[22:48] <rsalveti> such as /usr/lib, and get that bug opened for nvidia to handle later
[22:50] <infinity> rsalveti: The sed I gave him didn't change the size.
[22:51] <infinity> rsalveti: But there's breakage in their other libs havng the unversioned .so in NEEDED, so yeah.  It's all pretty FUBAR. ;)
[22:52] <rsalveti> infinity: oh, true, luckly there was \0\0
[22:52] <rsalveti> yeah, that's expected as well
[22:52] <rsalveti> in android nobody cares about sonames
[22:52] <rsalveti> actually, nobody cares about anything that's vendor/hardware specific :-)
[22:53] <rsalveti> the problem is that then the vendor ends up using the same solution everywhere else :-)
[22:55] <infinity> rsalveti: I'm fairly confident they'll fix it for Oli, the question is if they'll do it in a timely fashion. ;)
[22:56]  * infinity thinks he should take an afternoon nap and sleep off this cold/flu/whatever.
[22:56] <rsalveti> yeah, not for quantal, for sure