Re: Next browser finally on master!
Ricardo Wurmus writes: > The naming scheme applies to packages that are primarily used as > libraries. A package “foo” that is written in Python and also provides > modules that can be imported in an interactive Python session will not > be named “python-foo” when it is primarily used on its own. Agreed here. I don't want to speak out of turn and am interested in what Andy has to say here, but there are a few other Guix packages that do not follow their naming conventions when they are intended to be used alone. I think Idris is one. Perhaps it would confuse the end user if they were to know whether they were getting libraries for the SBCL environment to be able to hack on the package or if they were getting a runtime executable to operate the package without the SBCL environment. Brett Gilio
Re: Next browser finally on master!
Pierre Neidhardt writes: > Brett Gilio writes: >> Excuse me for not being fully aware, are you involved in the development >> of the Next browser? > > I am! John Mercouris is the original author, and I've implemented the > WebKitGTK > platform for Next. > Is there a mailing list for this, or is it Github-centric? I wouldn't mind throwing my hat in the ring if you all are looking for some extra development support. This might be off-topic so you can reply to me off of the list if you'd prefer. Brett Gilio
Re: Next browser finally on master!
Pierre Neidhardt writes: > - As far as I understand, the compiler *does* change the resulting > binary, thus the resulting REPL experience will be different, because > all Lisps are different beyond the ANSI standard and other undefined > behaviour. In other words, connecting via SLIME to ccl-next or > sbcl-next would result in a different environment. Sure. I wouldn’t expect people who use ECL to be able to load libraries that were built with SBCL. >> That these packages can *also* be used as libraries does not mean that the >> packages should have names with the “sbcl-” or “cl-” or “other-lisp-” prefix. > > That would not be consistent with the Lisp library naming scheme then. > And it raises the question as to why we have bothered with the sbcl- and > ecl- prefixes so far. The naming scheme applies to packages that are primarily used as libraries. A package “foo” that is written in Python and also provides modules that can be imported in an interactive Python session will not be named “python-foo” when it is primarily used on its own. -- Ricardo
Re: Next browser finally on master!
Brett Gilio writes: > Excuse me for not being fully aware, are you involved in the development > of the Next browser? I am! John Mercouris is the original author, and I've implemented the WebKitGTK platform for Next. Ricardo Wurmus writes: > I’ve read that discussion, but I don’t see how it is relevant. > The *name* of the package surely does not have any effect on the > features, does it? > > For applications like StumpWM and Next we could change the package names > to “stumpwm” and “next”, respectively. Don't get me wrong, I don't have a strong opinion against this change. But Lisp is special, and common sense for other packages / programming languages don't necessarily apply here. A few points to consider: - While StumpWM has dropped support for anything but SBCL, Next browser plans to support CCL (it already works but for one thing). So we could have a ccl-next package. - As far as I understand, the compiler *does* change the resulting binary, thus the resulting REPL experience will be different, because all Lisps are different beyond the ANSI standard and other undefined behaviour. In other words, connecting via SLIME to ccl-next or sbcl-next would result in a different environment. > That these packages can *also* be used as libraries does not mean that the > packages should have names with the “sbcl-” or “cl-” or “other-lisp-” prefix. That would not be consistent with the Lisp library naming scheme then. And it raises the question as to why we have bothered with the sbcl- and ecl- prefixes so far. Andy, any opinion on this? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Next browser finally on master!
Hi Pierre, >> I am also in favor >> of renaming SBCL-Next to something else. I know that we are using sbcl >> instead of clisp for building it, but the naming scheme seems to imply >> an SBCL library or module rather than a web browser application. > > This is being discussed for stumpwm in bug #33311. […] I’ve read that discussion, but I don’t see how it is relevant. The *name* of the package surely does not have any effect on the features, does it? For applications like StumpWM and Next we could change the package names to “stumpwm” and “next”, respectively. That these packages can *also* be used as libraries does not mean that the packages should have names with the “sbcl-” or “cl-” or “other-lisp-” prefix. Am I misunderstanding something? -- Ricardo
Re: Next browser finally on master!
Ricardo Wurmus writes: > Hi Pierre, > >>> I am also in favor >>> of renaming SBCL-Next to something else. I know that we are using sbcl >>> instead of clisp for building it, but the naming scheme seems to imply >>> an SBCL library or module rather than a web browser application. >> >> This is being discussed for stumpwm in bug #33311. […] > > I’ve read that discussion, but I don’t see how it is relevant. > The *name* of the package surely does not have any effect on the > features, does it? > > For applications like StumpWM and Next we could change the package names > to “stumpwm” and “next”, respectively. That these packages can *also* > be used as libraries does not mean that the packages should have names > with the “sbcl-” or “cl-” or “other-lisp-” prefix. > > Am I misunderstanding something? That was my understanding as well Ricardo. I do not see how renaming the package would detach it from its respective compiler. It should still be just as hackable in SLIME... Or so I thought? Brett
Re: Next browser finally on master!
Pierre Neidhardt writes: >> Hi all, I am also using the Next browser. A terrific tool. > > Oh, and I forgot: Thanks for the compliment! :) Excuse me for not being fully aware, are you involved in the development of the Next browser? I have been following it for some time, and am genuinely amazed by it. I have been a StumpWM + Emacs user for a long time, and combining Next with Guix my machine is pretty much LISP turtles all the way down (except the kernel). Brett
Re: Lock screen gnome
Hello, Ludovic Courtès ezt írta (időpont: 2018. dec. 19., Sze, 14:53): > > Hi Timothy, > > Timothy Sample skribis: > > > Someday I would like to return to fixing GDM, but I am a bit > > traumatized. It is a very slow and frustrating package to debug. > > > > 1. https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00268.html > >https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00231.html > > I would love to have GDM fixed for 1.0 though, because this GNOME > screen-locking issue, among other things, is really problematic. > > Is there anything we can do to help or otherwise provide motivation? > :-) > > Thanks, > Ludo’. > Yes, I also believe we need this. Along with the screen-locking multi-monitor support and i18n support comes to mind. If we can help in any way, please feel free to contact us. Thanks, g_bor
Re: PAM module
Yes, thank you. On Wed, Dec 19, 2018, 22:14 Brett Gilio > Saeed Jamali writes: > > > How we can change system configurations in /etc, I want to add some pam > > module to pam configuration files for exapmle pam.d/login, > > You use your system configuration file you made during the installation > and add relevant services to your configuration. I believe the Guix > website has documentation on various PAM. > > Does that help? > > Brett >
Re: Next browser finally on master!
Ludovic Courtès writes: > Hello! > > Pierre Neidhardt skribis: > >> I'm happy to let you know that after months of feisty packaging and the >> last month spent on the full rewrite of the GNU/Linux port, the Next web >> browser is finally on master! >> >> It's packaged as sbcl-next. > > Before reading your message I naively installed ‘next-webkit-gtk’, which > is not supposed to be used directly, right? Should we make it private > or hidden? > > Anyway, I’m trying it now and so far I like it! > > Thank you, > Ludo’. Hi all, I am also using the Next browser. A terrific tool. I am with you, Ludo, we should make next-webkit-gtk hidden and I am also in favor of renaming SBCL-Next to something else. I know that we are using sbcl instead of clisp for building it, but the naming scheme seems to imply an SBCL library or module rather than a web browser application. Brett Gilio
Re: PAM module
Saeed Jamali writes: > How we can change system configurations in /etc, I want to add some pam > module to pam configuration files for exapmle pam.d/login, You use your system configuration file you made during the installation and add relevant services to your configuration. I believe the Guix website has documentation on various PAM. Does that help? Brett
Re: About /var/guix/profiles and guix pull generations
> I think we're still waiting for Pierre to send his latest patch. If the > text really is too long, perhaps we can provide concrete examples, a > sentence explaining what they do, and a link to the manual, where we put > the slightly more verbose explanation. I think the text so far is OK, > but I also have not seen the final version yet. Pierre, what do you > think? I'll re-send the patch just now. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: About /var/guix/profiles and guix pull generations
Agreed "checkout" is not very precise, but can anyone come up with a better term? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: GC hints
Ludovic Courtès writes: > I agree that this would be more accurate, but isn’t there also a risk > with making hints too long? I’m split between the idea of providing > concise hints that can be pasted and get things done, and the idea or > not trying to be a substitute for the manual. I agree the manual should be authoritative, but I also think that if Guix can provide contextual information, it's great when it does so. The "did you forget to add (use-module..." hints you added a while back are a great example of this. The shorter the better, of course. I think we're still waiting for Pierre to send his latest patch. If the text really is too long, perhaps we can provide concrete examples, a sentence explaining what they do, and a link to the manual, where we put the slightly more verbose explanation. I think the text so far is OK, but I also have not seen the final version yet. Pierre, what do you think? > Actually, I was also wondering whether we should provide a >configurable > mechanism that would, by default, automatically delete old GC roots and > maybe even run the GC automatically when needed—similar to what Git > does. I think it's a great idea to allow a user or system administrator to configure a policy for automatic GC root clean-up. I'm not sure about ad-hoc roots, but for profiles, it would be great to be able to say something like "Keep the last 2 generations, and delete any others that are older than 2 weeks". Perhaps we could enforce the policy any time that a user runs code that modifies the profiles, such as "guix package" commands. Of course, that's a little more than what is being proposed in this email thread, so it would probably be best to work on that separately. -- Chris signature.asc Description: PGP signature
Re: About /var/guix/profiles and guix pull generations
Pierre Neidhardt writes: >> OK. Since that example deletes profile generations, Can we just say >> "profile generations" instead of "checkouts"? The latter makes me think >> of a Git repository checkout. Maybe the phrase "cleaning up old >> profiles" would be good enough, since we put a clear example right after >> the sentence. I wouldn't mind either way, as long as we avoid using the >> term "checkout" to refer to profiles and their generations. > > You might have misunderstood the example. There are two calls to > =--delete-generations=, which delete _both_ the user profile generations and > the > Guix checkout/build/copy generations. When you say the Guix checkout, you're referring to the contents of ~/.config/guix/current, right? It's been a little while since I peeked at that, but I believe that profile and its generations contain not only the currently installed Guix (in pre-compiled form), but also any channels the user has installed (also in pre-compiled form). Since it is not simply a Git checkout of either Guix or the channels, I'm not sure that "checkout" is the right term. But if you still think that "checkout" is easier to understand, then I would be okay with that. I feel like I am already bike-shedding, and I do not want to do that. -- Chris signature.asc Description: PGP signature
Re: GC hints
Ludovic Courtès writes: > Actually, I was also wondering whether we should provide a configurable > mechanism that would, by default, automatically delete old GC roots and > maybe even run the GC automatically when needed—similar to what Git > does. While this would be convenient and probably an improvement I’d like to mention that in the HPC use case this might be problematic as profiles might be located on file shares that are not accessible by the node running the daemon. It would be good if the GC would err on the side of caution in those cases. (It currently removes links to unreachable profiles.) -- Ricardo
Unable to Install Rust 1.20.0 and Beyond
Hi all, I’m not able to install rust. Initially, I was having problems with 1.19.0 because of memory issues. I fixed that by increasing the memory and now 1.19.0 is installed. Now that I have lots of memory 16GB, and lots of hard disk space, I cannot get 1.20.0 to install. I am installing it via: guix package -i rust It appears to be hung. guixbui+ 10572 0.0 0.2 127308 38260 ?Ssl 01:03 0:17 guile --no-auto-compile -L /gnu/store/27qw1zxljzylvm9b3jbi343gh6cngazq-module-import /gnu/store/iw20znxa586mkrv0156paq7z1ya9vcbq-rust-1.20.0-guile-builder The cpu just sits at 0.0 for this process. Normally it should be close to 100. My var/log/guix/drvs/av/xcyxs39bdzs28kya500s4kpv0xvb9p-rust-1.20.0.drv.bz2 file has the following at the end: test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1260) ... ignored test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1273) ... ok test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1306) ... ok test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1321) ... ok test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1338) ... ok test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1358) ... ok test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1409) ... ok test /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md - Standard_library_traits_used_for_error_handling (line 1440) ... ok test /tmp/guix-build-rust-1.20.0.drv-0/rustc- I have tried to install multiple times. Any ideas?
PAM module
How we can change system configurations in /etc, I want to add some pam module to pam configuration files for exapmle pam.d/login,
Re: Next browser finally on master!
> That’s because ‘guix size’ disables grafts, which allows it to check the > size of substitutes (build farms provide substitutes for ungrafted > variants.) > Before reading your message I naively installed ‘next-webkit-gtk’, which > is not supposed to be used directly, right? Should we make it private > or hidden? Hmm... I'm not sure. In the future, it could very well be that Next would have a "next-qt-webengine" platform, for instance. Then the user will have the possibility to choose explicitly. Another reason for keeping it public is that it's possible to install next-gtk-webkit on a system and have the Lisp core run on a remote machine(!!!). Well... > No. > > I assume you created the pack with: > > guix pack --relocatable -S /bin=bin sbcl-next > > Correct? > > And then you tried running it on a foreign distro? Yes and yes. > Is there a simple way to test it on a headless distro? So far, next-gtk-webkit needs a display. Its implementation was not really done with headless systems in mind. That said, it's testable on a virtual machine with a display, everything can be driven by Lisp. > Anyway, I’m trying it now and so far I like it! Thanks! It's still very alpha, but master already has much more: cookie support, echo area / status, copy/paste, etc. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Stuck upgrading from Guix v0.12
Ludovic Courtès writes: > Heya, > > Ricardo Wurmus skribis: > >> I’m in the same situation upgrading a machine that didn’t have an >> Internet connection for months. >> >> Here’s what I do: >> >> - use a git checkout to jump to commit >> b0cb92b2d43a2c4d5fa9b3f8c04c5732c60061e7, which adds guile-gcrypt >> >> - ./bootstrap && ./configure --localstatedir=/var && make clean && make >> >> - ./pre-inst-env guix package -i guile guile-sqlite3 guile-json >> guile-ssh guile-gcrypt >> >> - update to the latest version > > Just a reminder so people don’t run away ;-): the upgrade story got much > better shortly before 0.15.0, when ‘guix pull’ got the ability to “build > Guix from Guix” in a way that does not rely* on the currently installed > Guix. For example, you can run 0.15’s ‘guix pull’ and upgrade to > today’s Guix without problems. Yes, this is correct. The above recipe works when Guix is used exclusively from a git checkout. Using “guix pull” via version 0.15.0 is easier. -- Ricardo
Re: Stuck upgrading from Guix v0.12
Heya, Ricardo Wurmus skribis: > I’m in the same situation upgrading a machine that didn’t have an > Internet connection for months. > > Here’s what I do: > > - use a git checkout to jump to commit > b0cb92b2d43a2c4d5fa9b3f8c04c5732c60061e7, which adds guile-gcrypt > > - ./bootstrap && ./configure --localstatedir=/var && make clean && make > > - ./pre-inst-env guix package -i guile guile-sqlite3 guile-json > guile-ssh guile-gcrypt > > - update to the latest version Just a reminder so people don’t run away ;-): the upgrade story got much better shortly before 0.15.0, when ‘guix pull’ got the ability to “build Guix from Guix” in a way that does not rely* on the currently installed Guix. For example, you can run 0.15’s ‘guix pull’ and upgrade to today’s Guix without problems. Ludo’. * More specifically, ‘guix pull’ relies on a small subset of Guix functionality that hasn’t changed in a couple of years, which is a lot given Guix’s history.
Re: Lock screen gnome
Hi Timothy, Timothy Sample skribis: > Someday I would like to return to fixing GDM, but I am a bit > traumatized. It is a very slow and frustrating package to debug. > > 1. https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00268.html >https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00231.html I would love to have GDM fixed for 1.0 though, because this GNOME screen-locking issue, among other things, is really problematic. Is there anything we can do to help or otherwise provide motivation? :-) Thanks, Ludo’.
Re: gpg key does not exist on pgp.mit.edu
Hi Haz-Edine, Haz-Edine Assemlal skribis: > There is a small bug in the installation script guix-install.sh: > [1544622607.463]: [ FAIL ] Missing OpenPGP public key. Fetch it with > this command: > gpg --keyserver pgp.mit.edu --recv-keys > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > > However, > $ gpg --keyserver pgp.mit.edu --recv-keys > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > gpg: requesting key 3D9AEBB5 from hkp server pgp.mit.edu > gpgkeys: key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 not found on keyserver > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > > The installation manual says to import from pool.sks-keyservers.net, > which solves the problem. Indeed. A few days ago I updated the installation script to refer to pool.sks-keyservers.net instead of pgp.mit.edu. Thanks for reporting the issue! Ludo’.
GC hints
Hi! Pierre Neidhardt skribis: >(if profile >(display-hint (format #f (G_ "Consider deleting old profile > -generations and collecting garbage, along these lines: > +generations, deleting old Guix checkouts and collecting garbage, along these > +lines: > > @example > -guix package -p ~s --delete-generations=1m > -guix gc > -@end example\n") > -profile)) > +guix package --profile=~s --delete-generations=1m > +guix package --profile=~s --delete-generations=1m > +guix gc --free-space=5G > +@end example > + > +You might also want to delete old non-default profiles in > +/var/guix/gcroots/auto.") > +profile > +(string-append (config-directory #:ensure? > #f) "/current"))) I agree that this would be more accurate, but isn’t there also a risk with making hints too long? I’m split between the idea of providing concise hints that can be pasted and get things done, and the idea or not trying to be a substitute for the manual. Actually, I was also wondering whether we should provide a configurable mechanism that would, by default, automatically delete old GC roots and maybe even run the GC automatically when needed—similar to what Git does. Thoughts? Ludo’.
Re: Next browser finally on master!
Pierre Neidhardt skribis: > Forget the above, I was wrong. "guix pack" works well with regard to finding > the correct executable, with or without graft (could be wrong again, but so > far > it seems to work). > > The issue is that "next" cannot send XML-RPC requests to "next-gtk-webkit". > It > keeps polling it, but nothing flows through. > > "next-gtk-webkit" seems to be working well however, the port 8081 is correctly > open. > > I really wonder why the "next" executable fails to communicate with 8081. > > Question: Is there some network limitations when running a relocated "guix > pack"? No. I assume you created the pack with: guix pack --relocatable -S /bin=bin sbcl-next Correct? And then you tried running it on a foreign distro? Is there a simple way to test it on a headless distro? Thanks, Ludo’.
Re: Next browser finally on master!
Pierre Neidhardt skribis: > Hmm, I'm having an issue with Guix pack. > > Check out the following: > > $ ./pre-inst-env guix build next-gtk-webkit > /gnu/store/ildn4l2wr0y7irm2536dnp88hhrdphsz-next-gtk-webkit-1.1.0 > > $ ./pre-inst-env guix size next-gtk-webkit > store item totalself > /gnu/store/fd706jbvrk8zvk6175sz42xqbgc3krsg-webkitgtk-2.20.5 1057.9 > 130.3 12.1% That’s because ‘guix size’ disables grafts, which allows it to check the size of substitutes (build farms provide substitutes for ungrafted variants.) Ludo’.
Re: Next browser finally on master!
Hello! Pierre Neidhardt skribis: > I'm happy to let you know that after months of feisty packaging and the > last month spent on the full rewrite of the GNU/Linux port, the Next web > browser is finally on master! > > It's packaged as sbcl-next. Before reading your message I naively installed ‘next-webkit-gtk’, which is not supposed to be used directly, right? Should we make it private or hidden? Anyway, I’m trying it now and so far I like it! Thank you, Ludo’.
