| robru | soooo anybody know anything about opencsg? apparently qmake is bringing in gles on armhf but the source isn't compatible with gles at all. | 02:53 |
|---|---|---|
| === med_ is now known as Guest471 | ||
| darkxst | can I get gnome-online-accounts 3.16 removed from wily-proposed, doesnt look like we can get around webkit2 requirements | 06:24 |
| darkxst | bug 1466245 | 06:25 |
| ubot93 | bug 1466245 in gnome-control-center (Ubuntu) "Update to 3.16" [Wishlist,Triaged] https://launchpad.net/bugs/1466245 | 06:25 |
| darkxst | ah no its bug 1466290 | 06:25 |
| ubot93 | bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New] https://launchpad.net/bugs/1466290 | 06:25 |
| darkxst | infinity, didrocks ^ | 06:56 |
| didrocks | hum, I guess we will need to blacklist it to not get it synced back. I'm unsure what's the procedure to blacklist only for one release? (as we copy the black list to the next release) | 07:01 |
| didrocks | I guess infinity already got this case | 07:01 |
| darkxst | didrocks, yeh it will need blacklisting | 07:09 |
| didrocks | darkxst: I just don't want to blacklist it and forget about it later on (and so, will be blacklisted in next release), so that's why I wonder if there is a special section for this | 07:11 |
| darkxst | ok | 07:11 |
| darkxst | it would sometimes be nice if the sync-er ignored packages that are just going to depwait! | 07:13 |
| didrocks | darkxst: it's slightly more complicated I guess, because the new versionned dep-wait can be into that transaction | 07:15 |
| === med_ is now known as Guest61394 | ||
| didrocks | doable, but not trivial :) | 07:15 |
| didrocks | (especially as we don't know about the dep-wait without having a build running IIRC) | 07:16 |
| darkxst | yeh, and its probably only a few packages each cycle that get hit, so not worth the effort | 07:18 |
| darkxst | didrocks, also can you look at the gnome-getting-started-docs langpack split in new, would be nice to get the the 120MB monster package, off our dailies for the next build, so I can get people testing it;) | 07:21 |
| didrocks | darkxst: will probably after finishing the morning duties (so at my start of afternoon). Opening a tab with it :) | 07:23 |
| darkxst | didrocks, ok, thanks! | 07:27 |
| didrocks | darkxst: no worry, I just gave a first quick look, sounds good. Quite impressed they are shipping localized webm videos as well, do you know what tool did they use to create those animations? | 07:28 |
| didrocks | (as it's a space where we don't have really good tools) | 07:28 |
| darkxst | didrocks, no idea, but wonder if its somewhat not automated, since only 5-6 out of 30 locales have them | 07:29 |
| darkxst | where as all have localised svg's | 07:30 |
| didrocks | oh, so yeah, maybe they are svg with placeholders | 07:31 |
| didrocks | not sure, you can't rely on this | 07:31 |
| didrocks | so yeah, ok, I'll maybe poke upstream at some point | 07:32 |
| darkxst | didrocks, yeh, Ive not looked into the details at how they are generated, but they seem to have a bunch of python scripts that generate them, https://git.gnome.org/browse/gnome-getting-started-docs/tree/animation?id=8ad76711dbc4b895efa1cdea62fc06c1cff68fea | 07:38 |
| didrocks | darkxst: ok, seems they match that with some blender magic and spits out the webm, interesting… | 07:45 |
| didrocks | darkxst: while I was at it, I finished the review, NEWed | 07:45 |
| darkxst | didrocks, thanks | 07:51 |
| didrocks | yw | 07:53 |
| === kickinz1 is now known as kickinz1|lunch | ||
| === kickinz1|lunch is now known as kickinz1 | ||
| === didrocks1 is now known as didrocks | ||
| slangasek | Laney: so there are a lot of autohints in update_output right now that are all failing. Do you have the big picture view of what needs to happen to unblock the big mass? | 15:44 |
| cyphermox | slangasek: should we do a respin of one image once syslinux lands? | 15:44 |
| slangasek | cyphermox: yes | 15:44 |
| cyphermox | slangasek: I'm saying this because I don't think I have access to trigger that :) | 15:45 |
| cyphermox | it's still going to be a bit though, it's building right now | 15:45 |
| Laney | slangasek: No, I occasionally have a small view into it though | 15:45 |
| slangasek | cyphermox: maybe you do via the iso tracker, I'm not sure? but yes, when it's built let us know and we'll get it respun | 15:45 |
| Laney | Give me two minutes and I'll share my script so you can all be as clueful as me | 15:45 |
| cyphermox | slangasek: I only have access to trigger touch builds, I'm not in the cdimage team or whichever is used to respin isos | 15:47 |
| slangasek | Laney: well I've at least managed to find the two 700+ package easy hints; I wonder how much overlap there is between those | 15:51 |
| slangasek | in fact the two 700+ package easy hints differ by 16 packages | 15:56 |
| Laney | slangasek: https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/+merge/267970 | 15:59 |
| slangasek | Laney: ok | 16:02 |
| slangasek | fwiw I've just looked at double-conversion, which was notable in the list because one of the autohints tried it and one didn't; looks like qtdeclarative-opensource-src is the blocker there | 16:03 |
| Laney | I tried to fix kdeclarative | 16:04 |
| Laney | ah man, one of the upstream tests is failing too | 16:04 |
| slangasek | what's the nature of the kdeclarative failure? | 16:05 |
| slangasek | the autopkgtest log isn't very scannable :/ | 16:06 |
| Laney | look for "FAIL non-zero exit status" | 16:06 |
| slangasek | thank | 16:06 |
| slangasek | s | 16:06 |
| Laney | hopefully just a missing dep | 16:07 |
| slangasek | claims QtQuick is not installed, but qml-module-qtquick2 is in the log | 16:08 |
| Laney | it's not in the test-deps of "testsuite" | 16:15 |
| * Laney ponders on @ vs. qml-module-qtquick2 | 16:16 | |
| * Laney starts documenting blockers for this transition | 16:29 | |
| Laney | too much k and q | 16:31 |
| jdstrand | slangasek: hey, it seems today's wily i386 livecd doesn't get past ISOLINUX in kvm. is this known? if so, do you know when the last usable wily i386 was? | 17:05 |
| slangasek | jdstrand: yesterday's was usable; syslinux built with gcc5 is broken, we're working on getting a new image built with a gcc-4.9 syslinux | 17:05 |
| jdstrand | ok, great. thanks! | 17:05 |
| * jdstrand confirms that http://cdimage.ubuntu.com/daily-live/20150812/wily-desktop-amd64.iso appears to work | 17:11 | |
| jdstrand | slangasek: thanks again | 17:11 |
| slangasek | jdstrand: sure thing | 17:13 |
| slangasek | and syslinux 3:6.03+dfsg-8ubuntu1 is built/published, so I'll trigger an image respin now ( cyphermox davmor2 ) | 17:14 |
| slangasek | only triggering for ubuntu at the moment, but if any other flavors are blocked and need a respin let me know (or use that handy dandy iso tracker) | 17:15 |
| cyphermox | slangasek: thanks. | 17:44 |
| cyphermox | slangasek: apparently not any better sadly :( | 18:07 |
| cyphermox | ah, I see, we're still picking up lots from 5.2.1 | 18:10 |
| slangasek | cyphermox: picking up lots of what? | 18:32 |
| slangasek | is it linking in libgcc? | 18:32 |
| cyphermox | slangasek: I see a bunch of libraries coming from libgcc 5.2.1 | 18:33 |
| cyphermox | yes | 18:33 |
| slangasek | hmm ok | 18:33 |
| cyphermox | I'll just try the patch that's included, despite it not being blessed upstream | 18:33 |
| cyphermox | it seems to work for redhat if I read the bug report properly | 18:33 |
| robru | anybody know anything about qmake pulling in gles on armhf? I'm working on opencsg and it has seemingly no gles support but it's being pulled in somehow and ftbfs | 18:42 |
| infinity | robru: ARM has defaulted to GLES instead of GL pretty much since we did the first armel port. It's more surprising that that package hasn't tripped over it until now. | 18:46 |
| robru | infinity: seems it's a case of new upstream changes? wily release version is 1.3 and built on armhf, proposed has 1.4 and failed. the error message looks a lot like it's trying to mix GL and GLES in bad ways | 18:47 |
| robru | infinity: it's using qmake which tries to pull gles in automatically, but it seems like most of the code just has GL hard-coded and has no real support for GLES | 18:47 |
| robru | infinity: like, the code has references to "experimental GLES" that's commented out. | 18:48 |
| robru | infinity: and uncommenting it doesn't build successfully ;-) | 18:48 |
| wxl | hey folks problems with our alternates building today http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/wily/daily-20150813.log | 19:05 |
| wxl | seems like some seed is missing? | 19:05 |
| ianorlin | it looks like the import of the packages it should have fails in bzr looking at the log | 19:05 |
| wxl | near the bottom gpg issues too | 19:06 |
| infinity | wxl: Probably just need to mangle some priorities. Will fix. | 19:12 |
| wxl | thx infinity | 19:17 |
| robru | Laney: any thoughts on opencsg gles on armhf issue? | 19:32 |
| slangasek | infinity: so the package in question (opencsg) basically bundles glew from what I can see, which isn't going to work with GLESv2 AFAIK | 19:47 |
| slangasek | infinity: and the reason it pulls in GLESv2 is that it asks qmake for 'opengl' and this is the answer it gets | 19:47 |
| slangasek | so the first offense of course is using qmake | 19:47 |
| infinity | slangasek: Right, the second bit is well known, but the bundling of glew seems wrong... | 19:47 |
| slangasek | but I wonder how we could fix this | 19:47 |
| infinity | slangasek: The old version build-depped on glew, so I assume this bundling is a new offense. | 19:48 |
| infinity | The new one build-deps on glew too... | 19:49 |
| slangasek | robru: ^^ can you investigate why opencsg is now bundling glew? (if there's upstream history or Debian bugs that explain) | 19:49 |
| slangasek | robru: it's possible that a distro patch to replace the 'CONFIG += opengl' with 'LIBS += -lGLEW -lGL' would be enough to fix this here | 19:50 |
| robru | hmm | 19:50 |
| slangasek | robru: and if you exhaust those options, I'm fine with punting this one to the corner; there are other higher-priority issues that will need looked at, e.g. the "failing tests that need resolving" listed on the pad as blockers | 19:52 |
| robru | ok | 19:52 |
| robru | LOL http://opencsg.org/ their latest release is from 2014 but this website is straight outta 1993. | 19:53 |
| robru | "The archive contains all required helper libraries, i.e., also RenderTexture and GLEW." I'm not seeing a changelog suggesting that's new though | 19:56 |
| robru | v1.3 definitely had glew bundled as well | 19:57 |
| infinity | So, the bundling could be a red herring. Or it could be that we accidentally started using the bundled version when we didn't before. | 19:59 |
| robru | infinity: slangasek: clue? http://anonscm.debian.org/cgit/collab-maint/opencsg.git/commit/?id=6f46d2e0f28ed4ffa9b72b5bcfa68e0f643a4264 | 20:01 |
| infinity | robru: Now if only that changelog entry related to a code change... | 20:02 |
| robru | yeah I'm poking around a bit... | 20:03 |
| infinity | ---- opencsg-1.3.2.orig/Makefile | 20:05 |
| infinity | -+++ opencsg-1.3.2/Makefile | 20:05 |
| infinity | -@@ -1,4 +1,4 @@ | 20:05 |
| infinity | --SUBDIRS = glew src example | 20:05 |
| infinity | -+SUBDIRS = src example | 20:05 |
| infinity | - | 20:05 |
| infinity | Etc. | 20:05 |
| infinity | Check the debian-changes patch from the previous version. | 20:06 |
| infinity | Entirely possible none of that applied to the new version, hence they dropped it, but it might still be relevant in spirit and someone oopsed. | 20:06 |
| infinity | robru: If the above was gibberish, just debdiff 1.3.2 and 1.4.0, search for 'debian-changes', and go "oh, look at that". | 20:13 |
| robru | infinity: it took me a bit but I realized you were talking about the distropatch from 1.3, I see it now | 20:14 |
| infinity | robru: The maintainer was (a) disabling the bundled glew build, and (b) changing the link line to link slightly different sets of GLish libs. | 20:14 |
| robru | infinity: http://paste.ubuntu.com/12074203/ ok here's a diff of the patch. new version looks kinda fluffy (eg almost exclusively patching html files, no meat) | 20:18 |
| robru | infinity: so you're saying I should resurrect the old bits and try building with that? | 20:18 |
| robru | infinity: this isn't making a lot of sense, the Makefile in the new version no longer references glew at all, no SUBDIRS variable either. | 20:22 |
| infinity | robru: Right, the upstream build system no doubt changes substantially, leading the maintainer whose patch no longer applied to believe it was also no longer needed. | 20:23 |
| infinity | robru: s/changes/changed/ | 20:23 |
| infinity | A fine argument for the patch having been written in an upstreamable way, adding a "--no-bundled-glew-you-twits" flag to the build system, so they could wash their hands of it and not mess up on rebase. | 20:24 |
| infinity | But oh well. We're all guilty of not upstreaming as much as we should. | 20:24 |
| robru | right | 20:24 |
| robru | infinity: I guess what it comes down to is that I don't understand the new build system well enough to be able to identify how to disable building the bundled glew | 20:25 |
| robru | infinity: also that debian changelog entry seemed to imply the bundled glew wasn't building... | 20:25 |
| infinity | robru: Fair enough. As our glorious leader pointed out, there are more important things to bang your head on anyway. | 20:26 |
| robru | ok | 20:26 |
| robru | I'll grab lunch and start fresh on something else then | 20:26 |
| slangasek | the list of outstanding transitions is now fairly short and this makes me suspicious | 20:38 |
| slangasek | I wonder if there are a bunch of boost revdeps tied up in the transition knot | 20:39 |
| infinity | slangasek: You guys have put in a ton of hours on this, maybe you actually just made progress? | 20:39 |
| infinity | Look at me and all my optimism. | 20:39 |
| slangasek | infinity: it's a shorter list of edge things than I would expect given that the transition hasn't yet gone through :) | 20:39 |
| cyphermox | infinity: slangasek: could one of you please respin Ubuntu desktop wily once more? | 20:47 |
| * cyphermox will need to go buy a bunch of new USB keys tonight or so | 20:47 | |
| infinity | cyphermox: Sure. | 20:50 |
| === Guest61394 is now known as med_ | ||
| robru | slangasek: alright, thoughts on what should look at next? | 21:03 |
| cyphermox | ah, the livefs got broken because of the bluetooth transition :/ | 21:11 |
| bdmurray | infinity: could you do some -proposed cleanup? | 21:38 |
| robru | sweet, upstream success https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795144 | 21:40 |
| ubot93 | Debian bug 795144 in clementine "clementine: Fix FTBFS with qt4 moc & boost includes." [Important,Fixed] | 21:41 |
| infinity | bdmurray: Yup. | 21:52 |
| infinity | bdmurray: Done. | 21:52 |
| bdmurray | Thanks | 21:52 |
| slangasek | robru: anything listed under 'blockers'... | 21:59 |
| robru | slangasek: ok so randomly I'm looking at python-launchpadlib. Why does the excuses page say "regression" when clicking through to the log doesn't show any ever passing? | 22:03 |
| robru | slangasek: eg here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#simplejson | 22:03 |
| infinity | robru: Because this new infrastructure didn't import logs of old jenkins runs, but it did import state. | 22:06 |
| robru | ah | 22:06 |
| infinity | I suppose faking up old runs and importing logs might not be the worst idea, but scraping that all from jenkins would suck. | 22:07 |
| doko | slangasek, infinity: unrelated: what's holding up valgrind for trusty? | 22:22 |
| doko | and I'm unsure about the state of python3.4 | 22:22 |
| infinity | doko: See the bug, arges commented on it. | 22:25 |
| infinity | doko: Short story, backporting from the devel series for SRUs is generally frowned upon, but if that's the best option, please also update vivid to match. | 22:25 |
| doko | infinity, bug number? | 22:26 |
| infinity | doko: I'll go a bit further though, and say is there a test plan to validate this? Some things build-dep on valgrind for testsuites and such. A 5MB diff is, obviously impossible to audit. | 22:26 |
| infinity | doko: https://bugs.launchpad.net/ubuntu/trusty/+source/valgrind/+bug/1386524 | 22:26 |
| ubot93 | Launchpad bug 1386524 in valgrind (Ubuntu Trusty) "Update Ubuntu 14.04 with full Valgrind LE support." [Medium,Confirmed] | 22:26 |
| doko | ta | 22:27 |
| doko | infinity, honestly, I think valgrind isn't good enough for these things. we should find out how to use the sanitizers for that | 22:27 |
| infinity | doko: Perhaps, but that's not an answer for SRUs. :) | 22:28 |
| infinity | doko: At least, a PPA test of $(reverse-depends -r trusty -b src:valgrind) should be done, and we also need some what to know that $(reverse-depends -r trusty src:valgrind) don't break. | 22:29 |
| doko | infinity, I thought you were supposed to care about the ppc64el issues ... | 22:29 |
| infinity | doko: I care about ppc64el, but oddly enough, not at the expense of other arches. | 22:30 |
| infinity | doko: "valgrind sucks on ppc64el" is no excuse to shove in a new version without testing it doesn't break everything else. | 22:30 |
| infinity | Anyhow, commented on the bug. | 22:31 |
| infinity | doko: The upshot here is that this isn't a mass rebuild or something, it's dumping 20ish sources in a PPA and seeing how they do. | 22:31 |
| infinity | doko: The downside is testing the runtime rdeps, which aren't many, but I'm not sure how best to make sure they "don't break". | 22:32 |
| doko | infinity, can you do that? | 22:32 |
| infinity | doko: I can certainly do the "dump some stuff in a PPA" bit, sure. | 22:32 |
| infinity | doko: I'm less likely to agree to take ownership of it if any of them break. ;) | 22:33 |
| doko | thanks | 22:33 |
| doko | well, show me the results, and we'll see | 22:34 |
| infinity | doko: Give us a vivid upload to match (or backport the vivid one instead, if the wily one isn't actually needed), and I can set up the test PPAs. I'll do it under toolchain-r, so you have access to them too. | 22:36 |
| doko | toolchain-r/test please | 22:38 |
| doko | infinity, please take the one proposed for trusty and rebuild it | 22:38 |
| infinity | doko: I was going to just create a new PPA, they're cheap. | 22:38 |
| doko | or that | 22:38 |
| robru | hey xnox, when you get a chance can you do a release for lp:launchpadlib? looks like trunk has a fix for the latest autopkgtest failures that are blocking some things in proposed. | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!