Re: Stable endpoint to fetch guix binary
Ludovic Courtès writes: > Hi, > > André A. Gomes skribis: > >> The latest Guix binaries can be fetched via >> >> https://ci.guix.gnu.org/search/latest/archive?query=spec:tarball+status:success+system:x86_64-linux+guix-binary.tar.xz >> >> However, this doesn't always work. For instance, as of now, it returns >> error 502. > > There’s no other endpoint. This bug is tracked at > <https://issues.guix.gnu.org/64317> and will hopefully be fixed in the > not-too-distant future. Great, thanks! -- André A. Gomes Atlas Engineer - https://atlas.engineer/
Stable endpoint to fetch guix binary
Hello Guix, The latest Guix binaries can be fetched via https://ci.guix.gnu.org/search/latest/archive?query=spec:tarball+status:success+system:x86_64-linux+guix-binary.tar.xz However, this doesn't always work. For instance, as of now, it returns error 502. Is there a more reliable way to get it? Thanks! -- André A. Gomes Atlas Engineer - https://atlas.engineer/
Making sense of webkitgtk and webkitgtk-next
Hi Guix, I noticed that webkitgtk-next is defined in such a way that its name is set to "webkitgtk", not "webkitgtk-next". This contrasts with how other *-next packages are defined, such as emacs-next. With respect to webkitgtk, if I run: --8<---cut here---start->8--- guix install webkitgtk --8<---cut here---end--->8--- the version assigned in webkitgtk-next will be installed. On the other hand, all packages that depend on webkitgtk will be build with version according to version assigned to %webkit-version. I think I'm correct since I've just installed cl-cffi-gtk (which depends on webkitgtk) and the REPL told me: --8<---cut here---start->8--- WEBKIT> (format nil "~a.~a" (webkit-get-major-version) (webkit-get-minor-version)) "2.36" --8<---cut here---end--->8--- That is, it picked up the version assigned to webkitgtk, not webkitgtk-next. My question is: shouldn't webkitgtk-next be defined with its name set to "webkitgtk-next" instead of "webkitgtk"? Thanks. -- André A. Gomes "You cannot even find the ruins..."
Re: File search
Ludovic Courtès writes: > Hello Guix! > > Lately I found myself going several times to > <https://packages.debian.org> to look for packages providing a given > file and I thought it’s time to do something about it. My understanding is very limited but I thought that the following blog post could be of any help. https://batsov.com/articles/2022/01/22/how-to-find-which-package-a-file-belongs-to-in-debian-ubuntu/ -- André A. Gomes "Free Thought, Free World"
Re: Language menu in the HTML manual
Ludovic Courtès writes: >> Is that what the icon is supposed to do? If possible, the links should >> go to the same page in the other language, but that might be >> difficult. > > Yes. What makes it difficult is that Texinfo transliterates node names > to ASCII (which I find imperialistic and ridiculous, or at least > anachronistic): While I understand your intention, that might be too harsh. Are you aware of https://en.wikipedia.org/wiki/Punycode? > Probably the easiest (and ugliest?) way to fix it would be to view the > transliteration algorithm as a black box and to implement a mapping from > node names to file names, similar to the indexes computed in > ‘doc/build.scm’. Yes, and transliteration rules change over time too. -- André A. Gomes "Free Thought, Free World"
Re: Guix wiki
Attila Lendvai writes: > this sounds nice, but the reality is that nowadays reviewing and > pushing commits can take weeks or even months without much feedback. i > even have a fix for git-authenticate, coupled with tests that > demonstrate a hole, and it's been open for months. i assume because of > the lack of bandwidth from people who are in position to review and/or > push it, but whatever the reason is, this is the case. > > the vision you are painting here is inspiring, but i think the Guix > community is reaching a size where such an organizational structure is > not facilitating the cooperation well enough. more and more random > people will show up, with contributions of varying levels of > quality. if it all goes through the current choke-points of the core > (people, guix-devel, etc), then they will get overwhelmed, or at least > will limit what could otherwise be achieved with more appropriate > tools/processes. You might have a point here, but I get the feeling that things are slowly changing to address it. Also, it's important to keep in mind that the sporadic contributor will always be more scrutinised. > random example: the readability of plain-text emails pouring into > guix-patches, compared to e.g. threaded, formatted, and > displayed-in-context comment threads in a tool like gitlab. I don't see how gitlab would help. Gnus, for instance, provides the formatting you mention. -- André A. Gomes "Free Thought, Free World"
Re: Guix wiki
zimoun writes: > Hi Tobias, > > On Wed, 12 Jan 2022 at 03:20, Tobias Geerinckx-Rice wrote: > >> I'm disappointed by the ‘bikeshedding’ insult. I really don't >> care what you call it. > > 'insult' is a strong word and I am somehow hurt that you give me this > intention. I do not know what I did wrong --since we both agree we do > not care about the name-- but apparently my contributions to these > email lists lead to misunderstandings -- probably because my English > is not good enough. Therefore, I take a step back and some distance > with this thread and many others. > > >> > - cathedral, as it is today >> >> I object to redefining loaded terms to promote it. > > ..and I already agreed that it was probably a wrong choice. It seems that you're both are on the same page, and got too "excited" about the wording. Please don't draw more importance than it deserves. Simon, I'm sure everyone is eager to listen to your insights. -- André A. Gomes "Free Thought, Free World"
Re: Planet of Guix-related posts?
Matt writes: > On Mon, 10 Jan 2022 10:21:51 -0500 zimoun > wrote > > > (On a side note between parenthesis, we should avoid to fall into the > > "Package Definition" tutorial fallacy; as explained here for monads > > > https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/. > > And I wrote one post about monad and another about Packaging. ;-) > > However, I think the official documentation has enough materials for > > starting to package. End of parenthesis.) > > If many people feel inclined to write their own packaging tutorial, > it's probably an indication that the manual isn't sufficient. I would > urge you and others to not fall into the "don't touch it because it's > good enough for me fallacy". Others may, and probably do, see things > differently. I'd say it indicates that everyone has their own way of assimilating ideas. Often times we map things in our minds by means of simplifications, abuses of languages, imprecisions, etc. -- André A. Gomes "Free Thought, Free World"
Re: Packing Emacs 28.0.91 with native compilation
Ryan Prior writes: > Hey André, glad you're working on this! > > I have an Emacs package with native-compilation, pgtk, sqlite3, xinput2, and > xwidgets that I call "emacs-edge" and have been using daily with Spacemacs. > [1] > > Hope you're able to get yours working, I'd love to move back to an upstream > Guix package instead of limping my own thing along. > > Cheers, > Ryan > > [1] > https://github.com/ryanprior/guix-packages/blob/master/testing/emacs.scm#L17 Great work, thanks for sharing! -- André A. Gomes "Free Thought, Free World"
Re: Packing Emacs 28.0.91 with native compilation
Maxime Devos writes: > André A. Gomes schreef op di 11-01-2022 om 22:13 [+0300]: >> Maxime Devos writes: >> >> > > A log below. >> > > >> > > --8<---cut here---start->8--- >> > > configure: error: The installed libgccjit failed to compile and run a >> > > test program using >> > > the libgccjit library; see config.log for the details of the failure. >> > > [...] >> > >> > configure is telling that "config.log" has details, please include it. >> >> Right, but I couldn't figure out what's this file or where it's >> located. > > You can pass --keep-failed to "guix build", then "config.log" should be > in (a subdirectory) of /tmp/guix-build-aadcg-emacs-28.0.91-0 > (not sure about the directory name). Ah-ah! I was doing it with guix package, instead of guix build (silly me). Seems that the issue comes from here: --8<---cut here---start->8--- configure:5377: gcc --version >&5 gcc (GCC) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:5388: $? = 0 configure:5377: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/libexec/gcc/x86_64-unknown-linux-gnu/10.3.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.3.0 (GCC) configure:5388: $? = 0 configure:5377: gcc -V >&5 gcc: error: unrecognized command-line option '-V' gcc: fatal error: no input files compilation terminated. configure:5388: $? = 1 configure:5377: gcc -qversion >&5 gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. configure:5388: $? = 1 configure:5377: gcc -version >&5 gcc: error: unrecognized command-line option '-version' gcc: fatal error: no input files compilation terminated. configure:5388: $? = 1 configure:5408: checking whether the C compiler works configure:5430: gccconftest.c >&5 configure:5434: $? = 0 configure:5482: result: yes configure:5485: checking for C compiler default output file name configure:5487: result: a.out configure:5493: checking for suffix of executables configure:5500: gcc -o conftestconftest.c >&5 configure:5504: $? = 0 configure:5526: result: configure:5548: checking whether we are cross compiling configure:5556: gcc -o conftestconftest.c >&5 configure:5560: $? = 0 configure:5567: ./conftest configure:5571: $? = 0 configure:5586: result: no configure:5591: checking for suffix of object files configure:5613: gcc -c conftest.c >&5 configure:5617: $? = 0 configure:5638: result: o configure:5642: checking whether we are using the GNU C compiler configure:5661: gcc -c conftest.c >&5 configure:5661: $? = 0 configure:5670: result: yes configure:5679: checking whether gcc accepts -g configure:5699: gcc -c -g conftest.c >&5 configure:5699: $? = 0 configure:5740: result: yes configure:5757: checking for gcc option to enable C11 features configure:5960: gcc -c -g -O2 conftest.c >&5 configure:5960: $? = 0 configure:5974: result: none needed configure:6182: checking whether the compiler is clang configure:6203: gcc -c -g -O2 conftest.c >&5 configure:6203: $? = 0 configure:6211: result: no configure:6215: checking for compiler option needed when checking for declarations configure:6246: result: none configure:6307: checking whether gcc and cc understand -c and -o together configure:6338: gcc -c conftest.c -o conftest2.o >&5 configure:6342: $? = 0 configure:6348: gcc -c conftest.c -o conftest2.o >&5 configure:6352: $? = 0 configure:6363: cc -c conftest.c >&5 ./configure: line 6365: cc: command not found configure:6367: $? = 127 configure:6407: result: yes configure:6444: checking how to run the C preprocessor configure:6475: gcc -E conftest.c configure:6475: $? = 0 configure:6489: gcc -E conftest.c conftest.c:10:10: fatal error: ac_nonexistent.h: No such file or directory 10 | #include | ^~ compilation terminated. configure:6489: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU Emacs" | #define PACKAGE_TARNAME "emacs" | #define PACKAGE_VERSION "28.0.91" | #define PACKAGE_STRING "GNU Emacs 28.0.91" | #define PACKAGE_BUGREPORT "bug-gnu-em...@gnu.org" | #define PACKAGE_URL "https://www.gnu.org/software/emacs/; | #define HAVE_PDUMPER 1 | /* end confdefs.h. */ | #include configure:6514: result: gcc
Re: Packing Emacs 28.0.91 with native compilation
Malte Gerdes writes: > Hi, > > https://github.com/flatwhatson/guix-channel > > Contains a working Emacs 28.0.90. Thank you! -- André A. Gomes "Free Thought, Free World"
Re: Packing Emacs 28.0.91 with native compilation
Maxime Devos writes: >> A log below. >> >> --8<---cut here---start->8--- >> configure: error: The installed libgccjit failed to compile and run a test >> program using >> the libgccjit library; see config.log for the details of the failure. >> [...] > > configure is telling that "config.log" has details, please include it. Right, but I couldn't figure out what's this file or where it's located. -- André A. Gomes "Free Thought, Free World"
Packing Emacs 28.0.91 with native compilation
Hi Guix,
I tried to package Emacs as mentioned in the subject without success.
I'm wondering if someone else has done it already. Note that I have few
experience.
Please find my attempt below.
https://git.sr.ht/~aadcg/aadcg-guix-channel/tree/master/item/packages/aadcg-emacs.scm
A log below.
--8<---cut here---start->8---
configure: error: The installed libgccjit failed to compile and run a test
program using
the libgccjit library; see config.log for the details of the failure.
The test program can be found here:
<https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html>.
You can try compiling it yourself to investigate the issues.
Please report the issue to your distribution if libgccjit was installed
through that.
You can find the instructions on how to compile and install libgccjit from
source on this site:
<https://gcc.gnu.org/wiki/JIT>.
error: in phase 'configure': uncaught exception:
%exception #< program:
"/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8/bin/bash"
arguments: ("./configure"
"CONFIG_SHELL=/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8/bin/bash"
"SHELL=/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8/bin/bash"
"--prefix=/gnu/store/ljvhsyd91fc307r4chbrzkd5r7zvjgvp-aadcg-emacs-28-pretest-28.0.91-0.d193801"
"--enable-fast-install" "--with-native-compilation" "--with-modules"
"--with-cairo" "--disable-build-details") exit-status: 127 term-signal: #f
stop-signal: #f>
phase `configure' failed after 9.7 seconds
--8<---cut here---end--->8---
Thank you.
--
André A. Gomes
"Free Thought, Free World"
Re: Guix wiki
Tobias Geerinckx-Rice writes: > Hi Simon, all, > > I'll give your long and thoughtful reply the attention it deserves > when I have time, but there's another misleading tangent that has > bothered me (elsewhere) in this discussion: > >> - cathedral, as it is today > > This is revisionist. The Bazaar model perfectly describes Guix, where > everyone is free to submit changes and have them critiqued and revised > in public. Even maintainers are expected to submit. Changes that meet > $criteria are merged into a source tree immediately available to > everyone. > > Guix has never used the Cathedral model, where patch submission and > discussion happen behind closed doors, to be released unto the public > as a revelation from on high. > > ‘People push nontrivial changes without review’ was never a condition > of the Bazaar model or what made it successful. The book was based on > LKML, for heaven's sake! :-) > > We can find a cute new name for what's being proposed in this thread > (the Wailing Wall model?), but simply declaring ‘the Bazaar is called > Cathedral now, change my mind’ can't work. Tobias, I couldn't agree more!!! -- André A. Gomes "Free Thought, Free World"
Re: Guix Documentation Meetup
Matt writes:
> > I'm not connected with Guix with any way - a mere enthusiast and
> > observer.
>
> I'm not sure what you mean. Being excited about something and taking
> the time to observe it, like listening to music, is a connection,
> right?
I mentioned because ultimately the final word isn't mine :)
> I'm curious, what makes you feel not connected with Guix?
I feel connected "philosophically" as a (basic) user, but not as a
contributor. Guix, by itself, is a complex system. Honestly, I suck at
using Guile in a project of this scale (no, I don't think the
documentation is poor). I have some understanding in Emacs and
slime/common lisp systems, but I still need to dive into geiser. There
are difficulties of other sorts as well. This is a Unix system and that
fact alone requires knowledge and experience. I assume that most core
contributors are/were involved in other efforts such as Debian, Arch,
Gentoo, etc. Besides experience in "system administration" and HPC.
I don't know how many people in the community have
non-CS/Unix/programming backgrounds so I share some personal thoughts
below. It's not that I want to share my life, but it might resonate
with the experiences of others.
My background is in theoretical physics and pure maths. I never cared
about computers or computation, until I had to find a job circa 2018. I
landed on a wind energy company which owns a supercomputer (running
GNU/Linux of course), and without me realising, I was being "forced" to
be a software developer. I had to learn a lot and fast. Soon, I
understood that the bottleneck on the success of a given project isn't
in the lack of domain-specific/scientific knowledge, but in the lack of
robust (software) tools and "software knowledge" in general. Most
"scientists" think: "these IT/programmers can't do their work properly".
This division ("scientists" and "programmers") is toxic. Yes, it's VERY
hard to find people who do both well. Guix a step towards tearing this
wall apart for good. It's not by chance that Guix has a strong presence
on HPC. (Yes, it's hell to depend on an admin to install stuff). It's
interesting to note that the effort comes from the "programmers" side.
I think the bottleneck on Guix's world domination is precisely because
"scientists" generally make little effort in that regard. It's hard to
make "non-sexy" things look sexy. Go and tell a "data-scientist" about
reproducible builds. Good luck.
It's ok if things are overwhelming and hard. Things eventually click
and start to make sense.
--
André A. Gomes
"Free Thought, Free World"
Re: Guix Documentation Meetup
Matt writes: > > I see that this all seems confusing. > > Thank you for your response and for acknowledging my perspective. > Yes, I find many things about the documentation process confusing. I > can't speak for others, but I get the strong sense that I'm not alone > in that feeling. You're not alone, but honestly I think Guix's efforts are heroic to say the least. How many software has no documentation at all? I always gaze at the quality of Guix's manual. > First, the packaging tutorial is, I believe, a reasonable candidate > for the cookbook. It's ready for feedback toward inclusion, not > direct inclusion. The software being packaged isn't ideal as it > involves concepts which may detract from the main subject of > packaging, like stenography. It's also for a plugin and not standalone > software. Demonstrating the final package requires demonstrating the > parent application which again detracts from the main subject of > packaging. Finally, it's written using active voice which conveys > authority on the topic, authority I don't actually have. This was my > first attempt at packaging. > > Second, the troubleshooting post is not, in my option, suited for the > cookbook. It is, however, a good candidate for a wiki page (similar to > Arch wiki sections on troubleshooting). The last time a wiki was > talked about, it seems, was in 2015. I'll start a thread for that. Please don't misinterpret the following comments. You're doing something valuable for the community by the mere fact of talking about Guix - your writings are valuable! But I don't see how the 1st one could land in a cookbook. Regarding the 2nd and the wiki, as someone (perhaps you) already noted, wikis generally host low quality content. Guix's documentation has a ton of examples, perhaps even too many for an expository kind of text. Yes, I'm not a fan of wiki. Regardless, the efforts of such a wiki should perhaps land outside the scope of Guix (i.e. it should be non-"official"). I'm not connected with Guix with any way - a mere enthusiast and observer. I hope you continue to write great articles like these! -- André A. Gomes "Free Thought, Free World"
Re: EXWM
calcium writes: > I was totally at lost when I started my emacs/exwm session and tried to > `find-file' only to be redirected to an 'ido-find-file` with whom I don't > know how to navigate. > > In the moment, it felt very intrusive for me and I was very afraid to be > unable to control my emacs because I have set all my emacs's keybindings to > non-standard keys ((in a modal way (à la vim) but using my own custom modals) > and without honoring the `C-c' convetion.) and I don't know how to navigate > emacs using the default key bindings. > > Luckly, this time (because packages can evolve to add more default key > bindings), it was just the annoyance of ido that affected me. > > > I was thankfully able to understand what was going on by finding the > Guix-devel archive discussing this issue. > > I think that if we choose to keep things as they are, a simple fix that would > help next users know what is going on without having to find an archived > mailing list : > > a ) being more explicit in messages in both cases like : > (message "no \"~/.exwm\" elisp configuration found to setup exwm. " > "Falling back to executing the default config using > `(exwm-config-default)'") > (message "executing the elisp found at \"~/.exwm\"") > b ) while still keeping the explicit messages, creating the ~/.exwm file when > it doesn't exist populated with guix's choice of default settings (so that > the user can read and tweak his config) > > Because the message thrown by the snippet bellow is not enough at all. > > > (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) >((not (featurep (quote exwm))) > (require (quote exwm)) > (require (quote exwm-config)) > (exwm-config-default) > (message (concat "exwm configuration not found. " > "Falling back to default configuration..." > I feel you (been there, felt that). I tried, without success, to raise awareness about the issue (perhaps in the archived thread you mention). Sadly, no one agreed or tried to prove me wrong. I wrote a very simple and sane EXWM package definition, and you can find it here: https://git.sr.ht/~aadcg/aadcg-guix-channel/tree/master/item/packages/aadcg-emacs-xyz.scm#L147 I could send it as a patch, but without interest from the developers/maintainers it makes little sense. -- André A. Gomes "Free Thought, Free World"
Re: Convention for new “guix style“?
zimoun writes: > And “guix style” is a step toward fixing Danny’s words: > > FWIW, I do find it strange that Lisp projects, despite using a > minimal-syntax language (mostly in order to conserve its regular > tree structure), do not usually automatically format source code > as they check in, but Go projects, using the prime example of an > irregular C-like language, DOES usually use code formatters > automatically when checking in. That is some strange reversal > of strengths that I wouldn't have expected. > > <https://yhetil.org/guix/20201204161257.64363...@scratchpost.org/> I agree and disagree. (Disagree). Lisps hardly ever need external formaters or linters since you basically write down an AST. The "linting" job is done by the editor itself (think C-M-q and electrical indentation in major modes). Yes, there is ambiguity in some cases, but the decision is (rightly) left to the programmer. I believe that it's precisely the lack of "structure" in other languages that motivates the need for such tooling. (Agree). If we turn to the concrete issue at hand, cosmetic and "diff" issues of Guix packages, then I agree that this would (ideally) be a task for a tool (guix lint). Because it's important to have consistency and we can agree on the standards. I'm arguing that in this case the ambiguity (mentioned above) vanishes, and so the style can be enforced. When I go shopping, I write the list down in same way you do, Zimoun :) -- André A. Gomes "Free Thought, Free World"
Re: XFCE on Guix System shows rootfs twice no USB flash drives
Tobias Platen writes: > I installed the GNU Guix System 1.3.0 on my Laptop using the XFCE > desktop. I can mount USB flashdevices using udiskctl and once mounted > they show up in thunar. But before mounting they do not show in thunar. > This behaviour is different from other GNU/Linux distros. I think a > package is missing. Can you show the system config? I don't use XFCE for quite some time now, but I remember that devices would automatically show on thunar. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
André A. Gomes writes: > Therefore the claim that Guix forces a default EXWM config on the users > isn't entirely true. Actually, I made a mistake again. Guix seems to force a default EXWM config. Find a proof below. Emacs, as of today, is started by evaluating the following sexp: --8<---cut here---start->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) ((not (featurep (quote exwm))) (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here---end--->8--- This sexp is the first thing evaluated, taking precedence over the the user's init file. As a result, (not (featurep (quote exwm))) always returns t. Therefore, Guix forces the default EXWM config. In other words, the above sexp is equivalent to: --8<---cut here---start->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) (t (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here---end--->8--- As I've been advocating, this seems to qualify as Guix not honouring the user's Emacs init file. I'm surprised no one noticed it before. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
André A. Gomes writes: > Guix forces the execution of (exwm-config-default), unless the user has > a .exwm file. That forces a default config on EXWM users, which is > unpleasant for those (like me) that have been using it for a long time. > Notice that those users have their EXWM configuration where it belongs, > i.e. in their Emacs' init file. There's a subtle and important detail I missed, and I've only noticed it now. This returns --8<---cut here---start->8--- emacs -q --batch --eval '(progn (require (quote exwm)) (print (featurep (quote exwm' --8<---cut here---end--->8--- true, whereas --8<---cut here---start->8--- emacs -q --batch --eval '(print (featurep (quote exwm)))' --8<---cut here---end--->8--- returns nil. But --8<---cut here---start->8--- emacs -q --batch --eval '(print (fboundp (quote exwm-enable)))' --8<---cut here---end--->8--- returns t (as long as emacs-exwm is installed)! Therefore the claim that Guix forces a default EXWM config on the users isn't entirely true. I was led to think that way since, most likely, I didn't add (require 'exwm) in my Emacs init file. In result, EXWM's symbols were actually bound, but, due to the lack of the require statement, it was running with the non-desired default config. I apologise for my lack of attention. I'd say that this also qualifies as evidence that the present "magic" is a double-edge sword. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Ricardo Wurmus writes: > Hi André, > >> I packaged EXWM (the right way) for myself a long time ago. If I'm >> putting effort into this, it's because I think the community is >> missing >> an opportunity to improve. I won't get anything from any of this. >> You, >> on the other hand, seem to be interested in your selfish agenda. > > it’s frustrating to get the feeling to be misunderstood. But please > take a step back before judging others. “selfish agenda” sounds a lot > harsher than is warranted in this context. I apologise for the choice of words. > Some background: Guix implements a philosophy that could be described > as “magic with escape hatches”. We usually offer neat features and > automation by *default*, but we also provide escape hatches for those > who don’t want the magic or have different requirements. I do understand that, and that's why I like Guix. I started a thread before sending a patch, since I antecipated that it would be a sensitive topic. On top of that, I was concerned about backwards compatibility since, at this point, lots of users are perhaps used to the .exwm file. > The expectation to have EXWM start right up after selecting it as a >window manager is justified, in my opinion. Do we offer a sufficient >escape hatch here? No. My point is that the "magic" that Guix provides in this case is a double-edged sword. Guix forces the execution of (exwm-config-default), unless the user has a .exwm file. That forces a default config on EXWM users, which is unpleasant for those (like me) that have been using it for a long time. Notice that those users have their EXWM configuration where it belongs, i.e. in their Emacs' init file. The .exwm file is non-standard, and it's not documented in any EXWM project resource. This would be somehow alleviated if (exwm-enable) would run, instead of (exwm-config-default). But we can do better. I've advocated to the fact that "choosing EXWM as a window manager" is a meaningless statement. The meaningful statement is "choosing Emacs as the window manager". The user's Emacs init file dictates how EXWM is to be initiated and operated. In short, the EXWM bin wrapper should simply start Emacs. The approach I describe is the "standard" and documented way of using and "starting EXWM". See C-h P exwm RET for more info. Thank you. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Arun Isaac writes: > Hi André, > >> Your reply indicates that little or no effort was put into understanding >> my points. And no effort was put to indicate where did my reasoning go >> wrong. > > I, for one, did not understand how your workflow is affected by the way > EXWM is currently packaged in Guix. As far as I understand, Guix's > ~/.exwm separation is optional and you are not forced to create it. I > don't have an ~/.exwm, for example. It's frustrating to keep repeating myself at this point, but let's do it. It is optional, indeed. Now assume that you don't have a .exwm file. Then (exwm-config-default) runs. But that's backwards, since the user might not want that piece of code to run. I have explained this from several points of view, several times. For instance, in one of the replies to Ludovic. > But, it is possible that I may have misunderstood something you > said. Perhaps, making your point more precise by providing a patch or > just a code snippet showing your modified exwm package would help. I did all of that. I sent a link with my own EXWM package definition. And I've illustrated my points with code snippets. https://git.sr.ht/~aadcg/aadcg-guix-channel/tree/master/item/packages/aadcg-emacs-xyz.scm#L150 -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Jan Nieuwenhuizen writes: > André A. Gomes writes: > >> Jan Nieuwenhuizen writes: >> >>> I just tried adding my ~/.exwm into my init.el and running a nested >>> emacs and now I get a GUI dialog: >>> >>> Replace existing window manager? Y/N >>> >>> Not great! Not very suprisingly, the extra unnecessary initialization >>> /does/ hurt here. >> >> Isn't exwm doing precisely what it's supposed to do? Isn't it fair that >> the newly spawned (nested) Emacs has the right to take control over the >> "older" Emacs? > > Of course; that's my point exactly! Emacs cannot know, and thus cannot > help but doing the annoying thing: throwing a dialogue. That is what > this code > > (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) > ((not (featurep (quote exwm))) >(require (quote exwm)) >(require (quote exwm-config)) >(exwm-config-default) >(message (concat "exwm configuration not found. " > "Falling back to default configuration..." > > helps to prevent in a very nice way. Let's please keep it! After all the effort I put into all of my previous messages, it's unfortunate to receive such a reply. I packaged EXWM (the right way) for myself a long time ago. If I'm putting effort into this, it's because I think the community is missing an opportunity to improve. I won't get anything from any of this. You, on the other hand, seem to be interested in your selfish agenda. Your reply indicates that little or no effort was put into understanding my points. And no effort was put to indicate where did my reasoning go wrong. I give up. Let "worse is better" reign. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Jan Nieuwenhuizen writes: > Arun Isaac writes: > > Hello, > >>> My suggestion is simple: remove the added layer of complexity introduced >>> by the .exwm file; don't force a default Exwm config on the user. >> >> I think I agree with you now. I checked, and exwm indeed does not run >> when emacs is opened in the console even though my exwm config is >> defined in my ~/.emacs. > > Interesting. So the extra, unneccesary initialization code does not > hurt there. > > I just tried adding my ~/.exwm into my init.el and running a nested > emacs and now I get a GUI dialog: > > Replace existing window manager? Y/N > > Not great! Not very suprisingly, the extra unnecessary initialization > /does/ hurt here. Isn't exwm doing precisely what it's supposed to do? Isn't it fair that the newly spawned (nested) Emacs has the right to take control over the "older" Emacs? It does so in a very polite way, by asking what should be done. If you disagree with the default behaviour, you can change the value of the variable exwm-replace. >> So, I see no reason to continue having ~/.exwm. If no one else has any >> objections, please do send a patch fixing this. > > I would very much like for this nested emacs issue to be addressed > first. > > I just don't really see the point in mixing two bits of code that are > meant to run in different scenarios, and then disabling one of them. I don't see how it could possibly qualify as an issue, and what those "different scenarios" are. There's one and only one scenario. The user launches emacs. Emacs reads the user's init file, and carries out the instructions. The confusion arises from thinking about Exwm as a "session", with a .desktop file associated with it. But that's a special case of something more general and simple. Exwm is an Emacs extension, requiring a graphical X session. After all, it manages X windows "à la Emacs". If you try to start Exwm from the console, it will handle it. If you start Exwm from DEs or WMs (GNOME, i3, whatever), it will handle it (on Guix, that requires running xhost). Yes, this is a good middle ground for "beginners" that aren't ready to fully convert themselves to the Light. If you start Exwm from Exwm itself, it will handle it as well. The so-called "emacs-exwm" session is nothing but a convenience to handle a common scenario. If Exwm handles X windows, then it makes sense to start a graphical session and IMMEDIATELY start Emacs so that Exwm kicks in. What happens if Exwm doesn't kick in, btw? You get a bunch of X windows floating around, and you won't be able to handle them with ease. Makes sense. What should the "emacs-exwm" session do, then? With some simplifications, nothing but this: --8<---cut here---start->8--- dbus-launch --exit-with-session emacs -mm --debug-init --8<---cut here---end--->8--- Yes, there shouldn't even be any "exwm" logic in it. The user knows better. Let the user's init file be in charge. I did my best to show my point of view, and I won't press on it anymore. The decision is on the community's side. The patch the trivial. Acceptance isn't. -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Arun Isaac writes: > Hi André, > >> I remember, back in the day, to what great lengths I went to understand >> what the hell what going on. I had EXWM configured in my Emacs init.el >> file (the sane, standard and documented way of doing it), and I've used >> it before in other distros. > > Just to clarify, I have exwm configured in my ~/.emacs, and it works. I > don't have any ~/.exwm file. The way Guix currently starts exwm does not > require to you have a ~/.exwm. So, Guix does support the standard way of > configuring exwm. Do we agree on this? Absolutely not. Please read my previous message. It seems that what you call "the standard way of configuring Exwm" includes running the default config that Exwm packages, but this should be optional. Please look at C-h P exwm RET. Item number 2 should be handled by the user, but Guix forces it. The only way out of it is to write a .exwm file. But, as I've stated previously, this (besides being a bad idea) is not documented. Users would only find out about it by looking at the package definition, or by looking at how the emacs process was started. Users can use their emacs init files as they wish, but that's a separate issue. My suggestion is simple: remove the added layer of complexity introduced by the .exwm file; don't force a default Exwm config on the user. What do you think? -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Ludovic Courtès writes: > Hello, > > Arun Isaac skribis: > >>>> I was involved in the packaging of exwm when it was first done, and I >>>> hear your frustration. :-) Please do send patches (with me on Cc) >>>> addressing the issue, and we can continue our discussion there. >>> >>> As someone who didn't have a prior EXWM setup in their .emacs, I have >>> been enjoying the separate .exwm config file. >> >> Ah, I see. That may be good reason to not break this separation between >> .emacs and .exwm. > > FWIW, I don’t have .exwm either; instead I have just a few lines of exwm > config straight in ~/.emacs, which shouldn’t prevent it from running in > the console or anything. I'm afraid you're approaching the issue from the wrong angle. Exwm is smart than you think. As of today, there are workarounds (.exwm) that attempt to "solve" non-existent issues. As for the fact the you, Ludovic, don't have a .exwm file and configure Exwm from your emacs init file: are you aware that you're running a default Exwm config? M-x find-library RET exwm-config; and take a look at exwm-config-example. I find this extremely annoying, since it defeats the purpose of having a personal Exwm config. The only way to avoid this is to create an empty .exwm file. Again, sending a patch is trivial (I've been running my own Exwm for a while now), but I need to convince you first :) -- André A. Gomes "Free Thought, Free World"
Re: EXWM
Jan Nieuwenhuizen writes: > I'm wondering, how have you managed to switch off exwm when running a > nested emacs or a console emacs? Exwm handles that by itself. In a console, since it's a non-graphical session, Exwm won't even try to do anything. As for nested emacs, there's a variable called exwm-replace which by default is set to 'ask---meaning that Exwm will ask if it should replace the current window manager. -- André A. Gomes "Free Thought, Free World"
EXWM
Hi Guix, I'd like to addres the way EXWM is packged in Guix. EXWM starts (from the login manager, i.e. after X is running) by means of a script that starts emacs by evaluating the following s-exp: --8<---cut here---start->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) ((not (featurep (quote exwm))) (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here---end--->8--- I can't think of any good reason to doing this, but I can think of many against. I'll elaborate. I remember, back in the day, to what great lengths I went to understand what the hell what going on. I had EXWM configured in my Emacs init.el file (the sane, standard and documented way of doing it), and I've used it before in other distros. I wondered: why isn't it being honored? And why the hell is ido-mode on, if I did it enabled it? Let's check the EXWM wiki and documentation. Nothing. Ok, maybe I should check how EXWM is packaged in Guix. Let's be honest, the "lay user" will never do this. The present approach assumes that one of the following holds. Either the user is stupid and he expects some standard EXWM config to "just work", or he miracously knows he needs to write an extra .exwm file to serve such a specfic purpose. This doesn't configure EXWM in the most general case (more on that below), and it's bonkers. EXWM was thought to be started and used in many scenarios. The most common one, indeed, is to start it when no other window manager has been started. But users can also login into a full-blown DE (GNOME, Xfce, etc) and active EXWM when they wish! In this case, EXWM is able to take control of things (i.e. replace the running window manager). See how the .exwm file is short-sighted? This is a non-standard approach, and a source of duplication and confusion. Now, there's another problem. One simply doesn't start EXWM from another DE in Guix! It always fails. Why? Because the user needs to run the following beforehand (yes, the same bit that also appears in the exwm binary wrapper): --8<---cut here---start->8--- /gnu/store/HASH-xhost-1.0.8/bin/xhost +SI:localuser:$USER --8<---cut here---end--->8--- I'm not sure how to handle this issue. Most users would expect things to just work. There are lots of issues on github from Guix users clueless about this. Yes, I can mention this in the EXWM wiki, but perhaps deeper measures should be taken. It's trivial to fix part of the problem, and I have packaged EXWM myself. See the link below. https://git.sr.ht/~aadcg/aadcg-guix-channel/commit/4a27f9991b0b692694f954cb595a9748a0146d36. It seemed pointless to send a trivial patch without any further explation, so feel free to discuss the topic. Thank you. -- André A. Gomes "Free Thought, Free World"
Guix, ispell.el and FHS
Hi Guix, I'm relatively new to the GNU/Linux world, so I apologise for any silliness. I was looking ispell.el and saw: --8<---cut here---start->8--- (defcustom ispell-look-command (cond ((file-exists-p "/bin/look") "/bin/look") ((file-exists-p "/usr/local/bin/look") "/usr/local/bin/look") ((file-exists-p "/usr/bin/look") "/usr/bin/look") (t "look")) "Name of the look command for search processes. This must be an absolute file name." :type 'file :group 'ispell) --8<---cut here---end--->8--- That's the usual path for most GNU/Linus distro (FHS compliant). But for Guix System users it lives at /run/current-system/profile/bin/look. It's obvious I can set the variable properly myself. My question is: what should be done in such cases? I can think of the following: - Patch the Guix package - Patch the program itself - Nothing (apart from setting things myself) Thank you. -- André A. Gomes "Free Thought, Free World"
Re: delete-generations or --delete-generations?
Leo Famulari writes: > I think that adding `guix system --delete-generations` et al would not > be confusing for anyone. Let me share the position of a layperson. I noticed the lack of symmetry between `guix system list-generations` and `guix package --list-generations` and it felt like an inconsistency to me. -- André A. Gomes "Free Thought, Free World"
Re: Distributing Guix System Pinebook Pro images
Mathieu Othacehe writes: > Yeah SDDM drags Xorg between other things, I could definitely get rid of > it. Theoretically, it would be possible to write a SDDM service supporting wayland only AFAIK. But if you'll only use sway, it makes little sense to have a login manager indeed. -- André A. Gomes "Free Thought, Free World"
