all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Runciter via Guix-patches via <guix-patches@gnu.org>
To: Nicolas Graves <ngraves@ngraves.fr>
Cc: 74411@debbugs.gnu.org
Subject: [bug#74411] freedict-dictionaries build non-deterministic
Date: Tue, 19 Nov 2024 15:13:06 +0000	[thread overview]
Message-ID: <871pz76yv7.fsf@whispers-vpn.org> (raw)
In-Reply-To: <cover.1731747114.git.runciter@whispers-vpn.org>

"Nicolas Graves" <ngraves@ngraves.fr> writes:

> On 2024-11-18 06:37, Runciter via Guix-patches via wrote:
>
>> The build of the package freedict-dictionaries is non-deterministic, at
>> least because the output dictionaries are compressed by the utility
>> dictzip, which includes a timestamp in the compressed file headers.
>
> Are you sure there are no options at compression time to force
> determinism on the archive?
>

I'm as sure as one can be when one has read the man page of
dictzip. That is to say, not sure about undocumented features.

Independently of dictzip capabilities, one problem actually is having to
patch the freedict-tools package if one wants to change anything to the
output compression of freedict-dictionaries. From what I found online,
FreeDict does not document how to fine-tune or disable dictzip
compression within its build system. In the place where it's done at
compile-time, I don't see any handles I could use; you can look if you
want, it's in the source of the freedict-tools package, the
'install-base' target found in the file mk/dicts.mk.

Now that I think about it I figure, IF a patch has to be done, then
surely anyway some command-line hack could be inserted into the target
from the patch that would make up for the lack of a usable command-line
switch in dictzip... It's lame to have to create, setup and maintain a
patch, but if it has to be done we might as well enjoy the flexibility.

Incidentally, gzip as a subsitute for dictzip is documented to work in
dictd, some dictd optimizations would be lost though, I guess gzipped
dictionaries may also work in dicod and I also guess, dicod probably
does not bother to make detailed optimizations tailored to the dictzip
format specifics. This and other considerations makes it potentially
worthwhile to experiment a little by creating a dictd service in my
system, if that is practical, as well as playing around with the
relevant dicod handler.

Let me study in those directions until the end of the week and get back
to you.

Regards,





  parent reply	other threads:[~2024-11-19 16:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-17 18:06 [bug#74411] [PATCH 0/4] Add DICT and FreeDict projects packages Runciter via Guix-patches via
2024-11-18  5:55 ` [bug#74411] [PATCH 1/4] gnu: Add (gnu packages dictd) Runciter via Guix-patches via
2024-11-18  5:56 ` [bug#74411] [PATCH 2/4] gnu: Add dictd-1.13.1 Runciter via Guix-patches via
2024-11-18  5:56 ` [bug#74411] [PATCH 3/4] gnu: Add freedict-tools-0.6.0 Runciter via Guix-patches via
2024-11-18  5:56 ` [bug#74411] [PATCH 4/4] gnu: Add freedict-dictionaries Runciter via Guix-patches via
2024-11-18  6:37 ` [bug#74411] freedict-dictionaries build non-deterministic Runciter via Guix-patches via
2024-11-19  8:43   ` Nicolas Graves via Guix-patches via
2024-11-19 15:13 ` Runciter via Guix-patches via [this message]
2024-11-21  0:49 ` [bug#74411] [PATCH v2 1/5] gnu: Add (gnu packages dictd) Runciter via Guix-patches via
2024-11-21  0:49   ` [bug#74411] [PATCH v2 2/5] gnu: Add dictd-1.13.1 Runciter via Guix-patches via
2024-11-21  0:50   ` [bug#74411] [PATCH v2 3/5] gnu: Add freedict-tools-0.6.0 Runciter via Guix-patches via
2024-11-21  0:50   ` [bug#74411] [PATCH v2 4/5] gnu: Add freedict-dictionaries Runciter via Guix-patches via
2024-11-21  0:50   ` [bug#74411] [PATCH v2 5/5] gnu: freedict-tools: Fix non-determinism of dictzip compressed file headers Runciter via Guix-patches via
2024-11-21  1:15 ` [bug#74411] patch v2 non-determinism fix Runciter via Guix-patches via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871pz76yv7.fsf@whispers-vpn.org \
    --to=guix-patches@gnu.org \
    --cc=74411@debbugs.gnu.org \
    --cc=ngraves@ngraves.fr \
    --cc=runciter@whispers-vpn.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.