IRC channel logs


back to list of logs

<nckx>ACTION peeks in the spam folder, what's this.
<nckx>civodul: Did you get an emoji keyboard for valentine's day?
<bjc>it came in a *very* big box
<nckx>Like the Chinese mechanical typewriter I had as a child.
<nckx>ACTION → 😴💤
<Rampoina>is there an equivalent to specifically the configure/build/install commands?
<fruit-loops>"nix develop - Nix Reference Manual"
<civodul>nckx: even better: i got M-x emojify-insert-emoji, i'm a big fan! 😍
<civodul>Rampoina: "guix shell" is similar, but it doesn't let you run phases individually
<civodul>guix 🐚, that is
<fruit-loops>"Invoking guix shell (GNU Guix Reference Manual)"
<dp0>Hi, I'm trying to install guixsd on a VM using the GUI installer. I'm seeing the progress bar for some packages moving super slow. Specifically "libqmi" and "guix" so far. Is that common?
<dp0>It's weird. libgphoto (1.2MiB) is about the same size as libqmi (1.7MiB) but finished downloading in a couple seconds.
<vagrantc>been using guix plenty long now, and still surprised ... installing a package installs the gnutls-*-doc package?
<bjc>i know there have been complaints about the unicode progress bars, but i like 'em
<kraai>Hi. Why does `guix build rust@1.65.0` appear to work whereas `./pre-inst-env guix build rust@1.65.0` prints `guix build: error: failed to evaluate expression 'rust@1.65.0':\nUnbound variable: rust@1.65.0`?
<kraai>Sorry, the error message with `pre-inst-env` is `guix build: error: rust: package not found for version 1.65.0`.
<lechner>kraai / Hi, I'm not sure, but on my system ./pre-inst-env runs something different from the fully resolved `which guix` in a regular shell.
<fruit-loops>Exception: #<&compound-exception components: (#<&error> #<&origin origin: "scm_from_utf8_stringn"> #<&message message: "input locale conversion error"> #<&irritants irritants: 0> #<&exception-with-kind-and-args kind: decoding-error args: ("scm_from_utf8_stringn" "input locale conversion error" 0 #vu8(60 63 120 109 108 32 118 101 114 115 105 111 110 61 34 49 46 48 34 32 101 110 99 111 100 105 110 103 61 34 85 84 70 45 56 34 63 62 10 10 60 33 68
<fruit-loops>32 80 85 66 76 73 67 32 34 45 47 47 87 51 67 47 47 68 84 68 32 88 72 84 77 76 32 49 46 48 32 84 114 97 110 115 105 116 105 111 110 97 108 47 47 69 78 34 32 34 104 116 116 112 58 47 47 119 119 119 46 119 51 46 111 114 103 47 84 82 47 120 104 116 109 108 49 47 68 84 68 47 120 104 116 109 108 49 45 116 114 97 110 115 105 116 105 111 110 97 108 46 100 116 100 34 62 10 60 104 116 109 108 32 120 109 108 110 115 61 34 104 116 116 112 58 47 47 119 119
<fruit-loops> 57 57 47 120 104 116 109 108 34 32 120 109 108 58 108 97 110 103 61 34 101 110 34 32 108 97 110 103 61 34 101 110 34 62 10 60 104 101 97 100 62 10 32 32 60 116 105 116 108 101 62 100 101 98 105 97 110 32 80 97 115 116 101 122 111 110 101 60 47 116 105 116 108 101 62 10 32 32 60 108 105 110 107 32 114 101 108 61 34 115 116 121 108 101 115 104 101 101 116 34 32 116 121 112 101 61 34 116 101 120 116 47 99 115 115 34 32 104 114 101 102 61 34 47 1
<fruit-loops> 115 34 32 47 62 10 60 47 104 101 97 100 62 10 10 60 98 111 100 121 62 10 10 9 60 99 101 110 116 101 114 62 60 97 32 104 114 101 102 61 34 47 34 62 60 105 109 103 32 115 114 99 61 34 47 105 109 97 103 101 115 47 100 101 98 105 97 110 46 112 110 103 34 32 97 108 116 61 34 34 32 98 111 114 100 101 114 61 34 48 34 32 104 115 112 97 99 101 61 34 48 34 32 118 115 112 97 99 101 61 34 48 34 32 104 101 105 103 104 116 61 34 54 49 34 32 47 62 60 47 97
<fruit-loops>98 114 32 47 62 10 10 60 100 105 118 32 105 100 61 34 116 105 116 108 101 98 97 114 34 62 100 101 98 105 97 110 32 80 97 115 116 101 122 111 110 101 60 47 100 105 118 62 10 10 10 10 10 10 60 100 105 118 32 105 100 61 34 99 111 110 116 101 110 116 34 62 10 10 10 10 10 10 9 10 9 10 10 9 10 9 10 9 10 9 10 9 10 9 10 10 10 10 10 60 104 49 62 80 111 115 116 105 110 103 32 49 50 55 51 54 55 52 32 102 114 111 109 32 97 110 111 110 121 109 111 117 115
<lechner>sorry, the bot will stay off for the weekend
<bjc>why is that happening? is there some fluid leaking?
<lechner>kraai / vs
<lechner>bjc / Hi, I'm not sure but it's a decoding error
<lechner>the sun is setting here, so i'll you both on sunday
<bjc>yeah, i can tell that. just wondering why the crash dump ends up here. i assume ‘current-output-port’ or something is leaking out
<lechner>bjc / it worked well for typos in URLs
<mirai>so the bot suffers from some kind of allergic reaction?
<mirai>the theory seems to check out given the '#<&irritants irritants' message
<Rampoina><civodul> "Rampoina: "guix shell" is..." <- I know about guix shell, I was asking specifically about phases commands because of this.
<Rampoina>As far as I can tell (I haven't had time to try yet) it doesn't let you run phases at all? It's unclear to me what you do once you're inside of an environment with `guix shell --development X` . With the Nix command, one inside you're able to easily download the source, compile it and install it with those commands (although imo this is still lacking a command to make a package with the current change and install it). How do you do the equivalent
<Rampoina>steps in Guix? Manually?
<apteryx>AwesomeAdam54321: the postgresql trick work to start it in the build container, but the application (ruby-pg or ruby-activerecord) still seems hard-wired to want to task to a socket under /var/run/postgresql :-/
<apteryx>hm, a substitute server seems to be hanging connections
<apteryx>seems to be
<apteryx>shouldn't it time out and continue?
<apteryx>cbaines: is not responding anymore
<apteryx>oh, nevermind, the page finally loaded
<apteryx>must be under heavy load
<apteryx>but 'guix build ruby-railties --substitute-urls=' hangs minutes on "substitute:"
<AwesomeAdam54321>apteryx: Does ruby-pg or ruby-activerecord have options/settings related to postgresql?
<PurpleSym>lechner: Can we just keep that URL-repeating bot out of this channel?
<rekado>lechner: I don’t think the bot should print exceptions here. Make them go to a log instead.
<jpoiret>Rampoina: no, there's no way currently to run phases once inside the shell
<jpoiret>I wonder how we could do that, for nix it's easier since they have a tighter control on what build systems do, whereas we basically have any scheme code that can be modified on the fly per-package
<jpoiret>sneek, later tell kraai: rust-1.65 is not a public (exported) variable so the guix command line tools won't find it
<sneek>Got it.
<jpoiret>sneek, later tell kraai: you can use `guix build -e '(@@ (gnu packages rust) rust-1.65)'` instead probably
<sneek>Will do.
<AwesomeAdam54321>How can I prevent gcc from adding -fnoexceptions to the options? I tried giving -fexceptions to CMake but -fnoexceptions overrides it because it's in front
<AwesomeAdam54321>nvm it was because -fno-exceptions was hardcoded in a different cmake file
<futurile>Happy weekend Guixers
<unmatched-paren>hello guix :)
<jpoiret>sneek, later tell civodul: making hurd work will require a glibc patch
<sneek>Got it.
<faust45>hi guix1
<faust45>i have a question about guile
<faust45>can i have a few (abort) in side (call-with-prompt)
<faust45>(% (begin
<faust45>    (abort)
<faust45>    (abort))) ?
<Guest74>I need to edit /etc/libvirt/qemu.conf to add the path of $(guix build ovmf) so libvirt can use UEFI.  I did not see anything related to that in the manual.  Does someone know how?  Basically I just want UEFI to work in virt-manager
<jpoiret>Guest74: it doesn't exist on your system yet, right?
<jpoiret>you can extend etc-service-type for that
<Guest74>yes, there is a libvirt dir but without any confs
<Arjanhehim[m]>is there any reason /run is not a tmpfs on Guix System?
<AgentKilo[m]>Hi gents! When defining a package, can I grant my compiler process network access so that it can pull native dependencies the internet all by itself?
<AgentKilo[m]>The package looks like this:
<AgentKilo[m]>Or should I define all the dependencies as separate Guix packages?
<AwesomeAdam54321>AgentKilo[m]: All the dependencies should be defined as separate Guix packages
<AgentKilo[m]>Yeah I thought so. Guess I need a zig-build-system. But it seems the Zig package management interface is not quite stable yet. I was hoping there may be some ad-hoc solution
<AgentKilo[m]>And another question: When using git-fetch, what are the proper steps to calculate the base32 hash for a package? I tried guix hash -x -S nar .
<AgentKilo[m]>and guix hash -x -S nar ./some-src-dir
<AgentKilo[m]>and andguix hash -x -S git ...`
<AgentKilo[m]>they all produce different hashes, but none of them is the "actual hash" prompted by Guix
<Rampoina>jpoiret: gotcha, thanks. No idea how you could do it, I'll just leave the idea in the air ;)
<jpoiret>AgentKilo[m]: `guix hash -rx ./some/dir/`
<AgentKilo[m]>Hmmm, I tried that, and it produced the same hash as `guix hash -x -S nar ./some/dir/`, but not the "actual hash" printed by Guix either
<AgentKilo[m]>./some/dir/ should be the to-level dir that's cloned by git, right?
<bost>Hi. `guix lint <my-new-package>` reports 'can be upgraded to 1.5'. What does it mean? What should I do? The package version is defined as '(git-version "0.1" revision commit)' where the revision is "0".
<AgentKilo[m]> do I locate the source dir for some specific package in the store? Maybe the repo I cloned manually differ from the one in the Guix store?
<next4th>AgentKilo[m]: `guix show PKG` will report its location relative to the checkout.
<next4th>bost: that means that package may have a release version newer than your packaged version, you should check its homepage/git repositoy to see which version is wanted.
<AgentKilo[m]>next4th: Thanks! I see something like this running guix show zls:
<ae_chep>Could I get some eyes on #61768 please?
<ae_chep>Apologies... It's #61786 . Not #61768
<bost>next4th: Ah, ok. Thx. '(git-version "1.5" revision commit)' makes guix lint is happy, indeed.
<AgentKilo[m]>Seems there's no info for me to locate the source code in the store? To clarify, I want to check the zig source code of zls, not the guile source code for the package definition.
<next4th>AgentKilo[m]: guix build -S zls will get it, if the 'guix build zls' output the safe store path (if not same, the soure will be a different zls package, but near)
<next4th>output the same
<next4th>bost: well, you need make sure the commit is really newer than 1.5, or why you would prefer a git version than a release (tagged) one?
<bost>next4th: Ok, here are the details: I'm packaging, it has a release tag 1.5., but in fact I'm interested in the d228d75 commit.
<bost>next4th: d228d75 is the latest one.
<next4th>okay, that make sense..
<AgentKilo[m]>next4th: Yes! guix build -S zls gives what I want! My manual clone DO differ from the source in the store though.... I need to spend some time to find out why.... Many thanks guys!
<next4th>cool :)
<jpoiret>AgentKilo[m]: did you check out the right commit/tag?
<jpoiret>that's what often happens to me :p
<mirai>shouldn't files under gnu/packages/aux-files get registered in gnu/
<jpoiret>mirai: they're in
<jpoiret>as to why, 🤷
<bost>next4th: One more thing: The specifies no version, revision or anything like it. I use (git-version "0" revision commit) with revision "0" then `guix lint` complains 'emacs-railscasts-theme@0-0.1340c3f: updater 'generic-git' failed to find upstream releases'. What should I do about it?
<mirai>jpoiret: was this question ever raised before?
<kraai>lechner: thanks
<sneek>kraai, you have 2 messages!
<sneek>kraai, jpoiret says: rust-1.65 is not a public (exported) variable so the guix command line tools won't find it
<sneek>kraai, jpoiret says: you can use `guix build -e '(@@ (gnu packages rust) rust-1.65)'` instead probably
<kraai>jpoiret: thanks!
<kraai>that works.
<unmatched-paren>kraai: note that rust-1.65 likely won't have a substitute
<unmatched-paren>we should have a rust-latest package, but adding that would be harder than it sounds
<unmatched-paren>the rust package is not defined as just (define-public rust CURRENT-RUST-VERSION)
<unmatched-paren>it has a lot of changes that basically revert a bunch of modifications we make to the rust-VERSION packages to make them slightly less of a pain to build ad nauseum, iirc :)
<next4th>bost: that's fine i guess, that just means the updater can't handle repo without a proper tag/release..
<unmatched-paren>(about the substitute: cuirass only seems to build packages that either (1) are public, which means they will be picked up by FOLD-PACKAGES, or (2) are used by a package which is, which would of course lead to it being built as a dependency
<unmatched-paren>) >:(
<bost>next4th: thx
<jpoiret>ahhhh yes, the oft-praised logind replacement greetd pulling in millions of rust dependencies
<jpoiret>what a time we live in
<unmatched-paren>ACTION once again laments the fact that rust could have been way better
<jpoiret>these days I don't think any language can escape the dependency hell-hole
<unmatched-paren>(btw greetd is not the logind replacement, seatd is; it's written in C, thank goodness)
<unmatched-paren>greetd does work well though. it's just a shame it's in rust
<jpoiret>old languages manage to avoid because they're just that, old. Current society has no need for proper dependency management
<mirai>so rewrite-in-rust is a conspiracy to sabotage guix?
<AgentKilo[m]>jpoiret: Yeah both repos are at the same commit. Turns out it was the excess files generated by previous builds I ran in the manually cloned repo. Should have used a clean repo :p
<jpoiret>unmatched-paren: i do use it myself and am happy with it
<civodul>time to get our act together and Guile all the things!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, jpoiret says: making hurd work will require a glibc patch
<civodul>jpoiret: re Hurd, did you see ?
<mirai>I don't really comprehend the buzz around rust
<jpoiret>but yeah, I just wanted to see if it builds on core-updates. then i was greeted by mrustc + 10 rustc drvs, as well as all the dependencies
<ellysone[m]>borrow checker go brrrrrrrrrrrrrr
<jpoiret>my laptop Ctrl+C it itself, didn't want to go through all of that
<mirai>the safeties and whatever touted benefits exist... in languages like Ada (2012)
<unmatched-paren>ellysone[m]: That brrr is of course your CPU.
<jpoiret>civodul: not that mail, no, but the problem is that newer releases of mig also need newer gnumach
<jpoiret>and newer gnumach need newer hurd, see where i'm going with this?
<civodul>ah now that's interesting
<civodul>Mach doesn't depend on the Hurd, though?
<jpoiret>mig depends on gnumach unfortunately
<jpoiret>no it doesn't
<mirai>not to mention Ada (or SPARK) contains some very interesting tooling regarding program correctness
<jpoiret>i mean that older hurd won't build with newer gnumach
<civodul>jpoiret: did you try updating these things already? i know others such as r​ekado tried recently
<unmatched-paren>kraai: <- if we wanted to have a rust-latest package, we'd need to have another one of these... things. modified for 1.65, no less.
<civodul>jpoiret: maybe we can start with what you have?
<jpoiret>i basically followed what zamfofex did, but also added the glibc patches
<civodul>well, except for glibc :-)
<civodul>what's the deal with glibc?
<jpoiret>the glibc patches are only needed to build the cross libc
<jpoiret>the cross libc doesn't configure properly for the mach part
<civodul>so you have something that works for cross-compilation?
<jpoiret>it doesn't pass -ffreestanding when using AC_CHECK_HEADER, so #include <stdint.h> tries to use a non-existing glibc instead of the gcc built in
<jpoiret>well, I haven't built the cross toolchain for hurd yet
<jpoiret>because the glibc patch triggers a world rebuild :)
<civodul>it'd need to be applied conditionally
<civodul>but then we need a custom phase
<jpoiret>yeah, I was thinking of that as well. Maybe only for xglibc/hurd-headers and cross-libc
<civodul>all this is becoming unreadable :-)
<jpoiret>yes :) especially the hurd-specific "yes we need to build glibc to build the system headers"
<kraai>unmatched-paren: what's the reason for not pointing the rust package at the latest upstream release? dependency churn?
<civodul>once we've sorted cross-compilation out, we'll need tarballs to build from; otherwise we'll lose native i586-gnu support due to cycles
<unmatched-paren>kraai: we'd need to rebuild things, yeah
<jpoiret>civodul: wdym cycles?
<unmatched-paren>Quite A Few things, to put it lightly
<jpoiret>i'm not very familiar with the bootstrapping part
<unmatched-paren>(see: librsvg, which is pretty low down in the dependency graph iirc)
<jpoiret>kraai: also, upstream releases wayyy too often
<civodul>jpoiret: take mig-boot0 in commencement.scm: it cannot use 'git-fetch'
<jpoiret>ahhh, right
<jpoiret>we could host our own tarballs of the latest tags
<civodul>but that's ok, we can run "make dist" on our side and upload that to
<jpoiret>i'm not sure upstream wants to release right now
<civodul>since the Hurd folks are even more disorganized than we are :-)
<civodul>there's no real "upstream", only Debian
<civodul>that's part of the problem IMO
<jpoiret>so we need hurd and mig only?
<civodul>if we do need a Hurd update, then yes, we'll also need to host tarballs
<unmatched-paren>jpoiret: oh my, they're on 1.68 now...
<jpoiret>well, I can try to work the cross-compilation out, but that'll take some time
<civodul>i was hoping we could make do with just a mig update
<civodul>apparently that won't be the case
<jpoiret>i'll try to see if we can use the mig right after the commit that fixed this
<jpoiret>but it was not too long ago
<bost>next4th: ... and also for `guix lint` reports 'warning: no tags were found for ...'. I guess that can be ignored as well(?)
<civodul>jpoiret: for const qualifiers, it's mig commit cf4bcc3f1435eafa3ed8b5fadfa9698033d1e2df
<civodul>initially i tried to apply just that patch on top of 1.8, but that didn't work
<civodul>maybe we could backport it though, i haven't tried
<jpoiret>i'll clone and git blame
<bjc>what's “mig” mean in the context of the hurd?
<jpoiret>maybe it won't be too hard to backport
<civodul>bjc: "Mach Interface Generator"
<bjc>ah, thanks
<civodul>jpoiret: i'll let you look at it then; lemme know how it goes or if you'd like to pass it on or whatever :-)
<next4th>bost: um, it seems so, for detail need to check the updater code, which i haven't :)
<civodul>in other news, i pushed Mitchell's post on cross-compiling for Zephyr as a draft:
<civodul>feedback welcome!
<mirai>can someone confirm that they're getting only one path with this command? $ guix shell libxml2 docbook-xml docbook-xml@4.5 -- sh -c 'echo $XML_CATALOG_FILES'
<bjc>mirai: /gnu/store/qx3jgv6vfq79m0g4rdrk9k5ib5nir7ml-profile/xml/dtd/docbook/catalog.xml
<mirai>it should be displaying 2 paths
<mirai>looks like search-path is broken
<civodul>mirai: there's only one profile so it cannot display two entries
<Guest74>test /gnu/store/m4d1fspdy41xyf1hxa5qnp00h8ma5pkl-profile/xml/dtd/docbook/catalog.xml
<Guest74>hah interesting, pasting that path first will not sent my msg, anyways I wonder why I have a different hash than bjc
<bjc>messages in irc can't start with ‘/’
<mirai>civodul: one profile?
<Guest74>bjc Ah yea make sense. Didn't thought about that
<mirai>civodul: the issue here is that the first catalog.xml from docbook-xml is chomped
<mirai>it should be displaying VAR="/first/catalog.xml /second/catalog.xml"
<jpoiret>civodul: i don't think we can backport
<jpoiret>i've backported mig and gnumach's patches okay, but these ones will be much more painful
<jpoiret>(it doesn't apply properly in most of the files on our used commit)
<civodul>jpoiret: ok, i see
<civodul>the other option would be to strip 'const' qualifier from libc...
<jpoiret>but we're back to square one then
<civodul>that could be a tactic for now if it allows us to fix Hurd support in core-updates more quickly
<civodul>at some point we'll have to do that upgrade anyway
<jpoiret>if we're allowed to make changes to glibc, then better patch it
<jpoiret>so we can also get newer mig+hurd+gnumach
<jpoiret>all on "related" commits
<civodul>yeah, it's just more work, but it's more fruitful medium-term
<jpoiret>it's just more churn :) i have the patches ready for glibc
<jpoiret>ah, still have to deal with the tarball stuff though
<jpoiret>but getting it to cross-compile will be good enough
<civodul>sounds good
<civodul>i'm really happy you're looking into it BTW
<jpoiret>who should generate the tarballs?
<civodul>i can do that
<jpoiret>I guess it'd be better if a maintainer does it, right? (didn't want to shove that work onto you :p)
<civodul>though you'll have to do that as well to test locally?
<civodul>(i'm not a maintainer)
<jpoiret>i'm worried the tarballs will change
<civodul>(but i'm an uploader :-))
<civodul>well yeah, if i regenerate them locally, they'll be different from yours
<jpoiret>well, I'll see how long it takes using my local commits to go back to cross-glibc
<civodul>but if we communicate clearly on the commit(s) to use, that should be fine
<jpoiret>we'll look into the tarballs later
<civodul>do we need tarballs other than that of mig?
<Guest74>How do I set user fonts? I have a file for ~/.config/fontconfig/fonts.conf but I can't copy my own since Guix has one already created for system fonts
<jpoiret>gnumach and hurd as well i'd say, they're all used for the commencement
<jpoiret>Guest74: you should be able to use that file to specify which fonts you want
<jpoiret>i've done so myself
<Guest74>ah okay, thought since it is a symlink I need to configure it somewhere in Scheme
<jpoiret>are you using guix home?
<civodul>jpoiret: ok; not great, if that's what it takes, we'll do it
<jpoiret>it's quite annoying how tightly coupled these packages are
<Guest74>jpoiret not yet but I plan
<civodul>what's more annoying is that "upstream" is not attempting to clarify which versions works with what
<jpoiret>then there shouldn't be something at ~/.config/fontconfig/fonts.conf by default I'd say, but maybe some DE you used put something there
<civodul>BTW, Hurd contributor Sergey has been working on x86_64 userland support lately, and apparently made good progress!
<jpoiret>\o/ i've been lurking on #hurd for a while and they seem to be making a lot of progress
<jpoiret>smp as well
<jpoiret>I think it should be easier to manage those changes once they're not tied to the whole core-updates thing
<Guest74>jpoiret hm strange.  I only have EXWM and Slim which should be very minimal.  Guess I need todo some testing to figure out what creates that file
<civodul>jpoiret: yes; next time we'll do a feature branch! \o/
<jpoiret>second time my terminal itself crashes today
<jpoiret>good times
<jpoiret>oh no
<jpoiret>the service managing my fans was down
<jpoiret>here's the culprit
<Guest74>jpoiret Actually I am using home services for openssh. but that shouldn't create a fonts.conf or should it?
<jpoiret>i don't think so no
<jpoiret>but you never know :)
<mirai>I spotted this bug? in guix/search-paths.scm but I have no idea if the fix is correct or if the bug may go deeper than this:
<mirai>it's used with (filter-map search-path-definition search-paths)
<mirai>but that match never happens
<mirai>I say bug because it doesn't seem to "unbreak" anything
<mirai>but its not doing anything in its current state
<mvnx>More of a Guile question than a Guix question but what is the un-duckduckgo-able star (`*`) in `cons*` seen in some configuration examples?
<singpolyma>Just part of the procedure name
<bjc>it allows you to use multiple arguments: (cons* 'foo 'bar 'baz '()) ⇒ '(foo bar baz)
<bjc>more convenient than append in a lot of circumstances
<mvnx>How does it differ from `cons` without the `*`?
<bjc>normal cons only takes two arguments: the head and the tail
<mvnx>ohhh that's what you meant by multiple - got it
<mvnx>Thanks a lot
<lrabbt>Hi, I'm trying to install `rbw`, but it's running into a dependency mismatch, does anyone know how to install it?
<jpoiret>dependency mismatch? wdym?
<jpoiret>profile conflict?
<lrabbt>it's asking for `lock_api` "^0.4.6", but no candidates match (0.4.5, 0.3.4, 0.1.5)
<lrabbt>here are the build logs
<lrabbt>what I stated is at the very end
<jpoiret>ah, well that's probably a packaging issue
<jpoiret>maybe someone upgraded a dependency, not knowing that some dependent relied on a specific version
<jpoiret>actually no it'd have to be the opposite, weird
<lrabbt>I searched a little bit, and there is a big patch updating `rbw`, but for the time being, I'd be ok just fixing the current version
<jpoiret>well, we need to upgrade lock_api then probabbly
<lrabbt>that's what I found weird, when repacking, shouldn't the build fail if your version requires a newer version from somewhere else?
<lrabbt>I'll try to upgrade it locally, but I'm very new to guix (a week new), so maybe I'll do it wrong
<lrabbt>upgrade the lock_api, I mean
<arjan>lrabbt: that patch set does not even update it yet, just some of the dependencies, some others needed a newer Rust version, so I put it on hold for now
<lrabbt>arjan: so what do you suggest for a more immediate fix? is upgrading lock_api ok?
<arjan>sure, I think that does fix building the current version at least
<arjan>but I also remember getting some weird runtime errors about JSON parsing, not sure if it was caused by the Guix packaging
<johnjaye>where are the build instructions for emacs?
<johnjaye>is it
<arjan>do you mean the package definition? you can find it using "guix edit emacs"
<johnjaye>oh ok
<johnjaye>yeah like ncurses, libgmp, stuff to build emacs
<apoorv569[m]>I moved from using %desktop-services to %base-services and manually adding services I need from %desktop-services.
<apoorv569[m]>Before I was defining this variable,
<apoorv569[m]>then in the end of the services section of the config I was doing,
<apoorv569[m]>Now I wanna move all this directly in the services section but I am getting errors.
<apoorv569[m]>I added this
<apoorv569[m]>and it gives me this error,
<apoorv569[m]>The last is from when I had (udev-configuration-rules config)))))
<apoorv569[m]>now I get this error, guix system: error: more than one target service of type 'udev'
<jpoiret>apoorv569[m]: you need to extend the udev-service-type to add rules
<jpoiret>for example I have "(udev-rules-service 'android-udev-rules android-udev-rules)" in my services
<lrabbt>arjan: thanks for the help, got rbw working by bumping rust-lock-api-0.4 version
<lrabbt>should I submit a patch?
<lrabbt>also thanks, jpoiret
<jpoiret>lrabbt: it's probably a good idea yeah
<lrabbt>I've never done it, how do I know the changes didn't break anything else?
<civodul>mirai: re 'match' doesn't require you to list all the fields in the pattern, so that's fine
<jpoiret>lrabbt: well, you should try to build all the packages that `guix refresh -l rust-lock-api` lists
<jpoiret>but then again, I don't think that works for rust dependencies
<lrabbt>I've taken a look at --list-depends before patching, I found weird it just listed ' dep: python-cryptography
<lrabbt>I thought I'd done something wrong
<lrabbt>It doesn't even list rbw itself
<lfam>If it's a Rust package, unfortunately Guix doesn't handle Rust dependencies in the normal way, and they aren't visible through the Guix user interface
<lrabbt>oh, so no option other than to go blind, then?
<bjc>how do other distros deal with rust/npm/go? just give up?
<lfam>I would *cheat* and do `git grep rust-lock-api gnu/packages | wc -l`
<jpoiret>i think the best test here is to simply send the patch to the ml, and QA will compute the derivations
<lfam>We don't give up for Go, bjc!
<lfam>We kinda gave up for Rust
<jpoiret>did we?
<bjc>antioxidant seems to have died on the vine
<lfam>Well, like I said, Guix doesn't treat Rust dependencies in the normal way. The Rust package graph isn't something that the Guix UI can inspect
<jpoiret>right, but we still have quite a lot of rust packaged
<lfam>We gave up on doing it right ;)
<lfam>IIRC, the primary reason for this is that Rust programmers created many circular dependencies between their programs, but Guix can only model packages as an acyclic graph
<lfam>So, Rust packages are handled differently by Guix
<jpoiret>the acyclic deps are mostly there for "development" inputs
<jpoiret>i think
<lfam>It's fair to say that both Rust and Guix gave up a little bit
<bjc>i'm surprised rust can do that. crates have to be compiled independently, so how can they cycle?
<jpoiret>but just a little bit, other distros just shell out to cargo/go/npm
<lfam>Dunno bjc
<bjc>who was working on antioxidant? was that maximed?
<jpoiret>well, i think it's because some crates have features which create cycles, but they're not actually cycles since you don't depend on the same crate with the same features
<bjc>ah, i se
<jpoiret>you could see it as "every package needs a -minimal version, but maybe more than one even" problem
<jpoiret>civodul: btw, I haven't had any issues with the transparent huge pages in some time now, have you? are the qemu lock ups gone?
<lfam>I do think we should strive to overhaul how we handle Rust packages, so that the UI works properly for them
<civodul>jpoiret: i tried qemu recently and it went fine, so it may well be done
<civodul>i'm on 6.1.15-gnu
<jpoiret>6.1.11 for me
<jpoiret>I'll soon be at glibc-cross-hurd 🤞
<jpoiret>some automake tests need emacs? 🤨
<civodul>heh, who knows!
<Guest74>Is there a cmd to see why a file is present? I have a ~/.config/fontconfig/fonts.conf file and no clue why
<Guest74>(symlinked to gnu store)
<lfam>But, I can tell you that this file is related to fontconfig, which makes fonts wokr
<davidl>Hi, without knowing when, or fully if, what would the requirements be reg. copyright etc. if I wanted to build a GuixSD derivative distribution? I considered maintaining some patches and mainly follow Guix master but with a lot more default everything, and probably some simple custom package GUI for package management, maybe some changes to the installer etc. What about keep using Guix
<torari>hi its me torari
<davidl>...default substitute servers? What if the derivative distro has non-free things - would that change stuff?
<rekado>davidl: this is not a problem of licensing; our substitute servers will never provide non-free stuff, so it would be unreasonable to ask our servers for those things
<rekado>instead of a derivative distribution may I suggest using a channel?
<rekado>you can provide a whole lot of stuff in a channel — not just packages.
<sadmax>When following the instructions from I'm receiving an error I haven't found any suitable answer for online. When following the instructions I add a dbus-service to my services list. I then reconfigure my system. I'm receiving `guix system: error: more than one target service
<sadmax>of type 'dbus'`
<sadmax>I'm at my wit's end. I haven't configured any other dbus services
<Guest74>do use something like gnome DE?
<sadmax>No, I use the xmonad window manager.
<rekado>what services do you use?
<sadmax>It comes down to `(dbus-service #:services (list bluez-alsa))`. I cannot add this line to my config, else everything breaks.
<rekado>are you using %desktop-services?
<davidl>rekado: I know your servers won't provide non-free stuff, but the burden of maintaining substitutes for everything, except some additional packages, is prohibitively expensive for a small derivative distro. I do have a channel already, mainly for packages. What are all the things I can possibly have in a channel? I might want to override the grub-service, and the default creation of files in the user's Home-dirs, and default init files for some
<davidl> software, and default packages for new users. If I can get all that in a channel, that might be sufficient.
<lfam>Hey rekado, do you have any idea how to create a TLS client certificate for using the Cuirass web interface on Apparently we lost the script mentioned in ''.
<rekado>sadmax: note that the cookbook entry does not use any default list of services but an explicit list of services
<rekado>(I wrote that cookbook entry))
<rekado>lfam: no, we lost the certificate infrastructure when the file system was erased; it wasn’t backed up.
<rekado>would have to create new keys and certs
<lfam>What a blow
<jpoiret>civodul: got up to a build error of gnumach, so now I have the toolchain compiled, it'll be easier to test out the update
<rekado>lfam: all the client certs had expired anyway, so it’s not too bad. But it’s annoying for sure.
<sadmax>Oh, interesting. Is it common to not use the base services?
<lfam>rekado: Did you set it up initially?
<rekado>lfam: yes. IIRC it really wasn’t much that couldn’t be found on countless sites on the internet. Very boring stuff using openssl to create keys, CSRs, etc.
<Guest74>I configured via Guix home an alias for ls but it is not working.  Do I need to restart my machine to take effect or what is the problem?
<rekado>but it’s the kind of boring thing that I cannot ever commit to memory
<jpoiret>davidl: you can't "override services" but you can create your own derivative services
<rekado>(it’s also the unintuitive kind of boring)
<jpoiret>but roughly you could do all of that in a channel yeah
<lfam>On guix-sysadmin, people are advocating for giving more people SSH access to berlin so that they can use the hardware, but I think that's the wrong choice. It would be great to get this safer method working again, rekado
<rekado>lfam: I agree. I find SSH access to the substitute servers icky.
<lfam>I even suggested removing my own access
<rekado>lfam: I’ll try to make time to read up on this client certificate stuff again.
<rekado>maybe tonight
<rekado>sadmax: no, it’s common to use at least %base-services
<lfam>That would be much appreciated it. If you can't get around to it, I might be able to in a few weeks
<rekado>sadmax: I wrote this cookbook entry to document the headless setup that I had been using for years.
<rekado>sadmax: since it’s headless I don’t use %desktop-services
<rekado>%desktop-services contains a dbus-service instance already
<sadmax>I'm pretty new to this. I tried modifying desktop-services to add bluez-alsa to the services list, but could not get it to work.
<sadmax>I already have ``` (modify-services %desktop-services
<sadmax> (elogind-service-type config =>
<sadmax> (elogind-configuration (inherit config)
<sadmax> (inhibit-delay-max-seconds 2)
<sadmax> (handle-lid-switch-external-power 'suspend)
<sadmax> (lid-switch-ignore-inhibited? '#t)))
<sadmax> )``` in my config
<rekado>sadmax: modify-services is what you want here
<sadmax>But I couldn't figure out something equivalent for dbus-service
<rekado>you can add a clause for modifying the existing dbus-service-type
<apoorv569[m]>jpoiret: I see. So `udev-service-type` is already a part of `%base-services`?
<sadmax>```(dbus-root-service-type config =>
<sadmax> (dbus-configuration (inherit config)
<sadmax> (services (list bluez-alsa))
<sadmax> ))```
<sadmax>will wipe out the service list that was already present ni %desktop-services, right?
<sadmax>How do I extend the services list to include these new services, while keeping those items which are already present in %desktop-services?
<Guest74>Okay I figured it out.  Guix home creates the ~/.config/fontconfig/fonts.conf file although I used it only to configure openssh.  Anyways I now need to add my user default fonts and the only thing I found is which is for adding dirs that have fonts
<davidl>jpoiret: ok, do you mean like creating a service based on an existing service type, like (define-public special-cgit-service (service cgit-service-type (cgit-configuration ... ? That's of course a nice way to be able to do lots of stuff without messing with much normal Guix, which I like. However, I suspect it's not sufficient for what I want to achieve.
<rekado>sadmax: you need to extend the dbus-root-service-type
<rekado>the dbus-root-service-type is defined in such as way as to allow extensions
<rekado>comments in the definition say this: Extensions consist of lists of packages (representing D-Bus services) that we just concatenate.
<rekado>sadmax: I believe you can use simple-service for this
<rekado>(simple-service 'my-dbus-extensions dbus-root-service-type (list bluez-alsa))
<rekado>could you please try that?
<rekado>if this works for you we could 1) add an example for dbus service extension, 2) update the cookbook entry to remove the deprecated use of the “dbus-service” procedure, and 3) mention the case when a dbus service already exists (e.g. when %desktop-services is used).
<rekado>sadmax: please also note that %desktop-services likely implies the use of pulseaudio; using bluez-alsa will likely not work as expected
<civodul>jpoiret: well done!
<rekado>sadmax: the cookbook entry says “In the example below we [set] up a headless music server. There will be no graphical user interface, no Pulseaudio daemon, and no local audio output. Instead we will configure MPD with two outputs: a bluetooth speaker and a web server to serve audio streams to any streaming media player.”
<rekado>if you want to use a desktop environment I don’t think bluez-alsa is the correct choice
<sadmax>```(dbus-root-service-type config =>
<sadmax> (dbus-configuration (inherit config)
<sadmax> (services (list bluez-alsa))
<sadmax> ))``` works. All I need is bluetooth. I'm not going to setup or use MPD
<sadmax>I'm a little concerned I've overridden the services list in the dbus-service defined in %desktop-services.
<sadmax>In the above example can I use the the values in `config` in my `dbus-configuration` object?
<sadmax>I'd like to do something like ```(dbus-root-service-type config =>
<sadmax> (dbus-configuration (inherit config)
<sadmax> (services (cons bluez-alsa (get-services-from-config config)))
<sadmax> ))```
<sadmax>But I'm not sure how to implement the `get-services-from-config` function.
<rekado>sadmax: what I pasted above would be sufficient to extend the dbus root service
<rekado>just a single new service: (simple-service 'my-dbus-extensions dbus-root-service-type (list bluez-alsa))
<rekado>the dbus-root-service-type has an extension mechanism that will concatenate all the values provided by any extension service
<rekado>so you don’t need to take care of cons’ing or appending anything
<rekado>just define a service extension and it’ll take care of it.
<Guest74>can I use home-files-service-type with a whole directory?
<rekado>as I wrote earlier, though: bluez-alsa will not work well with a desktop environment, which likely uses pulseaudio
<sadmax>Thank you for your help rekado. It appears to be working with pulseaudio. pulsemixer even controls the volume.
<rekado>sadmax: in a desktop environment it may be sufficient to add this: (service bluetooth-service-type (bluetooth-configuration (bluez bluez) (auto-enable? auto-enable?)))
<rekado>sorry, I meant: (service bluetooth-service-type (bluetooth-configuration (bluez bluez) (auto-enable? #true)))
<rekado>this extends the dbus root service with the dbus services provided by the bluez package
<jpoiret>rekado: how would the TLS certificate setup work out in practice?
<jpoiret>I guess i can't just use `guix build` to test out some local changes with that, I'd need to push to some branch first, right?
<the_tubular>Is there binding for bash shopt ?
<Guest74>Can someone show me an example of how a type of text-config looks like?
<gnucode>Guest74: what is a text-config ?
<Guest74> I want to add my own bashrc to stop it from overwriting my ls alias
<torari>shepherd init?
<torari>i like shepherd
<torari>its cool
<jpoiret>so you're telling me I also need a i586-linux-gnu cross toolchain to build mig/32-bit to build hurd?
<bjc>litharge needs to learn how to punish exponentially
<attila_lendvai_>why is the ban soon lifted?
<jpoiret>nckx, civodul?
<jpoiret>or lilyp
<jpoiret>don't know who exactly can get op here
<jpoiret>attila_lendvai: litharge is a bot
<attila_lendvai>i know, but if someone needs banning to begin with, then why lift the ban only in a few seconds?
<jpoiret>attila_lendvai: it's not a ban, but quiet mode
<jpoiret>jess: thanks
<Guest74>thank you
<jess>nckx: soz for opping xoxo
<mirai>that doesn't look like the usual bot
<jpoiret>civodul: do you know if MiG on x86_64 can target i586? we're using a 32-bit mig to build hurd, but why doesn't gnumach also require the same?
<Guest74>jpoiret what is mig
<jpoiret>Mach Interface Generator
<civodul>jpoiret: we never really use MiG for x86_64; it's always built for i586 one way or another i think
<civodul>the cross-mig definitely targets i586-pc-gnu
<jpoiret>do you mean we always use mig/32-bit?
<jpoiret>because in the inputs of gnumach there's plain mig
<jpoiret>I was having build failures for gnumach because the static asserts were erroring out, they were trying to see if sizeof(some pointer) == 8
<jpoiret>which doesn't seem super common on 32-bit :p
<rekado>nckx: did you write this –> /etc/ssl-ca/create-cuirass-client-certificate ?
<rekado>or is this something I wrote long ago…?
<civodul>jpoiret: but i think we build gnumach with #:system "i686-linux" somehow?
<civodul>but yeah, gnumach has plain 'mig', not 'mig/32-bit'
<civodul>we must be missing something because using a 64-bit mig would most likely result in an unusable kernel
<jpoiret>i'll see if changing that solves my issue. I still have to build the i586-linux-gnu cross toolchain
<jpoiret>I'd have needed it anyways
<jess>someone ping me if the spam happens again?
<jpoiret>it's quite annoying that MiG doesn't support cross-generation. That means you can't cross-compile the hurd on anything other than x86_64 or i586?
<civodul>mig does support cross generation, that's what we're using here
<civodul>jess: sure, thank you!
<civodul>you don't need an i586-linux-gnu toolchain, too
<jpoiret>but isn't that exactly what mig/32-bit needs? it's built with #:system "i686-linux"
<jpoiret>at least my computer is building that very toolchain right now, I didn't ask for it specifically
<civodul>#:system is native compilation, not cross-compilation
<civodul>but yes, you're right; i thought you were talking about a cross-compilation toolchain
<civodul>this is confusing :-)
<jpoiret>ahhhh, so I'm just bootstrapping again the usual i586 toolchain
<jpoiret>silly me
<jpoiret>oh no, that means that it'll take wayyyy longer than I expected
<civodul>there should be substitutes though?
<jpoiret>no, because I have the glibc patches :)
<civodul>we're supposed to avoid world rebuilds at this point though
<civodul>if that's possible, that'd be great
<jpoiret>i'll just wait for gcc to finish compiling first then
<civodul>yeah, all this is tedious
<jpoiret>it's just that I'm reluctant to apply the patches only to the cross toolchain since it takes a libc variable
<jpoiret>hardwiring it in (cross-libc ...) doesn't feel nice to me, probably I could do that instead in gnu-build-system
<sleepycat>does guix work on macos?
<gnucode>sleepycat: guix assumes your OS uses glibc. It uses specific features of glibc. So if glibc has been ported to your OS, guix may be able to use it.
<gnucode>aka guix does not work on macos. :)
<sleepycat>"> brew install glibc" ... "glibc: Linux is required for this software." :(
<sleepycat>now i wonder why glibc hasn't been ported to macos
<jpoiret>that's not true I think
<jpoiret>i don't think we rely on glibc
<jpoiret>the one blocker is Linux-specific apis + macos being unbootstrappable
<jpoiret>sleepycat: porting a libc to another kernel is _very_ complicated
<jpoiret>nix has mac support, so without considering the bootstrapping issues we technically could as well
<jpoiret>but I don't think nix has any builder isolation, since mach doesn't have namespaces
<rekado>IIRC nix makes an arbitrary cut in the package graph and grafts it onto a huge binary substrate provided by macos