Bug 716284 – sys-auth/nss-myhostname-0.3 : nss-myhostname.c: error: conflicting types for _nss_myhostname_gethostbyname4_r

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Toralf Förster 2020-04-05 09:11:26 UTC]

  114 |                 struct gaih_addrtuple **pat,
      |                        ^~~~~~~~~~~~~~
nss-myhostname.c:112:17: error: conflicting types for _nss_myhostname_gethostbyname4_r
  112 | enum nss_status _nss_myhostname_gethostbyname4_r(
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nss-myhostname.c:68:17: note: previous declaration of _nss_myhostname_gethostbyname4_r was here

  -------------------------------------------------------------------

  This is an unstable amd64 chroot image at a tinderbox (==build bot)
  name: 17.0_musl-20200328-141627

  -------------------------------------------------------------------

gcc-config -l:
 [1] x86_64-gentoo-linux-musl-9.3.0 *
clang version 10.0.0 
Target: x86_64-gentoo-linux-musl
Thread model: posix
InstalledDir: /usr/lib/llvm/10/bin
/usr/lib/llvm/10
10.0.0
Available Python interpreters, in order of preference:
  [1]   python3.8
  [2]   python3.7
  [3]   python3.6
  [4]   python2.7 (fallback)
Available Ruby profiles:
  [1]   ruby24 (with Rubygems)
  [2]   ruby25 (with Rubygems) *
Available Rust versions:
  [1]   rust-1.42.0 *
The following VMs are available for generation-2:
Available Java Virtual Machines:
  (none found)


timestamp of HEAD at this tinderbox image:
/var/db/repos/gentoo	Sun Apr  5 03:07:54 UTC 2020
/var/db/repos/musl	Sat Apr  4 03:02:24 UTC 2020

emerge -qpvO sys-auth/nss-myhostname
[ebuild  N    ] sys-auth/nss-myhostname-0.3

[Comment 1 Toralf Förster 2020-04-05 09:11:29 UTC]

Created attachment 630346 [details]
emerge-info.txt

[Comment 2 Toralf Förster 2020-04-05 09:11:32 UTC]

Created attachment 630348 [details]
emerge-history.txt

[Comment 3 Toralf Förster 2020-04-05 09:11:35 UTC]

Created attachment 630350 [details]
environment

[Comment 4 Toralf Förster 2020-04-05 09:11:38 UTC]

Created attachment 630352 [details]
etc.portage.tbz2

[Comment 5 Toralf Förster 2020-04-05 09:11:40 UTC]

Created attachment 630354 [details]
logs.tbz2

[Comment 6 Toralf Förster 2020-04-05 09:11:43 UTC]

Created attachment 630356 [details]
sys-auth:nss-myhostname-0.3:20200405-060449.log

[Comment 7 Toralf Förster 2020-04-05 09:11:46 UTC]

Created attachment 630358 [details]
temp.tbz2

[Comment 8 Michał Górny 2020-09-13 07:12:03 UTC]

Does musl actually use NSS?

[Comment 9 Sam James 2020-09-13 07:13:10 UTC]

(In reply to Michał Górny from comment #8)
> Does musl actually use NSS?

no

[Comment 10 Michael 'veremitz' Everitt 2020-09-13 14:43:27 UTC]

(In reply to Sam James from comment #9)
> (In reply to Michał Górny from comment #8)
> > Does musl actually use NSS?
> 
> no

I think, rightly, that this can be fixed with some form of mask, yes?

[Comment 11 Michał Górny 2020-09-13 17:06:41 UTC]

Yes, I suppose all NSS providers should be masked in musl profiles.

[Comment 12 Michael 'veremitz' Everitt 2020-09-15 20:16:36 UTC]

(In reply to Michał Górny from comment #11)
> Yes, I suppose all NSS providers should be masked in musl profiles.

I'll have a look through the repo, and suggest some masks to musl@ via a PR or such-like. Then this kinda thing shouldn't crop up again.

[Comment 13 Jory A. Pratt 2020-09-17 15:14:39 UTC]

(In reply to Michael 'veremitz' Everitt from comment #12)
> (In reply to Michał Górny from comment #11)
> > Yes, I suppose all NSS providers should be masked in musl profiles.
> 
> I'll have a look through the repo, and suggest some masks to musl@ via a PR
> or such-like. Then this kinda thing shouldn't crop up again.

This is already fixed in the overlay.