[00:00] infinity: do you want the list of regressions that actually correspond with the gcc5 upload? [00:00] Since the way we give gcc-5 a pass is to tell britney to ignore all gcc-5 related tests. [00:00] Which I won't do until we're sure all the ones we care about are good. [00:00] ah [00:00] (The other way is to ignore tests for specific packages, but that gives those regressions a pass, which we don't want) [00:01] Some of these might be flappy weirdness. [00:01] * infinity retries a few. [00:02] ... after I read pitti's mail about how to retry. [00:02] is there a hand gesture to go with "flappy weirdness"? [00:02] slangasek: Imagine Kermit flailing. [00:15] doko, should we create a bug report for LP: #1483403 in Debian as well? [00:15] Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483403 [01:52] so, where should I start to help with gcc5? I have the pad open but I'm not quite sure where to begin [02:33] cyphermox, still looking where to help on gcc5? [02:56] cyphermox, anyway, the stuff at the bottom is more recent, so you can start there [05:11] I wonder if xcb-util could be dropped from NEW before we have a unwarranted diff against debian [05:11] an [05:18] tjaalton: Pretty sure the answer is “yes, but I'm not meant to press that button” [05:18] riight [05:18] ok [05:18] I'll wait for a reply first.. [05:19] from the uploader :) [05:19] before doing anything myself [05:20] the only thing being reverting the change from the debian branch [05:33] tjaalton: What diff do we not want? [05:33] infinity: renaming libxcb-util [05:34] well, pkg-xorg doesn't wan't the transition on debian, because it's pointless [05:34] tjaalton: It's not renamed because the SOVER changed? [05:34] the sover has been like that for ages [05:34] I mean, 0 -> 1 seems pretty clear. [05:34] hmm [05:35] or I'm completely wrong [05:35] * infinity looks at actual contents. [05:35] meh [05:35] Yeah, it really did bump SOVER. [05:35] * tjaalton woke up at 4am [05:35] Not renaming would be very wrong. :P [05:37] Hah. That's something you don't see every day. kwayland-integration was FTBFS on everything except arm64. [08:30] Laney, who can help promote deja-dup-caja out of the NEW queue for wily/ [08:30] ? [08:31] ~ubuntu-archive [08:38] Laney, how often do the packageset scripts run? [08:38] (for seeded stuff) [08:39] manually, I run it once a week or so [08:41] Laney, manually automatic ;) can you run it this week some time ? to pick up gnome-getting-started-docs [08:42] it means that the sets aren't managed by hand [08:42] will run it now if you want [08:43] Laney, that would be good, images took a 120MB hit from seeding it [08:45] though that in itself its not a huge problem, at this point, but want to be able test langpacks are getting installed correctly before B1 hits [08:51] need to fix this script to not rsync ALL the dists/wily-* [09:00] I want to get bcache-tools into trusty/precise... I'm guessing that I probably did wrong in 1429857 and actually just want to upgrade 1449099 from wishlist? or progress it anyway... [09:00] what's the next step for me here, really, oh mighty release gods? [09:27] lamont: precise seems a bit much. [09:28] lamont: But if it builds cleanly on a straight backport, meh. [09:28] lamont: If so, then we just need SRUs of said backports from vivid (versioned as 1.0.7-1~14.04 and 1.0.7-1~12.04) [09:29] lamont: Given that the package didn't exist before, there's no regression chance, so the backport is not really problematic, but do put a test plan in the SRU bug for how you intend to validate that it's working on both releases. [09:34] infinity: lts kernel on precise... :( [09:34] infinity: ack [09:34] ta [11:31] infinity: any updates on nvidia-352{-updates} ? [14:21] sigh; jackd2 has a wrong symbols file (seemingly generated out of nowhere), so all the jackd2 rebuilds have to be redone [14:24] oh, d-shlibs again. thanks Jonas [14:28] except... d-shlibs isn't used in the build either [14:34] Laney: it looks like the go script has been updated again, considering some of the things dropping out of the list. How confident are we that this is correct, before I start culling the list of in-progress transitions? [14:37] slangasek: Indeed, I deployed a new version --- moderately confident? :) [14:37] heh [14:37] I fixed the problems I knew about and have verified some transitions today [14:57] ok so no symbols file in libjack-jackd2-0v5 at all, just a shlibs file and the shlibs file looks correct. Brilliant [14:58] Got an example of a bad package? Second pair of eyes might be helpful? [14:59] Laney: every darn thing on http://people.canonical.com/~ubuntu-archive/transitions/html/jackd2-g++5.html [14:59] I'm starting from the zynjacku end [14:59] oh of course [14:59] it pulled in libjack-dev instead of libjack-jackd2-dev at build time [15:00] a) why do we still have two of those things, b) that obviously won't work if the ABI has changed so either there's no ABI transition or libjack is now bustificated [15:01] doko: how did you determine that jackd needed an ABI transition? [15:03] slangasek, https://people.debian.org/~doko/logs/gcc5-20150701/jackd2_1.9.10+20140719git3eb0ae6a~dfsg-2_unstable_gcc5.log [15:28] * Laney cries at the libbpp stack [15:37] doko: ok so on jack. jackd provides two libraries; libjack and libjacknet. libjack has a C-only ABI. the shlibs point to libjack-jackd2-0v5 (>= 1.9.5~dfsg-14) | libjack-0.116. libjacknet has a C++ ABI; its shlibs also point to libjack-jackd2-0v5 (>= 1.9.5~dfsg-14) | libjack-0.116. However, libjack-0.116 is a virtual package provided by both libjack-jackd2-0v5 and by libjack0, and libjack0 do [15:37] esn't include libjacknet at all [15:37] if nothing has noticed this, it's possible libjacknet is completely unused and we shouldn't do a package name change [15:41] Should we start to see stuff migrating once it's ready? [15:41] modulo gcc-5 itself [15:41] Laney: probably small clusters only [15:41] in theory though [15:41] yes [15:42] I like attacking things from the proposed-migration direction too [15:42] pick a package and drill down on it until it goes in [15:42] doko: confirmed that libjacknet is an internal library only with no header files, it shouldn't even be part of the libjack package AFAICS but it certainly shouldn't have the shlibs it currently has. I'll back out the transition [15:42] Laney: yes, you should be able to do that soon [15:42] nod, thanks [16:21] doko: are you aware of some change in our gcc5 that would affect floating point precision on i386? [16:22] cyphermox, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 -> almost always bad code [16:22] gcc.gnu.org bug 323 in middle-end "optimized code gives strange floating point results" [Normal,Suspended] [16:22] figured that's what you'd link me ;) [16:22] glad you found it on your own =) [16:22] hehe [16:23] doko: danke. [16:24] I've seen some no-change rebuilds for boost today; is anyone working on systematically rebuilding for http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.58.html ? [16:25] not me [16:31] afternoon - could someone point balloons and I at what we need to report against for wily live sessions in Ubuntu and Xubuntu falling to login screen rather than starting the desktop [16:32] slangasek, ocaml packages could need some attention (e.g. liblastfm-ocaml-dev not installable) who did those in the past? [16:32] doko: I don't know [16:33] cjw I think did some [16:33] it's the same as haskell - rebuild them in level order [16:49] flocculant: I saw something like that related to compiz perhaps, but it depends [16:49] flocculant: wily daily for xubuntu and ubuntu? [16:54] both [16:55] cyphermox: so not compiz I would have to assume [17:10] flocculant: if both try to log in and fail, falling back to the login prompt, then something is broken [17:10] cyphermox: want some logs? [17:10] I'd watch .xsession-errors carefully (or whatever gets written), to see where it breaks [17:12] flocculant: check .xsession-errors and the logs in .cache/upstart/, like gnome-session.log or unity7.log [17:12] I'll check in a bit [17:39] cyphermox: logs http://pastebin.com/MnV18Csc === jhodapp is now known as jhodapp|errand [17:58] anybody have any easy gcc5 stuff for a noob like me to poke at? [18:03] robru, https://launchpad.net/ubuntu/+source/openvdb/3.0.0-3ubuntu3 [18:04] doko: thanks [18:05] robru, there's also tbb ftbfs on arm64 [18:05] would suggest to contact debian and/or upstream [18:05] or looking for patches upstream === jhodapp|errand is now known as jhodapp [18:27] doko: I don't see any new versions for tbb or openvdb either upstream or in debian [18:28] doko: do you want me to just file bugs in debian? [18:28] robru, no, I meant upstream trunk [18:29] doko: what? I went to the upstream homepages and they had nothing new? [18:29] robru, ohh, np VCS? [18:29] doko: not that I could see... [18:29] robru, yes, debian forwards would be ok, but you probably can't reproduce on these architectures [18:30] tbb and openvpn without VCS? can't believe that [18:30] doko: well I didn't look into openvdb that closely but tbb was definitely just tarballs on a website. no VCS I could find [18:32] doko: ah, openvdb does have a github [18:40] doko: actually wait, https://launchpadlibrarian.net/214176471/buildlog_ubuntu-wily-arm64.tbb_4.3~20150611-1~exp3_BUILDING.txt.gz this just says "build killed after 150 minutes of inactivity", could that not be a transient issue? retry the build maybe? [18:41] robru, could you check on the developer box first? [18:41] doko: sure [18:48] doko: ok, arm64 build started, apparently it takes 4 hours if successful though [18:51] doko: also for openvpn, v3.0.0 has never built on powerpc. last successful powerpc build was 2.3.0-2 [19:36] slangasek, time to force gcc-5 and gcc-defaults to -release? [19:36] doko: where did we get to with the analysis of the failures? [19:36] see the pad. it's kde only, one ada issue, nothing important [19:37] ok [19:37] then yes, let's [19:37] the ftbfs for main are fixed [19:38] doko: hint added [19:39] slangasek: Oh, good, "force" didn't mean what I feared it did. :) [19:39] infinity: acceleratin' that mass [19:40] slangasek: AKA, American sexy fun times? [19:40] infinity: you have a dirty mind [19:40] slangasek: Little bit. [19:44] doko, infinity: robru is looking at openvdb, which ftbfs on powerpc because it uses tbb which appears to be reinventing the wheel on atomics. What's the right way to do atomics in C++? [19:45] slangasek: Lemme see the failure? [19:45] infinity: https://launchpadlibrarian.net/214175949/buildlog_ubuntu-wily-powerpc.openvdb_3.0.0-3ubuntu3_BUILDING.txt.gz [19:45] slangasek: If it's *only* on ppc, they might be doing atomics correctly, but missing -latomic. [19:45] "incomplete type" suggests otherwise [19:46] /usr/include/tbb/atomic.h:220:34: error: 'tbb::internal::atomic_impl::my_storage' has incomplete type [19:48] slangasek, infinity: this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787084 [19:48] Debian bug 787084 in src:tbb "error: 'tbb::internal::atomic_impl::my_storage' has incomplete type" [Serious,Open] [19:48] Yeahp. With a patch, no less. [19:48] oh hey [19:49] "Here is a patch whic huse the gcc libatomic instead of [...]" there we go [19:49] oh, except that the maintainer claims it's applied in experimental [19:49] and that's the version we have synced, I think? [19:50] No. [19:50] We have unstable. [19:50] Oh, tbb. [19:50] tbb | 4.3~20150611-1~exp3 | wily-proposed/universe | source [19:50] yes [19:50] I'm looking at ... Yeah. [19:50] oh, hangon [19:50] So, there may still be a missing -latomic on top of this. [19:51] robru: what version of libtbb-dev was openvdb building /against/ ? [19:51] infinity: it's not a linker error [19:51] Get:161 http://ftpmaster.internal/ubuntu/ wily-proposed/universe libtbb-dev powerpc 4.3~20150611-1~exp3 [208 kB] [19:51] From the build log. [19:51] well phooey [19:52] slangasek: yeah, that [19:52] slangasek: I had that idea too, maybe it was an older version or something [19:52] but no [19:54] Oh. [19:55] This was definitely applied... Differently. [19:55] (said in a raiders of the lost ark voice) [19:56] Hrm. [19:56] oops, no, not that movie the other one [19:56] #if (TBB_USE_GCC_BUILTINS && __TBB_GCC_BUILTIN_ATOMICS_PRESENT) [19:56] #include "machine/gcc_generic.h" [19:56] So, maybe that's not actually working. [19:57] Last Crusade, that's what it's called [19:57] so, gcc regression? [19:58] Ah-ha. [19:58] No, stupid patch. [19:58] See debian/patches/ppc32_atomics.patch [19:58] Which should be dropped. And libtbb should just be linked with -latomic. [19:59] Maybe. [20:00] Yeah. [20:00] The atomic-rework patch explicitly fixes things to work with -latomic (ie: new style intrinsics), then the ppc patch disables it. :P [20:01] slangasek: Gimme a few minutes to play on a porter, and I'll have a fix on the way. [20:01] hah [20:01] infinity: or do you want to hand it off to robru? [20:01] infinity: but wait though. the latest changelog specifically says "restoring this patch because it never should have been dropped" [20:03] robru: Yes, because his atomic-rework failed on ppc32 because he didn't link with -latomic, and he misread that as "oh, this doesn't work on ppc, then" [20:03] infinity: alright, want me to make a debdiff with the patch dropped? [20:04] robru: If you want to figure out how to make it link correctly (and drop that patch) as learning exercise, go nuts. [20:04] robru: The linking bit is important, not just dropping the patch. :) [20:04] oh, well [20:04] slangasek: how hard is that? for somebody who's never written any C++ and would just be stabbing in the dark ^ [20:05] robru: library linkage is unrelated to writing C++ [20:05] so it should be a piece of cake ;) [20:05] Good: .depends ~ /libassimp3v5/ [20:05] Bad: .depends ~ /libassimp3/ [20:06] slangasek: ok well I'm also completely unfamliar with library linkage. [20:06] also bad: someone's regexp handling at 3 in the morning? [20:06] robru: now's a great time to learn :) [20:06] slangasek: ok can you point me at some documentation to get me started [20:06] ? [20:07] Documentation won't help you here, these are custom Makefiles, not something pleasant(?) like autoconf. [20:07] robru: 1) drop the patch that's identified as bad 2) test-build on powerpc 3) see where it's failing to build because underlinked 4) fix the necessary makefile [20:08] slangasek, gcc-5 in -release, plus 7 libs [20:08] \o/ [20:08] and so it begins [20:08] infinity: autoconf? pleasant? uh-huh. [20:09] wondering if we can force boost1.58 and icu as well [20:10] doko: so the tbb rebuild on arm64 is stuck in the same spot, darn [20:10] robru: Just adding -latomic to LIBS in build/linux.gcc.inc will probably do the trick. Maybe. [20:11] infinity: thanks [20:11] robru: If you have access to the ppc porter, that will help a bit. [20:11] doko: I think we want to wait and see what p-m returns for those libraries [20:11] sure [20:11] infinity: yeah, just looking now [20:11] but boost1.58 is all new, and icu changed the soname, so the old lib isn't removed [20:12] robru: Not that that was much of a learning exercise, since I can't leave well enough alone, but I got there by backtracking from the Makefile generating the library through to the Makefiles in build/ and then to the include bits. [20:12] k [20:12] doko: yes; but if that was all there was, p-m should have figured it out already on its own so I want to see why it refused before we use a hammer [20:12] robru: All untested. So please test a full build with testsuite. [20:13] robru: And then if you fix it, forward to Debian with a "well, actually..." explanation. [20:13] infinity: yep, just firing it up now [20:13] hmm, only 7 libraries? I just got 38 wily install notification mails [20:14] * infinity goes to fix North Korea. [20:14] infinity: now for that, you'll want a hammer [20:14] cyphermox: ignition-math2, I just noticed was never built on i386 so not a regression; did you see the same? [20:15] slangasek: Or just a tzdata update. That'll fix ALL their problems, right? [20:15] slangasek: I had not noticed [20:15] slangasek: in any case, I'm sending a patch to debian now [20:15] infinity: as long as their clocks match the reality and declare that they're in the stone age, all is good [20:15] it's not perfect, but it allows it to build on i386 [20:15] cyphermox: ok. taking it off the pad anyway [20:16] slangasek: Setting all their clocks back to 1950 would be a great idea. I wonder if we're popular enough there to cause an international incident. [20:17] slangasek, where do you get these emails? I only get those for my own uploads [20:18] doko: who do you think uploaded the libraries [20:18] :P [20:18] heh [20:18] and 38 was just the first batch, p-m appears to still be running [20:20] ... and firefox has developed an -latomic issue suddenly too. [20:20] Weird. [20:20] doko: oh, actually, so there was a pause but tbb build succeded on arm64. not sure if you want to retry the arm64 build or just wait for the new upload that fixes powerpc anyway [20:25] robru, given back. please check tomorrow [20:25] doko: thanks [20:32] infinity, could you update the buildd images? get gcc-4.9 removed, and 5 wouldn't need updates, speeding up the builds a bit [20:33] doko: Yup, I was waiting for it to migrate before I mangled them. [20:34] doko: Are you happy (enough) with this version of GCC until the transition is done? [20:34] I mean, barring critical bugs you didn't know about, of course. [20:34] Cause not updating it until post-transition would be a big help for speed. [20:34] yes, at least we didn't find any GCC issue, after the transition started [20:34] Alright, I'll do some refreshes shortly here. [20:37] robru: I'm guessing from this slow build that no one ever taught you about export DEB_BUILD_OPTIONS="parallel=$(nproc)" [20:49] robru: Shiny, looks like that worked. Score one for me for (educated-)random sed? [20:50] infinity: yeah lots of stuff nobody ever told me about ;-) [20:50] was also eating lunch [20:50] infinity: ok, want the debdiff? or did you grab it since you're snooping in my home dir anyway? ;-) [20:51] robru: Well, depends on who wants credit for the upload and who's forwarding the fix to Debian. ;) [20:51] infinity: seeing as I have no upload rights... [20:51] robru: Though, for paranoia's sake, I think I'll stage it in my devirt PPA and try rebuilding whatsit against it first. [20:51] infinity: fair enough [20:51] WHatever whatsit was. I already forgot. [20:51] open... something. [20:51] infinity: openvdb [20:52] infinity: anyway, tbb.debdiff is there for you [20:52] robru: Sure. If I was sponsoring this for you (and I can, if you want credit), I'd ask you to flesh out the headers on that patch to explain it a bit better. [20:53] infinity: I'm not particularly bothered about credit for something that you directly told me to do that I didn't really understand. [20:53] "Since gcc-4.9, the atomic intrinsics on some architectures (like powerpc) are split off into -latomic, so always attempt to link it." [20:54] robru: Hah. Well, maybe you undestand it a bit better with my above edit. :) [20:54] robru: I'll take this one from here, though, thanks for the test run. [20:54] infinity: thanks for the instructions ;-) [21:07] doko: update_output is updated, and shows that icu has tentacles into a lot of other stuff; doesn't look like the old and new are coinstallable [21:08] well, the library is, probably not the -dev package [21:08] the -dev package isn't causing 11000 binary packages to be uninstallable [21:09] infinity: can you refresh my memory on what's expected to happen here? Should p-m calculate installability assuming the NBS binaries stick around? [21:09] robru: Also, your debdiff missed running "update-maintainer" [21:10] slangasek: It calculates assuming they're removed. [21:10] infinity: probably because I don't know what that is [21:10] robru: It needs running whenever we introduce a delta on top of Debian. [21:11] infinity: k, thanks [21:13] first nbs removals ... [21:17] robru: And found another bug while I was in there. Whee. [21:18] infinity: good thing you're on it then [21:20] infinity: so; if it assumes the NBS removals, there's no way to get p-m to show us the results of a partial upgrade? [21:20] (like it does in Debian these days) [21:25] NBS? [21:25] not built from source (anymore) [21:28] slangasek: I'm not entirely sure what you mean by "show results of a partial upgrade". [21:29] slangasek: But, indeed, our britney carries a patch to do things the inverse of how Debian does them, because we're dealing with a partial suite, and they have a full suite. [21:30] infinity: doko has requested, and it makes sense, to have icu transition into wily and unblock a bunch of stuff because it *should* be a soft migration - the old library binary should be coinstallable [21:30] infinity: er, I don't see why partial suiteness implies forcing hard transitions [21:30] that is, forcing transitions to be hard [21:30] slangasek: So they require NBS removal in sid before something can migrate, which gives them a wholistic view, we have to pretend to do NBS removal in "testing" to get a similar consistent view. [21:31] hmm [21:31] right, so it's because we don't have the old binary packages in the partial suite, so can't just look at -proposed to decide whether a package is ready to migrate [21:31] Is it desperately difficult to just finish the icu transition? [21:32] infinity: 11,000 binary packages [21:32] the icu transition underlies half the other C++ libraries in the archive [21:32] Ahh, a drop in the bucket! [21:32] Yeah, icu is always large, I've done it before. [21:32] Though, it's rarely problematic on its own. [21:32] Tied up with a new g++, though. Ick. [21:33] so if we tried to force icu in via p-m, it would remove libicu42 from wily? [21:33] slangasek: So, if we're sure it's not problematic on its own, we can force icu through the pipe manually. [21:33] slangasek: No, it won't *actually* remove it. britney does no removals. The inst checker just *pretends* it's removing it. [21:34] infinity: I checked, libicu52 and libicu55 are coinstallable (at least on amd64, should be same for all archs) [21:34] slangasek: So, if we're sure it's good, we can manually copy it, and let it unwind itself on the next run. [21:34] infinity: ok, I think we ought to. can you poke that in this afternoon? [21:34] I can. [21:35] ta [21:36] It does mean that list of broken packages migrates from update_output to the NBS report instead, but as long as there's a commitment to follow up sooner rather than later, I don't think it's an actual problem. [21:36] Oh. [21:36] It might also make the uninstall count go up? [21:36] Depends on how stupid britney is. [21:36] Hopefully stupid enough that it doesn't. [21:37] If it counts NBS binaries in testing as still being available, we're fine. [21:37] If not, we'll break the whole world. [21:39] Perhaps I'll copy it and do a no-commit britney run afterward to make sure the world didn't explode. [21:39] But I think it's sufficiently unclever enough to not break. === g4mby is now known as PaulW2U [23:17] how do you tell if something is a regression on an arch vs if something was never supported on that arch? [23:31] robru: rmadison, see if binaries exist on the arch in question. [23:31] robru: Or check the previous version on LP for successful/failed builds. [23:32] Holy crap on a stick, tbb takes forever to build on arm64. [23:32] infinity: so if the latest version in the release pocket is failed, that's authoritative that the arch isn't supported? [23:32] I wonder what's up with that. [23:32] robru: Well, it's authoritative that it's not a regression against the release pocket. :P [23:32] heh [23:33] robru: When I'm touching a package for unrelated reasons, I tend to look at the arch FTBFSes anyway to see if it's trivial to fix in passing. [23:33] robru: But if it's not trivial, as long as it's not a regression, the status quo is fine. [23:33] infinity: just curious about this pymia/mia thing mentioned on the pad. it suggests to rebuild mia against vtk5 on armhf except as far as i can tell armhf was never supported so I have no idea why this is blocking anything [23:33] robru: Where is this magic pad people are working from? I'm out of touch with the transition so far. [23:34] infinity: http://pad.ubuntu.com/gcc-5-transition has a bunch of TODOs, I'm finding it hard to follow though [23:35] robru: Right, I see no pymia/mia on armhf at all, in any release, so that line can likely be deleted. [23:36] infinity: well I started a build with the suggested change, maybe let's see how it turns out first ;-) [23:37] robru: Having it have different deps on different arches sounds like more trouble than it's worth, IMO. [23:39] robru: And the fact that it's never built in the past makes it a bit of a "who cares". If we leave it as-is, it'll magically work if/when someone fixes vtk6. [23:39] fair point [23:39] I don't know who put it on the list in the first place [23:39] Probably someone who just looked at the missing build without checking history. [23:40] Oh. And vtk6 on armhf is the usual Glfloat/GLdouble GL/GLES madness. [23:40] That's fixable, if anyone cares. [23:41] yes, please don't make something like mia build-depend vtk5 on armhf [23:41] I also don't know why it ended up on the pad; someone must've been working from their build-failure email notifications as a todo list, instead of the trackers [23:42] Are we not yet at a point where we have a new enough OpenGL that we can just use GLES everywhere as a pure subset of GL and stop this insanity with different standards on different arches? [23:42] not sure what you mean by that [23:43] slangasek: So, the reason one used to have to choose A or B was that GLES was, annoyingly, not a pure subset of GL. It was mostly a subset, but also included some features GL didn't have. [23:43] I thought the library entry points, not to mention the OpenGL runtime "whoami?" insanity, were different between the two [23:43] slangasek: Newer versions of the GL/GLES standard have GLES as a pure subset (or GL as a pure superset, however you want to look at it), so one can, in theory, write all their stuff to target GLES, and make it work on both. [23:43] slangasek: But, yes, that probably still needs fixing in mesa with a hybrid loader or something to fix the final step, now that the standard makes it possible. [23:44] right, so that doesn't really help if you're using things like libGLU [23:44] I guess in theory you just have everything building against GL headers, and if it's smart it only uses a subset and then you're happy? [23:45] but currently the compiler is what you use to enforce the subsetness [23:45] Right. [23:45] Oh well. Maybe next decade. [23:45] Our (correct) choice to make ARM GLES in Ubuntu (deviating from Debian) has been no end of pain, though.