Re: Italian Translation of the Guix Manual
Le Sat, 24 Oct 2020 19:37:02 +0200, Miguel Ángel Arruga Vivas a écrit : Hi! > > It's nice to read this :-) By the way, is it > > possible, if it seems necessary, to modify directly the .po file by > > hand with a simple text editor ? > > Sure, the po format is a text format that can be edited with the means > you estimate best for the task. Good to know ! > Usually higher level tools are more > adequate for the daily work, but a sed command to fix a typo might be > faster sometimes. :-) It is certain that if I learn sed, it will be useful. I find that Guix System is an incentive to improve in bash. > It's cool to understand the tools, even though not all of them are > oriented to the translators, but to the developers and maintainers as > xgettext. They are different points of view of the overall > localization process. > > If you want to learn, the gettext manual might have some outdated > sections, mainly about the translation tools, but there's a lot of > knowledge contained there, and all the info is very useful. Yes, for example, I was able to produce a .pot file, .msg messages and other tricks like displaying the file in the terminal with messages in color... > > It will be a great pleasure for me to contribute with succes, and > > these answers will help me :-) > > Just one more thing: *any contribution is a success*, they push > towards a better system. :-) Again, many thanks for your answer :-) Kind regards, Hubert
Re: Error in package building : error[E0463]: can't find crate for `openssl_src`
On Wed, Oct 21, 2020 at 05:27:16PM +0330, Hamzeh Nasajpour wrote:
> I'm so sorry I had a mistake in the previous package definition, I was in
> testing. Please remove these lines in the previous definition:
> ```
> (substitute* "Cargo.toml"
> (("0.10.30\"" all) "0.10.30\"}# "))
> ```
>
> It means that my package definition is:
> ```
> (define-public python-etebase-py
> (package
> (name "python-etebase-py")
> (version "0.30.0")
> (source
> (origin
> (method url-fetch)
> (uri (pypi-uri "etebase" version))
> (sha256
> (base32
> "1py635aqnxx3jy4x6zffriqi0l9gc2gk06h0ms91k4rs68h0gb0i"))
> (modules '((guix build utils)))
> (snippet
> '(begin
> (substitute* "Cargo.toml"
> (("etebase = " all) "#etebase = "))
> (substitute* "Cargo.toml"
> (("flapigen = " all) "flapigen = \"^0.6.0-pre7\" #"))
I'd add in a substitution here for openssl like this (untested):
;; Don't depend on vendored sources
(("0.10.30.*") "0.10.30\" }\n")
> #t
> (build-system cargo-build-system)
> (arguments
> `(#:tests? #f
> #:cargo-inputs
> (("rust-openssl" ,rust-openssl-0.10)
> ("rust-cpython" ,rust-cpython-0.3)
> ("rust-log" ,rust-log-0.4)
> ("rust-etebase-rs" ,rust-etebase-rs)
> ("rust-flapigen" ,rust-flapigen-0.6)
> ("rust-env-logger" ,rust-env-logger-0.7))
> #:phases
> (modify-phases %standard-phases
>(add-after 'unpack 'patch-env-var
> (lambda* (#:key inputs #:allow-other-keys)
> (let ((openssl (assoc-ref inputs "openssl")))
>(invoke "rm" "setup.py")
>(setenv "RUST_BACKTRACE" "full")
>(setenv "OPENSSL_DIR" openssl))
> #t))
> )))
> (native-inputs
> `(("openssl" ,openssl)
> ("python-msgpack" ,python-msgpack)
> ("python-setuptools-rust" ,python-setuptools-rust)))
> (inputs
> `(("python" ,python)
> ;("rust-etebase-rs" ,rust-etebase-rs)
> ))
> (home-page "https://github.com/etesync/etebase-rs;)
> (synopsis "A python client library for EteSync.")
> (description
> "This module provides a python API to interact with an EteSync
> server.
> It currently implements AddressBook and Calendar access, and supports two-way
> sync (both push and pull) to the server.")
> (license license:gpl3)))
> ```
>
> With above definition, I set the `OPENSSL_DIR` and add `openssl` as input but
> the problem not resolved:
> ```
> phase `patch-cargo-checksums' succeeded after 57.8 seconds
> starting phase `build'
>
>
>
>Compiling autocfg v1.0.1
>Compiling memchr v2.3.3
>Compiling lazy_static v1.4.0
>Compiling regex-syntax v0.6.18
>Compiling libc v0.2.71
>Compiling cc v1.0.58
>Compiling pkg-config v0.3.17
>Compiling bitflags v1.2.1
>Compiling openssl v0.10.30
>Compiling cpython v0.3.0
>Compiling foreign-types-shared v0.1.1
>Compiling cfg-if v0.1.10
>Compiling thread_local v1.0.1
>Compiling foreign-types v0.3.2
>Compiling aho-corasick v0.7.13
>Compiling num-traits v0.2.12
>Compiling regex v1.3.9
>Compiling openssl-sys v0.9.58
> error[E0463]: can't find crate for `openssl_src`
> -->
> /tmp/guix-build-python-etebase-py-0.30.0.drv-0/etebase-0.30.0/guix-vendor/rust-openssl-sys-0.9.58.tar.xz/build/main.rs:6:1
> |
> 6 | extern crate openssl_src;
> | ^ can't find crate
>
> error: aborting due to previous error
>
> For more information about this error, try `rustc --explain E0463`.
> error: could not compile `openssl-sys`.
> warning: build failed, waiting for other jobs to finish...
> error: build failed
> ```
>
>
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: guix import error + New: setting up a jupyterlab environment
Hello Efraim!
On 10/21/20 9:18 AM, Efraim Flashner wrote:
> On Mon, Oct 19, 2020 at 11:12:35PM +0200, Zelphir Kaltstahl wrote:
>> Meanwhile I have managed to run the jupyterlab-server tests, as
>> described in more details here:
>> https://github.com/jupyterlab/jupyterlab_server/issues/128
>>
>> Indeed, in version 1.2.0 the tests fail the same way they fail when I
>> try to create my environment. This means the next thing to fix would
>> probably be to use another version of jupyterlab-server. 1.2.0 is a tag
>> in the jupyterlab-server repository, which _seems_ to be the latest
>> "stable" version, before a lot of alpha, beta, and release-candidate
>> versions follow.
>>
>> I guess I could switch the commit in my `jupyterlab.scm` file to point
>> to a different one?
>>
>> I can change the version to `2.0.0rc1`, but I do not know how the
>> checksum is calculated. The checksum is shorter than what I see on
>> simply PyPI:
>>
>> https://files.pythonhosted.org/packages/79/43/5249be5ee741a93f3fa60823caf9a276cadc3103dae16d6e36cc534fefd8/jupyterlab_server-2.0.0rc1.tar.gz#sha256=733b149c5ab8e50ea5f2897c323047257060e7bf2dc0fa88663181427bec605d
>>
>> and base32 should only make it longer, not shorter.
>>
>> Can you explain how to switch a version manually and calculate the
>> checksum to match another version?
> For a tarball like the one at pythonhosted you'd download the file and
> then run 'guix hash the-file'. If you're using a source code repository
> then from the top level of the repo you'd run 'guix hash --exclude-vcs
> --recursive .', or 'guix hash -rx .' for short. The hash layout that
> Guix uses is the sha256 of the tarball base32 encoded, but with a change
> in the letters used.
>
> For python packages you can specify a version number, so in this case
> it'd be 'guix import pypi jupyterlab_server/2.0.0rc1'. Some other
> importers us the '@' symbol to specify version number and I think some
> don't support using other versions at all.
>
> I don't know how compatible different major versions of
> jupyterlab-server are with each other, so I'd stick with 1.2.0 for now.
This means however, that the check phase will fail, because of the
failing tests in the jupyterlab_server repository on version 1.2.0.
Unless there is a way to disable running those specific tests, I guess
this means, that only getting the tests to pass in the jupyterlab_server
repository will solve the problem?
>> Regards,
>> Zelphir
>>
>> On 10/19/20 8:19 PM, Zelphir Kaltstahl wrote:
>>> Hello Efraim,
>>>
>>> Thanks for your patience! It seems with that I am getting quite far
>>> (at least it feels like making progress, or even being close to have a
>>> working environment), up to the "check phase". There some tests
>>> failing in the "check phase". Here is what I am getting now,
>>> regardless of whether I stick ("python-ipykernel" ,python-ipykernel)
>>> in the native inputs or propagated inputs:
>>>
>>> START
>>> running install_egg_info
>>> Copying jupyterlab_server.egg-info to
>>> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/lib/python3.8/site-packages/jupyterlab_server-1.2.0-py3.8.egg-info
>>> running install_scripts
>>> phase `install' succeeded after 0.3 seconds
>>> starting phase `wrap'
>>> find-files:
>>> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/bin:
>>> No such file or directory
>>> find-files:
>>> /gnu/store/2h44ldpcqqd0q7hqpbcqdavcnbjsibfb-python-jupyterlab-server-1.2.0/sbin:
>>> No such file or directory
>>> phase `wrap' succeeded after 0.0 seconds
>>> starting phase `check'
>>> running "python setup.py" with command "test" and parameters ()
>>> running test
>>> running egg_info
>>> writing jupyterlab_server.egg-info/PKG-INFO
>>> writing dependency_links to jupyterlab_server.egg-info/dependency_links.txt
>>> writing requirements to jupyterlab_server.egg-info/requires.txt
>>> writing top-level names to jupyterlab_server.egg-info/top_level.txt
>>> reading manifest file 'jupyterlab_server.egg-info/SOURCES.txt'
>>> reading manifest template 'MANIFEST.in'
>>> warning: no previously-included files matching '*~' found anywhere in
>>> distribution
>>> warning: no previously-included files matching '*.pyc' found anywhere in
>>> distribution
>>> warning: no previously-included files matching '*.pyo' found anywhere in
>>> distribution
>>> warning: no previously-included files matching '.git' found anywhere in
>>> distribution
>>> warning: no previously-included files matching '.ipynb_checkpoints' found
>>> anywhere in distribution
>>> writing manifest file 'jupyterlab_server.egg-info/SOURCES.txt'
>>> running build_ext
>>> test_get (jupyterlab_server.tests.test_settings_api.SettingsAPITest) ...
>>> ERROR
>>> test_get_bad (jupyterlab_server.tests.test_settings_api.SettingsAPITest)
>>> ... ERROR
>>> test_listing (jupyterlab_server.tests.test_settings_api.SettingsAPITest)
>>> ... ERROR
>>> test_patch
Re: Italian Translation of the Guix Manual
Hi, I answer inline, so I snip a some bits here and there to leave just a bit of context. :-) Hubert Lombard writes: > So I knom I must update my merged 'guix-manual-1.2.0-pre1.fr.po' to > pre2, modify language from 'fr_FR to 'fr' and when I'm done, send it > directly. Cool, you already got it! >> I'm not aware of any other kind of error on the robot side, but >> sometimes they are cryptic, so don't be afraid to ask. There could be >> problems not detected by the robot too, as msgfmt doesn't check the >> texinfo markup, but these usually would be notified directly to you by >> the maintainers of the project. > > It's nice to read this :-) By the way, is it > possible, if it seems necessary, to modify directly the .po file by hand > with a simple text editor ? Sure, the po format is a text format that can be edited with the means you estimate best for the task. Usually higher level tools are more adequate for the daily work, but a sed command to fix a typo might be faster sometimes. :-) > I have tried to learn a few about msgfmt, msgunfmt, msgcat, msgmerge and > xgettext, using them during the process of research, in the last days... > Also, I have the impression that I will have to go into more detail > about gettext and others, before the ...next try ;-) It's cool to understand the tools, even though not all of them are oriented to the translators, but to the developers and maintainers as xgettext. They are different points of view of the overall localization process. If you want to learn, the gettext manual might have some outdated sections, mainly about the translation tools, but there's a lot of knowledge contained there, and all the info is very useful. >> And also, thank you both for stepping up to this task. :-) > > It will be a great pleasure for me to contribute with succes, and these > answers will help me :-) Just one more thing: *any contribution is a success*, they push towards a better system. :-) Best regards, Miguel
Re: problem with common lisp
Adam Kandur skribis: > Hi! thank you for this question. dont have to much knowledge about cpu. i > attached lscpu output. if you find something interesting in it, let me know, > please > > Oct 24, 2020, 16:35 by g...@posteo.net: > >> >> Adam Kandur via skribis: >> >>> hi, i realized that i have this problem with sbcl itself, if i install sbcl >>> in my main profile (without any of my packages, only sbcl from guix >>> channel) i still got this error: >>> >>> fatal error encountered in SBCL pid 1954 tid 1954: >>> Unhandled SIGILL at 0x52000e9d. >>> >> >> Out of curiosity, what does the "lscpu" command return on your machine >> (the flags in particular)? >> According to [1], there is a bug in SBCL 2.0.9 that causes an illegal instruction error on CPUs that support the popcnt instruction but not the AVX instructions. It it the case of your CPU. This bug has been fixed in the master branch of SBCL's repository, so the next version of SBCL (which will be released soon I think) should work on your machine. [1] https://www.reddit.com/r/sbcl/comments/j824cs/does_binary_209_require_some_fancy_x86/ signature.asc Description: PGP signature
Re: problem with common lisp
Hi! thank you for this question. dont have to much knowledge about cpu. i attached lscpu output. if you find something interesting in it, let me know, please Oct 24, 2020, 16:35 by g...@posteo.net: > > Adam Kandur via skribis: > >> hi, i realized that i have this problem with sbcl itself, if i install sbcl >> in my main profile (without any of my packages, only sbcl from guix channel) >> i still got this error: >> >> fatal error encountered in SBCL pid 1954 tid 1954: >> Unhandled SIGILL at 0x52000e9d. >> > > Out of curiosity, what does the "lscpu" command return on your machine > (the flags in particular)? > lscpu Description: Binary data
Re: problem with common lisp
Adam Kandur via skribis: > hi, i realized that i have this problem with sbcl itself, if i install sbcl > in my main profile (without any of my packages, only sbcl from guix channel) > i still got this error: > > fatal error encountered in SBCL pid 1954 tid 1954: > Unhandled SIGILL at 0x52000e9d. Out of curiosity, what does the "lscpu" command return on your machine (the flags in particular)? signature.asc Description: PGP signature
Re: Italian Translation of the Guix Manual
Le Sat, 24 Oct 2020 15:17:25 +0200, Miguel Ángel Arruga Vivas a écrit : > Hi, Hubert and Matias, > > Welcome you both! :-) Hi Miguel! Thank you :-) > What's the message the robot emitting? I'm aware of these problems > common problems: > > * You are not allowed: this has to be solved by the coordinators. > * Problems related to the copyright lines: it checks some patterns and > you have to follow its guidance. > * Problems related to the header: the empty string is special and it > contains information about the translation and plural forms. Same > as before, following its advice is usually enough. > * Problems related to the contents, for that you can run to check it > yourself "msgfmt -o /dev/null LANG.po". The message from the robot, and immediately after the answer of a regular translator from the French team : "Hi! I am the service robot at the Translation Project, and was awakened by one of your submissions. ***> As file name you supplied 'guix-manual-1.2.0-pre2.fr.po.zip'. In this I cannot find the domain name, the version number, nor the team code. The file name should look like 'DOMAINNAME- VERSIONNUMBER.TEAMCODE.po' (all in lowercase). Some error reported above (marked with "***>") prevents me from accepting your PO file. Sorry! But do not hesitate to resubmit your PO file, once you think the problem has been fixed. As a robot I am incredibly patient at these things!" Someone (thanks to him too ;-) from the French translation team answered me: "At least two problems with the headers: the version is not good, it should be updated to 1.2.0-pre2. The language is not good, it must be simply French without precision (fr, not fr_FR)." Then, the safest way is to send the file directly, not in a zip." So I knom I must update my merged 'guix-manual-1.2.0-pre1.fr.po' to pre2, modify language from 'fr_FR to 'fr' and when I'm done, send it directly. > > I'm not aware of any other kind of error on the robot side, but > sometimes they are cryptic, so don't be afraid to ask. There could be > problems not detected by the robot too, as msgfmt doesn't check the > texinfo markup, but these usually would be notified directly to you by > the maintainers of the project. It's nice to read this :-) By the way, is it possible, if it seems necessary, to modify directly the .po file by hand with a simple text editor ? I have tried to learn a few about msgfmt, msgunfmt, msgcat, msgmerge and xgettext, using them during the process of research, in the last days... Also, I have the impression that I will have to go into more detail about gettext and others, before the ...next try ;-) > > And also, thank you both for stepping up to this task. :-) It will be a great pleasure for me to contribute with succes, and these answers will help me :-) > Best regards, > Miguel Kind regards too -- Hubert
Re: problem with common lisp
hi, i realized that i have this problem with sbcl itself, if i install sbcl in my main profile (without any of my packages, only sbcl from guix channel) i still got this error: fatal error encountered in SBCL pid 1954 tid 1954: Unhandled SIGILL at 0x52000e9d. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Oct 21, 2020, 22:51 by zimon.touto...@gmail.com: > Please keep help-guix CC. :-) > > On Wed, 21 Oct 2020 at 23:53, Adam Kandur wrote: > >> hi, i mean that my packages for common lisp are same as one week ago when >> everything worked. also i had same issues with packages from guix channel. >> don't know about guix-deploy >> > > I understand. > > First, since the package you are building is yours, more information > is required to be able to find what is wrong. Idem about your > channel. > > > The questions in my previous email are: > > 1. could you provide the last version of Guix where it "worked"? > 2. could you provide the current version of Guix where it is "broken"? > > The #1 means that you have to: > > a) "guix pull -l | grep guix". This will display all the previous > versions of Guix you had (hoping that you have not deleted by running > "guix gc" with some well-chosen options). > From these versions (hashes), you can run: > > guix time-machine --commit= -- build -L paht/to/your/local/pkg sbcl-foo > > and see which worked and which not. The easiest is to go > anti-chronological (start by your current Guix version and go > backward). > > b) "guix describe" and probably attach the recipe of your broken > package. For example it seems that one of your package is named > "sbcl-deploy" since you have one item in the store named > "/gnu/store/fgfag09f1amsk82bs6jmg9h4rv6hqb94-sbcl-deploy-0.0.0-1.59fd497" > and this package is not in "master", AFAICT. > > > All the best, > simon >
help with cyrillic in games
hi everyone! i cannot type cyrillic chars in games (for example in xonotic). it refuses to print out any chars when i change layout
Re: Packaging a python package that is using setuptools_rust
Am 19.10.20 um 12:52 schrieb Hamzeh Nasajpour:
> running build_rust
> error: [Errno 2] No such file or directory: 'cargo'
> command "python" "-c" "import setuptools,
> tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\\r\\n',
> '\\n');f.close();exec(compile(code, __file__, 'exec'))" "build" failed with
> status 1
This looks like cargo is not found on the path, although it should be
there. You could validate $PATH like this: Add a phase before the
build-phase, containing just "(pk (getenv PATH))".
> Do you have any idea? I should add the rust dependencies to `native-inputs`
> or `inputs` of `etebase-py`?
It must be a native-input, since cargo and rustc are expected to run on
the build system.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: Italian Translation of the Guix Manual
Hi, Hubert and Matias, Welcome you both! :-) Just some comments as a fellow translator. Hubert Lombard writes: > I am now subscribed to the Translators mailing list. I have used > Gtranslator but I think POedit is better. I use po-mode for Emacs (it comes with gettext), but any tool that provides some kind of automatic spell-checking helps a lot, at least with typos. > 2) I haven't used weblate but just the TP by sending my translation in > an attachment file 'guix-manual-1.2.0-pre2.fr.po' to > ro...@translationproject.org. > > In my case, I have not yet succeeded in passing the robot test (a > returned email from the robot saying it's not OK yet. I must try again). What's the message the robot emitting? I'm aware of these problems common problems: * You are not allowed: this has to be solved by the coordinators. * Problems related to the copyright lines: it checks some patterns and you have to follow its guidance. * Problems related to the header: the empty string is special and it contains information about the translation and plural forms. Same as before, following its advice is usually enough. * Problems related to the contents, for that you can run to check it yourself "msgfmt -o /dev/null LANG.po". I'm not aware of any other kind of error on the robot side, but sometimes they are cryptic, so don't be afraid to ask. There could be problems not detected by the robot too, as msgfmt doesn't check the texinfo markup, but these usually would be notified directly to you by the maintainers of the project. And also, thank you both for stepping up to this task. :-) Best regards, Miguel
Re: Italian Translation of the Guix Manual
Hi Matias! I try to become a new contributor too, for the french translation of the guix manual. 1) I subscribed to the 2 mailing lists 'Traduc' and to 'Traduc.po' I am now subscribed to the Translators mailing list. I have used Gtranslator but I think POedit is better. 2) I haven't used weblate but just the TP by sending my translation in an attachment file 'guix-manual-1.2.0-pre2.fr.po' to ro...@translationproject.org. In my case, I have not yet succeeded in passing the robot test (a returned email from the robot saying it's not OK yet. I must try again). To facilitate the sending of a PO file, the TP provides a script for this purpose: translationproject.org/extra/sendpo.sh . The exact way to process the robot is explained at translationproject.org/html/robot.html I hope this helps. Good continuation and thank you for wanting to help ! Cheers Hubert Le Sat, 24 Oct 2020 12:46:43 +0200, Matias Jose Seco Baccanelli a écrit : > Hello! > I've found really useful pointers: > https://lists.gnu.org/archive/html/guix-devel/2020-08/msg8.html > > My main curiosity it's if we should use the TP or Weblate facility, > since i was reading a migration was planned. > > Thanks, > Matias > > On Sat, 24 Oct 2020 12:14:43 +0200 > Matias Jose Seco Baccanelli > wrote: > > > Greetings, > > i'd really like to contribute on the Italian > > translation for the Guix Manual. > > I've red that other participants were also interested on this task, > > i may join them for team play! > > I've found various mails related to preparing the translation, is > > there any resource giving an overview of the needed steps, or may i > > ask you suggestions to get on track :) ? > > > > Thank you very much, > > have a nice Guix day, > > Matias > > > > --
Re: Italian Translation of the Guix Manual
Le 24 octobre 2020 06:46:43 GMT-04:00, Matias Jose Seco Baccanelli a écrit : >Hello! >I've found really useful pointers: >https://lists.gnu.org/archive/html/guix-devel/2020-08/msg8.html Yes, you should follow advice in this email. Contact your team as they can alvise you better. Once you're part of the Italian team, you can start translating. Since there is no current translation for italian, you should download the pot file (at the top of the page: https://translationproject.org/domain/guix-manual.html) and use it in your favorite translation software (poedit, gtranslator, emacs' po mode, offlate, …). Once you are ready, please send the resulting po file to the robot. We'll take care of the rest. You will find more information at https://translationproject.org/html/translators.html Note that we do not require a disclaimer for translating guix, so you can start right away. > >My main curiosity it's if we should use the TP or Weblate facility, >since i was reading a migration was planned. Please use the TP for this release, as the migration is taking a lot more time than expected. > >Thanks, >Matias > >On Sat, 24 Oct 2020 12:14:43 +0200 >Matias Jose Seco Baccanelli >wrote: > >> Greetings, >> i'd really like to contribute on the Italian >> translation for the Guix Manual. >> I've red that other participants were also interested on this task, i >> may join them for team play! >> I've found various mails related to preparing the translation, is >> there any resource giving an overview of the needed steps, or may i >> ask you suggestions to get on track :) ? >> >> Thank you very much, >> have a nice Guix day, >> Matias >>
Re: Italian Translation of the Guix Manual
Hello! I've found really useful pointers: https://lists.gnu.org/archive/html/guix-devel/2020-08/msg8.html My main curiosity it's if we should use the TP or Weblate facility, since i was reading a migration was planned. Thanks, Matias On Sat, 24 Oct 2020 12:14:43 +0200 Matias Jose Seco Baccanelli wrote: > Greetings, > i'd really like to contribute on the Italian > translation for the Guix Manual. > I've red that other participants were also interested on this task, i > may join them for team play! > I've found various mails related to preparing the translation, is > there any resource giving an overview of the needed steps, or may i > ask you suggestions to get on track :) ? > > Thank you very much, > have a nice Guix day, > Matias >
Italian Translation of the Guix Manual
Greetings, i'd really like to contribute on the Italian translation for the Guix Manual. I've red that other participants were also interested on this task, i may join them for team play! I've found various mails related to preparing the translation, is there any resource giving an overview of the needed steps, or may i ask you suggestions to get on track :) ? Thank you very much, have a nice Guix day, Matias
Re: Guix: The Platform Harmonizer
On Thu, 22 Oct 2020 00:10:45 +0200 Ludovic Courtès wrote: > Hi Matias, :-) > > Julien Lepiller skribis: > > > Thank you for this presentation, it's really great! > > +1, a refreshing perspective! > > Thanks, > Ludo’. Thank you very much! It was really delightful to do this presentation. Matias
Re: guix environment ad-hoc manifests
Dear Simon, On Thu, 22 Oct 2020 18:22:46 +0200 zimoun wrote: > From my understanding, as Ricardo said, the command: > >guix environment -m my-manifest.scm > > is equivalent to: > > guix environment --ad-hoc pkg1 pkg2 pkg3 > Thanks for your response. yes this is exactly what I was looking for. just from the "Guix Environment" document: > Create an environment for the packages contained in the manifest > object returned by the Scheme code in file. I assumed that manifest packages, would be acted like: guix environment pkg1 pkg2 which it seems that I was wrong. Thanks Reza -- Reza Alizadeh Majd PantherX Team https://www.pantherx.org/
Re: guix environment ad-hoc manifests
On Thu, 22 Oct 2020 17:16:21 +0200 Ricardo Wurmus wrote: > > yes, a possible use-case would be to provide a development > > environment for a software which is not packaged yet. during > > development phase, we could easily update this manifest file and > > include third-parties we need to use. > > But isn’t this exactly what you can use a manifest file for already? > “guix environment” not only accepts a file that describes a package, > but also a manifest. > Thank you for your response, there is just a point that I don't understand. - when we add a package to environment, all of package inputs will be added to the environment. - using --ad-hoc switch, package itself will be present in environment. now I want to know add a series of packages using --manifest, add them directly to the environment (like --ad-hoc), or add inputs for each package to environment? Thanks Reza -- Reza Alizadeh Majd PantherX Team https://www.pantherx.org/
