* Re: Rename offensive terminology (master)
@ 2020-06-14 15:09 5% Michael Felt (aixtools)
0 siblings, 0 replies; 15+ results
From: Michael Felt (aixtools) @ 2020-06-14 15:09 UTC (permalink / raw)
To: Don Goodman-Wilson
Cc: Sérgio Augusto Vianna, philipoakley, Johannes Schindelin,
git, Michal Suchánek, newren, brian m. carlson,
Simon Pieters, stolee
How does the saying go...
You can please some of the people all of the time, ..., but you cannot please all of the people all of the time.
I learned as a child that my choice of certain words was influenced by words used by people i trusted. Words that I clearly did not understand completely because when I (tried) to use them, with no negative intention, but saw the use of a word shocked the people who heard me.
Does that mean I was a racist, or am a racist, because I used a word that others considered racist. Yes, I was naive. But I learned words can offend, regardless of intent.
And I feel that is what is missing here. Using a term that someone else takes offense to does not mean any offense was ever intended. But I tire of hearing that I am responsible for knowing what offends “them”. And since I am one of the unlucky, not clearly belonging to a “minority “ of some kind, I may never complain.
But I was well above 40, and learning from my own children, before I learned to deal with all the persecution i had to live through in my early years.
Racism is a powerful word, and it exists everywhere. Sometimes it is intentional - and we need to address that. But do not make the mistake that it is always intentional.
A git “master” or “main” - who really cares. Do not seek offence where none is intended. You only make your own life miserable.
Compare that with teasing (not as horrible as racism it seems). Just remember, teasing is always intentional, the object and objective of teasing is always clear.
The intent of a word choice is not always how it is received.
If “master” offends you, I feel for you. If “main” makes you happy, I am happy for you.
I am saddened that people feel that “master” in git is an expression of racism. It is not. I am saddened that people feel it must be changed because someone takes offense.
I also know my opinion does not matter. The fear of the many becomes the “ring that rules them all”.
Sent from my iPhone
> On 14 Jun 2020, at 15:58, Don Goodman-Wilson <don@goodman-wilson.com> wrote:
>
>
>> MASTER IS NOT INHERENTLY RELATED TO MASTER-SLAVE RELATIONS.
>
> 1) There is a great deal of evidence that that claim is simply not true.
> https://twitter.com/tobie/status/1270290278029631489
> https://twitter.com/jpaulreed/status/1272064807345115137
>
> 2) It's beside the point. Many problematic words and phrases have
> perfectly benign origins, but take on new meanings in new contexts.
>
> I personally reject the kind of moral relativism that is being
> espoused here. In fact, I believe that there is such a thing as
> justice, and that we each have a responsibility to seek it out and
> create it in every corner of our activities, big and small. You can
> abdicate that responsibility, I can't force anyone to do otherwise nor
> would I want to. But history judges harshly those who would throw
> others aside. Of course there are more people in the world than just
> Americans. But there are also Americans, and in particular Black
> Americans. Precisely because git is the tool of choice for open source
> and so much other development work, I believe we have a responsibility
> to build a tool that reflects the values of _all_ that we want to
> welcome into these communities. If you would rather exclude Black
> Americans or others descended from generations of colonial slavery,
> that's your choice, but you need to own the fact that it is an
> inherently racist choice.
>
> Don Goodman-Wilson
>
>> On Sun, Jun 14, 2020 at 2:20 PM Sérgio Augusto Vianna
>> <sergio.a.vianna@gmail.com> wrote:
>> There's nothing to be resolved because there is no problem. If someone
>> reads "master" and gets triggered because all they can think of is
>> racism, that person needs therapy.
^ permalink raw reply [relevance 5%]
* Re: Rename offensive terminology (master)
@ 2020-06-14 15:13 7% ` Michael Felt (aixtools)
0 siblings, 0 replies; 15+ results
From: Michael Felt (aixtools) @ 2020-06-14 15:13 UTC (permalink / raw)
To: Thomas Adam; +Cc: Simon Pieters, Git Users
Btw. The default branch, if it must have a new default label - how about calling it “default”?
Sent from my iPhone
> On 14 Jun 2020, at 16:59, Thomas Adam <thomas@xteddy.org> wrote:
>
> On Mon, 4 May 2020 at 18:22, Simon Pieters <simon@bocoup.com> wrote:
>> To avoid offensive terminology and to avoid further inconsistency, I
>> think git should use a different branch name than "master" when
>> initiating a repo. I don't have a strong opinion, but I like "main"
>> since it shares the first two characters and it's shorter.
>
> Hi Simon,
>
> Definitely agree, and thanks for starting this.
>
> One question that's been rattling round my mind is how we change the
> documentation to suit. By that, I mean, it has become common parlance
> at the moment to say "master" as the canonical branch, because that's
> the one that's been baked as the default. Now that we're making this
> configurable, I'm curious how we're going to change our semantics to
> match the "default" branch (which was "master") when talking about git
> branches, either here on the list, or in documentation.
>
> Kindly,
> Thomas
^ permalink raw reply [relevance 7%]
* Re: Rename offensive terminology (master)
@ 2020-06-14 15:20 4% ` Sérgio Augusto Vianna
0 siblings, 0 replies; 15+ results
From: Sérgio Augusto Vianna @ 2020-06-14 15:20 UTC (permalink / raw)
To: simon; +Cc: git
I'm just posting it here because apparently the guy posted but it wasn't
included here? I don't know.
"Michael Felt aixtools@felt.demon.nl
How does the saying go...
You can please some of the people all of the time, ..., but you cannot please all of the people all of the time.
I learned as a child that my choice of certain words was influenced by words used by people i trusted. Words that I clearly did not understand completely because when I (tried) to use them, with no negative intention, but saw the use of a word shocked the people who heard me.
Does that mean I was a racist, or am a racist, because I used a word that others considered racist. Yes, I was naive. But I learned words can offend, regardless of intent.
And I feel that is what is missing here. Using a term that someone else takes offense to does not mean any offense was ever intended. But I tire of hearing that I am responsible for knowing what offends “them”. And since I am one of the unlucky, not clearly belonging to a “minority “ of some kind, I may never complain.
But I was well above 40, and learning from my own children, before I learned to deal with all the persecution i had to live through in my early years.
Racism is a powerful word, and it exists everywhere. Sometimes it is intentional - and we need to address that. But do not make the mistake that it is always intentional.
A git “master” or “main” - who really cares. Do not seek offence where none is intended. You only make your own life miserable.
Compare that with teasing (not as horrible as racism it seems). Just remember, teasing is always intentional, the object and objective of teasing is always clear.
The intent of a word choice is not always how it is received.
If “master” offends you, I feel for you. If “main” makes you happy, I am happy for you.
I am saddened that people feel that “master” in git is an expression of racism. It is not. I am saddened that people feel it must be changed because someone takes offense.
I also know my opinion does not matter. The fear of the many becomes the “ring that rules them all”. "
^ permalink raw reply [relevance 4%]
* COMMENTS: building git on AIX
@ 2019-10-28 14:00 5% Michael Felt
0 siblings, 0 replies; 15+ results
From: Michael Felt @ 2019-10-28 14:00 UTC (permalink / raw)
To: git
I have, a couple of time, successfully built git for AIX. However, my
prior attempt (version 2.18) - I never got around to finishing and today
with version 2.23.0 - I am unsure how to proceed without a lot of hacking.
Just some comments - long long way from calling anything a bug - just
not as portable as I would have hoped.
The simple issues:
1. The "Makefile" is surprising. I expect to run ./configure (or better,
out-of tree, e.g., ../src/git-2.23.0/configure). Just running OOT
configure does not result in a "Makefile". So, copy source tree to dest
and try again.
2. Makefile assumes gmake. Standard make does not support :: syntax
(fix: install cmake)
3. The default CFLAGS contains -Wall. Not all compilers support -Wall.
"Fixed" by adding CFLAGS="-g -O2". I am also undecided on having -g as a
default flag.
4. Must have gettext installed, which needs GNU libiconv - sad to have
these libraries as additional dependencies. e.g., bash 4.4 finally
removed the gettext and iconv gnu dependencies. -- FYI!
5. Another "gcc"? dependency: "git-compat-util.h", line 361.1: 1506-277
(S) Syntax error: possible missing ';'
FIX: add 'CC=xlc_r' to get language extensions
6. Needs curl (libcurl and curl.h), but does not check until much later:
FIX install curl; FIX2 add -I flag to find $prefix/include to CFLAGS
(.e.g., CFLAGS="-g -O2 -I/opt/include") - FYI GNU autotools also fail to
include $prefix/include
7. More stuck here. libssh2 is built by curl, but as a static library. I
could "hack" the libssh2.o file into the linkage, but unclear how well
that will work. Also wonder if libssh2 is "required" or optional. For
curl it has been optional (and I think it still is).
Current status:
xlc_r -g -O2 -I/opt/include -I. -D_LARGE_FILES
-DGIT_HOST_CPU="\"00C291F54C00\"" -DUSE_CURL_FOR_IMAP_SEND -DNO_NSEC
-DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES
-DSHA1DC_INIT_SAFE_HASH_DEFAULT=0
-DSHA1DC_CUSTOM_INCLUDE_SHA1_C="\"cache.h\""
-DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C="\"git-compat-util.h\""
-DSHA256_BLK -DFREAD_READS_DIRECTORIES -DNO_STRCASESTR -DNO_STRLCPY
-DNO_MKDTEMP -DNO_MEMMEM -DINTERNAL_QSORT -Icompat/regex
-DFILENO_IS_A_MACRO -DNEED_ACCESS_ROOT_HANDLER -DDEFAULT_PAGER='"more"'
-DSHELL_PATH='"/bin/sh"' -DPAGER_ENV='"LESS=FRX LV=-c"' -o
git-imap-send imap-send.o http.o common-main.o \
-L/opt/lib -lcurl -lssh2 -lssh2 -lssl -lcrypto -lldap -llber
-lssl -lcrypto -lz -lssl -lcrypto libgit.a xdiff/lib.a -lz -liconv
-lintl -lpthread
ld: 0706-006 Cannot find or open library file: -l ssh2
ld:open(): A file or directory in the path name does not exist.
ld: 0706-006 Cannot find or open library file: -l ssh2
ld:open(): A file or directory in the path name does not exist.
ld: 0706-006 Cannot find or open library file: -l ldap
ld:open(): A file or directory in the path name does not exist.
ld: 0706-006 Cannot find or open library file: -l lber
ld:open(): A file or directory in the path name does not exist.
This will need, at the least an additional LDFLAGS added to the make
command ('LDFLAGS="-L/opt/lib"'), but I still have to find where the
-lssh2 is generated.
Not sure - if I can help - but do hope this already helps in a (small) way.
Regards,
Michael
^ permalink raw reply [relevance 5%]
* Re: [PATCH] sha1dc: update from upstream
@ 2018-08-02 21:29 7% ` Michael Felt (aixtools)
0 siblings, 0 replies; 15+ results
From: Michael Felt (aixtools) @ 2018-08-02 21:29 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, brian m . carlson, Dan Shumow, Jeff King
Sent from my iPhone
> On 2 Aug 2018, at 22:50, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
> Update sha1dc from the latest version by the upstream
> maintainer[1]. See 2db87328ef ("Merge branch 'ab/sha1dc'", 2017-07-10)
> for the last update.
>
> This fixes an issue where AIX was wrongly detected as a Little-endian
> instead of a Big-endian system. See [2][3][4].
>
> 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/232357eb2ea0397388254a4b188333a227bf5b10
> 2. https://github.com/cr-marcstevens/sha1collisiondetection/pull/45
> 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/42
> 4. https://public-inbox.org/git/20180729200623.GF945730@genre.crustytoothpaste.net/
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>
>> On Wed, Aug 01 2018, Ævar Arnfjörð Bjarmason wrote:
>> https://github.com/cr-marcstevens/sha1collisiondetection/pull/45
>> [...]
>> It should work, but as noted in the MR please test it so we can make
>> sure, and then (if you have a GitHub account) comment on the MR saying
>> it works for you.
>
> This got merged upstream, and as noted in that upstream PR I've
> personally tested this on AIX under both GCC and IBM's xlc on the GCC
> compile farm, it works.
>
Thanks. I already have git 2.18 in use with the manual patch.
> sha1collisiondetection | 2 +-
> sha1dc/sha1.c | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/sha1collisiondetection b/sha1collisiondetection
> index 19d97bf5af..232357eb2e 160000
> --- a/sha1collisiondetection
> +++ b/sha1collisiondetection
> @@ -1 +1 @@
> -Subproject commit 19d97bf5af05312267c2e874ee6bcf584d9e9681
> +Subproject commit 232357eb2ea0397388254a4b188333a227bf5b10
> diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
> index 25eded1399..df0630bc6d 100644
> --- a/sha1dc/sha1.c
> +++ b/sha1dc/sha1.c
> @@ -93,13 +93,23 @@
> #define SHA1DC_BIGENDIAN
>
> /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */
> +#elif (defined(_AIX))
> +
> +/*
> + * Defines Big Endian on a whitelist of OSs that are known to be Big
> + * Endian-only. See
> + * https://public-inbox.org/git/93056823-2740-d072-1ebd-46b440b33d7e@felt.demon.nl/
> + */
> +#define SHA1DC_BIGENDIAN
> +
> +/* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> */
> #elif defined(SHA1DC_ON_INTEL_LIKE_PROCESSOR)
> /*
> * As a last resort before we do anything else we're not 100% sure
> * about below, we blacklist specific processors here. We could add
> * more, see e.g. https://wiki.debian.org/ArchitectureSpecificsMemo
> */
> -#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <processor blacklist> */
> +#else /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> or <os whitelist> or <processor blacklist> */
>
> /* We do nothing more here for now */
> /*#error "Uncomment this to see if you fall through all the detection"*/
> --
> 2.18.0.345.g5c9ce644c3
>
^ permalink raw reply [relevance 7%]
* Re: Is detecting endianness at compile-time unworkable?
@ 2018-07-31 20:06 5% ` Michael
0 siblings, 0 replies; 15+ results
From: Michael @ 2018-07-31 20:06 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King
On 31/07/2018 16:25, Ævar Arnfjörð Bjarmason wrote:
> ...the real trick is using these macros outside of GCC / glibc and on
> older GCC versions. See the github link above, you basically end up with
> a whitelist of how it looks on different systems / compilers. Sometimes
> both are defined, sometimes only both etc.
>
> It can be done, but as that code shows it's somewhat complex macro soup
> to get right.
FYI - the gcc I was using is 4.7.4.
And, the reason I suggest the test for both not being defined is so that
'make' stops and whoever is running make just sets one or the other. Let
them 'file a bug' When they come with a compiler that does not work -
and find out what could be used.
For example, _AIX is the same as _BIG_ENDIAN. In the meantime, the code
to test is simple.
Either one of _BIG_ENDIAN or _LITTLE_ENDIAN is provided by the compiler
or the builder supplies one of the two using CFLAGS. I assume there is
also a "undefine" flag, maybe -U - so hopefully a -U and a -D
combination could be used for cross-compiling.
re: my mailer blocking things - it would only be for this list, as other
lists come through with no extra work from me. At least I am not aware
of anything special I could do.
^ permalink raw reply [relevance 5%]
* Re: Is detecting endianness at compile-time unworkable?
` (2 preceding siblings ...)
2018-07-31 12:32 6% ` Michael Felt
@ 2018-07-31 14:01 5% ` Michael Felt
3 siblings, 1 reply; 15+ results
From: Michael Felt @ 2018-07-31 14:01 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King
I hope a I have a "leap forward"
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> Perhaps it's worth taking a step back here and thinking about whether
> this whole thing is unworkable. It was hard enough to get this to work
> on the combination of Linux, *BSD and Solaris, but I suspect we'll run
> into increasingly obscure platforms where this is hard or impossible
> (AIX, HP/UX etc.)
While I still cannot say for HP/UX it does seem there is a potential
solution based on the status for _LITTLE_ENDIAN and _BIG_ENDIAN. At
least, gcc on POWER and xlc on POWER provides one or the other - and my
hope is that gcc on other platforms also provides them.
For "other" compilers that do not provide them - a modification to
CFLAGS to define one or the other should make "make" work.
Details (note - I am not a programmer, so by definition at least one of
my "macros" will be wrong :)
AIX and xlc
root@x066:[/]xlc -qshowmacros -E /dev/null | grep -i endi
1506-297 (S) Unable to open input file null. A file or directory in the
path name does not exist..
#define __HHW_BIG_ENDIAN__ 1
#define __BIG_ENDIAN__ 1
#define __THW_BIG_ENDIAN__ 1
#define _BIG_ENDIAN 1
On SLES12 (le) and xlc
suse12test:~/images/littleEndian/sles # xlc -qshowmacros -dM -E x.c |
grep -i endi
#define _LITTLE_ENDIAN 1
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412
#define __VEC_ELEMENT_REG_ORDER__ __ORDER_LITTLE_ENDIAN__
Based on what I can see on gcc on POWER and xlc on POWER I think an
approach (simplified) can be:
#if undefined(_BIG_ENDIAN) && undef(_LITTLE_ENDIAN)
#error "one of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined. Try adding
the correct value to CFLAGS"
#else defined(_BIG_ENDIAN) && defined(_LITTLE_ENDIAN)
#error "Only one of _BIG_ENDIAN and _LITTLE_ENDIAN may be defined, not both"
#endif
And then logic based on the value set.
This should also make cross-compile possible by unsetting an incorrect
default and setting the correct value.
p.s. Is there a setting I need to set somewhere so I receive a copy of
the email sent after it is received by the list. I could send myself a
copy, but I much prefer it comes from the maillist - as verification it
was received.
^ permalink raw reply [relevance 5%]
* Re: Is detecting endianness at compile-time unworkable?
2018-07-31 10:39 5% ` Michael Felt
@ 2018-07-31 12:32 6% ` Michael Felt
2018-07-31 14:01 5% ` Michael Felt
3 siblings, 0 replies; 15+ results
From: Michael Felt @ 2018-07-31 12:32 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King
[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> The reason we're in this hole is because we use this
> sha1collisiondetection library to do SHA-1, and the reason we have
> issues with it specifically (not OpenSSL et al) is because its only
> method of detecting endianness is at compile time.
When using gcc (no xlc available for Linux on Power)
POWER6 (Big Endian by definition)
root@x068:[/data/httpd/gcc]gcc -dM -E - < /dev/null | grep -i end
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __BIG_ENDIAN__ 1
#define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define _BIG_ENDIAN 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
SLES12 on POWER8
suse12test:~ # gcc -dM -E - < /dev/null | grep -i end
#define __ORDER_LITTLE_ENDIAN__ 1234
#define _LITTLE_ENDIAN 1
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
*So, for compile time tests, when gcc is the compiler it seems the
following defines are available**
**__BIG_ENDIAN__, _BIG_ENDIAN, __LITTLE__ENDIAN__, _LITTLE_ENDIAN**
**or something based on the value of __BYTE_ORDER__*
I'll see if I can find something similar for xlc, but will only be able
to test xlc on AIX.
>
> This didn't use to be the case, it was changed in this commit:
> https://github.com/cr-marcstevens/sha1collisiondetection/commit/d597672
>
> Dan Shumow: Since the commit message doesn't say why, can you elaborate
> a bit on why this was done, i.e. is determining this at runtime harmful
> for performance? If not, perhaps it would be best to bring this back, at
> least as an option.
[-- Attachment #2: Type: text/html, Size: 2629 bytes --]
^ permalink raw reply [relevance 6%]
* Re: Is detecting endianness at compile-time unworkable?
@ 2018-07-31 10:39 5% ` Michael Felt
2018-07-31 12:32 6% ` Michael Felt
2018-07-31 14:01 5% ` Michael Felt
3 siblings, 0 replies; 15+ results
From: Michael Felt @ 2018-07-31 10:39 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: brian m. carlson, git, Dan Shumow, Junio C Hamano, Jeff King
A small step back...
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Jul 29 2018, Michael wrote:
>
>> On 29/07/2018 22:06, brian m. carlson wrote:
>>> On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
>>>> On 29/07/2018 21:27, brian m. carlson wrote:
>>>>> Well, that explains it. I would recommend submitting a patch to
>>>>> https://github.com/cr-marcstevens/sha1collisiondetection, and the we can
>>>>> pull in the updated submodule with that fix.
>>>> Not sure I am smart enough to do that. I'll have to download, build, and see
>>>> what it says.
>>> The issue is that somewhere in lib/sha1.c, you need to cause
>>> SHA1DC_BIGENDIAN to be set. That means you need to figure out what
>>> compiler macro might indicate that.
>> I remember - roughly - a few decades back - having an assignment to
>> write code to determine endianness. PDP and VAC were different iirc,
>> and many other micro-processors besides the 8088/8086/z85/68k/etc..
>>
>> If you are looking for a compiler macro as a way to determine this -
>> maybe you have one for gcc, but not for xlc. I do not know it - currently :)
> I'm not familiar with AIX, but from searching around I found this
> porting manual from IBM:
> http://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf
This is from July 2001 - when AIX 5L, for Linux affinity, was new. AIX
was (nearly) the #1 posix system, and linux was a minor player in the
data center (in or out (now as IAAS)). IMHO, the recommendations made in
2001 are probably no longer applicable (64-bit was fairly new, e.g.,
rather than common).
>
> There they suggest either defining your own macros, or testing the
> memory layout at runtime (see section "2.2.2.3 Technique 3: Testing
> memory layout" and surrounding sections).
>
> Perhaps it's worth taking a step back here and thinking about whether
> this whole thing is unworkable. It was hard enough to get this to work
> on the combination of Linux, *BSD and Solaris, but I suspect we'll run
> into increasingly obscure platforms where this is hard or impossible
> (AIX, HP/UX etc.)
>
> The reason we're in this hole is because we use this
> sha1collisiondetection library to do SHA-1, and the reason we have
> issues with it specifically (not OpenSSL et al) is because its only
> method of detecting endianness is at compile time.
Cannot speak for the "others", but as I have mentioned before - as AIX
in only on POWER it is also only Big Endian - so a compiletime #if
testing for _AIX will work fine
> This didn't use to be the case, it was changed in this commit:
> https://github.com/cr-marcstevens/sha1collisiondetection/commit/d597672
>
> Dan Shumow: Since the commit message doesn't say why, can you elaborate
> a bit on why this was done, i.e. is determining this at runtime harmful
> for performance? If not, perhaps it would be best to bring this back, at
> least as an option.
>
> And, as an aside, the reason we can't easily make it better ourselves is
> because the build process for git.git doesn't have a facility to run
> code to detect this type of stuff (the configure script is always
> optional). So we can't just run this test ourselves.
On AIX - I am required to run configure, and frankly, I am amazed that
not everyone is running it. Among other things I an modifying the prefix
(to /opt) and many of the others to different /var/git/* areas as I do
not want to "polute" the BOS (base OS) and/or other packages/packagers.
Officially, according the Linux FHS-3.0 I sould be using /opt/aixtools
as prefix.
FYI: my current build process is:
wget git-{version}.tar.xz
xz -dc git-{version}.tar.xz
cd git-{version}.tar.xz
mv Makefile Makefile.git #my build scripts only run configure when
Makefile does not exist
./configure ...
ln Makefile.git Makefile
make
I am amazed, as it rarely happens (maybe git is my first encounter) -
that configure does not create a Makefile. This also complicates
building git "out of tree".
>
> Junio: I've barked up that particular tree before in
> https://public-inbox.org/git/87a7x3kmh5.fsf@evledraar.gmail.com/ and I
> won't bore you all by repeating myself, except to say that this is yet
> another case where I wish we had a hard dependency on some way of doing
> checks via compiled code in our build system.
For AIX: again - the determination is simple. If _AIX is set to 1 then
use BigEndian, or, use:
michael@x071:[/home/michael]uname
AIX
i.e., something like:
$(uname) == "AIX" && BigEndian=1
^ permalink raw reply [relevance 5%]
* Re: Is detecting endianness at compile-time unworkable?
@ 2018-07-31 10:06 5% ` Michael Felt
0 siblings, 0 replies; 15+ results
From: Michael Felt @ 2018-07-31 10:06 UTC (permalink / raw)
To: Daniel Shumow, Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, brian m. carlson, git,
Jeff King
[-- Attachment #1: Type: text/plain, Size: 3396 bytes --]
I have just replied to
https://github.com/cr-marcstevens/sha1collisiondetection/pull/42
I checked a gcc compiler on AIX, and I have the defines for vac.
I do not have access yet to SLES or RHEL (or Ubuntu), just a "free
Debian" on my Power6.
* my conclusions|recommendations:
a) AIX is always Big Endian, the define _AIX can be used to determine if AIX
b) POWER7 and earlier are always Big Endian
c) assuming lscpu is always available on Linux systems a command (in
configure?) could be used:
root@x074:/usr/bin# lscpu | grep -i endian
Byte Order: Big Endian
d) some linux systems (in any case latest versions of RHEL and SLES
enterprise) should have a file named lparcfg in /proc
(/proc/{powerppc|ppc64|ppc64le|ppc64el}/lparcfg - and it might be in
that file. Need to get onto a (POWER8|POWER9) system to check.
Hope this helps:
details re: define of _AIX
root@x068:[/data/httpd/gcc]gcc -dM -E - < /dev/null | grep AIX | head -1
#define _AIX 1
michael@x071:[/home/michael]/usr/bin/grep -p DEFLT:
/etc/vac.cfg.[567][123] | grep options\
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_IBMR2,-D_POWER
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_IBMR2,-D_POWER
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_AIX71,-D_IBMR2,-D_POWER
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_AIX71,-D_AIX72,-D_IBMR2,-D_POWER
michael@x071:[/home/michael]ls /etc/vac.cfg.[567][123]
/etc/vac.cfg.53 /etc/vac.cfg.61 /etc/vac.cfg.71 /etc/vac.cfg.72
On 7/30/2018 8:39 PM, Daniel Shumow wrote:
> The change was definitely made for performance. Removing the if
> statements, conditioned upon endianess was an approx 10% improvement,
> which was very important to getting this library accepted into git.
>
> Thanks,
> Dan
>
>
> On Mon, Jul 30, 2018 at 11:32 AM, Junio C Hamano <gitster@pobox.com
> <mailto:gitster@pobox.com>> wrote:
>
> Junio C Hamano <gitster@pobox.com <mailto:gitster@pobox.com>> writes:
>
> > Ævar Arnfjörð Bjarmason <avarab@gmail.com
> <mailto:avarab@gmail.com>> writes:
> >
> >> And, as an aside, the reason we can't easily make it better
> ourselves is
> >> because the build process for git.git doesn't have a facility
> to run
> >> code to detect this type of stuff (the configure script is always
> >> optional). So we can't just run this test ourselves.
> >
> > It won't help those who cross-compile anyway. I thought we declared
> > "we make a reasonable effort to guess the target endianness from the
> > system header by inspecting usual macros, but will not aim to cover
> > every system on the planet---instead there is a knob to tweak it for
> > those on exotic platforms" last time we discussed this?
>
> Well, having said all that, I do not think I personally mind if
> ./configure learned to include a "compile small program and run it
> to determine byte order on the build machine" as part of "we make a
> reasonable effort" as long as it cleanly excludes cross building
> case (and the result is made overridable just in case we misdetect
> the "cross-ness" of the build).
>
>
[-- Attachment #2: Type: text/html, Size: 5514 bytes --]
^ permalink raw reply [relevance 5%]
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3
@ 2018-07-30 6:22 4% ` Michael
0 siblings, 0 replies; 15+ results
From: Michael @ 2018-07-30 6:22 UTC (permalink / raw)
To: Andreas Schwab, Ævar Arnfjörð Bjarmason
Cc: brian m. carlson, git
On 29/07/2018 23:40, Andreas Schwab wrote:
> On Jul 29 2018, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>> Also, to you and anyone else with access to AIX: I'd be happy to figure
>> these issues out pro-actively if you give me a login to an AIX
>> machine. I promise not to do anything except compile/debug/test git on
>> it.
> The GCC compile farm <http://gcc.gnu.org/wiki/CompileFarm> has a machine
> running AIX, and is free to use for anyone working on free software.
My goal is less "to work on", more, "to package" and/or "to work with".
Most others, including IBM, seem to use gcc as compiler - which is fine.
However, on AIX I often see side-effects introduced by the GNU run-time
environment needed on top of the xlc.rte provided as part of AIX.
In any case - my testing is using the xlc complier - so there are syntax
differences. the compiler has many modes - by default I use 'xlc_r' that
has the following default settings:
xlc_r: use = DEFLT_C
crt = /lib/crt0.o
mcrt = /lib/mcrt0.o
gcrt = /lib/gcrt0.o
libraries = -L/usr/vac/lib,-lxlopt,-lxlipa,-lxl,-lpthreads,-lc
proflibs = -L/lib/profiled,-L/usr/lib/profiled
hdlibs = -L/usr/vac/lib,-lhmd
options =
-qlanglvl=extc99,-qcpluscmt,-qkeyword=inline,-qalias=ansi,-qthreaded,-D_THREAD_SAFE,-D__VACPP_MULTI__
DEFLT_C (for the curious, the default options is perhaps most
interesting) is:
* common definitions
DEFLT_C:
use =DEFLT
xlurt_cfg_path=/usr/vac/urt
xlurt_cfg_name=urt_client.cfg
DEFLT_CPP:
use =DEFLT
xlurt_cfg_path=/usr/vacpp/urt
xlurt_cfg_name=urt_client.cfg
DEFLT:
cppcomp = /usr/vacpp/exe/xlCentry
ccomp = /usr/vac/exe/xlcentry
code = /usr/vac/exe/xlCcode
cpp = /usr/vac/exe/xlCcpp
munch = /usr/vacpp/exe/munch
dis = /usr/vac/exe/dis
xlC = /usr/vac/bin/xlc
list = /usr/vac/exe/xllist
xslt = /usr/vac/exe/XALAN
transforms = /usr/vac/listings
listlibs = /usr/vac/lib
cppinc = /usr/vacpp/include
ipa = /usr/vac/exe/ipa
cppfilt = /usr/vacpp/bin/c++filt
bolt = /usr/vac/exe/bolt
as = /bin/as
ld = /bin/ld
artool = /bin/ar
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_IBMR2,-D_POWER
options32 = -bpT:0x10000000,-bpD:0x20000000
options32_bmaxdata = -bpT:0x10000000,-bpD:0x30000000
options64 = -bpT:0x100000000,-bpD:0x110000000
ldopt = "b:o:e:u:R:H:Y:Z:L:T:A:k:j:"
hdlibs = -L/usr/vac/lib,-lhmd
xlCcopt =
-qlanglvl=extc99,-qcpluscmt,-qkeyword=inline,-qalias=ansi
crt_64 = /lib/crt0_64.o
mcrt_64 = /lib/mcrt0_64.o
gcrt_64 = /lib/gcrt0_64.o
smplibraries = -lxlsmp
palibraries = -L/usr/vatools/lib,-lpahooks
resexp = /usr/vacpp/lib/res.exp
genexports = /usr/vac/bin/CreateExportList
vac_path = /usr/vac
vacpp_path = /usr/vacpp
xlcmp_path = /usr/vac:/usr/vacpp
xlc_c_stdinc = /usr/vac/include:/usr/include
xlc_cpp_stdinc = /usr/vacpp/include:/usr/include
xlurt_msg_cat_name=vacumsg.cat
__GNUC_MINOR__ = 3
>
> Andreas.
>
^ permalink raw reply [relevance 4%]
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3
@ 2018-07-29 20:50 5% ` Michael
0 siblings, 1 reply; 15+ results
From: Michael @ 2018-07-29 20:50 UTC (permalink / raw)
To: brian m. carlson, git
On 29/07/2018 22:06, brian m. carlson wrote:
> On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
>> On 29/07/2018 21:27, brian m. carlson wrote:
>>> Well, that explains it. I would recommend submitting a patch to
>>> https://github.com/cr-marcstevens/sha1collisiondetection, and the we can
>>> pull in the updated submodule with that fix.
>> Not sure I am smart enough to do that. I'll have to download, build, and see
>> what it says.
> The issue is that somewhere in lib/sha1.c, you need to cause
> SHA1DC_BIGENDIAN to be set. That means you need to figure out what
> compiler macro might indicate that.
I remember - roughly - a few decades back - having an assignment to
write code to determine endianness. PDP and VAC were different iirc, and
many other micro-processors besides the 8088/8086/z85/68k/etc..
If you are looking for a compiler macro as a way to determine this -
maybe you have one for gcc, but not for xlc. I do not know it - currently :)
> I can tell you that a POWER- or
> PowerPC-specific one is going to be a bad choice unless it includes the
> endianness, since those chips come in little-endian versions as well.
Actually, the POWER8 and POWER9 (and I expect all future versions)
support both. There are not separate chips. Per virtual machine - a mode
is determined during boot (virtual power on) e.g., SLES11 only ran in
BigEndian and SLES12 only runs in LittleEndian. afaik, RHEL was
supplying both BE and LE distributions. AIX, as an OS, only runs in BE
mode, and I expect IBM i (was os/400) is also only running in BE.
>
> _AIX might be a fine choice if you know that it only ever runs on
> big-endian chips.
Do you mean just testing for _AIX. That would be very very easy - yes!
>>> In the mean time, you could build using OpenSSL or the block SHA-1
>>> implementation, and switch back once things are in a good state. I do
>>> recommend using SHA1DC for things long term, though, as attacks on SHA-1
>>> are only going to get better.
>> Any suggestions on where/how to do this?
>>
>> root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep -i
>> sha
>> --sharedstatedir=DIR modifiable architecture-independent data
>> [PREFIX/com]
>> --datarootdir=DIR read-only arch.-independent data root
>> [PREFIX/share]
>>
>> root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep ssl
>> --with-openssl use OpenSSL library (default is YES)
>> ARG can be prefix for openssl library and headers
> If you're using configure, you can use --with-openssl, or
> --with-openssl=PREFIX if your OpenSSL isn't in the standard location but
> is instead in PREFIX.
I'll look in configure to see if it is not finding openssl. I was
assuming it was found - as everything else using GNU "auto" tools find
it okay. i.e., /var/lib/libssl.a, etc..
Tomorrow!
^ permalink raw reply [relevance 5%]
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3
[not found] ` <20180729192753.GD945730@genre.crustytoothpaste.net>
@ 2018-07-29 19:48 6% ` Michael
0 siblings, 1 reply; 15+ results
From: Michael @ 2018-07-29 19:48 UTC (permalink / raw)
To: brian m. carlson; +Cc: git
On 29/07/2018 21:27, brian m. carlson wrote:
> On Sun, Jul 29, 2018 at 08:59:39PM +0200, Michael wrote:
>> On 29/07/2018 20:10, brian m. carlson wrote:
>>> Are you using SHA1DC on that system, and does compiling with another
>>> SHA-1 implementation help? There was a change to the SHA1DC code big
>>> endian detection in that commit, which might be the cause of your
>>> problems if you're using a POWER or PowerPC system.
>> I was thinking it might be an 'endian' issue. So, yes - AIX runs on POWER,
>> only as BigEndian.
> Well, that explains it. I would recommend submitting a patch to
> https://github.com/cr-marcstevens/sha1collisiondetection, and the we can
> pull in the updated submodule with that fix.
Not sure I am smart enough to do that. I'll have to download, build, and
see what it says.
>
> In the mean time, you could build using OpenSSL or the block SHA-1
> implementation, and switch back once things are in a good state. I do
> recommend using SHA1DC for things long term, though, as attacks on SHA-1
> are only going to get better.
Any suggestions on where/how to do this?
root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep
-i sha
--sharedstatedir=DIR modifiable architecture-independent data
[PREFIX/com]
--datarootdir=DIR read-only arch.-independent data root
[PREFIX/share]
root@x066:[/data/prj/aixtools/git/git-2.13.2]./configure --help | grep ssl
--with-openssl use OpenSSL library (default is YES)
ARG can be prefix for openssl library and
headers
^ permalink raw reply [relevance 6%]
* Re: git broken for AIX somewhere between 2.13.2 and 2.13.3
@ 2018-07-29 19:46 5% ` Michael
[not found] ` <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl>
1 sibling, 1 reply; 15+ results
From: Michael @ 2018-07-29 19:46 UTC (permalink / raw)
To: brian m. carlson, git
[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]
On 29/07/2018 20:10, brian m. carlson wrote:
> On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote:
>> root@x066:[/tmp/xxx]git --version
>> git version 2.13.3
>> root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git
>> Cloning into 'hello-world'...
>> remote: Counting objects: 3, done.
>> remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
>> Receiving objects: 100% (3/3), done.
>> fatal: pack is corrupted (SHA1 mismatch)
>> fatal: index-pack failed
>>
>> p.s. - what surprises me re: git-2.13.2 - no messages about 'Cloning into
>> ...', which version 2.13.1 did give.
>>
>> I guess a bisect is the next step - between version 2.13.2 and 2.13.3. Other
>> suggestions welcome!
> Are you using SHA1DC on that system, and does compiling with another
> SHA-1 implementation help? There was a change to the SHA1DC code big
> endian detection in that commit, which might be the cause of your
> problems if you're using a POWER or PowerPC system.
I was thinking it might be an 'endian' issue. So, yes - AIX runs on
POWER, only as BigEndian.
git bisect returns:
michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect bad
Bisecting: 1 revision left to test after this (roughly 1 step)
[35049a2343948f686861e176a8c395f9f67da7b6] Merge branch
'aw/contrib-subtree-doc-asciidoctor' into maint
michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[9936c1b52a39fa14fca04f937df3e75f7498ac66] sha1dc: update from upstream
michael@x071:[/data/prj/aixtools/git/github/git-master]git bisect bad
9936c1b52a39fa14fca04f937df3e75f7498ac66 is the first bad commit
commit 9936c1b52a39fa14fca04f937df3e75f7498ac66
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sat Jul 1 22:05:45 2017 +0000
sha1dc: update from upstream
Update sha1dc from the latest version by the upstream maintainer[1].
See commit 6b851e536b ("sha1dc: update from upstream", 2017-06-06) for
the last update.
This solves the Big Endian detection on Solaris reported against
v2.13.2[2], hopefully without any regressions. A version of this has
been tested on two Solaris SPARC installations, Cygwin (by jturney on
cygwin@Freenode), and on numerous more boring systems (mainly
linux/x86_64). See [3] for a discussion of the implementation and
platform-specific issues.
See commit a0103914c2 ("sha1dc: update from upstream", 2017-05-20) and
6b851e536b ("sha1dc: update from upstream", 2017-06-06) for previous
attempts in the 2.13 series to address various compile-time feature
detection in this library.
1.
https://github.com/cr-marcstevens/sha1collisiondetection/commit/19d97bf5af05312267c2e874ee6bcf584d9e9681
2.
<CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com>
(https://public-inbox.org/git/CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com/)
3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/34
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:040000 040000 a84797967fb742e4ca9618a641d53ce3a6c6589b
32efa656d78901da961e4a47d84b6d82fede064b M sha1dc
[-- Attachment #2: Type: text/html, Size: 5402 bytes --]
^ permalink raw reply [relevance 5%]
* git broken for AIX somewhere between 2.13.2 and 2.13.3
@ 2018-07-29 16:44 5% Michael
0 siblings, 1 reply; 15+ results
From: Michael @ 2018-07-29 16:44 UTC (permalink / raw)
To: git
Hi,
Several years ago I had downloaded and packaged git-2.10.1 with no real
issues, and it has been working fine. Deciding it was time for an update
I downloaded git-2.18.0 and built from scratch.
After testing lots of version - the the last 2.12 version worked;
git-2.13.2 works but git-2.13.3 does not.
root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git
root@x066:[/tmp/xxx]git --version
git version 2.13.2
root@x066:[/tmp/xxx]ls -l
total 0
drwxr-xr-x 3 root system 256 Jul 29 16:37 hello-world
root@x066:[/tmp/xxx]git --version
git version 2.13.3
root@x066:[/tmp/xxx]git clone git@github.com:aixtools/hello-world.git
Cloning into 'hello-world'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.
fatal: pack is corrupted (SHA1 mismatch)
fatal: index-pack failed
p.s. - what surprises me re: git-2.13.2 - no messages about 'Cloning
into ...', which version 2.13.1 did give.
I guess a bisect is the next step - between version 2.13.2 and 2.13.3.
Other suggestions welcome!
Michael
^ permalink raw reply [relevance 5%]
Results 1-15 of 15 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2018-07-29 16:44 5% git broken for AIX somewhere between 2.13.2 and 2.13.3 Michael
2018-07-29 18:10 ` brian m. carlson
2018-07-29 19:46 5% ` Michael
2018-07-29 20:05 ` Ævar Arnfjörð Bjarmason
2018-07-29 21:40 ` Andreas Schwab
2018-07-30 6:22 4% ` Michael
[not found] ` <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl>
[not found] ` <20180729192753.GD945730@genre.crustytoothpaste.net>
2018-07-29 19:48 6% ` Michael
2018-07-29 20:06 ` brian m. carlson
2018-07-29 20:50 5% ` Michael
2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason
2018-07-30 14:54 ` Junio C Hamano
2018-07-30 18:32 ` Junio C Hamano
2018-07-30 18:39 ` Daniel Shumow
2018-07-31 10:06 5% ` Michael Felt
2018-07-31 10:39 5% ` Michael Felt
2018-07-31 12:32 6% ` Michael Felt
2018-07-31 14:01 5% ` Michael Felt
2018-07-31 14:25 ` Ævar Arnfjörð Bjarmason
2018-07-31 20:06 5% ` Michael
2018-08-01 7:31 Ævar Arnfjörð Bjarmason
2018-08-02 20:50 ` [PATCH] sha1dc: update from upstream Ævar Arnfjörð Bjarmason
2018-08-02 21:29 7% ` Michael Felt (aixtools)
2019-10-28 14:00 5% COMMENTS: building git on AIX Michael Felt
2020-05-04 17:20 Rename offensive terminology (master) Simon Pieters
2020-06-14 15:20 4% ` Sérgio Augusto Vianna
2020-06-14 14:59 Thomas Adam
2020-06-14 15:13 7% ` Michael Felt (aixtools)
2020-06-14 15:09 5% Michael Felt (aixtools)
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).