[02:10] Logan: Hey, so what did you find out with kanatest? === giraffe is now known as Guest17892 === AdmWiggin is now known as tianon [07:01] Hey, so after seeing some tests that should not be failing, I ran autopkgtest -U --apt-pocket=proposed -- lxc autopkgtest-artful on ruby-net-scp and that passed for me. [07:01] http://autopkgtest.ubuntu.com/packages/r/ruby-net-sftp/artful/amd64 also shouldn't have failed. [07:03] 34 tests, 66 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications [07:03] 100% passed [07:04] nice [07:05] I know because I prepped several uploads in Debian for ruby-net-ssh. :P [07:08] mwhudson: Should I ask where you are? You seem to always be alive in the 'dead zone'. [07:11] Is there a way to get them testing against -proposed? [07:15] Unit193: the tests can be triggered against additional packages [07:16] ginggs: ruby-net-scp/ruby-net-sftp need --apt-pocket=proposed=src:ruby-net-ssh [07:20] Unit193: retrying [07:20] Thanks! [07:20] I understand I don't have permissions for it, but how? [07:22] Unit193: do you see the links for retrying (they look like recycle icons) on http://autopkgtest.ubuntu.com/packages/r/ruby-net-sftp/artful/amd64 ? [07:24] ginggs: I did, but since it needed a package from -proposed I thought the fine tuning would be different. [07:24] Unit193: ok, so look at the URL of one of the retry links, then add '&trigger=ruby-net-ssh%2F1%3A4.1.0-1' [07:25] That's officially 'fun'. Thanks. [07:49] Unit193: nz [07:50] yes, retry url hacking is fun [07:50] you can also add &all-proposed=1 [07:52] Ah. I'm not core nor motu (just packageset), so not (yet) really able to useit. [07:52] mwhudson, what is the last thing blocking python3.6? [07:52] Unit193, I stole your wine-development merge [07:53] I had one? [07:53] Thanks, LocutusOfBorg! [07:53] you asked me to sponsor that for you [07:53] Good enough. :) [07:57] go cmake, go [08:21] LocutusOfBorg: yara ftbfs on armhf [08:21] ack [08:21] LocutusOfBorg: which i am hacking almightily now [08:21] I'm fixing the last gtk-d failures [08:21] oh wonderful [08:27] oh boy this code really expects aligned access to work [08:44] like, a lot [08:57] xnox: what do you think about removing the existing yara binaries on armhf? (and rdeps i guess) [09:13] xnox, slangasek, doko: sent an update to ubuntu-devel about yara === nikow1 is now known as nikow [10:34] can I ask for a little perl advice? [10:34] Laney, the debhelper merge is ready, but I fail to parse the Ubuntu version [10:34] you what? [10:35] perl -e ' undef $/; foreach (@ARGV) { open (IN, $_) or die "$_: $!"; $file=; close IN; if ($file=~m/=head1 .*?\n\n(.*?) - (.*?)\n\n/s) { my $item="=item $1(1)\n\n$2\n\n"; if (" dh_installmanpages " !~ / $1 /) { $list.=$item; } else { $list_deprecated.=$item; } } } END { my $recommended_compat = 10.6.4ubuntu1; $recommended_compat =~ s{\..*}{}; while () { s/#LIST#/$list/; s/#LIST_DEPRECATED#/$list_deprecated/; [10:35] s/#RECOMMEDED_COMPAT#/$recommeded_compat/; print; }; }' dh_auto_build dh_auto_clean dh_auto_configure dh_auto_install dh_auto_test dh_bugfiles dh_builddeb dh_clean dh_compress dh_fixperms dh_gconf dh_gencontrol dh_icons dh_install dh_installcatalogs dh_installchangelogs dh_installcron dh_installdeb dh_installdebconf dh_installdirs dh_installdocs dh_installemacsen dh_installexamples dh_installgsettings dh_installifupdown [10:35] dh_installinfo dh_installinit dh_installlogcheck dh_installlogrotate dh_installman dh_installmanpages dh_installmenu dh_installmime dh_installmodules dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_link dh_lintian dh_listpackages dh_makeshlibs dh_md5sums dh_missing dh_movefiles dh_perl dh_prep dh_shlibdeps dh_strip dh_systemd_enable dh_systemd_start dh_testdir dh_testroot dh_ucf dh_update_autotools_c [10:35] onfig dh_usrlocal | \ [10:35] pod2man --utf8 -c Debhelper -r "10.6.4ubuntu1" --name="debhelper" --section=7 > debhelper.7 [10:35] https://launchpadlibrarian.net/330668177/buildlog_ubuntu-artful-amd64.debhelper_10.6.4ubuntu1_BUILDING.txt.gz [10:35] bad copy-paste [10:35] forcing VERSION=10 "fixes" it, but it is hacky and bad [10:35] solution is to drop that ubuntu in recommended compat, right? [10:37] the question is: should I revert somewhere this? https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=d2ca3a7f964eb915035c4526baa92325d3f6dbd7 [10:37] $$recommended_compat =~ s{\..*}{}; [10:37] this is what fails [10:38] is it calculating that variable wrong? [10:40] the problem is that rege [10:40] with the debian version 10.6.4 is returning "10" [10:40] with the ubuntu version, 10.6.4ubuntu1 it returns "can't parse foobar" [10:40] Bareword found where operator expected at -e line 1, near "10.6.4ubuntu1" [10:41] so, this code "$recommended_compat =~ s{\..*}{};" is having issues [10:43] FWIW doing this VERSION=$(shell dpkg-parsechangelog -SVersion |cut -f 1 -d "u") also works, because it strips the "ubuntu" part from version [10:43] LocutusOfBorg: Looks like it should be quoted? [10:43] my $recommended_compat = 10.6.4ubuntu1; [10:44] Yeah that probably just wants to be my $$recommended_compat = q($(VERSION)); [10:44] or similar [10:46] hmm, do I have upstream commit access [10:49] doesn't look like it [10:54] sorry, bad connection sigh [10:55] seems not good, man ./debhelper.7 shows: "#RECOMMEDED_COMPAT#" instead of 10 [10:56] I'm preparing a patch [10:56] ack, do you want to directly upload debhelper? I can give you the merge, or you can just grab from the ppa above [10:57] not especially [10:57] I'll send a patch to Debian [10:58] ok thanks [11:02] There's some "recommeded" / "recommended" confusion too. [11:04] yes, I'm fixing that [11:05] Nod [11:05] so also debian manpages should be bad [11:06] yes lol [11:10] indeed [11:14] ... and a lack of s///g ... [11:24] LocutusOfBorg,Laney: https://bugs.debian.org/869780 [11:24] Debian bug 869780 in debhelper "debhelper: recommended compat version substitution is totally broken" [Normal,Open] [11:25] feel free to cherry-pick or whatever [11:36] cjwatson: Ta [11:36] LocutusOfBorg: You going to take that? [12:11] juliank: are you ok with the smaller patch against apt in LP: #1690980 ? [12:11] Launchpad bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980 [12:12] Laney, will upload in ppa [12:12] sorry I was @lunch [12:12] * Laney nod [12:14] rbalint: Tech side is OK, but I'm thinking about the commit message summary. It's a bit long, does not mention the timeout, and mentions shutdown, whereas it's any service stop that is affected? [12:15] Gracefully terminate processes apt-daily-upgrade.service on stop? [12:15] Laney, do you want to do some testing before I upload to Ubuntu? I admit, I'm worried about it :) [12:16] juliank: thanks that's clear and short [12:16] oh, it's missing a word [12:16] juliank: so sure, feel free to change it [12:16] Gracefully terminate processes *in* apt-daily-upgrade.service on stop [12:17] do you plan landing 1.2.25 in xenial in the near future? [12:18] Let's go with "Gracefully terminate process when stopping apt-daily-upgrade" [12:19] rbalint: Hey, I'm waiting for 1.2.24 since 5 weeks or so to enter proposed. 1.2.25 is basically scheduled now-ish, after the next 1.5 beta (and 1.4.8) [12:20] I did not yet push even 1.4.7 to zesty, as I'm waiting for 1.4.6 to be approved first [12:20] And AFAIUI, updates are supposed to be in newer suites before older ones. [12:22] So, the plan would be to have the service fix in 1.5~beta2, cherry pick to a 1.4.8 release, and cherry-pick that and the stuff from 1.4.7 into 1.2.25 [12:23] see bug 1702326 for the changes in 1.4.7 [12:23] bug 1702326 in apt (Ubuntu Zesty) "New microrelease 1.4.7 for zesty" [Medium,Triaged] https://launchpad.net/bugs/1702326 [12:24] (basically minor (in size) fixes to the http method to correctly handle some server responses) [12:24] juliank: ok, thanks! [12:24] There are no other fixes scheduled for 1.4.8 at the moment, so that would be just the service change :) [12:27] Oh, I see DonKult has some fixes in his repo he did not push yet [12:29] mvo: i'm fairly confident in the u-u PR, maybe could you please take a look again? [12:29] rbalint: sure, let me do that now [12:34] mapreri, diffoscope: error: unrecognized arguments: --thisflagdoesntexistandwontexist [12:34] diffoscope on s390x seems sad [12:34] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/d/diffoscope/20170726_103422_64cc6@/log.gz [12:35] LocutusOfBorg: that's not an error [12:35] indeed that autpkgtest test passes [12:35] and yeah, that thing is another failure that is fixed by another commit I forgot about… [12:35] (btw, that test is there to test that if you pass an invalid argument diffoscope exists with code 2) [12:37] ack [12:37] mwhudson, why python3-defaults is not pointing at the right python? I'm lost [12:37] https://launchpad.net/ubuntu/+source/python3-defaults/3.6.1-0ubuntu2 [12:37] it should be 3.6.2 [12:37] sagemath is picking up Get:10 http://ftpmaster.internal/ubuntu artful-proposed/main amd64 libpython3-stdlib amd64 3.6.1-0ubuntu2 [7012 B] [12:38] and not sure if this is the reason for its failure [12:38] LocutusOfBorg: https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=7e16cecb98ec2e874da4f3ea291e276602852dcd [12:38] and probably will need https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=fe57c99828060ae77af2784961d47beb44eb74f5 as well.. [12:39] I uploaded with the first patch, since I can't test s390x [12:40] it's weird that only s390x failed [12:40] that thing failed in debian as well, on amd64 [12:49] Laney, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages [12:49] do you want to test it out? :p [12:51] I uploaded wxwidgets3.0 on that ppa, lets see if it works or not [12:55] rbalint: I forgot to tell you, I committed it in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=78bc10d4702b30b46d802294ac43cffc34d9c431 [12:56] rbalint: Feel free to do a 1.5~beta1ubuntu1 now if you want it now, 1.5~beta2 comes in a few days [12:56] Well, it might come today, but I'm not sure what DonKult is up to exactly [13:00] arges, hmm, how did my name end up in that livecd-rootfs changelog ? i cant remember ever touching any of this [13:00] ogra_: I didn't put it there... [13:02] arges, well, you upploaded it [13:02] (but i see, seems rcj assembled it) [13:03] well, not that important anyway ... i was just wondering how my name got on there [13:04] https://launchpad.net/ubuntu/+source/livecd-rootfs/2.408.13 looks correct, I think my 'sru-release' script seems to have printed incorrect info on the bug [13:04] yeah, that was the trusty sru [13:04] not the xenial one :) [13:05] https://launchpad.net/ubuntu/+source/livecd-rootfs/2.208.14 [13:06] ah, yea I think rcj included other patches in his upload [13:13] (thats fine, but i still cant remember ever touching any vmdk, ova or vargrat stuff in my life ;) ) [13:13] (at least not in livecd-rootfs ... but perhaps my memory fades :P i'm getting old ... :) ) [13:25] pkkk~. [13:25] ~ [13:25] .~. [13:26] whoops [13:29] arges, this seems the command used to kill a stuck ssh connection, correct? [13:29] ogra_: I pulled in contributions to livecd-rootfs in the utopic->xenial timeframe for that trusty upload to support build of cloud-images. I kept all the contributors names. I can't recall which you contributed to but it must have been in there ;) === dja_ is now known as dja [13:42] juliank: thanks, in a few days is ok i would not create a delta for a few days in in this case [13:59] mwhudson, it is landing =) [13:59] i'm sure it will spill over two publications and screw people up for an hour or so. [14:09] yeah, got 56 migration mails ... [15:11] nacc: hi [15:12] zhongjun: hello [15:13] nacc: I got this error in ubuntu 16.04 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847557 [15:13] Debian bug 847557 in nfs-kernel-server "/usr/sbin/exportfs: exportfs cannot handle IPv6 addresses" [Important,Open] [15:13] nacc: This bug has been fixed in nfs-kernel-server version 1:1.3.4-1 [15:14] nacc: Could we backport the "fix" in nfs-kernel-server version 1:1.2.8 [15:16] nacc: Could we backport the "fix" in ubuntu 16.04 [15:16] zhongjun: do you know the specific fix? [15:17] nacc: Actually, I am not sure about the specifix fix [15:18] zhongjun: if you want it in xenial-backports, you can request it (https://wiki.ubuntu.com/UbuntuBackports). But for a bugfix to go into xenial-updates, you have to know what the bugfix is (https://wiki.ubuntu.com/StableReleaseUpdates). [15:22] nacc: Is there a fast way or some links that I could make me find the specific fix quickly? [15:22] nacc: Is there a fast way or some links that it could make me find the specific fix quickly? [15:26] zhongjun: https://en.wikipedia.org/wiki/Bisection_(software_engineering) maybe? [15:26] zhongjun: you would need to look at what was fixed in teh debian upload. More than likely it's an upstream fix (not a debian-specific one). Generally, no, there's not a 'quick way' [15:26] Or yeah, look through the commit messages and changelogs. [15:29] rbasak, nacc: Thanks, if anyone familiar with exportfs IPv6, please tell me [15:35] 4/win 3 [15:52] xnox: do you know if LocutusOfBorg will do the perl merge and start the perl transition? [15:52] no idea. [15:54] ok, then I'll do the merge [15:55] why not wait and ask? [15:58] doko, Laney: lemme ask him [16:06] last I heard from him he said "I won't until python is good" [16:08] doko, why do you think this is a merge? [16:08] I'm uploading a no-change rebuild in a ppa [16:08] was zlib updated in Debian? [16:09] some of the patches I'm carrying are fixed in new perl, so probably a plain sync will work [16:09] no doko it wasnt [16:09] btw I just uploaded debhelper, for sure I would wait a little bit before syncing perl [16:09] uploaded in my ppa [16:09] LocutusOfBorg: so you are handling this? [16:09] if you want to help, please help :) [16:10] I can do the sync/merge, but for sure I can't handle perl alone [16:10] (I was waiting for python3-defaults to land) [16:11] does this sound ok for you? [16:11] sync/merge in one hour or two [16:11] and then do the rebuilds tonight/later [16:11] I only want to make sure that it's done mid next week, before I start with gcc-7 [16:12] this sounds like a good plan [16:12] I'm just worried about the testsuite [16:12] but yeah, lets sync and start rebuilds in one hour [16:12] builders are bad now, amd64 is sloooow [16:13] not sure what they are building, hopefully they will be green soon [16:13] we still have that perl "hey don't build arch:all before arch:any or rmadison will be sad" stuff [16:14] so, I want amd64 ready before syncing [16:14] which ppa? [16:14] ~costamagnagianfranco/locutusofborg-ppa [16:15] ppc64el started, so I guess we can just wait for it [16:15] test failures were common [16:19] doko, can you please bump debhelper priority? https://launchpad.net/ubuntu/+source/debhelper/10.6.4ubuntu1 [16:19] I don't want the egg and cichken issue [16:19] * LocutusOfBorg chicken [16:21] tumbleweed: reverse-depends doesn't seem to handle '-r testing' or '-r buster' [16:22] jbicha, would be nice to see also -r artful-proposed, to understand which stuff has already been rebuilt on top of the new library :) [16:25] thanks to whoever did it [16:38] LocutusOfBorg: security updates, but it'll get there in a bit [16:47] why would objcopy fail to extract debug info on the buildds when FPC calls it, but works fine if I call it with the same arguments from a build script? [16:48] cjwatson, I mean, thanks to whoever bumped the priority of perl and debhelper :) [16:48] no problem cjwatson, breaking the whole world can wait some hours I hope :p [16:48] not I [16:55] doko, the plain sync seems to have worked on ppc64el [16:55] so, lets wait for builders to settle down and I'll force-sync [16:57] * LocutusOfBorg leaves [16:57] cheers! [17:03] which channel for help with community documentation issues? Just #ubuntu? [17:04] bluefoxxxx: I assume #ubuntu-doc? [17:04] thanks [17:06] jbicha: ah, I think the distro-info-data was out of date, re-running it now [17:27] doko, sync? [17:30] I'm doing it, done [18:18] jbicha: fixed [18:19] thanks! === sergiusens_ is now known as sergiusens [18:51] slangasek, infinity, jbicha: Hey there! I'll be helping with the Qt transition while mitya57 is off on vacation, what's the status of getting the Ubuntu Touch packages removed from the archive? If a new Qt version is uploaded, it probably won't migrate from -proposed unless those are removed... [18:57] tsimonq2: from my perspective, xnox was driving these removals; I'd check with him on status [18:58] slangasek: Thanks. [19:47] LocutusOfBorg: I'm uploading the first batch of perl rebuilds [20:14] mdeslaur: fyi, apache2 2.4.27-3 is now in unstable. I'll merge up to that, which should be past the version that declares http2 stable. [20:17] nacc: great, thanks [21:50] xnox: \o/ [22:37] doko, ack thanks [22:43] I'll rekick some stuff [22:56] infinity: I don't suppose you're online? [22:57] Unit193: I might be. [22:57] I was wondering why specifically in https://launchpad.net/ubuntu/+source/ruby-specinfra/2.66.0-1ubuntu1 you added that, I don't see it in the requirements and autopkgtests pass without it. [22:57] Based on grep, I do see how one might use it, but I'm wondering 1. How you saw that. 2. If the build-dep is still needed. [22:58] Unit193: If I recall, it actually showed us as failures in rdeps. [22:59] I wondered if that was the case, if it were I wouldn't think build-depend... [23:00] Build-dep was probably to cover a build-time testsuite or something, but might possibly have been a paranoid error. [23:00] I don't see how it hurts either, mind you. :P [23:00] I see "spec/command/debian/port_spec.rb: it { should eq 'netstat -tunl | grep -- :80\ ' }" in that version, and "lib/specinfra/command/base/port.rb: "netstat -tunl | grep -- #{escape(pattern)}"" in the new. [23:00] Lots of calls to netstat in the source. [23:00] infinity: Right, but if I push to Debian, specifically in a package I'm not an uploader, I want to make dang sure it's needed. :) [23:01] Yeah, though a lot under 'freebsd' [23:01] infinity: Thanks for explaining, and for remembering that long ago! [23:06] Unit193: Well, I would test it without the build-dep, but apparently the testsuite breaks earlier. :P [23:06] /usr/lib/ruby/2.3.0/rubygems/specification.rb:1436:in `block in activate_dependencies': can't satisfy 'net-ssh (< 4.0, >= 2.7)', already activated 'net-ssh-4.1.0' (Gem::LoadError) [23:06] sudo autopkgtest -U --apt-pocket proposed=ruby-net-ssh -- lxc autopkgtest-artful [23:06] Unit193: But I'd posit that if it passes for you, your chroot is dirty (ie: has net-tools in it) [23:08] I have no idea about the autopkgtests, it shouldn't have been installed (it's a new container, nothing abnormal), and the base chroot I used to build didn't have it either. [23:08] And the testsuite ran? [23:09] I mean, I literally just tried to build it and the testsuite doesn't run at all. [23:09] So, I kinda want to know how you managed. [23:10] The old one I think I targetted for Zesty, I'm working on a new version that of course handles net-ssh 4.x [23:11] Anyhow, it's possible the build-dep was in error if the ruby-specinfra testsuite doesn't exercise that bit of code (though, that would be a bug in lack of coverage of the testsuite, then), but the dependency is obviously correct. [23:11] And was needed for testsuites of OTHER rdeps to pass. [23:11] (And just needed because duh) [23:18] infinity: Re-running the autopkgtest, something else is pulling net-tools in, that could be the answer. :P [23:18] Err.. [23:27] infinity: SO yes, for sure no net-tools in the autopkgtest..container, and it still passed. No idea how to give you the log for autopkgtest run though. [23:46] Unit193: autopkgtest isn't relevant here, though. [23:47] Unit193: The direct dependency is correct *even if* the testsuite doesn't exercise that code. [23:47] Unit193: We don't add deps just to satsify testsuites. [23:47] Unit193: Now for *building*, the build-dep might not be relevant if the testsuite doesn't run that code, but also meh? [23:48] infinity: In this case, autopkgtest also builds it. And I figured good to specifically run with autopkgtests as they're a bit of a blackbox to me still. Of course building runs the tests, and the build passes. :) [23:49] To be clear, no I agree with your first point, net-tools should be a *depend*, but *build-depend* was what I was trying to figure out. [23:50] (https://deb.li/3PbhA) [23:51] Unit193: Sure. Build-dep might have just been a belt-and-bracers thing because I knew the build ran a testsuite and I didn't care to check if it had decent coverage. [23:52] Good enough. [23:52] Unit193: And path of least resistance, since it had literally always built with net-tools in the past. [23:52] Sure, understandable. [23:52] Unit193: I do know some OTHER testsuite exercises that code, cause that's how I noticed the bug, but damned if I can figure out what it was now. :P [23:52] ruby-serverspec or chef, likely. [23:53] Didn't seem to be either of them at a glance. [23:53] But there's also serverspec-runner, which might be a test-depend somewhere or something. [23:53] I dunno. I gave up looking, I have a dinner to run off to. :P [23:54] Food is always a good reason. [23:54] Free food. [23:54] Paid for by parents. [23:54] Ooooooh. [23:54] So, +1/-1 [23:54] But steak, so maybe another +1? [23:54] Yes very much so. [23:55] But, anywho if all goes well that package is syncable now. \o/