Re: Require packages to build without any configured DNS
On Mon, 06 Sep 2021, Mattia Rizzolo wrote: > It must be noted that no actual network operation happen, so this > doesn't fall into the "no network activity" bucket. > > This is the bug that was filed against dnspython: > https://bugs.debian.org/989171 > > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? Do you know why dnspython doesn't just fall back to socket.getaddrinfo if it can't parse /etc/resolv.conf [or maybe why python applications using dnspython don't fall back to that if dnspython fails?] That seems like the right default unless you really, really need to talk to a full-fledged DNS server directly. -- Don Armstrong https://www.donarmstrong.com He quite enjoyed the time by himself in the mornings. The day was too early to have started going really wrong. -- Terry Pratchet _Only You Can Save Mankind_ p133
Re: Require packages to build without any configured DNS
On Tue, Sep 07, 2021 at 04:41:49PM -0700, Don Armstrong wrote: > On Mon, 06 Sep 2021, Mattia Rizzolo wrote: > > It must be noted that no actual network operation happen, so this > > doesn't fall into the "no network activity" bucket. > > > > This is the bug that was filed against dnspython: > > https://bugs.debian.org/989171 > > > > Do anybody on the list have any opinion on where is the bug, on > > dnspython, or on the build environment? > > Do you know why dnspython doesn't just fall back to socket.getaddrinfo > if it can't parse /etc/resolv.conf [or maybe why python applications > using dnspython don't fall back to that if dnspython fails?] > > That seems like the right default unless you really, really need to talk > to a full-fledged DNS server directly. https://github.com/rthalley/dnspython dnspython provides both high and low level access to DNS. The high level classes perform queries for data of a given name, type, and class, and return an answer set. The low level classes allow direct manipulation of DNS zones, messages, names, and records. ... dnspython is a utility to work with DNS, /etc/hosts is thus not used. For simple forward DNS lookups, it's better to use socket.getaddrinfo() or socket.gethostbyname(). dnspython originated at Nominum where it was developed to facilitate the testing of DNS software. cu Adrian
Re: Require packages to build without any configured DNS
On 9/6/21 4:39 PM, Mattia Rizzolo wrote: > Hi, > > during the year, a src:dnspython change made it so that any software > importing that library now requires a valid /etc/resolv.conf with at > least one nameserver configured. > > This also made it so that something between 50-100 packages now fail to > build if the build system doesn't have any working /etc/resolv.conf. I > venture to say that this is a very reasonable configuration to have in a > build system that tries to be network-disabled. > > It must be noted that no actual network operation happen, so this > doesn't fall into the "no network activity" bucket. > > > This is the bug that was filed against dnspython: > https://bugs.debian.org/989171 > > > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? > > > As the pbuilder maintainer, I've been asked to make it serve a > non-working /etc/resolv.conf just to make that bug above moot, so I'm > quite biased on the matter myself :) I already stated this during discussions on IRC, but I will reiterate here to feed the discussion. The only place where dnspython needs a working /etc/resolv.conf is testing. Mandating a non-working /etc/resolv.conf will only result in having less tests in that package, which will potentially lower the package quality insurance, rather than improving Debian. When addressing this problem, we should ask ourselves: what is it that we're actually trying to fix. IMO: not much here... There's nothing broken. Therefore, I am in the opinion that we should let the package run its test as much as possible, especially considering that it's not doing actual network outbound connections. Cheers, Thomas Goirand (zigo)
Re: Require packages to build without any configured DNS
On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand wrote: Therefore, I am in the opinion that we should let the package run its test as much as possible, especially considering that it's not doing actual network outbound connections. Can't we run these tests as autopkgtests?
Re: Require packages to build without any configured DNS
On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote: > On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand > wrote: > > Therefore, I am in the opinion that we should let the package run its > > test as much as possible, especially considering that it's not doing > > actual network outbound connections. > > Can't we run these tests as autopkgtests? That would only move the problem elsewhere, since this creates a similar question whether such tests should need a "needs-internet" restriction for autopkgtest which might result in them being skipped in most cases. cu Adrian
Re: Require packages to build without any configured DNS
On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote: > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? I concur that the absence of /etc/resolv.conf is a sensible configuration. Indeed, it is my method-of-choice for implementing poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It doesn't actually prevent network access, but makes accidental network access very unlikely. I'm unsure whether /etc/resolv.conf is supposed to be essential. None of the packages in that set ensure its creation. Rather debootstrap and mmdebstrap have extra code to copy the host's /etc/resolv.conf into the chroot. Therefore any created chroot will contain one. However that seems more like an artifact of the bootstrap implementation rather than an intentional guarantee to me. As such, I err on dnspython being in need of a fix. Helmut
Re: Require packages to build without any configured DNS
Mattia Rizzolo wrote: > during the year, a src:dnspython change made it so that any software > importing that library now requires a valid /etc/resolv.conf with at > least one nameserver configured. > > This also made it so that something between 50-100 packages now fail to > build if the build system doesn't have any working /etc/resolv.conf. I > venture to say that this is a very reasonable configuration to have in a > build system that tries to be network-disabled. > > It must be noted that no actual network operation happen, so this > doesn't fall into the "no network activity" bucket. > > > This is the bug that was filed against dnspython: > https://bugs.debian.org/989171 > > > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? I think dnspython's previous approach was correct: just like glibc, musl, and other libraries, if /etc/resolv.conf is missing they should treat that as though it specified a nameserver on localhost. The change to make that a configuration error, instead, breaks real configurations that intentionally don't have /etc/resolv.conf. Among other things, having a DNS server on localhost (or forwarding the DNS port on localhost to your real DNS server) means that a chroot without /etc/resolv.conf still has functional DNS. Now, that said, if the build process actually wants a DNS server to run tests against, it should provide or depend on such a DNS server, and configure it for such tests. But a build process that's just *importing the dnspython library* should not need to have either /etc/resolv.conf *or* a functional DNS server. - Josh Triplett
Re: Require packages to build without any configured DNS
On Wed, Sep 08, 2021 at 05:44:34PM +0200, Helmut Grohne wrote: > On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote: > > Do anybody on the list have any opinion on where is the bug, on > > dnspython, or on the build environment? > > I concur that the absence of /etc/resolv.conf is a sensible > configuration. Indeed, it is my method-of-choice for implementing > poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It > doesn't actually prevent network access, but makes accidental network > access very unlikely. This does not work when software has a built-in fallback IP when no nameserver is configured in /etc/resolv.conf dnspython removing such a built-in fallback IP address and returning an error instead is what caused the breakage in reproducible builds. >... > As such, I err on dnspython being in need of a fix. What kind of fix? Re-adding a default of 127.0.0.1 (or even 8.8.8.8) when no nameserver is found in /etc/resolv.conf ? dnspython is initialized several packages down in the callstack for the failing packages by a concurrent networking library, and I am not aware of any package in this stack doing something unreasonable. > Helmut cu Adrian
Re: Require packages to build without any configured DNS
On 9/8/21 5:44 PM, Helmut Grohne wrote: > As such, I err on dnspython being in need of a fix. Dnspython isn't broken in any ways, it doesn't do any network access. The only thing you're going to achieve is: - more work for the maintainers (who will need to disable or patch the tests). - probably less tests (because the maintainer will probably choose to simply disable the tests), which means less quality. Again: what are you trying to achieve? On 9/8/21 6:01 PM, Josh Triplett wrote: > Now, that said, if the build process actually wants a DNS server to > run tests against, it should provide or depend on such a DNS server, > and configure it for such tests. Just to be 100% sure we're on the same page: that's *not* what dnspython is doing. It's a client library that's testing parsing of the /etc/resolv.conf format, and it just expects it to be there for parsing. The code has: class Resolver: def __init__(self, filename='/etc/resolv.conf', configure=True): Later on, the class calls the method read_resolv_conf that has: try: f = stack.enter_context(open(f)) except OSError: # /etc/resolv.conf doesn't exist, can't be read, etc. raise NoResolverConfiguration The test cases are of course instantiating the Resolver object to test it, and calls it with the default configuration (ie: /etc/resolv.conf as default), with something like this: r = dns.resolver.Resolver(configure=False) So, any test case that does that fails simply because the *FILE* /etc/resolv.conf isn't there on the filesystem (and not because there's no working DNS server, which would be just fine). One could argue that the test cases should aways instantiate the Resolver object with a non-default (test only) filename argument. Well, I agree with that: please propose such a patch upstream. But does it deserve anyone time? I don't think so. We're achieving absolutely nothing doing this: this doesn't improve Debian... Cheers, Thomas Goirand (zigo)
Re: Require packages to build without any configured DNS
On ബു, സെപ്റ്റം 8 2021 at 06:10:56 വൈകു +0300 +0300, Adrian Bunk wrote: On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote: On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand wrote: > Therefore, I am in the opinion that we should let the package run its > test as much as possible, especially considering that it's not doing > actual network outbound connections. Can't we run these tests as autopkgtests? That would only move the problem elsewhere, since this creates a similar question whether such tests should need a "needs-internet" restriction for autopkgtest which might result in them being skipped in most cases. I don't think the default autopkgtest environment should be as restrictive as the build environment. So adding this to default autopkgtest enviroment is not the same as adding it to default build environment.
Re: Require packages to build without any configured DNS
On Wed, Sep 8, 2021 at 8:23 PM Thomas Goirand wrote: > Later on, the class calls the method read_resolv_conf that has: It also fails if the file exists but has no nameservers: if len(self.nameservers) == 0: raise NoResolverConfiguration > So, any test case that does that fails simply because the *FILE* > /etc/resolv.conf isn't there on the filesystem (and not because there's > no working DNS server, which would be just fine). That seems like a bug in the test cases, they shouldn't be testing the build time environment like that, since it could differ from the runtime environment. There are nss_wrapper/resolv_wrapper for mocking away the build-time DNS resolving infrastructure. https://cwrap.org/nss_wrapper.html https://cwrap.org/resolv_wrapper.html > One could argue that the test cases should aways instantiate the > Resolver object with a non-default (test only) filename argument. Agreed. > I agree with that: please propose such a patch upstream. But does it > deserve anyone time? I don't think so. We're achieving absolutely > nothing doing this: this doesn't improve Debian... It improves support for offline systems, which often don't have a working /etc/resolv.conf -- bye, pabs https://wiki.debian.org/PaulWise
Re: Require packages to build without any configured DNS
On Wed, Sep 8, 2021 at 9:51 PM Pirate Praveen wrote: > I don't think the default autopkgtest environment should be as > restrictive as the build environment. So adding this to default > autopkgtest enviroment is not the same as adding it to default build > environment. It is already the case that the autopkgtest "needs-internet" restriction is not enabled by default. Personally I think that is the right choice, to give people the option of not running such tests on offline machines or where arbitrary outgoing Internet connections are not allowed. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Require packages to build without any configured DNS
On Thu, Sep 09, 2021 at 04:45:35AM +, Paul Wise wrote: >... > That seems like a bug in the test cases, they shouldn't be testing the > build time environment like that, since it could differ from the > runtime environment. These are usually not the tests of dnspython. dnspython even has some support for using a different file instead of /etc/resolv.conf, the problem is that there are several other packages in the callstack before dnspython in these failing tests. Note that even if you would be mocking /etc/resolv.conf, you'd still have to add a nameserver IP address in the mocked /etc/resolv.conf At that point you might as well install the mocked resolv.conf as /etc/resolv.conf in build environments. > There are nss_wrapper/resolv_wrapper for mocking > away the build-time DNS resolving infrastructure. > > https://cwrap.org/nss_wrapper.html > https://cwrap.org/resolv_wrapper.html >... This is mocking the C library functionality, which is not used by dnspython. > bye, > pabs cu Adrian
Re: Require packages to build without any configured DNS
Thomas Goirand wrote: > On 9/8/21 6:01 PM, Josh Triplett wrote: > > Now, that said, if the build process actually wants a DNS server to > > run tests against, it should provide or depend on such a DNS server, > > and configure it for such tests. > > Just to be 100% sure we're on the same page: that's *not* what dnspython > is doing. It's a client library that's testing parsing of the > /etc/resolv.conf format, and it just expects it to be there for parsing. I understood that; I'd just wanted to make it clear that while programs parsing /etc/resolv.conf should assume a nameserver on localhost if /etc/resolv.conf doesn't exist, that doesn't mean that build processes should actually require that such a nameserver be running.
Re: Require packages to build without any configured DNS
On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote: >... > I think dnspython's previous approach was correct: just like glibc, musl, and > other libraries, if /etc/resolv.conf is missing they should treat that as > though it specified a nameserver on localhost. How libraries implement a standard high-level C interface is not necessarily relevant for how a DNS library implements a low-level interface. > The change to make that a > configuration error, instead, breaks real configurations that intentionally > don't have /etc/resolv.conf. > > Among other things, having a DNS server on localhost (or forwarding the DNS > port on localhost to your real DNS server) means that a chroot without > /etc/resolv.conf still has functional DNS. It is debatable whether this is a feature or a bug. Having to configure a nameserver when you want DNS is less surprising than software automatically using nameservers like 127.0.0.1 or 8.8.8.8 when none is configured. > Now, that said, if the build process actually wants a DNS server to run tests > against, it should provide or depend on such a DNS server, and configure it > for > such tests. >... Depending on and configuring a normal DNS server might not happen in practice, since the build process running as a normal user would have to configure and manually start it running on a non-privileged port. Trying to resolve DNS addresses on the internet during the build is not permitted. > - Josh Triplett cu Adrian
Re: Require packages to build without any configured DNS
On 9/9/21 9:07 AM, Adrian Bunk wrote: > On Thu, Sep 09, 2021 at 04:45:35AM +, Paul Wise wrote: >> ... >> That seems like a bug in the test cases, they shouldn't be testing the >> build time environment like that, since it could differ from the >> runtime environment. > > These are usually not the tests of dnspython. > > dnspython even has some support for using a different file instead of > /etc/resolv.conf, the problem is that there are several other packages > in the callstack before dnspython in these failing tests. > > Note that even if you would be mocking /etc/resolv.conf, you'd still > have to add a nameserver IP address in the mocked /etc/resolv.conf > At that point you might as well install the mocked resolv.conf > as /etc/resolv.conf in build environments. Exactly. Which is why I wrote that we would be achieving nothing by mandating a broken /etc/resolv.conf *IN THIS SPECIFIC CASE* (ie: where the package is *NOT* doing any exteral DNS query). I do believe, however, that we should not allow real DNS queries during build time (just like accessing any external resource on the internet should be forbiden, DNS shouldn't be an exception). But that's not what happening with dnspython (it builds fine without any internet connectivity, it just wants a valid /etc/resolv.conf so it can parse it). Cheers, Thomas Goirand (zigo)
Re: Require packages to build without any configured DNS
On 9/10/21 10:53 AM, Josh Triplett wrote: > Thomas Goirand wrote: >> On 9/8/21 6:01 PM, Josh Triplett wrote: >>> Now, that said, if the build process actually wants a DNS server to >>> run tests against, it should provide or depend on such a DNS server, >>> and configure it for such tests. >> >> Just to be 100% sure we're on the same page: that's *not* what dnspython >> is doing. It's a client library that's testing parsing of the >> /etc/resolv.conf format, and it just expects it to be there for parsing. > > I understood that; I'd just wanted to make it clear that while programs > parsing /etc/resolv.conf should assume a nameserver on localhost if > /etc/resolv.conf doesn't exist I don't understand why that should be the case. If there's a local nameserver, then it should be configured in resolv.conf as "nameserver 127.0.0.1" no? Cheers, Thomas Goirand (zigo)
Re: Require packages to build without any configured DNS
Thomas Goirand wrote: > On 9/10/21 10:53 AM, Josh Triplett wrote: > > Thomas Goirand wrote: > >> On 9/8/21 6:01 PM, Josh Triplett wrote: > >>> Now, that said, if the build process actually wants a DNS server to > >>> run tests against, it should provide or depend on such a DNS server, > >>> and configure it for such tests. > >> > >> Just to be 100% sure we're on the same page: that's *not* what dnspython > >> is doing. It's a client library that's testing parsing of the > >> /etc/resolv.conf format, and it just expects it to be there for parsing. > > > > I understood that; I'd just wanted to make it clear that while programs > > parsing /etc/resolv.conf should assume a nameserver on localhost if > > /etc/resolv.conf doesn't exist > > I don't understand why that should be the case. If there's a local > nameserver, then it should be configured in resolv.conf as "nameserver > 127.0.0.1" no? Three reasons: - It's the documented behavior when /etc/resolv.conf doesn't exist. `man resolv.conf` says "If this file does not exist, only the name server on the local machine will be queried, and the search list contains the local domain name determined from the hostname.". - It's the established historical behavior of glibc, musl, adns, and various other resolvers, so breaking it would also be a backwards compatibility break. - This behavior allows providing DNS for a chroot or similar without hacks like mounting a file over /etc/resolv.conf.
Re: Require packages to build without any configured DNS
On Fri, 10 Sep 2021, Adrian Bunk wrote: > On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote: > >... > > I think dnspython's previous approach was correct: just like glibc, musl, > > and > > other libraries, if /etc/resolv.conf is missing they should treat that as > > though it specified a nameserver on localhost. > > How libraries implement a standard high-level C interface is not > necessarily relevant for how a DNS library implements a low-level > interface. It seems to me that upstream should just not raise NoResolverConfiguration, and instead not configure any nameservers. Then, if someone tries to resolve without any configured nameservers, NoNameservers will be raised, which is the same thing that happens if there are no good nameservers, and is less inconsistent with the previous behavior. -- Don Armstrong https://www.donarmstrong.com 2: There is no out. There is only in. -- "The Prisoner (2009 Miniseries)"
Re: Require packages to build without any configured DNS
Hi, Quoting Mattia Rizzolo (2021-09-06 16:39:39) > As the pbuilder maintainer, I've been asked to make it serve a non-working > /etc/resolv.conf just to make that bug above moot, so I'm quite biased on the > matter myself :) sbuild already disables network access for all chroot backends that support it. Schroot, the default chroot backend, currently doesn't allow this. See #802849. The only chroot backend that allows disabling the network is the unshare backend. It does so, by unsharing the network namespace, only bringing up the loopback interface and writing an empty /etc/resolv.conf. Thanks! cheers, josch signature.asc Description: signature
Re: Require packages to build without any configured DNS
On Mon, Sep 13, 2021 at 04:05:57PM -0700, Don Armstrong wrote: > On Fri, 10 Sep 2021, Adrian Bunk wrote: > > On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote: > > >... > > > I think dnspython's previous approach was correct: just like glibc, musl, > > > and > > > other libraries, if /etc/resolv.conf is missing they should treat that as > > > though it specified a nameserver on localhost. > > > > How libraries implement a standard high-level C interface is not > > necessarily relevant for how a DNS library implements a low-level > > interface. > > It seems to me that upstream should just not raise > NoResolverConfiguration, and instead not configure any nameservers. > > Then, if someone tries to resolve without any configured nameservers, > NoNameservers will be raised, which is the same thing that happens if > there are no good nameservers, and is less inconsistent with the > previous behavior. I would consider it worse if init of a module returns success in a situation where it is known that the whole module is nonfunctional, and then returns an error every time a thread tries to use the module. There are obviously several options what could be done, but it's difficult to call the current behaviour a bug in a DNS module. The large picture is that there is no piece of software involved in all this that is clearly buggy itself, the problem is that all pieces together are at the border of forbidden "uses network" in Debian builds. My personal stake in all this is that I've raised the topic twice with Mattia since it makes it a lot harder to use reproducible for finding FTBFS, and I was initially making the case for having the IP address of a non-existing nameserver in /etc/resolv.conf in the reproducible environment. My impression of this discussion is that unless someone discusses and convinces an upstream to change their (not obviously buggy) software, the affected packages must not run these tests during the build and if there are autopkgtest they must have a "needs-internet" restriction. cu Adrian
Re: Require packages to build without any configured DNS
On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Mattia Rizzolo (2021-09-06 16:39:39) > > As the pbuilder maintainer, I've been asked to make it serve a non-working > > /etc/resolv.conf just to make that bug above moot, so I'm quite biased on > > the > > matter myself :) > > sbuild already disables network access for all chroot backends that support > it. As several people already stated, this is *not* about network access. > Schroot, the default chroot backend, currently doesn't allow this. See > #802849. Likewise pbuilder, yes. > The only chroot backend that allows disabling the network is the unshare > backend. It does so, by unsharing the network namespace, only bringing up the > loopback interface and writing an empty /etc/resolv.conf. So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build packages using dnspython in their tests with your configuration? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Require packages to build without any configured DNS
Quoting Mattia Rizzolo (2021-09-14 15:34:36) > On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues > wrote: > > Hi, > > > > Quoting Mattia Rizzolo (2021-09-06 16:39:39) > > > As the pbuilder maintainer, I've been asked to make it serve a non-working > > > /etc/resolv.conf just to make that bug above moot, so I'm quite biased on > > > the > > > matter myself :) > > > > sbuild already disables network access for all chroot backends that support > > it. > > As several people already stated, this is *not* about network access. Yes, I mention it for context. > > Schroot, the default chroot backend, currently doesn't allow this. See > > #802849. > > Likewise pbuilder, yes. > > > The only chroot backend that allows disabling the network is the unshare > > backend. It does so, by unsharing the network namespace, only bringing up > > the > > loopback interface and writing an empty /etc/resolv.conf. > > So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build > packages using dnspython in their tests with your configuration? Correct. This currently fails: sbuild -d unstable --chroot-mode=unshare python-oslo.rootwrap The error message is the same as for the package mentioned in #989171, namely: https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-oslo.rootwrap.html This is why I'm writing about sbuild. I wonder if it's a bug for sbuild to write out an empty /etc/resolv.conf. Thanks! cheers, josch signature.asc Description: signature
Re: Require packages to build without any configured DNS
On September 14, 2021 5:16:51 PM UTC, Johannes Schauer Marin Rodrigues wrote: >Quoting Mattia Rizzolo (2021-09-14 15:34:36) >> On Tue, Sep 14, 2021 at 10:05:01AM +0200, Johannes Schauer Marin Rodrigues >> wrote: >> > Hi, >> > >> > Quoting Mattia Rizzolo (2021-09-06 16:39:39) >> > > As the pbuilder maintainer, I've been asked to make it serve a >> > > non-working >> > > /etc/resolv.conf just to make that bug above moot, so I'm quite biased >> > > on the >> > > matter myself :) >> > >> > sbuild already disables network access for all chroot backends that >> > support it. >> >> As several people already stated, this is *not* about network access. > >Yes, I mention it for context. > >> > Schroot, the default chroot backend, currently doesn't allow this. See >> > #802849. >> >> Likewise pbuilder, yes. >> >> > The only chroot backend that allows disabling the network is the unshare >> > backend. It does so, by unsharing the network namespace, only bringing up >> > the >> > loopback interface and writing an empty /etc/resolv.conf. >> >> So you ship an *empty* /etc/resolv.conf? Then I suppose you also can't build >> packages using dnspython in their tests with your configuration? > >Correct. This currently fails: > >sbuild -d unstable --chroot-mode=unshare python-oslo.rootwrap > >The error message is the same as for the package mentioned in #989171, namely: > >https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-oslo.rootwrap.html > >This is why I'm writing about sbuild. I wonder if it's a bug for sbuild to >write out an empty /etc/resolv.conf. At least based on the error text, I think it would be the same whether it was empty or missing: "Resolver configuration could not be read or specified no nameserver" As far as I can tell, dnspython is behaving reasonably. I don't think we should make it so it is an error for a package to complain it can't function. Scott K
