Translation: Would regional translation fall back to primary language?
Hi, I'd like to have Guix in Colombian Spanish (es-CO) but without translating the whole set of source strings. Instead, I'd like to be able to add translations only for those words and expressions whose current Spanish (es) translations don't sound that local. es └── es-CO So, assuming an incomplete es-CO translation catalog already exists, would the translation system (gettext?) retrieve missing translations from the catalog corresponding to the primary language (es) or would it retrieve the source string in English? Thanks in advance, --- Luis Felipe López Acevedo https://luis-felipe.gitlab.io/ publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Why are build systems separated into two modules?
Am Samstag, dem 17.09.2022 um 08:51 -0500 schrieb jgart: > Hi Guixers, > > Why are build systems separated into two modules? > > Why can't an entire build system be contained in a single module? > > Just trying to understand the background design decisions that went > into that for my own knowledge and understanding. This way it's easier to separate what goes into the build (guix build my-build-system) and what doesn't (guix build-system my). The closure of available modules at build time is declared in the #:arguments and gets default-initialized to the %my-build-system-modules. HTH
Why are build systems separated into two modules?
Hi Guixers, Why are build systems separated into two modules? Why can't an entire build system be contained in a single module? Just trying to understand the background design decisions that went into that for my own knowledge and understanding. all best, jgart
New Serbian PO file for 'shepherd' (version 0.9.0rc1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Serbian team of translators. The file is available at: https://translationproject.org/latest/shepherd/sr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Stumpwm Contrib Packages
On 11-09-2022 17:02, Trev wrote: Hey Guix, I am trying to decide whether or not to contribute a refactor of stumpwm-contrib in gnu/packages/wm.scm. It feels like each contrib module should be its own package with its own checkout and that it might be a bad idea to update all of the contrib modules through one common ancestor. If you are not familar with stumpwm and stumpwm-contrib, you can see the source repository here:https://github.com/stumpwm/stumpwm-contrib The inheritance I am referring to is here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/wm.scm#n1942 My reasoning for this is that if breaking changes are introduced to one module, but wanted updates happen to another, it would be nice to avoid the breaking changes and get the updates. If the stumpwm people put lots of components in a single 'stumpwm-contrib', I expect that they take care of making sure all the components _within a single version_ remain compatible, and that by picking a separate commit for each component in Guix, it is likely to encounter incompatibilities (breaking changes). In the hopefully rare case where we encounter an incompatibility, we can still choose to override the checkout for the impacted package. As such, I recommend keeping the status quo. Greetings, Maxime OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Stumpwm Contrib Packages
Trev writes: > Hey Guix, > > I am trying to decide whether or not to contribute a refactor of > stumpwm-contrib in gnu/packages/wm.scm. It feels like each contrib > module should be its own package with its own checkout and that it might > be a bad idea to update all of the contrib modules through one common > ancestor. Hi, I'm only an user of these contrib packages and I see no issue with your proposition. IMHO, you can move on. Thanks. Regards, -- Antonio Carlos PADOAN JUNIOR GPG fingerprint: 243F 237F 2DD3 4DCA 4EA3 1341 2481 90F9 B421 A6C9
Stumpwm Contrib Packages
Hey Guix, I am trying to decide whether or not to contribute a refactor of stumpwm-contrib in gnu/packages/wm.scm. It feels like each contrib module should be its own package with its own checkout and that it might be a bad idea to update all of the contrib modules through one common ancestor. If you are not familar with stumpwm and stumpwm-contrib, you can see the source repository here: https://github.com/stumpwm/stumpwm-contrib The inheritance I am referring to is here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/wm.scm#n1942 My reasoning for this is that if breaking changes are introduced to one module, but wanted updates happen to another, it would be nice to avoid the breaking changes and get the updates. I have some related contributions to stumpwm-contrib that I would like to submit but I would rather wait and see what others may think first and perhaps avoid making the effort to refactor where the effort is not wanted. If I run into personal issues with the current pattern, I can always just "fork" a module into my own channel, after all. -- Trev : 0FB7 D06B 4A2A F07E AD5B 1169 183B 6306 8AA1 D206
Re: Updating minetest to 5.6.0?
On 17-09-2022 02:13, Jan Wielkiewicz wrote: Forgot the patches... Some problems (1) a single package per patch (minetest-naturalslopeslib can be done in a commit before minetest-exile) (2) no superfluous version prefixes -- remove the "v" from (version "v0.3.8") and replace (commit version) by (commit (string-append "v" version)) (3) naturalslopeslib is lgpl2.1+, according to the README.md (4) In minetest-exile, input labels can be avoided by replacing +(add-after 'install 'install-dependencies + (lambda _ +(symlink (string-append + #$(this-package-input + "minetest-naturalslopeslib") + "/share/minetest/mods/naturalslopeslib") + (string-append + #$output + "/share/minetest/games/exile/" + "mods/naturalslopeslib"))) (5) Going by https://content.minetest.net/packages/Mantar/exile/, more specifically its Website link, the home page is https://exile.planetofnix.com/wiki/pmwiki.php?n=Main.HomePage (6) According to the content.minetest.net page, you forgot to mention the CC-BY-SA-3.0 license. (7) Patches need to be sent to guix-patc...@gnu.org, not guix-devel. (8) I found a directory utilities/ -- IIUC, these bundled mods aren't actually used by the game, so they could simply be removed in a snippet like minetest-naturalslopeslib with (add-after 'install 'install-dependencies (lambda _ (symlink (search-input-directory inputs "share/minetest/mods/naturalslopeslib") (string-append #$output "/share/minetest/games/exile/" "mods/naturalslopeslib"))) Some things I can confirm: (1) the hash for mintest-naturalslopeslib matches (2) likewise for minetest-exile Note: I didn't actually try out these patches. Greetings, Maxime OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Updating minetest to 5.6.0?
On 17-09-2022 02:10, Jan Wielkiewicz wrote: Done. See the patches (I can't really find "git send-email" on Guix for some odd reason). The hacks in the Exile package are quite ugly, but I don't know a better way, see below. Try "guix show git", it will mention a 'send-email' output that you can install to have access to 'git send-email'. See ‘(guix)Packages with Multiple Outputs’ on how to install such outputs. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
