Re: Please review blog post draft: powerpc64le-linux support
On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote: > They also say in that Twitter thread: "We have been putting together > our > systems from blob-free components only (sans NIC as is known and > being > actively worked), and this is an area where no low-cost blob-free > silicon is available right now." > I've been using the Free Software firmware replacement for the NIC since a while now and it's working great: https://github.com/meklort/bcm5719-fw/ signature.asc Description: This is a digitally signed message part
Re: Sourcehut packaging
It looks like the Makefile is the only place where csslint is called (atleast, from a quick glance at the source code) so it might work to substitute a different css minifier like one of the ones I mentioned previously and not use the npm deps at all. What do you think? We should test it. -- jgart April 8, 2021 5:11 PM, "jgart" wrote: > We have esbuild. Can esbuild replace clean-css? > > or maybe go-github-com-tdewolff-minify 樂 > > https://github.com/tdewolff/minify > > What are your thoughts? I'm just thinking out loud here. > > all the best, > > jgart
Re: Sourcehut packaging
We have esbuild. Can esbuild replace clean-css? or maybe go-github-com-tdewolff-minify 樂 https://github.com/tdewolff/minify What are your thoughts? I'm just thinking out loud here. all the best, jgart
Re: Document our WIP
Hi, On Thu, Apr 8, 2021 at 9:55 PM Luis Felipe wrote: > > I just sent a patch to include a link to the wiki in the Help page > > (https://issues.guix.gnu.org/47555). I'm sorry to not have given feedback, the Help page addition is great ! Nice wiki icon too. > > If the patch is applied, I can send a separate patch to update the Help > > menu as Vincent suggested: > > > > Help > > • GNU Guix Manual > > • Videos > > • Cookbook > > • GNU Manuals > > • Wiki > > • IRC Chat > > • Mailing lists > > I've just sent a patch to add this menu (https://issues.guix.gnu.org/47663). I'm not sure if I can help, but this LGTM (untrained eyes)... Thanks a lot -- Vincent Legoll
Re: Meta guix: making money with GNU Guix: slightly off topic
Hi guys, A bit crazy maybe but how about we completely redefine what money is? I wrote "this" (the attachment or http://datalisp.is) over the weekend (in one sitting! very raw, sorry if it's hard to understand, feel free to ask me any questions). Actually from seeing this: > Joshua Branson (joshuaBPMan in #guix) > Sent from Emacs and Gnus > https://gnucode.me > https://video.hardlimit.com/accounts/joshua_branson/video-channels > https://propernaming.org > "You can have whatever you want, as long as you help > enough other people get what they want." - Zig Ziglar It looks like you basically have the right idea about the economics, the paper describes something similar (get paid by helping others find the proper names for things). The document basically explains how to make a "cryptocurrency" that uses something like "automated science" as proof of work. Please leave preconceived notions at the door, this is not like any other cryptocurrency you are familiar with and the bit about automatic science is also slightly inaccurate, really it is hard to classify this idea (if it even works). However! I have access to funding and some other people and this pdf serves as a general overview for this (admittedly very ambitious) project. The first step (that I have in mind) is to make an education startup that teaches programming to children and teenagers, by using the ideas in the paper this can be automated and the network self-perpetuating. I am also very interested in making a "nixos-infect" type thing for Guix and asked about that in the past on the mailing lists. Let me know how you decide to proceed, I'm sure we can cooperate. Kind regards, - Ilmu ‐‐‐ Original Message ‐‐‐ On Wednesday, April 7, 2021 6:15 PM, Joshua Branson wrote: > Leo Famulari l...@famulari.name writes: > > > On Tue, Apr 06, 2021 at 12:05:00PM -0400, Joshua Branson wrote: > > > > > Aloha you lovely people! I personally believe that people should make > > > business out of free software. Here are some of my business ideas > > > involving GNU Guix. I invite you all to beat me to market! > > > > VPS service that accepts a config.scm and returns a running virtual > > machine, accessible with a web-based console (SSH, HTTPS and other > > services would be enabled by the user as desired, in config.scm). > > I'm all game to do something like this! We could be a serious contender > for linode or digital ocean! Guix already has a VPS like service...one > would just need to write the web interface...and potentially buy some > hardware. > > > -- >
Re: website: Building fails because of missing locales
Hi, On Wednesday, April 7, 2021 6:11 PM, Luis Felipe wrote: > On Wednesday, April 7, 2021 5:22 PM, Julien Lepiller jul...@lepiller.eu wrote: > > > Here's v2. > > I checked that it sets GUIX_LOCPATH properly on my system (I had to add > > the path specification for it to work). > > Thanks, Julien, with this new patch, the website builds. But I noticed other > problems now: > > 1. It does not run (haunt serve fails). > 2. Running it with "python3 -m http.server" instead, I see many characters > replaced by "?" marks. > > I'm using the commands from the website's README, but omitting "-E > GUIX_LOCPATH" and changing "lib/locale" to "lib/locales" because the former > does not exist. I managed to build and serve without problems (apparently) passing Julien's manifest to a script I use to manage Guix profiles for project development, instead of using the commands in the README.
Re: Document our WIP
Hi, On Thursday, April 1, 2021 9:33 PM, Luis Felipe > > I just sent a patch to include a link to the wiki in the Help page > (https://issues.guix.gnu.org/47555). > > If the patch is applied, I can send a separate patch to update the Help menu > as Vincent suggested: > > Help > • GNU Guix Manual > • Videos > • Cookbook > • GNU Manuals > • Wiki > • IRC Chat > • Mailing lists I've just sent a patch to add this menu (https://issues.guix.gnu.org/47663).
Re: Please review blog post draft: powerpc64le-linux support
Hello, On Thu, Apr 8, 2021 at 6:37 PM Chris Marusich wrote: > I specifically avoided speaking about the Blackbird, only because it's > not yet RYF-certified. However, perhaps I'm being too strict about it. Ah, yes, I forgot about this detail. I'd have chosen the blackbird myself, for the same reasons. But it's still a bit pricey for me though. I'd say you can talk about it, the way you proposed, as there's a high probability that it will get the certification. -- Vincent Legoll
Re: Please review blog post draft: powerpc64le-linux support
Vincent Legoll writes: > Why only speaking of Talos and not about the 3rd option: the blackbird ? > Maybe just concentrate on the vendor, more than on particular models... I specifically avoided speaking about the Blackbird, only because it's not yet RYF-certified. However, perhaps I'm being too strict about it. I actually own a Blackbird, myself. I chose to buy it instead of the Talos II or Talos II Lite because of its physically smaller form factor and its lower cost. I don't know why it isn't RYF-certified yet, but according to this Phoronix article, they are "pursuing RYF certification" for Blackbird, too: https://www.phoronix.com/scan.php?page=news_item=FSF-RYF-Talos-II Raptor Computing Systems claims that the Blackbird is "completely blob free": https://twitter.com/RaptorCompSys/status/1048373354695208960 They also say in that Twitter thread: "We have been putting together our systems from blob-free components only (sans NIC as is known and being actively worked), and this is an area where no low-cost blob-free silicon is available right now." However, the Talos II and Blackbird both use the same NIC, so I guess that wouldn't stop it from meeting the RYF requirements: https://wiki.raptorcs.com/wiki/Talos_II Networking: 2x GbE (Broadcom BCM5719) https://wiki.raptorcs.com/wiki/Blackbird Networking: 3x GbE (Broadcom BCM5719) See also: https://wiki.raptorcs.com/wiki/BCM5719 "As the BCM5719 is the only on-board device on the non-SAS Talos™ II variants to use proprietary firmware, Raptor Computing Systems has started a contest to see who can create a truly libre replacement firmware[1]. Anyone with the appropriate skill set is encouraged to take up the challenge, and contributions to this page as the device is analyzed in detail are welcomed. While the BCM5719 does, at least for now, execute proprietary firmware it is prevented from corrupting the operating system and/or other protected memory regions via the system IOMMU[2]." Thinking about this more, I think we should mention Blackbird in our blog post as a more affordable option. Let's explain that it doesn't yet have RYF certification, but the platform is very similar to the Talos II, and Raptor Computing Systems is currently pursuing RYF certification for it, too. -- Chris signature.asc Description: PGP signature
Re: Sourcehut packaging
Since your working on sourchut, would you also mind taking on adding an update for sourcehut packages, so that guix refresh works for them. There are many of them but no updater currently.
Re: A new wip-emacs branch
Hi Leo! On Thu, Apr 08 2021, Leo Prikler wrote: guix-emacs should still be loaded by site-start.el, which also initially loads your autoloads. Now that I've had more of a chance to play with it, you're right about this. I'm not sure what I did earlier, but it loaded properly just now. What changes for "Guix in Emacs modifying Emacs", is that you'll probably have to reload the subdirs.el file before autoloading the packages. Ah, okay. I just played around with this, and it seems like the sequence I now need is: $ guix install emacs-magit # shell command ... $ load subdirs # emacs command t $ guix-emacs-autoload-packages # emacs command (... list of autoload files ...) It also sees like I'm able to require the packages in Emacs after the "load subdirs" step, as well, so in practice it's still only two commands to make new Emacs packages loadable, it's just that the second command has changed. Obviously, there are exceptions to this, that we can argue on a case by case basis, but to summarize, I don't think hardcoding paths throughout Emacs is a good idea. I think there are two different cases which are more clear-cut, with a significant middle ground that's fuzzy, and using PATH just ignores this distinction entirely. There are program uses that are an implementation detail (e.g. the fact that dired uses ls), and there are programs that a user is directly interacting with (e.g. anything that I run in a shell). My thinking is that ideally the former should use hard-coded paths, and the latter should come from PATH. The tricky ones are things like geiser, or magit, where the Emacs package is a wrapper around a program's functionality. These feel like it's reasonable to go either way, but they are also the types of packages that provide ways to easily change which program they run (i.e. geiser-guile-binary and magit-git-executable for these specific examples), so they could default to a hard-coded store path because a user can easily change them if they want to use a different version. Although, as you mentioned in a previous email, TRAMP may make even those "clear-cut" cases a bit trickier. I'll admit I haven't considered TRAMP much in my thinking. As a more general comment, I feel like Guix's wrappers are often treated as "cheaper" than they are. It makes me sad that using awesome as a window manager means that I have to have LD_LIBRARY_PATH= GI_TYPELIB_PATH= before calls to external programs to stop things from crashing (and working out that I needed that was a pain in itself). I'll admit that this case with Emacs and PATH seems less dangerous than the awesome wrapper, but I'm wary of the unexpected problems that it might cause. Carlo
Re: Please review blog post draft: powerpc64le-linux support
Hello Chris, Great blog post ! I've not seen anything more than the already reported issues. On Thu, Apr 8, 2021 at 10:55 AM Chris Marusich wrote: > Talos II and Talos II Lite Why only speaking of Talos and not about the 3rd option: the blackbird ? Maybe just concentrate on the vendor, more than on particular models... Thanks -- Vincent Legoll
Re: Please review blog post draft: powerpc64le-linux support
Hi, Here's a new version of the blog post. It incorporates all the feedback so far. I've also removed the "About other freedom-friendly platforms" because it didn't seem to add much substance. I significantly rewrote the "Why Is This Important?" section, mainly because I realized that I was incorrectly and unfairly implying that POWER9 CPUs are not vulnerable to Spectre/Meltdown-style vulnerabilities. In fact, some POWER9 CPUs were found to be vulnerable, but the most recent models have been fixed. I've rewritten this section so that it focuses more on explaining why the RYF Talos II and Talos II Lite are "more free" than the popular Intel and AMD mainstays (even the older, RYF-certified models, where you still have to jump over the hurdle of removing the Intel ME or equivalent.) For details on Spectre/Meltdown on POWER9, see: https://wiki.raptorcs.com/wiki/Speculative_Execution_Vulnerabilities_of_2018 I added a footer describing GNU Guix, as is customary on most of our blog posts. I changed the title. I also fixed various links and rephrased a few things. Anyway, if you can cast your eye over it once more, I would appreciate it. I think it's just about done! -- Chris From 4d9133e51fc666f14074c1da18bb16af0d76066f Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Tue, 6 Apr 2021 00:10:35 -0700 Subject: [PATCH] website: drafts: Add powerpc64le-linux announcement. * website/drafts/new-system-powerpc64le-linux.md: New file. --- .../drafts/new-system-powerpc64le-linux.md| 389 ++ 1 file changed, 389 insertions(+) create mode 100644 website/drafts/new-system-powerpc64le-linux.md diff --git a/website/drafts/new-system-powerpc64le-linux.md b/website/drafts/new-system-powerpc64le-linux.md new file mode 100644 index 000..d2104aa --- /dev/null +++ b/website/drafts/new-system-powerpc64le-linux.md @@ -0,0 +1,389 @@ +title: New Supported Platform: powerpc64le-linux +date: 2021-04-08 00:00 +author: Chris Marusich and Léo Le Bouter +tags: porting, powerpc64le, bootstrapping, cross-compilation, reproducibility +--- + +It is a pleasure to announce that support for powerpc64le-linux +(PowerISA v.2.07 and later) has now been +[merged](https://issues.guix.gnu.org/47182) to the master branch of +GNU Guix! + +This means that GNU Guix can be used immediately on this platform from +a [from a Git +checkout](https://guix.gnu.org/manual/en/html_node/Building-from-Git.html). +Starting with the next release (Guix v1.2.1), you will also be able to +[download a copy of Guix pre-built for +powerpc64le-linux](https://guix.gnu.org/manual/en/html_node/Binary-Installation.html#Binary-Installation). +Regardless of how you get it, you can run the new powerpc64le-linux +port of GNU Guix on top of any existing powerpc64le GNU/Linux +distribution. + +This new platform is available as a "technology preview". This means +that although it is supported, +[substitutes](https://guix.gnu.org/manual/en/html_node/Substitutes.html) +are not yet available from the build farm, and some packages may fail +to build. Although powerpc64le-linux support is nascent, the Guix +community is actively working on improving it, and this is a great +time to [get +involved](https://guix.gnu.org/manual/en/html_node/Contributing.html)! + +### Why Is This Important? + +This is important because it means that GNU Guix now works on the +[Talos II and Talos II Lite +mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom), +which use [IBM POWER9 +processors](https://wiki.raptorcs.com/wiki/POWER9). This is a modern, +performant hardware platform that has recently received [Respects Your +Freedom (RYF) certification](https://ryf.fsf.org/) from the FSF. It +can run without any non-free code, all the way down to its bootloader +and firmware. In other words, it's a freedom-friendly platform that +aligns well with GNU Guix's commitment to software freedom. + +How is this any different from existing RYF hardware, you might ask? +One reason is performance. The existing RYF +[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC), +[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC), +and +[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC) +can only really be used with Intel Core Duo or AMD Opteron processors. +Those processors were released over 15 years ago. Since then, +processor performance has increased drastically. People should not +have to choose between performance and freedom, but for many years +that is exactly what we were forced to do. However, the Talos II and +Talos II Lite have changed this: the free software community now has +an RYF-certified option that [can compete with the performance of +modern Intel and AMD +systems](https://www.phoronix.com/scan.php?page=article=power9-threadripper-core9=1). + +Although the performance of POWER9 processors is competitive with
Re: A new wip-emacs branch
Hi Carlo, Am Donnerstag, den 08.04.2021, 13:17 +1000 schrieb Carlo Zancanaro: > Hi Leo! > > Thanks so much for working to improve Emacs packaging in Guix! I > have a question and a comment about your approach on the wip-emacs > branch. > > On Tue, Apr 06 2021, Leo Prikler wrote: > > Emacs now gets its core lisp path from the wrapper rather than > > the search path and there's a new profile hook adding all > > top-level subdirectories to a subdirs.el, that gets loaded at > > startup. > > This sounds great in terms of Emacs starting in an already > established profile, but one key use case for me is to be able to > install new packages without restarting Emacs. Usually I can do > this in eshell by running > > $ guix install emacs-magit # shell command > ... > $ guix-emacs-autoload-packages # emacs command > ... > > I just tried this in a fresh profile with a Guix built from > wip-emacs, but it didn't seem to work. It's possible that I've > done something wrong (I'm doing it with time-machine, which adds > its own complexities), but are you expecting this to work? It > looks like guix-emacs wasn't loaded, and it wasn't on the load > path, but I haven't had a chance to investigate further than that. guix-emacs should still be loaded by site-start.el, which also initially loads your autoloads. What changes for "Guix in Emacs modifying Emacs", is that you'll probably have to reload the subdirs.el file before autoloading the packages. The following snippet in (normal-top-level) seems to be responsible for setting up the load-path during init: ;; Look in each dir in load-path for a subdirs.el file. If we ;; find one, load it, which will add the appropriate subdirs of ;; that dir into load-path. This needs to be done before setting ;; the locale environment, because the latter might need to load ;; some support files. ;; Look for a leim-list.el file too. Loading it will register ;; available input methods. (let ((tail load-path) (lispdir (expand-file-name "../lisp" data-directory)) dir) (while tail (setq dir (car tail)) (let ((default-directory dir)) (load (expand-file-name "subdirs.el") t t t)) ;; Do not scan standard directories that won't contain a leim- list.el. ;; https://lists.gnu.org/r/emacs-devel/2009-10/msg00502.html ;; (Except the preloaded one in lisp/leim.) (or (string-prefix-p lispdir dir) (let ((default-directory dir)) (load (expand-file-name "leim-list.el") t t t))) ;; We don't use a dolist loop and we put this "setq-cdr" command at ;; the end, because the subdirs.el files may add elements to the end ;; of load-path and we want to take it into account. (setq tail (cdr tail Perhaps we should extract it as a whole/some bits of it into a guix- emacs procedure, that is normally not called? > > Extending PATH in the same wrapper as EMACSLOADPATH seems to be > > a fairly cheap option, however. > > I'm not supportive of this, because extending PATH would also > change the binaries that are available through Emacs' shells, > which I use a lot. This would mean that either (a) the Emacs > packages can shadow what I've explicitly installed in my profile, > potentially leading to me running unexpected versions of programs, > or (b) installing something else in my profile might break > something in Emacs because the version has changed. This isn't > likely to be a major problem for coreutils and gzip, assuming > they're stable enough, but it is a problem in general. In my view > either patching the Emacs libraries (to avoid the conflict) or > propagating inputs (to expose the potential conflict while > building the profile) are better options. I don't think I agree with you here. For one, I'd suffix PATH like EMACSLOADPATH, so (a) will not happen. Recall, that in (b) you're describing the status quo. Yes, you will be able to bork Emacs by installing a malicious version of coreutils into your PATH, but that'd also happen if you did so currently. The only difference, is that you currently also bork it, if you don't have any coreutils at all, which is typically only the case in pure environments or containers. As for Emacs libraries written in Elisp, I'm kinda split. I'm not even sure if they should have a fallback when your environment is borked tbh. Consider Geiser for example. To correctly set up Geiser+Guile, you would not only Guile to be installed, but also GUILE_LOAD_PATH to be set to a meaningful value. This can be done with Guix environments by adding Guile, but doing so without Guile and its search paths from elisp is somewhat difficult. I also enjoy being able to hack with Geiser in Guile 3, even though the package builds against Guile 2.2, without needing to install a different one. Obviously, there are exceptions to this, that we can argue on a case by case basis, but to
Re: [PATCH 0/9] Add 32-bit powerpc support
On Wed, Apr 07, 2021 at 10:33:33PM +0200, Vincent Legoll wrote: > Hello, > > On Tue, Apr 6, 2021 at 2:26 PM Efraim Flashner wrote: > > The wip-ppc branch on Savannah is currently in a good state. With the > > recent rapid churn on core-updates I haven't been very quick about > > rebasing on core-updates but I can confirm that building out to mesa > > works. Building is slow, it took 6 days to build from guile-final to > > mesa without stopping. > > I still haven't dragged my G4 mini from its osx misery, so I tried > cross-building (from x86_64) instead. > > cross-builds ok: > * bootstrap-tarballs > * guile > * binutils > * mac-fdisk > > failed: > * guix (perl refused to cross-build) > * nss, because nspr failed with: > [...] > ../../../config/./nsinstall -R -m 444 ./_aix32.cfg ./_aix64.cfg > ./_bsdi.cfg ./_darwin.cfg ./_freebsd.cfg ./_hpux32.cfg ./_hpux64.cfg > ./_linux.cfg ./_netbsd.cfg ./_nto.cfg ./_openbsd.cfg ./_os2.cfg > ./_qnx.cfg ./_riscos.cfg ./_scoos.cfg ./_solaris.cfg ./_unixware7.cfg > ./_unixware.cfg ./_win95.cfg ./_winnt.cfg > ../../../dist/include/nspr/md > ../../../config/./nsinstall: ../../../config/./nsinstall: cannot > execute binary file > > mesa and afl refused because of meson-build-system. There's currently a bug with cross-building on core-updates. I ran into it while trying to build rust for i686. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Please review blog post draft: powerpc64le-linux support
Hi Léo, Léo Le Bouter writes: > It's been mostly you here Chris, thank you so much for writing it, as > others said, it is really beautifully written! Unfortunately I havent > felt enough peace of mind to write like you did :-( You've been busy! It's totally understandable. The encouragement from you and others has been very useful and motivating for me, so thank you. > I would've liked to write about the early days where I met some > problems with the core-updates branch having to rebase several times > and learning GNU Guix at the same time since my first ever project > related to GNU Guix was porting before even trying to use it elsewhere. > Having to learn the GNU commit message guidelines, then learning git- > send-email and GNU Emacs (since that's where all dev tools are), all > that to contribute to GNU Guix and get this port in. Aaaahh very long > story! I agree. Those are interesting topics. I tried to include some discussion about it, but the post became too lengthy. I just want it to be about the new support, mainly, and why it's exciting. I think that the following related topics would make good candidates for future blog posts: - An analysis of trust in Guix, with an eye towards bootstrapping. If you use substitutes, what are you implicitly trusting? If you build without substitutes, what are you implicitly trusting? If you build Guix from source without using Guix, like you have to do when you first port Guix to a new platform, what are you trusting? A comparison of similar paths of trust when using other software. Make a script to find out if there are any forgotten "bootstrap roots" beyond the bootstrap binaries, like there apparently used to be for some self-hosted compilers (see: https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html). Stuff like that. I think it is not obvious. - An analysis of the hurdles / friction involved in contributing. Preferably with suggestions for ways to remove the hurdles and reduce friction. It is easy to complain or bikeshed, of course, but the point is not to do that. The point is to discuss issues to try and make things better. Thank you again for your help! This is just the beginning - let's keep hacking away at it and improving POWER9 support together! Hopefully others will see the benefits of the platform and join us along the way. -- Chris signature.asc Description: PGP signature
