| 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:17 |
|---|---|---|
| nacc | doko: i'm also unclear on the use of dh-exec (it was added to python-ldb-dev.install it seems) | 00:26 |
| 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:40 |
| RAOF | pdeee: That is my understanding | 00:43 |
| RAOF | pdeee: I believe rbasak will be doing that review. | 00:44 |
| 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:46 |
| RAOF | I think he got the 2nd opinion from an archive admin. | 00:47 |
| === salem_ is now known as _salem | ||
| pdeee | great to hear! rbasak does that mean that we're basically ready? | 00:51 |
| === JanC_ is now known as JanC | ||
| 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? | 07:10 |
| 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:02 |
| rbasak | cpaelzer: yes | 08:03 |
| cpaelzer | rbasak: it seems we were wrong, but I'm still trying to understand | 08:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| rbasak | cpaelzer: what version did you need it to build against? | 08:10 |
| rbasak | 16.11-1? | 08:10 |
| rbasak | cpaelzer: and which package has the component mismatch please? | 08:13 |
| rbasak | Although component mismatches can't happen on build deps now. | 08:16 |
| rbasak | So it can't be that, can it? | 08:16 |
| cpaelzer | rbasak: sorry had a interrupt | 08:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| rbasak | cpaelzer: if you build locally with sbuild, does it build correctly? | 08:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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 | 08:42 |
| Laney | elopio: ah oops, I forgot to pull the commit to actually do the reboot /o\ /o\ /o\ | 09:04 |
| 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:13 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 | |
| juliank | Ah no, that was fixed there in 1.3~rc3 | 09:32 |
| Laney | elopio: FTR, it's a reboot required to actually apply the new linux cmdline | 10: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 | ||
| 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:33 |
| 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:34 |
| 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:35 |
| barry | jgrimm: +1 | 14:36 |
| jgrimm | thanks sir | 14:37 |
| rbasak | jgrimm: FWIW, there's a newer version of autopkgtest in yakkety backports | 14:40 |
| jgrimm | rbasak, oh.. i'll look, thanks | 14:41 |
| zul | doko: ping | 14:51 |
| 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 | 14:54 |
| doko | zul: unlikely today, leaving early | 15:01 |
| zul | doko: ok | 15:04 |
| zul | doko: thanks | 15:04 |
| slangasek | pitti: I was on autopkgtest-cloud-worker/0 when trying to access them | 15:05 |
| 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:06 |
| slangasek | pitti: ah, ok | 15:07 |
| pitti | (probably still in bash_history somewhere) | 15:07 |
| 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:16 |
| chiluk | was there a particular reason, or just because it's not obvious what work seyeong did in testing? | 15:17 |
| jgrimm | rbasak, barry: interstingly the -backports autopkgtest didn't exhibit the problem. \o/ | 15:24 |
| barry | yeah, that is interesting | 15:25 |
| 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:28 |
| 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:29 |
| Laney | mapreri: ricotz: Are either of you fixing the x265 ppc64el build failure? | 15:30 |
| 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:32 |
| Laney | ricotz: Was doing so in experimental too | 15:33 |
| Laney | ginggs: Yes | 15:33 |
| ricotz | Laney, I see | 15:33 |
| doko | rbasak: could you do the kombu and python-glanceclient validations for the trusty updates? | 15:40 |
| 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:43 |
| 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:44 |
| 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 | 15:59 |
| coreycb | doko, yes i will today. i think i already verified kombu. | 16:00 |
| ricotz | Laney, mapreri, simply disabling ALTIVEC should work | 16:00 |
| ricotz | e.g. https://paste.debian.net/plain/911927 | 16:02 |
| ricotz | this feature only concerns power8 | 16:02 |
| mapreri | ricotz: thanks, I'll see later for it. | 16:04 |
| 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:05 | |
| 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:10 |
| 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:11 |
| 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:12 |
| chiluk | either way I'll get it sorted tonight.. | 16:14 |
| Laney | ricotz: mapreri: yeh, will look | 16:15 |
| Laney | ricotz: mapreri: I uploaded that, thx | 18:06 |
| mapreri | Laney: 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 |
| 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* | 18:27 |
| 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 | 19:35 |
| === salem_ is now known as _salem | ||
| mapreri | Laney, ricotz: JFYI: started the rebuilds | 21:45 |
| 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:47 |
| 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:48 |
| mapreri | no, the ppc64el build picked up the old li | 21:49 |
| mapreri | lib* | 21:49 |
| ricotz | right | 21:49 |
| 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] | 21:50 |
| 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:25 |
| slangasek | do not know | 22:26 |
| slangasek | cyphermox: ^^ ? | 22:26 |
| 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:28 |
| mwhudson | googling leads me to http://knowledgebase.progress.com/articles/Article/000049337 | 22:29 |
| mwhudson | which does actually seem to work | 22:29 |
| mwhudson | but uh | 22:30 |
| mwhudson | i don't know what that's doing at all | 22:30 |
| cyphermox | loadkeys is redefining what happens when the system receives a keycode | 22:31 |
| 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:32 |
| mwhudson | cyphermox: any idea how to find it? | 22:37 |
| mwhudson | or who might know how to find it? | 22:37 |
| sladen | mwhudson: what are you wanting to do? Just put the keyboard in ansi mode? | 22:43 |
| sladen | mwhudson: I expect ncurses probably puts the keyboard in raw mode and does the magic/handling internally | 22:44 |
| mwhudson | sladen: in the linux console, by default shift tab just sends the tab character | 23:07 |
| 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 | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!