[02:10] <tsimonq2> Logan: Hey, so what did you find out with kanatest?
[07:01] <Unit193> 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] <Unit193> http://autopkgtest.ubuntu.com/packages/r/ruby-net-sftp/artful/amd64 also shouldn't have failed.
[07:03] <Unit193> 34 tests, 66 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
[07:03] <Unit193> 100% passed
[07:04] <mwhudson> nice
[07:05] <Unit193> I know because I prepped several uploads in Debian for ruby-net-ssh. :P
[07:08] <Unit193> mwhudson: Should I ask where you are?  You seem to always be alive in the 'dead zone'.
[07:11] <Unit193> Is there a way to get them testing against -proposed?
[07:15] <ginggs> Unit193: the tests can be triggered against additional packages
[07:16] <Unit193> ginggs: ruby-net-scp/ruby-net-sftp need --apt-pocket=proposed=src:ruby-net-ssh
[07:20] <ginggs> Unit193: retrying
[07:20] <Unit193> Thanks!
[07:20] <Unit193> I understand I don't have permissions for it, but how?
[07:22] <ginggs> 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] <Unit193> ginggs: I did, but since it needed a package from -proposed I thought the fine tuning would be different.
[07:24] <ginggs> 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] <Unit193> That's officially 'fun'.  Thanks.
[07:49] <mwhudson> Unit193: nz
[07:50] <mwhudson> yes, retry url hacking is fun
[07:50] <mwhudson> you can also add &all-proposed=1
[07:52] <Unit193> Ah.  I'm not core nor motu (just packageset), so not (yet) really able to useit.
[07:52] <LocutusOfBorg> mwhudson, what is the last thing blocking python3.6?
[07:52] <LocutusOfBorg> Unit193, I stole your wine-development merge
[07:53] <Unit193> I had one?
[07:53] <Unit193> Thanks, LocutusOfBorg!
[07:53] <LocutusOfBorg> you asked me to sponsor that for you
[07:53] <Unit193> Good enough. :)
[07:57] <LocutusOfBorg> go cmake, go
[08:21] <mwhudson> LocutusOfBorg: yara ftbfs on armhf
[08:21] <LocutusOfBorg> ack
[08:21] <mwhudson> LocutusOfBorg: which i am hacking almightily now
[08:21] <LocutusOfBorg> I'm fixing the last gtk-d failures
[08:21] <LocutusOfBorg> oh wonderful
[08:27] <mwhudson> oh boy this code really expects aligned access to work
[08:44] <mwhudson> like, a lot
[08:57] <mwhudson> xnox: what do you think about removing the existing yara binaries on armhf? (and rdeps i guess)
[09:13] <mwhudson> xnox, slangasek, doko: sent an update to ubuntu-devel about yara
[10:34] <LocutusOfBorg> can I ask for a little perl advice?
[10:34] <LocutusOfBorg> Laney, the debhelper merge is ready, but I fail to parse the Ubuntu version
[10:34] <Laney> you what?
[10:35] <LocutusOfBorg> 	perl -e ' undef $/; foreach (@ARGV) { open (IN, $_) or die "$_: $!"; $file=<IN>; 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 (<STDIN>) { s/#LIST#/$list/; s/#LIST_DEPRECATED#/$list_deprecated/;
[10:35] <LocutusOfBorg> 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] <LocutusOfBorg> 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] <LocutusOfBorg> onfig dh_usrlocal | \
[10:35] <LocutusOfBorg> 	pod2man --utf8 -c Debhelper -r "10.6.4ubuntu1" --name="debhelper" --section=7  > debhelper.7
[10:35] <LocutusOfBorg> https://launchpadlibrarian.net/330668177/buildlog_ubuntu-artful-amd64.debhelper_10.6.4ubuntu1_BUILDING.txt.gz
[10:35] <LocutusOfBorg> bad copy-paste
[10:35] <LocutusOfBorg> forcing VERSION=10 "fixes" it, but it is hacky and bad
[10:35] <LocutusOfBorg> solution is to drop that ubuntu in recommended compat, right?
[10:37] <LocutusOfBorg> the question is: should I revert somewhere this? https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=d2ca3a7f964eb915035c4526baa92325d3f6dbd7
[10:37] <LocutusOfBorg> $$recommended_compat =~ s{\..*}{};
[10:37] <LocutusOfBorg> this is what fails
[10:38] <Laney> is it calculating that variable wrong?
[10:40] <LocutusOfBorg> the problem is that rege
[10:40] <LocutusOfBorg> with the debian version 10.6.4 is returning "10"
[10:40] <LocutusOfBorg> with the ubuntu version, 10.6.4ubuntu1 it returns "can't parse foobar"
[10:40] <LocutusOfBorg> Bareword found where operator expected at -e line 1, near "10.6.4ubuntu1"
[10:41] <LocutusOfBorg> so, this code "$recommended_compat =~ s{\..*}{};" is having issues
[10:43] <LocutusOfBorg> 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] <Laney> LocutusOfBorg: Looks like it should be quoted?
[10:43] <Laney> my $recommended_compat = 10.6.4ubuntu1;
[10:44] <cjwatson> Yeah that probably just wants to be my $$recommended_compat = q($(VERSION));
[10:44] <cjwatson> or similar
[10:46] <cjwatson> hmm, do I have upstream commit access
[10:49] <cjwatson> doesn't look like it
[10:54] <LocutusOfBorg> sorry, bad connection sigh
[10:55] <LocutusOfBorg> seems not good, man ./debhelper.7 shows: "#RECOMMEDED_COMPAT#" instead of 10
[10:56] <cjwatson> I'm preparing a patch
[10:56] <LocutusOfBorg> 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] <cjwatson> not especially
[10:57] <cjwatson> I'll send a patch to Debian
[10:58] <LocutusOfBorg> ok thanks
[11:02] <Laney> There's some "recommeded" / "recommended" confusion too.
[11:04] <cjwatson> yes, I'm fixing that
[11:05] <Laney> Nod
[11:05] <LocutusOfBorg> so also debian manpages should be bad
[11:06] <LocutusOfBorg> yes lol
[11:10] <cjwatson> indeed
[11:14] <cjwatson> ... and a lack of s///g ...
[11:24] <cjwatson> LocutusOfBorg,Laney: https://bugs.debian.org/869780
[11:25] <cjwatson> feel free to cherry-pick or whatever
[11:36] <Laney> cjwatson: Ta
[11:36] <Laney> LocutusOfBorg: You going to take that?
[12:11] <rbalint> juliank: are you ok with the smaller patch against apt in LP: #1690980 ?
[12:12] <LocutusOfBorg> Laney, will upload in ppa
[12:12] <LocutusOfBorg> sorry I was @lunch
[12:12]  * Laney nod
[12:14] <juliank> 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] <juliank> Gracefully terminate processes apt-daily-upgrade.service on stop?
[12:15] <LocutusOfBorg> Laney, do you want to do some testing before I upload to Ubuntu? I admit, I'm worried about it :)
[12:16] <rbalint> juliank: thanks that's clear and short
[12:16] <juliank> oh, it's missing a word
[12:16] <rbalint> juliank: so sure, feel free to change it
[12:16] <juliank> Gracefully terminate processes *in* apt-daily-upgrade.service on stop
[12:17] <rbalint> do you plan landing 1.2.25 in xenial in the near future?
[12:18] <juliank> Let's go with "Gracefully terminate process when stopping apt-daily-upgrade"
[12:19] <juliank> 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] <juliank> 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] <juliank> And AFAIUI, updates are supposed to be in newer suites before older ones.
[12:22] <juliank> 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] <juliank> see bug 1702326 for the changes in 1.4.7
[12:24] <juliank> (basically minor (in size) fixes to the http method to correctly handle some server responses)
[12:24] <rbalint> juliank: ok, thanks!
[12:24] <juliank> There are no other fixes scheduled for 1.4.8 at the moment, so that would be just the service change :)
[12:27] <juliank> Oh, I see DonKult has some fixes in his repo he did not push yet
[12:29] <rbalint> mvo: i'm fairly confident in the u-u PR, maybe could you please take a look again?
[12:29] <mvo> rbalint: sure, let me do that now
[12:34] <LocutusOfBorg> mapreri, diffoscope: error: unrecognized arguments: --thisflagdoesntexistandwontexist
[12:34] <LocutusOfBorg> diffoscope on s390x seems sad
[12:34] <LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/d/diffoscope/20170726_103422_64cc6@/log.gz
[12:35] <mapreri> LocutusOfBorg: that's not an error
[12:35] <mapreri> indeed that autpkgtest test passes
[12:35] <mapreri> and yeah, that thing is another failure that is fixed by another commit I forgot about…
[12:35] <mapreri> (btw, that test is there to test that if you pass an invalid argument diffoscope exists with code 2)
[12:37] <LocutusOfBorg> ack
[12:37] <LocutusOfBorg> mwhudson, why python3-defaults is not pointing at the right python? I'm lost
[12:37] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/python3-defaults/3.6.1-0ubuntu2
[12:37] <LocutusOfBorg> it should be 3.6.2
[12:37] <LocutusOfBorg> 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] <LocutusOfBorg> and not sure if this is the reason for its failure
[12:38] <mapreri> LocutusOfBorg: https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=7e16cecb98ec2e874da4f3ea291e276602852dcd
[12:38] <mapreri> and probably will need https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=fe57c99828060ae77af2784961d47beb44eb74f5 as well..
[12:39] <LocutusOfBorg> I uploaded with the first patch, since I can't test s390x
[12:40] <mapreri> it's weird that only s390x failed
[12:40] <mapreri> that thing failed in debian as well, on amd64
[12:49] <LocutusOfBorg> Laney, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[12:49] <LocutusOfBorg> do you want to test it out? :p
[12:51] <LocutusOfBorg> I uploaded wxwidgets3.0 on that ppa, lets see if it works or not
[12:55] <juliank> rbalint: I forgot to tell you, I committed it in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=78bc10d4702b30b46d802294ac43cffc34d9c431
[12:56] <juliank> 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] <juliank> Well, it might come today, but I'm not sure what DonKult is up to exactly
[13:00] <ogra_> arges, hmm, how did my name end up in that livecd-rootfs changelog ? i cant remember ever touching any of this
[13:00] <arges> ogra_: I didn't put it there...
[13:02] <ogra_> arges, well, you upploaded it
[13:02] <ogra_> (but i see, seems rcj assembled it)
[13:03] <ogra_> well, not that important anyway ... i was just wondering how my name got on there
[13:04] <arges> 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] <ogra_> yeah, that was the trusty sru
[13:04] <ogra_> not the xenial one :)
[13:05] <ogra_> https://launchpad.net/ubuntu/+source/livecd-rootfs/2.208.14
[13:06] <arges> ah, yea I think rcj included other patches in his upload
[13:13] <ogra_> (thats fine, but i still cant remember ever touching any vmdk, ova or vargrat stuff in my life ;) )
[13:13] <ogra_> (at least not in livecd-rootfs ... but perhaps my memory fades :P i'm getting old ... :)  )
[13:25] <arges> pkkk~.
[13:25] <arges> ~
[13:25] <arges> .~.
[13:26] <arges> whoops
[13:29] <LocutusOfBorg> arges, this seems the command used to kill a stuck ssh connection, correct?
[13:29] <rcj> 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 ;)
[13:42] <rbalint> juliank: thanks, in a few days is ok i would not create a delta for a few days in in this case
[13:59] <xnox> mwhudson, it is landing =)
[13:59] <xnox> i'm sure it will spill over two publications and screw people up for an hour or so.
[14:09] <doko> yeah, got 56 migration mails ...
[15:11] <zhongjun> nacc: hi
[15:12] <nacc> zhongjun: hello
[15:13] <zhongjun> nacc: I got this error in ubuntu 16.04 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847557
[15:13] <zhongjun> nacc:  This bug has been fixed in nfs-kernel-server version 1:1.3.4-1
[15:14] <zhongjun> nacc: Could we backport the "fix" in  nfs-kernel-server version 1:1.2.8
[15:16] <zhongjun> nacc: Could we backport the "fix" in  ubuntu 16.04
[15:16] <nacc> zhongjun: do you know the specific fix?
[15:17] <zhongjun> nacc: Actually, I am not sure about the specifix fix
[15:18] <nacc> 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] <zhongjun> nacc: Is there a fast way or some links that I could make me find the specific fix quickly?
[15:22] <zhongjun> nacc: Is there a fast way or some links that it could make me find the specific fix quickly?
[15:26] <rbasak> zhongjun: https://en.wikipedia.org/wiki/Bisection_(software_engineering) maybe?
[15:26] <nacc> 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] <rbasak> Or yeah, look through the commit messages and changelogs.
[15:29] <zhongjun> rbasak, nacc: Thanks,  if anyone familiar with exportfs  IPv6, please tell me
[15:35] <roaksoax_> 4/win 3
[15:52] <doko> xnox: do you know if LocutusOfBorg will do the perl merge and start the perl transition?
[15:52] <xnox> no idea.
[15:54] <doko> ok, then I'll do the merge
[15:55] <Laney> why not wait and ask?
[15:58] <ginggs> doko, Laney: lemme ask him
[16:06] <mapreri> last I heard from him he said "I won't until python is good"
[16:08] <LocutusOfBorg> doko, why do you think this is a merge?
[16:08] <LocutusOfBorg> I'm uploading a no-change rebuild in a ppa
[16:08] <doko> was zlib updated in Debian?
[16:09] <LocutusOfBorg> some of the patches I'm carrying are fixed in new perl, so probably a plain sync will work
[16:09] <LocutusOfBorg> no doko it wasnt
[16:09] <LocutusOfBorg> btw I just uploaded debhelper, for sure I would wait a little bit before syncing perl
[16:09] <LocutusOfBorg> uploaded in my ppa
[16:09] <doko> LocutusOfBorg: so you are handling this?
[16:09] <LocutusOfBorg> if you want to help, please help :)
[16:10] <LocutusOfBorg> I can do the sync/merge, but for sure I can't handle perl alone
[16:10] <LocutusOfBorg> (I was waiting for python3-defaults to land)
[16:11] <LocutusOfBorg> does this sound ok for you?
[16:11] <LocutusOfBorg> sync/merge in one hour or two
[16:11] <LocutusOfBorg> and then do the rebuilds tonight/later
[16:11] <doko> I only want to make sure that it's done mid next week, before I start with gcc-7
[16:12] <LocutusOfBorg> this sounds like a good plan
[16:12] <LocutusOfBorg> I'm just worried about the testsuite
[16:12] <LocutusOfBorg> but  yeah, lets sync and start rebuilds in one hour
[16:12] <LocutusOfBorg> builders are bad now, amd64 is sloooow
[16:13] <LocutusOfBorg> not sure what they are building, hopefully they will be green soon
[16:13] <LocutusOfBorg> we still have that perl "hey don't build arch:all before arch:any or rmadison will be sad" stuff
[16:14] <LocutusOfBorg> so, I want amd64 ready before syncing
[16:14] <doko> which ppa?
[16:14] <LocutusOfBorg> ~costamagnagianfranco/locutusofborg-ppa
[16:15] <LocutusOfBorg> ppc64el started, so I guess we can just wait for it
[16:15] <LocutusOfBorg> test failures were common
[16:19] <LocutusOfBorg> doko, can you please bump debhelper priority? https://launchpad.net/ubuntu/+source/debhelper/10.6.4ubuntu1
[16:19] <LocutusOfBorg> I don't want the egg and cichken issue
[16:19]  * LocutusOfBorg chicken 
[16:21] <jbicha> tumbleweed: reverse-depends doesn't seem to handle '-r testing' or '-r buster'
[16:22] <LocutusOfBorg> 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] <LocutusOfBorg> thanks to whoever did it
[16:38] <cjwatson> LocutusOfBorg: security updates, but it'll get there in a bit
[16:47] <ginggs> 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] <LocutusOfBorg> cjwatson, I mean, thanks to whoever bumped the priority of perl and debhelper :)
[16:48] <LocutusOfBorg> no problem cjwatson, breaking the whole world can wait some hours I hope :p
[16:48] <cjwatson> not I
[16:55] <LocutusOfBorg> doko, the plain sync seems to have worked on ppc64el
[16:55] <LocutusOfBorg> so, lets wait for builders to settle down and I'll force-sync
[16:57]  * LocutusOfBorg leaves
[16:57] <LocutusOfBorg> cheers!
[17:03] <bluefoxxxx> which channel for help with community documentation issues?  Just #ubuntu?
[17:04] <tsimonq2> bluefoxxxx: I assume #ubuntu-doc?
[17:04] <bluefoxxxx> thanks
[17:06] <tumbleweed> jbicha: ah, I think the distro-info-data was out of date, re-running it now
[17:27] <LocutusOfBorg> doko, sync?
[17:30] <LocutusOfBorg> I'm doing it, done
[18:18] <tumbleweed> jbicha: fixed
[18:19] <jbicha> thanks!
[18:51] <tsimonq2> 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] <slangasek> tsimonq2: from my perspective, xnox was driving these removals; I'd check with him on status
[18:58] <tsimonq2> slangasek: Thanks.
[19:47] <doko> LocutusOfBorg: I'm uploading the first batch of perl rebuilds
[20:14] <nacc> 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] <mdeslaur> nacc: great, thanks
[21:50] <mwhudson> xnox: \o/
[22:37] <LocutusOfBorg> doko, ack thanks
[22:43] <LocutusOfBorg> I'll rekick some stuff
[22:56] <Unit193> infinity: I don't suppose you're online?
[22:57] <infinity> Unit193: I might be.
[22:57] <Unit193> 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] <Unit193> 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] <infinity> Unit193: If I recall, it actually showed us as failures in rdeps.
[22:59] <Unit193> I wondered if that was the case, if it were I wouldn't think build-depend...
[23:00] <infinity> Build-dep was probably to cover a build-time testsuite or something, but might possibly have been a paranoid error.
[23:00] <infinity> I don't see how it hurts either, mind you. :P
[23:00] <Unit193> 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] <infinity> Lots of calls to netstat in the source.
[23:00] <Unit193> 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] <Unit193> Yeah, though a lot under 'freebsd'
[23:01] <Unit193> infinity: Thanks for explaining, and for remembering that long ago!
[23:06] <infinity> Unit193: Well, I would test it without the build-dep, but apparently the testsuite breaks earlier. :P
[23:06] <infinity> /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] <Unit193> sudo autopkgtest -U --apt-pocket proposed=ruby-net-ssh -- lxc autopkgtest-artful
[23:06] <infinity> Unit193: But I'd posit that if it passes for you, your chroot is dirty (ie: has net-tools in it)
[23:08] <Unit193> 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] <infinity> And the testsuite ran?
[23:09] <infinity> I mean, I literally just tried to build it and the testsuite doesn't run at all.
[23:09] <infinity> So, I kinda want to know how you managed.
[23:10] <Unit193> 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] <infinity> 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] <infinity> And was needed for testsuites of OTHER rdeps to pass.
[23:11] <infinity> (And just needed because duh)
[23:18] <Unit193> infinity: Re-running the autopkgtest, something else is pulling net-tools in, that could be the answer. :P
[23:18] <Unit193> Err..
[23:27] <Unit193> 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] <infinity> Unit193: autopkgtest isn't relevant here, though.
[23:47] <infinity> Unit193: The direct dependency is correct *even if* the testsuite doesn't exercise that code.
[23:47] <infinity> Unit193: We don't add deps just to satsify testsuites.
[23:47] <infinity> Unit193: Now for *building*, the build-dep might not be relevant if the testsuite doesn't run that code, but also meh?
[23:48] <Unit193> 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] <Unit193> 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] <Unit193> (https://deb.li/3PbhA)
[23:51] <infinity> 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] <Unit193> Good enough.
[23:52] <infinity> Unit193: And path of least resistance, since it had literally always built with net-tools in the past.
[23:52] <Unit193> Sure, understandable.
[23:52] <infinity> 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] <Unit193> ruby-serverspec or chef, likely.
[23:53] <infinity> Didn't seem to be either of them at a glance.
[23:53] <infinity> But there's also serverspec-runner, which might be a test-depend somewhere or something.
[23:53] <infinity> I dunno.  I gave up looking, I have a dinner to run off to. :P
[23:54] <Unit193> Food is always a good reason.
[23:54] <infinity> Free food.
[23:54] <infinity> Paid for by parents.
[23:54] <Unit193> Ooooooh.
[23:54] <infinity> So, +1/-1
[23:54] <infinity> But steak, so maybe another +1?
[23:54] <Unit193> Yes very much so.
[23:55] <Unit193> But, anywho if all goes well that package is syncable now. \o/