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