IRC channel logs


back to list of logs

<daemon77>systemd[24669]: guix-daemon.service: Failed to execute command: Permission denied
<daemon77>systemd[24669]: guix-daemon.service: Failed at step EXEC spawning /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon: Permission denied
<daemon77>systemd[1]: guix-daemon.service: Main process exited, code=exited, status=203/EXEC
<daemon77>systemd[1]: guix-daemon.service: Failed with result 'exit-code'.
<daemon77>I am running as root
<lfam>daemon77: What happens if you try to invoke `/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon` by hand? Does the file even exist?
<lfam>And how did you install Guix?
<daemon77>yep that works fine
<daemon77>I followed the binary install steps
<lfam>Can you put the systemd service file on
<lfam>Are you using anything like SElinux?
<lfam>That could interfere
<lfam>Check your selinux audit.log, wherever that may be
<daemon77>sestatus reports it as enabled
<lfam>I've never used selinux so I can't give specific advice about it or interpret that
<lfam>I googled 203 unix error code and found people talking about selinux in the context of starting things with systemd
<daemon77>I'll look into it
<daemon77>thanks for the pointer
<halfdann>I had the same issue when running SELinux. The right way is probably to install an SELinux policy, but that didn't work for me, so now I just disable it (sudo setenforce 0, then restart the daemon)
<lfam>Hm. It would be great to make it work properly. I feel like this has been discussed at length on guix-devel in the pasty
<nckx>Pasty's canon now.
<nckx>I thought we had a policy?
<lfam>Oh, could be
<lfam>selinux is in the category of things that I ignore completely
*jonsger tried once to add an AppArmor profile for guix...
<nckx>How did that path-based plan go?
<halfdann>Oh I do have the daemon running with SELinux enabled for a while now, and the policy works; was recalling some issues from the past
<jonsger>nckx: not really well
<nckx>I can imagine.
<mwette>Hi all. I spent some time trying to get SElinux working. I gave up and use "setenforce 0". I can post my notes.
<mwette>There were some items missing from the .cil file. I sent in as bug report. In the meantime I was reading the wiki and decided to recode according to suggestions there.
*janneke rebases and pushes wip-hurd
*janneke -> zZzzz
<mwette>This is all super-cil-hackage, but maybe worth something:
<nckx>mwette: Thanks! I don't use SELinux myself but it might be useful to someone.
<mwette>maybe useful notes:
<Veera>Hi guix
<Veera>in gnu-build-system how to run ./
<nckx>Veera: First, try simply adding autoconf and automake to native-inputs. gnu-build-system will try to auto-bootstrap things when they are present.
<nckx>It doesn't always work but sometimes it does.
<Veera>nckx: ok I try
<nckx>You might have to add libtool, gettext-minimal, … as well if you get error messages.
***wxie1 is now known as wxie
<Veera>How to remove a file from store
<Veera>Actually i used (patches (list "/tmp/a.patch"))
<Veera>guix build is using the old patch file even after updating it
<Blackbeard>Hello :)
***wxie1 is now known as wxie
<nckx>Veera: I've never seen Guix cache a patch, ever. But I always put my patches in gnu/packages/patches and use (patches (search-patches "…" ["…"])), which is what you'll need to use upstream anyway.
<nckx>Hullo Blackbeard.
<nckx>Would you take my torch & my cape
<nckx>I'm off to bed.
<nckx>Good night!
<mroh>Veera: `guix gc -D storeFile`
<mroh>nckx: gn8!
<apteryx>can I export a DISPLAY in a Guix environment container, to run a X application?
<Veera>is it safe to delete the directory which guix build creates in /tmp/
<apteryx>nckx: night!
<apteryx>Veera: sure
<apteryx>rm -r /tmp/guix-build*
<Veera>I removed that and guix build is not applying patches anymore
<Veera>It does not make sense though
<apteryx>no, it doesn't :-)
<Veera>guix build log is not showing the patching line
<Veera>previous it was showing
<apteryx>guix build of what?
<Veera>actually the patch is for configure and
<Veera>so does it bypasses for those files
<Veera>guix build of xchat
<apteryx>Veera: Usually the patches for packages are kept under gnu/packages/patches
<apteryx>and then you can just use (patches (search-patches "file-name.patch"))
<apteryx>grep the sources, you'll find lots of examples
<Veera>is using local-file bad
<Veera>can I keep my test patches there
<apteryx>in a package? yes
<Veera>should be one patch or group of
<apteryx>I see only one use of such thing in the guix sources, and it seems advanced wizardry to me.
<Veera>can I keep my test patches in gnu/packages/patches
<apteryx>sure, why not
<Veera>In other distros they keep a group of patches for easy review and changing
<Veera>in a separate folder for concerned pkg
<apteryx>In Guix in general we prefer patching directly in the package definition if the changes are trivial, using the substitutes* macro.
<apteryx>by adding an extra phase
<Veera>is it easy to do
<Veera>I am new learner
<apteryx>my best advice is to look through the sources for examples, there are plenty.
<Veera>So I want to go quick. At least a first successful build and install
<apteryx>You'll learn a lot by looking at actual examples
<Veera>then do proper way
<apteryx>sure, that's reasonable
<Veera>also am an outreachy applicant for guix
<apteryx>Neat :-) and welcome!
<Veera>Oh I saw patch for abiword and thought
<Veera>glibc ghc have many patches
<Veera>I will do this way
<brendyyn>Veera: Generally i make a branch of of the git repo and make all changes there, i would only do things seperately if i was making packaings only intended for my own use
<Veera>As for patch submission for new pkg, do I have to submit my xchat.scm file
<brendyyn>guile is a general purpose language, so narually there are many ways of doing the same thingse but some ways provide less resistance
<Veera>and the patches
<Veera>Yes I have done git clone of guix.git
<Veera>and using
<brendyyn>Veera: people post everything as a patch set to the guix-patches mailing list
<Veera>I tried placing my xchat.scm file in gnu/packages but it does not works
<brendyyn>even the creation of a new file is a patch.
<OriansJ>Veera: guix package -f file.scm should always work
<Veera>I see for other pkgs there are definitions in Makefile
<Veera>Am using guix package search env var for pkgs
<brendyyn>Veera: If you have created a new file and expect it to be available when you run ./pre-inst-env guix ..., then that means it needs to be a module like the other files
<brendyyn>it would start with (define-module (gnu packages xchat) ...
<Veera>I followed exactly as gkrellm, abiword but ./pre-inst-env guix package --list-available=xchat does not works
<Veera>brendyyn: i did exactly that
<brendyyn>can you upload your changes to
<Veera>I have to modify it again and try
<apteryx>raghavgururajan: about linphone, cool! I was thinking about that one yesterday. I hope you make it :-) I'll be happy to test.
<guix-vits>Hi Guix
<mroh>Hi guix-vits!
***net_ is now known as Veera
<Veera>test xchat
<brendyyn>seems you got it working
<Veera>a basic one
<Veera>no ssl no ipv6
<Veera>xchat license is gplv2 only plus exception for linking with openssl
<Veera>is it okay for inclusion in guix
<Veera>how to add exception licenses to guix
<brendyyn>good question it seems like for thc-ipv6 there is merely a comment.
<brendyyn>probably you would just set it as gplv2
<Veera>ipv6 can be enabled, I have to about it's stability
<Veera>i have no ipv6 in home internet so i can 't check it
<Veera>i will see
<Veera>Also Debian 10 Buster has xchat
<Veera>I will it's doc too.
<KE0VVT>Although there was this old amateur radio program that is based on XChat, which I would like to use one day.
<Veera>thank all
<Veera>thank to gabor boskovits for the lead for xchat
<drakonis>dont actually add xchat tho
<drakonis>add hexchat
<drakonis>xchat is completely unmaintained now
<drakonis>the reason it is on debian is due to a debian maintainer getting nostalgic
<bdju>Hexchat is already packaged for guix it looks like.
<KE0VVT>I thought people were considering it, and that would be my only reason for taking them seriously.
<drakonis>no dont
<Veera>xchat is kept maintained for latest debian 10
<drakonis>no tisnt
<drakonis>dead upstream
<KE0VVT>I wish CWIrc was not ported to HexChat. :-(
<Veera>yes hexchat is already there for guix
<drakonis>xchat is very much dead and hexchat is where development continued
<drakonis>let me see
<drakonis>see this
<KE0VVT>Somehow, CWirc cont. to op. on #cw but cannot run on any modern OS.
<Veera>well last xchat source release is 2010
<Veera>i will see that bug report
<drakonis>actually dont
<drakonis>check the blog post
<drakonis>because the person maintaining the xchat package on debian has questionable motives
<Veera>well Gabor Boskovits told me to see Guix:Group Wishlist
<drakonis>nostalgia really
<drakonis>it is honestly weird and misguided nostalgia
<drakonis>its been 10 years since a release
<KE0VVT>drakonis: I wouldn't mind running CDE on Guix System. :P
<drakonis>one thing is CDE
<drakonis>the other is a web facing application
<drakonis>irc RCEs yall
<brendyyn>I heard there is the hexchat fork, which is already in guix
<KE0VVT>HexChat fork? Ei, ei, ei!
<bdju>the fork that is known as hexchat is how I read it
<KE0VVT>I thought someone forked the fork of XChat.
<drakonis>the fork formerly known as the fork of xchat
<Veera>Hey I read the pages and as a user or packager I cannot make anything out of it.
<drakonis>rather, the fork formerly known as the fork of the fork of hexchat
<drakonis>okay so
<drakonis>as it turns out
<Veera>Only who knows the code can say
<drakonis>a debian developer got nostalgic for a unmaintained application and decided to keep it on debian with patches
<drakonis>despite the fork being maintained and being vastly better
<drakonis>he also decided to patch the cves
<drakonis>backport patches
<drakonis>despite there being way more exploitable bugs than cves
<Veera>So drakonis should I do some other project for Outreachy contribution
<brendyyn>Veera: In short it looks like Guix developers will most likely not wish to include this debian xchat fork.
<drakonis>hmm, there's a variety of other things
<Veera>drakonis: can you give leads
<Veera>please then remove xchat from Guix Wishlist
<brendyyn>Oh is it there i didn't know
<drakonis>i'm not a guix developer but i'm fairly certain its a bad idea to do xchat
<Veera>libreplanet Guix:Group Wishlist page
<drakonis>what are your skills?
<brendyyn>Personally I'd like Icedove, but it may be a big project
<Veera>Please read Outreachy Guix Project page
<Veera>The project with DannyM as Mentor
<Veera>Yes DannyM told to do some small GUI program for contribution
<brendyyn>Veera: I apologise for this. Many of us are just contributers that may not have paid attention that that stuff, and most the core developers are in europe i think so they are not online yet
<drakonis>the overall timezone is heavily skewed towards europe
<drakonis> you've been here, right?
<Veera>Well I see your names not on Guix Savannah's member list
<drakonis>clearly not
<Veera>I will wait for input from Outreachy Guix Coordinators specially project Mentor
<drakonis>nckx: hey you around?
<drakonis>or lfam even
<lfam>What's up drakonis
<Veera>lfam: Hi
<drakonis>say, packaging xchat seems to be a big no these days as it hasnt been maintained in 10 years
<drakonis>hexchat exists as a irc client
<drakonis>just running it through you real quick
<Veera>lfam: I was able to build xchat and install
<drakonis>as soon as i heard about that, i had to say that its likely a poor package to include
<lfam>I can't really say one way or the other. It's a good exercise regardless
<drakonis>hasnt been maintained in 10 years but a debian developer decided to include it on the debian archive out of nostalgia
<lfam>Quite a few programs are basically abandoned like that
<drakonis>it got forked into hexchat
<drakonis>so, would probably be best to have something else instead?
<Veera>I will wait for input from Danny Milosavljevic, Gabor Boskovits, Ricardo and Ludovic
<lfam>I mean, if there some grave problem with it, then we'll need to address that. But it's not necessarily a problem that it's old or has some more popular fork.
<lfam>It does seem to exist in a lot of the major distros:
<drakonis>only in older releases
<drakonis>there are a variety of grave problems
<lfam>We'll let the outreachy mentors handle it, drakonis. There is a process
<lfam>Even if we decide not to include the package, it's important for Veera to work on this task and go through the patch review process
<drakonis>fair enough
<drakonis>i have forgotten this
<drakonis>my bad.
<brendyyn>I edited the page
<brendyyn>Veera: An interesting decent sized project would bee to at Jitsi Meet. I think it requires a lot of packages, plus a service definition for all the parts. when complete, people could easily launch up their own service like
<Veera>lfam: For the approval of contribution I thought it's needed include the pkg in Guix
<lfam>Veera: I think you should continue with whatever your mentor asked you to do. I think that's the important thing right now
<Veera>lfam: They did not told any specific app to be done
<Veera>lfam: DannyM said any small GUI app that I like
<guix-vits>neverball (game)?
<lfam>Veera: DannyM is your mentor?
<Veera>lfam: yep
<lfam>Okay, Danny will tell you what is the right thing to do
<lfam>brendyyn: Jitsi Meet is awesome but we don't have a good javascript packaging system in Guix
<brendyyn>ok then maybe that is a tall order then :P
<lfam>We had a similar issue with Jitsi itself, which is Java. We can do Java but it's tough
*apteryx successfully built emacs-elpy 1.32 \o/
<apteryx>after stepping into emacs internals
<lfam>Hooray apteryx
<guix-vits>is rsync enough to move the Store to another partition?
<lfam>guix-vits: It may be a little tricky. At least, you'll need to preserve hard links unless you are not using deduplication. I would search the mailing list archives to see if anyone has done it before
<lfam>It's a question where I wonder, why are you doing it?
<guix-vits>lfam: bear in mind that i have 50 GiB free, and all of that is rather to playing.
<guix-vits>i'm just read about `guix archive` now.
<lfam>Yeah, best to stick to the Guix tools
<brendyyn>I notice when I click the button to open a download or folder from Icecat, it pops up with an Open With dialoge that has now programs listed at all and i have to go find the binary manually. If I open up PCmanFM and right click open on something, it works perfectly fine though. any idea why icecat isnt working?
<guix-vits>brendyyn: if you ran IceCat from terminal did it shows any errors?
<brendyyn>I will need to wait 3 hours for this download to finish first
<guix-vits>brendyyn: do IceCat supports some download managers (i'm about continue download as in `wget`)?
***net-safe__ is now known as Veera
<Veera>Hi guix
<Veera>is epdfview okay for inclusion in guix
<guix-vits>Hi Veera the "not-safe__".
<Veera>Hi guix-vits
<Veera>epdfview is not safe for inclusion
<guix-vits>Veera: idk, but
<Blackbeard>Veera: why do you want epdfview
<guix-vits>Veera: and the GitHub page: "Latest commit f1b4b26 on May 16, 2017" (one branch)
<Veera>Well the packages should be: stable, working and maintained? And not a clone of another pkg? Is it right.
<Veera>idk = i don't know?
<guix-vits>Veera: yes and
<brendyyn>i think if it works its reasonable
<g_bor[m]>Hello, Veera
<g_bor[m]>Are you around?
<g_bor[m]>I have just seen your mail. Sorry about the confusion.
<Veera>g_bor: Yes
<g_bor[m]>We will make sure that your efforts in this regards are appreciated. I do not have access to the timeline rigjt now, what is the contribution deadline?
<Veera>April 7
<g_bor[m]>Ok, we still have lots of time. Do you have any contribution recorded already? Also did you share your work on xchat?
<Veera>No contribution recorded yet
<Veera>xchat was to be the first one
<Veera>No sharing of xchat code yet
<g_bor[m]>I believe sharing the code would be a good idea, maybe by sending a patch request, tagging it won't fix and sending an email to it with the summary of objections and closing it. I believe that way we can also make it a contribution by providing a link to the issue.
<g_bor[m]>Anyways, what you did is already a meaningful contribution. Discussing this, updating the list, and if there will be and issue recording the objections of the community, that might be even more than having the package :)
<Veera>okay currently i hacked it build quickly mean used LIB variable for ./configure
<Veera>should I do it properly then send the patch. I don't know the procedure
<g_bor[m]>You can send the patch as is, and we can give you feedback. It is easier that way.
<g_bor[m]>I believe that the contribution section on the manual gives the instructions on how to do that.
<g_bor[m]>Once this is done, you will get an email from the tracker with the issue number.
<Veera>I will send the xchat.scm + glib-fix.patch + glib-module-fix-not-working.patch
<Veera>Also the xchat.scm is local package
<g_bor[m]>Further mails should go there.
<Veera>Was not able to properly use (define-module (gnu package xchat)...
<g_bor[m]>You can close the issue by sending a mail to issuenumber-done@
<Veera>okay I read that in manual
<g_bor[m]>What was the problem?
<Veera>guix build was complaining no such gnu package
<Veera>though i put it in guix.git/gnu/packages directory
<g_bor[m]>Did you wrap your package definition into a define-public form?
<Veera>(define-public xchat
<Veera>someone told me to paste the file
<Veera>Shall I do it now
<Veera>Or shall I send it as a patch
<g_bor[m]>It would be nice.
<Veera>As patch?
<g_bor[m]>Sending it as a patch would allow us to have a permalink, and ensure that noone else would get into this again.
<g_bor[m]>Sending it to the pastebin would allow me to have a look at it now.
<g_bor[m]>Feel free to do both
<brendyyn>Veera: I suggested using just for the sake of showing us what you were doing in real time chat .We use in IRC for text that is too big to paste into the channel. for the mailing list you would include everything in the email
<Veera>Yeah I know that
***wxie1 is now known as wxie
<g_bor[m]>Veera : thanks for your work so far. Today we have a family day, and I will have to go now to get the preparations done. Feel free to contact me, but it might well happen that I will only be able tomorrow.
<Veera>Ok. Thanks for help.
<bricewge>Hello Guix!
<bricewge>What is the default kernel version? Or how can I find out about it myself?
<Veera>uname -r
<bricewge>Veera: That's my kernel not the current default one.
<Veera>uname -r shows the version of running kernel
<Veera>Are you in Guix OS
<bricewge> should be fixed with Linux 5.4 but I don't know if it's the default kernel yet.
<Veera>well I have the latest pull and my kernel is 5.4.26
<bricewge>Veera: Do you use a custom kernel?
<brendyyn>bricewge: In gnu/system.scm, there is the definition of the operating-system record type, and it shows the default kernel field is linux-libre. so it should be the highest version that guix package --show=linux-libre provides, which is 5.4.25 for me
<Veera>No from official ci server
<bricewge>brendyyn: Thanks that make sense.
<brendyyn>bricewge: actually its right but technically wrong what i said. the operating-system reference identifiest it by the 'linux-libre
<Veera>Last time I did guix system reconfigure was 3 days ago
<bricewge>Veera: Thank you I'll assume we are on 5.4 by default then.
<brendyyn>' scheme symbol
<brendyyn>and you can see (define-public linux-libre linux-libre-5.4)
<brendyyn>in gnu/packages/linux.scm
<bricewge>brendyyn: That was exactly what I was looking for! I've searched in that file though...
***eir0 is now known as eiro
<raghavgururajan>apteryx Yeah :-) I hope that it will also helpful to civodul. He was looking for good VoIP solutions lately.
<brendyyn>I'm a little stumped by lexical scoping. I have a long let form in a phase that sets a var. how can I make that var available in a later phase. one way is to use setenv and getenv to pass it outside guile, but that seems like a bit of a joke.
<janneke>brendyyn: indeed, that's exactly the feature of lexical scoping
<janneke>a variable is only available inside its scope
<janneke>if you want it available in two places, you must define it in a larger scope that encompasses both places
<brendyyn>but how is that possible inside of (modify-phases ...)?
<brendyyn>its just a macro that lets you specify each phase separately
<janneke>yes, so it depends on the initialisation of the variable whether you can add an encompassing `let' or not
<brendyyn>im just trying to make a package with python3 into one that also works with python2 so it has to detect it. ive got it to work, but only by copy pasting the same let block
<rekado_>brendyyn: can you show us an example?
<pinoaffe1>i'm trying to run the guix indent script, but I'm getting an error bash: ./etc/ @EMACS@: bad interpreter: No such file or directory even though emacs is available in the environment I'm running it in - anyone know what's going on?
<cbaines>The .in file is a template, do you have ./etc/indent-code.el ?
<cbaines>If not, you probably need to run ./configure and make
<raghavgururajan>Folks! Which package provides "LibXsd". I tried several related packages.
<mbakke>raghavgururajan: maybe libxml or libxslt?
<raghavgururajan>mbakke I tried both. Didn't work.
<raghavgururajan>`Could NOT find LibXsd (missing: LIBXSD_INCLUDE_DIRS)`
<midnight>"CodeSynthesis XSD is an open-source, cross-platform W3C XML Schema to C++ data binding compiler." ?
<raghavgururajan>I believe it's not in guix.
<brendyyn>rekado_: i was trying to deduplicate these to let forms. it only needs the python version after all
<pinoaffe1>cbaines: oh, oops
<brendyyn>rekado_: also i was wondering if you knew why this (cons (car cl) .. ) is there. is it correct? when i removed it my program worked. it looks like it was passing a scripts name to its self
<help-please>hello, can somebody please help me with this issue? I'm not the OP but it's the same for me
<alextee[m]>should static libraries that don't plan to maintain API compatibility with previous versions still be packaged?
<help-please>my linux distro is solus
<rekado_>brendyyn: what you can do is define a procedure that takes inputs and outputs and returns the python version
<alextee[m]>i think in the worst case it would lead to mylibrary@0.10.1, mylibrary@0.12.3, etc
<alextee[m]>one example is zlfo and ztoolkit, and i think another would be geonkick and geonkit. i am wondering if it's a better idea to pre-fetch the static libraries as sources to the binaries (geonkick, zlfo) and not have the static libs available in guix
<janneke>wip-hurd now fails with: guix/inferior.scm:524:7: LLVM target for system is unknown "i586-gnu"
<mbakke>help-please: make sure that your user has 'glibc-locales' installed, and that $GUIX_LOCPATH is set up in your shell configuration
<mbakke>janneke: see system->llvm-target in llvm.scm
<janneke>yes, i found that...but how to reproduce/fix?
<help-please>mbakke: $GUIX_LOCPATH is set, I have the appropriate directory in .guix-profile/lib/locale/2.29. I installed glibc-locales and glibc-utf8-locales using guix, should I do it some other way?
*janneke is looking for `building XXXX' stanzas, but they seem to be missing in the logs?
<janneke>what would use llvm...hmm
<rekado_>brendyyn: about your second question: execl takes two (or more) arguments: filename (a string) and arg (multiple arguments).
<help-please>btw, something's wrong with this irc client, I'm seeing all messages twice.. if I send double messages let me know, I'll reload it or something
<rekado_>brendyyn: the original argument vector includes the program name at position 0.
<rekado_>brendyyn: take a look at the documentation for execl in the Guile manual.
<mbakke>janneke: I guess the LLVM target would be X86 for i586-pc-gnu
<mbakke>janneke: 'mesa' uses LLVM, at least
<mbakke>help-please: the guix-daemon service also uses GUIX_LOCPATH, check that the configuration in `/etc/systemd/system/guix-daemon.service` looks correct
<mbakke>probably you need to install `glibc-utf8-locales` for the root user too, or make the service refer to your user profile
<help-please>Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8
<mbakke>help-please: and does that directory exist?
<help-please>mbakke: oh, it doesn't. in .../per-user/root/ I only have current-guix and current-guix-1-link
<mbakke>help-please: by the way, glibc-utf8-locales is a subset of glibc-locales, you don't need to install both
<mbakke>help-please: in that case, running 'guix pull && guix install glibc-utf8-locales' as root should fix it
<mbakke>or you can edit the service so that it refers to your user instead of root
<help-please>mbakke: ah I see, I saw some old mailing list convo saying it's different. I'll uninstall it then
<help-please>mbakke: can I just edit the .service text file?
<mbakke>help-please: yes
<mbakke>afterwards you need to `systemctl daemon-reload && systemctl restart guix-daemon`
<help-please>mbakke: neat, I'll do that
<mbakke>help-please: good luck! :)
<janneke>mbakke: hmm, `llvm' and `mesa' build fine -- it must be something else
<brendyyn>i see well then i dont know how to fix it.
<rekado_>brendyyn: fix what?
<janneke>i'd be happy to try some of those (X86 esp.) but it feels so silly to try/debug such a thing, round-tripping through savannah an cuirass
<rekado_>brendyyn: can you show use the actual error you get?
<brendyyn>give me a sec
<mbakke>janneke: apparently the only consumer of system->llvm-target lives in julia.scm
<brendyyn>I have a cli tool that works fine with wrap-program, but with wrap-script it just shows the help page as if the cli args were wrong
*janneke needs to invest in a better "Perfect Setup"
<help-please>the service runs as root though, I didn't feel like meddling with that, lol. I installed glibc-utf8-locales on root and it helped! thank you so much mbakke
<mbakke>help-please: glad you figured it out! there are discussions ongoing on how to improve the GUIX_LOCPATH situation, I hope we can fix it for the upcoming Guix 1.1 :-)
<help-please>I also spent a lot of time trying to resolve a missing openpgp key.. turns out you have to run pgp as root. you could include that in your install script :)
<brendyyn>applying civodul's suggestion results in it printing out the help instead of that error
<efraim>sneek: later ask lfam what CLI command are you using for AV1 conversion with ffmpeg?
<sneek>Will do.
<efraim>sneek: botsnack
<DamienCassou>hi everyone
<DamienCassou>it seems the very latest commit from git can't be built:
<cbaines>DamienCassou, if you can figure out what .go files to delete, you should be able to get past that error
<cbaines>or you can run make clean-go to get rid of all of them
<DamienCassou>thank you
<sirgazil>I left my computer on overnight with a sway session opened. This morning, .gnome-shell-real was using 2.5 GiB. After a reboot, I started another sway session, and now I'm watching the leak live.
<sirgazil>Fun times.
<str1ngs>sirgazil: can confirm gdm has a memory leak. not sure why as of yet myself :(
<sirgazil>So, the issue is not related to GNOME only, but I was able to fallback to sway for some time... Until yesterday.
<sirgazil>str1ngs: Ah, good to hear, in a way :) Now it's three people with the problem.
<str1ngs>that's good to know. I though maybe this was an isolated case for myself. since I'm working on a GTK project which I thought might be the culprit
<str1ngs>sirgazil: this has been going on for sometime. I just assumed if it was a gdm issue other's would have noticed it somehow.
<str1ngs>maybe most people don't use long enough sessions to notice this?
<sirgazil>str1ngs: Yes, for months, in my experience. But only reported it recently, when the leak got worst enough to eat all my RAM in a few hours.
<str1ngs>for me the leak seems small but accumulates over days
<str1ngs>my workstation usually has long uptimes
<sirgazil>It was like that for me too, but now the problem got worst after recent pulls.
<sirgazil>I was using sway without apparent RAM problems, but yesterday I modify my system config (added some packages) and now .gnome-shell-real RAM usage increases ~6 MiB per minute.
<guix-vits>sirgazil: Gnomes. Gnomes never change :)
<str1ngs>guix-vits: I wonder if this leak contributed to your OOM issue yesterday?
<guix-vits>str1ngs: i'm not aware about any Gnome things in my system; how can i know for sure?
<guix-vits>i'm login from console, also.
<civodul>sirgazil: when you switched to sway, was it also gnome-shell eating all the memory?
<guix-vits>but their thechnologies for sure should be used by packages, though
<str1ngs>guix-vits: htop then sort by memory with m. .gnome-shell-real should be the culprit with user gdm
<sirgazil>civodul: When I switch, I didn't see any RAM issues, except for one time when .gnome-shell-real usage was around ~800 MiB.
<str1ngs>guix-vits: htop -u gdm is a better filter
<sirgazil>civodul: But yesterday, with the system config modification I did, I experience the leak, similar to the leak I see when using GNOME.
<jonsger>civodul: will there be a Guile 3.0.2 before guix 1.1.0?
<str1ngs>sirgazil: I'm curious why .gnome-sheel-real is being used at all. personally I use xfce
<sirgazil>civodul: But yeah, it is always .gnome-shell-real run by the gdm user.
<sirgazil>str1ngs: Maybe it is related to the login manager (GDM)?
<str1ngs>maybe this only effects none gnome users. that use gnome services?
<guix-vits>str1ngs: i'm tested with htop and `u`, but only me, root, and messagebus are there.
<str1ngs>sirgazil: the process tree show gnome-session-binary is the parent PID
<guix-vits>`ps -eaux |grep -i gdm|grep -v grep` shows nothing
<sirgazil>guix-vits: You don't use GDM login manager nor GNOME, right?
<guix-vits>sirgazil: yes.
<str1ngs>acutally looks like .ibus-daemon-real is the parent
<str1ngs>could be though if you gnome services this causes it.
*guix-vits have the %base-services and elogind
<guix-vits>sirgazil: i'm was unable to reproduce the OOM today.
<sirgazil>str1ngs: How do you get that information (parent of a PID). I don't know anything about that.
<kmicu>(Please keep in mind that the issue is with GNOME on Guix (System). For example we can have Emacs on X packaged by Y which will constatnly segfault. In such case blaming upstream before we know for sure that the issue is really with the upstream is not kind thing to do.)
<str1ngs>nope .gnome-session is the parent
<sirgazil>kmicu: for sure.
<str1ngs>sirgazil: pgrep gnome-session. then pstree PID
<raghavgururajan>Hello Guix!
<raghavgururajan>What build-system should I use for this source?
<raghavgururajan>I tried gnu-build-system, but getting "./configure: No such file or directory" error.
<str1ngs>seems this is more gnome services related
<str1ngs>is anyone using GNOME proper can confirm this leaks for them as well?
<raghavgururajan>I also tried with autoconf and automake as native-inputs. Still didn't work.
<mbakke>raghavgururajan: is there no README or INSTALL file that says how to build the thing?
<raghavgururajan>mbakke There is. It's mentioned `make`. But it is part of gnu-build-system right?
<mbakke>raghavgururajan: yes, make is called in the 'build' phase. Maybe you just need to delete the configure phase?
<sirgazil>str1ngs: By the way, this is the bug report
<raghavgururajan>mbakke Ah, it makes sense to delete configure phase. Because there is no 'configure' file in the root of the source.
<str1ngs>sirgazil: thanks
<raghavgururajan>mbakke: So Is the syntax `#configure? #f` correct?
<str1ngs>I curious why gnome-shell is running at all for people that use don't use GNOME proper
<str1ngs>unless maybe gdm uses a gnome-session to present the login maybe
<guix-vits>str1ngs: aren't gdm is an actual Gnome-mini-session?
<ngz>raghavgururajan: look for (delete 'configure) in the code base.
<raghavgururajan>ngx Gotcha! Thanks.
<str1ngs>guix-vits: I guess that makes sense
<civodul>sirgazil: i see
<civodul>jonsger: re 3.0.2, i don't know!
<civodul>it's tempting, but it's not a strict requirement for Guix 1.0.1
<civodul>i'm trying to prioritize and stay focused, but it's hard
<jonsger>oke. its no problem. i'll go for patched guile then :)
<civodul>yeah you can at least include the patch we have in Guix
<civodul>but yeah... 3.0.2 ought to be released soon
<raghavgururajan>So during install phase, I get "could not write to ?/usr: permission-denied".
<nckx>Good morning, friends.
<nckx>raghavgururajan: Try setting prefix= (GNU-style) or PREFIX= (BSD-style) #:make-flags. Look at the Makefile to find out which is used.
<guix-vits>Hi nckx, Hi all.
<raghavgururajan>nckx Thanks!
<nckx>raghavgururajan: Hm, what a strange makefile.
<nckx>raghavgururajan: INSTALL (always a good thing to read before starting, unless it's the GNU autotools boiler-plate) says: ‘make install_prefix=/usr install’
<nckx>So you'll be writing something like #:make-flags (list (string-append "install_prefix=" (assoc-ref %outputs "out")))
<nckx>o/ guix-vits.
<raghavgururajan>nckx That is perfect. Thanks so much.
<nckx>(guix-vits: as previously warned, I didn't check my MSGs until now 🙂)
<apteryx>mbakke: I'm preparing to push patches to emacs, and emacs-elpy to master
<mbakke>apteryx: great
<sirgazil>apteryx: nice 👍
*mbakke still can not figure out why 'ghc-cabal' from ghc 8.4 lacks an absolute reference to libgmp and libffi on the core-updates branch
<mbakke>i'd force -Wl,-rpath=$libgmp/lib if only I found where to add it :P
<jonsger>is it intended that adding (elogind-service) locks you out from your system? you can't login in anymore (ssh, direct login), not the normal user, not root
<guix-vits>jonsger: how the way? did you'd changed a number of users?
<bricewge>Now that we have `kernel-loadable-modules', how does one load a module at sartup (without using `initrd-modules')?
<guix-vits>jonsger: do you use %basic- or %desktop- services? (i'm not a developer, but use the elogind now)
<jonsger>guix-vits: %base because I'm on a server and elogind is required by docker
<guix-vits>jonsger: and have you recently added or deleted any users?
<guix-vits>jonsger: what error is?
<guix-vits>or it's not print anything?
<mbakke>jonsger: you'll likely need (dbus-service) as well
<jonsger>mbakke: I have (dbus-service)
<mbakke>jonsger: did you reboot after adding elogind-service?
<jonsger>mbakke: thx. That's the trick :)
<mbakke>jonsger: restarting dbus might also have worked
<jonsger>yeah. But thats not gonna work when you can't access your system anymore :P
<mbakke>good point :P
<mbakke>phew, reading GHC build scripts are sooo boring...
*mbakke goes to watch TV instead
<vagrantc>mesa seems to have almost two-thousand dependencies ... got changes specific to aarch64/armhf to enable drivers on rockchip platforms ... though i haven't even tested it yet ... guess that would go to core-updates?
<vagrantc>i *think* it would only trigger rebuilds on aarch64/armhf
<Veera>hi guix
<mbakke>I wonder if we actually need GHC 8.4, or whether we could jump straight to GHC 8.6 as there are some changes there that could be related
<Veera>if I have to run ./ before ./configure how to do
<mbakke>vagrantc: mesa has traditionally been updated on 'staging' despite the massive number of dependents (where did they come from anyway? it used to be like 500!)
<vagrantc>is it a very long build?
<mbakke>I suppose we should update the documentation to reflect that, because I don't want to make Mesa a 'core-updates' package :/
<mbakke>vagrantc: not really
<vagrantc>i guess it's all relative :)
<mbakke>Veera: you can add a new phase like (add-before 'configure 'autogen (lambda _ (invoke "./")))
<Veera>mbakke: I try
*mbakke goes AFK for a bit
<nckx>Veera: What are you packaging now?
<nckx>Sorry to hear about your XChat misadventure.
<Veera>nckx: same xchat
<Veera>gabor told to send patch of xchat
<nckx>Veera: From SVN? Why do you need to run ./ It won't be as simple as just (invoke "./"), it will need patching.
<Veera>from pkg tarball
<nckx>The tarball has ./configure though.
<Veera>running ./ works well out of guix
<nckx>I took a look at it and it does stuff like <>.
<nckx>What's wrong with the upstream ./configure script?
<nckx>Maybe we're looking at different tarballs. This is
*nckx → food times.
*guix-vits PS1='\n\[\033[32;1;4m\]\u\[\e[0m\]@\h\n \A\n \w\n$ ' -- bash prompt
<Veera>(arguments `(#:phases (modify-phases #standard-phases (add-before 'configure (lambda _ (invoke "./")))) #:configure-flags ...
<Veera>is not working
<guix-vits>Veera: try %standard-phases instead of #
<guix-vits>see gnu/packages/irc.scm
<Veera>got it fixed i have to add `autogen too
<nckx>Veera: Use ', not `
<Veera>nckx: okay
<Veera>nckx: yes is failing with gettext
<Veera>since xchat is not going to be included I just patch configure and get going
<janneke>mbakke: finally building julia locally...
<janneke>still haven't reproduced the llvm-target error
<nckx>Veera: Maybe someone told you a different opinion, but patching and using ./configure (not ./ is the approach I would take even if this package were included. I don't see the advantage to patching Plus it adds quite a few build-time dependencies.
<Veera>Oh GNU and other distros say so
<Veera>but when there is no option or as quick hack we can do
<nckx>I'm not aware of any such rule in GNU. We use pre-generated ./configure scripts whenever available.
<Veera>In the end we want it working and useful
<Veera>I did not said about pregenerated one
<Veera>I said patching configure is not recommended
<Veera>by gnu
<Veera>it says instead change precursors
<str1ngs>does guix not have an autconfig phase?
<lfam>What's an autoconfig phase?
<sneek>lfam, you have 1 message!
<sneek>lfam, efraim says: what CLI command are you using for AV1 conversion with ffmpeg?
<lfam>sneek: later tell efraim: Something like this: `ffmpeg -pattern_type glob -i "render/*.png" -c:v librav1e output-av1.mp4`
<str1ngs>lfam: where as autreconf is called
<lfam>sneek: later tell efraim: Of course you need rav1e from the wip-rav1e branch for that. I need to finish that work but struggling to find the focus
<sneek>Will do.
<nckx>str1ngs: We do.
<str1ngs>maybe its smart and only calls if configure does not exist?
<str1ngs>ie git sources
<nckx>Yep. I think it's called 'bootstrap. It also needs auto{conf,make} to be an input.
<jonsger>lfam: you're saving images as videos?
<str1ngs>nckx: ah that's right I forgot you need to had autoconf as a native-input for this
<lfam>jonsger: Most video rendering uses an intermediate step of still images for easy editing
<lfam>jonsger: That way you can change part of the movie without re-rendering the entire thing
<lfam>So you render as stills and then create the compressed video afterwards. Especially since compression can be super expensive
<str1ngs>nckx: thou I thing autoconf is implied when you use git sources
<Blackbeard>Hello ٩(◕‿◕。)۶
<lfam>And you may compress the video in different ways for different audiences. It's orthogonal to editing and rendering
<DamienCassou>I creating my first service. What do you use to test services? A combination of ./pre-inst-env and `guix system reconfigure`?
<lfam>DamienCassou: It may be more efficient to use `guix system vm-image` or `guix system vm`, depends on what you're doing
<lfam>Reconfiguring may also be best, just depends
<DamienCassou>makes sense
<nckx>str1ngs: It doesn't care how you got the sources (tarball vs. git vs. other VCS) if that's what you mean.
<nckx>Nothing is implied.
<nckx>(if (not (file-exists? "configure")) ; otherwise nothing
<nckx>(I've seen git repos with configure scripts in 'em but it shouldn't happen, of course.)
<str1ngs>nckx: four packages that use gnu-build-system and git sources its implied you need to autoreconf
<nckx>s/gnu-build-system/autotools/ but sure.
<str1ngs>i've never had to explicitly autoreconf when it's been required
<jonsger>lfam: ah. Thx for the explanations
<nckx>o/ Blackbeard.
<Blackbeard>nckx: hi :)
<Blackbeard>I'll work all day on guix from now on :)
<nckx>Blackbeard: on Guix or on Guix (or both)?
<Blackbeard>Guix and Shepherd
<nckx>Neato. Did it all go smoothly?
<Blackbeard>nckx: with my school? Yes
<nckx>I meant Guix because my priorities are all fucked, but very glad to hear that real life is treating you well 🙂
<Blackbeard>Oh no, I thought you asked because the other day I mentioned I had work my thesis and everything and today I'll be free
<Blackbeard>nckx: to be honest I am happy to work with Guix because it is an scape of real life
<nckx>☝ this.
<Blackbeard>But it seems like my city only has 4 cases and we are already on lockdown so here it won't be as bad I hope
<NieDzejkob>I read that as "caves" instead of "cases". Got quite confused for a moment :D
<NieDzejkob>On another note, I'm updating my system in the background and let me tell you, you can *feel* it when a big graft is being made
<lfam>That reminds me that it would be great to have an implementation of Rabin-Karp string searching in (guix build utils). We use it for grafting but there are other places we could use it
<lfam>When writing GNU changelog, I know that it's canonical to put variable names in ALL CAPS. But what about arguments / parameters of a procedure? Should they be all caps too?
<lfam>I'm working through the patches in <> and the commit messages need some work, so I'm trying to do it right
<sirgazil>Is there an easy way to use all %desktop-services sans, say, gdm-service-type?
<str1ngs>sirgazil: if you use %desktop-services for service field yes
*sirgazil tries (delete (service gdm-service-type) %desktop-services) would work.
<str1ngs>sirgazil: you probably want to modify-services
<sirgazil>str1ngs: Oh, I'll check that out...
<str1ngs>but, I think if you use slim now it disables gdm?
<str1ngs>sirgazil: which login manager do you want to use?
<sirgazil>str1ngs: I'm currently logging in from a TTY and start sway. So I just want to remove the gnome service and the gdm service.
<mbakke>sirgazil: there is an example in the manual about removing gdm-service-type
*sirgazil looks...
<str1ngs>sirgazil: for the slim service it shows how to remove gdm see
<str1ngs>sirgazil: essentially you are just using remove and it returns %desktop-services without gdm-service-type
<str1ngs>sirgazil: so my modify-services is was bad advice. apologies.
<sirgazil>str1ngs: No worries, I found the example.
<sirgazil>mbakke: Thanks.
<str1ngs>sirgazil: I'm assuming this is to resolve the gdm leak?
<sirgazil>But I wonder if there is anything wrong with "(delete (service gdm-service-type) %desktop-services)". My config evaluates without errors if I use it.
<sirgazil>str1ngs: Yes, I need a working computer. I currently have to reboot every 4 hours or so.
<str1ngs>if (service gdm-service-type) equals gdm-service-type then I guess that would work
<str1ngs>I would think it would be. (delete gdm-service-type %desktop-services) based on delete docs
<sirgazil>I copy/pasted (service gdm-service-type) from the definition of %desktop-services.
<str1ngs>sirgazil: I'm rebooting every 7 days haha. all jokes aside it's kinda a serious issue :)
<str1ngs>in that case (service gdm-service-type) should work . you can always evaluate that see if it's right.
<sirgazil>Yes, I'm using geiser.
<sirgazil>bricewge: Thanks for the link. I guess it would be good to add the implementation of the "remove-services" procedure to the issue tracker :)
<lfam>It's a good thing for the cookbook sirgazil
<sirgazil>lfam: Removing services?
<lfam>Yes, an example of how to do it
<lfam>Removing and replacing
<bricewge>sirgazil: I have modified a bit remove-package to cleanup one shot services
<sirgazil>bricewge: Add it to Guix please, I want that :)
<divansantana>Offtopic: Anyone know of software to transcribe video voices to text? Would be cool as part of research to document points from videos.
<bricewge>sirgazil: I'll see what I can do ;)
<bricewge>lfam: About #36380, what did you tired? Do you have a setup to reproduce the issue?
<lfam>bricewge: I don't remember exactly how I set it up, but you can start QEMU in a way that the guest's /dev/hwrng is fed by something that doesn't allow fast reads
<bricewge>I read trough the IRC log where you asked then about their setup, it's en empty place over there...
<lfam>You could exhaust /dev/random and use that
<lfam>Yes, but they were having discussions too. They definitely ignored me
<lfam>We are the ones doing something weird, but they are the ones doing something broken :)
<sirgazil>divansantana: I don't know, but I want that too, for my local corpora.
<lfam>Probably they are using /dev/random, or maybe just have a totally broken host setup. Who knows
<lfam>bricewge: I have this in my shell history. It won't help you get a slow /dev/hwrng but it will give you some tips on setting up the virtio RNG stuff:
<lfam>qemu-system-x86_64 -object rng-random,filename=/dev/urandom,id=guixsd-vm-rng -device virtio-rng-pci,rng=guixsd-vm-rng -m 3072 -net user -net nic,model=virtio -boot menu=on -drive file=/home/lfam/tmp/qemu-image
<bricewge>Thanks, I have seen those option in the blog post linked in the report.
<lfam>The read should be instantaneous so a 1 second timeout is sufficient
<bricewge>For the little I understand `expect' should be able to provide a way to timeout.
<lfam>I have no idea, unfortunately. I barely get by
<bricewge>I'll at least try to have a way to reproduce it.
<lfam>I think if you hook it up to /dev/random and do `head -n1024 /dev/random` it will occur
<lfam>This is one of the original sins of Linux
<nckx>Thou shalt never use /dev/random.
<lfam>BuT iTs NoT rAnDoM eNoUgH
<lfam>We have a number of years-old bug reports like "non-deterministic build failures of foo on armhf" or i686 or other weird architecture
<lfam>Without a decent CI it's difficult to say if they are building reliably now
<lfam>For example:
<lfam>It was a lot easier to deal with this stuff on Hydra
<midnight>Does --bootstrap --no-substitutes still work for 1.0.1 install for "guix pull" ?
<lfam>midnight: Are you asking because you think it's broken?
<midnight>lfam: I have two different machines where I've attempted to install version 1.0.1 and they both, eventually, choke. :( I used the guix install script on one, built from source on the other, and then just the guix install (with prebuilt bins) on the other, and "guix pull" eventually dies for both with "you found a bug please report it by email".
<lfam>It sounds like you have 3 machines... but anyways. If it doesn't work that's a bug
<midnight>lfam: e.g.:
<midnight>I thought perhaps I'd just munged something up with a manual install on one machine, so attempted to manually delete guix on it, and reverted to plain binary install thinking my build environment was weird or something.
<lfam>midnight: I'm not totally sure, but it appears to fail while trying to clone a git repo. Do you have guile-git?
<midnight>I thought I did. :-)
*midnight looks
<midnight>It's been running about 24 hours.
<lfam>What kind of computer is it?
<midnight>It's an Intel mumble-mumble running Ubuntu 16.04.x LTS with lots of ram and multi-TB of drive space. It's water-cooled but the CPU doesn't seem to complain.
<midnight>Oh interesting: [23344197.988098] git[26057]: segfault at 7ffffffdefe8 ip 00007ffff7e32960 sp 00007ffffffdefc0 error 6 in[7ffff7dd5000+13f000]
<lfam>So you're saying it's a fast computer?
<lfam>Not like a 10 year old laptop
<midnight>Oh; yeah, a rackmount monstrosity.
<lfam>I would limit the number of cores in use if it's a lot. I think we have been seeing some racy crashes in our build farm
<midnight>Oh interesting.. the other machine is segfaulting too. I should've looked in syslog. [23873996.086309] svn[28972]: segfault at 0 ip 00007ffff76c2ea6 sp 00007fffffffc008 error 4 in[7ffff7650000+141000]
<lfam>But, you should definitely report the bug
<lfam>I don't understand what --bootstrap does so I can't really give specific advice. civodul might but it's getting late for them
<midnight>100% build-from-scratch is what I thought it did, which is why I was so excited about guix.
<lfam>I can't imagine it should take 24 hours on a newish computer
<lfam>Bootstrapping Guile is a Huge task, but it doesn't even take 24 hours on my old laptop
<midnight>I might be mis-estimating. It might have been only about 9-12.
<midnight>CPU is: Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz
<midnight>So. Lower-end rackmount I guess.
<lfam>Okay but it's a real computer. A lot of people are using really old laptops for non-technical reasons
<lfam>I just wanted to make sure
<midnight>Oh yeah. Oh, for sure, I get it.
<str1ngs>midnight: what your kernel version uname -a
<str1ngs>midnight also do you have substitutes enabled?
<lfam>str1ngs: They are running with --no-substitutes
<civodul>midnight, lfam: --bootstrap is meant for Guix developers only
<civodul>for tests, specifically
<midnight>str1ngs: Linux linooks 4.4.0-151-generic #178-Ubuntu SMP Tue Jun 11 08:30:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
<midnight>civodul: Is there a lesser version where I build completely from scratch? It appears that guix will be the future basis of bitcoin deterministic builds; ideally in my view, I'd like to completely eliminate all binary dependencies.
<midnight>or.. perhaps just do like an initial build-from-scratch and then thereafter use my build artifacts.
<lfam>midnight: You should be able to build from the Git repo, run the guix-daemon from there, and then proceed
<lfam>Check the Contributing and Installation:Requirements sections of the manual for pointers on this
<midnight>lfam: so, in other words use master instead of 1.0.1. Okay I'll give it a shot. I have lots of time and I have absolutely no issue with these problems. Just interested in hopefully working around them. :)
<lfam>I don't know what the current "best practice" is for this but that will get you on the road
<midnight>Cool, I'll give it a shot.
<lfam>You can use 1.0.1 if you want. It's up to you
<midnight>Oh, no, I'm good with master.
<lfam>I mean, like all software... there is a binary seed. We are actively working to shrink it
<midnight>Or.. rather trying to use master. There, on one machine, restarting guix pull just completed.
<nckx>Getting rid of all binary dependencies is still a few years away.
<lfam>I think that bitcoin probably has bigger problems than a trusting trust attack.
<lfam>It's quote esoteric considering the real problems people have with cryptocurrency
<lfam>But we are working to solve it regardless :)
<midnight>It appears the notion of trusting trust issues is growing now that intel et al are utilizing SGX and installing IME type inaccessible subsystems. This is primarily my interest. Although I'm a strident bitcoin type my two Talos machines are more what I'm concerned about. Recently I learned there are trusting-trust behaviours currently active in e.g. go and rust. That really surprised me.
<lfam>I'm not saying it's impossible, just esoteric. There are probably about 1 trillion memory and logic bugs to be fixed before trusting trust becomes a preferred attack vector
<nckx>Remember that ‘building Guix from scratch/source’ is not going to make a noticeable difference since if already trusting gigabytes of Ubuntu binaries anyway. It's a cool party trick but don't sweat it.
<midnight>One of them has persisted right from its ocaml origins!
<lfam>Nevertheless, our binary seed has already shrunk a lot and the goal is to eliminate, starting with some tiny bit of assembly
<nckx>s/since //
<lfam>The work has proceeded surprisingly quickly. They are in the #bootstrappable channel if you're interested
<nckx>If anyone's pulled off a Thompson attack it won't be in some obscure hippie distro.
<midnight>nckx: Yes, I know. The ultimate goal is diverse double-compilation and then from-scratch bootstrap build, likely running on my power9 systems.
<midnight>bootstrappable. Okay. Cool.
<nckx>Yeah, from scratch is the goal.
<lfam>Have you ever heard Bunnie Huang's talk "Impedance Matching Expectations Between RISC-V and the Open Hardware Community"?
<lfam>It's relevant and super-interesting
<lfam>From somebody who actually designs and ships hardware with this stuff on their mind
<lfam>The talk:
<lfam>And the slides:
<midnight>lfam: I'm super interested in that. I'll watch it.
<nckx>midnight: This is the goal: No mucking about with hacks like DDC, no trusting last week's kernel, just building source with more source (and a tiny human-grokkable binary seed).
<nckx>Hm, that page still calls it GuixSD. So that's where they all come from.
<lfam>nckx: The source code is in our repo apparently:
<midnight>lfam: I wrote Bunnie recently, as he wrote an obscure blog post about risc-v open-sourced-ness being not quite there, and it appears the logic he's talking about is still closed. Most of the risc-v people think that refers to the preboot e.g. DIMM config but not at all. Really weirdly, IBM has no issues releasing chip information right down to the rings data.
<nckx>lfam: Huh. OK. I'll add that to my de-SD patch.
<midnight>nckx: arghh that's excellent.
<sirgazil>So, using the example for removing GDM didn't work. When I evaluate the operating-system definition, gdm is still there.
<sirgazil>My services look like this:
<midnight>nckx: There's a really neat guy who was originally doing a risc-v CPU "from scratch" using blocks of gate logic, but I think he relented and went to an array a chunk of the way through. Can't find his videos now.
<nckx>sirgazil: Could you paste your complete configuration?
<nckx>midnight: He's been vanished by the powers that be!
<bricewge>sirgazil: It's because of `set-xorg-configuration' it default to `gdm-service-type' if you don't specify the `login-service-type'.
<nckx>‘I suggest you come with us. It would be a shame to... execute you out of order.’
<sirgazil>nckx: My config:
<bricewge>nckx: Good one! :D
<nckx>sirgazil: The page I am looking for does not exist.
<midnight>nckx: I found him:
<bricewge>sirgazil: “The page you are looking for does not exist.”
<nckx>midnight: Ta.
<sirgazil>nckx: bricewge:
<nckx>sirgazil: Did you import (srfi srfi-1)? That's a frequent cause of this symptom. Although bricewge might be right too, I don't use s-x-c.
<nckx>Ah, never mind I see.
<sirgazil>nckx: remove is from SRFI-1
<nckx>But there's another one that people sometimes mistakenly use.
<nckx>I forget why or whence.
<bricewge>sirgazil: Which login manager are you planning to use, in place of GDM?
<sirgazil>bricewge: I've been logging in from TTY, I want to use just that.
<bricewge>sirgazil: Then for sure remove set-xorg-configuration.
<bricewge>If you need to configure Xorg then try xorg-start-command (I have never used it tough).
<sirgazil>Hmm, but then my keyboard layout wouldn't work?
<sirgazil>This system config is for using sway with everything GNOME removed to avoid the memory leak. But I have another option: Using another desktop environment with a login manager different than GDM.
<bricewge>Yeah that's why I suggested you to try xorg-start-command, it should set your keyboard correclty without the pesky gdm service.
<sirgazil>bricewge: Ok, thanks. I'll try that.