Guix home and operating-system
Hi Guix, I'm finally having some time to try and put guix on the older machines at home and thought I'd start by generating a live CD to show the rest of the family what that would look like without having to make any irreversible changes yet. Meanwhile, as this is a time to clean and rationalize system declarations to ease maintaining the various machines, I thought it would be an appropriate time to try and start learning about guix home (I came to guix for the reproducibility, I'm not going to spend hours on each machine reproducing the same user config !). To my greatest astonishment, I found no way to make guix home configurations interact with operating-system declarations. I expected something along the lines of a "configuration" or "home" field in the user-account data type, which could contain directly a valid guix home configuration or maybe the path to a file containing one. At least, I expected to find a "packages" field to allow specifying the packages set for a particular user. This is of course necessary when building a read-only live image which won't be able to receive modification at a later time. More generally, this raised a question in me: why go to such length to have a whole declarative system which you can generate in advance on each aspect, and then require to launch (stateful !) command lines at a later time to alter the configuration of users. I was discussing that the other night with @unmatched-paren on IRC and was told this could be an interesting idea so what do you think ? Is there a good reason why this hasn't been implemented ? Would it be very complicated to run the equivalent of a guix home at the end of the system generation ? I'd be personally interested to work on such a feature but I have absolutely no idea where to start and would be glad to receive some pointers if it was deemed useful enough that I should spend my time on it. Now I can think of several ways to do that differently: I suppose the live CD could have a system service performing the call to guix home to setup the user's environment during the boot. Also, this would not cover user services but regarding file configurations, I can think of a way because I'm prone to config vertigo these days: there are so many levels where we can alter the config, why always delay it ? Packages often contain a default configuration, and upon start the program checks half a dozen places for a custom user config: in other words why have a bash profile in my home when I could generate a bash package which has directly my dream profile in its "default" version in /etc ? I could still use ~/.bash_profile for a temporary tweak. Is that something people in guix do frequently ? Why ? Cheers, Tissevert
Re: Update CoC adapted from upstream 2.1 (instead of 1.4)
Hi, And, how exactly can "sex characteristics" be involved in the kind of interactions we're having in this community ? In particular, as this has already been explained patiently enough, how are "sex characteristics" any different from "gender identity" from its perspective ? If someone here is able to discriminate against someone else based on their "sex characteristics" (whatever that means) independently from their "gender identity", then I'm ready to bet their problems doesn't belong in the Guix community and its usual scope and had rather be discussed within the legal framework instead. Are dickpics going to be necessary to sign commits from now on ? Also, why isn't this message part of the other thread[1] ? How is this discussion any different ? Am I missing something obvious here ? If so I am truly sorry but I re-read Zimoun's message a couple times and I still fail to see the difference with Taylan's patch. Has the OP accidentally missed it by any chance ? And to avoid remaining on the implicit side of things, yes, I do oppose. Tissevert [1]: https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00198.html Le Fri, 25 Feb 2022 01:09:46 +0100, Tobias Geerinckx-Rice a écrit : > Hi, > > On 2022-02-25 1:05, zimoun wrote: > > So, since we are at it, let give a look at the most recent version > > v2.1 [3]. :-) I propose to adopt their extended list: > > > > regardless of age, body size, visible or invisible > > disability, ethnicity, sex characteristics, gender identity and > > expression, level of experience, education, socio-economic status, > > nationality, personal appearance, race, caste, color, > > religion, or sexual identity and orientation. > > > > Any opposition? > > I think this is an excellent idea, Simon (and Ricardo who suggested > the same). > > Kind regards, > > T G-R > > Sent from a Web browser. Excuse or enjoy my brevity. >
Re: [minor patch] Amend CoC
, not like those transgender people". And that I think is not acceptable in our community. I hope to have clarified why the current formulation is already as inclusive as can be and to have reassured you that there is no middle between two incompatible sides where to meet. Kind regards, Tissevert Le Sun, 20 Feb 2022 23:45:04 +0100, Taylan Kammer a écrit : > On 20.02.2022 22:02, Liliana Marie Prikler wrote: > > > > "Sex is distinct from gender" is a common transphobic talking > > point. > > Like I said I don't actually want to argue, but I really feel the need > to point out that what you seem to consider a transphobic talking > point is seen as a fundamental principle of feminism by many others, > and that long predates the contemporary transgender movement. > > "One is not born, but rather becomes, woman. No biological, psychic, > or economic destiny defines the figure that the human female takes > on in society; it is civilization as a whole that elaborates this > intermediary product between the male and the eunuch that is called > feminine." > -- Simone de Beauvoir, The Second Sex (1949), 2010 translation > > This is one of the most iconic passages from the book (especially the > first sentence on its own), and the book is considered to be pretty > much one of the most important works in feminist history. > > Given that, I find it somewhat baffling that distinguishing between > sex and gender is now apparently considered transphobic. (This isn't > the first time I'm hearing that claim, but I was under the impression > that it's a very fringe position.) > > Actually, I could swear that only about 5 years ago, "sex and gender > are *not* the same" was a very common thing transgender activists > would say. I might actually have learned that principle from trans > activists before reading up on feminist literature. > > Anyhow, all that is only tangential to the topic at hand. In context > of this topic, I want to mainly highlight one thing, which is that > regardless of what one thinks about gender as a social construct, > gender identity and expression, transgender identities, and so on, > there is undeniably a number of ways in which people born with female > anatomy have been and continue to be mistreated throughout history > and around the planet. To acknowledge that has very little to do with > transgender identities, and at no point did I or will I argue that the > CoC should for instance exclude "gender identity" from the list. > > Is it possible that we would meet in the middle on this topic and > acknowledge both perspectives? >
Re: Guix Package Search API Server
I see. Thank you very much for this piece of information ! And I'm relieved to know everything is fine with the UMC Utrecht instance. Le Fri, 7 Jan 2022 00:13:40 +0530, Sai Karthik a écrit : > You could also obtain the json file from > https://guix.gnu.org/packages.json > > On 05/01/22 13:08, Tissevert wrote: > > Hi, > > > > This JSON file sounds nice and useful. By the way, it may only be a > > transient error but the instance of hpcguix-web running at UMC > > Utrecht mentioned in the github repos seems to be down > > (https://hpcguix.op.umcutrecht.nl/). Is it supposed to be so ? > > > > Tissevert > > > > Le Mon, 03 Jan 2022 17:27:56 +0100, > > Ludovic Courtès a écrit : > > > >> Hi! > >> > >> Sai Karthik skribis: > >> > >>> Nice! I didn't knew about this earlier. Does hpc.guix.info exposes > >>> API ? > >> > >> It runs hpcguix-web¹, which exposes a big (but gzipped) JSON file > >> at <https://hpc.guix.info/packages.json>. Everything else happens > >> in client-side JavaScript code. > >> > >> Ludo’. > >> > >> ¹ https://github.com/UMCUGenetics/hpcguix-web > >> > > >
Re: Guix Package Search API Server
Hi, This JSON file sounds nice and useful. By the way, it may only be a transient error but the instance of hpcguix-web running at UMC Utrecht mentioned in the github repos seems to be down (https://hpcguix.op.umcutrecht.nl/). Is it supposed to be so ? Tissevert Le Mon, 03 Jan 2022 17:27:56 +0100, Ludovic Courtès a écrit : > Hi! > > Sai Karthik skribis: > > > Nice! I didn't knew about this earlier. Does hpc.guix.info exposes > > API ? > > It runs hpcguix-web¹, which exposes a big (but gzipped) JSON file at > <https://hpc.guix.info/packages.json>. Everything else happens in > client-side JavaScript code. > > Ludo’. > > ¹ https://github.com/UMCUGenetics/hpcguix-web >
Re: website: A little help running the website locally
Hey, it works here without -E GUIX_LOCPATH and without sharing any 'lib/locales?' file, system- or user-wide. Does that work for you too, Luis-Felipe ? If it does, should we entirely remove any mention of them in the build / serve instructions in the README ? Le Fri, May 21, 2021 at 12:38:26PM -0400, Julien Lepiller a écrit : > Apart from breaking my system somewhat, I tried again, and I think you > shouldn't pass -E GUIX_LOCPATH, because this will refer to something outside > the environment. Instead, you should let the manifest set that for you. It > will read po/LINGUAS to figure out which locales to bring in the environment. >
Re: website: A little help running the website locally
Hi ! I'm afraid I saw your message too late because I have exactly the same problems you describe in https://issues.guix.gnu.org/47623 which you've just closed. I too have no ~/.guix-profile/lib/locale but ~/.guix-profile/lib/locales exists and allows the build to complete. So I don't know but could this ~/.guix-profile/lib/locale with no trailing 's' be a left-over from a previous version of some software that used to build it at that location or something ? My install of guix is pretty recent (~3 months). >From what I understood from the original issue, I checked $GUIX_LOCPATH and saw it contained only my current system's, /run/current-system/locale, which, when shared in place of this hypothetical `locales?` in $HOME/.guix-profile also allows haunt to build the site correctly (it produces something, reports success, and browsing what it serves looks like the official website). Hope that helps : ) Tissevert Le Fri, May 21, 2021 at 01:53:43PM +, Luis Felipe a écrit : > Hi, > > I've never been able to build and run the internationalized website correctly > following the instructions on the README. I even thought there was a typo in > the instructions (https://issues.guix.gnu.org/47623), but it seems there is > actually a particular problem on my side that I don't know how to resolve. So > I could use a little help. > > The problem seems to be that the instructions on the README expect a > "$HOME/.guix-profile/lib/locale" directory to exist, but it doesn't exist > here. There is a "$HOME/.guix-profile/lib/locales" directory instead (note > the plural name). > > I've tried building and running the website using the "locales" directory to > work around the issue. It used to build most of the time, but with enconding > issues. Running the website almost always failed with some error about > invalid arguments to "setlocale"), so I used plane "haunt serve". > > Currently, though, using guix 1f68568 and guix website f7ca68f, building > fails for me everytime I run this: > > > $ GUIX_WEB_SITE_LOCAL=yes guix environment -C -m manifest.scm -E GUIX_LOCPATH > -E LANG --share=$HOME/.guix-profile/lib/locales -E GUIX_WEB_SITE_LOCAL > --share=/tmp -- haunt build > guile: warning: failed to install locale > Backtrace: >2 (primitive-load "/gnu/store/yzaxlqmiraznba4yf2cyqpyla9q?") > In haunt/ui.scm: > 131:2 1 (haunt-main _ "build") > In unknown file: >0 (setlocale 6 "") > > ERROR: In procedure setlocale: > In procedure setlocale: Invalid argument > > > > So I haven't been able to work much on the website for a long time. I don't > know what's going on... > > > --- > Luis Felipe López Acevedo > https://luis-felipe.gitlab.io/ >
Re: GNU Guix 1.3.0rc1 available for testing!
Hi !! On Mon, 3 May 2021 20:34:54 -0400 Leo Famulari wrote: > I think that a big part of why we offer the SysV-init "/etc/init.d" > service management script is to serve Devuan — there are not many > distros using that style of service management anymore. If `daemonize` > is not available by default on Devuan, I wonder if there is some other > way we should be writing the script. > > Can you check some "Devuan provided" scripts in '/etc/init.d' and see > if they use a different method of daemonizing things? Oh really ? I didn't think devuan was well-known enough for it to have an impact on a design choice like this. Well no other of the 69 scripts I have in /etc/init.d use daemonize. Most of them use /sbin/start-stop-daemon, although the point of running Devuan was to have runit, but it's so well hidden you wouldn't know it's PID 1 here… which is the main reason why I'm giving up on Devuan, I came for my favourite, easy to use, init system, not for some compat-bloat over it that end up hiding the best feature. So if this script is only for Devuan, I think a proper runit daemon may be better. Regards, Tissevert
Re: GNU Guix 1.3.0rc1 available for testing!
Hi !! I've just given the binary tarball a spin on Devuan. Worked almost flawlessly (daemonize wasn't installed and I missed the part when it was mentioned because I was a bit in a hurry but apart from that the overall experience was great — the guix text art was surprising in a good kind of way). I got the warning about the GPG keys, and I confirm I got a single warning for both keys at once with a very simple click'n'paste command to import the keys and fix the problem. Once installed and the daemon started manually, it looks like it works (at least the simple things I use do). To answer Leo's question if I understand it correctly, I can guarantee you that absolutely no guix-related user or group existed before I ran the script, and they have been successfully created (10 guix builder users named `printf "guixbuilder%02d" <$> [1..10]` and 1 group named guixbuild). It's so cool to be able to use Guix on that box (I'll soon reinstall it with Guix I think but in the meantime it's there and that's handy). Thanks ! Tissevert On Sat, 01 May 2021 01:45:57 -0400 Maxim Cournoyer wrote: > Hello Guix! > > A first RC for the upcoming 1.3.0 release is now available for > testing: > > source: > https://alpha.gnu.org/gnu/guix/guix-1.3.0rc1.tar.gz > > binary tarball (to install on a “foreign distro”): > https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.aarch64-linux.tar.xz > https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.armhf-linux.tar.xz > https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.i686-linux.tar.xz > > https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz > https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz > > system installation: > > https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.i686-linux.iso.xz > > https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.x86_64-linux.iso.xz > > virtual machine image: > > https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz > > SHA256 hashes: > > 46525e84d2a1d30a53bb40569de23bb1813b8df78731d09b5eac977818106ea7 > guix-1.3.0rc1.tar.gz > 2427e73f5f18c51446174cd230b6dc19c8461838641bec6f66761537e7aa7ad4 > guix-binary-1.3.0rc1.aarch64-linux.tar.xz > 89028139d049e1a868d41c5d1155f6b3be1b1b0407d93bfa86b7c713a87c1daf > guix-binary-1.3.0rc1.armhf-linux.tar.xz > 5da4edf9075c87d575d653140b53fe316305f94b58179aa935af223f037b36c2 > guix-binary-1.3.0rc1.i686-linux.tar.xz > f7c2a42f9f48fc6b2d7ba672ed49c3a6fc483cb3fbe261a8a79385b8381205ec > guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz > 3348ec2fd116ed97c1806f8eac777ab2f7cff2b466b7c0dc5c2d1a904e4395f7 > guix-binary-1.3.0rc1.x86_64-linux.tar.xz > 429deb5af3a956e7530cd0ed4cab7d5b13a7f1d22a0fe690f6714ab89a846db6 > guix-system-install-1.3.0rc1.i686-linux.iso.xz > a1772a8d08729471e7b1c04ac4d9213f4db077458aeacc59d14ff9f2399357b2 > guix-system-install-1.3.0rc1.x86_64-linux.iso.xz > 58ccabbc61cd00d9b1ec1f417360827aa2f8428567f1cfb0a83dc2191e67897e > guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz > > All these files have an associated ‘.sig’, an OpenPGP signature that > you can verify as explained at > <https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>. > > You can help by: > > 1. Testing the binary tarball on the distro of your choice. You can > download <https://guix.gnu.org/install.sh>. Uncomment the > ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it > should pick up 1.3.0rc1 automatically. > > 2. Testing the graphical installer of Guix System. > > 3. Testing the VM image. > > In any case, please report success, failure, and annoyances in this > thread. > > The remaining outstanding issues, which you can track here [0], are as > follow and affect the installer: > > 47567 Installer crash in 'uuid->string' for a FAT16 partition > 44872 Installer crash: 'uuid->string' is passed #f in lieu of a UUID > > If everything goes well, the final release is planned for the 10th of > May, which gives us about a week to test and fix any remaining issues. > > Thanks in advance! > > Maxim > > [0] http://issues.guix.gnu.org/47297 >
