Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #101558 > unrolled thread

Require packages to build without any configured DNS

Back to article view | Back to linux.debian.devel

Contents

  Require packages to build without any configured DNS Mattia Rizzolo <mattia@debian.org> - 2021-09-06 16:50 +0200
    Re: Require packages to build without any configured DNS Don Armstrong <don@debian.org> - 2021-09-08 01:50 +0200
      Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-08 15:00 +0200
    Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-08 16:20 +0200
      Re: Require packages to build without any configured DNS Pirate Praveen <praveen@onenetbeyond.org> - 2021-09-08 16:30 +0200
        Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-08 17:30 +0200
          Re: Require packages to build without any configured DNS Pirate Praveen <praveen@onenetbeyond.org> - 2021-09-09 00:00 +0200
            Re: Require packages to build without any configured DNS Paul Wise <pabs@debian.org> - 2021-09-09 06:50 +0200
    Re: Require packages to build without any configured DNS Helmut Grohne <helmut@subdivi.de> - 2021-09-08 18:00 +0200
      Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-08 19:10 +0200
      Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-08 22:30 +0200
        Re: Require packages to build without any configured DNS Paul Wise <pabs@debian.org> - 2021-09-09 06:50 +0200
          Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-09 09:40 +0200
            Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-12 21:10 +0200
        Re: Require packages to build without any configured DNS Josh Triplett <josh@joshtriplett.org> - 2021-09-10 11:00 +0200
          Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-12 21:10 +0200
            Re: Require packages to build without any configured DNS Josh Triplett <josh@joshtriplett.org> - 2021-09-13 06:20 +0200
    Re: Require packages to build without any configured DNS Josh Triplett <josh@joshtriplett.org> - 2021-09-08 18:10 +0200
      Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-10 22:40 +0200
        Re: Require packages to build without any configured DNS Don Armstrong <don@debian.org> - 2021-09-14 09:00 +0200
          Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-14 14:50 +0200
    Re: Require packages to build without any configured DNS Johannes Schauer Marin Rodrigues <josch@debian.org> - 2021-09-14 10:20 +0200
      Re: Require packages to build without any configured DNS Mattia Rizzolo <mattia@debian.org> - 2021-09-14 15:40 +0200
        Re: Require packages to build without any configured DNS Johannes Schauer Marin Rodrigues <josch@debian.org> - 2021-09-14 19:20 +0200
          Re: Require packages to build without any configured DNS Scott Kitterman <debian@kitterman.com> - 2021-09-14 19:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#101706

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

[toc] | [prev] | [next] | [standalone]

#101704

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#101707

[Multipart message — attachments visible in raw view] — view raw

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  `-

[toc] | [prev] | [next] | [standalone]

#101713

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#101714

On September 14, 2021 5:16:51 PM UTC, Johannes Schauer Marin Rodrigues <josch@debian.org> 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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.devel

csiph-web