Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-19 Thread Aurelien Jarno
On 2016-07-11 15:13, Aurelien Jarno wrote:
> On 2016-07-11 10:48, Craig Small wrote:
> > Hi Aurelien,
> 
> Hi,
> 
> >   It's definitely there because:
> > a) I could compile procps on my kfreebsd jessie setup
> 
> I have just tried to build procps version 2:3.3.12-1 in a kfreebsd
> chroot and it fails the same way:
> 
> | watch.c: In function 'output_header':
> | watch.c:375:16: error: 'HOST_NAME_MAX' undeclared (first use in this 
> function)
> |   char hostname[HOST_NAME_MAX + 1];
> | ^
> | watch.c:375:16: note: each undeclared identifier is reported only once for 
> each function it appears in
> 
> 
> > b) I could grep for it in the same system
> 
> Can you tell me which file contains this definition?
> 
> > c)
> > https://sources.debian.net/src/glibc/2.22-10/sysdeps/unix/bsd/bsd4.4/kfreebsd/bits/local_lim.h/?hl=25#L25
> 
> Indeed, that said the following file is the one installed in the
> include directory:
> 
> https://sources.debian.net/src/glibc/2.22-10/sysdeps/unix/bsd/bsd4.4/kfreebsd/fbtl/bits/local_lim.h/
> 
> Now it looks like we should merge the two files.

I have done that now, it will be in the next glibc upload. Note however
the following comment in  of a plain FreeBSD system:

| /*
|  * We leave the following values undefined to force applications to either
|  * assume conservative values or call sysconf() to get the current value.
|  *
|  * HOST_NAME_MAX
|  *
|  * (We should do this for most of the values currently defined here,
|  * but many programs are not prepared to deal with this yet.)
|  */

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-13 Thread Aurelien Jarno
On 2016-07-13 10:18, Craig Small wrote:
> On Tue, Jul 12, 2016 at 11:43 PM Aaron M. Ucko  wrote:
> 
> > Craig Small  writes:
> >
> > > /usr/include/x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64
> >
> > I just took a closer look and noticed the "-linux-" in this path.  This
> > is not a header I would expect kFreeBSD builds to use.
> >
> > I completely agree it seemed odd that a kfreebsd system included a header
> with linux in it.

Could you please tell me which package provides this file on you system?
It doesn't seem to come from libc0.1-dev:kfreebsd-amd64.

> However it is included at least on my system and there is nothing "linuxy"
> about that definition. Perhaps the value is but it seems odd you would put
> this into a linux only header.

The definition itself is nothing "linuxy", but the value itself is. It
seems the correct value would be 256 on a FreeBSD based system instead
of 64 on a Linux based system.

As I said in my previous email, it's something we can change for at
least kFreeBSD.

> I have a (yet another kfreebsd kludge) work-around so procps will compile
> but it seems to me something to get around the deficiencies or
> discrepancies of the libc headers. It's no real biggie to have that in
> procps though.

Same don't hesitate to list the issues in the kernel headers, that can
probably be changed.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-13 Thread Craig Small
On Tue, Jul 12, 2016 at 11:43 PM Aaron M. Ucko  wrote:

> Craig Small  writes:
>
> > /usr/include/x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64
>
> I just took a closer look and noticed the "-linux-" in this path.  This
> is not a header I would expect kFreeBSD builds to use.
>
> I completely agree it seemed odd that a kfreebsd system included a header
with linux in it.

However it is included at least on my system and there is nothing "linuxy"
about that definition. Perhaps the value is but it seems odd you would put
this into a linux only header.

I have a (yet another kfreebsd kludge) work-around so procps will compile
but it seems to me something to get around the deficiencies or
discrepancies of the libc headers. It's no real biggie to have that in
procps though.

 - Craig


Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-12 Thread Aaron M. Ucko
Craig Small  writes:

> /usr/include/x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64

I just took a closer look and noticed the "-linux-" in this path.  This
is not a header I would expect kFreeBSD builds to use.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-12 Thread Craig Small
On Mon, Jul 11, 2016 at 11:13 PM Aurelien Jarno 
wrote:

> Can you tell me which file contains this definition?
>
>From my reply in the bug report:

csmall@freebsd1:~$ grep '[[:space:]]HOST_NAME_MAX[[:space:]]' `find
/usr/include -type f`
/usr/include/x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64


local_lim.h is part of libc6-dev version 2.19-18+deb8u4

It seems very odd it was there and then disappeared.
Or... is it there for kfreebsd-amd64 and not there for kfreebsd-i386?

 - Craig


Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-11 Thread Aurelien Jarno
On 2016-07-11 10:48, Craig Small wrote:
> Hi Aurelien,

Hi,

