[00:17] <nacc> doko: also, there seems to be an undocumented change to drop the CFLAGS support ('noopt' in DEB_BUILD_OPTIONS), not sure if that was intentionally done (or which changelog entry it corresponds to)
[00:26] <nacc> doko: i'm also unclear on the use of dh-exec (it was added to python-ldb-dev.install it seems)
[00:40] <pdeee> rbasak, RAOF, hlieberman: am I correct in undetstanding that the only outstanding task for the Certbot SRU is getting an extra reviewer for the change to the python-letsencrypt package?
[00:43] <RAOF> pdeee: That is my understanding
[00:44] <RAOF> pdeee: I believe rbasak will be doing that review.
[00:46] <pdeee> RAOF, in comment #27 he said that he wanted someone else to do it. But I'd be happy to hear that is no longer the case! :)
[00:47] <RAOF> I think he got the 2nd opinion from an archive admin.
=== salem_ is now known as _salem
[00:51] <pdeee> great to hear! rbasak does that mean that we're basically ready?
=== JanC_ is now known as JanC
[07:10] <ginggs> mitya57: hi, would you please look at this build failure https://launchpad.net/ubuntu/+source/python-hypothesis/3.6.1-1ubuntu6 - is this a bug in sphinx?
[08:02] <rbasak> pdeee: I had some notes, but they're not on this computer. I'll pull them out within a couple of hours. I had a couple of minor requests only. IIRC, a changelog and NEWS entry describing the behaviour change (that the cronjob is now active) was one of them. And update-maintainer. I'll check for others when I can get to the notes.
[08:02] <cpaelzer> rbasak: hiho, do you remember when we discussed last week about "when exactly" the dpdk upload will be ready to do a no change rebuild for openvswitch-dpdk?
[08:02] <cpaelzer> I happend to miss that it was blocked on the new queue at first
[08:02] <cpaelzer> this was resolved and we discussed where on LP exactly one could/should check if it is available
[08:03] <rbasak> cpaelzer: yes
[08:03] <cpaelzer> rbasak: it seems we were wrong, but I'm still trying to understand
[08:04] <cpaelzer> rbasak: even after it showed up where we discussed last time it wasn't "pulled in" for the build
[08:04] <cpaelzer> rbasak: I'm currently assuming it was because of a (known) component mismatch in DPDK
[08:04] <cpaelzer> rbasak: that way it might have appeared on LP as if it would be "all ready" but the later rebuild of openvswitch still took the old version
[08:05] <cpaelzer> rbasak: would that make sense?
[08:05] <cpaelzer> I got to this as I have tests failing now looking for old sonames, and then checked the openvswitch build log to find it using the older version
[08:07] <cpaelzer> I have a new DPDK which would get rid of the component mismatch for now, but really really want to avoid inflating openvswitch no-change-rebuilds too much :-)
[08:07] <cpaelzer> so I want to full yunderstand
[08:07] <rbasak> I'm not sure myself.
[08:10] <rbasak> cpaelzer: what version did you need it to build against?
[08:10] <rbasak> 16.11-1?
[08:13] <rbasak> cpaelzer: and which package has the component mismatch please?
[08:16] <rbasak> Although component mismatches can't happen on build deps now.
[08:16] <rbasak> So it can't be that, can it?
[08:30] <cpaelzer> rbasak: sorry had a interrupt
[08:31] <cpaelzer> rbasak: yes 16.11-1 it should have build against
[08:31] <cpaelzer> rbasak: and I uploaded the no-change after https://launchpad.net/ubuntu/+source/dpdk showed us it was built and available in proposed
[08:32] <cpaelzer> rbasak: the component mismatch is on pytohn-elftools, you can see it e.g. in update_excuses
[08:32] <cpaelzer> rbasak: it is a runtime dependency
[08:32] <cpaelzer> rbasak: I have an upload to DPDK ready which drops that from a recommends to a suggests to make it happy
[08:33] <cpaelzer> rbasak: a bit of version magic as we will have to be "in front of" Debian for a few weeks because of their freeze, but other than that ok
[08:33] <cpaelzer> rbasak: yet I want to time and order it absolutely correctly to avoid having more than one more rebuild of openvswitch
[08:34] <cpaelzer> rbasak: I have the new DPDK in bileto and all is fine, except - of course - the dependent openvswitch test fails because it was build against the too old version
[08:35] <cpaelzer> rbasak: Now I wonder if that would be the right approach 1. publish new dpdk without component mismatch from bileto; 2. once that is available and passed dependencies in update_excuses it will block on the openvswitch test 3. only after that I'll upload another (hopefully final) no-change to ovs
[08:36] <cpaelzer> rbasak: the DPDK upload also fixes a ppc test issue which currently blocks several reverse dependencies
[08:36] <cpaelzer> rbasak: I mentioned that yesterday on ubuntu-releae as FYI but I want to unblock all those other things
[08:37] <cpaelzer> rbasak: and it will pick up the new Xen
[08:37] <cpaelzer> all could be so fine if things ever would work as intended :-)
[08:38] <rbasak> cpaelzer: if you build locally with sbuild, does it build correctly?
[08:39] <cpaelzer> rbasak: remaining open question - I'm not sure yet if the publish from Bileto will be right to get this as intended or if instead I'd have to upload "normally"
[08:39] <cpaelzer> rbasak: you mean if I re-build openvswitch-dpdk with a proposed enabled sbuild locally?
[08:39] <rbasak> Publishing from Bileto copies the binaries, right?
[08:39] <cpaelzer> rbasak: yes it does
[08:39] <cpaelzer> DPDK binaries in that case
[08:39] <rbasak> So is the Bileto build correct?
[08:39] <rbasak> Of openvswitch
[08:40] <cpaelzer> I have no openvswitch in it (yet)
[08:40] <cpaelzer> right
[08:40] <rbasak> Ah, OK.
[08:40] <cpaelzer> I could put the new openvswitch in there
[08:40] <rbasak> So yes, try there or locally maybe?
[08:40] <rbasak> I don't know the answer, just suggesting how I'd approach figuring it out
[08:40] <cpaelzer> yeah, ovs in there would at least avoid polluting archive version numbers if things go wrong
[08:41] <cpaelzer> and doing "joint" migrations was one of the things in bileto I wanted to try anyway
[08:41] <rbasak> I understand your desire to understand what's really going on, but I don't know what's really going on :-/
[08:41] <cpaelzer> rbasak: one puzzle piece at a time
[08:41] <cpaelzer> for now I just memorize component mismatches as a hiden inhibitor that I should consider in future
[08:42] <cpaelzer> mabye later on somebody else can shed some extra light on it after reading this
[08:42] <rbasak> Now that builds always have universe enabled, I don't see how a component mismatch can have anything to do with it
[09:04] <Laney> elopio: ah oops, I forgot to pull the commit to actually do the reboot /o\ /o\ /o\
[09:13] <pitti> barry, slangasek: you can reach the arm64 runners from the autopkgtest-cloud-worker/0 instance (they have its ssh key)
[09:13] <pitti> nobody from outside is supposed to have ssh access (I didn't have either)
[09:27] <josvaz> Got some questions about development from a PPA (Eg. https://launchpad.net/~cloud-support/+archive/ubuntu/rax-devel/+packages pkg rax-openstack-guest-agents)
[09:28] <josvaz> I am gussing to start development (if you lack a LP repo) you should download the .dsc orig.tar.gz and the debian.tar.xz in this case
[09:28] <josvaz> then use dpkg-source -x ...dsc to get the sources ready to work with them
[09:28] <josvaz> Anything special there I might be missing?
[09:29] <josvaz> cause when I build the package it does build clean the first time, but the second it complains that a file I did no touch had been modified (by the build scripts I guess)
[09:29] <josvaz> can it be I am missing some cleanup command?
[09:29] <josvaz> I am using debuild to build the source
[09:31] <juliank> Eww, seems I forgot to cherry-pick the changes for apt 1.2.17 in xenial (bug 1642386) into yakkety. How odd
[09:31] <ubottu> bug 1642386 in apt (Ubuntu) "At least one invalid signature was encountered." [High,Fix released] https://launchpad.net/bugs/1642386
[09:31]  * juliank is supposed to c-p downwards and not just skip branches :/
[09:32] <juliank> Ah no, that was fixed there in 1.3~rc3
[10:02] <Laney> elopio: FTR, it's a reboot required to actually apply the new linux cmdline
=== _salem is now known as salem_
=== hikiko is now known as hikiko|ln
=== mardy_ is now known as mardy
=== hikiko|ln is now known as hikiko
[14:33] <jgrimm> barry, FWIW, I seem to be hitting exactly this too -> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783202#19
[14:33] <ubottu> Debian bug 783202 in autopkgtest "[adt-buildvm-ubuntu-cloud] timeout nearly after display "Net device info"" [Normal,Open]
[14:34] <barry> jgrimm: that went away for me when i upgraded to zesty.  what are you on?
[14:34] <jgrimm> yakkety. :)
[14:34] <barry> there ya go ;)
[14:34] <jgrimm> same delays, same final timeout error. :)
[14:34] <barry> i never did figure out why yakkety had that problem
[14:35] <jgrimm> I'll upgrade my nuc to zesty and see if it goes away for me too.  but i'll probably file an ubuntu bug at least
[14:36] <barry> jgrimm: +1
[14:37] <jgrimm> thanks sir
[14:40] <rbasak> jgrimm: FWIW, there's a newer version of autopkgtest in yakkety backports
[14:41] <jgrimm> rbasak, oh.. i'll look, thanks
[14:51] <zul> doko: ping
[14:54] <elopio> thanks Laney :)
[14:54] <zul> doko: when you get a chance can you review python-os-xenapi its in source new and nova is is in dep-wait because of it
[15:01] <doko> zul: unlikely today, leaving early
[15:04] <zul> doko: ok
[15:04] <zul> doko: thanks
[15:05] <slangasek> pitti: I was on autopkgtest-cloud-worker/0 when trying to access them
[15:06] <pitti> slangasek: oh sorry -- I meant wendigo, Laney and me created the instances from there
[15:06] <pitti> slangasek: i. e. nova boot with https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/armhf-lxd-slave.userdata as userdata
[15:07] <slangasek> pitti: ah, ok
[15:07] <pitti> (probably still in bash_history somewhere)
[15:16] <Laney> ya
[15:16] <chiluk> bdmurray: why did you undo the verification for LP: #1587039 ?
[15:16] <ubottu> Launchpad bug 1587039 in qemu (Ubuntu Trusty) "aio: strengthen memory barriers for bottom half scheduling" [Undecided,Fix committed] https://launchpad.net/bugs/1587039
[15:17] <chiluk> was there a particular reason, or just because it's not obvious what work seyeong did in testing?
[15:24] <jgrimm> rbasak, barry: interstingly the -backports autopkgtest didn't exhibit the problem.  \o/
[15:25] <barry> yeah, that is interesting
[15:28] <slangasek> pitti: indeed, it is in scrollback, and actually shows the runners do have the correct commandline.  Does this mean Laney got in and fixed this before me?
[15:29] <slangasek> sure does
[15:29] <slangasek> Laney: thanks
[15:29] <slangasek> and indeed, I did wonder that I didn't see any logic to reboot them
[15:29] <Laney> np, sorry for the bus factor
[15:30] <Laney> mapreri: ricotz: Are either of you fixing the x265 ppc64el build failure?
[15:32] <ricotz> Laney, oh, wasn't aware that it failed
[15:32] <ginggs> Laney: https://bitbucket.org/multicoreware/x265/issues/320/fail-to-build-on-power8-le
[15:33] <Laney> ricotz: Was doing so in experimental too
[15:33] <Laney> ginggs: Yes
[15:33] <ricotz> Laney, I see
[15:40] <doko> rbasak: could you do the kombu and python-glanceclient validations for the trusty updates?
[15:43] <rbasak> doko: I don't see kombu. python-glanceclient would normally be done by the openstack team. Any particular reason you're asking me?
[15:44] <doko> rbasak: hmm, wait, you didn't do the updates ...
[15:44] <bdmurray> chiluk: Because there was no indication what testing was performed.
[15:44] <doko> coreycb: could you do the kombu and python-glanceclient validations for the trusty updates?
[15:59] <mapreri> Laney: I sent it upstream, but haven't yet had time to deal with it myself /cc ricotz
[15:59] <mapreri> oh, ginggs linked it already
[15:59]  * mapreri is busy
[15:59] <Laney> mapreri: Right, I saw it, just a bit annoying due to being a transition
[16:00] <coreycb> doko, yes i will today.  i think i already verified kombu.
[16:00] <ricotz> Laney, mapreri, simply disabling ALTIVEC should work
[16:02] <ricotz> e.g. https://paste.debian.net/plain/911927
[16:02] <ricotz> this feature only concerns power8
[16:04] <mapreri> ricotz: thanks, I'll see later for it.
[16:05] <mapreri> Laney: yeah, I didn't check the buildd in debian before syncing...
[16:05] <mapreri> sorry
[16:05]  * mapreri → afk for some more time
[16:10] <chiluk> Yeah bdmurray, I'll get that sorted with seyeongkim later today.  I highly suspect that he did testing, but it got lost in translation
[16:11] <chiluk> bdmurray... from what he's said it may not be easy to do bug verification, so we may have to live regression testing instead.
[16:12] <chiluk> bdmurray: if it makes you feel better a large cloud is already running with those fixes.
[16:12] <chiluk> I frankly feel that to be almost verification enough.
[16:14] <chiluk> either way I'll get it sorted tonight..
[16:15] <Laney> ricotz: mapreri: yeh, will look
[18:06] <Laney> ricotz: mapreri: I uploaded that, thx
[18:14] <mapreri> Laney: thank you.  Should I proceed with the rebuild of the relevant rdep(s)?
[18:15] <mapreri> (published 6 minutes ago, for all archs already)
[18:27] <jbicha> mapreri: you might need to wait a bit longer for the repos the Launchpad builders use to get the new binaries
[18:27] <mapreri> jbicha: sure, I'd do that later anyway, I don't have the needed right now.
[18:27] <jbicha> by the time rmadison shows the new files, you should be fine though
[18:27] <mapreri> needed key*
[19:35] <gQuigs> oops.. I missed that the verification tags got reset - https://bugs.launchpad.net/python-jujuclient/+bug/1644153
[19:35] <ubottu> Launchpad bug 1644153 in python-jujuclient "SSL handshake fails on xenial, yakkety, zesty" [Undecided,New]
[19:35] <gQuigs> should be good to SRU
=== salem_ is now known as _salem
[21:45] <mapreri> Laney, ricotz: JFYI: started the rebuilds
[21:47] <ricotz> mapreri, handbrake and libav?
[21:47] <ricotz> I mean ffmpeg
[21:47] <mapreri> not only those, but yes
[21:47] <ricotz> and vlc
[21:47] <mapreri> see https://release.debian.org/transitions/html/auto-x265.html for a start (ok, debian, but the list should be pretty much the same)
[21:48] <mapreri> I'll see if there are more once the update_output log becomes readable
[21:48] <mapreri> and/or I'll be bothered enough to deal with that grep-dctrl invocation I can never remember
[21:48] <ricotz> gst-bad should be fine already
[21:49] <mapreri> no, the ppc64el build picked up the old li
[21:49] <mapreri> lib*
[21:49] <ricotz> right
[21:50] <mapreri> https://launchpadlibrarian.net/304596806/buildlog_ubuntu-zesty-ppc64el.gst-plugins-bad1.0_1.10.3-1ubuntu1_BUILDING.txt.gz => Get:373 http://ftpmaster.internal/ubuntu zesty/universe ppc64el libx265-95 ppc64el 2.1-2 [1111 kB]
[22:25] <mwhudson> slangasek, infinity: do either of you happen to know if debian-installer does Something(tm) to get 'shift tab' to emit '\033[Z' on the linux console rather than just ^I?
[22:26] <slangasek> do not know
[22:26] <slangasek> cyphermox: ^^ ?
[22:28] <cyphermox> I don't know
[22:28] <cyphermox> if it's the case, it's certainly some termios magic that won't be all that obvious
[22:29] <mwhudson> googling leads me to http://knowledgebase.progress.com/articles/Article/000049337
[22:29] <mwhudson> which does actually seem to work
[22:30] <mwhudson> but uh
[22:30] <mwhudson> i don't know what that's doing at all
[22:31] <cyphermox> loadkeys is redefining what happens when the system receives a keycode
[22:32] <cyphermox> that would probably be stuff in console-setup
[22:32] <sladen> scancode -> linux keycode -> /dev/input code -> ansi sequence -> X mapping -> X keypress
[22:32] <mwhudson> sladen: talking about the console here, no X at least :)
[22:37] <mwhudson> cyphermox: any idea how to find it?
[22:37] <mwhudson> or who might know how to find it?
[22:43] <sladen> mwhudson: what are you wanting to do?  Just put the keyboard in ansi mode?
[22:44] <sladen> mwhudson: I expect ncurses probably puts the keyboard in raw mode and does the magic/handling internally
[23:07] <mwhudson> sladen: in the linux console, by default shift tab just sends the tab character
[23:08] <mwhudson> sladen: in d-i though, it sends, well, something different, probably \033[Z
[23:08] <mwhudson> sladen: i want to find the code that makes that change