Re: Big picture of building & packaging

[dev]

Thank you, Bruno. I'll take your advice.

The original issue came from the tests of the Perl po4a module 
(https://github.com/mquinson/po4a), in which the header of a generated German 
PO file went from:

# German translations for po package
# ...

to

# German translations for po package
# German translation for po
# ...

In nixpkgs, this package is built on both OSX and NixOS (Linux distro), and the 
failure only appears on OSX.

I have been able to trace it down to the following section of code in msginit.c:

  if (setlocale (LC_ALL, "") == NULL)
    /* Nonexistent locale.  Use the English title.  */
    result = english;
  else
    {
      /* Fetch the translation.  */
      ...
      if (result != msgid && strcmp (result, msgid) != 0)
        /* Use the English and the foreign title.  */
        result = xasprintf ("%s\n%s", english, result);
      ...

On OSX, in v0.21, the setlocale function call returns NULL, while it does not 
in v0.21.1. (Therefore, the line of code that prints both the English and the 
foreign title is triggered and the extra line appears.)

Any insights or suggestions for where to look next very welcome.

Teddy


June 10, 2023 3:40 PM, "Bruno Haible" <bruno@clisp.org> wrote:

> Hi,
> 
>> Brief background: I'm debugging a difference in behavior between v0.21 and 
>> v0.21.1 on OSX as part
>> of building something in the nixpkgs project.
> 
> Maybe, if you state the actual problem, I can make some guess as to the cause?
> The NEWS file doesn't mention a modified behaviour on macOS 10.*, only that
> "Building on macOS 11/arm64 is now supported."
> 
>> I have exhausted some easy / low-tech ways to find out the root cause and 
>> would like to bisect
>> gettext.
>> 
>> The problem is that nixpkgs builds gettext from source in the released tar 
>> files and not from the
>> Git repository, so I need to translate from one to the other. For instance, 
>> as you know, the tar
>> files have gnulib vendored under gettext-tools while the repository does 
>> not. I poked around a
>> little and tried "./gitsub.sh pull" followed by "./autogen.sh" and ran into 
>> some error related to
>> patching files (on an M1 Mac).
> 
> Bisecting gettext is possible, but
> - be sure to use the '0.21.x' branch of
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=summary
> - on this branch, the 'gnulib' submodule switched to a branch as well,
> namely gnulib's stable-202201 branch.
> 
>> I can debug that and push this to the end, but I'm worried about sinking a 
>> lot of time
>> unproductively if the actual packaging process is completely different.
> 
> Not only that. Also, bisecting usually assumes that all commits in the history
> were "good" in the sense that they produced a working build. But especially as
> - sometimes a commit (or a few commits) are not working, and this gets only
> corrected a week later or so,
> - macOS 11 is not a frequently tested platform,
> you can get into all sorts of trouble while bisecting.
> 
>> Would you be able to advise me on whether I am on the right track here?
> 
> I would say that it's going to be a big time sink. It's most likely more
> productive if you just state the problem.
> 
> Bruno