[05:29] <cpaelzer> good morning
[05:44] <pitti> Good morning
[06:22] <flexiondotorg> pitti, If at all possible can you cast an eye over the SRUs we discussed last week? I'd really like to see them included in 16.04.1
[06:22] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1574789
[06:23] <flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1581168
[06:23] <pitti> flexiondotorg: so mate-settings looks good and is verified, and can land in 3 days
[06:24] <flexiondotorg> Great.
[06:24] <pitti> flexiondotorg: and it seems nobody accepted mate-artwork from the queue
[06:26] <pitti> flexiondotorg: I assume bug 1052936 is fixed in yakkety? please mark accordingly
[06:26] <pitti> this is still open in y
[06:26] <pitti> flexiondotorg: accepted m-artwork for xenial (but needs updating this ^)
[06:26] <flexiondotorg> If it.
[06:26] <flexiondotorg> And marked now.
[06:27] <pitti> danke
[06:27] <flexiondotorg> No, thank you :-)
[07:36] <tsimonq2> greetings, I have a bug fix attached to bug 1423326 but I don't have upload permissions and it needs a sponsor. Could somebody please take a loog?
[07:36] <tsimonq2> *look
[09:41] <jtaylor> hm there might be a problem in the xenial docker update
[09:41] <jtaylor> can someone test something for me to confirm? just build a container from: FROM centos:6\n RUN echo test
[09:43] <jtaylor> I get /bin/sh not found, also from ubuntu base images, I'm pretty sure it worked before the update
[09:49] <jtaylor> hm nevermind seems to have been an artifact of not restarting the daemon probably
[09:50] <jtaylor> maybe a NEWS entry would be good
[09:51]  * jtaylor adds that to the bug
[09:58] <flexiondotorg> pitti, I've just tested the ubuntu-mate-artwork update in a clean VM built from todays Xenial daily
[09:58] <flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1581168
[10:11] <caribou> pitti: Are packages synced from Debian have their autopkgtest run when pulled in ?
[10:12] <pitti> caribou: yes
[10:12] <caribou> pitti: thought so
[10:21] <mwhudson> jtaylor: thanks for the comment, i'll see about adding a note indeed, it's a bit of a footgun
[10:59] <Laney> pitti: britney merge> yay!
[11:06] <pitti> Laney: what a pain :)
[12:13] <LocutusOfBorg> hi, do anybody have any idea for expat and python3.5/python2.7 testsuite failure?
[12:13] <LocutusOfBorg> I admit I don't know how to debug it
[12:13] <LocutusOfBorg> seems really a bug in expat
[12:23] <pitti> LocutusOfBorg: right, it seems the new expat changed/fixed the line counting, and now the expected error message changed
[12:23] <pitti> LocutusOfBorg: so looking at the python test to see whether it *should* be line 13 (as before) or 14 (as of now) should tell :)
[12:23] <pitti> i. e. whether it's an expat fix (then python tests need an update) or an expat regression
[12:30] <LocutusOfBorg> pitti, I already did that
[12:30] <LocutusOfBorg> and to me it seems an expat regression
[12:32] <LocutusOfBorg> https://sources.debian.net/src/python2.7/2.7.12-1/Lib/test/test_pyexpat.py/#L611
[12:32] <LocutusOfBorg> it seems really 14 to me
[12:33] <LocutusOfBorg> also here https://sources.debian.net/src/python3.5/3.5.2-2/Lib/test/test_pyexpat.py/#L657
[12:33] <LocutusOfBorg> this is why I would like to send an upstream bug to expat folks
[12:34] <LocutusOfBorg> OOPS https://bugs.python.org/file43515/0001-Fix-Python-3.x.x-tests-for-Expat-2.2.0.patch
[12:34] <LocutusOfBorg> so, I'll ping doko about updating the teststuite :(
[12:40] <LocutusOfBorg> pitti, question: I asked doko to fix the testsuite, but since the testsuite is broken, and upstream is aware, what about ignoring tests for this time and let it migrate? :)
[12:41] <LocutusOfBorg> the only test failing is that one
[12:44] <LocutusOfBorg> oops they didn't have applied the patch yet on the branch
[12:44] <pitti> LocutusOfBorg: which bugs.python.org # does that belong to? (for the comment)
[12:44] <pitti> LocutusOfBorg: is expat blocking anything else?
[12:45] <LocutusOfBorg> https://bugs.python.org/issue27369
[12:45] <LocutusOfBorg> seems really a Python fault, according to the bug
[12:46] <pitti> thanks
[12:46] <pitti> LocutusOfBorg: yes, seems fine; note that doko is on vacation
[12:47] <LocutusOfBorg> I honestly don't know what is blocking, but it is in main, and I like to see my things migrating :p
[12:49] <pitti> LocutusOfBorg: right, I'm mostly just concerned about a lot of things now failing due to an apparent python regression; i. e. would be better to actually fix python right away
[12:50] <LocutusOfBorg> I can't, I should wait for doko :(
[12:50] <pitti> LocutusOfBorg: happy to sponsor
[12:50] <LocutusOfBorg> but meh, I'm not worried for that expat anymore now :)
[12:50] <LocutusOfBorg> oh... ubuntu delta?
[12:50] <LocutusOfBorg> right, hold on
[12:50] <pitti> just really busy ATM, so I'm afraid I don't have time to update this myself
[12:50] <pitti> LocutusOfBorg: it's temporary only, so it's ok
[12:51] <LocutusOfBorg> yes, I can agree
[12:59] <LocutusOfBorg> pitti, I sent debdiffs by email
[13:01] <pitti> LocutusOfBorg: perfect, thanks! please let me know once your build finishes, then I'll upload this
[13:02] <LocutusOfBorg> ack
[13:02] <LocutusOfBorg> FWIW you can also grab debdiffs from the ppa lol :)
[13:25] <LocutusOfBorg> pitti, fine https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/10454431
[13:26] <pitti> LocutusOfBorg: yay, thanks!
[13:27] <LocutusOfBorg> thanks to you :) and don't forget to run testsuite against proposed :p
[13:27] <pitti> I will, once it built/published
[13:28] <LocutusOfBorg> I see the same testsuite runs in dh_auto_test
[13:28] <LocutusOfBorg> so I can presume we are good
[13:28] <pitti> right, and builds happen against -proposed; the build log should tell you the expat version
[13:28] <pitti> oh, your PPA might not enable -proposed
[13:28] <LocutusOfBorg> exactly
[13:28] <pitti> LocutusOfBorg: uploaded, thanks!
[13:31] <LocutusOfBorg> IIRC it has it enabled
[13:33] <LocutusOfBorg> Get:81 http://ftpmaster.internal/ubuntu yakkety-proposed/main arm64 libexpat1-dev arm64 2.2.0-1 [104 kB]
[13:33] <LocutusOfBorg> confirmed
[14:10] <smoser> anyone know why i see this when using eatmydata for atpg-et install
[14:10] <smoser> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
[14:10] <rbasak> smoser: I've seen that, but I presumed that LD_PRELOAD got passed into a container or something where libeatmydata.so no longer existed in that filesystem namespace.
[14:11] <smoser> but it most certainly does exist.
[14:11] <rbasak> What does $LD_PRELOAD say? And ldd that?
[14:13] <smoser> well, heres a recreate:
[14:14] <smoser> lxc launch xenial x1
[14:14] <smoser> lxc exec x1 -- eatmydata apt-get install --assume-yes libvirt-bin
[14:26] <dobey> cjwatson, mvo_: hey, does click unpack stuff to /tmp and then mv to destination? or do something else with /tmp?
[14:29] <cjwatson> dobey: it's been a long time, but that would be a weird and surprising thing for it to do given that it's potentially a different filesystem and might cause atomicity headaches; I don't think I would have done that
[14:29] <cjwatson> dobey: "click verify" will unpack the package to a tmpdir, and there may be other paths that do that kind of thing
[14:30] <dobey> cjwatson: ok, just wanted to check. got a few complaints about /tmp filling up when installing a very large .click package, and trying to figure out what's going on exactly
[14:31] <cjwatson> dobey: not sure what that would be, unless something is explicitly calling verify first
[14:31] <cjwatson> which seems unlikely
[14:31] <dobey> yeah, we don't do that in the click scope i'm pretty sure. we just do "pkcon install-local foo.click"
[14:32] <cjwatson> probably an strace job to figure that out
[14:32] <dobey> yeah
[14:34] <cjwatson> I think dpkg-deb extracts the control area to a temporary directory, but that shouldn't be large
[14:34] <mvo_> dobey: iirc debsig-verify will unpack the signed bits into /tmp to verify them
[14:34] <cjwatson> ah, that could do it ...
[14:35] <dobey> oh
[14:35] <dobey> maybe we need to make /tmp not be tmpfs on the phone images then
[14:36] <rbasak> flexiondotorg: mate-hud> do you have a link to our previous discussion please?
[14:37] <flexiondotorg> rbasak, Maybe. I'll go hunting...
[14:37] <rbasak> flexiondotorg: sorry I don't remember it. I believe that we discussed it, but I'd like to remind myself of any context.
[14:39] <flexiondotorg> rbasak, My question: https://irclogs.ubuntu.com/2016/07/01/%23ubuntu-devel.html#t08:24
[14:39] <flexiondotorg> rbasak, You're reply - https://irclogs.ubuntu.com/2016/07/01/%23ubuntu-devel.html#t10:18
[14:39] <rbasak> flexiondotorg: thanks!
[14:39] <flexiondotorg> Or Your reply even.
[14:39] <mvo_> dobey: yeah, or use /var/tmp just for debsig-verify (if that is on a real FS)
[14:41] <dobey> mvo_: /var/tmp is in the read-only partition
[14:42] <LocutusOfBorg> pitti, I was wondering, python should migrate anyway, regardless of expat, so I guess there is no need to retry them against proposed, but just see python migrate and retry them
[14:42] <LocutusOfBorg> am I correct?
[14:42] <pitti> LocutusOfBorg: correct
[14:44] <rbasak> flexiondotorg: looks like I don't know what I'm doing, sorry :-/
[14:45] <rbasak> flexiondotorg: I thought MATE was a set automatically generated from the seed, but it's not in https://bitbucket.org/ubuntu-mate/mate-hud
[14:45] <rbasak> Uh, not in http://bazaar.launchpad.net/~developer-membership-board/+junk/packageset/view/head:/packageset-report
[14:45] <flexiondotorg> Yeah, I saw that. Derived from the seeds.
[14:46] <rbasak> flexiondotorg: I need to run, but I'll try and look again later and ask around for help. If I drop the ball, please ping me, or if you add it to the agenda before Monday's meeting, we can give someone an action to take care of it so we don't forget.
[14:46] <flexiondotorg> rbasak, OK. Thanks.
[14:46] <rbasak> flexiondotorg: +1 from me to add mate-hud to the MATE packageset, as it's obviously MATE only. So you don't need any more approval - I just don't know how to do it right now exactly.
[14:47] <rbasak> flexiondotorg: I'm also not sure what to do give it doesn't exist yet. You might need it sponsoring in so that it exists, then a seed change sponsored to seed it, and then the packagesets regenerated or something.
[14:48] <rbasak> *given
[14:48] <flexiondotorg> Understood.
[14:49] <rbasak> flexiondotorg: I'm stuck for time today, but I'd be happy to sponsor it for you tomorrow regardless of what we do about permissions in order to unblock you if that would be helpful.
[14:50] <flexiondotorg> Thanks!
[14:56] <Laney> rbasak: That looks like https://code.launchpad.net/~laney/+junk/packageset didn't get merged
[14:59] <rbasak> Laney: thanks, I'll look later
[15:20] <michael-vb> sladen: so looks like that "low graphics mode" problem was my bug after all.  Sorry for the noise.
[15:22] <sladen> michael-vb: what's important is that it gets tracked down and fixed.
[15:23] <sladen> michael-vb: could you write a full-debrief on the bug report of your present understanding how what is happening/where it needs fixing
[15:23] <michael-vb> Will do that, but the fix will be entirely in VirtualBox.
[15:23] <sladen> michael-vb: then this can all be tracked when new releases/patches are available and people can be pointed to the right versions,
[15:24] <michael-vb> Sure, will do that.
[15:25] <sladen> michael-vb: I did have a quick look this morning for libEGL/RTR3InitDll() etc and didn't immediately spot the cause, although there were a couple of possibilities, eg. around the env("DISPLAY") checking about server vs. client and the corresponding #ifdefs (from memory)
[15:27] <michael-vb> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/common/crOpenGL/egl.c#L136
[15:29] <michael-vb> Our local tree now has another check for the DISPLAY variable before that.  Very hack-ish I know, and Debian and Ubuntu would have a better solution, but I prefer an ugly solution that works everywhere to individual solutions for everyone.
[15:29] <michael-vb> Basically we provide client-side but not server-side OpenGL, and have to prevent the server from loading the library.
[15:29] <michael-vb> Like NVIDIA do.
[15:30] <michael-vb> But they have a few more people working on it and probably a cleaner solution.
[15:30] <michael-vb> Maybe.
[15:31] <LocutusOfBorg> I'm studying right now a solution like nvidia does, more debian and ubuntu friendly
[15:31] <LocutusOfBorg> I'm reading nvidia-graphic-drivers/debian/*.postinst
[15:32] <LocutusOfBorg> I still have to implement that in vbox, but I'll do eventually :)
[15:33] <michael-vb> For the Debian Additions package you can use the official Debian method which is nice and clean.
[15:33] <michael-vb> Can't immediately remember what it was, but of course I did look at it.
[15:37] <LocutusOfBorg> michael-vb,
[15:37] <LocutusOfBorg> update-alternatives --force \
[15:37] <LocutusOfBorg>             --install /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf x86_64-linux-gnu_gl_conf /usr/lib/nvidia-361/ld.so.conf 8604 \
[15:37] <LocutusOfBorg> this is what nvidia does
[15:37] <LocutusOfBorg> I have to do mostly the same
[15:38] <LocutusOfBorg> install two .conf files with the vbox directories
[15:38] <LocutusOfBorg> and update the default
[15:38] <michael-vb> Right, sounds nice and Debian-ish.
[15:38] <LocutusOfBorg> :)
[15:39] <LocutusOfBorg> the problem is to install the conf file, to update alternatives again on prerm, to check dkms module
[15:39] <semiosis> Odd_Bloke: if you're around, can you spare a moment to look at the conversation slangasek and I had yesterday about 'manage_etc_hosts: localhost' in the ubuntu-cpc images?  https://irclogs.ubuntu.com/2016/07/11/%23ubuntu-devel.html#t22:14
[15:39] <LocutusOfBorg> and most important *test everything* before uploading
[15:39] <LocutusOfBorg> and... ENOTIME :)
[15:39] <LocutusOfBorg> but I want to have the change for debian stretch
[15:39] <pitti> RAOF, arges: could you please review systemd/xenial? I uploaded it, so I can't self-review. thanks!
[15:48] <arges> pitti: ok i'll take a look in a bit
[16:24] <Laney> pitti: bos01 woes?
[16:26] <caribou> xnox: Is s390-tools still expected to set crashkernel= in /etc/zipl.conf ?
[16:26] <pitti> Laney: what, again?
[16:27] <pitti> arges: cheers!
[16:27] <Laney> pitti: 5 minutes ago or so
[16:27] <pitti> Laney: ah, I know: http://autopkgtest.ubuntu.com/running.shtml#queue-ubuntu-yakkety-ppc64el
[16:27] <pitti> this is bogus
[16:28] <pitti> this looks like using some outdated retry-autopkgtest-regressions script
[16:28] <pitti> Laney: cleaned these two and restarted
[16:29] <Laney> pitti: hmm
[16:29] <Laney> why did that kill it?
[16:30] <pitti> Laney: "autopkgtest exit with 1" is a Should Not HappenTM
[16:30]  * pitti tosses a lost compose key in there
[16:30] <pitti> Laney: "foo/1.2.3" is not a valid test spec, autopkgtest can't decipher what that means and exits with a CLI error
[16:31] <pitti> this could possibly be made more robust by ignoring/consuming and tossing away invalid test requests, but that would just  silently paper over problems somewhere else
[16:31] <pitti> not sure what to do with bogus queue entries..
[16:32] <coreycb> arges, bdmurray: hi, we have the following openstack SRUs in the queue if you have some time to chip away at them: http://paste.ubuntu.com/19187967/
[16:32] <Laney> Doesn't feel that valuable to me to kill the workers in this case
[16:32] <pitti> but this is what an outdated retry-autopkgtest-regressions would produce, so I'm betting on that
[16:33] <pitti> Laney: I like to immediately kill a worker on exit code 1, as that's a "Should Not Happen"; i. e. the worker itself could check the package argument for sanity and presumably basic_reject() it
[16:33] <pitti> then it'd stay in the queue forever until someone looks and cleans up
[16:33] <pitti> that could be a better failure mode
[16:33] <pitti> but much less visible
[16:35] <Laney> pitti: For malformed input you know it's not going to work, so an option is to remove it from the queue and display this somewhere or mail it to us, or something
[16:35] <Laney> This rogue person is probably going to run r-a-r again at some point
[16:35] <pitti> Laney: yes, remove + mail sounds good
[17:12] <xnox> caribou, no. you said you are taking that into the other package that provides crashing functionality
[17:12] <xnox> i think I will need to remove that from installer & s390-tools to migrate over to crashdump package.
[17:13] <caribou> xnox: yes I did, I just thought I had to remove it from s390-tools so everything is fine
[17:13] <xnox> caribou, i can handle removal from s390-tools and installer.
[17:13] <xnox> caribou, is it in yakkety & xenial now? or just yakkety for now?
[17:13] <caribou> xnox: fine, the version in Yakkety will set it if it is absent & I'm about to SRU the same to Xenial
[17:13] <xnox> cool.
[17:14] <caribou> xnox: with the cio_ignore fix & a few other things
[17:14] <caribou> xnox: to xenial, it's already in Y
[17:14] <cpaelzer> is there a trivial way to send something into apport handling to test an apport hook of an upload?
[17:15] <cpaelzer> I thought sending a SIGSEGV, but thats not kicking in as I hoped
[17:15] <cpaelzer> maybe I just need to enable something, but if there is a common sequence let me know
[17:16] <cpaelzer> hmm, actually I think it would be enough to call apport-bug without a crash - consider it solved
[17:38] <pitti> cpaelzer: yes, report a bug and save it or look at the data in the expander, or SIGKILL the program if your hook is specific to a crash
[17:43] <seb128> sil2100, shrug, so you ignored my NEW review for repowerd and landed it despite the blocker issue I gave you and bypassed NEW? :-(
[19:01] <pitti> Laney: meh, next mass-killing; I guess I'll actually teach the workers to verify the test argument now..
[19:04] <pitti> oh, seems it's britney itself which does those -- http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libtemplates-parser
[19:15] <pitti> nevermind, I was just reading this wrong
[19:34] <pitti> Laney: done
[19:44] <bdmurray> coreycb: Did you get anybody to look at those SRUs?
[19:44] <coreycb> bdmurray, hey, not yet
[19:56] <bdmurray> coreycb: Do you know why bug 1592865 was tagged v-done?
[19:57] <coreycb> bdmurray, that's a mistake, I updated the bug
[19:57] <coreycb> ddellav, ^
[19:58] <ddellav> coreycb ack
[20:54] <bdmurray> coreycb: could you add some comment about how you'll test stuff in bug 1501854
[20:54] <bdmurray> er 1601854
[21:02]  * kees has his eyes cross reading the gcc-5-cross debian/rules
[21:11] <bdmurray> coreycb: The ceilometer version would be greater than the one in yakkety...
[21:11] <coreycb> bdmurray, ok that's updated with test process
[21:12] <coreycb> bdmurray, hmm
[21:12] <coreycb> bdmurray, ok we need to fix that up then
[21:14] <bdmurray> coreycb: should I keep looking then or wait for ceilometer to be sorted?
[21:16] <coreycb> bdmurray, I could either drop ceilometer from that bug or else that bug is blocked by me until I situate ceilometer
[21:17] <coreycb> bdmurray, probably might as well leave ceilometer in that bug and I'll fix it up tomorrow