Re: Require packages to build without any configured DNS

2021-09-14 Thread Scott Kitterman



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



Re: Require packages to build without any configured DNS

2021-09-14 Thread Johannes Schauer Marin Rodrigues
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

2021-09-14 Thread Mattia Rizzolo
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

2021-09-14 Thread Adrian Bunk
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

2021-09-14 Thread Johannes Schauer Marin Rodrigues
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

2021-09-13 Thread Don Armstrong
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

2021-09-12 Thread Josh Triplett
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

2021-09-12 Thread Thomas Goirand
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

2021-09-12 Thread Thomas Goirand
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

2021-09-10 Thread Adrian Bunk
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

2021-09-10 Thread Josh Triplett
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

2021-09-09 Thread Adrian Bunk
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

2021-09-08 Thread Paul Wise
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

2021-09-08 Thread Paul Wise
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

2021-09-08 Thread Pirate Praveen




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

2021-09-08 Thread Thomas Goirand
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

2021-09-08 Thread Adrian Bunk
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

2021-09-08 Thread Josh Triplett
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

2021-09-08 Thread Helmut Grohne
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

2021-09-08 Thread Adrian Bunk
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

2021-09-08 Thread Pirate Praveen




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

2021-09-08 Thread Thomas Goirand
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

2021-09-08 Thread Adrian Bunk
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

2021-09-07 Thread Don Armstrong
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