bugManeage - Bugs: bug #58248, Git depends on Gettext (which is...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58248: Git depends on Gettext (which is not yet in Maneage)

Submitter:  Boud Roukema <boud>
Submitted:  Sun 26 Apr 2020 03:39:06 PM UTC
   
 
Category:  Software Severity:  3 - Normal
Item Group:  Crash Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Jump to the original submission

Fri 08 May 2020 04:12:57 PM UTC, comment #26: 

Thanks a lot Mohammad, I am also happy to be able to fix little by little all of this bugs ;-)

Raul Infante-Sainz <infantesainz>
Group Member
Fri 08 May 2020 04:01:12 PM UTC, comment #25: 

I checked it on a clean build and it worked beautifully, so it is now merged into Maneage as a single commit (I "rebased" and "squashed" the branch into one commit to avoid confusing the Maneage users with all the minor commits). I am really happy we finally fixed the Gettext problem and all the other problems with core libraries, so this bug is now closed :-D.

Thanks a lot Raul and Boud for all the help in recognizing this problem and fixing it, Maneage is now much more stable for all our projects.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 08 May 2020 11:18:56 AM UTC, comment #24: 

Thanks a lot Mohammad. In a first attempt it didn't work, but then I noticed this option was set to be the lib directory. So, I changed it to `yes' and it worked!! I also hope you test will pass successfully so we can close this issue :-)
Have a look here: https://gitlab.com/infantesainz/reproduce-raulfork/-/commit/e12d7bab1d4fca

Raul Infante-Sainz <infantesainz>
Group Member
Thu 07 May 2020 08:44:28 PM UTC, comment #23: 

That was great Raul, thanks!

The word "curses" is not used in any of them beyond what we called! I am really puzzled by how your system's libncurses gets into the Bash executable, its not explicitly linked anywhere!

So I had a look in the source of Bash's `configure' script and I have a guess that may solve the problem:

In the build-rule of Bash, (where we call `gbuild') can you add `--with-curses=yes', just before `$$stopt'. Then try re-building Bash and checking its linked libraries. If it works, please commit it over that branch so I also try it and hopefully close the bug.

Just one tiny tip: to avoid taking extra space on Savannah for archiving text files, you can run `gzip output.txt' to compress them to `.txt.gz' and upload that. This will greatly reduce their size and help Savannah maintainers in terms of required space ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 07 May 2020 09:49:53 AM UTC, comment #22: 

Starting from the end. Here you are the components of `libncurses' that have been installed:


$ ls -l .local/lib/libncurses*

.local/lib/libncurses++.dylib -> libncurses++w.6.dylib
.local/lib/libncurses++w.6.dylib
.local/lib/libncurses++w.dylib -> libncurses++w.6.dylib
.local/lib/libncurses.dylib -> libncursesw.6.dylib
.local/lib/libncursesw.6.dylib
.local/lib/libncursesw.dylib -> libncursesw.6.dylib



Then, attached are the three files:
 `bash-output.log': Standard output when installing Bash
 `config.log': Log file generated in the configure step
 `Makefile': Makefile generated just after configure

I tried to replace the directories by shortcuts ;-)


