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