>   It's definitely there because:
> a) I could compile procps on my kfreebsd jessie setup

I have just tried to build procps version 2:3.3.12-1 in a kfreebsd
chroot and it fails the same way:

| watch.c: In function 'output_header':
| watch.c:375:16: error: 'HOST_NAME_MAX' undeclared (first use in this function)
|   char hostname[HOST_NAME_MAX + 1];
| ^
| watch.c:375:16: note: each undeclared identifier is reported only once for 
each function it appears in


> b) I could grep for it in the same system

Can you tell me which file contains this definition?

> c)
> https://sources.debian.net/src/glibc/2.22-10/sysdeps/unix/bsd/bsd4.4/kfreebsd/bits/local_lim.h/?hl=25#L25

Indeed, that said the following file is the one installed in the
include directory:

https://sources.debian.net/src/glibc/2.22-10/sysdeps/unix/bsd/bsd4.4/kfreebsd/fbtl/bits/local_lim.h/

Now it looks like we should merge the two files.

Aurelien


> It seems very odd it comes and goes, perhaps it is there but something is
> not including local_lim.h?
> 
> On Mon, Jul 11, 2016 at 8:26 PM Aurelien Jarno  wrote:
> 
> > On 2016-07-10 18:50, Aaron M. Ucko wrote:
> > > Craig Small  writes:
> > >
> > > > local_lim.h is part of libc6-dev version 2.19-18+deb8u4
> > > > So what version are you using and why did the definition go away?
> > >
> > > unstable has 2.23-1, which dropped this definition on hurd-i386 and
> > > kfreebsd-*.  It's not clear why it went away, or whether the change was
> > > even intentional; copying debian-glibc for clarification.
> >
> > TTBOMK local_lim.h on kfreebsd or hurd has never contained such a
> > definition (even in 2.19-18+deb8u4), so it hasn't been dropped.
> >
> > Now we might want to add such a definition. It seems to be 256 on
> > FreeBSD. I have no idea for Hurd, but I guess it might actually be
> > dynamic.
> >
> > Aurelien
> >
> > --
> > Aurelien Jarno  GPG: 4096R/1DDD8C9B
> > aurel...@aurel32.net http://www.aurel32.net
> >

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-11 Thread Craig Small
Hi Aurelien,
  It's definitely there because:
a) I could compile procps on my kfreebsd jessie setup
b) I could grep for it in the same system
c)
https://sources.debian.net/src/glibc/2.22-10/sysdeps/unix/bsd/bsd4.4/kfreebsd/bits/local_lim.h/?hl=25#L25

It seems very odd it comes and goes, perhaps it is there but something is
not including local_lim.h?

On Mon, Jul 11, 2016 at 8:26 PM Aurelien Jarno  wrote:

> On 2016-07-10 18:50, Aaron M. Ucko wrote:
> > Craig Small  writes:
> >
> > > local_lim.h is part of libc6-dev version 2.19-18+deb8u4
> > > So what version are you using and why did the definition go away?
> >
> > unstable has 2.23-1, which dropped this definition on hurd-i386 and
> > kfreebsd-*.  It's not clear why it went away, or whether the change was
> > even intentional; copying debian-glibc for clarification.
>
> TTBOMK local_lim.h on kfreebsd or hurd has never contained such a
> definition (even in 2.19-18+deb8u4), so it hasn't been dropped.
>
> Now we might want to add such a definition. It seems to be 256 on
> FreeBSD. I have no idea for Hurd, but I guess it might actually be
> dynamic.
>
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>


Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-11 Thread Aurelien Jarno
On 2016-07-10 18:50, Aaron M. Ucko wrote:
> Craig Small  writes:
> 
> > local_lim.h is part of libc6-dev version 2.19-18+deb8u4
> > So what version are you using and why did the definition go away?
> 
> unstable has 2.23-1, which dropped this definition on hurd-i386 and
> kfreebsd-*.  It's not clear why it went away, or whether the change was
> even intentional; copying debian-glibc for clarification.

TTBOMK local_lim.h on kfreebsd or hurd has never contained such a
definition (even in 2.19-18+deb8u4), so it hasn't been dropped.

Now we might want to add such a definition. It seems to be 256 on
FreeBSD. I have no idea for Hurd, but I guess it might actually be
dynamic.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Re: Bug#830734: procps: FTBFS[!linux]: 'HOST_NAME_MAX' undeclared

2016-07-10 Thread Aaron M. Ucko
Craig Small  writes:

> local_lim.h is part of libc6-dev version 2.19-18+deb8u4
> So what version are you using and why did the definition go away?

unstable has 2.23-1, which dropped this definition on hurd-i386 and
kfreebsd-*.  It's not clear why it went away, or whether the change was
even intentional; copying debian-glibc for clarification.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu