[bug#49408] [PATCH 2/2] gnu: biber: Update to 2.16

[Thiago Jung Bauermann via Guix-patches via <guix-patches@gnu.org>]

Em terça-feira, 13 de julho de 2021, às 10:19:56 -03, Nathan Benedetto 
Proença escreveu:
> Thiago Jung Bauermann <bauermann@kolabnow.com> writes:
> > Hi Nathan,
> > 
> > Em sexta-feira, 9 de julho de 2021, às 10:45:16 -03,
> > Nathan Benedetto Proença escreveu:
> > Either way, this patch is also missing a changelog entry.
> 
> What would be the appropriate course of action? Should I simply send new
> patches with changelogs like I have sent these ones?

Yes, and also mark them as v2.

> >> @@ -6963,6 +6959,7 @@ values (strings, macros, or numbers) pasted
> > 
> > together.")
> > 
> >>         ("perl-datetime-format-builder" ,perl-datetime-format-builder)
> >>         ("perl-datetime-calendar-julian"
> >>         ,perl-datetime-calendar-julian)
> >>         ("perl-file-slurper" ,perl-file-slurper)
> >> 
> >> +       ("perl-io-string" ,perl-io-string)
> >> 
> >>         ("perl-ipc-cmd" ,perl-ipc-cmd)
> >>         ("perl-ipc-run3" ,perl-ipc-run3)
> >>         ("perl-list-allutils" ,perl-list-allutils)
> > 
> > I removed perl-io-string from the inputs and I was still able to build
> > the package. If it is needed, can you add a comment somewhere (not
> > sure if it’s better to mention it in the commit message or put it as a
> > comment in the code) explaining why it’s necessary?
> 
> When some of the builds failed, biber listed packages they required, and
> perl-io-string was one of them, so this is why I added it.
> I believe that if you look into the build log you may find some
> complaint about IO::String missing, or that you are using an older
> version.

You are right, it shows:

```
Checking prerequisites...
  requires:
    !  IO::String is not installed

ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the 
versions of the modules indicated above before proceeding with this 
installation

Run 'Build installdeps' to install missing prerequisites.
```

I should have checked the build log to see if everything was ok.

> >> @@ -6970,10 +6967,8 @@ values (strings, macros, or numbers) pasted
> >> together.") ("perl-mozilla-ca" ,perl-mozilla-ca)
> >> 
> >>         ("perl-regexp-common" ,perl-regexp-common)
> >>         ("perl-log-log4perl" ,perl-log-log4perl)
> >> 
> >> -       ;; We cannot use perl-unicode-collate here, because otherwise
> >> the -       ;; hardcoded hashes in the tests would differ.  See
> >> -       ;; https://mail-archive.com/debian-bugs-dist@lists.debian.org/
> > 
> > msg1469249.html
> > 
> >> -       ;;("perl-unicode-collate" ,perl-unicode-collate)
> >> +       ("perl-parse-recdescent" ,perl-parse-recdescent)
> >> +       ("perl-unicode-collate" ,perl-unicode-collate)
> >> 
> >>         ("perl-unicode-normalize" ,perl-unicode-normalize)
> >>         ("perl-unicode-linebreak" ,perl-unicode-linebreak)
> >>         ("perl-encode-eucjpascii" ,perl-encode-eucjpascii)
> > 
> > I applied the patch and verified that perl-text-bibtex builds. You
> > mentioned in my GitLab repo that you use biber for your dissertation.
> > With these patches applied, is it working well for you?
> 
> Yes, I have been using biber and latex from this sequence of patches for
> a couple of days now.

Nice! Thanks for doing these tests.

> I believe I have identified another problem: texdoc is not working.
> Perhaps this is by choice (maybe Guix separates it into another package)
> or because we missed something, but I did not have time to look into it.

That’s true. It doesn’t seem to work even with TeX Live 2019. I’m not 
familiar with texdoc, so I don’t know what could be wrong (or whether it’s 
deliberate).

> If texlive does not "ship" texdoc, we may want to play around with some
> flags to be sure that we are not packaging documentation files we are
> not using.
> There are 3.1gb of files in the folder /share/texmf-dist/doc inside of
> the store folder generated by this package.

I agree. If files in /share/texmf-dist/doc are only useful with texdoc, 
then either it should be fixed or these files shouldn’t be shipped.

Though since this is a pre-existing problem (as far as I can tell, at 
least) I think it’s better to track it in a separate issue and not 
condition the TeX Live update on it.

-- 
Thanks,
Thiago