For discussion of Alpine Linux development and developer support

8 4

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

William Pitcock
Details
Message ID
<CA+T2pCErwS_KFW98fvJ86-cx-dmpruxeCVKu-gG-2Ud08UVwpw@mail.gmail.com>
Sender timestamp
1485679798
DKIM signature
missing
Download raw message
Hello,

On Fri, Jan 27, 2017 at 1:59 AM, 7heo <7heo@mail.com> wrote:
> I am really confused that you want to use a wrong vocab because GNU software already use it. Plus, it was my understanding that our tool's name isn't 'make' (since it's about identical terms).

Has very little to do with GNU software, "make check" is #2 most
frequently used in APKBUILD to invoke the testsuite behind "make
test".  "test" is a shell built-in and cannot be used, as others have
said in the thread.  The reason why "make check" is used so
frequently, is because those packages have an automake-based build
system.

> I understand that for many people this discussion may seems like a waste of time, but using the correct vocabulary is an essential part of code-as-documentation.
>
> Going with check is not a huge inaccuracy I admit; but it will most likely effectively hinder the understanding of newcomers while lowering the learning curve for GNU people/users.

I'm not really convinced that any new packager will be hindered any
further by that considering that we can explain it in the "how to
write an APKBUILD" guide.  We should not make decisions based on
people who do not read docs.

> I can explain in a separate mail (or on IRC) why I think it is a bad enough idea to attract GNU contributors to alpine, to justify continuing this discussion; but I'll assume here that all alpine contributors share a similar view on the GNU code style.

That's not very nice.  We should, and do, welcome anyone who wants to
contribute as long as their contributions are in line with the project
overall.

> So, does anyone agree?

I agree that some care should be taken to ensure the tests verb is
well known.  This is why I chose "check" as an alternative to
"testsuite" (since it is #2 behind "make test" which we can't use).
The most preferable option would be "test" but it's not happening
without a complete rewrite of abuild, which I don't see happening just
to support this...

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

William Pitcock
Details
Message ID
<CA+T2pCHJ9-aOzd_A2=5W_eF__ja+uC4yPf6LPyOQpxJKKAreUQ@mail.gmail.com>
In-Reply-To
<5890704A.8090402@mail.com> (view parent)
Sender timestamp
1485883297
DKIM signature
missing
Download raw message
Hello,

On Tue, Jan 31, 2017 at 5:08 AM, 7heo <7heo@mail.com> wrote:
> Hey again,
>
> On 1/29/2017 9:49 AM, William Pitcock wrote:
>>
>> Hello,
>>
>> On Fri, Jan 27, 2017 at 1:59 AM, 7heo <7heo@mail.com> wrote:
>>>
>>> I am really confused that you want to use a wrong vocab because GNU
>>> software already use it. Plus, it was my understanding that our tool's name
>>> isn't 'make' (since it's about identical terms).
>>
>>
>> Has very little to do with GNU software, "make check" is #2 most
>> frequently used in APKBUILD to invoke the testsuite behind "make
>> test".  "test" is a shell built-in and cannot be used, as others have
>> said in the thread.  The reason why "make check" is used so
>> frequently, is because those packages have an automake-based build
>> system.
>
> Yes, it was my understanding that the choice of "check" as an alternative to
> "test" isn't a core belief of the GNU community. However, it is proposed
> here because it occurs often, and it occurs often because it is used in a
> GNU software. That's nothing new and is what I meant: I do not want to
> repeat the mistakes made by communities we do not wish to follow (please
> tell me if you think I'm wrong), because of their choices and focuses.
>
> TL;DR: Why would we perpetuate a mistake "because it's popular"? I thought
> that this was the very idea alpine was against.

I am not convinced it is a "mistake".  It can be explained that the
"check" phase is "to run checks against the package."

>>> I understand that for many people this discussion may seems like a waste
>>> of time, but using the correct vocabulary is an essential part of
>>> code-as-documentation.
>>>
>>> Going with check is not a huge inaccuracy I admit; but it will most
>>> likely effectively hinder the understanding of newcomers while lowering the
>>> learning curve for GNU people/users.
>>
>> I'm not really convinced that any new packager will be hindered any
>> further by that considering that we can explain it in the "how to
>> write an APKBUILD" guide.  We should not make decisions based on
>> people who do not read docs.
>
> Here, I couldn't disagree more. I would never ask every user, every
> developer, ever person who ever uses a software to read their entire
> documentation thoroughly. There are bits such as proc(5), queue(3) and
> perf_event_open(2) that are just too big. And that is just the tip of the
> iceberg. One of the main reasons why the UNIX philosophy is so popular among
> seasoned geeks is because they can grok most things without having to
> consult the documentation every ten minutes or so. And that is because of
> the high reuse of ideas and concepts as much as the sensible choice of
> vocabulary.

By docs, I mean the example APKBUILD which clearly shows what it is
for.  If they can't look at the example and figure it out, then they
probably aren't going to be able to figure out the rest of the
APKBUILD, either.

>>> I can explain in a separate mail (or on IRC) why I think it is a bad
>>> enough idea to attract GNU contributors to alpine, to justify continuing
>>> this discussion; but I'll assume here that all alpine contributors share a
>>> similar view on the GNU code style.
>>
>> That's not very nice.  We should, and do, welcome anyone who wants to
>> contribute as long as their contributions are in line with the project
>> overall.
>
> That is not what I said. Nor what I wanted to talk about. Attracting people
> isn't at all the same as accepting them. What I meant is that we shouldn't
> favor GNU contributors over random contributors.

We do not have any practice to attract any specific contributors, nor
would our use of "check" as the testsuite invocation cause this.
Perhaps the wording you used originally is unfortunate, but it reads
differently.

>>> So, does anyone agree?
>>
>> I agree that some care should be taken to ensure the tests verb is
>> well known.  This is why I chose "check" as an alternative to
>> "testsuite" (since it is #2 behind "make test" which we can't use).
>> The most preferable option would be "test" but it's not happening
>> without a complete rewrite of abuild, which I don't see happening just
>> to support this...
>
> I still fail to understand why "tests" isn't a viable, more fitting
> alternative (after all, most of the time there will be more than one test).

I originally considered "tests" as an alternative to testsuite besides
"check".  My conclusion was that people would likely mess up and do
something like:

test() { ... }

which would break their APKBUILDs.  "check" on the other hand cannot
have such a fatal error -- at worst you fail to override the default,
while with "tests" if you forget to make it plural, you are overriding
a shell builtin.

Most likely the GNU people came to the same conclusion, which is why
they went with "check".  I chose "check" because Jakub mentioned that
Arch was already using it and GNU software also uses it.  While it is
true that Alpine is not about maintaining the status quo in cases
where the status quo needs disruption, this is not really something we
need to do differently just because we can.

At any rate, it is already in abuild and will be part of abuild 2.30,
so I think it is not productive for you to continue beating a dead
horse.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

7heo
Details
Message ID
<5890704A.8090402@mail.com>
In-Reply-To
<CA+T2pCErwS_KFW98fvJ86-cx-dmpruxeCVKu-gG-2Ud08UVwpw@mail.gmail.com> (view parent)
Sender timestamp
1485860938
DKIM signature
missing
Download raw message
Hey again,

On 1/29/2017 9:49 AM, William Pitcock wrote:
> Hello,
>
> On Fri, Jan 27, 2017 at 1:59 AM, 7heo <7heo@mail.com> wrote:
>> I am really confused that you want to use a wrong vocab because GNU software already use it. Plus, it was my understanding that our tool's name isn't 'make' (since it's about identical terms).
>
> Has very little to do with GNU software, "make check" is #2 most
> frequently used in APKBUILD to invoke the testsuite behind "make
> test".  "test" is a shell built-in and cannot be used, as others have
> said in the thread.  The reason why "make check" is used so
> frequently, is because those packages have an automake-based build
> system.
Yes, it was my understanding that the choice of "check" as an 
alternative to "test" isn't a core belief of the GNU community. However, 
it is proposed here because it occurs often, and it occurs often because 
it is used in a GNU software. That's nothing new and is what I meant: I 
do not want to repeat the mistakes made by communities we do not wish to 
follow (please tell me if you think I'm wrong), because of their choices 
and focuses.

TL;DR: Why would we perpetuate a mistake "because it's popular"? I 
thought that this was the very idea alpine was against.

>
>> I understand that for many people this discussion may seems like a waste of time, but using the correct vocabulary is an essential part of code-as-documentation.
>>
>> Going with check is not a huge inaccuracy I admit; but it will most likely effectively hinder the understanding of newcomers while lowering the learning curve for GNU people/users.
>
> I'm not really convinced that any new packager will be hindered any
> further by that considering that we can explain it in the "how to
> write an APKBUILD" guide.  We should not make decisions based on
> people who do not read docs.

Here, I couldn't disagree more. I would never ask every user, every 
developer, ever person who ever uses a software to read their entire 
documentation thoroughly. There are bits such as proc(5), queue(3) and 
perf_event_open(2) that are just too big. And that is just the tip of 
the iceberg. One of the main reasons why the UNIX philosophy is so 
popular among seasoned geeks is because they can grok most things 
without having to consult the documentation every ten minutes or so. And 
that is because of the high reuse of ideas and concepts as much as the 
sensible choice of vocabulary.

>
>> I can explain in a separate mail (or on IRC) why I think it is a bad enough idea to attract GNU contributors to alpine, to justify continuing this discussion; but I'll assume here that all alpine contributors share a similar view on the GNU code style.
>
> That's not very nice.  We should, and do, welcome anyone who wants to
> contribute as long as their contributions are in line with the project
> overall.
That is not what I said. Nor what I wanted to talk about. Attracting 
people isn't at all the same as accepting them. What I meant is that we 
shouldn't favor GNU contributors over random contributors.

>
>> So, does anyone agree?
>
> I agree that some care should be taken to ensure the tests verb is
> well known.  This is why I chose "check" as an alternative to
> "testsuite" (since it is #2 behind "make test" which we can't use).
> The most preferable option would be "test" but it's not happening
> without a complete rewrite of abuild, which I don't see happening just
> to support this...
I still fail to understand why "tests" isn't a viable, more fitting 
alternative (after all, most of the time there will be more than one test).

>
> William
>
>

Theo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Non-standard C library

William Pitcock
Details
Message ID
<CA+T2pCE36Z8j_wnHCb7gK_VwKt3BOHws-KJLW401s-Of3NN9Ug@mail.gmail.com>
In-Reply-To
<717ca2a3-d579-4ab6-ace2-1bc0dbbb111c@skogtun.org> (view parent)
Sender timestamp
1485888625
DKIM signature
missing
Download raw message
Hello,

On Tue, Jan 31, 2017 at 12:22 PM, Harald Arnesen <harald@skogtun.org> wrote:
> musl defines "IPPORT_RESERVED" in "netdb.h", while both GNU libc and BSD
> libc define it in "netinet/in.h". And I can't find an e-mail address for
> a musl developer without subscribing to their mailing list.
>
>
> This is from a conversation with Snobol maintainer Phil Budne:
>
>> > This one is from an old Asus EeePC 900, running AlpineLinux, which uses
>> > the musl libc instead of glibc. A compile error ('IPPORT_RESERVED'
>> > undeclared) in 'lib/auxil/bindresvport.c' was fixed by
>> > '#include <netdb.h>'
>
> Thanks!
>
> I'd report it as a bug in libc....  IPPORT_RESERVED is a property of
> on the wire protocol (or at least the local TCP stack), while
> <netdb.h> is the interface for hostname lookups.
>
> Linux and BSD agree the constant comes from netinet/in.h
>
> And charmingly, they refuse to define an ifdef so you can tell
> you're using their broken library (because they're never wrong):
>
> http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F
>
> I've put this in after #include <errno.h>:
>
> #if !defined(IPPORT_RESERVED) && !defined(__GLIBC__)
> /*
>  * could be using broken musl libc!
>  * they refuse to identify themselves:
>  * http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F
>  */
> #include <netdb.h>
> #endif

I checked on both a Debian and FreeBSD machine and indeed, they both
have it in netinet/in.h.

What shall we do?

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Non-standard C library

William Pitcock
Details
Message ID
<CA+T2pCEyVO=EZ2m2WtM_BRysJx9sKTSJ11LONK2ckjzLJs68Lg@mail.gmail.com>
In-Reply-To
<717ca2a3-d579-4ab6-ace2-1bc0dbbb111c@skogtun.org> (view parent)
Sender timestamp
1485890728
DKIM signature
missing
Download raw message
Hello,

On Tue, Jan 31, 2017 at 12:22 PM, Harald Arnesen <harald@skogtun.org> wrote:
> musl defines "IPPORT_RESERVED" in "netdb.h", while both GNU libc and BSD
> libc define it in "netinet/in.h". And I can't find an e-mail address for
> a musl developer without subscribing to their mailing list.
>
>
> This is from a conversation with Snobol maintainer Phil Budne:
>
>> > This one is from an old Asus EeePC 900, running AlpineLinux, which uses
>> > the musl libc instead of glibc. A compile error ('IPPORT_RESERVED'
>> > undeclared) in 'lib/auxil/bindresvport.c' was fixed by
>> > '#include <netdb.h>'
>
> Thanks!
>
> I'd report it as a bug in libc....  IPPORT_RESERVED is a property of
> on the wire protocol (or at least the local TCP stack), while
> <netdb.h> is the interface for hostname lookups.

I asked about it on the musl list for you.  They rejected the change
request, citing POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/netdb.h.html

which explicitly says:

"The <netdb.h> header shall define the IPPORT_RESERVED symbolic
constant with the value of the highest reserved Internet port number."

Including both <netinet/in.h> and <netdb.h> is likely more portable
than the Snobol maintainer's current approach, as well.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Non-standard C library

William Pitcock
Details
Message ID
<CA+T2pCEbXX1KecU_qRAv=FLw-X2o0O6oByKVrSsQkfNV3mi0ew@mail.gmail.com>
In-Reply-To
<df5ff2c5-42d7-27f9-caa7-1bc06f7d5ca2@skogtun.org> (view parent)
Sender timestamp
1485906732
DKIM signature
missing
Download raw message
Hello,

On Tue, Jan 31, 2017 at 3:33 PM, Harald Arnesen <harald@skogtun.org> wrote:
> William Pitcock [2017-01-31 20:25]:
>
>> I asked about it on the musl list for you.  They rejected the change
>> request, citing POSIX:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/netdb.h.html
>>
>> which explicitly says:
>>
>> "The <netdb.h> header shall define the IPPORT_RESERVED symbolic
>> constant with the value of the highest reserved Internet port number."
>>
>> Including both <netinet/in.h> and <netdb.h> is likely more portable
>> than the Snobol maintainer's current approach, as well.
>
> And which operating systems follow that Posix standard?

Almost all UNIX-like operating systems follow POSIX.

GNU systems running on Glibc will pick up IPPORT_RESERVED from
<netdb.h> due to it's inclusion of <netinet/in.h>.  While in general,
there is an argument which may be made for following implementation
quirks of the past, depending on <netinet/in.h> to provide
IPPORT_RESERVED is not a requirement of POSIX.  The solution I
mentioned earlier will provide portability for systems which do not
provide IPPORT_RESERVED in netinet/in.h without harming the build
process.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] Non-standard C library

Harald Arnesen
Details
Message ID
<717ca2a3-d579-4ab6-ace2-1bc0dbbb111c@skogtun.org>
In-Reply-To
<CA+T2pCHJ9-aOzd_A2=5W_eF__ja+uC4yPf6LPyOQpxJKKAreUQ@mail.gmail.com> (view parent)
Sender timestamp
1485886957
DKIM signature
missing
Download raw message
musl defines "IPPORT_RESERVED" in "netdb.h", while both GNU libc and BSD
libc define it in "netinet/in.h". And I can't find an e-mail address for
a musl developer without subscribing to their mailing list.


This is from a conversation with Snobol maintainer Phil Budne:

> > This one is from an old Asus EeePC 900, running AlpineLinux, which uses
> > the musl libc instead of glibc. A compile error ('IPPORT_RESERVED'
> > undeclared) in 'lib/auxil/bindresvport.c' was fixed by
> > '#include <netdb.h>'

Thanks!

I'd report it as a bug in libc....  IPPORT_RESERVED is a property of
on the wire protocol (or at least the local TCP stack), while
<netdb.h> is the interface for hostname lookups.

Linux and BSD agree the constant comes from netinet/in.h

And charmingly, they refuse to define an ifdef so you can tell
you're using their broken library (because they're never wrong):

http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F

I've put this in after #include <errno.h>:

#if !defined(IPPORT_RESERVED) && !defined(__GLIBC__)
/*
 * could be using broken musl libc!
 * they refuse to identify themselves:
 * http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F
 */
#include <netdb.h>
#endif
-- 
Hilsen Harald


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Non-standard C library

Harald Arnesen
Details
Message ID
<df5ff2c5-42d7-27f9-caa7-1bc06f7d5ca2@skogtun.org>
In-Reply-To
<CA+T2pCEyVO=EZ2m2WtM_BRysJx9sKTSJ11LONK2ckjzLJs68Lg@mail.gmail.com> (view parent)
Sender timestamp
1485898407
DKIM signature
missing
Download raw message
William Pitcock [2017-01-31 20:25]:

> I asked about it on the musl list for you.  They rejected the change
> request, citing POSIX:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/netdb.h.html
> 
> which explicitly says:
> 
> "The <netdb.h> header shall define the IPPORT_RESERVED symbolic
> constant with the value of the highest reserved Internet port number."
> 
> Including both <netinet/in.h> and <netdb.h> is likely more portable
> than the Snobol maintainer's current approach, as well.

And which operating systems follow that Posix standard?
-- 
Hilsen Harald


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Non-standard C library

Shiz
Details
Message ID
<7E01F0E1-6DC9-4EB4-88AE-F3D5C3425396@shiz.me>
In-Reply-To
<df5ff2c5-42d7-27f9-caa7-1bc06f7d5ca2@skogtun.org> (view parent)
Sender timestamp
1485902559
DKIM signature
missing
Download raw message
> On 31 Jan 2017, at 22:33, Harald Arnesen <harald@skogtun.org> wrote:
> 
> William Pitcock [2017-01-31 20:25]:
> 
>> I asked about it on the musl list for you.  They rejected the change
>> request, citing POSIX:
>> 
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/netdb.h.html
>> 
>> which explicitly says:
>> 
>> "The <netdb.h> header shall define the IPPORT_RESERVED symbolic
>> constant with the value of the highest reserved Internet port number."
>> 
>> Including both <netinet/in.h> and <netdb.h> is likely more portable
>> than the Snobol maintainer's current approach, as well.
> 
> And which operating systems follow that Posix standard?

#include <stdio.h>
#include <netdb.h>

int main(void)
{
    printf("%d\n", IPPORT_RESERVED);
    return 0;
}

ยป uname ; ./ttt
Darwin
1024
$ uname ; ls /lib | grep ld-linux ; ./ttt
Linux
ld-linux-x86-64.so.2
1024
# uname ; ls /lib | grep ld-musl ; ./ttt
Linux
ld-musl-x86_64.so.1
1024

- Shiz