robruinfinity: do you want the list of regressions that actually correspond with the gcc5 upload?00:00
infinitySince the way we give gcc-5 a pass is to tell britney to ignore all gcc-5 related tests.00:00
infinityWhich I won't do until we're sure all the ones we care about are good.00:00
infinity(The other way is to ignore tests for specific packages, but that gives those regressions a pass, which we don't want)00:00
infinitySome of these might be flappy weirdness.00:01
* infinity retries a few.00:01
infinity... after I read pitti's mail about how to retry.00:02
slangasekis there a hand gesture to go with "flappy weirdness"?00:02
infinityslangasek: Imagine Kermit flailing.00:02
tdaitxdoko, should we create a bug report for LP: #1483403 in Debian as well?00:15
ubot93Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/148340300:15
cyphermoxso, where should I start to help with gcc5? I have the pad open but I'm not quite sure where to begin01:52
tdaitxcyphermox, still looking where to help on gcc5?02:33
tdaitxcyphermox, anyway, the stuff at the bottom is more recent, so you can start there02:56
tjaaltonI wonder if xcb-util could be dropped from NEW before we have a unwarranted diff against debian05:11
RAOFtjaalton: Pretty sure the answer is “yes, but I'm not meant to press that button”05:18
tjaaltonI'll wait for a reply first..05:18
tjaaltonfrom the uploader :)05:19
tjaaltonbefore doing anything myself05:19
tjaaltonthe only thing being reverting the change from the debian branch05:20
infinitytjaalton: What diff do we not want?05:33
tjaaltoninfinity: renaming libxcb-util05:33
tjaaltonwell, pkg-xorg doesn't wan't the transition on debian, because it's pointless05:34
infinitytjaalton: It's not renamed because the SOVER changed?05:34
tjaaltonthe sover has been like that for ages05:34
infinityI mean, 0 -> 1 seems pretty clear.05:34
tjaaltonor I'm completely wrong05:35
* infinity looks at actual contents.05:35
infinityYeah, it really did bump SOVER.05:35
* tjaalton woke up at 4am05:35
infinityNot renaming would be very wrong. :P05:35
infinityHah.  That's something you don't see every day.  kwayland-integration was FTBFS on everything except arm64.05:37
flexiondotorgLaney, who can help promote deja-dup-caja out of the NEW queue for wily/08:30
darkxstLaney, how often do the packageset scripts run?08:38
darkxst(for seeded stuff)08:38
Laneymanually, I run it once a week or so08:39
darkxstLaney, manually automatic ;) can you run it this week some time ? to pick up gnome-getting-started-docs08:41
Laneyit means that the sets aren't managed by hand08:42
Laneywill run it now if you want08:42
darkxstLaney, that would be good, images took a 120MB hit from seeding it08:43
darkxstthough that in itself its not a huge problem, at this point, but want to be able test langpacks are getting installed correctly before B1 hits08:45
Laneyneed to fix this script to not rsync ALL the dists/wily-*08:51
lamontI 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
lamontwhat's the next step for me here, really, oh mighty release gods?09:00
infinitylamont: precise seems a bit much.09:27
infinitylamont: But if it builds cleanly on a straight backport, meh.09:28
infinitylamont: 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:28
infinitylamont: 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:29
lamontinfinity: lts kernel on precise... :(09:34
lamontinfinity: ack09:34
tseliotinfinity: any updates on nvidia-352{-updates} ?11:31
slangaseksigh; jackd2 has a wrong symbols file (seemingly generated out of nowhere), so all the jackd2 rebuilds have to be redone14:21
slangasekoh, d-shlibs again.  thanks Jonas14:24
slangasekexcept... d-shlibs isn't used in the build either14:28
slangasekLaney: 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:34
Laneyslangasek: Indeed, I deployed a new version --- moderately confident? :)14:37
LaneyI fixed the problems I knew about and have verified some transitions today14:37
slangasekok so no symbols file in libjack-jackd2-0v5 at all, just a shlibs file and the shlibs file looks correct.  Brilliant14:57
LaneyGot an example of a bad package? Second pair of eyes might be helpful?14:58
slangasekLaney: every darn thing on http://people.canonical.com/~ubuntu-archive/transitions/html/jackd2-g++5.html14:59
slangasekI'm starting from the zynjacku end14:59
slangasekoh of course14:59
slangasekit pulled in libjack-dev instead of libjack-jackd2-dev at build time14:59
slangaseka) 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 bustificated15:00
slangasekdoko: how did you determine that jackd needed an ABI transition?15:01
dokoslangasek, https://people.debian.org/~doko/logs/gcc5-20150701/jackd2_1.9.10+20140719git3eb0ae6a~dfsg-2_unstable_gcc5.log15:03
* Laney cries at the libbpp stack15:28
slangasekdoko: 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 do15:37
slangasekesn't include libjacknet at all15:37
slangasekif nothing has noticed this, it's possible libjacknet is completely unused and we shouldn't do a package name change15:37
LaneyShould we start to see stuff migrating once it's ready?15:41
Laneymodulo gcc-5 itself15:41
slangasekLaney: probably small clusters only15:41
Laneyin theory though15:41
LaneyI like attacking things from the proposed-migration direction too15:42
Laneypick a package and drill down on it until it goes in15:42
slangasekdoko: 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 transition15:42
slangasekLaney: yes, you should be able to do that soon15:42
Laneynod, thanks15:42
cyphermoxdoko: are you aware of some change in our gcc5 that would affect floating point precision on i386?16:21
dokocyphermox, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  -> almost always bad code16:22
ubot93gcc.gnu.org bug 323 in middle-end "optimized code gives strange floating point results" [Normal,Suspended]16:22
cyphermoxfigured that's what you'd link me ;)16:22
dokoglad you found it on your own =)16:22
cyphermoxdoko: danke.16:23
slangasekI'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:24
dokonot me16:25
flocculantafternoon - 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 desktop16:31
dokoslangasek, ocaml packages could need some attention (e.g. liblastfm-ocaml-dev not installable) who did those in the past?16:32
slangasekdoko: I don't know16:32
Laneycjw I think did some16:33
Laneyit's the same as haskell - rebuild them in level order16:33
cyphermoxflocculant: I saw something like that related to compiz perhaps, but it depends16:49
cyphermoxflocculant: wily daily for xubuntu and ubuntu?16:49
flocculantcyphermox: so not compiz I would have to assume16:55
cyphermoxflocculant: if both try to log in and fail, falling back to the login prompt, then something is broken17:10
flocculantcyphermox: want some logs?17:10
cyphermoxI'd watch .xsession-errors carefully (or whatever gets written), to see where it breaks17:10
cyphermoxflocculant: check .xsession-errors and the logs in .cache/upstart/, like gnome-session.log or unity7.log17:12
cyphermoxI'll check in a bit17:12
flocculantcyphermox: logs http://pastebin.com/MnV18Csc17:39
=== jhodapp is now known as jhodapp|errand
robruanybody have any easy gcc5 stuff for a noob like me to poke at?17:58
dokorobru, https://launchpad.net/ubuntu/+source/openvdb/3.0.0-3ubuntu318:03
robrudoko: thanks18:04
dokorobru, there's also tbb ftbfs on arm6418:05
dokowould suggest to contact debian and/or upstream18:05
dokoor looking for patches upstream18:05
=== jhodapp|errand is now known as jhodapp
robrudoko: I don't see any new versions for tbb or openvdb either upstream or in debian18:27
robrudoko: do you want me to just file bugs in debian?18:28
dokorobru, no, I meant upstream trunk18:28
robrudoko: what? I went to the upstream homepages and they had nothing new?18:29
dokorobru, ohh, np VCS?18:29
robrudoko: not that I could see...18:29
dokorobru, yes, debian forwards would be ok, but you probably can't reproduce on these architectures18:29
dokotbb and openvpn without VCS? can't believe that18:30
robrudoko: well I didn't look into openvdb that closely but tbb was definitely just tarballs on a website. no VCS I could find18:30
robrudoko: ah, openvdb does have a github18:32
robrudoko: 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:40
dokorobru, could you check on the developer box first?18:41
robrudoko: sure18:41
robrudoko: ok, arm64 build started, apparently it takes 4 hours if successful though18:48
robrudoko: also for openvpn, v3.0.0 has never built on powerpc. last successful powerpc build was 2.3.0-218:51
dokoslangasek, time to force gcc-5 and gcc-defaults to -release?19:36
slangasekdoko: where did we get to with the analysis of the failures?19:36
dokosee the pad. it's kde only, one ada issue, nothing important19:36
slangasekthen yes, let's19:37
dokothe ftbfs for main are fixed19:37
slangasekdoko: hint added19:38
infinityslangasek: Oh, good, "force" didn't mean what I feared it did. :)19:39
slangasekinfinity: acceleratin' that mass19:39
infinityslangasek: AKA, American sexy fun times?19:40
slangasekinfinity: you have a dirty mind19:40
infinityslangasek: Little bit.19:40
slangasekdoko, 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:44
infinityslangasek: Lemme see the failure?19:45
slangasekinfinity: https://launchpadlibrarian.net/214175949/buildlog_ubuntu-wily-powerpc.openvdb_3.0.0-3ubuntu3_BUILDING.txt.gz19:45
infinityslangasek: If it's *only* on ppc, they might be doing atomics correctly, but missing -latomic.19:45
slangasek"incomplete type" suggests otherwise19:45
slangasek/usr/include/tbb/atomic.h:220:34: error: 'tbb::internal::atomic_impl<T>::my_storage' has incomplete type19:46
tdaitxslangasek, infinity: this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=78708419:48
ubot93Debian bug 787084 in src:tbb "error: 'tbb::internal::atomic_impl<T>::my_storage' has incomplete type" [Serious,Open]19:48
infinityYeahp.  With a patch, no less.19:48
slangasekoh hey19:48
slangasek"Here is a patch whic huse the gcc libatomic instead of [...]" there we go19:49
slangasekoh, except that the maintainer claims it's applied in experimental19:49
slangasekand that's the version we have synced, I think?19:49
infinityWe have unstable.19:50
infinityOh, tbb.19:50
slangasek tbb          | 4.3~20150611-1~exp3   | wily-proposed/universe | source19:50
infinityI'm looking at ... Yeah.19:50
slangasekoh, hangon19:50
infinitySo, there may still be a missing -latomic on top of this.19:50
slangasekrobru: what version of libtbb-dev was openvdb building /against/ ?19:51
slangasekinfinity: it's not a linker error19:51
infinityGet:161 http://ftpmaster.internal/ubuntu/ wily-proposed/universe libtbb-dev powerpc 4.3~20150611-1~exp3 [208 kB]19:51
infinityFrom the build log.19:51
slangasekwell phooey19:51
robruslangasek: yeah, that19:52
robruslangasek: I had that idea too, maybe it was an older version or something19:52
robrubut no19:52
infinityThis was definitely applied... Differently.19:55
slangasek(said in a raiders of the lost ark voice)19:55
slangasekoops, no, not that movie the other one19:56
infinity        #include "machine/gcc_generic.h"19:56
infinitySo, maybe that's not actually working.19:56
slangasekLast Crusade, that's what it's called19:57
slangasekso, gcc regression?19:57
infinityNo, stupid patch.19:58
infinitySee debian/patches/ppc32_atomics.patch19:58
infinityWhich should be dropped.  And libtbb should just be linked with -latomic.19:58
infinityThe atomic-rework patch explicitly fixes things to work with -latomic (ie: new style intrinsics), then the ppc patch disables it. :P20:00
infinityslangasek: Gimme a few minutes to play on a porter, and I'll have a fix on the way.20:01
slangasekinfinity: or do you want to hand it off to robru?20:01
robruinfinity: but wait though. the latest changelog specifically says "restoring this patch because it never should have been dropped"20:01
infinityrobru: 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
robruinfinity: alright, want me to make a debdiff with the patch dropped?20:03
infinityrobru: If you want to figure out how to make it link correctly (and drop that patch) as learning exercise, go nuts.20:04
infinityrobru: The linking bit is important, not just dropping the patch. :)20:04
robruoh, well20:04
robruslangasek: how hard is that? for somebody who's never written any C++ and would just be stabbing in the dark ^20:04
slangasekrobru: library linkage is unrelated to writing C++20:05
slangasekso it should be a piece of cake ;)20:05
slangasekGood: .depends ~ /libassimp3v5/20:05
slangasekBad: .depends ~ /libassimp3/20:05
robruslangasek: ok well I'm also completely unfamliar with library linkage.20:06
slangasekalso bad: someone's regexp handling at 3 in the morning?20:06
slangasekrobru: now's a great time to learn :)20:06
robruslangasek: ok can you point me at some documentation to get me started20:06
infinityDocumentation won't help you here, these are custom Makefiles, not something pleasant(?) like autoconf.20:07
slangasekrobru: 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 makefile20:07
dokoslangasek, gcc-5 in -release, plus 7 libs20:08
slangasekand so it begins20:08
robruinfinity: autoconf? pleasant? uh-huh.20:08
dokowondering if we can force boost1.58 and icu as well20:09
robrudoko: so the tbb rebuild on arm64 is stuck in the same spot, darn20:10
infinityrobru: Just adding -latomic to LIBS in build/linux.gcc.inc will probably do the trick.  Maybe.20:10
robruinfinity: thanks20:11
infinityrobru: If you have access to the ppc porter, that will help a bit.20:11
slangasekdoko: I think we want to wait and see what p-m returns for those libraries20:11
robruinfinity: yeah, just looking now20:11
dokobut boost1.58 is all new, and icu changed the soname, so the old lib isn't removed20:11
infinityrobru: 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
slangasekdoko: 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 hammer20:12
infinityrobru: All untested.  So please test a full build with testsuite.20:12
infinityrobru: And then if you fix it, forward to Debian with a "well, actually..." explanation.20:13
robruinfinity: yep, just firing it up now20:13
slangasekhmm, only 7 libraries? I just got 38 wily install notification mails20:13
* infinity goes to fix North Korea.20:14
slangasekinfinity: now for that, you'll want a hammer20:14
slangasekcyphermox: ignition-math2, I just noticed was never built on i386 so not a regression; did you see the same?20:14
infinityslangasek: Or just a tzdata update.  That'll fix ALL their problems, right?20:15
cyphermoxslangasek: I had not noticed20:15
cyphermoxslangasek: in any case, I'm sending a patch to debian now20:15
slangasekinfinity: as long as their clocks match the reality and declare that they're in the stone age, all is good20:15
cyphermoxit's not perfect, but it allows it to build on i38620:15
slangasekcyphermox: ok.  taking it off the pad anyway20:15
infinityslangasek: 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:16
dokoslangasek, where do you get these emails? I only get those for my own uploads20:17
slangasekdoko: who do you think uploaded the libraries20:18
slangasekand 38 was just the first batch, p-m appears to still be running20:18
infinity... and firefox has developed an -latomic issue suddenly too.20:20
robrudoko: 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 anyway20:20
dokorobru, given back. please check tomorrow20:25
robrudoko: thanks20:25
dokoinfinity, could you update the buildd images? get gcc-4.9 removed, and 5 wouldn't need updates, speeding up the builds a bit20:32
infinitydoko: Yup, I was waiting for it to migrate before I mangled them.20:33
infinitydoko: Are you happy (enough) with this version of GCC until the transition is done?20:34
infinityI mean, barring critical bugs you didn't know about, of course.20:34
infinityCause not updating it until post-transition would be a big help for speed.20:34
dokoyes, at least we didn't find any GCC issue, after the transition started20:34
infinityAlright, I'll do some refreshes shortly here.20:34
infinityrobru: I'm guessing from this slow build that no one ever taught you about export DEB_BUILD_OPTIONS="parallel=$(nproc)"20:37
infinityrobru: Shiny, looks like that worked.  Score one for me for (educated-)random sed?20:49
robruinfinity: yeah lots of stuff nobody ever told me about ;-)20:50
robruwas also eating lunch20:50
robruinfinity: ok, want the debdiff? or did you grab it since you're snooping in my home dir anyway? ;-)20:50
infinityrobru: Well, depends on who wants credit for the upload and who's forwarding the fix to Debian. ;)20:51
robruinfinity: seeing as I have no upload rights...20:51
infinityrobru: Though, for paranoia's sake, I think I'll stage it in my devirt PPA and try rebuilding whatsit against it first.20:51
robruinfinity: fair enough20:51
infinityWHatever whatsit was.  I already forgot.20:51
infinityopen... something.20:51
robruinfinity: openvdb20:51
robruinfinity: anyway, tbb.debdiff is there for you20:52
infinityrobru: 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:52
robruinfinity: I'm not particularly bothered about credit for something that you directly told me to do that I didn't really understand.20:53
infinity"Since gcc-4.9, the atomic intrinsics on some architectures (like powerpc) are split off into -latomic, so always attempt to link it."20:53
infinityrobru: Hah.  Well, maybe you undestand it a bit better with my above edit. :)20:54
infinityrobru: I'll take this one from here, though, thanks for the test run.20:54
robruinfinity: thanks for the instructions ;-)20:54
slangasekdoko: 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 coinstallable21:07
dokowell, the library is, probably not the -dev package21:08
slangasekthe -dev package isn't causing 11000 binary packages to be uninstallable21:08
slangasekinfinity: 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
infinityrobru: Also, your debdiff missed running "update-maintainer"21:09
infinityslangasek: It calculates assuming they're removed.21:10
robruinfinity: probably because I don't know what that is21:10
infinityrobru: It needs running whenever we introduce a delta on top of Debian.21:10
robruinfinity: k, thanks21:11
dokofirst nbs removals ...21:13
infinityrobru: And found another bug while I was in there.  Whee.21:17
robruinfinity: good thing you're on it then21:18
slangasekinfinity: 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
slangasek(like it does in Debian these days)21:20
dokonot built from source (anymore)21:25
infinityslangasek: I'm not entirely sure what you mean by "show results of a partial upgrade".21:28
infinityslangasek: 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:29
slangasekinfinity: 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 coinstallable21:30
slangasekinfinity: er, I don't see why partial suiteness implies forcing hard transitions21:30
slangasekthat is, forcing transitions to be hard21:30
infinityslangasek: 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:30
slangasekright, 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 migrate21:31
infinityIs it desperately difficult to just finish the icu transition?21:31
slangasekinfinity: 11,000 binary packages21:32
slangasekthe icu transition underlies half the other C++ libraries in the archive21:32
infinityAhh, a drop in the bucket!21:32
infinityYeah, icu is always large, I've done it before.21:32
infinityThough, it's rarely problematic on its own.21:32
infinityTied up with a new g++, though.  Ick.21:32
slangasekso if we tried to force icu in via p-m, it would remove libicu42 from wily?21:33
infinityslangasek: So, if we're sure it's not problematic on its own, we can force icu through the pipe manually.21:33
infinityslangasek: No, it won't *actually* remove it.  britney does no removals.  The inst checker just *pretends* it's removing it.21:33
slangasekinfinity: I checked, libicu52 and libicu55 are coinstallable (at least on amd64, should be same for all archs)21:34
infinityslangasek: So, if we're sure it's good, we can manually copy it, and let it unwind itself on the next run.21:34
slangasekinfinity: ok, I think we ought to. can you poke that in this afternoon?21:34
infinityI can.21:34
infinityIt 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
infinityIt might also make the uninstall count go up?21:36
infinityDepends on how stupid britney is.21:36
infinityHopefully stupid enough that it doesn't.21:36
infinityIf it counts NBS binaries in testing as still being available, we're fine.21:37
infinityIf not, we'll break the whole world.21:37
infinityPerhaps I'll copy it and do a no-commit britney run afterward to make sure the world didn't explode.21:39
infinityBut I think it's sufficiently unclever enough to not break.21:39
=== g4mby is now known as PaulW2U
robruhow do you tell if something is a regression on an arch vs if something was never supported on that arch?23:17
infinityrobru: rmadison, see if binaries exist on the arch in question.23:31
infinityrobru: Or check the previous version on LP for successful/failed builds.23:31
infinityHoly crap on a stick, tbb takes forever to build on arm64.23:32
robruinfinity: so if the latest version in the release pocket is failed, that's authoritative that the arch isn't supported?23:32
infinityI wonder what's up with that.23:32
infinityrobru: Well, it's authoritative that it's not a regression against the release pocket. :P23:32
infinityrobru: 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
infinityrobru: But if it's not trivial, as long as it's not a regression, the status quo is fine.23:33
robruinfinity: 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 anything23:33
infinityrobru: Where is this magic pad people are working from?  I'm out of touch with the transition so far.23:33
robruinfinity: http://pad.ubuntu.com/gcc-5-transition has a bunch of TODOs, I'm finding it hard to follow though23:34
infinityrobru: Right, I see no pymia/mia on armhf at all, in any release, so that line can likely be deleted.23:35
robruinfinity: well I started a build with the suggested change, maybe let's see how it turns out first ;-)23:36
infinityrobru: Having it have different deps on different arches sounds like more trouble than it's worth, IMO.23:37
infinityrobru: 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
robrufair point23:39
robruI don't  know who put it on the list in the first place23:39
infinityProbably someone who just looked at the missing build without checking history.23:39
infinityOh.  And vtk6 on armhf is the usual Glfloat/GLdouble GL/GLES madness.23:40
infinityThat's fixable, if anyone cares.23:40
slangasekyes, please don't make something like mia build-depend vtk5 on armhf23:41
slangasekI 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 trackers23:41
infinityAre 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
slangaseknot sure what you mean by that23:42
infinityslangasek: 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
slangasekI thought the library entry points, not to mention the OpenGL runtime "whoami?" insanity, were different between the two23:43
infinityslangasek: 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
infinityslangasek: 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:43
slangasekright, so that doesn't really help if you're using things like libGLU23:44
slangasekI 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:44
slangasekbut currently the compiler is what you use to enforce the subsetness23:45
infinityOh well.  Maybe next decade.23:45
infinityOur (correct) choice to make ARM GLES in Ubuntu (deviating from Debian) has been no end of pain, though.23:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!