Bug in strip phase of gnu-build-system?
Hello, Sanity check, please. When `strip-binaries?` is `#f` and a "debug" output is defined, said output remains empty. Instead, I expect "debug" to get populated with separated debug files. The logic for creating debug files exists in (guix build gnu-build-system) under the definition of `strip`. In particular `strip-dir` extracts the debug info into "debug" if and only fi that output exists. Note, that (guix build-system gnu) already removes "debug" from the outputs when strip-binaries? is true. However, for some reason the actual `strip-dir1 invocation is wrapped in a (if strip-binaries? ...) check, meaning that the entire phase becomes a no-op. Shouldn't that if check be removed? I have CC'ed Mark Weaver, since it looks like he is the author of this particular if block. Cheers, B. Wilson P.S. If the above is correct, then would it make sense for --with-debug-info to also inject a "debug" output as needed? It looks like this would be pretty easy under guix/transformations.scm:transforma-package-with-debug-info.
Re: Set FORCE_SOURCE_DATE=1 by default
On 2022-06-23, Maxim Cournoyer wrote:
>>> Perhaps to show our stand here we could patch our copy of pdftex with
>>> 's/FORCE_SOURCE_DATE/SOURCE_DATE_EPOCH/', lest we end up with a grocery
>>> list of *SOURCE_DATE* variable variants.
>>
>> Sure, with some technical details fixed up, as I think they are
>> functionally different, in that FORCE_SOURCE_DATE is a boolean, and
>> SOURCE_DATE_EPOCH is an integer, though ... Guix sets
>> SOURCE_DATE_EPOCH=1 ... so it might just work by dumb luck! Though There
>> may be some rare packages that need SOURCE_DATE_EPOCH to be some larger
>> value... "It can't possibly be 1970, this program was first written in
>> 2002, there must be some error, failing build..."
>>
>> At any rate, if diverging from upstream Tex Live is how Guix wants to
>> handle this, I'm all for it!
>
> Seems we have a small consensus here (Ludo, you and myself); would you
> like to give it a try?
My first naive attempt appeared to build, but failed lots of test
suites... so that clearly needs some more work!
diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index f6b4c25595..e8c99d202b 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -395,6 +395,12 @@ (define-public texlive-bin
(("srcdir/tests/pprecA-0.ind pprecA-0.ind1 \\|\\| exit 1")
"srcdir/tests/pprecA-0.ind pprecA-0.ind1 || exit 77")
'())
+ (add-after 'unpack 'default-to-force-source-date
+ ;;
https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00330.html
+ (lambda _
+ ;; texk/web2c/lib/texmfmp.c: string sde_texprim = getenv
("FORCE_SOURCE_DATE");
+ (substitute* "texk/web2c/lib/texmfmp.c"
+(("getenv ..FORCE_SOURCE_DATE..") "1"
(add-after 'unpack 'unpack-texlive-extra
(lambda* (#:key inputs #:allow-other-keys)
(mkdir "texlive-extra")
No idea if this approach would have any side-effects ... there is some
code that checks if both FORCE_SOURCE_DATE and SOURCE_DATE_EPOCH are set
... but i *think* this is the only spot where it directly checks if
FORCE_SOURCE_DATE is set. It would also be good to support
FORCE_SOURCE_DATE=0 if there is in fact some real-world use-case with
SOURCE_DATE_EPOCH is set and FORCE_SOURCE_DATE should be "0".
I'll try with tests disabled to see if it at least fixes the issue in
the two packages (itpp, discrover) that manually set FORCE_SOURCE_DATE.
live well,
vagrant
signature.asc
Description: PGP signature
My GPG key just expired. I know.
Hi, Just a pre-emptive note that, yes, I'm aware. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
Re: Non-free data in Poppler test suite
Hi, Mark's reply addresses everything that would worry me from an FSDG perspective and more -- thanks Mark! On 2022-07-01 15:12, Ludovic Courtès wrote: It may also be that this qualifies as fair use (AIUI, we’re talking about pages extracted from larger PDF files, right?). ...but from a copyright perspective, no, this does not fly at all I'm afraid. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
Re: Non-free data in Poppler test suite
Am Dienstag, dem 28.06.2022 um 23:19 +0200 schrieb Marius Bakke: > Hello Guix, > > I discovered a potential freedom issue with the Poppler test suite. > [...] > So the million dollar question ... are these files okay to use for > Guix? > > In my (non-lawyer) opinion, I have faith that Poppler developers would > not distribute files that are not freely redistributable, and that this > counts as "non-functional data" per FSDG guidelines: Looking around the repository some more, I think there might actually have been some neglect w.r.t. how we typically recommend licensing information ought to be conveyed. I've raised two issues upstream, [1] for data as reported here, [2] for code. Let's see how poppler devs reply. Cheers [1] https://gitlab.freedesktop.org/poppler/test/-/issues/1 [2] https://gitlab.freedesktop.org/poppler/test/-/issues/2