(file #49018, file #49019, file #49020)

Raul Infante-Sainz <infantesainz>
Group Member
Wed 06 May 2020 10:58:30 PM UTC, comment #21: 

Thanks a lot Raul, this is indeed very strange! We'll have to see what part of its build process its linking with your system's libncurses. Can you re-build Bash and upload the full build commands (from the configure phase to the part it finishes building Bash). Also the `config.log' file and `Makefile'.

I had a look in the source of Bash and found this line in `support/shobj-conf', but I am not sure how relevant it is in this case, we need to see the outputs above.


SHLIB_LIBS='-lncurses'        # see if -lcurses works on MacOS X 10.1


It would also be helpful to see what libncurses components are actually installed:


ls -l .local/lib/libncurses*


Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 06 May 2020 10:17:34 PM UTC, comment #20: 

Thanks Mohammad. Before the clean build, these are the libraries that readline links to:


$ otool -L .local/lib/libreadline.8.dylib
.local/lib/libreadline.8.dylib:
        BDIR/software/installed/lib/libreadline.8.dylib (compatibility version 8.0.0, current version 8.0.0)
        BDIR/software/installed/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)


And after a clean build:


$ otool -L .local/lib/libreadline.8.dylib
.local/lib/libreadline.8.dylib:
        BDIR/software/installed/lib/libreadline.8.dylib (compatibility version 8.0.0, current version 8.0.0)
        BDIR/software/installed/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)


Related with bash, it didn't work :S This is really strange, but as you can see, it is still linking with my host libncurse:


$ otool -L .local/bin/bash
.local/bin/bash:
        BDIR/software/installed/lib/libreadline.8.dylib (compatibility version 8.0.0, current version 8.0.0)
        BDIR/software/installed/lib/libhistory.8.dylib (compatibility version 8.0.0, current version 8.0.0)
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
        BDIR/software/installed/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0)
        BDIR/software/installed/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)


Raul Infante-Sainz <infantesainz>
Group Member
Wed 06 May 2020 05:51:37 PM UTC, comment #19: 

Thanks Raul, I just set libiconv as a dependency of Gettext, and also added the `--with-curses' option to Bash's build. You can see them in this commit.

The fact that your bash doesn't link with Maneage's ncurses is very strange! Because we actually build ncurses as a dependency of readline (which bash correctly links with). So before a clean build, can you also have a look at the libraries your readline links to:


otool -l .local/lib/libreadline.8.dylib


After the clean build, check bash again and let me know. For example below you can see that on my GNU/Linux, Bash actually links with `libncursesw'.


$ ldd .local/bin/bash
        linux-vdso.so.1 (0x00007ffd4ad1f000)
        libreadline.so.8 => BDIR/software/installed/lib/libreadline.so.8 (0x00007fe7a0c2a000)
        libhistory.so.8 => BDIR/software/installed/lib/libhistory.so.8 (0x00007fe7a0c1d000)
        libncursesw.so.6 => BDIR/software/installed/lib/libncursesw.so.6 (0x00007fe7a0bae000)
        libiconv.so.2 => BDIR/software/installed/lib/libiconv.so.2 (0x00007fe7a0ac8000)
        libdl.so.2 => BDIR/software/installed/lib/libdl.so.2 (0x00007fe7a0ac3000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fe7a08cb000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe7a0d94000)


Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 06 May 2020 08:46:01 AM UTC, comment #18: 

Thanks a lot Mohammad.
See by yourself that actually it depends on libiconv. And another catch: bash depends on ncurses!


$ otool -L .local/bin/gettext
.local/bin/gettext:
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1455.12.0)
        BDIR/software/installed/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)


$ otool -L .local/bin/bash
.local/bin/bash:
        BDIR/software/installed/lib/libreadline.8.dylib (compatibility version 8.0.0, current version 8.0.0)
        BDIR/software/installed/lib/libhistory.8.dylib (compatibility version 8.0.0, current version 8.0.0)
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
        BDIR/software/installed/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)


Raul Infante-Sainz <infantesainz>
Group Member
Wed 06 May 2020 08:36:48 AM UTC, comment #17: 

Perfect! Thanks ;-).

Fortunately we already have libiconv in `basic.mk', but before setting it as a prerequisite of Coreutils, can you also check if gettext itself depends on libiconv? Or maybe even Bash?

If we do this we do this the main prerequisite of pkg-config should be set to Make (see the comment in basic.mk on how libiconv and coreutils are related). pkg-config's Coreutils dependency was just for human reasons (to build all higher-level basic tools after coreutils) it has no special need on GNU coreutils.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 06 May 2020 08:18:00 AM UTC, comment #16: 

Wait! Now I also see it is pointing to my host `libiconv' (but before I didn't see it).
Maybe we should also include this library into Maneage, it seems to be not so difficult (https://www.gnu.org/software/libiconv/). What do you think?

Raul Infante-Sainz <infantesainz>
Group Member
Wed 06 May 2020 08:12:13 AM UTC, comment #15: 

I run it from scratch and it worked perfectly! `cp' is also pointing to our own Gettext. I think it is ready to be merged :-)


$ otool -L .local/bin/cp
.local/bin/cp:
        /path/to/builddir/software/installed/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1455.12.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)


Raul Infante-Sainz <infantesainz>
Group Member
Tue 05 May 2020 10:58:35 PM UTC, comment #14: 

