naccdoko: 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:17
naccdoko: i'm also unclear on the use of dh-exec (it was added to python-ldb-dev.install it seems)00:26
pdeeerbasak, 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:40
RAOFpdeee: That is my understanding00:43
RAOFpdeee: I believe rbasak will be doing that review.00:44
pdeeeRAOF, 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:46
RAOFI think he got the 2nd opinion from an archive admin.00:47
=== salem_ is now known as _salem
pdeeegreat to hear! rbasak does that mean that we're basically ready?00:51
=== JanC_ is now known as JanC
ginggsmitya57: 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?07:10
rbasakpdeee: 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
cpaelzerrbasak: 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
cpaelzerI happend to miss that it was blocked on the new queue at first08:02
cpaelzerthis was resolved and we discussed where on LP exactly one could/should check if it is available08:02
rbasakcpaelzer: yes08:03
cpaelzerrbasak: it seems we were wrong, but I'm still trying to understand08:03
cpaelzerrbasak: even after it showed up where we discussed last time it wasn't "pulled in" for the build08:04
cpaelzerrbasak: I'm currently assuming it was because of a (known) component mismatch in DPDK08:04
cpaelzerrbasak: 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 version08:04
cpaelzerrbasak: would that make sense?08:05
cpaelzerI 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 version08:05
cpaelzerI 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
cpaelzerso I want to full yunderstand08:07
rbasakI'm not sure myself.08:07
rbasakcpaelzer: what version did you need it to build against?08:10
rbasakcpaelzer: and which package has the component mismatch please?08:13
rbasakAlthough component mismatches can't happen on build deps now.08:16
rbasakSo it can't be that, can it?08:16
cpaelzerrbasak: sorry had a interrupt08:30
cpaelzerrbasak: yes 16.11-1 it should have build against08:31
cpaelzerrbasak: and I uploaded the no-change after https://launchpad.net/ubuntu/+source/dpdk showed us it was built and available in proposed08:31
cpaelzerrbasak: the component mismatch is on pytohn-elftools, you can see it e.g. in update_excuses08:32
cpaelzerrbasak: it is a runtime dependency08:32
cpaelzerrbasak: I have an upload to DPDK ready which drops that from a recommends to a suggests to make it happy08:32
cpaelzerrbasak: 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 ok08:33
cpaelzerrbasak: yet I want to time and order it absolutely correctly to avoid having more than one more rebuild of openvswitch08:33
cpaelzerrbasak: 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 version08:34
cpaelzerrbasak: 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 ovs08:35
cpaelzerrbasak: the DPDK upload also fixes a ppc test issue which currently blocks several reverse dependencies08:36
cpaelzerrbasak: I mentioned that yesterday on ubuntu-releae as FYI but I want to unblock all those other things08:36
cpaelzerrbasak: and it will pick up the new Xen08:37
cpaelzerall could be so fine if things ever would work as intended :-)08:37
rbasakcpaelzer: if you build locally with sbuild, does it build correctly?08:38
cpaelzerrbasak: 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
cpaelzerrbasak: you mean if I re-build openvswitch-dpdk with a proposed enabled sbuild locally?08:39
rbasakPublishing from Bileto copies the binaries, right?08:39
cpaelzerrbasak: yes it does08:39
cpaelzerDPDK binaries in that case08:39
rbasakSo is the Bileto build correct?08:39
rbasakOf openvswitch08:39
cpaelzerI have no openvswitch in it (yet)08:40
rbasakAh, OK.08:40
cpaelzerI could put the new openvswitch in there08:40
rbasakSo yes, try there or locally maybe?08:40
rbasakI don't know the answer, just suggesting how I'd approach figuring it out08:40
cpaelzeryeah, ovs in there would at least avoid polluting archive version numbers if things go wrong08:40
cpaelzerand doing "joint" migrations was one of the things in bileto I wanted to try anyway08:41
rbasakI understand your desire to understand what's really going on, but I don't know what's really going on :-/08:41
cpaelzerrbasak: one puzzle piece at a time08:41
cpaelzerfor now I just memorize component mismatches as a hiden inhibitor that I should consider in future08:41
cpaelzermabye later on somebody else can shed some extra light on it after reading this08:42
rbasakNow that builds always have universe enabled, I don't see how a component mismatch can have anything to do with it08:42
Laneyelopio: ah oops, I forgot to pull the commit to actually do the reboot /o\ /o\ /o\09:04
pittibarry, slangasek: you can reach the arm64 runners from the autopkgtest-cloud-worker/0 instance (they have its ssh key)09:13
pittinobody from outside is supposed to have ssh access (I didn't have either)09:13
josvazGot some questions about development from a PPA (Eg. https://launchpad.net/~cloud-support/+archive/ubuntu/rax-devel/+packages pkg rax-openstack-guest-agents)09:27
josvazI 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 case09:28
josvazthen use dpkg-source -x ...dsc to get the sources ready to work with them09:28
josvazAnything special there I might be missing?09:28
josvazcause 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
josvazcan it be I am missing some cleanup command?09:29
josvazI am using debuild to build the source09:29
juliankEww, seems I forgot to cherry-pick the changes for apt 1.2.17 in xenial (bug 1642386) into yakkety. How odd09:31
ubottubug 1642386 in apt (Ubuntu) "At least one invalid signature was encountered." [High,Fix released] https://launchpad.net/bugs/164238609:31
* juliank is supposed to c-p downwards and not just skip branches :/09:31
juliankAh no, that was fixed there in 1.3~rc309:32
Laneyelopio: FTR, it's a reboot required to actually apply the new linux cmdline10:02
=== _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
jgrimmbarry, FWIW, I seem to be hitting exactly this too -> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783202#1914:33
ubottuDebian bug 783202 in autopkgtest "[adt-buildvm-ubuntu-cloud] timeout nearly after display "Net device info"" [Normal,Open]14:33
barryjgrimm: that went away for me when i upgraded to zesty.  what are you on?14:34
jgrimmyakkety. :)14:34
barrythere ya go ;)14:34
jgrimmsame delays, same final timeout error. :)14:34
barryi never did figure out why yakkety had that problem14:34
jgrimmI'll upgrade my nuc to zesty and see if it goes away for me too.  but i'll probably file an ubuntu bug at least14:35
barryjgrimm: +114:36
jgrimmthanks sir14:37
rbasakjgrimm: FWIW, there's a newer version of autopkgtest in yakkety backports14:40
jgrimmrbasak, oh.. i'll look, thanks14:41
zuldoko: ping14:51
elopiothanks Laney :)14:54
zuldoko: when you get a chance can you review python-os-xenapi its in source new and nova is is in dep-wait because of it14:54
dokozul: unlikely today, leaving early15:01
zuldoko: ok15:04
zuldoko: thanks15:04
slangasekpitti: I was on autopkgtest-cloud-worker/0 when trying to access them15:05
pittislangasek: oh sorry -- I meant wendigo, Laney and me created the instances from there15:06
pittislangasek: i. e. nova boot with https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/armhf-lxd-slave.userdata as userdata15:06
slangasekpitti: ah, ok15:07
pitti(probably still in bash_history somewhere)15:07
chilukbdmurray: why did you undo the verification for LP: #1587039 ?15:16
ubottuLaunchpad bug 1587039 in qemu (Ubuntu Trusty) "aio: strengthen memory barriers for bottom half scheduling" [Undecided,Fix committed] https://launchpad.net/bugs/158703915:16
chilukwas there a particular reason, or just because it's not obvious what work seyeong did in testing?15:17
jgrimmrbasak, barry: interstingly the -backports autopkgtest didn't exhibit the problem.  \o/15:24
barryyeah, that is interesting15:25
slangasekpitti: 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:28
slangaseksure does15:29
slangasekLaney: thanks15:29
slangasekand indeed, I did wonder that I didn't see any logic to reboot them15:29
Laneynp, sorry for the bus factor15:29
Laneymapreri: ricotz: Are either of you fixing the x265 ppc64el build failure?15:30
ricotzLaney, oh, wasn't aware that it failed15:32
ginggsLaney: https://bitbucket.org/multicoreware/x265/issues/320/fail-to-build-on-power8-le15:32
Laneyricotz: Was doing so in experimental too15:33
Laneyginggs: Yes15:33
ricotzLaney, I see15:33
dokorbasak: could you do the kombu and python-glanceclient validations for the trusty updates?15:40
rbasakdoko: I don't see kombu. python-glanceclient would normally be done by the openstack team. Any particular reason you're asking me?15:43
dokorbasak: hmm, wait, you didn't do the updates ...15:44
bdmurraychiluk: Because there was no indication what testing was performed.15:44
dokocoreycb: could you do the kombu and python-glanceclient validations for the trusty updates?15:44
mapreriLaney: I sent it upstream, but haven't yet had time to deal with it myself /cc ricotz15:59
maprerioh, ginggs linked it already15:59
* mapreri is busy15:59
Laneymapreri: Right, I saw it, just a bit annoying due to being a transition15:59
coreycbdoko, yes i will today.  i think i already verified kombu.16:00
ricotzLaney, mapreri, simply disabling ALTIVEC should work16:00
ricotze.g. https://paste.debian.net/plain/91192716:02
ricotzthis feature only concerns power816:02
mapreriricotz: thanks, I'll see later for it.16:04
mapreriLaney: yeah, I didn't check the buildd in debian before syncing...16:05
* mapreri → afk for some more time16:05
chilukYeah bdmurray, I'll get that sorted with seyeongkim later today.  I highly suspect that he did testing, but it got lost in translation16:10
chilukbdmurray... from what he's said it may not be easy to do bug verification, so we may have to live regression testing instead.16:11
chilukbdmurray: if it makes you feel better a large cloud is already running with those fixes.16:12
chilukI frankly feel that to be almost verification enough.16:12
chilukeither way I'll get it sorted tonight..16:14
Laneyricotz: mapreri: yeh, will look16:15
Laneyricotz: mapreri: I uploaded that, thx18:06
mapreriLaney: thank you.  Should I proceed with the rebuild of the relevant rdep(s)?18:14
mapreri(published 6 minutes ago, for all archs already)18:15
jbichamapreri: you might need to wait a bit longer for the repos the Launchpad builders use to get the new binaries18:27
maprerijbicha: sure, I'd do that later anyway, I don't have the needed right now.18:27
jbichaby the time rmadison shows the new files, you should be fine though18:27
maprerineeded key*18:27
gQuigsoops.. I missed that the verification tags got reset - https://bugs.launchpad.net/python-jujuclient/+bug/164415319:35
ubottuLaunchpad bug 1644153 in python-jujuclient "SSL handshake fails on xenial, yakkety, zesty" [Undecided,New]19:35
gQuigsshould be good to SRU19:35
=== salem_ is now known as _salem
mapreriLaney, ricotz: JFYI: started the rebuilds21:45
ricotzmapreri, handbrake and libav?21:47
ricotzI mean ffmpeg21:47
maprerinot only those, but yes21:47
ricotzand vlc21:47
maprerisee https://release.debian.org/transitions/html/auto-x265.html for a start (ok, debian, but the list should be pretty much the same)21:47
mapreriI'll see if there are more once the update_output log becomes readable21:48
mapreriand/or I'll be bothered enough to deal with that grep-dctrl invocation I can never remember21:48
ricotzgst-bad should be fine already21:48
maprerino, the ppc64el build picked up the old li21:49
maprerihttps://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]21:50
mwhudsonslangasek, 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:25
slangasekdo not know22:26
slangasekcyphermox: ^^ ?22:26
cyphermoxI don't know22:28
cyphermoxif it's the case, it's certainly some termios magic that won't be all that obvious22:28
mwhudsongoogling leads me to http://knowledgebase.progress.com/articles/Article/00004933722:29
mwhudsonwhich does actually seem to work22:29
mwhudsonbut uh22:30
mwhudsoni don't know what that's doing at all22:30
cyphermoxloadkeys is redefining what happens when the system receives a keycode22:31
cyphermoxthat would probably be stuff in console-setup22:32
sladenscancode -> linux keycode -> /dev/input code -> ansi sequence -> X mapping -> X keypress22:32
mwhudsonsladen: talking about the console here, no X at least :)22:32
mwhudsoncyphermox: any idea how to find it?22:37
mwhudsonor who might know how to find it?22:37
sladenmwhudson: what are you wanting to do?  Just put the keyboard in ansi mode?22:43
sladenmwhudson: I expect ncurses probably puts the keyboard in raw mode and does the magic/handling internally22:44
mwhudsonsladen: in the linux console, by default shift tab just sends the tab character23:07
mwhudsonsladen: in d-i though, it sends, well, something different, probably \033[Z23:08
mwhudsonsladen: i want to find the code that makes that change23:08

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!