[06:40] <pitti> Good morning
[06:41] <pitti> cjwatson: in that case these are usuall "temporary testbed failures", I'll sort them out
[06:42] <pitti> cjwatson: we had gazillions of failures and retrys over the weekends due to some cloud trouble again, sorry
[06:42] <pitti> Mirv: filing a bug and overriding WFM
[07:07] <Mirv> pitti: ok
[07:14] <Mirv> pitti: bug #1523364 filed
[07:36] <pitti> Mirv: thanks! hinted kwin
[07:50] <highvoltage>  /win 38
[07:55] <dholbach> good morning
[07:56] <sladen> likewise
[07:59] <Mirv> pitti: thanks! what's up by the way with all the "Test in progress" ones that don't seem to happen? for example I see akonadi-calendar, frameworkintegration etc for armhf at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src but not in http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-armhf
[07:59] <seb128> hey dholbach
[07:59] <dholbach> hey seb128
[08:00] <Mirv> or ubuntuone-credentials for all archs
[08:08] <Trevinho> Hi folks
[08:26] <robert2> Hi
[08:28] <robert2> when I using wily in armhf,but dash and left bar miss
[08:29] <robert2> dconf reset -f /org/compiz/ && setsid unity
[08:30] <robert2> compiz (opengl) - Fatal: GL_OES_EGL_image is missing  is output
[08:36] <Mirv> xnox: I prefer having qt uploads through CI Train so that I know what's landing - I was preparing ubuntu2 for now but I will import your changes to the packaging git and switch to ubuntu3 instead
[08:37] <pitti> Mirv: I'll take care of that
[08:41] <alkisg> pitti: good morning, I'm seeing a regression for LP: #1492546 in 228-2ubuntu1, is it by design or should I try to find out what exactly caused it?
[08:45] <pitti> alkisg: that surely doesn't sound like it's by design; maybe indeed some unintended change
[08:45] <smb> Logan, I probably should (dahdi) as time allows. There were a few things more pressing before.
[08:53] <pitti> didrocks, tseliot, apw: so wrt. plymouth and vga16gb: last time I saw a computer with an nvidia card, it looked pretty much like a text plymouth interface
[08:53] <pitti> is there really much difference between the vga16fb renderer and the text one?
[08:53] <pitti> i. e. could we drop the former?
[08:54] <robert2> https://bugs.launchpad.net/compiz/+bug/1086736 is sloved?
[08:56] <robert2> ubottu> I find that bug,but I don't know how to fix it
[08:59] <apw> pitti, i cirtainily only care it works in that situation it is such a short period of time
[09:20] <Mirv> pitti: sorry to ping so much but the hinting is not seen on excuses page although it was updated 25min ago
[09:23] <pitti> Mirv: odd indeed; the hint is there, I'll check closer in a bit
[09:36] <xnox> Mirv, sure, however s390x builds are not done for landings yet, as far as i know.
[09:37] <Mirv> xnox: ah, true that, they'd be nice to have soonish as s390x progresses. anyway, I'm nearing the now ubuntu3 testing so if you have anything new for that, send the to me and I can combine.
[09:38] <tseliot> pitti, didrocks: right, I had to disable that for nvidia but it should no longer be an issue to re-enable it (I simply forgot to do it).
[09:38] <pitti> tseliot: do we have to?
[09:39] <didrocks> yeah, it's been like that for cycles, isn't it?
[09:39] <pitti> tseliot: if so, I guess it has been disabled for a long time alreddy?
[09:39] <Mirv> xnox: the packaging btw is at http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/log/?h=ubuntu
[09:40] <xnox> Mirv, well, that my upload still failed tests on s390x, i have made the tests run with -k now, to see all failures.
[09:41] <tseliot> pitti: as a matter of fact, we probably don't. I haven't tested the KMS module that nvidia provides now
[09:41] <pitti> tseliot: wow, did I hear "nvidia" and "KMS" in one sentenc? :-)
[09:41] <xnox> Mirv, using `make -k` for tests is one thing to add, and make the good/bad arches do fail or e.g. || true -> such that we still run tests, but see how good/bad they are.
[09:42] <xnox> Mirv, that's nice, but i don't have commit access there, now do i =) how do you want patches for that repo?
[09:42] <xnox>  /o\
[09:43] <tseliot> pitti: right :) that's part of a release that we don't have in the archive yet
[09:45] <Mirv> xnox: anything is fine - git repo somewhere, LP bug with attachments, debdiff..
[09:48] <xnox> Mirv, if you want to upload now, you should mark s390x as `bad' arch for the tests.
[09:49] <xnox> but i will work to enable test suite for it, cause i don't want it to regress.
[09:51] <Mirv> xnox: alright, let's re-enable it once the test suite passes
[10:00] <alkisg> pitti: is there somewhere that I could see the systemd history in ubuntu, along with its debian/ folder? In http://bazaar.launchpad.net/~registry/systemd/master/files I don't see debian/ ...
[10:00] <alkisg> (so that I could do some bisection...)
[10:01] <pitti> alkisg: it's maintained here: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git
[10:01] <alkisg> Thank you!
[10:01] <pitti> alkisg: I keep the ubuntu delta in the ubuntu branch, but it just keeps getting rebased
[10:01] <pitti> so not much to bisect there
[10:01] <alkisg> OK, checking...
[10:07] <xnox> pitti, can acpid please be waived through autopkgtest, or rather nvidia-graphics-drivers-340[-updates] to be marked as bad on armhf. I'm not quite sure why armhf tests are failing for nvidia-graphics-drivers.
[10:07] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#acpid
[10:36] <Laney> @pilot in
[11:49] <cjwatson> pitti: well, it's not just temp failures, it's that the excuses output doesn't appear to accurately reflect the most recent runs
[11:49] <cjwatson> pitti: and when I looked, the queues were empty
[11:50] <cjwatson> pitti: still, I guess we'll see if they clear now
[11:52] <LocutusOfBorg1> hi Unit193 the service file for vboxweb is in place
[11:52] <LocutusOfBorg1> let me know if it works or not
[12:15] <Laney> slangasek: Do you know who the right person to look at bug #1465386 might be?
[12:16] <Laney> xnox: bug #1472314 looks like it is waiting for you
[12:19] <xnox> Laney, i disagree with is =) ./debian/rules clean must be run between built steps =)
[12:19] <xnox> *it
[12:21] <Laney> the comment #3 doesn't involve packaging
[12:21] <Laney> but take it to the bug please :P
[12:38] <xnox> Laney, =D
[12:38] <xnox> Mirv, does Qt at all work on big-endian platforms? I sense there are legit test suite failures on big-endian.
[13:01] <Laney> doko: can you comment on sruing bug #1501300 please?
[13:01] <Laney> (in the bug)
[13:02] <stevenm_> Hey, anyone here familiar with the ubiquity installer?  i'm looking at the bottom of the ubiquity/plugins/ubi-prepare.py file
[13:03] <xnox> stevenm_, #ubuntu-installer is a better channel for things like that.
[13:03] <doko> Laney, done
[13:03] <stevenm_> ah ok thanks xnox
[13:13] <Laney> doko: ty
[13:20] <Mirv> xnox: not sure about working, but it builds and upstream accepts patches. upstream does not run any of their tests on big endian archs afaik (last time I checked their test configurations it was arm/x86 only)
[13:22] <xnox> Mirv, e.g. they don't use "gcc atomics" and have per arch, atomics, there are no atomics committed for s390x, and then it fallback to bitshifts... little endian way...
[13:22] <xnox> src/corelib/io/qloggingcategory.h
[13:24] <Mirv> xnox: arm64 enablement was contributed to upstream from us if I remember correctly. feel free to submit commits https://codereview.qt-project.org/#/q/project:qt/qtbase,n,z and I can also add you to the Canonical CLA group in Qt upstream
[13:24] <xnox> hm, well there is Q_BIG_ENDIAN defined with reverse shifts.... =/
[13:30] <xnox> Mirv, hm... something is really odd.
[13:31] <pitti> cjwatson: right, I did some admin and upgrades with clearing the queues in between; armhf is still sick, the others are catching up now
[13:43] <seb128> doko, do you plan to submit your pep8 changes to Debian?
[13:43] <seb128> doko, or do we need an Ubuntu delta know to fix build issues for things like https://launchpadlibrarian.net/222742791/buildlog_ubuntu-xenial-amd64.prospector_0.10.1%2Bgit20150706.a00e191-1_BUILDING.txt.gz ?
[13:45] <seb128> e.g do we need to change things build-depending on pep8 to use python-pep8?
[13:51] <xnox> Mirv, so, i'd like to upload qtbase with s390x set to bad architectures for now.
[13:51] <xnox> Mirv, shall i upload it, or do you want to do that via debian/git/landing ?
[13:52] <xnox> it's blocking a lot of s390x bootstrap, and i think the problems are real, and i'd need more time fixing them, but i'm not yet sure of the priority on those.
[13:52] <xnox> e.g. it's not critical for the next milestone as far as i can see.
[13:53] <Mirv> xnox: I've it in my next upload, so no need to upload. I just wish the migration of Qt 5.5 to release pocket could happen before triggering another 1000 of tests with a new upload.
[13:55] <Mirv> xnox: it'd sound like pitti has unblocked something in the queue so maybe there's hope for the migration later today. meanwhile, I have my part of the next qtbase upload seemingly done so I will pre-build a version of that in a landing PPA to copy over once the migration has happened.
[13:56] <xnox> Mirv, it will not, because of lack of s390x build, and lack of poppler.
[13:56] <xnox> but let me double check that.
[13:57] <xnox> or maybe it will.
[13:57] <pitti> Mirv, xnox: I'm done with infra rescuing, and armhf are back; I'm looking at excuses.html now to see what's stuck
[13:57] <Mirv> xnox: well qtbase surely never built on s390x so it couldn't be blocking
[13:57] <xnox> if we ignore outstanding tests to do.
[13:58] <xnox> Mirv, ok, and does it ignore failures on s390x for now?
[13:59] <Mirv> xnox: the new upload yes, I've only opted-in amd64 armhf i386 for the test runs. if you have some more additions than what you had in ubuntu2 upload (there was -k added at the end of xvfb line at least), I can add those
[13:59] <Mirv> xnox: what I'm going to upload is there in the git
[14:00] <xnox> Mirv, true. and looking at qtbase.git tree it looks good.
[14:00] <xnox> in terms of s390x build should pass, once you copy it over into the archive proper.
[14:00] <xnox> if you could do that, it would be wonderful.
[14:00] <Mirv> that's what I believe too
[14:00] <xnox> Mirv, i'd be happy with git uploaded soon.
[14:00] <xnox> i will work on these things more, later.
[14:01] <Mirv> xnox: I will do that but as said I'd like to see the migration happen first, since a new qtbase would trigger lots of autopkgtests again which are already struggling. but I'd say tomorrow morning (16h) I'd do it if the migration has finally happened
[14:01] <xnox> why ubuntu-minimal is not installable does worry me more on s390x at the moment.
[14:01] <cjwatson> procps
[14:02] <cjwatson> if that ever migrates then I believe it'd fix it
[14:02] <xnox> cool.
[14:03] <cjwatson> currently blocked on systemd/{armhf,i386}, openafs/armhf, and sysdig/armhf autopkgtest regressions, and clamav/armhf autopkgtest in progress
[14:03] <xnox> cjwatson, and how did you work that out, so quickly =)
[14:03] <cjwatson> sounded like pitti was looking into that kind of thing
[14:03] <cjwatson> xnox: I looked into something else the other day with chdist and ended up there
[14:03] <cjwatson> xnox: don't actually know it's the only blocker for ubuntu-minimal, but it's certainly a significant one
[14:04] <xnox> ok.
[14:05]  * xnox ponders if pitti is in ~ubuntu-release or not.
[14:05] <pitti> formally I am, for pushing hints
[14:05] <xnox> Laney, looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#procps could systemd tests be ignored, or e.g. procps hinted to ignore autopkgtests?
[14:06] <xnox> ah cool.
[14:07] <pitti> xnox: I'll hint it
[14:07] <xnox> pitti, i'm looking into procps and ncurses. and whether ncurses will be needed too, to get procps migratable.
[14:07] <cjwatson> xnox: it clearly is, excuses says so
[14:07] <pitti> xnox: already is
[14:07] <pitti> as I said, I'm currently walking over excuses.html and see what's stuck, updating some hints
[14:08] <pitti> like pyx
[14:08] <pitti> and the two sytemd failures were due to infra bugs, not procps etc.
[14:08] <pitti> while the queues catch up we can speed up the landing of those
[14:08] <xnox> right. thanks, ok.
[14:08] <pitti> (yay for having multiple staggered infra disasters :( )
[14:09] <Laney> thanks
[14:09]  * Laney eats own arm
[14:09] <Laney> @pilot out
[14:23] <Mirv> pitti: did you figure out why the kwin being hinted is not showing?
[14:26] <Mirv> hmm now it seems autopkgtests are failing because apt would get uninstalled o_O
[14:32] <pitti> Mirv: not yet, but as I wrote above, I'm currently doing -proposed cleanup, getting there
[14:33] <Mirv> pitti: ok
[14:55] <gQuigs> hi there, do I need to do anything else for the SRU of https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1505328 ?
[14:57] <gQuigs> is "get a sponsor" and  subscribe ubuntu-sponsors the same thing?  (https://wiki.ubuntu.com/StableReleaseUpdates#Procedure)
[15:03] <seb128> Laney, cyphermox, hey, any idea why network-manager-gnome is missing for xenial desktop isos? it's a recommends from n-m so it should be either, I though that maybe it was uninstallable for some reason but I don't see why it would (and can't get an error by pbuilder testing)
[15:05] <cyphermox> looking
[15:05] <gQuigs> seb128: well, the versions seem off to me -gnome is on 1.0.6 and nm is on 1.0.4
[15:05] <seb128> gQuigs, why would that be an issue?
[15:06] <cyphermox> gQuigs: that shouldn't matter
[15:06] <cyphermox> well, as long as it remains installable anyway
[15:06] <cyphermox> seb128: was the package missing altogether or just no indicator in the panel?
[15:06] <seb128> gQuigs, 15.10 has 1.0.4 and 0.9.10
[15:06] <seb128> cyphermox, it's not on http://cdimage.ubuntu.com/daily-live/current/xenial-desktop-amd64.manifest
[15:06] <cyphermox> wow
[15:07] <seb128> right
[15:07] <cyphermox> ah, perhaps it's indeed from the merge
[15:07] <cyphermox> https://launchpadlibrarian.net/228999342/buildlog_ubuntu_xenial_amd64_ubuntu_BUILDING.txt.gz
[15:07] <cyphermox> ^ mentions it just once as a Recommends, but never after tht
[15:07] <cyphermox> *that
[15:08] <gQuigs> hmm.. I thought they were the same source package.. oops
[15:08] <seb128> gQuigs, oh, about your "find a sponsors", subscribing the team is a good way to do that yes
[15:09] <seb128> though for a security fix you might want the ubuntu-security-sponsors
[15:10] <gQuigs> seb128: yea, I'm guessing that's why it seems in limbo, security team said they want it to go throught the normal SRU process
[15:11] <seb128> oh ok, then ubuntu-sponsors is right
[15:11] <mdeslaur> gQuigs: sorry, I'll look at your cups bug today
[15:11] <mdeslaur> gQuigs: you erased the previous debdiff, so now I have to review it all over again :P
[15:11] <gQuigs> mdeslaur: oh, you can also do normal SRUs? :)
[15:12] <mdeslaur> gQuigs: I can ack it and upload it, then the SRU team will handle it
[15:12] <gQuigs> 'doh, the name of the old one kept confusing, it was final patch or something.. bad choice on my part
[15:12] <gQuigs> thanks both
[15:13] <seb128> cyphermox, was reported as bug #1522955 for reference
[15:13] <cyphermox> seb128: ok
[15:13] <seb128> cyphermox, I'm a bit puzzled at why, I tried to install ubuntu-desktop and the other plugins in a pbuilder and no error
[15:14] <cyphermox> yep
[15:25] <seb128> cyphermox, k, found the issue
[15:25] <cyphermox> ah?
[15:26] <seb128> cyphermox, that change got dropped in the n-m-applet merge
[15:26] <seb128>  network-manager-applet (0.9.8.8-0ubuntu9) vivid; urgency=medium
[15:26] <seb128>  
[15:26] <seb128>    * Switch gnome-icon-theme to adwaita-icon-theme, which is its
[15:26] <seb128> or g-i-t is in universe
[15:26] <seb128> so it makes n-m-gnome uninstallable
[15:26] <cyphermox> oh, of course
[15:26] <cyphermox> *sigh*
[15:26] <cyphermox> you or I fix?
[15:26] <seb128> as you want
[15:26] <seb128> is there a vcs for it?
[15:26] <cyphermox> yeah
[15:27] <seb128> if so you probably have that set up so please do
[15:27] <seb128> thanks :-)
[15:27] <cyphermox> ok ;)
[15:27] <cyphermox> lp:~network-manager/network-manager-applet/ubuntu
[15:27] <seb128> yeah, I'm basically being lazy :p
[15:28] <seb128> but I can do it if you prefer
[15:29] <cyphermox> no I'm on it :)
[15:29] <seb128> cool, thanks
[15:29] <cyphermox> just sharing the vcs for posterity.
[15:29] <seb128> :-)
[15:33] <Laney> seb128: good find
[15:34] <seb128> Laney, thanks!
[16:13] <xnox> mvo, what is this _apt user business?
[16:13] <xnox> i've seen this failing, and like sbuild and/or apt complaints about it.
[16:13] <mvo> xnox: in a meeting right now so a bit short: its the drop privs user that we use when downloading debs
[16:15] <xnox> mvo, cool, ok. who should create it? cause e.g. sbuild autopkgtest is failing at the moment because of this.
[16:19] <mvo> xnox: hm, I thought we fixed that in the latest apt build
[16:19] <mvo> xnox: its created via postinst
[16:20] <Laney> Is it failing on stderr output?
[16:21] <seb128> yes
[16:21] <seb128> mvo, there is a warning written and the autopkgtest considers that as wrong and nack it
[16:22] <xnox> mvo, well, and old apt is used to start the chroot, then a newer apt is upgraded to, which is too late by that time.
[16:22] <xnox> pitti, could you mark sbuild as a bad test for now, or like allow apt to go through please?
[16:23] <xnox> mvo, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/sbuild/20151207_114240@/log.gz
[16:24] <pitti> xnox: done
[16:24] <xnox> pitti, thank you.
[16:24] <Laney> What if you make the test depend on apt 1.1?
[16:24] <Laney> ...or skip it...
[16:24] <xnox> and then once apt migrates, the next time it should work fine.
[16:25] <xnox> Laney, well, i'm not sure, so sbuild first downloads source, then upgrades things. maybe if the test does $ apt-get source procenv; sbuild procenv*.dsc it would work better.
[16:25] <xnox> Laney, instead of what i gather from logs it's doing $ sbuild procenv_version
[16:25] <xnox> meh, once in a life time "bootstrap" bug.
[16:26] <pitti> I don't think it's transient
[16:26] <xnox> and the test log still says that all is good, and packages have built.
[16:26] <pitti> sbuild usually copies the host's passwd into the chroot
[16:26] <pitti> and apt loudly complains if it doesn't find that _apt sys user (which isn't static)
[16:27] <pitti> so this conceptually collides
[16:27] <xnox> pitti, iff the chroot is created with apt 1.1.3 there should be a warning, i would have through.....
[16:27] <xnox> ... hm =/
[16:27] <pitti> xnox: ah, that way around; yes
[16:35] <pitti> apw: I filed bug 1523586 with the kernel panic now
[16:36] <apw> oh nice thanks
[16:39] <apw> pitti, and shove at rtg as that is actually his very latest shiney whihc is imploding
[16:40] <apw> and shoved (past tense)
[16:49] <xnox> hallyn, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1523593
[16:51] <dholbach> slangasek, do you know what the problem might be with https://bugs.launchpad.net/ubuntu/+source/skype/+bug/1523060?
[16:52] <hallyn> xnox: yeah i saw the build failiure, it's on my list, thx
[16:52] <hallyn> ooh a patch, thanks :)
[16:52] <xnox> hallyn, that one makes it built =) i'm not yet able to run that, but at least it will compile for now.
[16:53] <hallyn> xnox: will push that ina few mins (after bfast0
[16:54] <xnox> hallyn, cool thanks. upload to ubuntu would be appreciated too.
[16:57] <xnox> pitti, there is a bogus hint from riddell, that overrides your hint in britney.
[16:57] <xnox> from http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2015-12-07/16:35:26.log
[16:57] <xnox> W: [Mon Dec  7 16:35:52 2015] - Overriding force-badtest[kwin] = ('4:5.4.3-0ubuntu2', 'pitti', 'None') with ('4:5.4.3-0ubuntu3', 'pitti', 'None')
[16:57] <xnox> W: [Mon Dec  7 16:35:52 2015] - Overriding force-badtest[kwin] = ('4:5.4.3-0ubuntu3', 'pitti', 'None') with ('4:5.4.2-0ubuntu1', 'jriddell', 'None')
[16:57] <xnox> could you drop jriddell's hint, and just keep latest hint of yours?
[16:57] <pitti> ooh
[16:58] <pitti> well, not bogus, just old :)
[16:58]  * xnox ponders if comments like that qualify me for ~ubuntu-release team ;-)
[16:58] <xnox> pitti, on this 7th day of christmas it's now bogus =)))) i'm not agist ;-)
[16:58] <pitti> xnox: hinted harder
[16:58] <pitti> xnox: thanks for spotting!
[16:59] <brendand> is this 404 anything to worry about? ports.ubuntu.com/ubuntu-ports/dists/xenial-security/restricted/binary-armhf/Packages
[16:59]  * xnox sings we can go hard, or we can go home
[17:00] <cjwatson> xnox: errr very much not the 7th day of Christmas.  try that in 24 days :)
[17:00] <xnox> cjwatson, #fail
[17:00] <xnox> brendand, no, that's normal. there are compressed files only. and it's empty anyway, as nothing is published there yet.
[17:02]  * xnox ponders if it's 7th advent, already?! i had tree up since november, so i don't care much. And had turkey dinner yesterday.
[17:02] <cjwatson> xnox: (well, or 12-ish days later in the eastern churches ...)
[17:02] <cjwatson> xnox: ninth day of Advent today
[17:02] <cjwatson> we did our tree yesterday.  and chanukah candles, so if any neighbours were paying attention I bet they were confused.
[17:03] <xnox> >_< =)
[17:03] <xnox> cjwatson, keep them guessing =)
[17:04] <xnox> Mirv, kwin hint will be fixed, in the next britney run
[17:05] <xnox> cjwatson, i tend to keep tree until the 13th of January and celebrate Soviet Old New Year - that confuses people, cause generally there isn't chritstmas tree collection service from council by that time (if we have real tree that year)
[17:06] <cjwatson> pitti: cinnamon-control-center looks like another testbed failure
[17:06] <cjwatson> pitti: (armhf)
[17:09] <pitti> cjwatson: right, thanks, retrying again
[17:11] <pitti> and apparently there's a bug with sometimes not seeing new test results in swift
[17:12] <doko> hmm, binutils-static wants to demote?  does this mean we won't need it anymore?
[17:12] <doko> cjwatson, and binutils-udeb?
[17:18] <cjwatson> doko: binutils-static-udeb (assuming that's what you mean) has been explicitly seeded in the installed seed since breezy; I think it's been obsolete for quite a while but am not certain
[18:00] <cjwatson> xnox: looks like https://launchpad.net/ubuntu/+source/libindicator/12.10.2+14.10.20140922-0ubuntu1/+build/8377385 is the current blocker for ubuntu-desktop/s390x
[18:01] <xnox> cjwatson, ack, thanks. will look into it.
[18:02] <cjwatson> definitely gradually improving though ...
[18:52] <cyphermox> bdmurray: will you be around for the DMB meeting shortly?
[18:54] <bdmurray> cyphermox: yep
[19:04] <mdeslaur> slangasek: no new edk2 yet?
[19:05] <slangasek> mdeslaur: hmm, new relative to what?  the one that had been in the Debian new queue is in xenial today
[19:06] <slangasek> Laney: bug #1465386> I would not consider this a priority to fix in SRU and it's of course not something we would prioritize for xenial because we don't support upstart as system init in xenial
[19:06] <mdeslaur> slangasek: ah crud, sorry about that, I was expecting a newer date in the version number for some reason
[19:07] <mdeslaur> slangasek: thanks
[19:38] <pitti> Mirv: can you have a quick look at http://autopkgtest.ubuntu.com/packages/o/okteta/xenial/amd64/ ?
[19:38] <pitti> Mirv: error: ‘QIODevice’ has not been declared
[19:38] <pitti> Mirv: is that an API change which okteta needs to get adjusted to?
[21:26] <chiluk> hey pitti... you had mentioned that you might do a merge of findutils from debian-unstable for xenial for https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788
[21:26] <chiluk> pitti: can I assign you the case?