IRC channel logs


back to list of logs

***Server sets mode: +cnt
<vits95>I'm think that: S--ch (chance)--э (elephant)--m (e omitted). Why it isn't written as skheme?
<vits95>I'm mean, cat is (kat), not (se ei t) Why sch?
<milesrout>because greek
<vits95>his name, by chance isn't Gladiolus?
<vits95>OK, now i see: SCHeme and SHame. They really differ more.
<vits95>By two letters, as minimum.
<vits95>Skimming is good as well, then!
<vits95>* sets flooding on skimmer *
<oriansj>make sure not to miss: and (you may also enjoy
***apteryx_ is now known as apteryx
<drakonis>huh i thought that got skipped
<drakonis>wingo's talk was skipped in the listing
<oriansj>drakonis: I am only listing what is on the website; I have no idea what local changes are being made
<kmicu>Guix Days? What about Guix Nights? 🤫
<drakonis>oriansj: no changes made
<drakonis>i merely thought you skipped over a talk
<oriansj>no worries;
<bricewge>Next « GNU Guix as an alternative to the Yocto Project »
<mbakke>happy to see the stateful service discussion
<mbakke>sounds like it could be useful for backups too, e.g. "herd save-state mysql" and "herd load-state mysql"
<oriansj>some concern that isn't streaming anything
<bricewge>oriansj: Use the m3u8 link it works there
<oriansj>I just getting the No signal slide and no audio
<oriansj>as a 25second clip
<oriansj>looks like a client side caching issue
<efraim>First talk went pretty well, lots of good feedback and discussion afterward about rust packaging. From distros and from gnome mostly.
<NieDzejkob>hmm, on one hand I want to package some rust programs, but on the other hand, I feel like doing it while other rust patches are pending is pointless due to the potential for conflicts
<mbakke>I must admit that sipping coffee and streaming the talks from home is much more comfortable than running to the GRUB stand to borrow hot water for my Aeropress in between FOSDEM lectures.
<jlicht>does anybody use the emacs-ess in guix? I can't seem to load any of the .el{,c} files, even after rebooting :/
<pkill9>where is the link to stream fosdem
<mroh>jlicht: i use guix emacs a lot in a foreign distro... do you get any error msgs? have you tried with emacs -Q ?
<jlicht>mroh: I really mean the "ESS" emacs package; it seems to build okay, but none of the resulting el and elc files are put in my emacs' load-path.
<jlicht>so I get messages such as "cannot open load file: no such file or directory, <anything-ess>"
<vits95>exit 0
***jomat23[m] is now known as jomat23[m]1
***jomat23[m]1 is now known as jomat23[m]2
***jomat23[m]2 is now known as joma4
***joma4 is now known as joma6
***joma6 is now known as jomat23[m]
<coldpress>is that the command to quit kiwiirc?
<oriansj>why doesn't have info files?
<NieDzejkob>oriansj: they're in the git repo
<oriansj>NieDzejkob: find . -iname '*.info' says no
<NieDzejkob>ah, sorry, confused info with texinfo
<oriansj>NieDzejkob: find . -iname '*texinfo*' also says no
<oriansj>there we go
<shtwzrd>I'm trying to build a uboot package but it keeps dying early, with a fail on include <asm/string.h> but I'm having trouble understanding why
<shtwzrd>it feels like my build environment is missing linux headers or something? But I'm pretty clueless, it doesn't seem like I needed to include anything like that before. And I have all the inputs that other similiar uboot packages have.
<shtwzrd>It's either an issue with the repo I'm using for uboot (unlikely, it's branched directly from official and laid out identically it seems) or it's a mismatch in behavior between git-fetch (what I'm doing) and url-fetch
<shtwzrd>In my build, the source goes in a "source" dir, and in the normal build it's in 'uboot-2020.01', and I can see that in the normal build, there's a lot of output where (I think) it's copying files. Maybe the dirname is important. Is there any 'smart' way to change the dirname git-fetch uses or am I just supposed to `mv` it in a snippet?
<bricewge>shtwzrd: Still trying to build the u-boot package for the pinebook pro?
<shtwzrd>yea :) It's taking me a while because I'm a scrub but at least it's a learning experience :)
<bricewge>shtwzrd: I think I manage to build it with the patch you linked to yesterday
<bricewge>There is probably a nicer way to modify the source field. I took inspiration form the u-boot-rockpro64-rk3399 package.
<bricewge>u-boot-pinebook-pro.patch is
<shtwzrd>nice :) I may try it with that. At the moment I'm trying to build u-boot with this though:
<shtwzrd>It's the source being used in the AUR and i know it addresses the issue of the bootloader not bringing up all of the cores correctly
<shtwzrd>Though I haven't read the patch, maybe it includes that fix too
<bricewge>Then try using the git repo as your source.
<shtwzrd>bricewge: That's what I'm doing, but then it just completely fails to build because it can't resolve its includes anymore.
<shtwzrd>bricewge: that package definition is very cool, though. Mine is very stupid and ugly because I didn't realize I could apply a change to origin or patches directly on the deriving package, so I was re-defining things all way up to the level of the u-boot package itself.
<shtwzrd>also, yours actually works ;) So, perhaps I should just use your package definition, and if I really want that source's changes, I can just generate a .patch from their master and run with that.
<pkill9>is it possible to extract package requirements from CMakeLists/ files?
***daviid` is now known as daviid
<pkill9>i'm thinking about how it could be possible to create importers for these
<bricewge>shtwzrd: I'm having the same issue about the `#include <asm/string.h>`. Did you managed to build the AUR package before?
<valignatev>Hey guix! long time no see. I can't build 227aeeb64c825870433cfca1755b7d30005ae259, it segfaults on [ 56%] GUILEC gnu/packages/maths.go with the error "mmap(PROT_NONE) failed".
<valignatev>How do I debug it?
<shtwzrd>bricewge: no, I haven't built it before. I could hop onto an arch machine real quick tho and just verify that I'm not sending us on a wild goose chase
<bricewge>shtwzrd: There isn't a asm/string.h in linux-libre-headers that's probably why. « find $(guix build linux-libre-headers) -name 'string.h' »
<bricewge>Or it's cross-compilation issue and I don't yet understand how it works in Guix.
<shtwzrd>bricewge: I think it's a cross compile issue, because if I do the same, I do have asm/string.h (I'm running from the pinebook itself)
<valignatev>Also, I've prepared to finally submit Alacritty and rebased all my stuff on top of master but notices that it doesn't build on the newest guix version: for some reason guix vendors alacritty while trying to build alacritty e.g. it puts the very package I'm trying to build under guix-vendor dir of this very package
<valignatev>That didn't happened before I pulled latest commit yesterday
<cnmne>hi guix! I followed the "guix cookbook - direct checkout hacking" section to the T and it seems like my guix isn't picking up my changes to `/gnu/packages/ruby.scm'. It recognized it was changed and `newer than compiled', so I ran `make' according to the mailing list thread. Now it doesn't complain about being outdated, but the packages I added can't be searched or built!
<alextee[m]>would upstream welcome a change to the cairo package to allow for xml support?
<ngz>cnmne: Did you "guix environment guix" first?
<cnmne>ngz: yep!
<efraim>valignatev: I thought it did that with all the crates. Is it actually a problem?
<valignatev>I don't think it happened before. At least it didn't fail the build and it does now.
<ngz>alextee[m]: You are welcome to provide a patch.
<NieDzejkob>cnmne: Are you using ./pre-inst-env?
<cnmne>NieDzejkob: yep!
<alextee[m]>ngz: will do, it's just a matter of --enable-xml=true i think
<valignatev>efraim: It tries to build alacritty while building alacritty, it doesn't sound right to me.
<ngz>Note that this entails rebuilding 4800 packages, so it will certainly go into "core-updates" branch, i.e., once approved, it will not be available at once.
<ngz>cnmne: I would suggest to "make clean-go", "./configure --localstatedir=/var" and "make" again.
<cnmne>ngz: I'll try that
<nckx>Good morning, Guix.
<nckx>How's FOSDEM?
<valignatev>efraim: It's 100% didn't happen before. Luckily my logs from the previous builds are still exist. They show that cargo-build-system definitely didn't vendored the package as a dependency of itself
<valignatev>So it must've been introduced during the last month or so
<wajsel>Hi all, I got a problem after updating my system with sudo guix system reconfigure
<wajsel>all worked great until the update. Problem looks to be that gnome-session-binary warns about "unable to find required component 'org.gnome.SettingsDaemon.XSettings' (and other components)
<wajsel>from /var/log/messages I see those lines and also "gdm: GdmDisplay: display latest 1.286123 seconds"
<wajsel>this happens when I try to login on the graphic login display, which I assume is GDM
<wajsel>does anyone have any idea where things could have gone wrong
<wajsel>I did a "guix pull" before the reconfig
<wajsel>my /etc/config.scm had not changed after the installation
<wajsel>This is the first time trying guix-sd
<alextee[m]>just sent a patch for cairo to add XML support. is someone available to review it?
<alextee[m]>gtk and pango will probably need to be rebuilt, so i guess many things will have to be rebuilt after that
<alextee[m]> nice ID
<NieDzejkob>wajsel: did you reconfigure with sudo as your normal user, or when logged in as root?
<wajsel>guix pull as my user and then sudo guix system reconfigure
<NieDzejkob>okay, could you paste the output of `guix describe' and the contents of your config.scm? if you don't have any preferred paste site
<wajsel>I did not change to the root user. I read those two lines in the manual
<NieDzejkob>yeah, you did everything right. This is a bug on our side
<NieDzejkob>raghav-gururajan: you did some work on GNOME, any idea what could be happening here?
<NieDzejkob>wajsel: any chance we could get your config.scm and `guix describe'? That will make sure (well, much more probable) that we'll be able to reproduce the problem
<NieDzejkob>though, now that I reread your messages, are you observing any actual problems, or only those warning messages?
<wajsel> the guix describe
<wajsel> config.scm
<wajsel>the packages part is newly changed to use a mpa
<wajsel>... to use a map over the packages. the original version did also not work
<wajsel>that's the only thing I have changed so It's quite vanilla
<NieDzejkob>in the meantime, you could try using slim instead of gdm
<wajsel>gladly, I can't find GDM in my config.scm so how do I change that?
<NieDzejkob>you'd have to remove it like this: (remove (lambda (service) (eq? gdm-service-type (service-kind service))) %desktop-services)
<NieDzejkob>(put that where %desktop-services currently is)
<NieDzejkob>you'll need to add some stuff to use-modules, (srfi srfi-1) and (gnu services) should be enough
<wajsel>is there no need to add slim as service?
<NieDzejkob>yeah, you need to add (service slim-service-type) too
<NieDzejkob>"of course"
<wajsel>(use-modules (gnu srfi srfi-1)) is that how you would add that use-module?
<wajsel>this is now the top of the file
<wajsel>(use-modules (gnu srfi srfi-1))
<wajsel>(use-service-modules desktop networking ssh xorg)
<NieDzejkob>(use-modules (gnu) (gnu services) (srfi srfi-1))
<NieDzejkob>some might choose to split it up into separate lines
<NieDzejkob>e1026ba70138f105ebc95281d22c09241feee9d5 (pushed 20 minutes ago by Nicolas Goaziou, dunno what their nick here is), breaks guix pull due to a typo in (extension .png vs .patch)
<nckx>NieDzejkob: ngz; they quit a minute before your message.
*nckx 'll fix it.
<NieDzejkob>well that's just ironic
<nckx>I wonder how that happened.
<cnmne>ngz, NieDzejkob : thanks for the help, but it turns out my file was just written wrong yikes! I was using `guix import ... >> ruby.scm' and didn't wrap anything with `define-public'. sorry for the trouble!
<drakonis1>ah fosdem is over already
<drakonis1>thanks timezones
<wajsel>NieD: looks like this causing some problem for me. (services (append (list (service slim-service-type)
<wajsel> (service openssh-service-type)
<wajsel> (set-xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout))
<wajsel>sorry but got some more problems trying to reconfigure
<wajsel>$ sudo guix system reconfigure /etc/config.scm
<wajsel>guix system: error: service 'xorg-server' provided more than once
<wajsel>is it a problem with the (list command... )? should i add slim-service some other way?
<wajsel>my lisp abilities are not very great?
<drakonis1>hold on, you're just getting started
<drakonis1>its because gdm is included that it happens
<Blackbeard[m]>wajsel: please copy paste all your file in paste.debian :)
<ngz>nckx: Thank you for fixing my silly typo!
<nckx>ngz: No problem, it was certainly a new kind for me 🙂
<drakonis1>so, the fosdem recordings should slowly come online
<ngz>nckx: When I fumble, I try to be imaginative.
<nckx>Somewhere out there someone's now trying to create a .png that's also a valid diff.
<drakonis1>binary diffs heyo
<oriansj>drakonis1: well you could have done: ffmpeg -i "" -codec copy file_name.mp4
<drakonis1>the stream's over tho
<drakonis1>plus it happened outside of my waking hours
<oriansj>cron job?
<drakonis1>ehh i have never done a cron job before
<wajsel> config.scm
<pkill9>what can be done to increase the rate at which patches to add packages are reviewed and merged?
<ngz>Increase the number of committers?
<drakonis1>run a branch where trivial patches are merged?
*jonsger has calls running (not working) :P
<ngz>Isn't Guix data service supposed to apply patches and see if they build, or some such?
<oriansj>the important part is to add -t 01:00:00 so that it stops after the limit (in this case 1 hour)
<g_bor[m]><pkill9 "what can be done to increase the"> pkill9 ( i believe that we made some progress in this direction in the last few days, and have quite good plans for the future.
<drakonis1>ah guix days eh
<g_bor[m]>What actually should be done is to make it easy to review.
<drakonis1>i figure y'all have looked into avoiding letting them pile up like nix does, yeah?
<nckx>ngz: No, but it integrates with Patchwork, which can provide that kind of thing.
<tsmish>Hi #guix. Is there a way to change files in .guix-profile? vis package stores example configuration file in there, which gets picked because it is highest priority config.
<g_bor[m]>Oh, yeah! :)
<nckx>drakonis1: Yup, we looked into it: ‘yeah let's not do that’. Now we wait for the volunteers to show up. 😉
<drakonis1>heh, they've been waiting for more volunteers but they aren't showing up
<drakonis1>as there's too many drive-by patches
<nckx>drakonis1, g_bor[m]: Patchwork should deffo make it easier to review the average Guix patch. I hope.
<drakonis1>is there a rundown of what was discussed in guix days?
<nckx>We sent all the notes from the sessions to Andreas (I think), I assume they will be published soonish.
*nckx hasn't actually sent them yet.
*jonsger did :P
<Blackbeard[m]> How to Design Programs. 2edition
<pkill9>g_bor: ah good, what are the plans?
<nckx>jonsger: Thanks so much for your help on Friday. I already have working bootstrap binaries and am pretty close to bootstrapping, I think. Insane considering the few hours (if that) of work!
<pkill9>tsmish: no, the store is not meant to be modified
<jonsger>nckx: oh wow! keep us informed
<pkill9>tsmish: you'll need to modify the package definition to delete the example configuration file if that's what you want
<drakonis1>haha nice.
<tsmish>pkill9: well, looks like bug in vis package.
<bandali>ngz, hey, you have a minute?
<nckx>jonsger: I'm trying (and currently failing) to stay off my laptop during my holiday. We'll see how that goes.
<drakonis1>wajsel: its the way you're trying to remove gdm from the service set
<ngz>bandali: Sure
<bandali>ngz, firstly, thanks for the feedback and merges :-) second, re adding message-x as a propagated input for gnus-harvest, i'm not quite sure. it's an optional dependency after all, like bbdb
<drakonis1>as it happens, someone tried to do the exact thing you're trying here
<wajsel>drakonis1: yes, I got suggestion from NieDzejkob to replace it with slim because of problems with gnome-session
<bandali>but i think message-x may be a bit more useful for gnus-harvest compared to bbdb
<tsmish>pkill9: Actual problem is that configuration file cannot be overriden by anything, because package also sets $VIS_PATH to that directory, which has priority over $XDG_CONFIG_HOME.
<bandali>so if you suggest, i'll add it as a propagated input
<ngz>bandali: I have no strong opinion about message-x, if you think that's optional, we can ignore it. However, we should remove sqlite as a propagated input.
***jonsger1 is now known as jonsger
<wajsel>drakonis1: then I only need to remove gdm. Why was gdm started and not slim if both of them were in the %desktop-services ?
<bandali>ngz, ha, i'm a bit torn honestly. i'd personally probably add message-x along with gnus-harvest if i were to use gnus-harvest, but idk if i'd want to impose that onto others. maybe let's leave it out for now, and if people complain, we'll add it
<bandali>ngz, re sqlite, absolutely. the v2 i'm sending in a few mins has that sorted out, thanks for pointing that out :-)
<drakonis1>the service is probably enabled?
<drakonis1>on shepherd that is
<drakonis1>but i actually dont know if its possible to swap out gdm for slim
<drakonis1>hm, what's a way to view available shepherd services?
<wajsel>I removed the line with slim and did a reconfigure and on reboot, gdm started :/
<g_bor[m]>tsmish: I believe you can't do that easily. I think that the package should be fixed.
<wajsel>so the remove of gdm service did not work
<nckx>drakonis1: Available in the current system? sudo herd status.
<g_bor[m]>nckx : actually it already helps a lot, for example you can immediately see if the package lints. I also believe it is possible to check if it builds.
<g_bor[m]>More checks should be added, which is the easy part. Also patchwork attaches a state based on what checks passed, but does not yet allow to categorize patches based on that, which would be nice.
<g_bor[m]>wajsel: I believe this should not be allowed. I don't currently have access to the code, but these services should be made conflicting, which can be done by providing the same symbol, for example login-manager would do
<wajsel>can I dump what is the full config? so that all %base-magic is expanded?
<nckx>g_bor[m]: Yes, I was pleasantly suprised by the Data Service :-) I look forward to playing with it once I get home.
*nckx had forgotten how god-awful moshless ssh is.
<ngz>g_bor[m]: Is there a Data Service for the dummies available somewhere? All my visits to were totally unhelpful.
<g_bor[m]>wajsel: I don't know if the system provisioning information stores it interpolated, or in its plain form...
***jonsger1 is now known as jonsger
<g_bor[m]>But I believe if you are in the same guix state you can just copy it to a repl and query it or pretty print it
<valignatev>How do I delete non-empty directory in guile?
<g_bor[m]>ngz: what information are you looking for?
<wajsel>like whats in the default xorg configuration
<g_bor[m]>valignatev: is this in a phase?
<ngz>g_bor[m]: Well, I don't know. My problem is: what kind of information is helpful to me there?
<valignatev>g_bor[m]: yes
<NieDzejkob>wajsel: Fire up guix repl, then you can do (define my-config (load "/etc/config.scm"))
<NieDzejkob>and then you can poke at it with the various operating-system-* procedures
<nckx>valignatev: Guix provides a delete-file-recursively helper.
<wajsel>do I need to install guix-repl?
*jonsger kicks nckx to his well earned laptop free holidays :P
<valignatev>nckx: ok, thanks
<nckx>wajsel: Nope, it's ‘part’’ of Guix.
<g_bor[m]>ngz: for example if a package fails to build because of a dependency, it tells you the failing dependencies.
<ngz>g_bor[m]: So, it is more accurate than How can I get that information?
<NieDzejkob>wajsel: for example, you could do (map (lambda (s) (service-type-name (service-kind s))) (operating-system-services os))
<g_bor[m]>It also attaches lint info, so you can see what security vulnerabilities are there.
<NieDzejkob>I'd try putting the set-xorg-config before slim, might matter
<nckx>jonsger: Okie.
***ChanServ sets mode: +o nckx
***nckx was kicked by nckx (nckx)
***ChanServ sets mode: -o nckx
<jonsger>10s of holidays seems quite short
<nckx>Damned auto-join.
<bandali>nckx, how about a perma-ban? :p
<bandali>permanent holidays
<nckx>OMG power grab!!!1!1
*bandali whistles in the distance
<nckx>Little insider-GNU humour for you there 😒
*nckx → dinner.
<drakonis1>oho, guile 2020 talk up
<g_bor[m]>ngz you can click on the dependency failed thing and it returns a list of required failed builds
<pkill9>maybe there should be a generic service for display managers
<drakonis1>well, up next for guile, absorb racket features
<Blackbeard[m]>drakonis1: awesome :)
<pkill9>'display-manager' service, which you specify as sddm, gdm, etc
<drakonis1>lang keyword for racket.
<g_bor[m]>I wanted to check, but navigating such a wide site in mobile is not so fast :)
<pkill9>guile was born the year i was born
<drakonis1>other talks up: g-expressions
<g_bor[m]>pkill9 ( how do you think that a display manager service would improve the situation?
<pkill9>you wouldn't need to delete gdm service, there wouldn't be conflicts, it would be neater to have the name "display-manager" with a field to specify which display manager. honestly it probably wouldn't , i was just bikeshedding
<g_bor[m]>I mean it is almost trivial to do it, but you would still have to modify it if we include it in desktop services
<pkill9>i think it's easier though as you could just specify the service and it would 'overwrite' the one in %desktop-services, no deleting require
<pkill9>but it's bikeshedding so nevermind :P
<pkill9>you'd still need to delete it if you want no display manager anyways
<g_bor[m]>pkill9 ( How would that work? I mean the service would provide a symbol, so adding another instance would cause a conflict.
<g_bor[m]>So you would use modify-services, I believe...
<pkill9>oh not sure
<NieDzejkob>how does set-xorg-configuration work?
<g_bor[m]>I would rather vote for providing the symbol from the services, and expose a procedure, for example provision, that takes two list of services, combining in a way that all services in the first list are guaranteed and as much of the second list as possible without conflicts. Does that make sense?
<NieDzejkob>hmm, looks like it's hardcoding gdm
<NieDzejkob>wajsel: looks like you can't use set-xorg-configuration, here's an example of how I am setting my xorg-configuration for slim:
<g_bor[m]>So you could do something like (provision (list (service slim-service-type)) original-services)
<bricewge>NieDzejkob: It does. The documentation isn't clear about it.
<g_bor[m]>liberdiko: could you propose a patch?
<drakonis1>hmm, i'm having a bit of trouble while trying to recursively copy a directory
<NieDzejkob>guix lint: warning: while connecting to Software Heritage: host lookup failure: Name or service not known <- what's that about
<NieDzejkob>host resolves fine, though through two aliases
<NieDzejkob>drakonis1: what code are you using?
<drakonis1>hurf i know why, i'm missing the target
<NieDzejkob>I'm your rubber ducky now. Quack.
<bricewge>g_bor: Yes. But it would be better to adjust the other display manager services.
<drakonis1>quack quack.
<drakonis1>i went to look at guix util
<g_bor[m]>liberdiko: also think so.
<bricewge>g_bor: Having a way to compose service would be nice.
<g_bor[m]>It would be the right thing to do.
<drakonis1>i'm cleaning up gzdoom so i can hear its sweet dulcet metal tones
<drakonis1>i'm getting builder errors though
<drakonis1> some advice please.
<paprika>how do I properly upgrade my system?
<paprika>I just did a guix pull followed by a guix upgrade and a guix system reconfigure /etc/config.scm
<NieDzejkob>sounds about right, though wouldn't the reconfigure need sudo?
<paprika>my kernel went from 5.1.6 to 5.1.2
<g_bor[m]>liberdiko: i actually have the function provision, it just does not yet work for the case when the
<g_bor[m]>shepherd service is indirectly or multiple times extended.
<paprika>oh I logged in as root for that g_bor[m]
<drakonis1>errr, the current kernel is at 5.5.0
<g_bor[m]>I will try to get that into shape
<g_bor[m]>Actually the extensions mechanism is so flexible that it requires care to recursively find out service properties
<g_bor[m]>paprika: guix system?
<g_bor[m]>As what user?
<NieDzejkob>paprika: that's the problem. when you log in as root, you'll get root's $PATH, which gets root's package definitions
<NieDzejkob>and running guix pull updates your users' package definitions
<paprika>I get an ssl error when using sudo
<paprika>I'll do it again so I can give you the exact error
<paprika>I don't need to redo guix pull, right?
<NieDzejkob>hmm, do you have nss-certs in your operating-system's packages field?
<paprika>ah yes, that one
<paprika>Ill check my config.scm
<NieDzejkob>why is nss-certs not in %base-packages, anyway?
<g_bor[m]>Could you try hash guix after pulling?
<g_bor[m]>Also did you also pull as root?
<NieDzejkob>paprika: did you read ?
<paprika>I did also pull as root
<g_bor[m]>NieDzejkob: because of security reasons the maintainers decided that it will always require explicit user consent to install trusted certificatres.
<drakonis1>i'll ask about my issue later.
<drakonis1>i'm not sure why my build is breaking.
<g_bor[m]>paprika: I believe that guix pull as root, then hash guix and finally guix system reconfigure should work...
<g_bor[m]>What does which guix tell you?
<NieDzejkob>perhaps there should be a warning when you run /run/current-system/profile/bin/guix?
<leoprikler>which would be weird when you just freshly booted your system
<leoprikler>(after init)
<NieDzejkob>no, why? it should tell you to `guix pull && hash guix`
<NieDzejkob>drakonis1: it's called copy-recursively, not recursively-copy
<drakonis1>it still doesnt work
<drakonis1>syntax error this time
<NieDzejkob>have you pasted the error yet?
<drakonis1>hmm welp there's no wraparound here
<drakonis1>you might want to copy that to somewhere with wraparound
<drakonis1>oh, the error is that it didn't find anything
<drakonis1>cool beans.
<drakonis1>so that leads me to a situation where i have to find out the internal structure of the build
<NieDzejkob>are you using -K?
<g_bor[m]>drakonis1: looks like a syntax error...
<drakonis1>the error is that it didn't match the pattern
<drakonis1>i'm using -K but the directory is empty
<NieDzejkob>it's (modify-phases %standard-phases
<g_bor[m]>drakonis1: it is source expression didn't match any pattern. This is usually a scheme syntax error because of missing a paren somewhere...
<NieDzejkob>not (%modify-phases% *phases)
<paprika>g_bor[m]: It says the following
<paprika>The following environment variable definitions may be needed:
<paprika> export PATH="/root/.config/guix/current/bin${PATH:+:}$PATH"
<paprika>after running guix pull as root
<NieDzejkob>try reentering your shell
<paprika>what do you mean by that?
<g_bor[m]>NieDzejkob: yeah, did not spot it. So problematic identifier...
<drakonis1>NieDzejkob: i have %standard-phases
<NieDzejkob>paprika: log out and log in if on a console, or restart your terminal, or recreate your tmux pane, ...
<g_bor[m]>Well I assumed that phases* was a variable...
<drakonis1>well, i'm mildly confused now
<apteryx>am I doing something wrong, or is the GPG sig for PHP 7.4.2 bad?
<lfam>Which one apteryx?
<lfam>The xz?
<g_bor[m]>:-) would be nice to have some sleep, but I don't want to miss my flight
<apteryx>this is the dl link:, and the signature:
<apteryx>and the key used to sign appears to be the first on on the top of this page:
<apteryx>ah, sorry, s/bz2/xz/
<lfam>It works for me
<lfam>using RSA key 5A52880781F755608BF815FC910DEB46F53EA312
<apteryx>and then issuing: gpg --verify /gnu/store/myv8r3hsf4v0n4vjl6cv2adn41amwnli-php-7.4.2.tar.gz.asc /gnu/store/x6rjq20h2wyr4kqfzx46v3mbis6ncb48-php-7.4.2.tar.xz returns "gpg: BAD signature from "Derick Rethans <>" [unknown]".
<lfam>You're using the wrong signature file
<lfam>Double-check the filename extensions
<apteryx>ahem. Thanks for pointing that out.
*apteryx hides
<lfam>No worries :)
<paprika>when I want to reconfigure my guix system from /etc/config.scm I get the following error
<paprika>/etc/config.scm:43:13: error: extraneous field initializers (display)
<paprika>this is new for me
<paprika>I did do guix pull and hash guix as root
<paprika>also doing guix system reconfigure /etc/config.scm as root
<lfam>Maybe the slim-service-type interface changed
<NieDzejkob>paprika: what's line 43 of config.scm? Actually, paste your whole file if you don't mind
<paprika>what should I change? Also, nss-certs used to give an error when I wanted to reconfigure using sudo instead of root
<paprika>that's why I do it as root
<NieDzejkob>hmm, your slim-configuration looks alright
<NieDzejkob>try running guix repl (in the same way you're running reconfigure, to reduce variables), and then do
<NieDzejkob>,use(gnu services xorg)
<NieDzejkob>(slim-configuration (display ":0"))
<paprika>I made a typo, how do I revert?
<paprika>or quit?
<lfam>Like in bash
<paprika>It just says User interrupt
<paprika>but I'm still in scheme@(guix-user) [2]>
<bandali>ctrl+d often exits
<NieDzejkob>you can either ignore it or C-d twice
<paprika>thanks, C-d worked
<paprika>NieDzejkob: as to what you suggested:
<paprika>While compiling expression:
<paprika>Syntax error:
<paprika>unknown file:2:0: slim-configuration: extraneous field initializers (display) in form (slim-configuration (display ":0"))
<paprika>what does this mean?
<NieDzejkob>...and that doesn't happen on my side.
<NieDzejkob>what does guix describe say now?
<paprika>guix describe: error: failed to determine origin
<paprika>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version
<paprika>string is 1.0.0-1.326dcbf.
<paprika>should I do guix pull again?
<lfam>I think there is some confusion over whether or not you are using the root account
<NieDzejkob>you pulled as root before, right? try `hash guix' instead
<paprika>NB: I am using root account
<paprika>root@librepad /home/strawberry# hash guix
<paprika>root@librepad /home/strawberry# guix describe
<paprika>guix describe: error: failed to determine origin
<paprika>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version
<paprika>string is 1.0.0-1.326dcbf.
<lfam>You're using an old version of Guix
<lfam>We are on 1.0.1 now
<paprika>updating my system is where all this started...
<paprika>guix pull followed by guix upgrade?
<paprika>or guix package -u?
<paprika>I've lost track
<NieDzejkob>hmm, `which guix'?
<lfam>In order to update the system, as root, do `guix pull && guix system reconfigure /etc/config.scm`. Adjust the name of config.scm as necessary
<NieDzejkob>hmm, that's not right
<NieDzejkob>did guix pull say anything about env vars/
<paprika>not that I noticed
<NieDzejkob>what does echo $PATH say?
<paprika>root@librepad /home/strawberry# echo $PATH
<NieDzejkob>there was this before: <paprika> export PATH="/root/.config/guix/current/bin${PATH:+:}$PATH"
<paprika>yes NieDzejkob, but I don't know what to do with that
<paprika>that's why I posted that here
<NieDzejkob>hmm, I'm confused as to how my environment variables are being set on my system
<paprika>I've been getting that message for a while now but it didn't seem to matter since everything was working fine regardless
<NieDzejkob>if by "fine" you mean using ancient versions of guix...
<NieDzejkob>anyway, does a root shell not run /etc/profile?
<paprika>i didn't know, but I'd like to fix it
<paprika>what do you mean?
<lfam>I think we are getting distracted here
<NieDzejkob>no, /etc/profile is how the environment variables are set normally
<lfam>In order to get paprika up to date, they need to do `/root/.config/guix/current/bin/guix pull` as root,
<lfam>Then do the reconfigure
<lfam>On the Guix system, it shouldn't be necessary to manually do things with these environment variables
<NieDzejkob>yeah, but they aren't being set for some reason
<paprika>do a regular reconfigure lfam ? or /root/.config/guix/current/bin/guix system reconfigure /etc/config.scm
<g_bor[m]>lfam: seems like the correct thing to do.
<NieDzejkob>the latter is more likely to work :D
<lfam>paprika: After `guix pull` is done, log out of root, then log back in, and do the command you pasted
<lfam>You shouldn't need to be logging in and out normally, but in this case it will help us be sure that everything is good
<paprika>cool, doing that right now
<paprika>it'll take a while since I'm using an old X200
<lfam>One last thing, what command do you use to become root?
<paprika>or sometimes sudo su
<lfam>You should do `su --login` or `sudo --login`
<lfam>You need a login shell for all this stuff to work
<lfam>That will partially explain why things have not been going right
<lfam>Unfortunately the distinction between login and non-login shells matters a lot with Guix
<paprika>so now I do /root/.config/guix/current/bin/guix system reconfigure /etc/config.scm
<paprika>or hash guix first?
<lfam>Just reconfigure
<lfam>`hash guix` won't have an effect
<paprika>it's warning me that it failed to install locale, that won't affect anything, right?
<paprika>I got the following error after reconfigure:
<lfam>Locale error can be ignore
<lfam>Okay, locale error cannot be ignore
<lfam>One sec
<lfam>Do `export GUIX_LOCPATH=/run/current-system/locale` and then try again
<lfam>Okay but does reconfigure work
<lfam>That's just a warning
<lfam>Okay log out of root. Let's try it as your normal user: `sudo --preserve-env /home/USERNAME/.config/guix/current/bin/guix system reconfigure /etc/config.scm`
<apteryx>any recommendation for a networked file system that would work well on both GNU/Linux and Android devices?
<paprika>thanks, doing that right now lfam
<g_bor[m]>paprika: you should add --fallback to reconfigure to get past nss-certs
<lfam>Good advice
<paprika>ok I'll C-c then?
<g_bor[m]>This is a locale issue.
<paprika>can I put fallback after /etc/config.scm
<paprika>I did, seems to work
<paprika>Guix sometimes makes me feel like gnu+linux isn't for me..
<paprika>I've never been on IRC so much to ask questions for any distro
<lfam>Sorry paprika :(
<lfam>This issue you are having is a major UX problem
<paprika>though people are particulary helpfull here so that might also be why :)
<paprika>np lfam
<paprika>I'm glad this IRC exists
<lfam>I think we can improve it
<lfam>I'm curious about how you've been updating Guix since you installed it, and how we can improve the workflow / documentation to make it "just work"
<paprika>ah so it's not only my incompentence at work here?
<lfam>Um no this part is too confusing! You are not the first with this problem
<paprika>well, the manual is really helpfull but a bit intimidating and expects you to have a lot of basic knowledge on operating systems
<lfam>I see the manual section After System Installation" tells users to keep the system up to date with `guix pull; sudo guix system reconfigure /etc/config.scm`
<lfam>Is that what you've been doing?
<NieDzejkob>they mentioned before that they've been using su because of the certificate issue
<paprika>no I've quickly switched to doing it as root
<paprika>indeed NieDzejkob, nss-certs was giving issues
<paprika>I ended up doing guix pull as user, followed by guix package -u
<NieDzejkob>paprika: "was"? What was the fix?
<paprika>then doing the same thing as root again
<lfam>And becoming root with just `su` or `sudo su`?
<paprika>no fix yet NieDzejkob
<paprika>currently doing `sudo --preserve-env /home/USERNAME/.config/guix/current/bin/guix system reconfigure /etc/config.scm --fallback
<paprika>but that is taking a while
<paprika>I used sudo su and just su simultaneously as I didn't know I had to use su --login
<lfam>I think we can improve how we rely on these fine points of UNIX shells
<lfam>It's really obscure and arcane knowledge and a lot of people have been tripped up by it
<pkill9>is there a package containing glxgears?
<lfam>`su` without --login leaves the shell in a weird inconsistent state between the root account and the unprivileged user's account
<paprika>basically the first few results in any search engines tell you just 'su' is fine
<paprika>well, the best way to learn is trial and error, I guess
<lfam>Traditional distros don't rely on the details of this stuff as much as Guix does
<lfam>It doesn't matter on Debian, for example
<lfam>But Guix uses environment variables extensively, and those are set in different ways depending on how the shell is started
<lfam>Specifically the distinction between login and non-login shells.
<lfam>In the long run we need to stop relying on this in a way that breaks so easily
<g_bor[m]>What I usually do is sudo -E guix system --fallback reconfigure file
<efraim>pkill9: Mesa?
<lfam>Yeah, the method used by g_bor[m] works. It uses the unprivileged user's account (and their guix), whereas `sudo --login` makes you root (and you use root's guix)
<lfam>I ended up suggesting paprika do that because it seemed like root's guix was super old, whereas I figured their own users's guix would be more recent
<lfam>I'm not sure how to make this stuff more reliable but I think it's worth considering
<paprika>WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete'
<paprika>it's done now lfam
<paprika>no errors so far I think..
<lfam>That error is harmless
<lfam>Great, it finished reconfiguring?
<paprika>wait, I'll post a paste
<paprika>no red text so no real errors, right?
<lfam>Just paste it to be sure
<paprika>exactly :)
<lfam>I hope the bootloader was installed successfully... I'm not familiar with that warning
<lfam>Well if it worked you should be able to reboot and get the new system
<paprika>I'll be back
<paprika>systems are GO
<paprika>:) everything's fine
<g_bor[m]>lfam: it should be harmless. These are related to the guile transition, and expected to dissappear once that is complete.
<lfam>Cool :)
<paprika>from now on I should just update my system like this:
<lfam>What I do is `sudo --login` and then `guix pull && guix system reconfigure [...]`, also `guix upgrade` if I have packages installed by root
<lfam>If you don't want to use root's account at all you can, as your normal user, do `guix pull && sudo --preserve env guix system reconfigure [...]`
<lfam>That will use you user's guix and ignore root's guix
<lfam>Sorry, typo
<lfam>`guix pull && sudo --preserve env guix system reconfigure [...]`
<lfam>`guix pull && sudo --preserve-env guix system reconfigure [...]`
<lfam>It's --preserve-env. It "preserves" your user's environment while using sudo
<g_bor[m]>See you later.
<apteryx>after some readings, it seems NFS is the way to go for a network file system between GNU/Linux machines, and Sambda (CIFS) is a more supported alternative (less performant for small files) to access from Android.
<paprika>what is preferred, lfam ?
<paprika>upgrading as root or as user?
<pkill9>nope efraim
<lfam>paprika: I would use root because I think it's useful to keep that account up to date even if you rarely use it
<paprika>but using root also updates my user?
<lfam>paprika: If you let it go un-updated for a really long time (years) it might get hard to update if you decide to do it later
<paprika>aren't those sererated?
<lfam>paprika: Every user has their own copy of Guix and can install their own private packages with that copy of Guix. But the "system" packages are handled independently of that
<lfam>Hence the exist of the `guix package` command and the `guix system` command
<lfam>So, you use `guix pull` to update or manage your user's copy of Guix. That copy of Guix controls what packages are available to `guix package` and `guix system`
<lfam>Kind of like `apt-get update` but it's for each user
<paprika>ah ok
<paprika>so if there are multiple users they'd all influence the system?
<paprika>(in my case there's only one user, me)
<lfam>Potentially but it requires root privileges to use `guix system reconfigure`
<paprika>so I'm putting the commands in a text file for later use and so I won't remember them incorrectly
<paprika>should [...] be replaced with /etc/config.scm?
<paprika>lfam: ?
<lfam>Yes paprika. You can put the file anywhere so I didn't fill it out
<paprika>cool, thanks for your patience and amazing help
<paprika>others too btw :)
<lfam>Also you should do `guix upgrade` as your user too, to install the packages installed by your user
<lfam>I mean, to update them
<pkill9>i think glxgears is in mesa-demos which isn't packaged in guix
<paprika>does it matter if I do guix upgrade before or after reconfigure?
<lfam>paprika: No, they are not related
<paprika>ok, makes sense
<valignatev>Ok, I've finally submittel Alacritty: Pinging efraim :) Wanna die now
<efraim>I'll take a look at it and exo (exa?) when I get back from FOSDEM
<valignatev>efraim: Sure, I'm not in a hurry or anything. Have a great time at fosdem!
<NieDzejkob>woah. 275 patches.
<pkill9>oh, it's in mesa-utils
<wdkrnls>Now that qtwebengine is in the repository, I don't suppose anyone is interested in packaging RStudio?
<wdkrnls>It seems quite a bit more complicated than a packaging an R library.
<lfam>valignatev: Is there a git repo online with that work? It will be easier to clone a git repo than to apply all those patches
<wdkrnls>rekado had made a package for an older version before it depended on qtwebengine, but only in his bioinformatics repository.
<jackhill>wdkrnls: I think we'd need more js packages too perhaps?
<jackhill>I think some people are working on the js stuff, but I understand it's a tangled web of circular dependencies
<wdkrnls>There are a few things that the NixOS packaging script seem to just download from some amazon S3 file repository.
<valignatev>lfam: Just pushed to github: Mailing list workflow bad
<lfam>Thanks valignatev, please share the link in the mailing list thread
<valignatev>Okay. Unfortunately, I committed straight to master without creating a new branch because I haven't planned to upload a local repo anywhere :)
<valignatev>lfam: shared
<lfam>No worries valignatev, git will still work
<wdkrnls>I don't think there is any javascript that isn't already packaged in Guix.
<valignatev>Packaging Rust is nightmare. I can only imagine that js is a way worse
<wdkrnls>Packaging RStudio looks really complicated to me, but its an important package for a lot of R users, who would love to use Guix to make their scientific research more reproducible.
<wdkrnls>It's primarily a qt application, depending on qt-5.12
<wdkrnls>I went through all the packages the NixOS RStudio package brings in and they all appear to be in Guix.
<wdkrnls>It's just these extra executables, the source patches, and the environment variable wrapper stuff that I don't understand.
<NieDzejkob>efraim: python-path-and-address doesn't distribute its tests on PyPI, should I download from git and run tests or download from PyPI and skip tests?
<efraim>Ah, I didn't know that. From git then so we can have the tests
<NieDzejkob>(I actually only learned of this now)
<milesrout>how is packaging Rust a nightmare? The binaries are statically linked
<lfam>I would use pypi and skip the tests. If the upstream doesn't think the tests are important for downstream packagers that is okay
<valignatev>milesrout: Here I packaged Alacritty: Lots of small transitive and cyclic dependencies. Crates are broken up with no reason apart from working around a slow Rust compiler. Kinda looks like lighter version of nmp chaos
<shtwzrd>is there any way to get guix to output how it is resolving dependencies, and how it decides what to build first? I'd like to see how it's working its way through the tree when I pass it an operating-system form.
<jackhill>wdkrnls: oh cool, I didn't realize all the dependencies were packaged. I guess that wasn't true a few months ago when someone asked me. I don't have time to work on it right now, but that sounds promising
<wdkrnls>jackhill: no worries, thanks for listening :) I have posted my plea to the help-guix mailing list. I'm hopeful someone like zimoun or rekado might not have too much trouble with packaging it given their other impressive contributions to R-support within Guix.
<wdkrnls>There are some emacs packages which if added to Guix, would make it easier for me to work with all my .Rmd files without it. Some seemed easy enough to package, but then unfortunately they didn't work right when I tried to use them.
<wdkrnls>These are extensions to emacs-polymode which is packaged in Guix.
<jackhill>wdkrnls: +1 reading your mail now
<ngz>Ouch. Mono package is antique.