That is interesting! So it only installs this library in macOS! I just pushed a change to the test branch where we install Gettext (and its dependencies) before Bash.

Since it involves some re-organizing of some basic tools, I done a clean build and it worked properly. Before the merge, can you please try one final clean build on macOS and see if it builds smoothly. It would also be interesting to check if `cp' now points to our installation of Gettext ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Tue 05 May 2020 06:53:57 PM UTC, comment #13: 

This is what I obtain:



$ find .local/  -name "libintl*"
.local//include/libintl.h
.local//lib/libintl.dylib
.local//lib/libintl.la
.local//lib/libintl.8.dylib
.local//lib/libintl.a
.local//share/awk/libintl.awk
.local//share/gettext/libintl.jar
.local//share/texinfo/lib/libintl-perl


Raul Infante-Sainz <infantesainz>
Group Member
Tue 05 May 2020 06:46:36 PM UTC, comment #12: 

Thanks for pointing this out Raul. Indeed, Gettext is used in many low-level components of the system. For example all the commands that print a Spanish output on your computer, but English on mine are using Gettext.

For example probably you'll also see it in your Bash. So maybe we can set it as a dependency of Bash.

I just checked on my computer, but there was no `libint', after some searching, I noticed that apparently a copy of Gettext is also in the GNU C library, so apparently it doesn't actually go looking for it.

So I just generally looked, and noticed that there is no `libintl' (of Gettext) installed in my Maneage:


$ find .local/  -name "libintl*"
.local/share/texinfo/lib/libintl-perl
.local/share/awk/libintl.awk


Can you try this on your system, maybe its a special part of it that is only built for macOS?

Mohammad Akhlaghi <makhlaghi>
Group administrator
Tue 05 May 2020 03:24:43 PM UTC, comment #11: 

I noticed in my macOS system that all programs of GNU coreutils needs Gettext. If I check for example `cp':


$ otool -L .local/bin/cp
.local/bin/cp:
  /usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.7.0)
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1455.12.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)


It is clear that depends on gettext! I also checked other programs like `echo', `ln', etc. I think it could be easily fixed by setting `gettext' to be a prerequisite of GNU coreutils.

Raul Infante-Sainz <infantesainz>
Group Member
Tue 05 May 2020 08:31:19 AM UTC, comment #10: 

Thanks Mohammad, I didn't notice there was a more recent version of libunistring because I used the ftp, and the last version is not there!! Anyway, I tried with the changes you added and it nicely went up to the end. So, everything is fine and can be merged into the master branch.

Raul Infante-Sainz <infantesainz>
Group Member
Tue 05 May 2020 02:02:41 AM UTC, comment #9: 

By the way, just one point: you may notice that I set Make to be a dependency of all the newly added libraries in `basic.mk' that didn't have any other dependency.

This is because in `basic.mk', first we need to make sure that we have the necessary low-level tools like the compressing programs, tar and Make. All other basic software depend on Make (which is only built after tar, which is built after the compressing programs).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Tue 05 May 2020 01:54:34 AM UTC, comment #8: 

Thanks a lot Raul, I tried it and everything built nicely until libunistring. It crashed with an error about core C library components, after searching a little, I noticed that the problem has been fixed in the more recent version 0.9.10.

So I upgraded the version in your branch and now it works on my system and Gettext was also built successfully! Nice job.

