[01:20] <infinity> slangasek: You around?
[01:20] <slangasek> infinity: ohai
[01:20] <infinity> slangasek: https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu136.11
[01:20] <infinity> slangasek: Can you sru-release that as soon as its all built and published (in an hour or two)?
[01:20] <slangasek> infinity: ack
[01:21] <infinity> slangasek: The current precise-updates d-i is built against a kernel that never made it to -updates, so iz broke.
[02:53] <infinity> slangasek: Belay the d-i/precise request.  I'm still awake, I'll nab it on the next publisher run.
[03:18] <slangasek> infinity: mmk
[08:00] <apw> openvswitch seems to have built and tested just fine (second time) and yet britney is listing it as autopkgtest fail ... could someone who knows how poke it
[13:39] <ogra_> is there any way for a packge to know it is installed on a package builder ?
[13:39] <ogra_> infinity, ^^  do you knwo ?
[13:41] <stgraber> ogra_: that's sounds like an hack ;) but I suppose checking for /build may do the trick
[13:42] <ogra_> stgraber, better than nothing :)
[13:42] <ogra_> we need a way for libhybris to know it lives in a build env ...
[13:43] <ogra_> else it sets an alternative for GLES that points too a non existing android dir
[13:43] <ogra_> (instead fo just using mesa ... which it shoudl for builds)
[13:43] <stgraber> ogra_: you may also be able to use some env variables set by dpkg-buildpackage which should be better than looking at /build (as /build won't exist on your local machine when running debuild)
[13:44] <stgraber> ah though if you need that to be checkable from the postinst of a build-dep, then I guess /build may be the only way (that I can think of anyway)
[13:45] <ogra_> well, doesnt postinst see the env vars ?
[13:45] <ogra_> that sounds more proper than checking for /build
[13:45] <ogra_> rsalveti, ^^^
[13:46] <stgraber> ogra_: yeah, it'd except that it's not dpkg-buildpackage installing the build-deps but sbuild, so you'll be missing most/all build env variables that early in the build process
[13:46] <ogra_> i need an opinion ... builds fail if Mir is involved because hybris sets the GLES alternative to /system/lib ...  during build we'd like it to use mesa instead
[13:46] <ogra_> stgraber, bah, k ... so that wouldnt help
[13:47]  * rsalveti looks
[13:48] <rsalveti> ogra_: why is hybris even used there?
[13:48] <ogra_> rsalveti, yeah, i was pushig to just drop the dep from Mir as well
[13:48] <ogra_> but tvoss says that doesnt work because he uses its herades for gralloc etc
[13:49] <ogra_> so the -dev is a build dep of Mir (which breaks all normal armhf desktop installs :( )
[13:49] <ogra_> *headers
[13:49] <rsalveti> hm, in theory it should just use mesa
[13:49] <rsalveti> where is tvoss
[13:49] <ogra_> they were about to move the alternative creation into lxc-android-config but i vetoed
[13:50] <ogra_> (thats like udev shipping an xorg.conf)
[13:50] <rsalveti> ogra_: where did this discussion happened?
[13:50] <cjwatson> Isn't there a way to select a GLES provider other than via the system alternative?
[13:50] <seb128> rsalveti, in half a dozen channels and lists today :p
[13:50] <ogra_> cjwatson, not implemented i think
[13:50] <cjwatson> Some solution like that sounds much more likely to be robust to me
[13:50] <cjwatson> ogra_: You have to implement *something* :)
[13:50] <ogra_> cjwatson, and it would involve changing lots of packages i guess
[13:50] <rsalveti> seb128: haha
[13:50] <cjwatson> Surely not
[13:50] <seb128> rsalveti, he pinged you earlier on #phablet, maybe pong there
[13:50] <cjwatson> Strawman: LD_LIBRARY_PATH or LD_PRELOAD
[13:51] <ogra_> i.e. nvidia/ati drivers on x86
[13:51] <cjwatson> ogra_: I don't care about drivers, this is at build time
[13:51] <ogra_> cjwatson, yeah i suggested that ... seb128 decliend ... i forrgot why
[13:51] <ogra_> rsalveti, sadly it is spread all over the channles (and the ML now)
[13:51] <ogra_> there he is :)
[13:51] <seb128> cjwatson, ogra_: we are not going to patch every package in the archive calling xvfb-run make check...
[13:51] <ogra_> tvoss|lunch, stop eating :)
[13:52] <tvoss|hungry> ogra_, done ;)
[13:52] <ogra_> seb128, ah, right, i remember it was valid ... just forgot what it was :)
[13:52] <ogra_> cjwatson, no it isnt
[13:52] <ogra_> cjwatson, it is for packages that depend on libmir
[13:52] <cjwatson> How about a shim library that tries GLES from the Android directory and falls back to Mesa if it doesn't exist?
[13:52] <rsalveti> tvoss_: so, why do you need to build-depend on libhybris?
[13:52] <cjwatson> Should be eminently doable with dlopen et al
[13:53] <ogra_> cjwatson, that would break image builds ... we dot have android available there
[13:53] <cjwatson> ogra_: What are you replying to?
 How about a shim library that tries GLES from the Android directory and falls back to Mesa if it doesn't exist?
