Re: Encrypted Images?
Hi Christopher, Christopher Howard writes: > Hi, I've recently starting learning how to use `guix system image', > and have learned enough to create one raw image which I was able to > copy onto a hard drive on another computer. > > I am wondering if it is possible to use `guix system image' to create > an image that is luks encrypted, with the other file systems and OS > installed on that. If not, can I setup an luks-encrypted image > manually and then have guix system install to that somehow, without > having to boot up into an installer disc and run through all the > installation steps? > > I see documentation in the manual for the luks target, of course, but > I am unclear on how that ties into guix system image and how much guix > system is able to do on its own. It's not currently possible; 'guix system' doesn't offer much in terms of declaring partitions layouts, creating file systems, LUKS layers, etc. -- Thanks, Maxim
Re: Why bash-minimal is part of sbcl package
Hi Felix, Felix Lechner writes: > Hi Maxim, > > On Tue, Dec 12 2023, Maxim Cournoyer wrote: > >> it means bash-minimal should be explicitly added to the inputs, >> otherwise when cross-building the package for another architecture the >> native bash captured wouldn't be executable on the target. > > The core-updates branch has a lot of new 'bash-minimal' additions, > presumably for cross-building. Maybe this is a good opportunity to ask > about something I have been working on. > > As part of a broader effort to make development in scripting language > like GNU Guile easier, I rewrote the executable wrapper so that it uses > Guile instead of Bash. My initial hope was that the Guile wrapper could > use /run/current-system/profile/bin/guile (and thereby avoid an explicit > Bash prerequisite) but it is only available on Guix System. Yes, the problem with that would be portability when using anything but a Guix System machine. > My Guile wrapper will eventually reach you as part of a proposal to > migrate Guix from the Automake build system to my very own Bespoke, > which is likewise written in Guile. Meanwhile, please let me know if > there is any use for a Guile wrapper (instead of Bash). Thanks! Sounds fun! You may be interested in looking at 'wrap-script', which already leverages Guile for use in wrappers. -- Thanks, Maxim
Re: Why bash-minimal is part of sbcl package
Hi, Pan Xie writes: > Hello > > I find this interesting thing but I don't have an explanation. When > query the "references" of my Gnu Store item "sbcl", it shows that sbcl > references bash-mininal, as the following output shows: [...] > So the question is, which part of sbcl's package definition tells Guix > it need to add bash-minimal as part of sbcl? Is there a practical > method to figure that out? A bunch of core commands such as bash, sed, make etc. are implicitly included in the build environment by the GNU build systems (which most other build systems simply extend). So if there's a bash shebang somewhere, the patch-source-shebang phase may substitute it to the *native* implicit bash command found in the environment, thus keeping a reference to it. That's a bug, as it means bash-minimal should be explicitly added to the inputs, otherwise when cross-building the package for another architecture the native bash captured wouldn't be executable on the target. -- Thanks, Maxim
Re: documentation on copyright headers?
Hi, Simon Tournier writes: > Hi, > > On Thu, 16 Nov 2023 at 15:39, Wilko Meyer wrote: > >> - why a copyright header has to be inserted >> - if a copyright header has to be inserted for all files that are >> subject to changes (is there a treshold? can it be left out for minor >> changes to files etc.?) of a sent patch. > > As a rule of thumb, each time your change is non-trivial – say more than > 5 modified or new lines in one specific file – it deserves a Copyright > header on that specific file. Note that deleting only does not count, > i.e., Copyright does not apply > > In the past, the project had been very permissive, where even 2 lines > only modifying the version and checksum fields lead to hold a Copyright > on such modification. Now, it should be avoided, IMHO. I think it should be avoided as well, the long list of copyrights are already a bit messy to maintain across trees :-). info '(maintain) Legally Significant' offers as advice that changes of 15 lines or less or not legally significant for copyright. -- Thanks, Maxim
Re: Turning off tests leads to a different store item
Hi,
Simon Tournier writes:
> Hi Maxim,
>
> On Thu, 09 Nov 2023 at 10:04, Maxim Cournoyer
> wrote:
>
>>> I agree. On a side note, one of the issue is the time of some tests.
>>> Sometimes, packaging is frustrating: build takes ages, then you fix some
>>> tests, think it will be good, re-launch “guix build”, another test
>>> failing, repeat. It could nice to be able to cache the result of the
>>> build phase.
>>
>> I usually end up working in the /tmp/guix-build-* failed build of a
>> package for these situations; then I don't need to rebuild the whole
>> thing for each test suite run, and can test changes directly without
>> proper patches while working toward a fix.
>
> Do you know all the command lines equivalent for each phase run by all
> the build systems? ;-)
It depends of the build system, but for gnu-build-system, it's typically
just sourcing environment-variables then running 'make check', I think.
Note that 'live' environment variables are captured in the
'environment-variables' file, which is handy.
> Well, this workflow seems appealing but it never works for me on
> concrete situations. Most of the time, my issue does not come from
> “what to do from command line” but “how to do it inside the Guix
> recipe”.
>
> For example, this test suite adjustment:
>
> (add-before 'install 'disable-network-tests
> (lambda _
> (substitute* "test/runtests.jl"
> (("\"async.jl") "# \"async.jl")
> (("\"client.jl") "# \"client.jl"))
[...]
> (("@testset.*Set-Cookie casing.*" all)
> (string-append all "return\n"
>
> To have the correct replacement rules, I almost never get it right at
> the very first try, and the feedback loop is poor. In some case, the
> replacement is done after 'unpack, so I can just kill the build process
> and check inside /tmp/guix-build-* if the output is the expected one.
I've used 'guix repl' in a failed build before, running the same
commands directly in the tree to observe their effects (e.g.,
substitutions) directly.
--
Thanks,
Maxim
Re: Guarantee of no broken dependencies?
Hi Peter, Peter Polidoro writes: > For every commit to the Guix master branch, is there a guarantee that > there are no packages with broken dependencies? There's no strong guarantee; we rely on people having well tested their changes and reviewing what QA had to say about it. Any unexpected breakage can be caught by Cuirass notifications and hopefully acted on quickly. In the future, we'd want to have QA and or Cuirass gate the merge, to ensure the change (and all impacted packages) were properly built before being merged. > I have not experienced packages with broken dependencies, so I am > curious how that is checked. In theory, someone could make a commit > that accidentally breaks other packages correct? Aren’t most inputs > just found by name, not name and version or hash? The inputs are referenced exactly, via their Scheme variable name. > Do packages not get broken, though, because right before every commit > the updated package is built, along with every package that depends on > the updated package? Is that enough to make sure all dependencies are > fine? There are no race conditions with other people making updates at > the same time? No race condition, thanks to Git; but after rebasing a change on master, it should be rebuilt and retested ideally. > How can we do such a consistency check or have such a guarantee when > we use multiple channels? Does we just rebuild every package in every > non-Guix channel every time we update Guix to find out what breaks? I'd suggest setting up a private Cuirass instance testing your channel. That's actually easier painful than it sounds. -- Thanks, Maxim
Re: Turning off tests leads to a different store item
Hi Simon, Simon Tournier writes: [...] >> I think the lower fruits are in looking at making the test suite of the >> few common offenders more robust (using libfaketime or the likes) to >> prevent (re)occurrences of time bombs in the future. > > I agree. On a side note, one of the issue is the time of some tests. > Sometimes, packaging is frustrating: build takes ages, then you fix some > tests, think it will be good, re-launch “guix build”, another test > failing, repeat. It could nice to be able to cache the result of the > build phase. I usually end up working in the /tmp/guix-build-* failed build of a package for these situations; then I don't need to rebuild the whole thing for each test suite run, and can test changes directly without proper patches while working toward a fix. -- Thanks, Maxim
Re: Turning off tests leads to a different store item
Hi, Simon Tournier writes: > Hi, > > On Wed, 8 Nov 2023 at 20:20, Saku Laesvuori wrote: > >> There is another way: simply preventing the tests from changing the >> resulting store item. For example, the package could first be built >> without tests and then that build tree could be copied to the build tree >> of the build with tests enabled. > > Somehow, the store would need to keep all the build intermediary > artifacts produced, right? For instance, consider the extreme case > where the build phase produces .o artifact files and the tests for > whatever reasons relies on these temporary artifacts. > > Well, we had a quick chat with Josselin and Andreas about separating > the tests at https://hpc.guix.info/events/2023/workshop/program/ > And my understanding of the rough conclusion we had: it is not easy > and the evil are in all the details. For example autotools: somehow > "make check" is connected in one way or the other to "make" and/or > "make install". Somehow, the complete build tree (with intermediary > artifacts as .o) should keep in the store. > > From a pragmatical point of view, there is packages where the tests > cannot be totally separated from from the temporary build, therefore > the question seems: how do these cases compare to the other regular > cases? What is the ratio? Is the rule about many corner cases > without a clear "regular"? Or are they just few corner cases? One easy-ish way, which would be kind of ugly because coupled to the specific file system capabilities (e.g Btrfs), would be to leverage CoW features and create a Btrfs snapshot at the beginning of the test suite, and reverting to it after it's run. But even that is not fullproof; that'd only protect the build directory, say, not the store location (some check phases are moved after installation). I agree it looks tricky to get it right (and even trickier to prove/test for it) :-). I think the lower fruits are in looking at making the test suite of the few common offenders more robust (using libfaketime or the likes) to prevent (re)occurrences of time bombs in the future. -- Thanks, Maxim
Re: Turning off tests leads to a different store item
Hi Felix, Felix Lechner writes: > Hi, > > On Tue, Nov 07 2023, Maxim Cournoyer wrote: > >>> Felix Lechner via writes: >>> >>>> Those shortfalls are a consequence of our packaging habits. In an ideal >>>> world, would running a test suite ever build a different derivation? >> >> You seem to be confusing 'derivation', which is the build recipe >> description that a package "compiles" to, with the package output, the >> result of executing the derivation. [...] > A source tree should produce the same derivation regardless of whether > build-time tests ran or didn't. It should also pull the same substitute. A source tree doesn't produce a derivation. A derivation is the complete build recipe that captures the source and the package definition, that when built by the daemon produces a store item. Earlier in the thread, I've mentioned that running a test suite can have side effects such as happened in the past in Python with timestamps being written to the loaded .pyc files when running test suites; we can't ensure the test suite has no side-effects on the rest of the package, so we can't simply assume building with #:tests? #f produces the same as when building with #:tests? #t. And to come back to the original idea: building with the tests run makes sense for a distribution -- it's one of the rare things we have at our disposal to ensure things are properly integrated and keep working. -- Thanks, Maxim
Re: Turning off tests leads to a different store item
Hi, Suhail writes: > Felix Lechner via writes: > >> On Tue, Oct 31 2023, Julien Lepiller wrote: >> >>> You could skip tests, but that would build a different derivation >>> tree, so it might affect reproducibility >> >> Those shortfalls are a consequence of our packaging habits. In an ideal >> world, would running a test suite ever build a different derivation? You seem to be confusing 'derivation', which is the build recipe description that a package "compiles" to, with the package output, the result of executing the derivation. While I wouldn't expect the package output to change unless tests are installed when disabling the test suite, the derivation changes to account for the different build arguments used (e.g. that #:tests? #t vs #:tests? #f). Running tests *may* cause the output derivation to be different. I remember a bug in Python that would cause some time stamps to be embedded in the .pyc when running the test suite (!). I think it's safer to assume that a derivation with test enabled is not the same as a derivation with tests disabled. There was the "Intensional Store" RFC in Nix that tried to address that [0]; it may be worth reading but it looks like it comes with a lot of caveats and complexity. [0] https://github.com/NixOS/rfcs/pull/17 -- Thanks, Maxim
Re: Stuck installing guix package manager on Fedora with selinux
Hi, Alexis Simon writes: > Hi, > > So trying to prepare a patch, I realized those changes are already in > master. So that's the reason I didn't get them in the normal stable > release install. Ah! You could try installing from a development snapshot instead. -- Thanks, Maxim
Re: Stuck installing guix package manager on Fedora with selinux
Hello, Alexis Simon writes: > Ok I think I'm starting to get somewhere > > those are the changes that were needed in the selinux policy to be > able to start installing a package > > == > diff --git a/guix-daemon.cil b/guix-daemon.cil > index 3994e62..c26ed1a 100644 > --- a/guix-daemon.cil > +++ b/guix-daemon.cil > @@ -202,7 +202,7 @@ >sys_admin))) >(allow guix_daemon_t > fs_t > - (filesystem (unmount))) > + (filesystem (unmount remount))) >(allow guix_daemon_t > devpts_t > (dir (search))) > @@ -308,6 +308,8 @@ > (lnk_file (read))) >(allow guix_daemon_t NetworkManager_var_run_t > (dir (search))) > + (allow guix_daemon_t init_var_run_t > + (dir (search))) > >;; Access to profiles >(allow guix_daemon_t > = > > I'll try it out more and update as I go along. Sounds good, keep us posted! When you have reached a point you are satisfied with, please email your patch to guix-patc...@gnu.org. -- Thanks, Maxim
Re: -v, --verbosity=LEVEL use the given verbosity LEVEL
Hi, Simon Tournier writes: > Hi, > > On Tue, 26 Sep 2023 at 12:19, Maxim Cournoyer > wrote: > >>> Where should the user of the Guix command-line interface be expected >>> to read about the verbosity LEVEL argument that they can pass to >>> `--verbosity` and that is also valid? > > To answer a question elsewhere in this threads, I think these levels > come from Nix and daemon side. > >> See info '(guix) Invoking guix build': >> >> --8<---cut here---start->8--- >> ‘-v LEVEL’ >> ‘--verbosity=LEVEL’ >> Use the given verbosity LEVEL, an integer. Choosing 0 means that >> no output is produced, 1 is for quiet output; 2 is similar to 1 but >> it additionally displays download URLs; 3 shows all the build log >> output on standard error. >> --8<---cut here---end--->8--- > > Maybe, we could add an option as ’--list-verbosity’ which would display > that information. > > Well, the main issue, IMHO, is that the option ’--verbosity’ is not > shared across various command-line scripts, but implemented script per > script, IIRC. Oh, is it? That's not great. I've never used it, but Guix already soft-depends on guile-lib, and guile-lib provides a logging library. Perhaps if we used that we would benefit from some standardized and global way to perform logging across at least the host-side code? And that'd help more straightforwardly reason and explain the levels? I have experience with logging from Python and would like to have a similar tool available in Guix. Instead of adding pk all over the place when debugging enabling the debug level (assuming we've added a few well placed debug level logging directives in the code) would help trace execution and pinpoint where things go wrong easily. -- Thanks, Maxim
Re: Question regarding qmk firmware
Hi, Peter Polidoro writes: > On Sunday, October 8th, 2023 at 10:28, Ekaitz Zarraga > wrote: > >> There are other ways to do it, but I find this the easiest. >> You can even make a package for your firmware and let guix compile >> it for you (and maybe flash it too?). > >> Cheers, >> Ekaitz > > I am also interested in using Guix packages for firmware projects. > > Do you have any links to example firmware projects that package, > compile, and flash firmware to embedded boards? Our 'qmk' package now contains all that is needed to build Arduino based firmwares, and you can also use the 'qmk-make-firmware' procedure to generate a customized firmware. For my ErgoDox keyboard, I use the following: --8<---cut here---start->8--- (use-modules (gnu packages firmware) (guix gexp)) (define-public qmk-firmware-dvorak-emacs-software-custom (make-qmk-firmware "ergodox_ez" "dvorak_emacs_software_custom" #:keymap-source-directory (local-file "dvorak_emacs_software" #:recursive? #t))) qmk-firmware-dvorak-emacs-software-custom --8<---cut here---end--->8--- where 'dvorak_emacs_software' is a directory containing keymap.c and supporting files. -- Thanks, Maxim
Re: Guix Home: SSH won't ask for GPG password
Hi Caleb, Caleb Herbert writes: > Maxim Cournoyer wrote .. >> I now use the canonical 'pinentry' package, which seems most featureful. > > Changed to plain "pinentry". > > (service home-gpg-agent-service-type > (home-gpg-agent-configuration >(pinentry-program > (file-append pinentry "/bin/pinentry")) >(ssh-support? #t))) > > > I still get an error when trying to reconfigure. What do you mean by "still" ? It must have worked at some point? What changed in your configuration? > Loading /gnu/store/2hwp7i1xn24rlsnwmcc8hpbdynznv4an-shepherd.conf. > herd: error: exception caught while executing 'load' on service 'root': > In procedure fport_write: Input/output error > Comparing > /gnu/store/3jphbp9sisp54nshd8dimrnn4lks3p4d-home/profile/share/fonts and > > /gnu/store/vkkl9ymxkcq5a72z42rm4yx573k0wk1f-home/profile/share/fonts... done > (same) > Evaluating on-change gexps. > > On-change gexps evaluation finished. Hm. I'm not sure what that is trying to say, other than there was some error in the service definition. -- Thanks, Maxim
Re: Guix Home: SSH won't ask for GPG password
Hi, Caleb Herbert writes: > Guix System. > > In home-configuration.scm: > (service home-gpg-agent-service-type > (home-gpg-agent-configuration > (pinentry-program > (file-append pinentry-gnome3 "/bin/pinentry")) > (ssh-support? #t))) > > caleb@bender ~$ ssh c...@tty.sdf.org > c...@tty.sdf.org's password: > > This shouldn't happen. Pinentry should come up and ask me for my GPG password. > > gpg-agent.conf looks normal. > > caleb@bender ~$ cat /home/caleb/.gnupg/gpg-agent.conf > pinentry-program > /gnu/store/6rlqjdc9ginn4gnkwg8mhqwm015phhrm-pinentry-gnome3-1.2.1/bin/pinentry > default-cache-ttl 600 > max-cache-ttl 7200 > default-cache-ttl-ssh 1800 > max-cache-ttl-ssh 7200 I don't use guix home, but my hand-crafted gpg-agent.conf reads like: --8<---cut here---start->8--- # PIN entry program enable-ssh-support allow-emacs-pinentry # Remember GPG/SSH passwords for longer. default-cache-ttl 28800 # cache GPG on access for 8 hours max-cache-ttl 57600 # keep GPG on cache for a maximum of 16 hours default-cache-ttl-ssh 28800 # cache SSH on access for 8 hours max-cache-ttl-ssh 57600 # keep SSH on cache for a maximum of 16 hours --8<---cut here---end--->8--- Also, it could be caused by the pinentry-gnome3 variant. I remember wrestling with a similar problem in the past, only to find out that it was limited. I now use the canonical 'pinentry' package, which seems most featureful. HTH, -- Maxim
Re: -v, --verbosity=LEVEL use the given verbosity LEVEL
Hello, "jgart" writes: > Hi Maxim, > > Thanks for the reply and info. > > I don't mind doing the work to find out exactly what is being logged > with deep understanding of Guile/Guix's logging mechanism. A bird's > eye view while still understanding the low level and commenting on it. > > It will require some time to do that research and write a good explanation. > > I'm in no rush so I will try unless someone else gets to it first. > > Might be good to talk with the person who wrote that logging to > discuss the information and concepts involved in the context of guile > and guix. There might have been some discussion on guix-devel (you can search through the archives); otherwise I believe it was implemented by Ludovic. -- Thanks, Maxim
Re: -v, --verbosity=LEVEL use the given verbosity LEVEL
Hi, "jgart" writes: >> 1 is for quiet output; 2 is similar to 1 but it additionally displays >> download URLs; > >> it additionally displays > > I think it is confusing to use the word "additionally" here as there is > nothing that we know about the quiet output for the description that let's us > then conceptualize what will be added to it. > > In other words, level 1 should be described with more detail than "1 is for > quiet output". > > What should we expect to see in the content of verbosity level 1 in general. > > I would have to find the time to conduct some empirical usages with the > --verbosity flag to answer that question succinctly and in the general across > guix subcommands beyond just describing it as "quiet output". > > WDYT, nitpick? maybe/maybenot I agree it can be improved, but I'd also have to read the code to know what each level exactly do. I think it could make things simpler to use nouns for the level, as they could mean something without having to be explained to verbosely, e.g.: debug (very verbose) info (include some extra messages) warning (warnings and errors -- the default level) error (errors only) Basically like what the levels of the 'logging' Python library are expected to do, which the logging library included with guile-lib is inspired by. -- Thanks, Maxim
Re: -v, --verbosity=LEVEL use the given verbosity LEVEL
Hi, "jgart" writes: > Hi Maxim, > > That's awesome documentation! Thanks for doing that. Approved. > Do you want to merge this? There seems to be a misunderstanding; it's already documented. If you run the info command I shared you'll see I copied the text from there. -- Thanks, Maxim
Re: -v, --verbosity=LEVEL use the given verbosity LEVEL
Hi jgart, "jgart" writes: > Hi Guixers, > > Where should the user of the Guix command-line interface be expected > to read about the verbosity LEVEL argument that they can pass to > `--verbosity` and that is also valid? See info '(guix) Invoking guix build': --8<---cut here---start->8--- ‘-v LEVEL’ ‘--verbosity=LEVEL’ Use the given verbosity LEVEL, an integer. Choosing 0 means that no output is produced, 1 is for quiet output; 2 is similar to 1 but it additionally displays download URLs; 3 shows all the build log output on standard error. --8<---cut here---end--->8--- -- Thanks, Maxim
Re: Encrypted install in VM stuck in GRUB
Hi! Le 14 septembre 2023 12:41:53 GMT-04:00, David Lecompte a écrit : >> > Now, I need to find out how to change [the keyboard layout to type the >> > passphrase in GRUB], and also to make it so that I can retype the >> > passphrase without going to a grub rescue prompt. >> >> We could track this as two separated Guix bugs, if they haven't already >> been reported. > >I found https://issues.guix.gnu.org/39632 for the keyboard layout issue for >the decryption passphrase in grub and also https://issues.guix.gnu.org/49435 >which is making a suggestion about how to address it. > >I could not find any existing issue for being able to retype the decryption >passphrase in grub without going to the grub rescue prompt. Should I send an >email to bug-guix for that? Thanks for researching passed issues! Yes, please ooen a newly issue for the decryption passphrase retry. Maybe such an issue also exists in the GRUB bug tracker; if so we can cross-reference them Maxim
Re: Encrypted install in VM stuck in GRUB
Hi! Le 14 septembre 2023 09:09:58 GMT-04:00, David Lecompte a écrit : > >> That is the same error message I get after mistyping my password. I'm >> also quite sure the layout is US qwerty before unlocking the encryption >> regardless of any keyboard layouts defined in the system configuration. > >Thanks, I can confirm that it works if I am assuming US qwerty layout! > >Now, I need to find out how to change that, and also to make it so that I >can retype the passphrase without going to a grub rescue prompt. We could track this as two separated Guix bugs, if they haven't already been reported. I agree the user experience for decrypting the disks leaves much to be desired. Maxim
Re: Plugin Package Paths
Hi Peter, Peter Polidoro writes: > Maxim Cournoyer writes: > >> These programs should be patched to honor e.g. FREECAD_PLUGINS_PATH >> or >> similar. Then a 'native-search-path' specification can be attached >> to >> the freecad packaged, and finding freecad plugins will happen in any >> profile. >> >> The FREECAD_PLUGINS_PATH should be written with the intent of >> upstreaming it (sharing it for inclusion with upstream), as that >> should >> be valuable to other distributions/scenarios as well. > > Thanks. I have reached out to both the kicad and freecad communities > about adding support for environment variable options in the search > paths, but so far people from both communities seem skeptical. > > Do you know of any examples of other projects doing this properly in > Python and C++ that I can show to these communities? Developers only accustomed to file hierachy standard (FHS) systems will indeed need some rationale to be convinced. I think snapcraft may be an environment where such support could be useful, I'm not so sure. At least NixOS is another non-FHS system that would benefit from a plugins search path. > Both programs search for the executable path, then base other system > search paths relative to this root path. In general, do you think it > is better to use an environment variable to set the root to the > profile directory or to be more narrow and just specify the plugin > path or paths if the program uses more than one? In general it's better to be precise; this way the search paths in Guix can match only what's needed, and it means less scanning of the file system to do. > I am guessing it may take a while, if ever, to get such changes > included in the upstream projects. In the mean time, is it considered > bad practice to attempt to just patch the source code in the Guix > package? In the mean time it's OK to have them live as patches in the Guix tree, as they are needed :-). -- Thanks, Maxim
Re: Plugin Package Paths
Hi, Peter Polidoro writes: > What is the proper way to package plugins when a packaged program > searches for them in the executable path rather than the profile path? > > I would like to package plugins for two programs, kicad and freecad, > and they both search for plugins by first finding the path of the > executable. Freecad uses /proc/self/exe and kicad uses > wxStandardPaths::GetExecutablePath. This seems to cause them to look > for plugins in the package path in the store rather than the profile > path. > > What is the proper way of handling this when packaging plugins? Should > the package of the main program modify the source code to find the > path of the executable using the environment variable GUIX_ENVIRONMENT > rather than /proc/self/exe or wxStandardPaths::GetExecutablePath? Or > can these calls be tricked with hard links somehow? Or is there some > other better way of dealing with this? These programs should be patched to honor e.g. FREECAD_PLUGINS_PATH or similar. Then a 'native-search-path' specification can be attached to the freecad packaged, and finding freecad plugins will happen in any profile. The FREECAD_PLUGINS_PATH should be written with the intent of upstreaming it (sharing it for inclusion with upstream), as that should be valuable to other distributions/scenarios as well. -- Thanks, Maxim
Re: problem trying to install python module in python virtual environment on top of Guix
Hi Andy, Andy Tai writes: > Hi, on a Guix system I tried to install python dependencies in a > python virtual environment. I installed Guix packages > python-toolchain and python-virtualenv, and use the basic python > commands virtualenv and pip3 to go ahead and install dependencies in a > typical python manner. > > I got one error in a dependencies that tried to build C modules which > involves using cmake in this python environment: (not the system cmake > but something python stuff installed as part of its process): > > Building wheels for collected packages: llama-cpp-python > Building wheel for llama-cpp-python (pyproject.toml) ... error > error: subprocess-exited-with-error > > × Building wheel for llama-cpp-python (pyproject.toml) did not run > successfully. > │ exit code: 1 > ╰─> [9 lines of output] > Traceback (most recent call last): > File > "/tmp/pip-build-env-44zbk4iu/overlay/lib/python3.10/site-packages/skbuild/setuptools_wrap.py", > line 645, in setup > cmkr = cmaker.CMaker(cmake_executable) > File > "/tmp/pip-build-env-44zbk4iu/overlay/lib/python3.10/site-packages/skbuild/cmaker.py", > line 148, in __init__ > self.cmake_version = get_cmake_version(self.cmake_executable) > File > "/tmp/pip-build-env-44zbk4iu/overlay/lib/python3.10/site-packages/skbuild/cmaker.py", > line 105, in get_cmake_version > raise SKBuildError(msg) from err > > Problem with the CMake installation, aborting build. CMake > executable is > /tmp/pip-build-env-44zbk4iu/overlay/lib/python3.10/site-packages/cmake/data/bin/cmake > [end of output] > > note: This error originates from a subprocess, and is likely not a > problem with pip. > ERROR: Failed building wheel for llama-cpp-python > Failed to build llama-cpp-python > ERROR: Could not build wheels for llama-cpp-python, which is required > to install pyproject.toml-based projects > > [notice] A new release of pip is available: 23.1.2 -> 23.2.1 > [notice] To update, run: pip install --upgrade pip > > > wonders if anyone knows if the above can be attempted on top of Guix; > not sure if the C build environment can be seen properly under Python > virtualenv I've had success in the past using the --emulate-fhs option in a containerized shell, but the better option would be to package what you need in Guix proper. > Also the Python tools packaged in Guix seem rather old, and tat can be > part of the issue here. I'm sure the Python team would welcome new members :-). -- Thanks, Maxim
Re: error: %guix-register-program: unbound variable on guix time-machine
Hi Simon, Simon Tournier writes: > Hi Maxim, > > On Wed, 31 May 2023 at 21:15, Maxim Cournoyer > wrote: >> Hello, >> >> Attempting to navigate to a relatively distant past (Wed Jan 25 23:42:11 >> 2017 -0500) with commit 9b9e147117e6009451d7acc1f8f156e041263e32, I hit: > > [...] > >> Is this expected? info '(guix) Invoking guix time-machine' does not >> mention of any point "too far" in the past to travel to. > > It’s expected. It’s not possible to travel so far back. The zero for > time-traveling is the introduction of “inferiors” mechanism around 2019. > > Well, since the question is recurrent, I agree that: > > 1. the manual needs to be improved; > 2. the command “guix time-machine” should raise a gentle error when the > specification is unreachable. I've sent a patch doing both 1 and 2 above to guix-patches; you were CC'd on it. Let me know what you think! -- Thanks, Maxim
Re: Read only_Edit Icecat.desktop
Hello, segundom...@tutanota.com writes: > Of course, today I'm using KDE Plasma(Kubuntu), but it's the same problem I > had when using the default GNOME in > Ubuntu. Attached video. Thanks for the video! It's a strange problem, but I believe I've seen something similar when using GNOME. I'll try taking a look when I have a chance. -- Thanks, Maxim
Re: patch question: any tool to download patches from guix patch mailing list?
Hi,
Giovanni Biscuolo writes:
> Hi!
>
> Jelle Licht writes:
>
> [...]
>
>> I know it was already mentioned, but some features were recently added
>> to piem (patch waiting over at https://issues.guix.gnu.org/64155) to
>> integrate it with debbugs.el,
>
> great! I missed it (v. 0.5.0 released few hours ago [1]); thank you for
> the patch to the Guix package!
>
>> the Emacs debbugs interface. This makes it
>> (IMHO) a fairly easy to apply some patches locally.
>>
>> I have this set up with (something similar to) the following:
>> --8<---cut here---start->8---
>> (setq piem-inboxes
>> (("guix-patches"
>> :coderepo ("/home/jlicht/Documents/guix")
>> :url "https://yhetil.org/guix-patches;
>> :listid "guix-patches.gnu.org"
>> :address "guix-patc...@gnu.org"
>> :gnu-package "guix-patches")))
>>
>> (require 'piem)
>> (piem-gnus-mode 1)
>> (piem-debbugs-mode 1)
>>
>> (require 'debbugs)
>> (defun debbugs-gnu-guix ()
>> "List Guix issues."
>> (interactive)
>> (debbugs-gnu '("serious" "important" "normal") '("guix-patches") nil t))
>> --8<---cut here---end--->8---
>>
>> With the configuration taken care of, just `M-x debbugs-gnu-guix',
>> navigate to any issue (just put point on an issue you are interested in)
>> and run `M-x piem-b4-am'. It should pull down all needed messages (from
>> yhetil's public inbox mirror), and use some heuristics to apply the most
>> recent patch revision, taking into account either 'git send-email' or
>> attachment-based patch series.
>
> Thank you for the explanation, it's very valuable since this new feature
> is not well documented on the pien online manual at
> https://docs.kyleam.com/piem/
> (e.g. https://docs.kyleam.com/piem/Lisp-Function-Index.html mentions
> piem-debbugs-mode but no other documentation is found)
That's very cool. I haven't tried it yet, but if it works as well as
advertised, it'd make sense to document it in our manual. Perhaps a new
"Applying patches" subsection to the 'Contributing' chapter?
--
Thanks,
Maxim
Re: Can Guix channels be non-GPL?
Hi David, david larsson writes: > On 2023-06-12 14:13, Parnikkapore wrote: >> Hi Guix! >> I realized a while ago that, since pretty much all Guix channels >> have >> to import some module from Guix (e.g. (guix packages)), it's basically >> impossible for a Guix channel to have any license other than GPLv3 or >> GPLv3+. >> Is this correct? If this is true, I'll have to relicense my channel >> accordingly. (it's currently under LGPL since that's my preference) I believe that's correct. If your channel is public/distributed to someone, it ought to be GPLv3+. -- Thanks, Maxim
Re: Read only_Edit Icecat.desktop
Hi! segundom...@tutanota.com writes: > Hello! > thanks for the feedback; > > I tested it, unfortunately it didn't work, because the new desktop was > "opened" by the original icecat icon inside the guix folder equally > other browsers. For testing purposes I completely uninstalled guix to > check if it wasn't something else, and all the other browsers opened > in their icon working perfectly no more from a second how it was with > icecat installed. > Do you know if there is another way to fix this? > I know that ready only as a user can't edit, if this is the case of course. Could you make some kind of video of the issue? It may help to graps the exact problem better. How some basic steps to reproduce when using GNOME. Don't forget to keep the help-guix@gnu.org email in CC so that everybody on the list can read our replies (you can use the 'wide' reply button in your mail client to ensure that). -- Thanks, Maxim
Re: Read only_Edit Icecat.desktop
Hello! segundomail--- via writes: > Hello, > I recently ran into a small problem that I would like some help if > possible. I use Guix Package Manager on ubuntu and I have a small > problem with the icon of the browsers, all the ones browser installed > are redirected when opened to the icon of the icecat (palemoon, > librewolf etc) in the dock (native in gnome and plank on kde). I > checked and I believe the problem is in the icecat.desktop where the > tag is StartupWMMClass=Navigator, and speculate that it should be > StartupWMClass=icecat-default, I may be wrong, but before guix it > didn't happen (I edited the others' StartupWMMClass to make > sure). however I can't edit the icecat.desktop because it is read > only, is there any way to edit the .desktop to check if this is what > creates the problem or solution? > Thanks for your attention; I noticed something strange with the Icecat icon used when used in a desktop environment such as GNOME. There are two icons at play, it seems. To test, you should be able to copy the icecat.desktop from the icecat package to a ~/.local/share/applications directory, I think! Perhaps something like (untested): --8<---cut here---start->8--- mkdir -p ~/.local/share/applications cp $(find $(guix build icecat) -name icecat.desktop) \ ~/.local/share/applications chmod +w ~/.local/share/applications/icecat.desktop --8<---cut here---end--->8--- Then you should be able to make changes to the icecat.desktop file copy. Don't forget to turn the "Exec" value to just 'icecat %u' to avoid effectively pinning it to an old version. Please let us know if you find the solution! -- Thanks, Maxim
error: %guix-register-program: unbound variable on guix time-machine
Hello, Attempting to navigate to a relatively distant past (Wed Jan 25 23:42:11 2017 -0500) with commit 9b9e147117e6009451d7acc1f8f156e041263e32, I hit: --8<---cut here---start->8--- $ LANG=C guix time-machine --commit=9b9e147117e6009451d7acc1f8f156e041263e32 -- shell --pure -D openconnect autoconf automake libtool Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Updating channel 'sfl-packages' from Git repository at 'https://gitlab.com/Apteryks/sfl-guix-channel'... Backtrace: In guix/store.scm: 659:37 19 (thunk) In guix/status.scm: 839:4 18 (call-with-status-report _ _) In guix/store.scm: 1298:8 17 (call-with-build-handler # ?) 2168:25 16 (run-with-store # ?) In guix/inferior.scm: 927:8 15 (_ _) In guix/channels.scm: 975:2 14 (_ _) 917:2 13 (_ _) In ./guix/monads.scm: 487:9 12 (_ _) In guix/store.scm: 1996:8 11 (_ _) In guix/channels.scm: 793:19 10 (_ _) In guix/store.scm: 1996:8 9 (_ _) In guix/channels.scm: 668:36 8 (_ #) 729:11 7 (_) In ice-9/eval.scm: 619:8 6 (_ #(#(#(#) # ?) ?)) 626:19 5 (_ #(#(#(#) # ?) ?)) 155:9 4 (_ #(#(#(#) # ?) ?)) 223:20 3 (proc #(#(#(#) ?) ?)) In unknown file: 2 (%resolve-variable (7 . %guix-register-program) #) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: %guix-register-program: unbound variable --8<---cut here---end--->8--- Is this expected? info '(guix) Invoking guix time-machine' does not mention of any point "too far" in the past to travel to. -- Thanks, Maxim
Re: Mcron jobs using with-mail-out
Hi Felix, Felix Lechner via writes: > Hi, > > Does anyone have a working job specification for Mcron that uses > "with-mail-out"? [1] I have some trouble providing (mcron redirect) > inside the gexp. Thanks! Sorry, I don't, but I'd be interested in a concrete example as well. -- Thanks, Maxim
Re: to save my Guix System installation
Hi Felix, Felix Lechner via writes: > Hi Florian, > > On Tue, May 23, 2023 at 9:33 AM pelzflorian (Florian Pelz) > wrote: >> >> yes, making a backup is good. > > I don't think Gottfried is making a backup. I think he is leaving us. > > We failed a beginner who is absolutely dedicated to free software. Let's try to provide value in our replies, or at least stay positive :-). It seems Gottfried is looking for a way to keep their Guix System available along other GNU/Linux systems. As Florian already mentioned, the challenge will be in configuring the bootloader. For moving Guix itself, you could copy its root file system using 'cp -a', or opt to reinstall from your config.scm as already mentioned up-thread. Sadly, for the complex part (the bootloader configuration), I'll leave it to someone more knowledgeable than myself to provide concrete answers, but I believe you'll want to read on something called multi-boot. There's a GRUB example here [0]. Good luck! [0] https://www.gnu.org/software/grub/manual/grub/html_node/Multi_002dboot-manual-config.html -- Thanks, Maxim
Re: guix build: error: gcry_md_hash_buffer: Function not implemented
Hi! "jgart" writes: > Hi, > > Can this be closed now given the recent mention of --sysconfdir? > > https://issues.guix.gnu.org/47401#1 I think so. Done! -- Thanks, Maxim
Re: guix build: error: gcry_md_hash_buffer: Function not implemented
Hi Simon, Simon Tournier writes: > Hi, > >> "26a788ae06 doc: Add some information/recommendation regarding >> --sysconfdir." >> >> that I hope rectifies this! >> >> Let me know if something can be improved still. > > I think the “make install” part means here “./pre-inst-env guix pull”. > Well, that’s the only case where I had troubles because this value is > recorded and can be propagated. Consider, > > ./bootstrap && ./configure --localstatedir=/var && make > ./pre-inst-env guix pull > guix pull --commit=1234abc > > and compared to the sequence without ./pre-inst-env: > > guix pull > guix pull -- commit=1234abc > > then it does not lead to the exact same Guix. 'sudo -E ./pre-inst-env guix system reconfigure ...' would be another such incantation that requires --sysconfdir to be set to /etc. Since we now recommend it to always be used, it is covered should these "advanced" commands be used, I think. -- Thanks, Maxim
Re: Install and load new emacs package without restarting it
Hi, Mekeor Melire writes: > On May 8, 2023 3:15:55 AM GMT+02:00, Maxim Cournoyer > wrote: >>Hi, >> >>Mekeor Melire writes: >> >>> 2023-05-04 12:38 andremegaf...@gmail.com: >>> >>>> Hi Guix, >>> >>> Hello! >>> >>>> I'm wondering whether it's possible to install an emacs package and >>>> enable it without restarting emacs. >>>> >> >>[...] >> >>> Or, if you have emacs-guix installed, you could try: >>> >>>M-x guix-emacs-autoload-packages RET >> >>It should be the above (note that it ships with Guix itself, not with >>emacs-guix) as the glue used to load the autoload packages. >> >>It used to work prior to reinstating elisp package installation to their >>own unique directory. I think it'd be worth it to open a bug for it and >>try to make it work again; it shouldn't be too difficult. >> >>-- >>Thanks, >>Maxim > > Thanks for clarification. > > So, you are suggesting that guix-emacs-autoload-packages currently > does not work? I just tested it on my machine and it works just fine. I think it would work only for "legacy" Elisp packages that still install directly to the EMACSLOADPATH (site-lisp) directory, but not those who install to their own sub-directory, basically those with directories listed in your $EMACSLOADPATH/subdirs.el file. One example in my profile is emacs-cmake-mode, which installs its files to: --8<---cut here---start->8--- /gnu/store/...-emacs-cmake-mode-3.25.1/share/emacs/site-lisp/cmake-mode-3.25.1 --8<---cut here---end--->8--- -- Thanks, Maxim
Re: pypi import certs issues
Hi, c4droid writes: > Hi, Maxim > > On Sun, May 07, 2023 at 09:18:25PM -0400, Maxim Cournoyer wrote: >> Hi, >> >> c4droid writes: >> >> > Hi, Guix! >> > >> > on commit dc5430c9dc20ee53441995d9a89a90b0a86aeed3 pypi import has >> > issues: >> > >> > Backtrace: >> > In ice-9/eval.scm: >> > 619:8 19 (_ #(#(#))) >> > In guix/ui.scm: >> >2300:7 18 (run-guix . _) >> > 2263:10 17 (run-guix-command _ . _) >> > In guix/scripts/import.scm: >> > 89:11 16 (guix-import . _) >> > In ice-9/boot-9.scm: >> > 1752:10 15 (with-exception-handler _ _ #:unwind? _ # _) >> > In guix/scripts/import/pypi.scm: >> > 97:21 14 (_) >> > In guix/import/utils.scm: >> >638:27 13 (recursive-import "pwntools" #:repo->guix-package _ # . #) >> >630:33 12 (lookup-node "pwntools" #f) >> > In guix/memoization.scm: >> > 98:0 11 (mproc "pwntools" #:version #f #:repo->guix-package #<…> …) >> > In unknown file: >> > 10 (_ # …) >> > In guix/import/pypi.scm: >> >495:21 9 (_ "pwntools" #:version _) >> >126:10 8 (pypi-fetch _) >> > In ice-9/exceptions.scm: >> >406:15 7 (json-fetch _ #:http-fetch _ #:headers _) >> > In ice-9/boot-9.scm: >> > 1752:10 6 (with-exception-handler _ _ #:unwind? _ # _) >> > In guix/import/json.scm: >> > 53:19 5 (_) >> > In guix/http-client.scm: >> >107:28 4 (http-fetch _ #:port _ #:text? _ #:buffered? _ # _ # _ # …) >> > In guix/build/download.scm: >> > 468:4 3 (open-connection-for-uri _ #:timeout _ # _) >> > 360:6 2 (tls-wrap # _ # _) >> > In ice-9/boot-9.scm: >> > 1685:16 1 (raise-exception _ #:continuable? _) >> > 1683:16 0 (raise-exception _ #:continuable? _) >> > >> > ice-9/boot-9.scm:1683:16: In procedure raise-exception: >> > X.509 certificate of 'pypi.org' could not be verified: >> > revocation-data-superseded >> > invalid >> > >> > I found a old discuss in >> > https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00247.html, >> > but set SSL_CERTS_DIR to /etc/ssl/certs don't working. >> >> [...] >> >> Do you have nss-certs installed in your operating system declaration (on >> Guix System) ? >> >> Not sure if it could help, but I just updated nss-certs to 3.88.1, up >> from 3.85, so pulling and reconfiguring your system may help. > > I tried to update nss-certs, after reconfiguring system still report this. At least we've ironed out that. I'm out of ideas for now :-/. Hopefully a TLS certs expert jumps in. -- Thanks, Maxim
Re: guix build: error: gcry_md_hash_buffer: Function not implemented
Hi, Mekeor Melire writes: > 2023-05-07 14:55 jg...@dismail.de: > >> > Sorry. I meant "./configure --localstatedir=/var > >> --sysconfdir=/etc". >> >> Hi, thanks. >> >> Is the --sysconfdir necessary? >> >> I've never used that. What does it mean or where should I get the >> TLDR/RTFM(L) on it? > > The only thing I know is that this command is instructed in info node > "(guix) Building from Git", i.e. in Guix' manual's chapter "22.1 > Building from Git". Unfortunately, in the manual as a whole, there is > no documentation that explains what this argument does. I just pushed a small doc commit, "26a788ae06 doc: Add some information/recommendation regarding --sysconfdir." that I hope rectifies this! Let me know if something can be improved still. -- Thanks, Maxim
Re: pypi import certs issues
Hi, c4droid writes: > Hi, Guix! > > on commit dc5430c9dc20ee53441995d9a89a90b0a86aeed3 pypi import has > issues: > > Backtrace: > In ice-9/eval.scm: > 619:8 19 (_ #(#(#))) > In guix/ui.scm: >2300:7 18 (run-guix . _) > 2263:10 17 (run-guix-command _ . _) > In guix/scripts/import.scm: > 89:11 16 (guix-import . _) > In ice-9/boot-9.scm: > 1752:10 15 (with-exception-handler _ _ #:unwind? _ # _) > In guix/scripts/import/pypi.scm: > 97:21 14 (_) > In guix/import/utils.scm: >638:27 13 (recursive-import "pwntools" #:repo->guix-package _ # . #) >630:33 12 (lookup-node "pwntools" #f) > In guix/memoization.scm: > 98:0 11 (mproc "pwntools" #:version #f #:repo->guix-package #<…> …) > In unknown file: > 10 (_ # …) > In guix/import/pypi.scm: >495:21 9 (_ "pwntools" #:version _) >126:10 8 (pypi-fetch _) > In ice-9/exceptions.scm: >406:15 7 (json-fetch _ #:http-fetch _ #:headers _) > In ice-9/boot-9.scm: > 1752:10 6 (with-exception-handler _ _ #:unwind? _ # _) > In guix/import/json.scm: > 53:19 5 (_) > In guix/http-client.scm: >107:28 4 (http-fetch _ #:port _ #:text? _ #:buffered? _ # _ # _ # …) > In guix/build/download.scm: > 468:4 3 (open-connection-for-uri _ #:timeout _ # _) > 360:6 2 (tls-wrap # _ # _) > In ice-9/boot-9.scm: > 1685:16 1 (raise-exception _ #:continuable? _) > 1683:16 0 (raise-exception _ #:continuable? _) > > ice-9/boot-9.scm:1683:16: In procedure raise-exception: > X.509 certificate of 'pypi.org' could not be verified: > revocation-data-superseded > invalid > > I found a old discuss in > https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00247.html, > but set SSL_CERTS_DIR to /etc/ssl/certs don't working. [...] Do you have nss-certs installed in your operating system declaration (on Guix System) ? Not sure if it could help, but I just updated nss-certs to 3.88.1, up from 3.85, so pulling and reconfiguring your system may help. -- Thanks, Maxim
Re: Install and load new emacs package without restarting it
Hi, Mekeor Melire writes: > 2023-05-04 12:38 andremegaf...@gmail.com: > >> Hi Guix, > > Hello! > >> I'm wondering whether it's possible to install an emacs package and >> enable it without restarting emacs. >> [...] > Or, if you have emacs-guix installed, you could try: > >M-x guix-emacs-autoload-packages RET It should be the above (note that it ships with Guix itself, not with emacs-guix) as the glue used to load the autoload packages. It used to work prior to reinstating elisp package installation to their own unique directory. I think it'd be worth it to open a bug for it and try to make it work again; it shouldn't be too difficult. -- Thanks, Maxim
Planned Guix services downtime on May 10th
Hello! The Max Delbrück Center [0], which graciously hosts the Berlin Guix infrastructure, will be conducting upgrades to their data center. The Berlin fleet of machines will have to be powered down between 01:00 and 06:00 (Berlin time) on May 10th, which will cause the following service disruptions: 1. https://ci.guix.gnu.org downtime (use bordeaux.guix.gnu.org instead) 2. https://issues.guix.gnu.org downtime (use Debbugs instead [1]) The website should remain available, if the fallback in place works as expected. [0] https://www.mdc-berlin.de/ [1] https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix -- Thanks, Maxim
Re: Error building with guix system image
Hi,
Saku Laesvuori writes:
>> > (define %operating-system
>> > (operating-system
>> >(host-name "image-test")
>> >(bootloader (bootloader-configuration
>> > (bootloader grub-bootloader)
>> > (targets '("/dev/sdX"
>> >(file-systems (cons*
>> > (file-system
>> >(mount-point "/")
>> >(device "/dev/sdX1")
>> >(type "ext4"))
>> > %base-file-systems
>>
>> Do you correctly substitute /dev/sdX for your real device name (e.g.,
>> /dev/sda) ?
>
> I did try with that too, but it failed with the same error. Today I
> almost accidentally found out that this error was caused by a corrupt
> store item and was fixed by running `guix gc --verify=contents,repair`.
>
> The error message could certainly be improved (or rather, a error
> message about a corrupt store could be added), but I didn't find the
> actual failing check so that I can't send a patch.
OK! I'm glad you at least got past that road bump.
--
Thanks,
Maxim
Re: do old packages like Musescore 3.6.2 need updating?
Hello, Gottfried writes: > Hi, > > 1. > I have the old version of Musescore 3.6.2 which I want in one profile. > When I update all profiles at once through a script, it also builds > locally the old version of Musescore, which needs 1 hour on my laptop. > Firstly, why it always builds it on my laptop? This suggests your are using an old Guix version, as musescore is currently at 4.0.2. Did you run 'guix pull' recently? That's how package definitions are updated. Guix upgrade then use these to update your profiles. -- Thanks, Maxim
Re: Latest binary release downloads broken
Hello, +CC guix-sysadmin writes: > Hi all, > > > the links to the binary releases are broken (502 error): > > https://guix.gnu.org/en/download/latest/ > > I noticed this because the guix-install-action on github is also > affected. > > Please point me to the appropriate place to report this issue if it > isn't here and just in case it is already known: sorry for the noise! I've noticed that too. You can create an issue for it by submitting a bug to bug-g...@gnu.org. I'll poke the guix-sysadmin mail alias to see if one of them would have an idea. -- Thanks, Maxim
Re: Alternatives to --emulate-fhs on foreign distros
Hi Kyle, Kyle writes: > Dear Maxim, > > Unfortunately, I don't see /usr/bin/env when I look inside the file system > resulting from: > > guix shell coreutils --container > For this use case, I use the --symlink option, like so: '--symlink=/usr/bin/env=bin/env'. -- Thanks, Maxim
Re: Alternatives to --emulate-fhs on foreign distros
Hi Kyle, Kyle Andrews writes: > Dear Guix, > > The (many) shell scripts in my software depend on bashisms. In the > code right now I typically use /usr/bin/env bash since I had read that > was the most portable way of referencing a shell. However, I really > don't think I have a good handle on what my choices are. Maybe the > tedious solution of just typing `bash script.sh' in all of the system > calls referencing this scripts might be the right approach in the long > run? Use /usr/bin/env. It's available on all mainstream distributions, and it's also available on Guix System, so it should work everywhere. -- Thanks, Maxim
Re: Error building with guix system image
Hello,
Saku Laesvuori writes:
> Running `guix system image image-minimal.scm` fails with the following
> build log:
>
> ```build log for partition.img.drv
> copying 340 store items | [progress bar animation]
> registering 337 items | [progress bar animation, fails before end]
> Backtrace:
> In ice-9/eval.scm:
> 619:8 19 (_ #(# # …))
> In ./gnu/build/image.scm:
> 236:4 18 (initialize-root-partition "tmp-root" #:bootcfg _ # _ # …)
> In ice-9/boot-9.scm:
>260:13 17 (for-each # …)
> In ./gnu/build/image.scm:
> 167:6 16 (register-closure "tmp-root" "system" #:schema _ # _)
> In ./guix/store/database.scm:
>111:20 15 (call-with-database "tmp-root/var/guix/db/db.sqlite" # # …)
> In ./guix/progress.scm:
> 71:36 14 (call-with-progress-reporter #< sta…> …)
> In srfi/srfi-1.scm:
> 634:9 13 (for-each # …)
> In ./guix/store/database.scm:
>420:36 12 (_ #< item: "/gnu/store/8z1q7vjxylm6l4ibsyw…>)
> In ./guix/store/deduplication.scm:
> 42:4 11 (nar-sha256 "tmp-root/gnu/store/8z1q7vjxylm6l4ibsywd4h6…")
> In ./guix/serialization.scm:
> 381:9 10 (dump "tmp-root/gnu/store/8z1q7vjxylm6l4ibsywd4h6m6jv6z…")
> In srfi/srfi-1.scm:
> 634:9 9 (for-each # …)
> In ./guix/serialization.scm:
>386:23 8 (_ "share")
> 381:9 7 (dump "tmp-root/gnu/store/8z1q7vjxylm6l4ibsywd4h6m6jv6z…")
> In srfi/srfi-1.scm:
> 634:9 6 (for-each # …)
> In ./guix/serialization.scm:
>386:23 5 (_ "locale")
> 381:9 4 (dump "tmp-root/gnu/store/8z1q7vjxylm6l4ibsywd4h6m6jv6z…")
> In srfi/srfi-1.scm:
> 634:9 3 (for-each # …)
> In ./guix/serialization.scm:
>386:23 2 (_ "ja")
>380:43 1 (dump "tmp-root/gnu/store/8z1q7vjxylm6l4ibsywd4h6m6jv6z…")
> In srfi/srfi-1.scm:
>691:29 0 (filter-map # …)
>
> srfi/srfi-1.scm:691:29: In procedure filter-map:
> In procedure car: Wrong type argument in position 1 (expecting pair): #f
> environment variable `PATH' set to
> `/gnu/store/zfiwdkwfs039q346nkynvhllxbra2rg8-e2fsprogs-1.46.4/bin:/gnu/store/zfiwdkwfs039q346nkynvhllxbra2rg8-e2fsprogs-1.46.4/sbin:/gnu/store/nj43wfbldxrwfmrk9vgvliz28iyl89dp-fakeroot-1.30.1/bin:/gnu/store/lpkpldxni8vab82kwq9qs032hni580ak-dosfstools-4.2/sbin:/gnu/store/131xfb6iz9vh7c8s7kv6nhvycrqcfad8-mtools-4.0.42/bin'
> ```
>
> Does anyone have any pointers on how to debug or fix this? The operating
> system builds nicely with `guix system vm`. Building
> `gnu/system/examples/bare-bones.tmpl` with `guix system image` also
> fails with a similar error and works correctly with `guix system vm`.
>
>
> ```image-minimal.scm
> (use-modules
> (gnu)
> (gnu system image))
>
> (define %operating-system
> (operating-system
>(host-name "image-test")
>(bootloader (bootloader-configuration
> (bootloader grub-bootloader)
> (targets '("/dev/sdX"
>(file-systems (cons*
> (file-system
>(mount-point "/")
>(device "/dev/sdX1")
>(type "ext4"))
> %base-file-systems
Do you correctly substitute /dev/sdX for your real device name (e.g.,
/dev/sda) ?
It should print a nice error when it doesn't exist, I think, but perhaps
it regressed.
'guix system vm' overrides the root file system, so wouldn't complain
about a problem in your root file system definition.
--
Thanks,
Maxim
Re: Is it possible to system reconfigure from a local guix git?
Hi Denis, Denis 'GNUtoo' Carikli writes: > On Tue, 18 Apr 2023 09:03:51 +0200 > Andreas Enge wrote: > >> So in a first step, if I am limited to sudo, I do "sudo su -" to >> become root. > Thanks a lot, that seems to work: I don't have the same errors anymore > (I've other errors related to i686 though). You can also use --8<---cut here---start->8--- sudo -E ./pre-inst-env guix system reconfigure ... --8<---cut here---end--->8--- To avoid bad surprises, make sure that you've run --8<---cut here---start->8--- ./configure --localstatedir=/var --sysconfdir=/etc --8<---cut here---end--->8--- before that. -- Thanks, Maxim
DNS problems with guix.gnu.org domain (and a tip)
Hello, There is currently a problem with DNS for the various Guix services. Berlin at least appears to be running fine otherwise, and you can still get substitutes by using its public IP like: --8<---cut here---start->8--- guix install hello --substitute-urls='https://141.80.181.40' --8<---cut here---end--->8--- I thought I'd share this useful tip while the problem is investigated and resolved. -- Thanks, Maxim
Re: Most used and least used build-system in Guix packages
Hello, Rodrigo Morales writes: > Table of Contents > _ > > 1. TL; DR > 2. My findings > 3. The question > > > 1 TL; DR > > > Today, I was wondering what the most used build system and the least > one are. The most used build system is `gnu-build-system'. The least > used build system is `dub-build-system'. Here's how I found that out. > > > 2 My findings > = > > , > | (car %load-path) > ` > > , > | > /gnu/store/zc7dzsd10dd3pw60hircphz4vh1wlki0-guix-module-union/share/guile/site/3.0 > ` > > , > | > dir="/gnu/store/zc7dzsd10dd3pw60hircphz4vh1wlki0-guix-module-union/share/guile/site/3.0" > | path="$dir/gnu/packages" > | grep -hREo '[a-zo-]+-build-system' $path | sort | uniq -c | sort -nr > ` > > , > | 3893 gnu-build-system > | 2717 python-build-system [...] > 3 The question > == > > Does anyone know if there's a more accurate way of finding out this > information? I'm asking because my method also counts build systems > that are mentioned in comments. For example, if a file contains > comments that mention build systems, they are also counted. Guix provides an API, so you could use it from the comfort of the 'guix repl' REPL to query it, using fold-packages. The following repo will surely provide some clues as to how to do that; the following is an example querying all the packages that make use of the emacs-build-system [0] [0] https://notabug.org/apteryx/guix-api-examples/src/master/emacs-packages-manifest.scm Have fun! -- Thanks, Maxim
Re: Strange error when adding module gnu/packages/engineering
Hi Reza, Reza Housseini writes: >> Thinking more about it, since this a new module, there shouldn't be any >> recursive dependency problem. >> Probably you are missing some #:use-module at the top of your new >> module. I'd start minimal and see what works, and evaluate the package >> at the REPL for more accurate messages perhaps. > > I could boil it down a bit: when commenting out `#:use-module (gnu > packages commencement)` in gnu/packages/engineering.scm the error > vanishes but the freehdl package in module engineering does not build > anymore (due to gcc-toolchain missing). > Is there a cycle inside module commencement? Seems really strange to me? That's a tell sign of a Guile module top-level circular dependency. I think the usual way to work around that is usually to resort to use (@ (gnu packages toolchain) gcc-toolchain) in place of the input, so that importing it at the top level is not necessary (the evaluation of inputs is delayed, eliminating the cycle). I hope that helps, -- Thanks, Maxim
Manifest to run git-webkit, when contributing patches to Webkit
Hello, Having spent some time trying to use their 'git-webkit' script to submit guix-related work, I thought I'd share what worked: --8<---cut here---start->8--- ~/src/WebKit$ guix shell -m git-webkit-manifest.scm -- Tools/Scripts/git-webkit setup --8<---cut here---end--->8--- Then --8<---cut here---start->8--- guix shell -m git-webkit-manifest.scm -- Tools/Scripts/git-webkit pull-request --8<---cut here---end--->8--- Where git-webkit-manifest.scm contains: --8<---cut here---start->8--- (setenv "DISABLE_WEBKITCOREPY_AUTOINSTALLER" "1") (packages->manifest (map specification->package (list "python" "python-certifi" "python-mock" "python-chardet" "python-dateutil" "python-entrypoints" "python-idna" "python-packaging" "python-pyparsing" "python-requests" "python-setuptools-scm" "python-socks" "python-six" "python-tblib" "python-urllib3" "python-wheel" "python-whichcraft" "python-xmltodict" "python-jeepney" "python-cffi" "python-cryptography" "python-secretstorage" "python-keyring"))) --8<---cut here---end--->8--- Their contribution process is documented at https://webkit.org/contributing-code/#setting-up-a-checkout. I hope that helps someone else (or myself in the future). -- Thanks, Maxim
Re: How to properly upgrade Guix System & Home?
Hi, Tanguy LE CARROUR writes: > Hi Julien, > > Thanks for your reply! > > Quoting Julien Lepiller (2023-03-22 18:24:37) >> Most likely, you're just seeing a weird behavior caused by grafts. […] >> When you reconfigure, guix needs to download the ungrafted package >> before it figures out it already has the graft. > > Oh… Oh… grafts! 勞 > > >> Since they have the same name and version, I think you're just >> cwnfusing the two :) > > "Confused" is the appropriate word, indeed! > > The thing is, I've been (for the last few months! ) in the process of > writing home services definitions to replace **all** my configuration files, > so I run **a lot** of `guix home reconfigure`. The command usually takes 30 > seconds to run, but right after I `guix gc` it takes 10 minutes. So I > guess I should stop collecting garbage for the time being, which is most > inconvenient for it saves more than 4Go of disk space. I think we should do something on Guix's side too; it'd be more intuitive and save resource/time if the things needed by grafts were always available, i.e. prevented from being garbage collected. -- Thanks, Maxim
Re: Problems running Guix System initrd on an i.MX6 ARM board
Hello!
Efraim Flashner writes:
> On Mon, Dec 12, 2022 at 10:40:50PM -0500, Maxim Cournoyer wrote:
>> Hi Guix!
>>
>> I've been trying for some time to run Guix System on an ARM board (a
>> TS-7970 with an i.MX6 Cortex A9 CPU). I wanted to cross-compile the
>> image for speed and efficiency, and stumbled upon some problems on the
>> way, such as https://issues.guix.gnu.org/44924, fixed on core-updates.
[...]
>> The initrd now runs, but it fails with the following error:
>>
>> --8<---cut here---start->8---
>> [8.448448] ALSA device list:
>> [8.451472] #0: On-board Codec
>> [8.454768] #1: imx-hdmi-soc
>> [8.461095] Freeing unused kernel memory: 1024K (80e0 - 80f0)
>> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main
>> thread
>> GC Warning: Couldn't read /proc/stat
>> [8.481168] mmc0: new SDIO card at address 0001
>> Welcome, this is GNU's early boot Guile.
>> Use 'gnu.repl' for an initrd REPL.
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record
>> ABI mismatch; recompilation needed" (#>) ())'.
>>
>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>> GNU Guile 3.0.8
>> Copyright (C) 1995-2021 Free Software Foundation, Inc.
>>
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>>
>> Enter `,help' for help.
>> scheme@(guile-user)>
>> --8<---cut here---end--->8---
>>
>> The .go modules appear to be correctly cross-compiled for
>> arm-linux-gnueabihf (they run fine on the same target using a different
>> OS that I can boot with).
>>
>> Ideas?
>
> Perhaps you'll need to compile more with guile-3.0-latest. If it's not
> too much I suppose you could try moving guile-3.0-latest to guile-3.0.
> Otherwise I guess you'll need to find where is being
> compiled and replace that guile-3.0 with guile-3.0-latest too, and then
> see where the next failure is.
I've tried that on master, with the following patch applied:
--8<---cut here---start->8---
1 file changed, 17 insertions(+), 31 deletions(-)
gnu/packages/guile.scm | 48 +---
modified gnu/packages/guile.scm
@@ -310,15 +310,15 @@ (define-public guile-3.0
(package
(inherit guile-2.2)
(name "guile")
-(version "3.0.7")
+(version "3.0.9")
(source (origin
(inherit (package-source guile-2.2))
- (patches '()) ; We no longer need the patches.
+ (patches '()) ;no longer needed
(uri (string-append "mirror://gnu/guile/guile-"
version ".tar.xz"))
(sha256
(base32
-"1dwiwsrpm4f96alfnz6wibq378242z4f16vsxgy1n9r00v3qczgm"))
+"03bm1mnfc9kkg2ls942a0js7bxrdzmcffgrgg6anwdmjfan2a9hs"))
;; Replace the snippet because the oom-test still
;; fails on some 32-bit architectures.
(snippet '(begin
@@ -334,6 +334,11 @@ (define-public guile-3.0
(delete "gmp" "libltdl")))
(arguments
(substitute-keyword-arguments (package-arguments guile-2.0)
+ ;; Guile 3.0.9 is bit-reproducible when built in parallel, thanks to
+ ;; its multi-stage build process for cross-module inlining, except when
+ ;; cross-compiling.
+ ((#:parallel-build? _ #f)
+(not (%current-target-system)))
((#:configure-flags flags ''())
;; XXX: JIT-enabled Guile crashes in obscure ways on GNU/Hurd.
`(cons* ,@(if (hurd-target?)
@@ -365,19 +370,19 @@ (define-public guile-3.0
(lambda _
;; Upstream knows about suggested solution.
;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214
- (substitute* "bootstrap/Makefile.in"
+ ;;
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977223#46
+ (substitute* "stage0/Makefile.in"
(("^GUILE_OPTIMIZATIONS.*")
"GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives
-Ocps\n")
'())
,@(if (or (target-ppc32?)
(target-riscv64?))
-
Re: attempt to scan in Guix
Hello, Gottfried writes: > Hi, > > I can’t scan with my HP OfficeJet printer all-in-one in Guix. > > When opening the "Enlightenment Desktop" > it gives me this message after trying to scan: > > /gnu/store/sw1j2kavizxwj7sc51p83nwrfdvm6xj4-hplip-3.33.10/bin/hp-toolbox > was broken due to a segmentation error. > > in German: > /gnu/store/sw1j2kavizxwj7sc51p83nwrfdvm6xj4-hplip-3.33.10/bin/hp-toolbox > wurde durch einen Segmentierungsfehler unterbrochen. > > When I want to open the program "HP Device Manager" through klicking > in my Start Menu > it flashes for a quarter of a second (it wants to open) and shows > something (but too short to see what), but than it dissapears. > > Could it be a hplip problem? Not sure where you got that 3.33.10 version; the current one in Guix is 3.22.10. I used it recently, had to patch wheer it looked its hp.conf, but it seemed to mostly work (I needed to install cups for 'lp'). -- Thanks, Maxim
Re: Can't type Japanese anymore
Hello, Luis Felipe writes: > On Wednesday, December 28th, 2022 at 21:14, Luis Felipe > wrote: > > >> Hi Maxim, >> > >> On Tuesday, December 27th, 2022 at 03:42, Maxim Cournoyer >> maxim.courno...@gmail.com wrote: >> > >> > I just tried, and it doesn't work for me either :-/. Not sure if it's >> > cache related, or a more serious issue. >> > >> I don't know..., removing ~/.cache/ibus didn't seem to have any effect here >> anymore. It used to. I tried in two different machines. > > It's been a month since I wrote this. Today, I came across a ".anthy" folder > in my home directory, I trashed it, ran "ibus-daemon -dr" and Japanese is > back (よかった～！). Awesome, thanks for sharing! Yet another case of a stale cache... -- Thanks, Maxim
Re: Python build system cross build
Hi, phodina via writes: > Hi, > > what are the necessary steps to allow python-build-system to be cross > buildable? > > ``` > guix build gnome-shell --target=aarch64-linux-gnu > guix build: error: gnu/packages/gtk.scm:2066:2: python-pycairo@1.20.0: build > system `python' does not support cross builds > ``` Review/apply this patch: https://issues.guix.gnu.org/60847 :-) -- Thanks, Maxim
Re: What are you doing for a screen locker?
Hi, kiasoc5 writes: > On 1/21/23 13:44, Christine Lemmer-Webber wrote: >> I used to use xscreensaver. I kinda miss it. It's still broken, see >> bug #57919. >> But really, the lack of xscreensaver has made me move back to Gnome >> and >> recently Gnome started having weird bugs on my hardware, so then I >> wanted to move back to stumpwm. But I simply don't understand how to >> get screen locking to work right without xscreensaver, which at least >> had made it relatively easy. >> The cookbook contains some info on how to use session locking with >> xorg >> but it doesn't seem like complete information. I'd be interested if >> people would share their configurations. Thanks! >> > > xlockmore and slock are installed in %base-packages and should work > out of the box on Xorg. I use xlockmore, but beware that it'll peak one of your core 100% while used. Perhaps there's something better? -- Thanks, Maxim
Re: emacs-guix: error message when calling guix-packages-by-name
Hi, André A. Gomes writes: > Hi Guix, > > When running the command guix-packages-by-name from emacs-guix I get the > following error: > > Starting Guix REPL ... [5 times] > guix-geiser-eval: Error in evaluating guile expression: > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > In procedure package-name: Wrong type argument: # gnu/packages/abduco.scm:28 7ff3e7236f20> > > Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. > scheme@(emacs-guix) [1]> Invalid face reference: sly-inspector-label-face > > I'm wondering whether this is general problem or a problem from my > side. Thanks. I just tried it, and it seems to work here. -- Thanks, Maxim
Re: How to diagnose this "system reconfigure" error?
Hi Erik, Erik Winkels writes: > Hi, > >> On 2023-01-16 17:38 CET Maxim Cournoyer wrote: >> >> Could you please try to narrow down the problem by reducing your >> config, first by removing its dependency on the nongnu >> channel/modules? I suspect it has something to do with it. If >> so, you should seek support on their own support channels. > > You were right and I should have defaulted to suspecting nonguix first. > Thing is: my initial searches didn't turn anything up. > > Anyway, sorry for bothering the official mailinglist with this, but at least > I am subscribed now ;-) No worries, I'm glad you sorted it out. Thank you for sharing the outcome with us! -- Thanks, Maxim
Re: customize-linux not working as expected
Hi,
"dabb...@gmail.com" writes:
> Dear community,
>
> I would like to customize the configuration of my linux kernel, in
> particular of a xenomai-patched one.
> In the past days I've followed the route of using the procedure
> make-linux-libre*, in particular using the
> key #:extra-options to append my customizations to
> %default-extra-linux-options. In that case I did
> not encounter any suspect behavior (except for the fact that
> %default-extra-linux-options must be
> appended after my list, and not the opposite, in order to have my
> settings in place).
>
> Today I've decided to give a try to the new procedure
> "customize-linux". Here is the snippet:
>
> define-public linux-xenomai
> (let ((father ((@@ (gnu packages linux) customize-linux)
> #:name "linux-xenomai"
> #:linux linux-libre-5.4
> #:defconfig "x86_64_defconfig"
> #:configs
> '("CONFIG_LOCALVERSION=\"-xenomai3.2.2\""
> ;; Xenomai specific tweaks
> "# CONFIG_SCHED_MC_PRIO is not set"
> "# CONFIG_CPU_FREQ is not set"
> "# CONFIG_ACPI_PROCESSOR is not set"
> "# CONFIG_CPU_IDLE is not set"
> "# CONFIG_APM is not set"
> "# CONFIG_INTEL_IDLE is not set"
> "# CONFIG_INPUT_PCSPKR is not set"
> "# CONFIG_COMPACTION is not set"
> "# CONFIG_MIGRATION is not set"
> ;; PCP customization
> "CONFIG_XENO_DRIVERS_NET=y"
> "CONFIG_XENO_DRIVERS_NET_DRV_E1000=m"
> "CONFIG_XENO_DRIVERS_NET_DRV_E1000E=m"
> "CONFIG_XENO_DRIVERS_NET_DRV_IGB=m"
> "CONFIG_NTFS_FS=m"
> "CONFIG_NTFS_RW=y"
> "CONFIG_CIFS=m"
> "CONFIG_CIFS_XATTR=y"
> "CONFIG_CONSOLE_LOGLEVEL_DEFAULT=4")))
>(ipipepatch (ipipe-x86-patch "5.4.228-x86-12"
> "05l092vfswqlwyis0m6x5wa5hxwlmv7jwjpnjrbjav0b5ibv0xnr")))
> (package
>(inherit father)
>(name "linux-xenomai")
>(version "5.4.228")
>(arguments
> (substitute-keyword-arguments (package-arguments father)
> ((#:phases phases)
>#~(modify-phases #$phases
> (add-after 'unpack 'unpack-extra-sources
> (lambda _
> (begin
>(copy-recursively #+ipipepatch "ipipe.patch")
>(copy-recursively #+xenomai-origin "xeno-source.tar.bz2")
>(invoke "tar" "-xjf" "xeno-source.tar.bz2")
>(invoke "bash" (string-append "xenomai-v"
> #$xenomai-version "/scripts/prepare-kernel.sh") "--ipipe=ipipe.patch"
> "--arch=x86_64"
>(synopsis "Linux kernel with Xenomai Cobalt co-kernel")
>(description
> "Xenomai is a Free Software project in which engineers from a wide
> background collaborate to build a robust and resource-efficient
> real-time core for Linux following the dual kernel approach, for
> applications with stringent latency requirements.")
>(home-page "http://xenomai.org/;
>
>
> Unfortunately, some of my custom configs are in contrast to the
> default one (and they have to be that
> way for xenomai to work), and this leads the build process to stop at
> "verify-config".
> Here is the output to the terminal:
>
> error: in phase 'configure': uncaught exception:
> misc-error #f "~A ~S" ("Mismatching configurations in .config and
> arch/x86/configs/guix_defconfig" (("CONFIG_JUMP_LABEL" (#f "y"))
> ("CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE" (#f "y"))
> ("CONFIG_CPU_FREQ_GOV_PERFORMANCE" (#f "y"))
> ("CONFIG_CPU_FREQ_GOV_ONDEMAND" (#f "y")) ("CONFIG_X86_ACPI_CPUFREQ"
> (#f "y")) ("CONFIG_NF_CONNTRACK_IPV4" (#f "y"))
> ("CONFIG_IP_NF_TARGET_MASQUERADE" ("m" "y"))
> ("CONFIG_NF_CONNTRACK_IPV6" (#f "y")) ("CONFIG_SND_MIXER_OSS" (#f
> "y")) ("CONFIG_SND_PCM_OSS" (#f "y")) ("CONFIG_SND_SEQUENCER_OSS" (#f
> "y")) ("CONFIG_TIMER_STATS" (#f "y")) ("CONFIG_DEBUG_STACKOVERFLOW"
> (#f "y")) ("CONFIG_XENO_DRIVERS_NET" ("m" "y" #f
> phase `configure' failed after 111.5 seconds
[...]
>
>
> This behaviour is strange to me, as I was expecting my #:configs to
> take priority over default ones.
>
> Am I missing something?!
> Thank you for your support!
The new customize-linux procedure ensures that the provided #:defconfig
(or default defconfig if not specified), modified by #:configs, let's
name that "guix_defconfig" generates a .config file that can be saved
back exactly into exactly the same "guix_defconfig" when calling "make
savedefconfig".
[solved] Geiser (or ielm) in Emacs doesn't return the prompt
Hi Guix, I've spent some time today trying to understand why my setup had stopped working, with the following symptoms: 1. Evaluating anything in Geiser (wih Guile) would not return the prompt, seemingly hanging. 2. The same in IELM (M-x ielm), an Elisp REPL builtin Emacs It ended up being due to changes in Paredit 25 and up. The author currently recommends disabling the electric-indent-mode, or overriding the following mode map keys: (define-key paredit-mode-map (kbd "RET") nil) (define-key paredit-mode-map (kbd "C-j") 'paredit-newline) I've used the later, and my setup now works as it used to! I hope this can save some time for anyone else affected. -- Thanks, Maxim
Re: grub-install failing while system reconfigure
Hello, Akib Azmain Turja writes: > grub-install is saying no space left, but I still have much space > available in both root and EFI partition. > > akib@gnu-guix:~/dotfiles$ sudo guix system reconfigure > ~/dotfiles/guix/system-config.scm > The following derivation will be built: > /gnu/store/ss6c3krd1wwbg7kybdr8pkrl7jy3cc79-grub.cfg.drv > > building /gnu/store/ss6c3krd1wwbg7kybdr8pkrl7jy3cc79-grub.cfg.drv... > /gnu/store/i3bl3mpy92hwm6v1n74slvyvlgnpg85g-system > /gnu/store/hhm7spb2xdd6i5ci8p6wjs9dalv9g18a-grub.cfg > > activating system... > making '/gnu/store/i3bl3mpy92hwm6v1n74slvyvlgnpg85g-system' the current > system... > setting up setuid programs in '/run/setuid-programs'... > populating /etc from /gnu/store/dkr38kkqiykn86qxmqq0vmd86kf8v7qr-etc... > The following derivation will be built: > /gnu/store/77k62g58nhi9kaxfryfa3b54a9i53gd6-install-bootloader.scm.drv > > building > /gnu/store/77k62g58nhi9kaxfryfa3b54a9i53gd6-install-bootloader.scm.drv... > guix system: error: > '/gnu/store/ch9q9w5zbvgq8srr6dscq6hdf03pfqb4-grub-efi-2.06/sbin/grub-install > --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi' > exited with status 1; output follows: > > Installing for x86_64-efi platform. > Could not prepare Boot variable: No space left on device > > /gnu/store/ch9q9w5zbvgq8srr6dscq6hdf03pfqb4-grub-efi-2.06/sbin/grub-install: > error: efibootmgr failed to register the boot entry: Input/output error. I have experienced PC with buggy UEFI firmware; when I saw errors similar to the above rebooting the machine would resolve it. -- Thanks, Maxim
Re: How to diagnose this "system reconfigure" error?
Hi Erik, Erik Winkels writes: > Since I a few weeks I have been able to do a system reconfigure. When > this happened in the past it usually fixed itself after a few days but > it seems the problem is on my end this time. > > However, I'm at a loss where to start diagnosing this. I've added > debug levels to the command but this is all I keep getting: > > $ sudo guix system --debug=3 reconfigure ~/cfg/system-config.scm > Backtrace: > In guix/store.scm: > 2055:12 19 (_ #) > 1382:11 18 (map/accumulate-builds # …) > 1300:8 17 (call-with-build-handler # …) > 2170:25 16 (run-with-store # …) > In guix/gexp.scm: > 1180:2 15 (_ #) > 1046:2 14 (_ _) > 892:4 13 (_ _) > In guix/store.scm: > 2055:12 12 (_ #) > 1382:11 11 (map/accumulate-builds # …) > 1300:8 10 (call-with-build-handler # …) > 2170:25 9 (run-with-store # …) > In guix/gexp.scm: > 897:13 8 (_ _) > In guix/store.scm: > 1998:8 7 (_ _) > In guix/gexp.scm: > 299:22 6 (_ _) > In guix/store.scm: > 1998:8 5 (_ _) > In guix/packages.scm: > 1948:11 4 (_ _) > 1884:8 3 (_ _) > In guix/build-system/copy.scm: > 80:0 2 (copy-build _ _ #:guile _ #:source _ #:outputs _ # _ # _ …) > In ice-9/boot-9.scm: > 1685:16 1 (raise-exception _ #:continuable? _) > 1685:16 0 (raise-exception _ #:continuable? _) > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > Unrecognized keyword: #:linux > I've attached my config. Could you please try to narrow down the problem by reducing your config, first by removing its dependency on the nongnu channel/modules? I suspect it has something to do with it. If so, you should seek support on their own support channels. -- Thanks, Maxim
Re: Strange error when adding module gnu/packages/engineering
Hi, Reza Housseini writes: >> This looks like the kind of (misleading) error thrown when there are top >> level dependency cycle problems. These are not fun to debug. > > I thought maybe this is the problem, any advice how to debug? Thinking more about it, since this a new module, there shouldn't be any recursive dependency problem. Probably you are missing some #:use-module at the top of your new module. I'd start minimal and see what works, and evaluate the package at the REPL for more accurate messages perhaps. -- Thanks, Maxim
Re: Help with DBus Tests Failing for Python Package
Hi, Jaft writes: > On Tuesday, December 27, 2022 at 11:49:31 AM CST, Maxim Cournoyer > wrote: >> I bet this is because of the expectation of python-dbus on the processes >> being reaped by PID 1 instead of staying around as zombies, as currently >> happens in the Guix build container (see: >> https://issues.guix.gnu.org/30948). >> >> The current workaround currently used in Guix involves the use of tini >> and of a forked process... it's not very pretty (see 'guix edit mutter' >> for such an example). > > Thanks a ton for the pointer, Maxim. > > Unfortunately, I still seem to be getting the same result. At first, I tried > a simple approach of ~(execlp "tini" "--" "python" "setup.py" "test")~; I > think it wound up still requiring the =dbus= package, to run. > > That failing, I decided to try something closer to what =mutter= was doing > with [...] >> (match (primitive-fork) >> (0 ;child process >> (set-child-subreaper!) >> ;; XXX: Tini provides proper PID1-like signal >>handling that >> ;; reaps zombie processes, necessary for the >> ;; 'test_shutdown_subprocesses' test to pass. >> >> ;; TODO: Complete >>https://issues.guix.gnu.org/30948. >> ;; (execlp "tini" "--" "python" "setup.py" >>"test") >> (execlp "tini" "--" >> "dbus-run-session" "--" >> "xvfb-run" "-a" "-s" (getenv >>"XVFB_SERVER_ARGS") >> "python" "setup.py" "test")) >> (pid >> (match (waitpid pid) >> ((_ . status) >> (unless (zero? status) >> (error "`pytest' exited with status" >> status > > I know some bits there are definitely not relevant; I figured I could clean > it up, after, if things worked but I'm still getting the exact same errors. > > Just to make sure /I'm/ not doing something incorrectly, is this within what > you meant? Or did I do anything that's obviously not correct, in this setup? The important bits are the fork, the (set-child-subreaper!) in the child process (forked) and the (execlp "tini" "--" your-test-commands). If this doesn't improve things, the problem may be elsewhere. -- Thanks, Maxim
Re: Specifying rust version
Hi, phodina writes: [...] >> It's typical that build system or services expose a way for the user to >> use a variant of a package, but in the case of rust, I don't think it >> should be advertised as a way to use different rust versions (given only >> the last version is supported by upstream, e.g. sometimes fixing CVEs). > > I have to agree with you that this is just an anti-pattern and the #:rust > should not be advertised. > > The best approach would be to add new rust version and switch to it. > > So do you think Maxim the `#:rust` parameter should be dropped and the > documentation also removed? I don't think it needs to be dropped, as it can be useful for experimentation. Sometimes, newer rust may be needed and the work to update the entire collection (with the risks it entails or the build time) deferred, in which case it could be used. It's preferable though to do the work to package the latest and greatest rust and rebuild the whole collection with it, on a branch though. I hope that helps, -- Thanks, Maxim
Re: Specifying rust version
Hello, Efraim Flashner writes: > On Mon, Dec 26, 2022 at 09:00:40AM +, phodina wrote: >> Hi, >> >> the documentation for 'cargo-build-system' [1] refers to parameter >> '#:rust' which allows user to specify the Rust compiler version. >> However, I've found this commit >> 9635119a61a9ab1b023558727fcdf1816fdc7fc6 from Maxim which makes all >> 'rust-.*' definitions private. Is there a way to specify newer Rust >> compiler? Something like 'rust-next'? The package requires version >> 1.62 but the current is 1.60. Also both version are already defined. >> What's missing is just way to select them. >> >> [1] https://guix.gnu.org/manual/en/html_node/Build-Systems.html >> > > I checked gnu/packages/rust.scm and it looks like the rust packages > aren't hidden but actually not exported. If they were just hidden then > you could still do `#:rust ,rust-1.62`. Since they're actually not > exported you need to use the not-really-supported `@@` to refer to that > variable, so you'd have to use something like: > #:rust ,(@@ (gnu packages rust) rust-1.62) Normally only the newest released Rust version is supported by upstream, so what we should do is add a newer rust and use it by default. The reasons previous rust versions are not exported is because they aren't intended to be used by applications; they are built using '--stage=1' to speed up compilation, which creates slower binaries and may expose ABI stability problems (*if I remember the rust people's explanation correctly). When adding new version of rust, we move all the tests and final rust version specifics to the leaf (last) rust version, and keep the intermediary rusts minimal (no test, no tools, stage=1, etc.) > Given how it would be useful to have access to newer rust versions I > think it'd be worthwhile to make a post in guix-devel about making the > newer versions of rust use define-public but be hidden, so they can be > used as expected for the #:rust keyword. It's typical that build system or services expose a way for the user to use a variant of a package, but in the case of rust, I don't think it should be advertised as a way to use different rust versions (given only the last version is supported by upstream, e.g. sometimes fixing CVEs). -- Thanks, Maxim
Re: Can't type Japanese anymore
Hi Luis, Luis Felipe writes: > Hello, > > After upgrading recently to Guix System 9cb42f7, I can't type Japanese > anymore. It disappeared from the list, even though I still have > ibus-anthy installed. > > Also, the workaround in https://issues.guix.gnu.org/35610 does not work > anymore. > > If you are using a more recent version of the system, can you type Japanese > normally? I just tried, and it doesn't work for me either :-/. Not sure if it's cache related, or a more serious issue. -- Thanks, Maxim
Problems running Guix System initrd on an i.MX6 ARM board
Hi Guix! I've been trying for some time to run Guix System on an ARM board (a TS-7970 with an i.MX6 Cortex A9 CPU). I wanted to cross-compile the image for speed and efficiency, and stumbled upon some problems on the way, such as https://issues.guix.gnu.org/44924, fixed on core-updates. Then it took me some time to figure out that Guile 3.0.7 was segfaulting when running the initrd's init script, which would cause the following kernel panic and backtrace: --8<---cut here---start->8--- [5.913371] ALSA device list: [5.913374] #0: On-board Codec [5.913376] #1: imx-hdmi-soc [5.921483] sdhci-esdhc-imx 219.usdhc: card claims to support voltages below defined range [5.938332] mmc0: new SDIO card at address 0001 [5.987225] mmc2: new DDR MMC card at address 0001 [5.998025] mmcblk2: mmc2:0001 MMC04G 3.60 GiB [6.009623] mmcblk2boot0: mmc2:0001 MMC04G partition 1 16.0 MiB [6.020181] mmcblk2boot1: mmc2:0001 MMC04G partition 2 16.0 MiB [6.031772] mmcblk2rpmb: mmc2:0001 MMC04G partition 3 128 KiB [6.957080] Freeing unused kernel memory: 1024K (80e0 - 80f0) [6.967865] Kernel panic - not syncing: Attempted to kill init! exitcode=0x8b00 [6.967865] [6.977015] CPU3: stopping [6.979732] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.11-tsimx #1 [6.986174] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [6.992704] Backtrace: [6.995189] [<80111d48>] (dump_backtrace) from [<80111f38>] (show_stack+0x18/0x1c) [7.002765] r7: r6:2193 r5: r4:80f2fecc [7.008437] [<80111f20>] (show_stack) from [<8054d61c>] (dump_stack+0x80/0x9c) [7.015669] [<8054d59c>] (dump_stack) from [<8010d8dc>] (handle_IPI+0xe0/0x178) [7.022981] r7: r6:d80b1f18 r5:0003 r4:80e7f034 [7.028648] [<8010d7fc>] (handle_IPI) from [<801014d8>] (gic_handle_irq+0x70/0x78) [7.036222] r7:f4a01100 r6:80f0358c r5:f4a00100 r4:d80b1f18 [7.041895] [<80101468>] (gic_handle_irq) from [<80a0a34c>] (__irq_svc+0x6c/0xa8) [7.049380] Exception stack(0xd80b1f18 to 0xd80b1f60) [7.054434] 1f00: 0001 [7.062617] 1f20: 59eaf000 dad2fec0 9fdcb41d 9f4ecbfd dad2f1a8 0001 [7.070800] 1f40: 0001 d80b1f9c d80b1f68 d80b1f68 80826350 80826374 6113 [7.078981] r7:d80b1f4c r6: r5:6113 r4:80826374 [7.084651] [<80826284>] (cpuidle_enter_state) from [<80826488>] (cpuidle_enter+0x1c/0x20) [7.092921] r10:d80b1fc0 r9:80e801a0 r8:80f030f4 r7:d80b r6:0003 r5:80f08cd4 [7.100752] r4:dad2f1a8 [7.103301] [<8082646c>] (cpuidle_enter) from [<80165ccc>] (call_cpuidle+0x3c/0x40) [7.110966] [<80165c90>] (call_cpuidle) from [<80165f48>] (cpu_startup_entry+0x188/0x1a8) [7.119149] [<80165dc0>] (cpu_startup_entry) from [<8010d5b8>] (secondary_start_kernel+0x134/0x164) [7.128196] r7:80f8d320 r4:80f14490 [7.131779] [<8010d484>] (secondary_start_kernel) from [<1010156c>] (0x1010156c) [7.139178] r7:80f8d320 r6:10c03c7d r5:0051 r4:6809806a [7.144839] CPU1: stopping [7.147554] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.11-tsimx #1 [7.153996] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [7.160524] Backtrace: [7.162999] [<80111d48>] (dump_backtrace) from [<80111f38>] (show_stack+0x18/0x1c) [7.170573] r7: r6:2193 r5: r4:80f2fecc [7.176242] [<80111f20>] (show_stack) from [<8054d61c>] (dump_stack+0x80/0x9c) [7.183471] [<8054d59c>] (dump_stack) from [<8010d8dc>] (handle_IPI+0xe0/0x178) [7.190783] r7: r6:d80adf18 r5:0001 r4:80e7f034 [7.196449] [<8010d7fc>] (handle_IPI) from [<801014d8>] (gic_handle_irq+0x70/0x78) [7.204022] r7:f4a01100 r6:80f0358c r5:f4a00100 r4:d80adf18 [7.209689] [<80101468>] (gic_handle_irq) from [<80a0a34c>] (__irq_svc+0x6c/0xa8) [7.217173] Exception stack(0xd80adf18 to 0xd80adf60) [7.27] df00: 0001 [7.230410] df20: 59e93000 dad13ec0 9fdcb2cf 9f4ecbfd dad131a8 0001 [7.238592] df40: 0001 d80adf9c d80adf68 d80adf68 80826350 80826374 6013 [7.246773] r7:d80adf4c r6: r5:6013 r4:80826374 [7.252439] [<80826284>] (cpuidle_enter_state) from [<80826488>] (cpuidle_enter+0x1c/0x20) [7.260709] r10:d80adfc0 r9:80e801a0 r8:80f030f4 r7:d80ac000 r6:0001 r5:80f08cd4 [7.268539] r4:dad131a8 [7.271082] [<8082646c>] (cpuidle_enter) from [<80165ccc>] (call_cpuidle+0x3c/0x40) [7.278746] [<80165c90>] (call_cpuidle) from [<80165f48>] (cpu_startup_entry+0x188/0x1a8) [7.286931] [<80165dc0>] (cpu_startup_entry) from [<8010d5b8>] (secondary_start_kernel+0x134/0x164) [7.295979] r7:80f8d320 r4:80f14490 [7.299560] [<8010d484>] (secondary_start_kernel) from
Re: guix shell: error: mount: Invalid argument
Hi, Tobias Geerinckx-Rice writes: [...] > ~ λ guix shell -C --expose=/proc=/test coreutils -- echo Elmo > world > guix shell: error: mount: mount "/proc" on > "/tmp/guix-directory.zTa1qb//test": Invalid argument > > > Weird! Clearly, /proc is imbued with magical Kernel magick and > simply canno— what? Oh: > > ~ λ mount | grep /proc > none on /proc type proc (rw,relatime) > binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc > (rw,relatime) > > > Surely not… > > ~ λ sudo umount /proc/sys/fs/binfmt_misc > > ~ λ guix shell -C --expose=/proc=/test coreutils -- echo Elmo > world > Elmo world > > …huh. > > So, ‘guix shell --container’ apparently takes issue with rbind'ing > mounts, or something like that. > > Maybe that's something Guix can handle by bind-mounting the entire > subtree itself, or maybe it's a hard permissions error enforced by > the kernel. I don't know. > > Someone with podman/Docker/similar experience might. I'm not useful, but just want to point out that this looks a lot like https://issues.guix.gnu.org/46782 (guix environment --expose options cannot be layered onto $PWD). -- Thanks, Maxim
Re: program prepared with `guix pack` unusable by end users
Hello, Wojtek Kosior writes: >> > IMHO yes, the pack output does not work as expected. That's the >> > definition of a bug. >> >> I disagree. That Python gives precedence to USERSITE compared to >> site-packages and GUIX_PYTHONPATH is by design, so that users can >> override system provided libraries such as those by Guix. It used to be >> the other way around, and it caused all sort of problems such as >> virtualenv not working as expected on Guix. My memory failed me here; the past problems with Guix and virtualenv had to do with us (ab)using PYTHONPATH, which would take precedence above everything and not get reset by virtualenv, if I remember. --8<---cut here---start->8--- $ . bin/activate (venv) maxim@hurd /tmp/venv [env]$ python -m site sys.path = [ '/tmp/venv', '/gnu/store/bbakd2h7s4g62fymjmqpxgvlanp1ydny-python-3.9.9/lib/python39.zip', '/gnu/store/bbakd2h7s4g62fymjmqpxgvlanp1ydny-python-3.9.9/lib/python3.9', '/gnu/store/bbakd2h7s4g62fymjmqpxgvlanp1ydny-python-3.9.9/lib/python3.9/lib-dynload', '/tmp/venv/lib/python3.9/site-packages', ] USER_BASE: '/home/maxim/.local' (exists) USER_SITE: '/home/maxim/.local/lib/python3.9/site-packages' (doesn't exist) ENABLE_USER_SITE: False --8<---cut here---end--->8--- We can see that virtualenv disables loading libraries from USER_SITE (ENABLE_USER_SITE: False). We can also see that it puts its site-packages directly on sys.path. > Perhaps the best solution would be to > * have Python interpreter itself give precedence to user site packages but > * have user site disabled (or enabled with lower precedence) by default > for Python applications. > > Consider the creation of wrapper script for python programs as it is > done now[1]. Is there currently any application that would behave > incorrectly with PYTHONNOUSERSITE exported as 1 and > `~/.local/lib/python/site-packages/` included in > GUIX-PYTHONPATH after the other paths? If there is, perhaps it would be > at least easier to make a workaround for this single application? I agree that setting PYTHONNOUSERSITE to 1 in the wrapper of Python commands to ensure no stray user-installed librairies from under "~/.local/lib/python/site-packages/" clash with their operation would make sense. Note that this is an interoperability problem between 'guix' and 'pip', for 'pip install x' users that end up filling their "~/.local/lib/python/site-packages/" directory. If you 'rm -rf ~/.local/lib/python*' and stick to use only Guix-provided packages, they won't experience any issue. -- Thanks, Maxim
Re: How to avoid downloading qtbase:debug
Hi, Efraim Flashner writes: > On Sat, Oct 22, 2022 at 12:39:54PM +0200, Csepp wrote: >> >> kiasoc5 writes: >> >> > Dear Guix, >> > >> > =guix shell qtbase= downloads the entire debug output of qtbase even >> > though I didn't write down qtbase:debug. That's hundreds of megabytes >> > of bandwith I didn't want to use. How do I avoid downloading the debug >> > output? Is this a bug? >> >> I think it should be considered a bug. guix shell always downloads >> every output of all the packages. > > I assume it's related to grafts: > > (ins)efraim@3900XT ~$ guix shell qtbase@6 > 321.1 MB will be downloaded > qtbase-6.3.1-debug 287.7MiB 3.7MiB/s 00:01 [ ] 1.4%^C > (ins)efraim@3900XT ~$ guix shell --no-grafts qtbase@6 > (ins)efraim@3900XT ~ [env]$ > exit > > Looks like it downloads all the outputs so it can perform grafts on all > the outputs, and only then does it put just qtbase in the environment. Yes, and this is because grafts have been marked as non-substitutable by choice, for performance considerations. Would revisiting this choice helps here (making graft derivations substitutable?). -- Thanks, Maxim
Re: How to avoid downloading qtbase:debug
Hi, Csepp writes: > kiasoc5 writes: > >> Dear Guix, >> >> =guix shell qtbase= downloads the entire debug output of qtbase even >> though I didn't write down qtbase:debug. That's hundreds of megabytes >> of bandwith I didn't want to use. How do I avoid downloading the debug >> output? Is this a bug? > > I think it should be considered a bug. guix shell always downloads > every output of all the packages. Yes, that's annoying. I think it has to do with grafts; when a package must be grafted, all its output must be available. Grafts complicates many things, but unfortunately they are necessary to provide timely security updates. I don't see a bug anymore for that one, we should try to improve things here; feel free to report it to bug-g...@gnu.org, perhaps with a title like "grafts cause all outputs to be downloaded". Perhaps a solution would be making graft derivations substitutable (currently they happen on the local machine). -- Thanks, Maxim
Re: When do you re-export?
Hi jgart, jgart writes: > Hi, > > When should I re-export something in a module? > > docs say the following: > > Add all variables (which must be symbols or pairs of symbols) to the > list of re-exported bindings of the current module. Pairs of symbols > are handled as in export. Re-exported bindings must be imported by the > current module from some other module. > > The docs don't explain why you would want to even do a re-export in the first > place... I've used in two places, I think: 1. Move code around while preserving backward compatibility. 2. For convenience (when people importing B would typically also want something from A). Best used very sparingly, or not at all, I'd say :-). -- Thanks, Maxim
Re: Trouble with nfs mount
Hi, Fredrik Salomonsson writes: [...] > ---✂ > … > shepherd: Evaluating user expression (and (defined? (quote transient?)) (map > (# ?) ?)). > guix system: warning: exception caught while executing 'start' on service > 'file-system-/media/Valhalla': > In procedure mount: mount "fafner:/srv/nfs4/Valhalla" on "///media/Valhalla": > Invalid argument > guix system: warning: some services could not be upgraded > … > > > So that's probably what's happening during boot. > > I have no idea how it transforms the mount-point from "/media/Valhalla" > to "///media/Valhalla" and if that's a red herring. > > Any ideas what I'm doing wrong? Nothing; mounting an NFS file system at boot is not supported currently with Guix System; see the related issue #47706. My current ugly workaround is to define the mount points with "(mount? #f)" and mount them via a script post boot, e.g.: --8<---cut here---start->8--- (file-system (device "jami-buildmachine-04:/srv/nfs/jami") (mount-point "/var/cache/jami") (create-mount-point? #t) (type "nfs") (mount? #f) (options "soft,user")) --8<---cut here---end--->8--- -- Thanks, Maxim
Re: bash scripts in Guix question
Hi,
Olivier Dion writes:
[...]
>> I prefer the "#!/usr/bin/env bash" shebang; /usr/bin/env is available on
>> FHS distribution, and on Guix System, for convenience. You can use if
>> for any interpreted script, such as Guile, Python, Perl, etc.
>
> Only if coreutils is in the profile that would work yes.
coreutils doesn't need to be in the profile since /usr/bin/env is linked
to (file-append coreutils "bin/env"); see in the value of %base-services
in (gnu services base), which contains:
--8<---cut here---start->8---
(service special-files-service-type
`(("/bin/sh" ,(file-append bash "/bin/sh"))
("/usr/bin/env" ,(file-append coreutils "/bin/env"
--8<---cut here---end--->8---
'env' looks up the command passed to it from PATH, but that's usually
satisfied if you were going to use a FHS location anyway such as
"/bin/bash".
--
Thanks,
Maxim
Re: bash scripts in Guix question
Hi, Olivier Dion via writes: > On Tue, 04 Oct 2022, jordi wrote: >> Hi guixers, >> >> i'm wondering...for my scripts to work in Guix, instead of >> '#! /bin/bash' , >> > > Typically the `sh' program should be a symlinked to `bash' in your > system profile. I think it is the case for many distro. If you want it > to be bulletproof though for other distros maybe something like that: > > #!/bin/sh > if [ "$(basename $SHELL)" != "bash" ]; then > exec bash "$0" "$@" > fi > > echo "hey!" I prefer the "#!/usr/bin/env bash" shebang; /usr/bin/env is available on FHS distribution, and on Guix System, for convenience. You can use if for any interpreted script, such as Guile, Python, Perl, etc. -- Thanks, Maxim
Re: What Python IDE are you using?
Hello, For what it's worth, I used Emacs with Elpy. I have python-ipython, python-ipdb, and python-pdbpp installed, and to debug I use put 'breakpoint()' in the code, along the PYTHONBREAKPOINT=ipdb.sset_trace environment variable. As an IPython configuration I have the lines: --8<---cut here---start->8--- ## lines of code to run at IPython startup. c.InteractiveShellApp.exec_lines = ['%autoreload 2'] ## A list of dotted module names of IPython extensions to load. c.InteractiveShellApp.extensions = ['autoreload'] --8<---cut here---end--->8--- Enabled in a ~/.ipython/profile_default/ipython_config.py file. It works decently for me. HTH, Maxim
Re: xcons is a con?
Hi, jgart writes: > Hi Guixers, > > What is a non-trivial use of xcons in the context of a hof? > > I realize I can use fold to reverse a list with xcons but how do > guixers use xcons in the common practice? I don't :-). But thanks for letting me know xcons was a thing. Maxim
Re: Cannot input the character ê using Emacs on Debian11
Hi, "cont...@phfrohring.com" writes: > Hello, > > I've recently setup two Debian11 machines, intalled Guix then Emacs using > `guix install emacs`. > For some reason, it's impossible de input the `ê` character after `emacs -Q` ; > but it is possible to enter the `ê` character after `emacs -Q -nw`. > > How to have `guix install emacs` install Emacs in such a way that accents > like `ê` can be written? > > Thank you, > PHF Did you install glibc-locales and set GUIX_LOCPATH as mentioned in info "(guix) Application Setup" ? HTH, Maxim
Re: substitute for Skype
Hi Luis, Luis Felipe writes: > Hi Gottfried, > > On Monday, August 1st, 2022 at 15:47, Gottfried wrote: > >> Has somebody got experience with Jami or Mumble? > > I've used Jami until recently. As other people already mentioned, installing > the "jami" package should be enough. > > I only used it to converse with one person at a time, not group > [audio|video]chats. When it worked, it was enjoyable. Unfortunately, most of > the time it didn't. > > I tried it for several months at different times, checking if upgrades > would improve the experience, but the experience wasn't good enough to > grow a list of contacts that included people from mainstream culture > (people used to WhatsApp and proprietary software in general). The few > contacts I had (~5) eventually stopped using the application because > of its constant malfunctioning. Some contacts left making harsh > comments about it. > > Most noticeable problems: > > • Missing messages > • Sharing images, voice messages and files seldom worked Sadly, I can relate. Luckily there is some hope. The new swarm mechanism for syncing conversations via libgit is maturing and promises to avoid the loss of messages when delivery can't happen in real time (such as when the remote participant is offline). I think the latest release we have packaged already implements it in 1:1 conversations. Mobile clients may have other issues (the need to use push notifications or a gateway server to the distributed network to avoid wasting the tiny battery in a few hours introduces its own share of complications -- and bugs). Thanks for having shared your experience! Maxim
Re: substitute for Skype
Hi Gottfried, Gottfried writes: > Thanks for all answers, > > I want to use my laptop and talk to somebody or even exeptionally to > others (several people) in a room, connected through one > laptop. (through more laptops - I haven't done it yet, so I don't > know) > > Earlier I used Skype. > > Jitsi Meet isn't in guix. But Jami is there. > > > There are 8 packages for Jami, do I need to install all of them? > > > ffmpeg-jami 4.4.2 Audio and video framework htttps://www.ffmpeg.org/ > > jami 20220726.1515.da8d1da Qt Jami client https://jami.net > > jami-gnome20220726.1515.da8d1da Qt Jami client https://jami.net > > jami-qt 20220726.1515.da8d1da Qt Jami client https://jami.net > > libjami 20220726.1515.da8d1da Jami core library and daemon > https://jami.net/ > > libring 20220726.1515.da8d1da Jami core library and daemon > https://jami.net/ > > node-jsondiffpatch0.3.11 Diff & Patch for Javascript objects > https://github.com/benjamine/jsondiffpatch > > pjproject-jami2.11-0.e1f389d Session Initiation Protocol (SIP) > stack https://www.pjsip.org You should 'guix pull'; it was updated yesterday. Now there's only one client package, 'jami'. You can run it via 'guix shell jami -- jami' to try it out, or install it. I'd suggest getting to know jami itself before venturing into jami-service-type. You can already make calls and add more users manually to get started. When you want some permanent channel that people can call and join automatically, jami-service-type will provide value. Thanks, Maxim
Re: substitute for Skype
Hi Gottfried,
"(" writes:
> On Mon Aug 1, 2022 at 12:55 PM BST, Akib Azmain Turja wrote:
>> There is a software named Jitsi Meet, through I think that's not what
>> you want.
> Also, Jitsi only really has a web application. (There *is* a desktop app,
> but it's written in Java and appears to be abandoned, and it's not in
> Guix.)
I think Jami may be the closest thing to Skype we have. If you are
interested in setting up persistent conference rooms, you may be
interested in the jami-service-type as well, which makes it easy to host
such on headless servers.
Thanks,
Maxim
Re: help: perl library fails to be discovered in guix package
Hi, jgart writes: > Hi, > > Does anyone happen to know why this package fails to find perl-timedate? > > https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/misc.scm#L1370 > > Any advice/code review is much appreciated. The file probably changed since then, it's pointing to a package that doesn't has perl-timedate as input. I'm guessing you had forgotten to also include 'perl', which has the search path specification that defines the PERL5LIB environment variable. Thanks, Maxim
Re: Testing Pre-Release Graphical Installer 1.4
Hello, Matias Jose Seco Baccanelli writes: > Morning Guixers! > Following the ml news i read that a new release is upcoming > (1.4 right? exciting!), > Actually i wanted to tryout the graphical installer for testing, should > i simply download the "x86-64" iso of "GNU Guix System on Linux" at the > "download > latest" to have the most recent version of it ? The later will be closer to what is going to be in the next release, so please try that :-). Thank you! Maxim
Re: System not booting after guix gc
Hi, phodina via writes: > Hi, > > I've run the following commands: > > guix system delete-generations > guix gc > sync > > After reboot the system cannot boot and panics. Is there way to recover? > > I can decrypt the LUKS partition with Btrfs, that's where the kernel panics. You could try following the recently added info '(guix) System Troubleshooting Tips' section to chroot into your system from the bootable Guix installation media, and fix your configuration from there. Good luck! Maxim
Re: Modular texlive and xelatex
Hi Andreas, Andreas Enge writes: > Am Fri, Jun 17, 2022 at 09:06:06PM +0200 schrieb Ricardo Wurmus: >> The tlpdb says that this file is provided by the xunicode package – >> which we don’t have yet. >> >> [time passes] > > Not much actually! > >> We now have texlive-xunicode as of commit >> 793ce82c9d5ead8457da9cec8d1d8afc12704f10. > > Thanks a lot! I used "guix import texlive floatflt" to add this package. > Congratulations for a nice importer! (Although I stumbled over needing to > add #:trivial? #t, which becomes obvious only when comparing with > neighbouring packages.) > > The result for my file still is not quite like the monolithic texlive. > First, babel complains as follows: > Package babel Warning: No hyphenation patterns were preloaded for > (babel)the language `German (trad. orthography)' into the > format. > (babel)Please, configure your TeX system to add them and > (babel)rebuild the format. Now I will use the patterns > (babel)preloaded for \language=0 instead on input line 62. > I have installed texlive-generic-babel-german and texlive-hyphen-german; > have you got an idea what I am missing? > > Second, the font (Linux Libertine O) looks ragged, and a "--" is typeset > as two dashes instead of an ndash. Suggestions are also welcome! If you're going for xelatex, I suggest migrating from Babel to Polyglossia, as that's recently been fixed and tested to work fine with e.g. generating the IPython documentation in PDF format. Hope that helps, Maxim
Re: Why Emacs is echoing message for each installed Emacs package while startup
Hi, [...] >> > But, why is the message is shown? Can someone remove it? It would >> > probably be better that I myself clone the repo, fix it and send the >> > patch, but my hard disk space isn't allowing me to do that. Is it >> > possible disable that message by modifing any Guix configuration file? > >> Like Simon, I do not see why the autoloads-related messages are a >> problem; they only occur when starting Emacs from scratch. If you have >> so many packages that the loading time or loading messages bothers you, >> you may want to consider running Emacs as a server and connecting to it >> via emacsclient; that way you load it once when you login to your >> session for example and that's it. > >> For what it's worth, the messages are not printed by that custom Guix >> Elisp code explicitly but by the Emacs function `load', on line 59 of >> guix-emacs.el: (load f 'noerror). If it really bothers you could change >> it to: > >> (load f 'noerror 'nomessage) > >> Hope that helps, > >> Maxim > > > The messages also appear when viewing the *Async-native-compile-log* when > Emacs is native compiling packages. And the all of the "loading packages" > messages are repeated before /each/ package that is compiled. That's not with the Emacs in Guix I guess, since we do not yet have native compilation enabled. But it seems like the problem here is not the printing of the messages, but why when natively compiling packages it would cause all the packages to be reloaded for each package... which is crazy. Maxim
Re: Why Emacs is echoing message for each installed Emacs package while startup
Hi, Akib Azmain Turja writes: > zimoun writes: > >> Hi, >> >> On Wed, 18 May 2022 at 22:29, Akib Azmain Turja wrote: >> >>> The timing maybe wrong, because it is more a year old (and I didn't >>> measure). I was new to Emacs Lisp (I used Doom before), and my init.el >>> was messy. So maybe the init file had something in it that was >>> responsible for slow startup when the packages managed by Guix. >> >> Well, if you are able to time the two setups: the one using package.el >> and ’leaf’ and the other one using Guix (and probably replacing the >> lines «:ensure :package :feather :straight :el-get» to use instead the >> Emacs packages installed by Guix). >> >> It could be informing about the potential gap. There were timings made in the past when considering using the builtin package.el to take care of some of the things we do, but it's much more code than what we have and is unsurprisingly a bit slower. If you look at the guix-emacs.el file that takes care of autoloads discovery you'll see there's really not much to it, if fits all under 100 lines of code. > But, why is the message is shown? Can someone remove it? It would > probably be better that I myself clone the repo, fix it and send the > patch, but my hard disk space isn't allowing me to do that. Is it > possible disable that message by modifing any Guix configuration file? Like Simon, I do not see why the autoloads-related messages are a problem; they only occur when starting Emacs from scratch. If you have so many packages that the loading time or loading messages bothers you, you may want to consider running Emacs as a server and connecting to it via emacsclient; that way you load it once when you login to your session for example and that's it. For what it's worth, the messages are not printed by that custom Guix Elisp code explicitly but by the Emacs function `load', on line 59 of guix-emacs.el: (load f 'noerror). If it really bothers you could change it to: (load f 'noerror 'nomessage) Hope that helps, Maxim
Re: Installation: Load non-free wifi firmware (iwlwifi)
Hello, 白い熊＠相撲道 writes: > On 2022-05-11 14:31, yasu wrote: >> This is also an old topic, but we need lesser-help-guix@... >> The help-guix@... seems so much against even discussion of such >> things... >> So for now (and let me stress, I do not like this situation of self- >> imposed-gagging and would like to help create alternative communication >> forums), let me send you something personally! > > Many thanks, Yasu. > > I was able to get it working according to the instructions sent > privately, including adding a channel for the kernel source etc. > > Seeing as how there might have been criticism in the past here on the > list in discussing topics, which some think are inconducive to promote > software freedom - I don't wish to damage the culture here and fully > describe the solution, if it is indeed frowned upon here. > > On the other hand, I feel the same way as Yasu describes above - for > instance for me I think seeing the solution, which I could not have > figured out myself is actually conducive towards learning more guix > and scheme and perhaps developing some snippets in the future that > could help someone else. > > For this reason I'd think it'd be beneficial to fully discuss the Guix > solution here. Moderators - can you give guidance on this? Nothing has changed regarding the GNU Guix policy regarding free software, which stems from the requirements of a GNU FSDG distribution [0]; it is about including only free software in the distribution and providing support only for free software. This means this is not the right place to discuss how to install/configure nonfree software which is not part of GNU Guix. Yasu, you've been sharing your opinion about this many times here; enough times that it's starting to be mildly annoying, to me at least :-). GNU Guix is not and won't be a place to discuss nonfree software; I'd appreciate if you could stop advertising your idea to create some parallel, nonfree community on Guix channels. You are free to do so if you like, but don't please don't advertise it on the Guix project communication channels. I personally think this policy is a plus that makes the project stand out; GNU FSDG distributions are rarer than non-FSDG ones, after all, and free software as at the heart of GNU and GNU Guix. We should be thankful for it :-). Thank you for your understanding, Maxim [0] https://www.gnu.org/distros/free-system-distribution-guidelines.html
Re: Impressions after 4 years of using Guix ( + guix-hurd logo ?) :)
Hi Hubert, Hubert Lombard writes: > Hi Luis ! > >>I think they could work for many things. I particularly liked these: >> >>https://www.hubert-lombard.website/image5.php#grand-format >>https://www.hubert-lombard.website/image8.php#grand-format >>https://www.hubert-lombard.website/image12.php#grand-format >>https://www.hubert-lombard.website/image13.php#grand-format Wow! That is serious talent. It looks stunning! Like Luis, I think a GNU-themed painting of yours could make for a beautiful desktop background image for GNU Guix. No pressure, just ideas and encouragement :-) Thanks for sharing, Maxim
Re: Screen sharing ungoogled-chromium
Hello, phodina via writes: > Jitsi works in chromium and I'm able to share screen. > > But I'm trying to switch to Guix as my work laptop but in order to do > that the Teams screen share would have to work. > > Anyway it's proprietary garbage so if there isn't anybody who got it > working let's just close the discussion. If it's anything like the Google Meet proprietary SaaS, it may requires Google-specific WebRTC extensions not yet part of the standard (dubbed "Hangout Services Extension" and disabled in ungoogled-chromium). I remember reading this interesting related discussion about the "Hangout Services Extension" [0]. I'm not sure it's related, but who knows! [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886358 HTH, Maxim
Re: Questions regarding substitutes with debug output
Hi, Olivier Dion writes: > On Sat, 23 Apr 2022, Maxim Cournoyer wrote: > >> When the package uses the gnu-build-system, it is usually just adding a >> "debug" outputs and the copying of the stripped symbols to this output >> is taken care of automatically. Some packages use their own flags or a >> release build without symbols in which case just adding "debug" alone >> won't be enough. > > Right. My guess is that project using autotools are handled > automagically. Although, I don't know of any configuration option for > splitting debug symbols from binaries in autotools. If you are curious, it's defined in the 'strip' phase in (guix build gnu-build-system). By default Autoconf causes the builds to include the debug symbols (-g). In the usual case (no "debug" output defined on a Guix package), these debug symbols are simply stripped (using 'strip', part of GNU binutils) and discarded. When the "debug" output exists, the debug symbols are instead copied to the debug output. It should also work with the other C/C++ build systems such as meson-build-system or cmake-build-system so long as they generate debug symbols by default (which they should). I hope that helps, Maxim
Re: Questions regarding substitutes with debug output
Hello,
Olivier Dion writes:
> On Fri, 22 Apr 2022, Maxim Cournoyer wrote:
>>> I require debugging symbols of multiple packages. Some of them
>>> already have a debug output from the main guix channel, but others
>>> don't. So I had in mind to make a channel and publish the
>>> substitutes with the debug outputs.
>>
>> In general, if you need debug symbols for something, I think it's OK
>> to contribute adding them to Guix proper (in a debug output), unless
>> they make like >= 1 GiB (as I can imagine may be the case for IceCat).
>
> Okay I will try. I'm not sure how easy it is so add debug symbols to some
> packages e.g. git, nginx. In any case I need them, so I will contribute
> back to the main channel if it works.
When the package uses the gnu-build-system, it is usually just adding a
"debug" outputs and the copying of the stripped symbols to this output
is taken care of automatically. Some packages use their own flags or a
release build without symbols in which case just adding "debug" alone
won't be enough.
>>> How could I make sure that Guix use my version of Firefox over the one
>>> defined by the main channel? My guess is to change the name of my
>>> package to something like "my-firefox". But it would be nicer if I
>>> don't have to do so. Perhaps there's a way to force channel
>>> preference?
>>
>> Channels can only extend, not override the default Guix channel (the
>> world would be a bit of a mess if it did). So the easiest path is to
>> use a different name; alternatively for graph rewriting you could use
>> the various APIs to effect package transformations.
>
> Would be nice to have some way to specify channel in a package
> specification. I don't think that it would break things if we
> considerer channels as namespaces, i.e. different graph. A
> specification like:
>
> {channel}package@version:output
>
> would be useful. For now I will just rename them to "my/package".
That could be neat, yes. I wonder how easy/difficult its implementation
would be.
Thanks,
Maxim
Re: Questions regarding substitutes with debug output
Hi Olivier, Olivier Dion via writes: > Hi, > > I require debugging symbols of multiple packages. Some of them already > have a debug output from the main guix channel, but others don't. So > I had in mind to make a channel and publish the substitutes with the > debug outputs. In general, if you need debug symbols for something, I think it's OK to contribute adding them to Guix proper (in a debug output), unless they make like >= 1 GiB (as I can imagine may be the case for IceCat). [...] > How could I make sure that Guix use my version of Firefox over the one > defined by the main channel? My guess is to change the name of my > package to something like "my-firefox". But it would be nicer if I > don't have to do so. Perhaps there's a way to force channel > preference? Channels can only extend, not override the default Guix channel (the world would be a bit of a mess if it did). So the easiest path is to use a different name; alternatively for graph rewriting you could use the various APIs to effect package transformations. > I know that we can specify version like "firefox@99" but what about > outputs? Is it possible to do (list "firefox:out" "firefox:debug").? I know nothing about GWL, but if it uses the Guix-provided specification->package procedure, it would work that way yes.n I hope that helps, Cheers! Maxim
Re: Tex packages on core-updates failing
Hi, phodina via writes: > Hi, > > I'm attempting to build packages on branch core-updates > (3f2b0e12f1ef0cc9e13d5ae00275fee8a0fa752d) and it seems some tex > packages are broken. > > I've attempted to fix one of them - texlive-amsmath - but there's another > failing - texlive-psnfss-fixed. > > I've found issue and applied patches about texlive-psnfss but now it does not > build. [1] > > Could you please help? > > [1] https://issues.guix.gnu.org/53454#6 > > > Petr > > > diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm > index 7fab21679e..c39a568e2b 100644 > --- a/gnu/packages/tex.scm > +++ b/gnu/packages/tex.scm > @@ -4168,11 +4168,15 @@ (define-public texlive-amsmath > (add-before 'copy-files 'unchdir > (lambda _ > (chdir "../../.."))) > - (add-after 'copy-files 'delete-extra-files > - (lambda* (#:key outputs #:allow-other-keys) > - (delete-file-recursively > - (string-append (assoc-ref outputs "out") > - > "/share/texmf-dist/source/latex/amsmath/build" > + (replace 'copy-files > + (lambda* (#:key inputs outputs #:allow-other-keys) > + (let ((origin (assoc-ref inputs "source")) > + (source (string-append (assoc-ref outputs "out") > + "/share/texmf-dist/source")) > + (doc (string-append (assoc-ref outputs "doc") > + "/share/texmf-dist/doc"))) > + (copy-recursively (string-append origin "/source") source) > + (copy-recursively (string-append origin "/doc") > doc I think you're missing a "doc" output. HTH, Maxim
Re: cannot boot from microSD card on aarch64 machine
Hi Ricardo, Ricardo Wurmus writes: > Hi, > >>> I mounted the target disk (an SSD) at /mnt, made sure that the microSD >>> card was inserted, unmounted, and available at /dev/mmcblk1, and then >>> ran >>> >>>guix system init config.scm /mnt >>> >>> This was successful. >>> >>> Unfortunately, rebooting failed. There is seemingly no activity at all >>> when I power on the board, so something’s not right with how u-boot was >>> installed on the microSD card. >>> >>> Does it perhaps install the u-boot files at the wrong offsets? How >>> would I begin to debug this? >>> >>> I’d appreciate any hints. >> >> Sorry, I don't have any clue to offer, but were you able to solve or >> workaround your problem? > > Not quite, but I’ve learned more and understand the problem better. > > I manually copied the two u-boot files to the expected offsets on the > microsd card, and that let me boot Guix System from USB. But I have so > far been unsuccessful in my attempts to do this automatically as part of > “guix system init” (I haven’t tried this much) or to successfully patch > u-boot to boot from the SSD on the PCIe card (I have tried this a > lot). Heh, sounds tricky. > My next step is to attempt to install the whole system onto the microsd > card, just to end up with a usable system. If that works then nothing > is wrong with Guix (except for a lack of documentation), but it would be > a disappointing workaround. > > I think it should be possible to patch u-boot to initialize the PCIe > card and boot from the attached disk (with the patched u-boot residing > on the microsd card). I tried the relevant subset of the netbsd > patches, but the CPU keeps resetting after (successfully) enumerating > the PCI devices. If I recall from my limited experience with an embedded ARM, you'd have to register the newly supported hardware in the device tree of U-Boot/the kernel; do the patches applied take care of that? > I hope I can make some more time for this soon and overcome that last > hurdle — and then write a cookbook entry for all this :) I wish you luck! Cheers, Maxim
Re: Activate multiple profiles inside emacs
Hi Reza, Reza Housseini writes: > Hi Guix > > Say I have several projects each with their specific profile > containing the needed dependencies and a profile for all my Emacs > specific stuff. > > Now I want to work on a projects inside Emacs and make therefore a > union of the project specific profile and my Emacs profile. So as for > example pylint does not complain about missing modules inside my > project source code. > > As I understand I could source my needed profile files in a shell and > then start Emacs from there, but this makes it quite cumbersome to > switch projects as I have to restart Emacs every time. > > Is there a possibility to achieve the same while Emacs keeps running? > > How do you guixers handle this scenario? Or is there an obvious > solution to my needs? Typically, I keep a manifest.scm per project, then create the environment with 'guix shell', retrieve the profile link with 'echo $GUIX_ENVIRONMENT' within that environment, which I then pass to the 'guix-set-emacs-environment' Emacs procedure, which is provided by the 'emacs-guix' package. Clunky, but it works for me. Hope that helps, Maxim