I have pushed my changes to a test branch on project-dev (where we can all push for development commits like these.

Can you just give this version a fast check on your macOS and if it doesn't have any problem, I'll merge it. Just remove the libunistring file and let it be built again.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 04 May 2020 06:06:59 PM UTC, comment #7: 

Thanks Mohammad. I am happy to say that after some time, I have been able to include GNU gettext into the project. Have a look at my fork (https://gitlab.com/infantesainz/reproduce-raulfork/-/commit/b43146918). It worked in my macOS laptop, so check if it also works in your machine and then merge ;-)
Just remember that there is a warning in the configure script to check if gettext is already available in the host system (remove it if now it is not necessary).

comment #6:

> Thanks Raul. Then if you have the chance, can you find where `msgfmt' is on your system, temporarily rename it, then check if it is not installed anywhere else:
>


> l=$(which msgfmt)
> mv $l $l-backup
> which msgfmt


>
> Then can you remove Git from your current build of Maneage, so it rebuilds it? If it builds, then we can only set this check for GNU/Linux systems.
>
> About adding Gettext in Maneage, to be honest its just a matter of available time. If you have a few minutes, can you try adding and testing it (as a dependency of Git on GNU/Linux and macOS)?

Raul Infante-Sainz <infantesainz>
Group Member
Wed 29 Apr 2020 11:36:07 PM UTC, comment #6: 

Thanks Raul. Then if you have the chance, can you find where `msgfmt' is on your system, temporarily rename it, then check if it is not installed anywhere else:


l=$(which msgfmt)
mv $l $l-backup
which msgfmt


Then can you remove Git from your current build of Maneage, so it rebuilds it? If it builds, then we can only set this check for GNU/Linux systems.

About adding Gettext in Maneage, to be honest its just a matter of available time. If you have a few minutes, can you try adding and testing it (as a dependency of Git on GNU/Linux and macOS)?

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 29 Apr 2020 08:35:15 AM UTC, comment #5: 

From bug #58265
comment #2:

> But another point was also interesting for me: you didn't have gettext on your macOS until now, and Maneage built successfully with no problem, right?
>
> If so, maybe we should only add that test only for GNU/Linux systems, thanks for mentioning this ;-).


The point is that I don't know if I had gettext. I tried to run and when I saw the warning message about gettext, I installed it from source but getting some errors. Then I installed it with brew.

In this sense, what is the reason of not having gettext into Maneage? I guess it is because some difficulties but I saw the brew formulae and it seems to be not particularly hard.

Raul Infante-Sainz <infantesainz>
Group Member
Wed 29 Apr 2020 02:01:52 AM UTC, comment #4: 

I am opening this bug following the discussion in bug #58265: that gettext may not be necessary for Git on macOS.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 27 Apr 2020 01:10:08 AM UTC, comment #3: 

Oh yes! Gettext! Currently we use the host operating system's Gettext (by making a link to it in the `low-level-links' target). I think one of the problems we had with it was several dependencies that we didn't have time to add.

Unfortunately I couldn't find a way to tell Git to ignore Gettext as a configuration option! Maybe we should ask them to add such an option if its possible for them.

I just defined task #15616 so we don't forget to install Gettext. In that task I have also mentioned that until then, we add a check and warning in `configure.sh' to ask the user to install it manually before actually building anything.

So given that the source of the problem is now found and a task has been defined, we can safely close this bug.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 27 Apr 2020 12:13:34 AM UTC, comment #2: 

Solved. I hadn't scrolled up enough in the log to find the real bug: msgfmt was missing.


aptitude install gettext


solves the bug in Debian GNU/Linux.

Obviously, a better solution for Maneage would be (1) define gettext as a dependence of git in reproduce/software/make/high-level.mk and (2) provide the mechanisms needed for installing gettext high-level.mk (or rather basic.mk ?), config/checksums.conf and config/versions.conf .

I'm switching the severity to 'normal', because many people will already have gettext installed or will easily be able to install it.

Is gettext part of POSIX?

https://en.wikipedia.org/wiki/Gettext


"Two proposals were raised in the late 1980s, the 1988 Uniforum gettext and the 1989 X/Open catgets (XPG-3 ยง 5). ... As of August 2019, whether gettext should be part of POSIX was still a point of debate in the Austin Group, despite the fact that its old foe has already fallen out of use."


So probably gettext should be added to basic.mk and the associated files, even if it's apparently not yet formally part of POSIX.

Boud Roukema <boud>
Group Member
Sun 26 Apr 2020 11:53:33 PM UTC, comment #1: 

I think I've solved this... ;) Back soon...

Boud Roukema <boud>
Group Member
Sun 26 Apr 2020 03:39:06 PM UTC, original submission:  

DESCRIPTION:
On commit cb74bd9fa865d2f, on a completely fresh download, i.e. after


git clone https://git.maneage.org/project.git
mv -iv project maneage_project
cd maneage_project
time (./project configure) |tee tmp.configure.rza20200426.log 2>&1


I got the error messages in the terminal

