[00:14] <ScottK> Meh.  autopkgtest for python-qt4 4.10.2-1ubuntu1: RUNNING
[00:15] <cjwatson> Hm, yeah, it would, I suppose.  It might be quick enough that the run I'm doing now will pick it up ...
[00:15] <cjwatson> The hint was typoed so it wouldn't have gone through in that run in any event
[00:15] <cjwatson> Last run was 12 minutes.  Maybe.
[00:16] <ScottK> Thanks for fixing.
[00:17] <cjwatson> Still running.  I'll go and make my son's lunch for tomorrow and then see ...
[00:24] <cjwatson> It's done now.  I just missed it last time
[00:24]  * cjwatson reruns
[00:25] <cjwatson> Might squeeze it in before the next publisher run if I'm lucky
[00:30] <cjwatson> ScottK: final: avogadro,calibre,pykde4,pyqwt3d,pyqwt5,python-poppler-qt4,python-qt4,qscintilla2,sip4,veusz
[00:30] <cjwatson> phew
[00:30] <ScottK> Thanks for the help.
[00:33]  * cjwatson -> bed
[00:34] <ScottK> Good night.
[03:24] <TheMuso> @pilot out
[03:56] <pitti> Good morning
[04:15] <pitti> Laney: why is there a block on gucharmap?
[04:16] <pitti> Laney: the MIR was resolved, so it built fine now
[05:57] <ScottK> There's a block on a lot of stuff for Alpha 1.  It's not that, is it?
[05:58] <pitti> ScottK: oh, could be, yes
[06:08] <tvoss> ScottK, ping
[06:29] <dholbach> good morning
[06:40] <ScottK> tvoss: Hello
[06:48] <ScottK> tvoss: Missed your chance.  I'm going to bed.
[07:47] <darkxst> cjwatson, the syslinux splash on ubuntu GNOME images is a bit broken, do you know where that is configured?
[07:49] <darkxst> cjwatson, we only get the text based screen, and the language selector is active (like F2 had been pressed)
[07:50] <pitti> I thought the latter was deliberate
[07:51] <pitti> to avoid having to present English text to find out how to set the language
[07:51] <darkxst> pitti, ok, but there is still the first issue why we only get text-based splash
[07:52] <pitti> right
[07:52] <darkxst> I believe that was the case for raring images also ;(
[09:07] <Noskcaj> roaksoax: This is your daily reminder to allocate a day to testdrive
[09:16] <doko> didrocks: why is google-mock shipping a shared libgmock which has references to a shared libgtest, which is never shipped?
[09:18] <didrocks> doko: yeah, I realized that when looking at the package the other day and I think we inherited that from debian
[09:18] <xnox> doko: because google-mock shouldn't ship any shared libraries, but it's a mini transition where we need to fix r-build-deps first to use shared google-mock src code shipped by the package & then sync from debian.
[09:18] <xnox> e.g. unity ;-)
[09:19]  * xnox thinks there was a tracking bug about that.
[09:19] <xnox> bug 1185265
[09:23] <doko> didrocks, xnox: hmm, so the ftbfs should go away when merging the package from debian.
[09:24] <didrocks> doko: I don't think so, I tried to build it with the same FTBFS
[09:24] <didrocks> we inherited the issue from them, as told
[09:24] <doko> didrocks, but then why ship a shared libgmock?
[09:26] <xnox> building debian package I get undefined reference to pthreads.... despite -pthreads present on cmd line.
[09:26] <didrocks> doko: I don't think that the shared libgmock is linked to the FTBFS, did you try building the debian source? I did and same issue
[09:26] <didrocks> the one that xnox is telling ^
[09:27] <doko> didrocks, the ftbfs goes away if you explicitly link against -lpthread
[09:28] <doko> but then dpkg-shlibdeps complains about unresolved references, so this shipped libgmock can never properly work
[09:29] <didrocks> doko: please feel free to sync from debian and add that, I tried adding -lpthread without any success here
[09:29] <doko> didrocks, did you check that it is ok to discard the ubuntu changes?
[09:30] <didrocks> doko: I'm fine with it for the unity side, I'll fix those packages so that we build our own google-mock
[09:30] <didrocks> (the ones we are upstream for anyway)
[09:30] <bdrung> ScottK: the correct target is pbuilder-dist in this case, but love letters are accepted, too. ;)
[09:38] <doko> didrocks, http://people.canonical.com/~doko/tmp/ not uploading, so you can coordinate with the rest
[09:39] <didrocks> doko: ah, thanks a lot! will handle that this week :)
[09:39] <doko> didrocks, so the proper fix seems to be to that the package respects --enable-external-gtest and doesn't build it again
[09:40] <doko> which it apparently doesn't do
[09:40] <didrocks> yep
[09:44] <doko> tvoss tries to escape me ...
[09:47] <doko> ScottK, kde4libs explicitly b-d's on gcc-4.7. why?
[09:48] <doko> ahh, infinity made a "fix"
[09:48] <Laney> doko: Check out the previous build logs on armhf.
[09:48] <xnox> doko: on armhf, if FTBFS otherwise, compiler ice.
[09:48] <xnox> doko: yeap.
[09:48] <Laney> "This bug is not reproducible" thing which was reproducible...
[09:48] <Laney> not sure if anyone reported it on gcc though
[09:48] <xnox> i didn't yet. was on my todo list......
[10:19] <ScottK> doko: I filed Bug #1194501  to keep track of this.
[10:31] <OdyX> tkamppeter: saw it, cool. Does cups still build with these ?
[10:38] <doko> ScottK, how do you restart the kde4libs build?
[10:38] <ScottK> doko: Before that build was superseded I just hit the retry button in launchpad.
[10:38] <ScottK> All the build logs are from the same upload.
[10:39] <doko> ScottK, how do you restart a failed kde4libs build, without re-configuring
[10:39] <ScottK> Ah.  I see.
[10:39] <ScottK> I'm pretty sure passing -nc to dpkg-buildpackage is enough.
[10:40] <ScottK> Sorry, /me had < 3 hours sleep the last three nights in a row, so I'm likely not fully coherent.
[10:44] <tkamppeter> OdyX, CUPS should build without cups-filters and its build process should not depend on changes in cups-filters.
[10:48] <OdyX> tkamppeter: hmmm. It doesn't. I had to add cups-filters to build-depends to get the test-suite to complete.
[11:02] <cjwatson> darkxst: OK, if nobody else looked while I was offline, I guess I'll need to grab an image to look
[11:09] <tvoss_> ScottK, ping
[11:09] <tvoss_> ScottK, succeeded in installing kubuntu-desktop after manually install kde-workspace
[11:10] <ScottK> OK.  I'll be offline for the day in ~a minute.  Please chat with Riddell.
[11:12] <tvoss_> ScottK, ack and thx
[12:05] <zyga> jcastro: hey, I must say I'm really interested in the juju + openstack virtual thing that one can deploy on a laptop
[12:05] <zyga> jcastro: do you have any details on how that work, you've mentioned a blog
[12:14] <pitti> fginther: good morning
[12:14] <pitti> fginther: I think I bent the ap-gtk tests to my will now
[12:19] <pitti> fginther: so if I can bother you to re-review? after that lands, I can create three MPs for three bug fixes, but they all add/change tests
[12:28] <jcastro> zyga: http://javacruft.wordpress.com/2013/06/25/virtme/
[12:32] <zyga> thanks
[13:06] <jml> was just asking a question on behalf of an acquaintance on #ubuntu [http://askubuntu.com/questions/312927/booting-13-04-64-bit-pendrive-in-uefi-freezes-immediately-after-loading-ramdisk]. surprised there's so few devs there.
[13:13] <yolanda> hi, i'm just going to work in the ipxe FTBFS
[13:17] <tkamppeter> OdyX, this is really strange, "make test" should only test the source package itself and not require anything which is not needed for building the package. To build and test CUPS from scratch a user has to configure make, and install CUPS to be able to build cups-filters, then he has to configure, make, and install cups-filters to be able to test cups. I would consider this as a bug in CUPS upstream. "make test" should be independent
[13:17] <tkamppeter>  of cups-filters. Also if "make test" of CUPS fails we should be sure that we have to fix CUPS and not cups-filters.
[13:18] <OdyX> tkamppeter: I can't disagree. In my case I couldn't get the cups testsuite to run without cups-filters.
[13:21] <tkamppeter> OdyX, can you report this to Mike? Thanks.
[13:25] <OdyX> tkamppeter: Hrm. I can do, but I need to test all our patches to see which one breaks what.
[13:45] <jbicha> barry: I updated bug 1194526 with a new debdiff if you want to re-sponsor to fix the ftbfs
[13:46] <barry> jbicha: thanks.  i have some meetings coming up, but will take a look this afternoon
[13:46] <jbicha> barry: thanks
[14:18] <cjwatson> darkxst: so, I'm not sure what you mean about only getting the text-based screen - do you mean that you want the same kind of behaviour that's in Ubuntu where you just get an icon until you press a key?
[14:55] <OdyX> tkamppeter: http://alioth.debian.org/~odyx-guest/cups-str-1.6-2013-06-26-didier.html <- is what you get if you disable the cups-filters patch
[15:27] <chrisccoulson> cjwatson, did you see that chromium failed on heka again? (but this time, in a different place and much earlier too)
[15:29] <cjwatson> I didn't but I guess you can sort it out?
[15:30] <chrisccoulson> cjwatson, not sure. it hit an internal error in the linker this time, which it didn't hit on the previous build: https://launchpadlibrarian.net/143369029/buildlog_ubuntu-precise-armhf.chromium-browser_28.0.1500.52-0ubuntu1.12.04.1_FAILEDTOBUILD.txt.gz
[15:31] <cjwatson> feel free to retry if it looks like hw corruption
[15:31] <chrisccoulson> cjwatson, ok, i've got to do another upload in any case
[15:47] <debfx> jodh: procenv doesn't print the test output to the build log anymore :(
[15:49] <xnox> debfx: automake-1.13 doesn't, changing to serial-tester will get that back.
[15:50] <cjwatson> Or cat test-suite.log at the end?
[15:50] <cjwatson> automake seems to be fairly aggressively deprecating the serial test harness, so it might be safer not to assume it
[15:51] <Laney> Is there a way to tell automake to do that?
[16:07] <tkamppeter> OdyX, the CUPS test suite contains tests which are out of the scope of the CUPS package as printing JPEG, TXT, ... upstream CUPS does not ship this functionality any more and so these tests are actually testing cups-filters. These tests should be removed from upstream CUPS.
[16:09] <tkamppeter> OdyX, test jobs with filters should only use the filters which come with CUPS.
[16:24] <OdyX> tkamppeter: can't disagree. :)
[16:24] <OdyX> tkamppeter: do you want me to report: I can't before tomorrow.
[16:25] <jodh> debfx: yes I know :-( See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710955
[16:27] <jodh> check.am in automake-1.13 still includes "test x"$$VERBOSE" = x || cat $(TEST_SUITE_LOG);" but I cannot make VERBOSE work :(
[16:28] <tkamppeter> OdyX, please do so.
[16:28] <Laney> jodh: I only played very quickly but it also didn't work for me
[16:28] <Laney> let me know if you get it
[16:28] <tkamppeter> OdyX, I am releasing cups-filters 1.0.35 now.
[16:29] <cjwatson> jodh: Might be worth asking upstream directly
[16:29] <cjwatson> help-automake or similar
[16:30] <jodh> cjwatson: ack - will do.
[16:31] <cjwatson> Looks like it's just automake at gnu.org actually
[17:03] <tkamppeter> OdyX, I have release cups-filters 1.0.35 upstream now. I have also updated the BZR repo of the Debian package, so it is ready for you to upload cups-filters 1.0.35 to Debian.
[17:03] <OdyX> tkamppeter: will do tomorrow then, thanks.
[17:36] <jml> cjwatson: can I persuade you to take a look at http://askubuntu.com/questions/312927/booting-13-04-64-bit-pendrive-in-uefi-freezes-immediately-after-loading-ramdisk ?
[17:40] <cjwatson> jml: posted some hints on at least getting more data
[17:41] <jml> cjwatson: thank you :)
[18:13] <bdmurray> Sweetshark: could you have a look at bug 1194740?
[23:43] <darkxst> cjwatson, yes basically, apparently the text-based menu is not accessible for screen-readers
[23:43] <darkxst> but then I also suppose that the ubiquity menu can't be re-branded to be flavour specific?
[23:54] <slangasek> infinity: around?  I think I need another brain to look at bug #1187318
[23:55] <slangasek> infinity: i386-only, a plymouth upstream commit that adds a reference to ply_get_timestamp() from the 'script' theme engine breaks pango text display... I've checked everything I can think of to explain this.
[23:58] <infinity> slangasek: I was just heading out to dinner, but my brain might be functional upon my return.
[23:59] <slangasek> infinity: ok - the problem will be here when you return, I'm sure ;)
[23:59] <infinity> Heh.