[13:53] <ogra_> <r
[13:53] <tvoss_> rsalveti, because the mir client library needs hardware/fb.h, hardware/gralloc.h at buildtime
[13:53] <cjwatson> ogra_: Can you elaborate on why that would break image builds?  Why do they need to load GLES?
[13:54] <ogra_> cjwatson, oh, i see, you would drop the alterbnative completely
[13:54] <cjwatson> And why would they care if they got Mesa as a run-time choice?
[13:54] <ogra_> yeah, i didnt get that bit
[13:54] <ogra_> sorry
[13:54] <cjwatson> ogra_: Not necessarily, since that's probably wired in elsewhere, but have an alternative provider that can dynamically select for itself
[13:54] <ogra_> i thought yu wanted a separate entiti for setting the alternative
[13:54] <cjwatson> I would prefer to leave the alternative in place and have it point to something smart
[13:55] <tvoss_> cjwatson, that's what we need and want for supporting multiple vendor-specific egl/gl implementations being installed and usable in parallel
[13:55] <ogra_> yeah
[13:55] <ogra_> well, i think having the postinst be intelligent would suffice
[13:55] <cjwatson> No, it's better not in the postinst
[13:55] <cjwatson> Because the postinst is run in a non-Android environment (image build) and then the contents of the system transferred to a device where Android is present
[13:56] <cjwatson> You could have the library's constructor do a few checks with dlopen and then set a load of function pointers based on what it finds
[13:56] <cjwatson> It's certainly no harder than all the crazy stuff libhybris already does :)
[13:56] <ogra_> so you would do it in libmirclient ? or in hybris ?
[13:56] <rsalveti> tvoss_: so would it need such files for all archs?
[13:57] <cjwatson> And this way, you can check for what you actually care about (is Android there?) rather than a strange proxy (are we in a package build environment?)
[13:57] <cjwatson> ogra_: Don't know enough about them to pick one
[13:57] <ogra_> k
[13:57] <tvoss_> rsalveti, no, only if we build the android driver model, and we take armhf as a trigger for that
[13:57] <seb128> rsalveti, it doesn't, the deps is only there on armhf, but armhf != android
[13:57] <ogra_> (arent you on vacation ? i pinged adam on purpose because i thought so :) )
[13:58] <cjwatson> ogra_: Me?  No
[13:58] <ogra_> ah , k
[13:58] <ogra_> i thought you said something about skiing yesterday
[13:58] <rsalveti> seb128: tvoss_: right, assuming armhf == android is already wrong indeed
[13:58] <ogra_> yeah
[13:58] <infinity> If hybris is linked against this library, it seems sensible for it to be the one doing the resolution at runtime.
[13:59] <infinity> Since it's the only thing that cares about which one it uses.
[13:59] <tvoss_> rsalveti, fully agreed, and we would love to have a different trigger
[13:59] <ogra_> infinity, it isnt linked thats the issue ... it uses the alternative ... but forcefully sets it
[13:59] <ogra_> (to something nonexisting)
[13:59] <infinity> ogra_: It "uses" the alternatives, how?  It's still linked to and/or dlopening a library, or there wouldn't be a problem. :P
[14:00] <ogra_> it is linked to the alternative ... which the postinst sets to something that doesnt exist if android isnt available
[14:00] <rsalveti> tvoss_: seb128: do you have the build log for the original issue?
[14:00] <infinity> ogra_: If it's a dlopen, this becomes trivial.  If it's linked, then you'd need an intelligent stub.
[14:00] <tvoss_> infinity, hybris provides an alternative libEGL, that gets selected as the default when hybris is installed
[14:00] <rsalveti> too many parallel talks and my brain is still waking up
[14:00] <seb128> rsalveti, https://jenkins.qa.ubuntu.com/job/unity-saucy-armhf-autolanding/157/console
[14:01] <seb128> rsalveti, that's one
[14:01] <cjwatson> ogra_: Not I.  In two weeks I'm going to be in the middle of the Alps, but whether that will involve any skiing is debatable since I've never skied before
[14:01] <infinity> tvoss_: Oh, I see.  So it's everything else being linked to it that's the issue.  Not running it through hybris.
[14:01] <ogra_> cjwatson, heh, Alps = skiing for me like armhf = android for tvoss_ ;)
[14:01] <cjwatson> In that case I would suggest a new stub library
[14:01] <tvoss_> rsalveti, don't have it handy, but in summary: hybris installed -> egl from hybris forced as default -> applications accessing default egl impl -> kaboom
[14:02] <rsalveti> seb128: that's because it's trying to use that library when running the test, right?
[14:02] <infinity> tvoss_: So, the libhrybris-provided libEGL should be a stub that loads the right bits if they're there, and not if they're not.
[14:02] <tvoss_> cjwatson, +1, and we could reuse that work to support vendor-specific (nvidia, amd) egl/gl implementations being installed in parallel
[14:02] <tvoss_> but: we need a short-term fix to unblock CI
[14:02] <seb128> rsalveti, it's trying to use a graphical toolkit, which leads to that
[14:03] <rsalveti> right, it's not just a linking issue, it's indeed trying to use the library
[14:03] <seb128> rsalveti, same issue on ubuntu-system-settings trying to run a qt5 ui through xvfb-run
[14:03] <rsalveti> and failing because hybris can't load /system/lib/libGLESv2.so
[14:03] <tvoss_> infinity, true, but see my comment to cjwatson :) ideally, the mesa egl would be clever, and hybris would be just another implementation
[14:03] <tvoss_> rsalveti, right, linking is not the problem
[14:03] <cjwatson> Perhaps, but there's no reason you should block on that.
[14:03] <cjwatson> Or even try to do it in the first pass.
[14:03] <ogra_> why cant xfb unset the alternative btw ?
[14:03] <ogra_> as a quick hack
[14:04] <ogra_> *xvfb
[14:04] <cjwatson> Sounds scary
[14:04] <cjwatson> Messing with alternatives is on my "avoid if possible" list
[14:04] <tvoss_> cjwatson, the moment tests are executing, they crash
[14:04] <ogra_> well, hack ... and quick were in the sentence :)
[14:04] <cjwatson> Especially outside maintainer scripts
[14:04] <stgraber> ogra_: because people have xvfb installed on their desktop machines too?
[14:04] <cjwatson> Quick hacks can be hard to undo
[14:04] <ogra_> stgraber, crazy people :P
[14:04] <stgraber> ogra_: well, I'd expect any ubiquity developer to have it and anyone who worked on projects that mvo once started ;)
[14:05] <ogra_> why would i need it for ubiquity ? i just test  in a real X :)
[14:05] <stgraber> (unless they like windows randomly popping up on their screen while the pre-commit stuff runs ;))
[14:06] <cjwatson> ogra_: We have this thing called a test suite :)
[14:06] <ogra_> :)
[14:06] <ogra_> i dont mind popping up windows
[14:06] <rsalveti> tvoss_: would we also have test cases to test gralloc or such?
[14:07] <rsalveti> if so, then we're back to the same issue, even with a stub
[14:07] <tvoss_> rsalveti, sure, exercising the mir parts that make use of it
[14:07] <rsalveti> we basically can run such tests that depend on hybris if we're not in a valid android environment
[14:08] <rsalveti> unless we have fake stubs for everything, but which will cause side effects for the tests as well
[14:09] <tvoss_> rsalveti, true, that's why a lot of mir tests on armhf are currently disabled
[14:09] <ogra_> cjwatson, stgraber, in any case i would just make xvfb-run export something like "HYBRIS_USE_MESA" and make the hybris postinst alternative setup be conditional for this as the quick hack i was proposing ... shouldnt do any harm to xvfb-run
[14:10] <rsalveti> heheh
[14:10] <stgraber> ogra_: I doubt that'd work as you'd need to have the dependencies be installed under xvfb-run which I doubt they are
[14:11] <ogra_> oh, right, so HYBRIS_USE_MESA would have to override the alternative inside hybris ...
[14:11] <ogra_> thats not a quick hack anymore indeed
[21:47] <rsalveti> if anyone around, mind taking a look at ^
[21:47] <rsalveti> just moving stuff from libhybris into more packages, android-platform-headers, libhardware2 and libhybris-common1
[21:47] <rsalveti> this will solve that mir/hybris issue in the archive for armhf that we had today
[21:48] <rsalveti> will split the rest after proper discussion with upstream, as I'd like some libs to get renamed as well
[21:53] <seb128> rsalveti, seems weird that you don't have Replaces/Breaks (<< new), on the old binaries, to avoid file conflict on update?
[21:56] <rsalveti> seb128: the new packages would need to replace/breaks << libhybris, right?
[21:56] <seb128> rsalveti, yes
[21:57] <rsalveti> doing so many things in parallel that I forgot that
[21:57] <seb128> rsalveti, otherwise you might have apt hitting file conflicts if the e.g libhardware is unpacked before libhybris is upgraded
[21:57] <rsalveti> seb128: let me cook another upload
[21:57] <seb128> rsalveti, thanks
[21:58] <seb128> rsalveti, also you are sure it's not going to break touch? e.g nothing is depending on libhybris and expecting to get libhardware with it?
[22:00] <rsalveti> seb128: mir is the first one
[22:01] <seb128> rsalveti, you might want to keep libhybris depending on libhardware (if it's not doing it through shlibs)
[22:01] <seb128> rsalveti, to avoid those issues
[22:02] <rsalveti> seb128: yup
[23:01] <skellat> Greetings.  Is anybody willing and able to dispose of this SRU request plus Sponsored Upload request?  https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1207493
[23:01] <ubot2`> Ubuntu bug 1207493 in xubuntu-docs (Ubuntu) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Confirmed]