sed -e '1s|#!.*/sh|#!/tmp/tmp_build_maneage_project/software/installed/bin/bash|' \
     -e 's|@@BUILD_DIR@@|/tmp/tmp_build_maneage_project/software/build-tmp/git-2.23.0|' \
     -e 's|@@PROG@@|t/helper/test-tool|' < wrap-for-bin.sh > bin-wrappers/test-tool && \
chmod +x bin-wrappers/test-tool
make[1]: Leaving directory '/dev/shm/tmp-maneage_project-boud/git-2.23.0'
make: *** [//tmp/tmp_build_maneage_project/software/installed/version-info/proglib/git] Error 2
reproduce/software/make/basic.mk:959: recipe for target '/tmp/tmp_build_maneage_project/software/installed/version-info/proglib/git' failed
make: Target 'all' not remade because of errors.


and in my log file, with line numbers, I have

 62989  chmod +x bin-wrappers/test-tool
 62990  make[1]: Leaving directory '/dev/shm/tmp-maneage_project-boud/git-2.23.0'
 62991  reproduce/software/make/basic.mk:959: recipe for target '/tmp/tmp_build_maneage_project/software/installed/version-info/proglib/git' failed
 62992  PASS: t-toom8h
 62993  PASS: t-toom2-sqr


In basic.mk I see

   956  $(ibidir)/git: $(ibidir)/curl \
   957                 $(ibidir)/libiconv \
   958                 | $(tdir)/git-$(git-version).tar.xz
   959          if [ x$(on_mac_os) = xyes ]; then \
   960            export LDFLAGS="$$LDFLAGS -lcharset"; \
   961          fi; \
   962          $(call gbuild, git-$(git-version), static, \
   963                         --without-tcltk --with-shell=$(ibdir)/bash \
   964                         --with-iconv=$(idir), V=1) \
   965          && echo "Git $(git-version)" > $@


This system is not a Mac, it is Debian/stretch x86_64 GNU/Linux.

REPRODUCE:
I did `./project configure --existing-conf` a second and third time and got the same error each time.

ANALYSIS:
Each time I try `./project configure --existing-conf`, a whole lot of configuring and compilation is done, taking about three minutes, so the testing cycle for tracing this bug is slow.

DIAGNOSIS:
After the third try:


$ ls -lt .build/software/installed/version-info/*
.build/software/installed/version-info/proglib:
total 144
-rw-r--r-- 1 boud boud 39 Apr 26 15:52 mpc
-rw-r--r-- 1 boud boud 14 Apr 26 15:51 gawk
-rw-r--r-- 1 boud boud 53 Apr 26 15:51 mpfr
-rw-r--r-- 1 boud boud 29 Apr 26 15:48 isl
-rw-r--r-- 1 boud boud 48 Apr 26 15:46 gmp
-rw-r--r-- 1 boud boud 16 Apr 26 15:42 wget
-rw-r--r-- 1 boud boud 12 Apr 26 15:41 curl
-rw-r--r-- 1 boud boud 18 Apr 26 15:41 libiconv
-rw-r--r-- 1 boud boud 18 Apr 26 15:41 glibtool
-rw-r--r-- 1 boud boud 18 Apr 26 15:41 pkg-config
-rw-r--r-- 1 boud boud 14 Apr 26 15:41 m4
-rw-r--r-- 1 boud boud 20 Apr 26 15:41 findutils
-rw-r--r-- 1 boud boud 13 Apr 26 15:40 grep
-rw-r--r-- 1 boud boud 18 Apr 26 15:40 diffutils
-rw-r--r-- 1 boud boud 12 Apr 26 15:40 sed
-rw-r--r-- 1 boud boud 13 Apr 26 15:40 libbsd
-rw-r--r-- 1 boud boud 10 Apr 26 15:40 file
-rw-r--r-- 1 boud boud 15 Apr 26 15:40 which
-rw-r--r-- 1 boud boud 19 Apr 26 15:40 coreutils
-rw-r--r-- 1 boud boud 16 Apr 26 15:39 texinfo
-rw-r--r-- 1 boud boud 12 Apr 26 15:38 perl
-rw-r--r-- 1 boud boud 15 Apr 26 15:36 openssl
-rw-r--r-- 1 boud boud 16 Apr 26 15:36 bash
-rw-r--r-- 1 boud boud 17 Apr 26 15:35 readline
-rw-r--r-- 1 boud boud 16 Apr 26 15:35 ncurses
-rw-r--r-- 1 boud boud 14 Apr 26 15:34 patchelf
-rw-r--r-- 1 boud boud 13 Apr 26 15:34 make
-rw-r--r-- 1 boud boud 13 Apr 26 15:34 tar
-rw-r--r-- 1 boud boud 12 Apr 26 15:33 bzip2
-rw-r--r-- 1 boud boud  8 Apr 26 15:33 zip
-rw-r--r-- 1 boud boud 15 Apr 26 15:33 xz
-rw-r--r-- 1 boud boud 10 Apr 26 15:33 unzip
-rw-r--r-- 1 boud boud 10 Apr 26 15:33 lzip
-rw-r--r-- 1 boud boud 14 Apr 26 15:33 gzip
-rw-r--r-- 1 boud boud 12 Apr 26 15:32 zlib
-rw-r--r-- 1 boud boud  0 Apr 26 15:31 low-level-links
-rw-r--r-- 1 boud boud 21 Apr 26 15:31 flock

.build/software/installed/version-info/tex:
total 0

.build/software/installed/version-info/cite:
total 0

.build/software/installed/version-info/python:
total 0


and

$ cat .build/software/installed/version-info/proglib/*
GNU Bash 5.0.11
Bzip2 1.0.6
GNU Coreutils 8.31
cURL 7.65.3
GNU Diffutils 3.7
File 5.36
GNU Findutils 4.7.0
Discoteq flock 0.2.3
GNU AWK 5.0.1
GNU Libtool 2.4.6
GNU Multiple Precision Arithmetic Library 6.1.2
GNU Grep 3.3
GNU Gzip 1.10
GNU Integer Set Library 0.18
Libbsd 0.9.1
GNU libiconv 1.16
Lzip 1.20
GNU M4 1.4.18
GNU Make 4.3
GNU Multiple Precision Complex library
GNU Multiple Precision Floating-Point Reliably 4.0.2
GNU NCURSES 6.1
OpenSSL 1.1.1a
PatchELF 0.10
Perl 5.30.0
pkg-config 0.29.2
GNU Readline 8.0
GNU Sed 4.7
GNU Tar 1.32
GNU Texinfo 6.6
Unzip 6.0
GNU Wget 1.20.3
GNU Which 2.21
XZ Utils 5.2.4
Zip 3.0
Zlib 1.2.11


After the 6th try (see below):

du -hs .build/
432M    .build/


HYPOTHESES:
This might be an error introduced in commit `3a49e2c`. However, after git checking out down to commit `d91813a`, the error occurs, but on line 962: `reproduce/software/make/basic.mk:962:`.

Trying with git checkout commit `8eb0892e`... fails at `reproduce/software/make/basic.mk:971`.

Trying with commit `a4e2ec81d57e` from 5 April. `./project configure --existing-conf` asked me to give the build directory again. Failure at `reproduce/software/make/basic.mk:971`.

Boud Roukema <boud>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #49018:  bash-output.log added by infantesainz (188KiB - application/octet-stream)
file #49019:  Makefile added by infantesainz (82KiB - application/octet-stream)
file #49020:  config.log added by infantesainz (722KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by infantesainz (Posted a comment)
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-08 makhlaghi StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2020-05-07 infantesainz Attached File- Added config.log, #49020
    2020-05-07 infantesainz Attached File- Added bash-output.log, #49018
        Attached File- Added Makefile, #49019
    2020-04-29 makhlaghi CategoryNone Software
        Item GroupNone Crash
        StatusNone In Progress
    2020-04-29 makhlaghi Open/ClosedClosed Open
    2020-04-27 boud CategorySoftware None
        Item GroupCrash None
        StatusFixed None
        Assigned toboud None
    2020-04-27 makhlaghi CategoryNone Software
        Item GroupNone Crash
        StatusNone Fixed
        Assigned toNone boud
        Open/ClosedOpen Closed
        Summarybasic.mk bug Git depends on Gettext (which is not yet in Maneage)
    2020-04-27 boud Severity4 - Important 3 - Normal

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code