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:20 |
infinity | slangasek: The current precise-updates d-i is built against a kernel that never made it to -updates, so iz broke. | 01:21 |
infinity | slangasek: Belay the d-i/precise request. I'm still awake, I'll nab it on the next publisher run. | 02:53 |
slangasek | infinity: mmk | 03:18 |
=== doko_ is now known as doko | ||
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 | 08:00 |
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:39 |
stgraber | ogra_: that's sounds like an hack ;) but I suppose checking for /build may do the trick | 13:41 |
ogra_ | stgraber, better than nothing :) | 13:42 |
ogra_ | we need a way for libhybris to know it lives in a build env ... | 13:42 |
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:43 |
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:44 |
ogra_ | well, doesnt postinst see the env vars ? | 13:45 |
ogra_ | that sounds more proper than checking for /build | 13:45 |
ogra_ | rsalveti, ^^^ | 13:45 |
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:46 |
* rsalveti looks | 13:47 | |
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:48 |
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:49 |
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:50 |
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:51 |
=== tvoss|lunch is now known as tvoss|hungry | ||
tvoss|hungry | ogra_, done ;) | 13:52 |
=== tvoss|hungry is now known as tvoss_ | ||
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:52 |
ogra_ | cjwatson, that would break image builds ... we dot have android available there | 13:53 |
cjwatson | ogra_: What are you replying to? | 13:53 |
ogra_ | <cjwatson> 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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 13:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
rsalveti | unless we have fake stubs for everything, but which will cause side effects for the tests as well | 14:08 |
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:09 |
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:10 |
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 | 14:11 |
=== 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 | ||
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:47 |
rsalveti | will split the rest after proper discussion with upstream, as I'd like some libs to get renamed as well | 21:48 |
seb128 | rsalveti, seems weird that you don't have Replaces/Breaks (<< new), on the old binaries, to avoid file conflict on update? | 21:53 |
rsalveti | seb128: the new packages would need to replace/breaks << libhybris, right? | 21:56 |
seb128 | rsalveti, yes | 21:56 |
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:57 |
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? | 21:58 |
rsalveti | seb128: mir is the first one | 22:00 |
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:01 |
rsalveti | seb128: yup | 22:02 |
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] | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!