[00:06] <sergio-br222> there is no libqt5opengl5-gles-dev in the armhf repo
[00:06] <sergio-br222> so yeah, it's only x86 stuff
[00:06] <Logan> is there any way to simulate pkgstriptranslations (as it acts on the buildds) in pbuilder?
[00:07] <lifeless> sergio-br222: what RAOF was saying is that libqt5opengl5-dev on armhf *is GLES only*.
[00:07] <lifeless> sergio-br222: and that the packaging layout is just really confusing for $reasons
[00:07] <sergio-br222> heh
[00:07] <sergio-br222> OK, now I'm understanding
[00:07] <sergio-br222> $reasons, heh
[00:08] <lifeless> RAOF: might be something to fix :)
[00:08] <lifeless> RAOF: since the reasons seem fairly shallow
[03:55] <dupingping> The awesome software is published, You can use the trial version of Sticky Notes.
[03:55] <dupingping> http://korsoftware.com
[04:53] <pitti> Good morning
[06:23] <tsdgeos> What's the best way to get a patch into the fbi package? It's just a one liner so that it actually picks up the correct jpeg lib and doesn't just abort on run
[06:46] <dholbach> good morning
[07:56] <jamespag`> morning
[08:43] <flexiondotorg> Laney, I see you're piloting sometime today. Please may I kindly request you take a look at the package updates:
[08:43] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1466521
[08:43] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1466785
[08:48] <alkisg> infinity: good morning, may I ping you to approve this x11-utils SRU that's in the precise queue? https://bugs.launchpad.net/ubuntu/+source/x11-utils/+bug/1463663, https://launchpad.net/ubuntu/precise/+queue?queue_state=1, https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[09:13] <Riddell> pitti_: libkdegames seems stuck on a test server error, can you retry it? https://jenkins.qa.ubuntu.com/job/wily-adt-libkdegames/lastBuild/ARCH=amd64,label=adt/console
[09:14] <highvolt1ge> t/win 23
[09:18] <seb128> Riddell, hey, did you notice bug #1461987?
[09:18] <Riddell> seb128: hmm I did not, thanks
[09:18] <seb128> Riddell, yw!
[11:30] <Laney> LocutusOfBorg1: debfx: have you seen any problems with cmake 3.2 and CMAKE_INSTALL_LIBDIR? qtmir has started FTBFSing because it doesn't point to the multiarch libdir any more.
[12:03] <debfx> Laney: I don't know how it worked before but -DCMAKE_INSTALL_PREFIX=$(TMP1_DIR)/usr/ is just wrong
[12:14] <pitti_> Riddell: I doubt that this helps -- the -proposed version has failed consistently 8 times in a row, it's a real regression (in code or test)
[12:15] <Riddell> pitti_: for which one?
[12:15] <pitti_> Riddell: libkdegames
[12:15] <Riddell> ah libkf5kdegames6
[12:17] <Riddell> mm I think that's just not been changed since the kdelibs4 version so of course it's wrong
[12:17] <Laney> debfx: this seems weird
[12:29] <debfx> Laney: cmake uses multiarch paths only when the prefix is /usr, except when you patch it too much.
[12:30] <debfx> so I'd suggest to a) fix the cmake invocation in qtmir
[12:30] <debfx> b) fix the cross compile patch to not alter behavior in the default case
[12:30] <debfx> c) install MultiArchCross.cmake to the correct dir
[13:03] <cyphermox> good morning!
[13:04] <seb128> hey cyphermox, how are you?
[13:04] <cyphermox> good, you?
[13:04] <seb128> did you have good holidays?
[13:04] <seb128> I'm good thanks ;-)
[13:04] <cyphermox> yep :)
[13:17] <Laibsch> Previously, I was able to upload to a release pocket in my ppa other than the one specified in the changelog via "incoming = ~r0lf/ppa/ubuntu/trusty" in dput.cf
[13:17] <Laibsch> Is that no longer supported?  It was very nifty.
[13:22] <cjwatson> Laibsch: Should still work, but I can't see any evidence of you having tried that recently in the logs ...
[13:23] <cjwatson> Laibsch: Though the preferred form now is ~r0lf/ubuntu/ppa/trusty; the earlier form is deprecated
[13:25] <Laibsch> cjwatson: it was rejected by dput, I guess.  It could be that this is because it's debian's dput in this case
[13:26] <cjwatson> Laibsch: I don't see why dput would care.  Do you have a transcript?
[13:26] <Laibsch> cjwatson: http://paste.debian.net/252618/
[13:27] <cjwatson> Laibsch: That has nothing to do with the incoming directory.  See line 28.
[13:27] <Laibsch> dsc-upload-$target is a script I wrote for uploading to ppa: http://paste.debian.net/252619/
[13:28] <cjwatson> "Error: uploading files for distribution UNRELEASED to trusty not allowed."
[13:28] <cjwatson> $ dpkg -L dput | xargs grep -s 'not allowed'
[13:28] <cjwatson> /usr/bin/dput:            raise dputhelper.DputUploadFatalException("Error: uploading files for distribution %s to %s not allowed."%(distribution, host))
[13:29] <Laibsch> well, but I am uploading to my PPA. At least that is what i am trying to do and what worked until a few days ago.
[13:29] <cjwatson> well, but you need to read the error message
[13:29] <cjwatson> it's not relevant where you're uploading to
[13:30] <cjwatson> except in that the host definition in dput's config has an allowed_distributions regex which is checked
[13:30] <cjwatson> but UNRELEASED normally simply means what is says; I'd recommend running dch -r first
[13:30] <cjwatson> *what it says
[13:30] <cjwatson> releasing things (to PPA or otherwise) which are marked UNRELEASED is terribly confusing and should be avoided
[13:31] <Laibsch> yes, I now checked /etc/dput.cf and this indeed seems to be Debian-specific
[13:32] <Laibsch> checking for UNRELEASED
[13:32] <cjwatson> it's not Debian-specific
[13:32] <Laibsch> well, I am working on releasing the package officially and just making some testing packages available now
[13:32] <cjwatson> the default allowed_distributions in Ubuntu's dput.cf for all hosts is (?!UNRELEASED)
[13:32] <Laibsch> how about HALFRELEASED ;-)
[13:32] <cjwatson> I care not what you write there, but dput's config does
[13:33] <Laibsch> apparently, but IIRC this used to work when I did this kind of stuff in now-EOL lucid
[13:33] <Laibsch> anyway, the root of the problem was found. thanks!
[13:33] <cjwatson> that was rather a long time ago.  anyway dput's config is sensible and if I were you I'd improve your practices to be less confusing :)
[13:34] <cjwatson> this dput change appears to predate lucid, see dput 0.9.2.30's changelog
[13:34] <cjwatson> but hard to debug something that long ago
[13:36] <dobey> jamespage: hi. why did you upload intermediate broken versions of unittest2/testtools to wily, rather than the latest versions?
[13:36] <Laney> debfx: looks like (b) is enough ;)
[13:36] <Laney> I saw "  * Fix install path of MultiArchCross.cmake to be cmake-3.0." but didn't twig that this was for 3.0 and not 3.2
[13:36] <jamespage> dobey, that was an interim step towards newer versions, without the requirement for two new bits of packaging right now
[13:36] <Laney> so discounted it as a possible breakage source
[13:39] <dobey> jamespage: well it seems that it breaks @testtools.skip decorator, causing previously working tests to fail in autopkgtests; and it seems wily has python 3.5, so the latest versions could probably work without the other new packages in wily, by depending on 3.5?
[13:39] <jamespage> dobey, urgh - sorry - obviously un-intended
[13:42] <dobey> jamespage: any idea when this can be fixed? https://jenkins.qa.ubuntu.com/job/wily-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/console for a reference to see the skip failure
[13:43] <jamespage> dobey, looking now
[13:51] <doko> mvo, online?
[13:53] <mvo> doko: sprinting, sort of online
[14:39] <Laney> @pilot in
[14:40] <jamespage> dobey, looks like some sore of change in behaviour - even with latest I still see the same issue with the scopes test
[14:42] <jamespage> dobey, still looking
[14:43]  * dholbach hugs Laney
[14:43] <dobey> jamespage: hmm, i am seeing the tests passing with what's in ppa:dobey/testtols (installed the trusty versions on top of wily)
[14:43] <jamespage> dobey, ok - I have a fix - but its in the scope-harness package
[14:44] <jamespage> dobey, ScopeHarnessTestCase needs to inherit from testtools.TestCase - currently it goes off unittest.TestCase
[14:44] <jamespage> this may be a bug in testtools - but that at-least gets you past this problem
[14:45] <dobey> hmm, ok
[14:45] <jamespage> dobey, I'll raise a bug and see what upstream think
[14:46] <dobey> jamespage: i guess we can land that change. i don't have a problem with it
[14:47] <dobey> it seems like an unnecessary dep though, since it doesn't seem python3-scope-harness depends on testtools for anything else
[14:50] <jamespage> dobey, https://bugs.launchpad.net/testtools/+bug/1467558
[14:51] <dobey> oh
[14:52] <dobey> jamespage: i guess the issue is because the decorator is on setUp there?
[14:52] <jamespage> quite possibly
[14:52] <jamespage> I think its the mixing of unittest/unittest2 which is causing the problem - this may have worked by accident before
[14:53] <dobey> jamespage: i'm re-running the jenkins test builds on https://code.launchpad.net/~dobey/unity-scope-click/more-harness-tests/+merge/255211 now. i'm at least not seeing the problem there, with the testtools from my ppa; we'll see what happens with proposed
[14:54] <jamespage> ok
[14:54] <jamespage> dobey, apologies for the break
[14:55] <dobey> jamespage: well, if it works ok with this branch, i'll fast track it through landing to get things back on course
[14:57] <dobey> oh, that jenkins doesn't build with proposed it seems
[15:24] <dobey> jamespage: looks like the issue is gone with that branch and the testtools in proposed, so I'll try to get it pushed through asap.
[15:25] <dobey> jamespage: so i guess the issue is that it doesn't like the decorator on setUp() in newer versions for some reason
[15:32] <jamespage> dobey, looks that way
[15:32] <jamespage> does anyone know how often the component mismatches report is mean't to refresh?
[15:32] <jamespage> http://people.canonical.com/~ubuntu-archive/
[15:32] <jamespage> last refresh at 0850 ish today - I was hoping that my junit4 upload this morning might have made that a little shorter
[15:42] <LocutusOfBorg1> Laney, sorry I was afk, seems you already have the solution :)
[15:43] <Laney> LocutusOfBorg1: ya, merge mistake
[15:44] <Laney> I moved the offending file up a bit in .install and added a comment but I worry this won't be enough at the next merge
[15:47] <LocutusOfBorg1> Laney, I guess it will be enough if I prepare the next merge by myself (at least I hope to)
[15:47] <LocutusOfBorg1> :)
[16:35] <rbasak> infinity: any chance of SRU review for docker.io please?
[16:36] <infinity> Maaaaaybe.
[16:54] <work_alkisg> infinity: thanks a lot :)
[17:03] <Laney> @pilot out
[17:03] <Laney> TBC
[18:00] <pitti_> wgrant, cjwatson: how "scalable" is stalingstack right now? i. e. how many instances could/should I be using in parallel for autopkgtesting? or should I ask IS that and not you?
[18:48] <sarnold> who is the right person to talk with for more privileges on errors.ubuntu.com? cboltz is very helpful to the apparmor project, he's trying to track down something that's been reported in errors.ubuntu.com, and it'd be nice if he had privileges to view all the *apparmor* reports, at a minimum..
[19:01] <smoser> anyone know of something that does what 'annotate-output' does but does so without running 'date' for every line of input ?
[19:07] <sarnold> smoser: is it the calls to date you don't like or the timestamps themselves? maybe pass a format like +"" ?
[19:08] <smoser> the fact that it calls date. ie, forks for every line of input.
[19:08] <sarnold> ouch
[19:08] <sarnold> strftime is right there...
[19:08] <smoser> in bash ?
[19:08] <sarnold> this thing is written in _bash_??
[19:08] <smoser> yeah. its really simple. and works really well.
[19:08] <smoser> but no 'date' builtin in bash means fork.
[19:09] <sarnold> it's shorter and cleaner than I expected :) impressive
[21:46] <hallyn_> arges: bug 1425619 - i think i'm about to become very cross
[21:47] <arges> hallyn_: what happened now
[21:52] <arges> hallyn_: so the missing bit was allow_incoming_qemukvm
[21:52] <cjwatson> pitti_: You should ask IS that; we don't have direct visibility.
[21:56] <hallyn_> arges: yeah.  so the guy who was marking it incomplete wasn't fully up on the issue.  now i guess the test case wasn't fully documented ...
[21:56] <hallyn_> grrrr!
[21:57] <arges> hallyn_: well we can get this into the next update
[22:00] <hallyn_> had you deleted the qemu pkg or can that still be used alongside a new libvirt pkg?