Re: Translation of the Guix manual & node names
Hi Julien,
Julien Lepiller writes:
> Le 24 avril 2019 09:08:34 GMT+02:00, Meiyo Peng a écrit :
>>Hi Julien,
>>
>>Julien Lepiller writes:
>>
>>> No, we have a small script that takes care of this. As long as the
>>node
>>> name is translated somewhere near the beginning of the file, it is
>>also
>>> automatically translated in the rest of the file. So that shouldn't
>>> cause an issue. Maybe there's an error in the script?
>>>
>>> Look at xref_command in doc/local.mk
>>
>>The xref_command is too complex for me to understand. Do you mean we
>>don't need to translate all the reference strings in @ref{}, @xref{}
>>and
>>@pxref{} as long as the target node name after "@node" is translated?
>>That will be a good news.
>
> Yes exactly! What this command does is to look for any ref, xref and pxref
> command and look for the translation of its content in the po file for the
> language.
I just find out that the @pxref{Packages with Multiple Outputs} in
doc/contributing.texi has to be translated. Or I will get an error
while running make:
#+begin_example
doc/contributing.zh_CN.texi:567: @pxref reference to nonexistent node
`Packages with Multiple Outputs'
#+end_example
I guess it's because the node name is in doc/guix.texi (another file
than doc/contributing.texi). Any idea?
--
Meiyo Peng
https://www.pengmeiyu.com/
Fwd: GNU gettext 0.20.1 released
Bruno, Wow. Thank you for this great summary! Would that all projects published such clear (and custom) release notes… <3 I see that gnu/packages/gettext.scm has a nice chronological list of copyright lines, which does make it appear as if I'm the current packager of gettext in Guix. However, the Guix project doesn't have this notion of (package) maintainer: everyone packages, fixes, and updates what they can whenever they can. This might change in future but it works rather well now. For that reason, I'm CC'ing the guix-devel@gnu.org list. I encourage you to add it to your own for future releases. I'm having some trouble with the actual upgrade but I'll save that for a reply. Thanks again, T G-R [Original message:] Available at https://ftp.gnu.org/gnu/gettext/gettext-0.20.1.tar.xz New in 0.20.1: * Important bug fix: - Fixed a wrong shared library versioning of libintl.so. New in 0.20: * Libtextstyle: - This package installs a new library 'libtextstyle', together with a new header file . It is a library for styling text output sent to a console or terminal emulator. Packagers: please see the suggested packaging hints in the file PACKAGING. * Support for reproducible builds: - msgfmt now eliminates the POT-Creation-Date header field from .mo files. * Improvements for translators: - update-po target in Makefile.in.in now uses msgmerge --previous. * Improvements for maintainers: - msgmerge now has an option --for-msgfmt, that produces a PO file meant for use by msgfmt only. This option saves processing time, in particular by omitting fuzzy matching that is not useful in this situation. - The .pot file in a 'po' directory is now erased by "make maintainer-clean". - It is now possible to override xgettext options from the po/Makefile.in.in through options in XGETTEXT_OPTIONS (declared in po/Makevars). - The --intl option of the gettextize program (deprecated since 2010) is no longer available. Instead of including the intl sources in your package, we suggest making the libintl library an optional prerequisite of your package. This will simplify the build system of your package. - Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone as well. * Programming languages support: - C, C++: xgettext now supports strings in u8"..." syntax, as specified in C11 and C++11. - C, C++: xgettext now supports 'p'/'P' exponent markers in number tokens, as specified in C99 and C++17. - C++: xgettext now supports underscores in number tokens. - C++: xgettext now supports single-quotes in number tokens, as specified in C++14. - Shell: o The programs 'gettext', 'ngettext' now support a --context argument. o gettext.sh contains new function eval_pgettext and eval_npgettext for producing translations of messages with context. - Java: o xgettext now supports UTF-8 encoded .properties files (a new feature of Java 9). o The build system and tools now support Java 9, 10, and 11. On the other hand, support for old versions of Java (Java 5 and older, GCJ 4.2.x and older) has been dropped. - Perl: o Native support for context functions (pgettext, dpgettext, dcpgettext, npgettext, dnpgettext, dcnpgettext). o better detection of question mark and slash as operators (as opposed to regular expression delimiters). - Scheme: xgettext now parses the syntax for specialized byte vectors (#u8(...), #vu8(...), etc.) correctly. - Pascal: xgettext can now extract strings from .rsj files, produced by the Free Pascal compiler version 3.0.0 or newer. - Vala: xgettext now parses escape sequences in strings more accurately. - JavaScript: xgettext now parses template literals correctly. * Runtime behaviour: - The interpretation of the language preferences on macOS has been fixed. - Per-thread locales are now also supported on Solaris 11.4. - The replacements for the printf()/fprintf()/... functions that are provided through on native Windows and NetBSD are now POSIX compliant. There is no conflict any more between these replacements and other possible replacements provided by gnulib or mingw. According to [1], you seem to be packaging gettext for Guix/GuixSD. I invite you to upgrade to version 0.20.1. The packaging will need changes, regarding the new libtextstyle; I recommend to package it as a separate binary package (see file PACKAGING). When doing this upgrade, you can drop the following workarounds: - test-lock now never hangs any more. - expat is not longer used (already since 0.19.7). Best regards, Bruno [1] https://git.savannah.gnu.org/gitweb/?p=guix.git;a=blob;f=gnu/packages/gettext.scm signature.asc Description: PGP signature
Re: GNU Shepherd 0.6.1 released
Hi Nala Ginrut, Nala Ginrut writes: > I saw it describes that "intended for use on GNU/Hurd", is it still > workable on GNU/Linux? Since that’s where it’s mainly used: definitely yes. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Check whether package has substitution
Hi znavko, On Mon, 13 May 2019 11:22:01 -0500 wrote > Hello! Users that have experience to install packages from binaries may have > troubles waiting compilation process. > I want to propose some things that can appreciably improve Guix users > experience. > > Users do not want to wait the compilation process. This may happen on > installation and update. > Guix may solve this problem giving to the user next possibilities: > > 1) check if there is substitution of some package you want to install for > your system state (and environment) > 2) check what packages will have to compile if you will update your system > > I think this is not that academic way Guix is intended for. But such a > feature will improve user experience riding him from long time compilation. > > Guix also may solve the problem of absent substitutions the next way. > Guix developers can create user interface for sending requests to default > substitution server to compile those packages users want right now. > As I know, hydra compiles all the packages for all the systems without > priorities. > So users can address to hydra their requests to compile some packages for > their system type (and environment). So hydra will stop its usual way of > things (that actually has the lowest priority) and start to compile packages > on user's behalf. > This way user can send a request, wait for 30-120 minutes and install it or > update to having substitution built on hydra. > > Reading some discussions about OS, I can say this is the first user want to > have, saying: 'Computing freedom is imposed by Guix, but that ugly > compilation process is what does not give me to start using it'. > > Please, could you try to satisfy new users by speed up packages installation? I've had similar thoughts. I usually run commands with the "--dry-run" option to avoid starting to build expensive packages (I have one computer; I depend on substitute servers to build those expensive packages for me). I was thinking that maybe the request to the substitute servers to build a given package should be done implicitly, instead of requiring the user to run some Guix command specific to that purpose. For example, and taking into account what znavko says, I'd like something like this: ## $ guix package -m manifest.scm would install new manifest from 'aggregate-manifest.scm' with 45 entries substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivations would be built: /gnu/store/...-abc.drv /gnu/store/...-dfg.drv 149.1 MB would be downloaded: /gnu/store/...-mno-3.1.0 /gnu/store/...-xyz-0.14.2 The following profile hooks would be built: /gnu/store/...-manual-database.drv /gnu/store/...-xdg-mime-database.drv Do you want to proceed? If "Yes", your machine will have to build some derivations locally. Depending on your machine, this process can take a lot of time. If "No", a request will be sent to https://ci.guix.gnu.org to build the derivations for you; then, you can try again later to see if the substitutes are available for download. (Yes/No) ## And the list of derivations that need to be built could be yellow or something.
Re: Introducing myself
Jakob L. Kreuze writes: > Hello, guix-devel! > > My name is Jakob L. Kreuze, and I was accepted into Google's Summer of > Code program this year to work on "guix deploy," the deployment > automation tool for GuixSD that's been discussed in [1] and [2]. I just > wanted to briefly introduce myself to the list, as you'll likely be > seeing postings from me about "guix deploy" on a regular basis. > > Officially, my work doesn't start until the 27th of this month; the next > few days will be spent ensuring that I have a working development > environment and familiarizing myself with both the code and the > development practices of Guix. > > I look forward to working with all of you. > > Jakob > > [1]: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00145.html > [2]: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00114.html Hi Jakob! Fancy seeing you here ;) As said in person today, the vision of "guix deploy" is what originally got me interested in Guix. I'm so thrilled you're going to be working this summer on making that a reality. Welcome aboard! - cwebb
Re: Check whether package has substitution
Hello! ezt írta (időpont: 2019. máj. 13., H, 18:22): > Hello! Users that have experience to install packages from binaries may > have troubles waiting compilation process. > I want to propose some things that can appreciably *improve Guix users > experience*. > > Users do not want to wait the compilation process. This may happen on > installation and update. > Guix may solve this problem giving to the user next possibilities: > > 1) check if there is substitution of some package you want to install for > your system state (and environment) > 2) check what packages will have to compile if you will update your system > > For profiles which have a manifest, you can guix weather the manifest. I believe someone more knowledgable than me can answer if that could be extended easily for the 'system reconfigure' case. > I think this is not that academic way Guix is intended for. But such a > feature will improve user experience riding him from long time compilation. > > Guix also may solve the problem of absent substitutions the next way. > Guix developers can create user interface for sending requests to default > substitution server to compile those packages users want right now. > As I know, hydra compiles all the packages for all the systems without > priorities. > So users can address to hydra their requests to compile some packages for > their system type (and environment). So hydra will stop its usual way of > things (that actually has the lowest priority) and start to compile > packages on user's behalf. > This way user can send a request, wait for 30-120 minutes and install it > or update to having substitution built on hydra. > > Reading some discussions about OS, I can say this is the first user want > to have, saying: 'Computing freedom is imposed by Guix, but that ugly > compilation process is what does not give me to start using it'. > > Please, could you try to satisfy new users by speed up packages > installation? > Best regards, g_bor
Re: Check whether package has substitution
Znavko, This doesn't address all points in your e-mail, but some days ago I too was suprised by the fact that ‘guix weather PACKAGE-SPEC’ didn't just do what I expected. I'll clean up my patch to do so (mainly testing that it actually works for other use cases than my… two :-) and send it in. Kind regards, T G-R signature.asc Description: PGP signature
Check whether package has substitution
Hello! Users that have experience to install packages from binaries may have troubles waiting compilation process. I want to propose some things that can appreciably improve Guix users experience. Users do not want to wait the compilation process. This may happen on installation and update. Guix may solve this problem giving to the user next possibilities: 1) check if there is substitution of some package you want to install for your system state (and environment) 2) check what packages will have to compile if you will update your system I think this is not that academic way Guix is intended for. But such a feature will improve user experience riding him from long time compilation. Guix also may solve the problem of absent substitutions the next way. Guix developers can create user interface for sending requests to default substitution server to compile those packages users want right now. As I know, hydra compiles all the packages for all the systems without priorities. So users can address to hydra their requests to compile some packages for their system type (and environment). So hydra will stop its usual way of things (that actually has the lowest priority) and start to compile packages on user's behalf. This way user can send a request, wait for 30-120 minutes and install it or update to having substitution built on hydra. Reading some discussions about OS, I can say this is the first user want to have, saying: 'Computing freedom is imposed by Guix, but that ugly compilation process is what does not give me to start using it'. Please, could you try to satisfy new users by speed up packages installation?
Re: [PATCH] download: Support 'https_proxy'.
Ludovic Courtès writes: > Hi! > > iyzs...@member.fsf.org (宋文武) skribis: > >> Hello, this patch add 'https_proxy' to 'guix download' (and guix-daemon >> if we update guix?): > > Neat! Pushed, thank you for the review! > >> From 424da6e43ba9c928403e3fd9b42e75d0fe90fc23 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= >> Date: Fri, 10 May 2019 21:27:40 +0800 >> Subject: [PATCH] download: Support 'https_proxy'. >> >> * guix/build/download.scm (setup-http-tunnel): New procedure. >> (open-connection-for-uri): Honor the 'https_proxy' environment variable. > > [...] > >> +(define (setup-http-tunnel port uri) >> + "Establish a tunnel to the destination server of URI." > > Maybe “Establish over PORT an HTTP tunnel to the destination server of > URI.”? Sure. > > Otherwise LGTM! > >> Some problems and questions: >> >> - It assumes ‘https_proxy’ is ‘http://PROXY-SERVER:PORT’, if the scheme >> part is missing, it fail. > > That’s already the case with ‘http_proxy’. > > It seems that other tools can happily deal with the lack of a URI > scheme, so perhaps in a subsequent patch we should add code to > automatically add a URI scheme when it’s missing? Yes, I think the URI scheme can be ‘http’, ‘https’ or ‘socks5’, etc. and default to ‘http’. We only have ‘http’ now, other are good exercise :) > >> - It fails some servers (eg: www.google.com) for me while curl works... > > For www.google.com it fails even without ‘https_proxy’, so that’s OK. > :-) > >> - I think this should go into guile’s ‘(web client)’ module? > > Yes! Once we’ve committed it Guix, it’d be great if you could a similar > patch to bug-gu...@gnu.org. > > Thank you! > > Ludo’. Okay, get it!
Re: New Russian PO file for 'guix-manual' (version 1.0.0-pre3)
Hello, "pelzflorian (Florian Pelz)" skribis: > On Sat, May 11, 2019 at 08:40:52PM +, zna...@disroot.org wrote: >> I have just sent both: >> guix-manual-1.0.1-pre1.ru.po, >> guix-manual-1.0.0-pre3.ru.po >> >> containing exact the same content. If it is right. >> As I understood, we go up in version number. >> > > Thank you! It works fine for me. (Sending the new version number > 1.0.1-pre1 would have been sufficient.) I confirmed that it works! Committed as 3bac7e6495934de9913e6186d954d1331883e064. Thank you! Ludo’.
Re: [PATCH] download: Support 'https_proxy'.
Hi! iyzs...@member.fsf.org (宋文武) skribis: > Hello, this patch add 'https_proxy' to 'guix download' (and guix-daemon > if we update guix?): Neat! > From 424da6e43ba9c928403e3fd9b42e75d0fe90fc23 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= > Date: Fri, 10 May 2019 21:27:40 +0800 > Subject: [PATCH] download: Support 'https_proxy'. > > * guix/build/download.scm (setup-http-tunnel): New procedure. > (open-connection-for-uri): Honor the 'https_proxy' environment variable. [...] > +(define (setup-http-tunnel port uri) > + "Establish a tunnel to the destination server of URI." Maybe “Establish over PORT an HTTP tunnel to the destination server of URI.”? Otherwise LGTM! > Some problems and questions: > > - It assumes ‘https_proxy’ is ‘http://PROXY-SERVER:PORT’, if the scheme > part is missing, it fail. That’s already the case with ‘http_proxy’. It seems that other tools can happily deal with the lack of a URI scheme, so perhaps in a subsequent patch we should add code to automatically add a URI scheme when it’s missing? > - It fails some servers (eg: www.google.com) for me while curl works... For www.google.com it fails even without ‘https_proxy’, so that’s OK. :-) > - I think this should go into guile’s ‘(web client)’ module? Yes! Once we’ve committed it Guix, it’d be great if you could a similar patch to bug-gu...@gnu.org. Thank you! Ludo’.
Re: GNU Shepherd 0.6.1 released
Hi Ludo! First, congrats! I saw it describes that "intended for use on GNU/Hurd", is it still workable on GNU/Linux? On Mon, May 13, 2019 at 3:59 PM Ludovic Courtès wrote: > > Hi Arne, > > Arne Babenhauserheide skribis: > > > Ludovic Courtès writes: > > [...] > > >> interface. The GNU Shepherd may also be used by unprivileged users to > >> manage per-user daemons (e.g., tor, privoxy, mcron, etc.) > > > > Is there a tutorial about using shepherd for per-user daemons? I don’t > > really know how to start with it, but I would very much like to > > move services from "just start this in ~/.bashrc" to shepherd. > > There’s no tutorial, but the manual has a couple of examples, and I > think it’s rather easy to get started. > > Cheers, > Ludo’. >
Re: GNU Shepherd 0.6.1 released
Hi Arne, Arne Babenhauserheide skribis: > Ludovic Courtès writes: [...] >> interface. The GNU Shepherd may also be used by unprivileged users to >> manage per-user daemons (e.g., tor, privoxy, mcron, etc.) > > Is there a tutorial about using shepherd for per-user daemons? I don’t > really know how to start with it, but I would very much like to > move services from "just start this in ~/.bashrc" to shepherd. There’s no tutorial, but the manual has a couple of examples, and I think it’s rather easy to get started. Cheers, Ludo’.
Re: Packaging Grisbi
Hi Timothy, Le 05/12, Timothy Sample a écrit : > Tanguy Le Carrour writes: > > I get the following error message: > > > > ``` > > failed to commit changes to dconf: > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: > > The name ca.desrt.dconf was not provided by any .service files > > ``` > > Drat! > > > Installing dconf does not solve the problem, though. > > If you are using GDM, this might be due to the way it (used to) start > D-Bus. See commit dcb3a0fe0a086b4762a721e9b1da64826d5160d0. If you > have not ran “guix pull” in the last four days, doing so might make this > problem disappear. My bad! I'll update my system and try again! > > I also don't know where to put it! In its own `grisbi.scm` file? Or > > alongside gnucash in a new `finance.scm` file? > > We already have a “finance.scm”, which seems appropriate to me. Oups, I did not notice it! I was focused on GnuCash and only saw `gnucash.scm`. Shouldn't it also be in `finance.scm`?! I guess, there's a good reason for it not to be, though! > Hope that helps! Definitively! Thanks! -- Tanguy
