[13:29] <kkeithley> I'm stumped by a build failure in my ppa of nfs-ganesha for disco.   it's not seeing the dependency for libntirpc-dev.  I have a dependencies set and it finds them cosmic, bionic, and xenial
[13:29] <kkeithley> https://launchpadlibrarian.net/401988716/buildlog_ubuntu-disco-amd64.nfs-ganesha_2.7.1-ubuntu1~disco2_BUILDING.txt.gz
[13:30] <kkeithley> https://launchpad.net/~nfs-ganesha
[13:42] <cjwatson> kkeithley: "is not going to be installed" means that the dependency exists but that *its* dependencies can't be satisfied
[13:42] <cjwatson> (possibly only in combination with your other build-dependencies)
[13:42] <kkeithley> cjwatson: ah, okay
[13:44] <kkeithley> I guess
[13:45] <kkeithley> Then I guess I'm puzzled as to how its dependencies were satisfied to build it (it = libntirpc)
[13:46] <cjwatson> Well that's often the way
[13:46] <cjwatson> Let's see
[13:46] <kkeithley> hmm, maybe libjemalloc
[13:47] <kkeithley> it shouldn't be using that in any event
[13:48] <cjwatson> kkeithley: libntirpc1 in https://launchpad.net/~nfs-ganesha/+archive/ubuntu/libntirpc-1.7/+packages has a hardcoded dependency on libtirpc1 which doesn't exist in disco
[13:48] <cjwatson> Any reason you aren't relying on ${shlibs:Depends} for that?
[13:49] <cjwatson> (It's libtirpc3 in disco)
[13:49] <kkeithley> lol, because I'm a rank amateur when it comes to Debian/Ubuntu packages.  I'm sure there are a lot of warts
[13:50] <cjwatson> You don't seem to be build-depending on libtirpc-dev there, so I'm not quite sure how that package works
[13:51] <cjwatson> I guess you're just depending on it for /etc/netconfig rather than for the actual library?
[13:51] <cjwatson> Unfortunate (and a policy violation on libtirpc's part, probably) that that isn't in a libtirpc-common package or similar
[13:51] <kkeithley> I expect that's correct (/etc/netconfig)
[13:51] <cjwatson> So I think you probably just have to hardcode a different dependency for disco and later
[13:52] <cjwatson> And possibly whine in the general direction of https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libtirpc about getting /etc/netconfig split out
[13:53] <cjwatson> Oh, in fact it's libtirpc-common in disco
[13:53] <cjwatson> So ... you could conceivably write Depends: [stuff], libtirpc-common | libtirpc1
[13:53] <cjwatson> That might not be too terrible
[13:54] <kkeithley>  libtirpc-common | libtirpc1 ?  Not  libtirpc-common | libtirpc3 ?
[13:54] <kkeithley> Pretty sure I don't even need libtirpcX libs at all.
[13:55] <cjwatson> No, libtirpc-common | libtirpc1
[13:55] <cjwatson> The thing is, your library needs /etc/netconfig
[13:55] <cjwatson> That's in libtirpc-common in disco, and libtirpc1 in earlier releases
[13:55] <cjwatson> So libtirpc-common | libtirpc1 is more or less the right dependency, as a workaround for the now-fixed bug in libtirpc's packaging
[13:57] <kkeithley> oh, well, I'm not even trying to have "one true set of packaging bits"   I have separate .../debian/* bits for Disco
[13:57] <cjwatson> OK, so if you're doing that already then just making it be libtirpc-common would be fine
[13:58] <kkeithley> okay
[13:58] <kkeithley> thanks
[13:58] <cjwatson> np
[13:58] <cjwatson> I haven't checked whether that's the only problem
[13:58] <kkeithley> I'm sure it's not
[13:58] <kkeithley> but I bet that's the main one
[13:59] <cjwatson> Yeah, seems likely
[17:02] <smoser> hey. https://code.launchpad.net/~pollinate/+recipe/pollinate-daily
[17:02] <smoser> wondering why that decided to build.
[17:03] <smoser> it built yesterday https://code.launchpad.net/~pollinate/+archive/ubuntu/daily
[17:03] <smoser> and as far as I can tell there was no changes to upstream
[17:04] <cjwatson> Would take some investigation and I don't have time at the moment, sorry.  You can file a bug if you think it's important although it doesn't seem likely to block anything.
[17:04] <smoser> cjwatson: not important. if you want abug i'll file
[17:05] <smoser> but if you dont care, i dont care as long as it doesn't happen every day
[17:05] <smoser> (and then fail with ... i think ... git checkout errors )
[17:05] <cjwatson> IIRC it happens occasionally but only once.
[17:05] <cjwatson> After manually-requested builds, possibly.
[17:05] <cjwatson> I forget exactly - I think I worked it out once
[17:07] <smoser> i did manually request build
[17:07] <smoser> as recipe aded.
[17:07] <smoser> so i'm good with that. thanks!