Ludovic Courtès <l...@gnu.org> writes: Hello Guix,
> Hello Runciter, > > Lots of interesting things in there! > > If I could have a wish list of things to integrate in Guix proper, it > would be this: > >> * dictd: the original programs for the DICT protocol. Includes the dict >> client and dictd server, which dico and dicod know how to >> emulate. Also includes the dictfmt utility, which is useful to express >> DICT dictionaries from human-written sources or other dictionary >> formats, for which GNU dico has no equivalent to my knowledge. I'm >> just the packager not an author. >> >> * freedict-tools: I packaged helper tools to compile the freedict >> multilingual dictionaries. I'm just the packager not an author. >> >> * freedict-dictionaries: package containing a subset of the >> freedict-dictionaries, intended for a local installation on a Guix >> system. I think the subset which I packaged corresponds exactly to the >> Freedict bilingual dictionaries which are human-written. The Freedict >> project also has a system which copulates 2 bilingual dictionaries >> sharing a common language into a third new automatically generated >> bilingual dictionary, I don't think my package outputs any of the many >> dictionaries which are expressed by this system. I'm just the packager >> not an author. I've just sent a cover letter to the patches mailing list, I'm waiting for it to show up before sending 4 patches. There's 4 packages and not 3 finally because 'libmaa' is a dependency of dictd. Everything compiles and cross-compiles, however the 'freedict-dictionaries' build is non-deterministic. One reason, hopefully the only reason for the non-deterministic output is that the 'dictzip' program includes a timestamp header in the compressed files it produces. The man page of dictzip does not document a way to modify or get rid of the timestamp header. There is a possible fix I have not tried yet, which looks like it's going to work: I could probably output non-compressed binary dictionary files (*.dict) instead of dictzipped dictionary files (*.dict.dz). In order to do it, an 'install-base' target needs to be modified. This target is found in mk/dicts.mk inside the toolchain package 'freedict-tools'. I have not found how this could be easily configured at build-time, at the moment I would only know how to do it with a patch to the 'freedict-tools' package. What's your policy, or what's your call for this case? Do you want me to try my fix, or do you find it preferable to sacrifice determinism in exchange for enjoying dictzip compression of the output, which also amounts to staying faithful to the upstream intended installation contents? Other suggestions? Runciter
