IRC channel logs

2024-02-20.log

back to list of logs

<dodoyada>euouae thanks, I think https://guix.gnu.org/cookbook/en/html_node/A-_0060_0060Hello-World_0027_0027-package.html is what I wanted and didn't see before
<peanuts>"A ``Hello World'' package (GNU Guix Cookbook)" https://guix.gnu.org/cookbook/en/html_node/A-_0060_0060Hello-World_0027_0027-package.html
<dodoyada>lol thanks peanuts
<peanuts>dodoyada: Hi, for comments please contact my maintainers at https://codeberg.org/lechner/irc-helper-bot
<euouae>dodoyada: great,
<euouae>AH! I made kexec workL!
<euouae>-yay-
<euouae>it was I and I only, no help whatsoever
<Kingsy>why might I get this error "error: wrong numer of arguments for action 'reconfigure'" when running guix system reconfigure ?
<euouae>Kingsy: you need to provide a system configuration
<euouae>`guix system reconfigure /etc/config.scm` or similar
<Kingsy>ah! thanks. where in the docs does it say that?
<euouae>Kingsy: <https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html>
<peanuts>"Invoking guix system (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Invoking-guix-system.html
<Kingsy>thanks
<Kingsy>ls
<Kingsy>what does guix pull actually do? I am running it for the first time and its taken literally like 15 minutes.. hah
<euouae>Kingsy: download and deploy guix distribution and package list, also updates guile modules. the result is a profile under .config/guix/current
<Kingsy>euouae: but surely it doesnt download every package? or does it? also,similar question, what does quix system reconfigure do? does that reinstall the entire os each time? (system packages are all installed again)
<Kingsy>well it worked very well! looks like reconfigure needs sudo though
<Kingsy>which I suppose makes sense. given its system level
<euouae>Kingsy: `guix system reconfigure' will upgrade system (system packages such as kernel or even emacs if declared so). sudo is important to preserve user environment
<euouae>basically downloads & installs the new kernel
<euouae>Kingsy: `guix pull` needs all packages I think. It doesn't download the packages themselves, just metadata. `guix upgrade` actually upgrades your packages (only those you have installed.) `guix system reconfigure` upgrades your kernel. Roughly speaking that's how it goes.
<Kingsy>euouae:oh good to know! reconfigure must do slightly more than the kernel, I added slim and stumpwm in there and after a reconfigure those services were installed and running. so I guess it does that too. but generally this makes sense.
<Kingsy>thanks for the info
<hako>euouae: You might be interested on this
<hako> https://issues.guix.gnu.org/68524
<hako> https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00228.html
<peanuts>"[PATCH 0/2] Support root encryption and secure boot." https://issues.guix.gnu.org/68524
<peanuts>"[RFC] proposal for refactoring bootloaders" https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00228.html
<euouae>hako: no way
<euouae>I dislike systemd : P
<euouae>but it's great that at least this solution is being put in by someone else
<euouae>also the LUKS password entry is in the initrd. What?
<euouae>doesn't that mean it's in plain sight?
<dodoyada>anybody have an example of getting eshell to have completions when using guix shell
<dodoyada>maybe this is an emacs only question, I've seen it in other sub-shells. I'll ask there
<dodoyada>omg guile-hall is awesome
<apteryx>anyone knows the right 'guix shell --container inkscape' incantation so I can use its GUI?
<podiki>try with (on X) --preserve='^DISPLAY$' "--preserve='^XAUTHORITY$'" --share=$XAUTHORITY
<dodoyada>is there a faster way to find a package's scm name than looking at the package source code?  for example, guile-json comes up as "guile-json" in package search but the name for package definitions is guile-json-4 (or whatever version) https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n638
<peanuts>"guile.scm\packages\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n638
<apteryx>dodoyada: I don't use eshell, but emacs-bash-completion is useful for M-x shell
<mange>I don't know a faster way than looking at the source code, but "guix edit guile-json" will take you straight to the right place at least.
<dodoyada>apteryx maybe I already have emacs-bash-completion, it does work in shell mode
<apteryx>'guix package -I emacs-bash-completion' can confirm that
<dodoyada>apteryx I don't but it works
<apteryx>OK; maybe Emacs has improved something or has bundled it since
<apteryx>why aren't the RUNPATH correctly baked in libtool libraries?
<euouae>apteryx: what do you mean?
<euouae>should work if you use libtool
<oriansj>I am getting this error: "error: service 'ntpd' requires 'networking', which is not provided by any service"; but I have iwd-shepherd-service in my configuration.
<hako>oriansj: Does this 'iwd-shepherd-service' have 'network in its provision field?
<hako>'networking, sorry
<oriansj>not but easy to fix
<dodoyada>sorry I couldn't find how to link this, but shouldn't L436 of (gnu home services shells) put aliases after default bashrc content?  (if (home-bash-configuration-guix-defaults? config)
<dodoyada>                  (list (serialize-field 'aliases)
<dodoyada>                        (plain-file-content %default-bashrc))
<dodoyada>                  (list (serialize-field 'aliases)))
<dodoyada>so that users can override aliases for ls or whatever else without needing to disable guix-defaults?
<oriansj>hako: looks like that fixed it, thank you
<euouae>dodoyada: override how?
<dodoyada>like (simple-service 'custom-bash-service
<dodoyada>                   home-bash-service-type
<dodoyada>                   (home-bash-extension
<dodoyada>                    (aliases
<dodoyada>                     '(("python" . "python3")
<dodoyada>                       ("grep" . "grep --color=auto")
<dodoyada>                       ("ls" . "ls -pl --color=auto")))))
<euouae>dodoyada: You should not paste more than 2 line into IRC
<dodoyada>the resulting .bashrc has the user defined aliases above the guix-defaults aliases so ls can't be aliased
<euouae>Use a pastebin like <https://paste.debian.net>
<dodoyada>oh sorry
<peanuts>"Debian Pastezone" https://paste.debian.net
<dodoyada> https://paste.debian.net/1307895/
<peanuts>"debian Pastezone" https://paste.debian.net/1307895
<euouae>I'm not familiar with home-bash-extension
<dodoyada> https://guix.gnu.org/manual/en/html_node/Shells-Home-Services.html
<peanuts>"Shells Home Services (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Shells-Home-Services.html
<euouae>dodoyada: okay so what is the problem exactly if you use both at the same time?
<dodoyada>both aliases?  when you have `alias ls="ls -pl --color=auto"` at the top and `alias ls='ls -p --color=auto'` at the bottom of .bashrc only the bottom results
<dodoyada>I tried showing a complete example but am rate limited by pastebin
<euouae>you're saying the defaults override user specifics?
<dodoyada>yes
<dodoyada>only if you have an alias named ls, ll, grep, or ip
<euouae>dodoyada: <https://issues.guix.gnu.org/67652>
<peanuts>"Guix home - bash alias declarations order" https://issues.guix.gnu.org/67652
<euouae>It seems that you're right. The issue is "Open" but "Christian Miller" posted a workaround
<euouae>dodoyada: Do you want to contribute to Guix?
<euouae>If you have a solution. Right now my brain is fried and I can't think straight to try to fix -- or even understand -- this myself
<dodoyada>euouae yes!  I can't do it tonight but I know where the code needs to change and would just need to get up to speed on the contribution process (I see https://guix.gnu.org/en/contribute/)
<euouae>awesome dodoyada thank you
<dodoyada>I'm fairly certain it's just a matter of swapping https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shells.scm#n432 and 433, I'll try it when I get a good chunk of time
<peanuts>"shells.scm\services\home\gnu - guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shells.scm#n432
<sham1>What's the canonical way to have a package with an input that's a certain version?
<sham1>Like how do I specify that the package has to have a certain version
<efraim>cbaines: I got a 504 error fetching from git.guix-patches.cbaines.net, and I noticed that the rust-team branch hasn't been processed yet.
<efraim>also thank you for all the work you do on the QA side of things!
<efraim>apteryx: I built rust-1.73 on rust-team with mold-as-ld-wrapper, checked the cargo binary and it says it used mold. 7 minutes 20 seconds to build, going to time test it against not using mold
<efraim>looks like cargo used mold but rustc didn't
<efraim>7 minutes 33 seconds without mold
<ayatsfer>hello, I am trying to get a shell (specifications->manifest + guix shell -m) for rust dev
<ulfvonbelow>I'm finding cargo-build-system quite difficult to work with. If I understand correctly, for the most part, the part of each "crate" package that actually matters to other "crates" is the source. Building a crate consists of copying the source for that crate, and all of its dependencies, recursively, and doing whatever the source Cargo.toml says to do for the build for every one of those (with no opportunity to modify build phases,
<ulfvonbelow>substitute paths, etc). So if rust-foo-0.1 requires some special handling before or after its build, that needs to be done in rust-foo-0.1, and also copied into every rust package that uses rust-foo-0.1, and every rust package that uses those packages, and so on.
<ayatsfer>one of the deps is libffi, which doesn't build because it can't find libclang.so, how should I proceed?
<ulfvonbelow>this also means that the native inputs necessary for building rust-foo-0.1 are also necessary for building all of its dependents
<efraim>ayatsfer: the short version is libclang.so is in clang. can you add it to the manifest? or add it before the -m?
<efraim>ulfvonbelow: you're using the cargo-build-system and cargo-inputs and cargo-development-inputs, right? also, for the rust crates we generally try to put the changes into a patch or a snippet for the affected crate so that it carrys through to all the other packages which depend on it
<ulfvonbelow>to make matters worse, every rust package *must* have a tarball source, so we can't even patch paths at the source level
<ulfvonbelow>efraim: indeed I am
<efraim>also I'd suggest working against the rust-team branch, which should be merged into master soon (i hope)
<efraim>it should be possible to patch dependant crates before the 'configure phase
<ayatsfer>efraim: yes, I have added clang to the manifest: https://gitlab.inria.fr/fayatsll/mpi-heat/-/blob/master/shell.scm?ref_type=heads
<peanuts>"shell.scm ? master ? Fernando Ayats / mpi-heat ? GitLab" https://gitlab.inria.fr/fayatsll/mpi-heat/-/blob/master/shell.scm?ref_type=heads
<ayatsfer>the exact error says:
<ayatsfer>Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-_.so', 'libclang.so._', 'libclang-_.so._'], set the "LIBCLANG_PATH" environment variable to a path where one of these files can be found (invalid: [])"
<ayatsfer>LIBCLANG_PATH is not exported, maybe I need it?
<efraim>probably would help. the cargo-build-system it seems always exports LIBCLANG_PATH when clang is an input
<efraim>(setenv "LIBCLANG_PATH" (string-append (assoc-ref inputs "clang") "/lib")))
<ulfvonbelow>not sure what you mean by "patch dependent crates"
<efraim>I suppose that could be $GUIX_ENVIRONMENT/lib inside a guix shell
<ulfvonbelow>do you mean substitute files in guix-vendor/rust-blablah-0.1.tar.gz/?
<efraim>yes, that's what I was about to write
<ulfvonbelow>that can certainly be done, and then done again, and then done again... for every dependent package
<ayatsfer>efraim: what is inputs in this context?
<efraim>unless you can patch rust-blabla-0.1''s source, in which case you won't need to patch it in all the builds
<efraim>ayatsfer: package inputs, from a package definition. from the CLI with your manifest it should work with 'export LIBCLANG_PATH = $GUIX_ENVIRONMENT/lib' or something like that
<ayatsfer>ah, I see
<ulfvonbelow>I wish cargo-build-system worked more like installing header-only libraries
<ayatsfer>perhaps it would be better to do a package the definition for the app, instead of using specifications->manifest + manually exporting things (?)
<efraim>that's what I normally end up doing, but it depends if you want to do some by-hand building during development or just have it build in the build environment
<ayatsfer>what I've been doing in nix is just declaring the deps in a nixfile (be it a plain shell or a package), and within the shell use cargo build. If I need to distribute it, then with nix/guix build (?)
<efraim>I've never used nix, but 'guix pack' should help with distributing a compiled package
<ayatsfer>what would be the (source) field be if the scm lives in the same repo? (Or in this case, I only needs the deps for build in a shell, so don't really care for that)
<ulfvonbelow>(local-file "." #:recursive? #t) maybe?
<efraim> https://git.sr.ht/~efraim/guix.vim/tree/master/item/guix.scm here's what I use as a template for a guix.scm file. it strips out the .git folder and the guix.scm file itself
<peanuts>"~efraim/guix.vim (master): guix.scm - sourcehut git" https://git.sr.ht/~efraim/guix.vim/tree/master/item/guix.scm
<hako>What happened to https://git.savannah.gnu.org/cgit/guix.git/ ?
<peanuts>"guix.git - Documents and web site of bootstrappable.org" https://git.savannah.gnu.org/cgit/guix.git
<futurile>morning all
<efraim>o/
<efraim>hako: no idea, but I think it's just a display error
<ayatsfer>efraim: thanks for that, trying right now..
<ayatsfer>though perhaps it would be nice to have this "local clean source" in guix itself :)
<ayatsfer>doesn't work yet, same error...
<ayatsfer> https://gitlab.inria.fr/fayatsll/mpi-heat/-/blob/master/package.scm
<peanuts>"package.scm ? master ? Fernando Ayats / mpi-heat ? GitLab" https://gitlab.inria.fr/fayatsll/mpi-heat/-/blob/master/package.scm
<ayatsfer>(with guix shell -D -f ./package.scm)
<efraim>ayatsfer: try exporting CC=gcc also
<ayatsfer>yeah, I've been doing that manually
<efraim>`CC=gcc LIBCLANG_PATH=$GUIX_ENVIRONMENT/lib cargo build` worked for me
<ayatsfer>shouldn't LIBCLANG_PATH be exported automatically?
<efraim>it probably searches for /usr/lib/libclang.so
<ayatsfer>I'm on nixos, so no /usr/lib :)
<ayatsfer>I guess LIBCLANG_PATH is exported within the rust builder but not with guix shell -D ?
<efraim>I'm on guix system, also no /usr/lib
<efraim>yeah
<erikeah>Good morning everyone!
<efraim>o/
<ayatsfer>gm
<ayatsfer>efraim: should I file a bug to keep track of this?
<erikeah>I'm following this article https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/ and tried a simple guix.scm, but once I get inside the guix shell the package is not available from shell, Am i missing something?
<efraim>it might be worth asking the authors how they find libclang but I'm not sure what I'd write in a bug report against guix, except 'not working as expected'
<efraim>I found the spot in clang-sys, it should call llvm-config from $PATH on its own, so not sure what's up with that
<yelninei>hey, is it possible to set a default value for a configuration to a gexp (that will evaluate to a string).
<erikeah>I would like to share my simple guix.scm but I dont know which code sharing tool is preferred in this community
<erikeah>May some could help me
<janneke>erikeah: see /topic :)
<erikeah>janneke: thanks!
<ayatsfer>efraim: then the plot thickens
<yelninei>nvm, i can just set the field to gexp and it doesn't complain
<erikeah>well this is my guix.scm https://paste.debian.net/1307913/, once I place it on my directory and run guix shell, it gets into the shell but the protoc binary is not available
<peanuts>"debian Pastezone" https://paste.debian.net/1307913
<janneke>erikeah: guix shell (with the implicit -D -f guix.scm) sets up a development environment for the package returned by guix.scm
<janneke>to get a shell with a built version of <package>, run guix shell <package>
<janneke>what are you trying to do?
<rekado>the cuirass hook at /jobset/guix/hook/evaluate returns 500
<civodul>d’oh
<rekado>(write (jobset-last-update-times hurd-packages) #<input?>)
<rekado>and (write (trigger-jobset master) #<input-output: socket 43>)
<rekado>they both fail with “Broken pipe”
<civodul>right
<civodul>i restarted ‘cuirass-web’ and it’s fixed
<civodul>looks like ‘cuirass-web’ got disconnected from the ‘cuirass register’ socket somehow
<civodul>there’s no attempt to reconnect in that case because it’s Not Supposed to Happen
<ayatsfer>guix shell --search-paths description states "display needed environment variable definitions", yet it doesn't export GUIX_ENVIRONMENT (which is exported without --search-paths). Should this be revised?
<rekado>civodul: thanks
<rekado>ayatsfer: the search paths are determined by the software that ends up in the profile/environment. GUIX_ENVIRONMENT is merely a convenience variable pointing to the temporary profile location.
<rekado>it’s not a variable that is needed by any of the software installed in the profile.
<rekado>so I think it’s fine that it doesn’t appear in “guix shell --search-paths”
<ayatsfer>yeah, it makes sense
<civodul>also, ‘--search-paths’ is more of a debugging aid or low-level plumbing tool than an interface one would “normally use”
<civodul>heya ayatsfer :-)
<ayatsfer>and is it possible to build/print GUIX_ENVIRONMENT from the cli for automation?
<ayatsfer>> also, ‘--search-paths’ is more of a debugging aid
<ayatsfer>> I am used to nix+direnv (https://direnv.net), and direnv's guix implementation is to use guix shell --search-paths, so yeah..
<peanuts>"direnv ? unclutter your .profile | direnv" https://direnv.net
<janneke>ACTION also uses guix shell --search-paths in .envrc
<janneke>well, eval $(guix shell --search-paths)
<ayatsfer>the usecase is getting GUIX_ENVIRONMENT to export LIBCLANG_PATH (previous conversation). For now I can do GUIX_ENVIRONMENT=$(dirname $(dirname $(which gcc))) ...
<ayatsfer>(within direnv)
<erikeah>janneke: thanks I'm trying to create the development environment, I think I didnt catch the main purpose of guix.scm
<civodul>ayatsfer: you could always do: guix shell … -- /bin/sh -c 'echo $GUIX_ENVIRONMENT'
<civodul>not ideal i guess
<erikeah>I thought the package definition was need to define which packages are needed to install on the shell but literrally is defining a package and the dependecies will be installed
<ayatsfer>the current state of my direnv hack: https://gitlab.inria.fr/fayatsll/mpi-heat/-/blob/776f1635e35671f9ceff27ea6b42093a4ac081d5/.envrc
<peanuts>".envrc ? 776f1635e35671f9ceff27ea6b42093a4ac081d5 ? Fernando Ayats / mpi-heat ? GitLab" https://gitlab.inria.fr/fayatsll/mpi-heat/-/blob/776f1635e35671f9ceff27ea6b42093a4ac081d5/.envrc
<rekado>does anyone have an emscripten toolchain package?
<rekado>I need it for finally being able to move the r-diagrammer package from Guix Science to Guix proper.
<rekado>it bundles graphviz compiled to JavaScript via emscripten.
<civodul>woow, impressive, when you think about it
<civodul>ACTION doesn’t have an emscripten package
<BlueTemplar>hello shining light in the gloom, how haven't I heard of you before ? :D
<civodul>poetry :-)
<BlueTemplar>so, uh, is it a good idea to try to replace Ubuntu on a split Win7/Ubuntu SSD, or should I just get a new, separate SSD instead ? (I heard Guix doesn't work *that* well with GRUB ?)
<rekado>I heard Guix System works excellently with Grub, because that’s what it uses to allow for booting older generations of the system ;)
<BlueTemplar>ah, maybe that person was mistaken then (I wanted to check beforehand since getting a new SSD isn't an immediate affair)
<rekado>the manual documents in “11.14 Bootloader Configuration” how you can add extra menu entries to GRUB in a declarative fashion.
<BlueTemplar>OTOH maybe I should buy a new one anyway, that way I don't have to shudder about thinking about having to completely reinstall Win7 in case I make some big mistake...
<rekado>BlueTemplar: yes, it’s not a bad idea.
<rekado>gives you peace of mind when playing with a system you aren’t yet familiar with.
<BlueTemplar>but thanks about the manual reference
<BlueTemplar>oh, anything I should be wary about in terms of Guix-SSD (in)compatibility ?
<janneke>BlueTemplar: no, I haven't encountered SSD disks that need proprietary firmware
<chsasank>Any guidance on hosting a mirror? I am getting very very bad speeds (~50kb/s) from EU servers and I live in India. How do I host my own mirror?
<chsasank>This slow download is a complete deal breaker because UX is really bad :(
<BlueTemplar>thx
<rekado>chsasank: I’ll just note that speed from AWS EC2 instances is really quite good. If you intend to not host the mirror yourself and cost of AWS ingress/egress is not an issue this could be an option for you.
<chsasank>rekado: I can host bare metal on some server I have assuming the data is not too big. How big are the mirrors?
<rekado>we don’t actually have any mirrors. The servers behind ci.guix.gnu.org are not just passively hosting binaries.
<rekado>a mirror would have to host the “guix publish” caches and serve them via “guix publish”
<chsasank>So when guix is downloading something, what is it doing?
<rekado>just checked: the “guix publish” cache on ci.guix.gnu.org is 19TB.
<chsasank>similar issue: https://issues.guix.gnu.org/46942
<peanuts>"ci.guix.gnu.org is slow from my system" https://issues.guix.gnu.org/46942
<rekado>this includes gzip, lzip, and zstd-compressed files.
<janneke>(and all architectures, i figure)
<chsasank>19TB is a lot! Not gonna get there
<chsasank>I only want things for my architecture and even there specific packages
<BlueTemplar>I'm reading about disks, and Seagate is about to start selling HAMR-based 24 to 32 Go drives
<BlueTemplar>*HDD
<BlueTemplar>with plans for 40 and then 50 To in the next years
<rekado>chsasank: the zstd-compressed stuff is “only” 4.4TB
<chsasank>rekado: if this is so, how do I maintain my own `guix publish` caches?
<chsasank>rekado: may be I can pick and choose the packages I want?
<Kingsy>how can I search for a file in a package rather than the package itself?
<rekado>chsasank: that’s probably not easy.
<rekado>Kingsy: you can use “guix locate”
<rekado>chsasank: we used to share the cache via rsync daemon, but I don’t know what the current status is.
<chsasank>how do I run simple cache server? I don't mind building packages I care and pushing them there
<rekado>we don’t push any build results anywhere
<rekado>the build farms are regular Guix users
<rekado>any Guix user can run “guix publish” to share the contents of their own /gnu/store
<chsasank>ok, they have to share packages explicitly right
<rekado>that (with some optimizations) is hwat the build farms do.
<janneke>ChanServ: possibly you want to run an offload/build server
<janneke>and add it as a substitute server
<janneke>at least, that's what I do
<chsasank>that's exactly my plan. Right now I am the only user, but I am looking to scale that up
<rekado>chsasank: you could run cuirass and have it build only things from a manifest
<rekado>it could still use the existing build farms as substitute servers
<rekado>so you don’t needlessly rebuild *everything*
<chsasank>correct, but 'mirror
<chsasank>'mirror' is just nginx static file server?
<Kingsy>rekado: thanks
<oriansj>build of /gnu/store/rh6rzc69b7b3hn0by6wn7y8gsvrbbysd-linux-libre-documentation-6.6.16.drv failed
<nckx>oriansj: Cherry-pick the fix from the kernel-updates branch.
<oriansj> https://paste.debian.net/1307933/
<peanuts>"debian Pastezone" https://paste.debian.net/1307933
<oriansj>nckx: ok, how does one do that in guix?
<nckx>In my case, run git cherry-pick in ~/guix which is where my channels.scm points 🤷
<isaneran>hello guix!
<nckx>chsasank: Which mirror are you talking about (that's a simple nginx server)?
<nckx>Hi isaneran.
<chsasank>nckx: I am talking about substitute servers. They are really slow to access from India
<oriansj>nckx: got it make a local channel, then select different commit
<nckx>oriansj: I don't know whether kernel-updates itself is based on a recent or old commit that's missing other interesting updates, but yes, that's the gist.
<nckx>Otherwise I'd dare recommend ’guix pull --branch=kernel-updates’ but I don't.
<nckx>chsasank: There's a (possibly incomplete) list of other servers at <https://libreplanet.org/wiki/Group:Guix/Mirrors>. Maybe one of those is acceptable?
<peanuts>"Group:Guix/Mirrors - LibrePlanet" https://libreplanet.org/wiki/Group:Guix/Mirrors
<chsasank>I tried singapore one, it's slow too :(
<nckx>It's not impossible to mirror Guix substitutes as static files, but I don't think it's trivial and I don't have a step-by-step guide.
<nckx>At least the SJTUG one use{s,d} a custom software solution for that reason.
<nckx>[…slow, plodding thinking sounds…] I don't want to step on any toes, but why is a commit that fixes a build failure on master taking a leisurely detour through kernel-updates in the first place? I can't think of a good reason.
<cbaines>chsasank, could you try testing the signapore mirror again and see what speeds you get?
<chsasank>Sure, I'll try and report back
<cbaines>the setup of the bordeaux mirrors is pretty simple, it uses the nar-herder plus NGinx, with NGinx taking care of the caching
<cbaines>I don't think I've posted the config anywhere, but I'm happy to share it
<cbaines>chsasank, I'm hosting the singapore mirror using a Vultr VM, so they also have some test data you can use https://www.vultr.com/features/datacenter-locations/
<cbaines>so you could check what speeds you get to the their different data centers, including the ones in India
<chsasank>here's ExecStart from my guix-daemon.service: ExecStart=/usr/bin/guix-daemon --build-users-group=_guixbuild --substitute-urls='https://bordeaux-singapore-mirror.cbaines.net'
<peanuts>"bordeaux-singapore-mirror.cbaines.net" https://bordeaux-singapore-mirror.cbaines.net
<cbaines>passing --substitute-urls= on the command line (e.g. to guix build) should work fine for testing, you don't necessarily need to change the daemon default
<chsasank>this is what instructions showed in docs, so did it
<chsasank>trying guix install emacs, guix is updating itself first I guess. Taking time.
<PotentialUser-99>hi
<cbaines>chsasank, for testing, you could just try: guix build /gnu/store/kw8kv1bwhmfnc4qb9mhf51i1agix04dg-emacs-29.1
<chsasank>is guix always this slow? I am not even sure what it's doing :(
<chsasank>when it's downloading I see 5 MB/s!
<cbaines>note that the speeds you see for small downloads might not be that representative
<chsasank>fair, I should try installing a big package
<PotentialUser-99>I'm trying guix build for the first time and hitting an error with openssl
<cbaines>if you want something big to test, you can try: guix build /gnu/store/8yh8wasjql1sdad9g3g24p7pypzl9l4v-0ad-data-0.0.26-alpha
<cbaines>(that's 1.2G)
<PotentialUser-99>It starts the build fine and then it hits this error
<PotentialUser-99>crypto/bn/asm/x86_64-gcc.c:78:17: error: expected ')' before ':' token
<PotentialUser-99>   78 | : "=a"(low),"=d"(high) \
<PotentialUser-99>what module do I need to install in order to get openssl successful compiled?
<PotentialUser-99>on debian/ubuntu I simply do apt install libssl-dev
<Kingsy>so just out of curiousity. to leverage the power that the config.scm gives you. should you not just ALWAYS install packages using this file? so you can record the state of your system for future builds?
<chsasank>cbaines: can I try in a new terminal or do I have to wait like how apt-get makes me wait?
<elb>chsasank: guix pull and package updates after a pull are frequently very slow in my experience, yes; a pull on a system that has not pulled for a long time can take many minutes
<cbaines>chsasank, no need to wait, you can run multiple guix commands at once
<chsasank>it's only been 8 days according to logs guix install: warning: Your Guix installation is 8 days old.
<elb>chsasank: once the packages you are using are in your store, guix operations are _very_ fast, typically; for example, if you use guix shell with a set of packages, the first time you do that after a guix pull will take many seconds, but the second time will be almost instantaneous
<cbaines>(some commands that alter the same profile may need to run one after the other though)
<chsasank>@eb: most of the time seems to be going into 'check' phase
<elb>occasionally you'll hit a package that doesn't yet have a substitute and that can slow things down a lot, depending on how many dependencies it has, how long it takes to build, etc.
<cbaines>chsasank, if you're building things from source, then that can be slow
<elb>oh, yeah, or if you don't have substitutes configured!
<chsasank>guix build command you shared is not doing anything
<cbaines>chsasank, it's possible you haven't enabled substitutes from bordeaux
<elb>if you check top, are the guix build servers doing anything?
<cbaines>is the key given on https://bordeaux.guix.gnu.org/ included in your ACL (/etc/guix/acl)?
<peanuts>"bordeaux.guix.gnu.org Build farm" https://bordeaux.guix.gnu.org
<Kingsy>oh and guix home. so with the mixture of guix home and guix system, surely its bad practice to ever run guix install?
<chsasank>I think they are building yeah . all cpus are full.
<chsasank>Am I doing something wrong with my daemon script?
<nckx>PotentialUser-99: What exactly is the command that fails? Installed packages don't affect builds.
<cbaines>if you're unsure about the ACL chsasank, there's some documentation here https://guix.gnu.org/manual/en/html_node/Substitute-Server-Authorization.html
<peanuts>"Substitute Server Authorization (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/Substitute-Server-Authorization.html
<chsasank>how do I find my prefix
<cbaines>chsasank, if you've done guix pull, then try using ~/.config/guix/current/
<cbaines>otherwise it'll depend on how you've installed guix I think
<chsasank>found it! it's in ~/.config/guix/current
<chsasank>since sg one is bordeaux mirror I have to use guix archive --authorize < ~/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub ?
<cbaines>yep
<chsasank>I get this error: guix archive: error: mkstemp: Permission denied
<nckx>sudo guix archive …
<chsasank>I shouldn't have to use sudo right?
<chsasank>why sudo?
<nckx>Because setting trust for all system users must be done as root.
<chsasank>got it, finally it's downloading from sg mirror! Getting 10 MB/s!
<chsasank>No need to mirror! Yayyyyyy
<chsasank>thanks a lot folks. Sorry for all the noob questions
<nckx>If a user authorises a malicious substitute server (they presumably control), they could have it respond to Guix's ‘please give me icecat!’ with any arbitrary binary.
<nckx>Which would affect all system users since the store is shared.
<chsasank>So the authorization of the mirror was the issue
<nckx>I thought Guix warned about this.
<chsasank>It didn't :(
<chsasank>Instead of downloading, it was just building everything
<nckx>ACTION boos.
<cbaines>I think commands like guix weather might now warn
<cbaines>did you use the shell script installer chsasank?
<chsasank>I used apt-get install guix
<chsasank>Do I have to always do this guix authorize whenever I install?
<rekado>chsasank: you do this once.
<rekado>it modifies /etc/guix/acl
<cbaines>nope, and I'm also not sure why bordeaux wasn't authorized by default
<chsasank>I mean whenever I install guix
<cbaines>assuming you enabled "default" substitutes at some point
<chsasank>I just did apt-get install and changed the service file
<cbaines>chsasank, what version of Guix did apt install?
<chsasank>unfortunately guix doesn't seem to be working from distrobox, I would've reproduced otherwise
<chsasank>apt info guix shows 1.3.0-4
<cbaines>ah, I'm not sure the key for bordeaux was included in the 1.3.0 release
<chsasank>oh that was the issue all along then.
<chsasank>recommended way to install is through shell script?
<chsasank>btw I am using distrobox as my makeshift guix environments until I figured the mirror issue out
<chsasank>distrobox is pretty amazing for that
<nckx><recommended way to install is through shell script?> Yes.
<chsasank>ok thanks.
<chsasank>is there a way in which I can mix and match debian packages with guix?
<nckx>IWBN if it wasn't, but it is.
<chsasank>ok
<chsasank>I wanna do something like this but for intel gpus: https://hpc.guix.info/blog/2024/01/hip-and-rocm-come-to-guix/
<chsasank>is this the right channel for hpc packaging? Also it might have some non-free components (usually blas libraries)
<cbaines>one point on the guix-daemon arguments chsasank, I'd recommend listing all substitute servers you want to use, in order that you wish to use them
<jpoiret>chsasank: there's the #guix-hpc channel iirc
<nckx>chsasank: There's a #guix-hpc channel but IMO it's better to discuss the packaging here, since the audience is larger and most questions won't be HPC-specific.
<cbaines>e.g. "--substitute-urls=https://bordeaux-singapore-mirror.cbaines.net https://bordeaux.guix.gnu.org https://ci.guix.gnu.org"
<peanuts>"bordeaux-singapore-mirror.cbaines.net" https://bordeaux-singapore-mirror.cbaines.net
<peanuts>"bordeaux.guix.gnu.org Build farm" https://bordeaux.guix.gnu.org
<peanuts>"Cuirass" https://ci.guix.gnu.org
<nckx>chsasank: Also, #guix-hpc does not treat proprietary software differently than #guix.
<cbaines>that way you should get substitutes even if the singapore mirror is down
<chsasank>Got it, I put it originally that way, but was getting slow speeds - so removed everything except sg one to test it out
<chsasank>nckx: got it
<Kingsy>did anyone see my question? just looking for some advice
<chsasank>nckx: it looks like even rocm in guix doesn't provide blas libs yet: https://hpc.guix.info/blog/2024/01/hip-and-rocm-come-to-guix/. Very likely because the kernels are likely not opensource,.
<janneke>Kingsy: yes, i guess
<janneke>ACTION trying to be just about as vague as the original "question" ;)
<Kingsy>how is the question vague? I am asking what is best practice? guix install or guix reconfigure using home / system (sorry I am new to this system)
<Kingsy>janneke: ^
<elb>they're not mutually incompatible
<Altadil>Kingsy: personnaly, I use guix home and guix install, in order to separate software I use "normally" and software I just want to try out. So I guess both can be used together, it’s just a personal preference of how you want to organize things.
<elb>there may be times that you absolutely want a completely declarative configuration, in which case you want to avoid guix install, but at other times it's just fine to use imperative configuration
<elb>I personally do not use guix home, but I also don't use guix install; I maintain a directory ~/.guix-local with some manifests and configuration files that are sourced on login, and if I want to install a package I add it to a manifest there and rebuild the appropriate package directories
<elb>I have a base manifest that's installed on all of my systems, and then a system-specific manifest that goes with a particular hostname, and then some task-specific manifests
<Kingsy>yeahn makes sense. I feel like its a big benefit having a declarative config. so I might try and use this
<elb>if I want to try out a package, I use guix shell, and if I decide I want to add it to my repertoire, I put it in the appropriate manifest and rebuild
<Kingsy>well I am super new to this. so as long as its not horrendous practice I might stay away from guix install and use a scm for everything I can
<Kingsy>but yeah apart from just trying stuff
<elb>there's nothing at all wrong with never using guix install
<Kingsy>another question, if I install a load of crap I no longer want with guix install (outside of guix shell) so on my base system. how do I remove it? will it vanish afgter a reconfigure? or do I need to just list-installed and remove them? how can I clean things up I suppose is what I am asking
<Altadil>Kingsy: list-installed and remove will work just fine :)
<Kingsy>then guix gc or something?
<rekado>for stuff that I don’t care to keep permanently I use “guix shell”.
<rekado>I only use guix home for things I need all the time (or may need at a whim)
<Kingsy>what choices do I have to launch my X window manager? I can only see slim, gdm, lightdm. any alternatives? greetd seems to just be for wayland
<sham1>sddm, but that's about it
<Kingsy>:( I don't want these fancy GUI things... but ok
<Kingsy>ideally I just want to launch a tty and just run startx, but thats not possible either I hear
<ieure>Hold up, why's that impossible? I haven't done it myself, but I believe it's very possible.
<ieure>Kingsy, Have you put xorg-server in your system package list & startx in your profile? That should give you getty login / startx for X session, no?
<Kingsy>ieure: sorry wasnt I talking to you yesterday about this and you said it was not possible? haha perhaps it was someone else.
<Kingsy>I will try it later then! I need to clean up my config anyways
<ieure>Kingsy, We were talking, I never said anything remotely like that. I told you to do the same thing as I'm saying now.
<Kingsy>haha then I totally misunderstood
<sham1>With `xorg-start-command`, you can do that, but then you'll have to somehow get that done
<Kingsy>I'll have a go!
<Kingsy>sham1: well if I can get this done with startx then I am happy really.
<lispmacs[work]>hi, I installed a 20GB guix image I made onto a computer, with a boot partition and a root partition. Now I need to resize the root partition. Somebody here suggested I should be able to do this live using gparted. However, gparted is telling me (rather mysteriously) that /dev/sda2 is a read-only filesystem. It will not allow me, of course, to unmount the file system since it is in use
<lispmacs[work]>wondering if I'm going to have to make a live CD or something to resize it offline, or if there is some other trick here
<Kingsy>lispmacs[work]: yeah I would boot into a live image so its not mounted and do it there. I don't think its possible any other way
<apteryx>efraim: inkscape takes 30 s less to build with mold; uses a bit more memory to link (2.1 GiB vs 1.4 GiB)
<isaneran>oo
<isaneran>is inkscape getting updated=
<apteryx>I guess we should prioritize going to binutils 2.42, which has improved ld performance
<apteryx>(c.f. https://yt.artemislena.eu/watch?v=h5pXt_YCwkU)
<efraim>in rust only some of the executables are linked with mold but I didn't look too closely
<peanuts>"Michael Matz Speeding up the BFD linker - Invidious" https://yt.artemislena.eu/watch?v=h5pXt_YCwkU
<efraim>my powerpc machine ran OOM while linking mold itself
<apteryx>isaneran: I did update it to 1.3.2 on core-updates (not pushed yet)
<efraim>now I'm looking through the debian sources for the magic flag to add to decrease memory pressure while linking
<apteryx>I'm still fighting with libtool shenanighans (it doesn't seem to cause RUNPATHs to be baked in the library it produces, so removing .la causes underlinking problems)
<efraim>that seems worse than overlinking
<apteryx>I guess it doesn't make use of --enable-new-dtags or something
<efraim>did we fix the issue with making ld.so.cache on i686 for llvm-15+?
<efraim>found it in the debian-mips mailing list! --param ggc-min-expand=10
<apteryx>here's the ld-wrapper debug output: https://paste.debian.net/1307953/
<peanuts>"debian Pastezone" https://paste.debian.net/1307953
<apteryx>efraim: what's hat param for?
<apteryx>that*
<isaneran>apteryx: ah ok! awesome, thanks for putting in the work
<efraim>limits memory during linking IIRC, set for C(XX)?FLAGS
<efraim> https://lists.debian.org/debian-mips/2022/09/msg00004.html
<peanuts>"Re: Do you see any chance to fix the "virtual memory exhausted" for nheko on mipsel VM" https://lists.debian.org/debian-mips/2022/09/msg00004.html
<lispmacs[work]>Kingsy: hi, I have a guix installation usb handy, so I am trying to resize the partition using parted, from the command line. but something confusing me is that parted only shows /dev/sda as being 30GB in size, and if I try to resize partition 2 any larger than that, it says I can't
<lispmacs[work]>the hard disk is a 128GB disk
<apteryx>efraim: oh!
<lispmacs[work]>oh, wait, sda here is pointing to the usb stick
<lispmacs[work]>the hard disk is not even showing up under /dev
<lispmacs[work]>that is weird. I'm not sure what to do if the hard disk dev doesn't appear
<ieure>lispmacs[work], Can you see it with lsblk?
<lispmacs[work]>ieure: no
<apteryx>how is new-dtags enabled globally in Guix?
<lispmacs[work]>some driver I'm supposed to load first/
<lispmacs[work]>?
<ieure>lispmacs[work], That's definitely weird. Are you using an encrypted root FS?
<lispmacs[work]>no
<apteryx>ah, on binutwils: "--enable-new-dtags"
<lispmacs[work]>I'll reboot and see if the disk is still working
<dariqq>is there a reason why /var/lib/gdm is mounted as tmpfs? This will make the accessibiltiy settings not persist through reboots. Is this intended?
<apteryx>dariqq: it's to workaround state that can become messed up when stopping to use the gdm service and restarting to use it again (wrong user ids)
<ieure>lispmacs[work], No idea then. Maybe check dmesg? It should show up with lsblk. Drivers for most common disk types (NVMe, SATA) are built in to the kernel. I assume you don't have some kind of exotic setup here.
<apteryx>it could be made unnecessary if the root cause was fixed instead (user ids should never change)
<lispmacs[work]>ieure: disk is not booting up now. Maybe a cable got loose or something, will check...
<marcc>Any examples of adding make flags and install phase flags for guix package?
<marcc>Are there any examples*
<lispmacs[work]>ieure: BIOS can't see disk anymore. weird, it was just working ten minutes ago
<lispmacs[work]>tried reseating the cable
<ieure>lispmacs[work], Hopefully you don't have to resize the disk by buying a larger one!
<marcc>I would basically like to add the equivalent of installPhase in nix package
<iK0u>Hi everyone
<rekado>marcc: there are countless examples throughout gnu/packages.
<rekado>marcc: depends a bit on the build system, though.
<iK0u>I cannot figure this out, when I build the install iso on two different computers with the same commit I get different derivations, even though I am trying to do the same thing
<dariqq>apteryx: i see. The 'problem' is that dconf stores the accessibilty settings there (in /var/lib/gdm/.config/dconf) so people using them would need to reenable them on every boot which is annoying
<iK0u>I use the commit source, cd into it, and run guix system image -t iso9660 gnu/system/install.scm
<iK0u>expecting same derivation at least, no its different on both devices, does anyone have any clues?
<iK0u>Been scouring the documentation I dont see anything for this problem
<apteryx>dariqq: I see. There was an issue about making user ids created by Guix deterministic
<apteryx>can't find it anymore
<apteryx>dariqq: thanks for working on that!
<apteryx>(the GDM accessibility problems)
<dariqq>i was just a bit too annoyed by the missing icon and then by the missing functionality and had some time to look into it :)
<dariqq>iK0u: do you also build the source or are you using your system guix to build the iso?
<iK0u>dariqq No, I have the substitute server enabled, and I am just cd'ing into that source directory which I downloaded from the same commit and ran the above command
<iK0u>I have also made sure to guix pull the commit
<iK0u>Both devices are using the substitute server, would building everything from source be better?
<iK0u>I have also tried many different versions of the command and I can't get the same derivation as the install iso for that commit from cuirass either
<iK0u>I am not sure what command is being used to generate the official iso, but because I cannot even get the same derivation on two different devices with same method I think I am doing something wrong
<apteryx>dariqq: the blank menu gave the desktop experience a poor first impression, so I'm happy it's getting resolved
<iK0u> https://ci.guix.gnu.org/build/3395955/details This is the cuirass one which I am also trying to get it to be the same as, but I cannot get this derivation
<peanuts>"Build 3395955" https://ci.guix.gnu.org/build/3395955/details
<dariqq>That's not what I meant. The way you are doing it right now the only thing you use from the tarball is the one file and all the rest comes from your system. But you said your system guix is also at the same commit so i have no idea
<iK0u>dariqq I copied the entire source from that commit, not just the one file, if I only use the one file it fails because it expects some other files that are near it
<iK0u>the install.scm refers to other source files
<iK0u>maybe this is why?
<iK0u>however I also tried doing it without the source tarbal with this method
<iK0u>guix system image -t iso9660 -e '(@ (gnu system install) installation-os)'
<dariqq>apteryx: building my system for gnome-team right now. If this is also ok I'll send the patch later
<iK0u>Is anyone able to get the same derivation as the cuirass link I posted? If so what did you do to get it? I am unsure what method it is using
<iK0u>does the official one use the same method that is given in the documentation for building it?
<iK0u>I don't know how to simply "guix challenge" it either because it's not a package, and when I try it complains that I haven't built the same derivation locally
<apteryx>dariqq: sounds good!
<apteryx>anyone knows if ld ignores trailing -rpath directives?
<apteryx>(argument ordering issue?)
<apteryx>I guess I can try mold and see
<apteryx>(mold is not sensitive to its arguments ordering, or not supposed to be)
<apteryx>hm, baked RUNPATH unchanged
<iK0u>By the way, guix system image -t iso9660 -e '(@ (gnu system install) installation-os)' and guix system image -t iso9660 gnu/system/install.scm produce the same derivations
<iK0u>I guess this rules out any inpurity regarding using the source directory
<iK0u>On one machine, each time the derivation is the same as the previous on that machine, even in a VM. However, on a different machine, it is the same case except that they are different on each machine.
<iK0u>Could the different hardware be causing the derivation to be different?
<iK0u>How can I make this more deterministic
<iK0u>They are using the same architecture but probably a different microarchitecture
<iK0u>Is there anything I can do to make the build not care what hardware it is on and simply focus on the generic architecture
<nckx>How do the two .drvs' contents differ? There should be a root cause.
<nckx>Guix hashes inputs, and your microarchitecture is not an input to the hash function… 😛
<nckx>Something like diffoscope should help you diff these single-line files.
<cow_2001>i want to install guile-cv 0.4.0 on guix, but i'm out of my depth :(
<iK0u>nckx I am going to check, thanks
<nckx>I assume (hope) that only one input will differ, and you can simply recurse down a single path to find the culprit.
<iK0u>It's going to take me a little while to get the derivation back, is there a way to directly download a direvation from ci.guix.gnu.org?
<nckx>Honestly… no idea. I've never tried.
<iK0u>Well.. I'll report back in an hour or so..
<iK0u>Heh
<nckx>You… are taking an hour to print a .drv?
<iK0u>No I had to GC and I didn't save the .drv's
<iK0u>so I need to get both of them back
<nckx>Why does that take an hour though?
<iK0u>I guess my computer is slow
<nckx>What command are you running?
<nckx>The ones above?
<iK0u>Yeah, but to compare with the one from cuirass I have to do guix build /gnu/store/q1xam99hzsyz6dg7b0hnmgk7ppf3dak1-image.iso.drv
<iK0u>to get the file for comparison
<iK0u>Which takes a very long time
<nckx>Sure, but we don't care about the output yet.
<nckx>You said the drvs differed.
<nckx>Or did I misget you.
<nckx>> Could the different hardware be causing the derivation to be different?
<nckx>To me means that each machine produces a different /gnu/store/<this>image.iso.drv.
<iK0u>Yeah, they are
<iK0u>And I am also producing one that is different from this https://ci.guix.gnu.org/build/3395955/details
<peanuts>"Build 3395955" https://ci.guix.gnu.org/build/3395955/details
<iK0u>So all three are different
<iK0u>And on my own two machines I am sure I am running the exact same command
<nckx>guix system image -dt iso9660 -e '(@ (gnu system install) installation-os)' should not take an hour.
<nckx>And you are on Guix commit b13d6c5715b71c4499ce37ef3968e4216125a5ed ?
<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b13d6c5715b71c4499ce37ef3968e4216125a5ed
<nckx>Yeah, that one, thanks peanuts.
<peanuts>nckx: Hi, for comments please contact my maintainers at https://codeberg.org/lechner/irc-helper-bot
<iK0u>Yeah, I am on that commit for both computers, yes
<nckx>OK.
<iK0u>I am running the command with -d right now
<iK0u>One of the devices already has the derivation ready, waiting on the other right now
<nckx>-_-.png https://paste.debian.net/plainh/4bd5d004
<nckx>iK0u: OK, if the file names differ, that means their contents should too.
<dariqq>apteryx: now dconf is both a native input and a normal input. Can I just remove the native one or keep both?
<nckx>So ‘guix system image [-d]’ won't work on any of my computers, which is annoying. I guess this is new. I don't remember this happening last year.
<nckx>ACTION AFK a bit.
<iK0u>nckx separate -dt into -d and -t
<iK0u>that works for me
<nckx>That implies our option parser is buggy…
<nckx>…no, that still produces the pasted error.
<nckx>I don't think this is related to -dt.
<nckx>However, if your ‘guix system image’ does accept --disable-authentication, I'd be very curious to know.
<iK0u> guix system image -d -t iso9660 -e '(@ (gnu system install) installation-os)'
<iK0u>this version of the command works for me
<iK0u>actually it just completed.. you were right it did not take an hour
<iK0u>I did not use --disable-authentication
<nckx>Yes, but since I have all my machines set up a certain way, that command doesn't work for me (see paste), and the work-around doesn't work either, so I can't reproduce your output, which is annoying. That's all.
<iK0u>This is my derivation /gnu/store/j17m0b935bhc3lic6w497jpsv1rfc145-image.iso.drv
<nckx>ACTION really AFK for a bit now.
<iK0u>Going to compare the contents with the other machine
<iK0u>I just tested --disable-authentication, I get the same error as you
<apteryx>dariqq: if dconf is used as part of the build process (e.g. for the suite), it needs to remain in native-inputs
<apteryx>(for cross-compilation)
<apteryx>for the test suite*
<dariqq>ok, looking at pacakge definitions in other distributions it seems to be both. I'll keep it then
<marcc>Heya, when trying to compile a project, I am getting the error `make: *** [Makefile:177: src/pg_query.o] Error 127
<marcc>It doesn't happen if I clone the git repo and run make
<marcc>any clue if I am missing something basic?
<marcc>Ah I have the error make: cc: No such file or directory
<marcc>Isn't gcc included by default?
<marcc>Resolved it! Had to add setenv "CC" "gcc" before the build step
<iK0u>nckx I figured out how to download the file https://ci.guix.gnu.org/nar/zstd/q1xam99hzsyz6dg7b0hnmgk7ppf3dak1-image.iso.drv
<iK0u>Nvm use this link for the uncompressed version https://ci.guix.gnu.org/nar/q1xam99hzsyz6dg7b0hnmgk7ppf3dak1-image.iso.drv
<nckx>marcc: As a free ‘thanks, I hate it’ tip: ‘error 127’ in this context is usually ‘command not found’.
<iK0u>diffoscope is treating these as binary files, werid
<iK0u>weird*
<marcc>@nckx haha thanks
<marcc>So I think my build works! I setup support for the library libpg_query. It typically writes to /usr/local/lib, but this one will write to /gnu/store/blahblahblah-libpg/usr/local/lib, would that be the correct directory?
<marcc>and are there any tests or similar that I need to add?
<iK0u>nckx I have put the contents of my derivation j17m0b935bhc3lic6w497jpsv1rfc145-image.iso.drv here: https://paste.debian.net/plainh/83a70b62
<iK0u>Unfortunately I am noticing many differences between the 3 files already..
<iK0u>Parted, module-import-compiled , grub.cfg, -system, guile sqlite differs between them too
<iK0u>There is probably more but I haven't managed to get diffoscope to work properly so I am doing it manually
<iK0u>All 3 differ in these, except my two machines only partially differ in guile sqlite.. One machine has 3 of them and the other has 2, and the extra is different..
<iK0u>Grub hybrid too..
<iK0u>nckx it appears that the majority of the derivations inside this derivation are different on each of the 3 files, my two machines that ran the same command have a few similarities but still a lot more differences.
<marcc>If the name of a library has underscore, I.E. libpg_query, what is the naming convention? The linter complains about the underscore
<janneke>marcc: the library should be installed in /gnu/store/...-libpg/lib; no /usr/local
<janneke>i've got no idea why an underscore (or any other character ftm) would be of interest to a linter
<marcc>It's complaining about the title, I set name to libpg_query but it wants it to be libpg-query
<marcc>@janneke So the program writes to /usr/local/include, /share/doc/LICENSE and /usr/local/lib. So I guess I can move everything to the "root" after install, I.E. out/usr/local/lib -> /lib, out/usr/local/share -> out/share etc?
<marcc>maybe with an add-after hook
<janneke>the 'usr/local` bit is called prefix
<janneke>usually configuring using --prefix=/gnu/store/...-libpg, or else using prefix=/gnu/store/...-libpg during make install should work?
<marcc>The way it's set in the makefile is `prefix=/usr/local`
<marcc>makes me think I'd need to overwrite it with sed or something
<marcc>Not sure how to do it in guile-lang haha
<marcc>but it's hardcoded
<janneke>okay, so you may use #~(#:make-flags (list "prefix=$#output" ))
<janneke>there are serveral examples of this
<janneke>*"prefix=#$output"
<janneke>hmm, it seems gexps don't expand inside a string? probably it shoul be
<janneke>#~(list (string-append "prefix=" #$output)
<janneke>well, best to have a look at an example :)
<nckx>iK0u: Hmm, that's not what I was expecting. If the two Guixes are truly identical (‘guix describe’), then I'd expect either identical derivations (normality) or one subtle difference (~weirdness~), but not completely diverging hash trees.
<nckx>ACTION moves /etc/guix/channels.scm out of the way so they can pull & run guix system image; let's see what it produces here.
<iK0u>Yeah, guix describe is the same
<nckx>Can you share it on paste.debian.net?
<nckx>I'm pulling to b13d6c5715b71c4499ce37ef3968e4216125a5ed now.
<peanuts>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b13d6c5715b71c4499ce37ef3968e4216125a5ed
<iK0u>I posted above my derivation on paste.debian.net as well as link to the ci.guix.gnu.org version
<marcc>@janneke so one solution I saw was this #:make-flags (list (string-append "prefix=" (assoc-ref %outputs "out"))). But it doesn't seem to really work.
<iK0u>"nckx I have put the contents of my derivation j17m0b935bhc3lic6w497jpsv1rfc145-image.iso.drv here: https://paste.debian.net/plainh/83a70b62"
<nckx>iK0u: I meant the output of ‘guix describe’.
<iK0u>Oh sure
<nckx>Ta!
<iK0u> https://paste.debian.net/plainh/b76e1bed
<janneke>marcc: that's the old meme, when using `(arguments ...)
<janneke>for newer packages, we use #~(arguments ...)
<janneke>wait, that's
<janneke>(arguments (list #:make-flags #~(list (string-append "prefix=" #$output))))
<nckx>No, #$ inside a string isn't magical. Have you been spending too much time with Nix or something? ☺
<janneke>ACTION is confusing things sorry
<janneke>nckx: some sort of brain-fog tonight, apparently
<nckx>Very familiar.
<janneke>ACTION has been running the nix command a couple of times the past days, but hasn't really looked at any package definitions
<jakiki6>docker-compose refuses to work after I recently ran guix system reconfigure
<jakiki6>it says: "ERROR: for postgres  Cannot start service postgres: Unknown runtime specified /gnu/store/vp6hkmpc0jkfcdy53jwnbgyjfgaf3smk-runc-1.1.9/sbin/runc"
<jakiki6>but "/gnu/store/vp6hkmpc0jkfcdy53jwnbgyjfgaf3smk-runc-1.1.9/sbin/runc" exists
<podiki>jakiki6: remake the docker image
<podiki>e.g. docker-compose up --rebuild --force (well i don't remember the exact flags, but rebuild and force)
<podiki>this came up just the other day in here, we should document this somewhere or see if there is anything we can do on our end (doubt it, just things will change after a reconfigure)
<jakiki6>thanks
<jakiki6>--force-recreate seems to do the trick
<podiki>not sure what is happening, i guess some paths are set to something that doesn't exist or moved? as you say, the runc it refers to is there, but something else it tries to use is not
<podiki>don't think you should have that problem with oci-container-service, at least i hope, since that is more controlled by guix as a system service
<jakiki6>yeah that one still works
<marcc>Unrelated to earlier, how is the nix integration with guix? Can I use it for projects with nix-flakes or if I need a package that doesn't exist for guix?
<yaslam>hello everyone, for those that use EXWM, is there a way to include the EXWM config in the guix config
<yaslam>.scm like rde does https://github.com/abcdw/rde
<peanuts>"GitHub - abcdw/rde: Tools for managing reproducible development environments. Mirror of https://sr.ht/~abcdw/rde/" https://github.com/abcdw/rde
<yaslam>i looked at rde but is too complicated for me to understand
<janneke>yaslam: i'v no idea how rde does it, but i've added my ~/.exwm to my home config, just like other dotfiles
<Kingsy>currently I am using a system config in /etc/guix/config.scm, does it matter if I just move this file somewhere else? I need to specify it in the guix system command anyway.
<yaslam>janneke: rde makes it so that when you reconfigure the system exwm is already setup with their config
<Kingsy>sorry its in /etc/
<yaslam>that is what i meant sorry
<janneke>Kingsy: you can move it where you like; i keep in in git
<Kingsy>yeah will do. also how come (keyboard-layout (keyboard-layout "gb")) doesnt give me uk keyboard layout?!
<Kingsy>anyway thats less important right now
<nckx>Where?
<Kingsy>oh!! its correct in a tty. maybe its a stupid X problem
<janneke>Kingsy: you have to specify it for xorg too
<janneke>see https://guix.gnu.org/en/manual/en/html_node/Keyboard-Layout.html
<peanuts>"Keyboard Layout (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/en/html_node/Keyboard-Layout.html
<nckx>Kingsy: Not so much problem as a quirk. For X (and the boot loader), you need to explicitly inherit the console layout: https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html
<peanuts>"Using the Configuration System (GNU Guix Reference Manual)" https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html
<Kingsy>so what browser is most commonly used in here? I am still looking for a nice one to settle on, I know its high subjective so just asking around. I really dont want something super bloated.
<Kingsy>nckx: thank!
<ieure>Kingsy, The system config file can live anywhere, I keep mine in a Git repo.
<nckx>+janneke.
<Kingsy>ieure: got it! thansk
<ieure>Kingsy, I use LibreWolf daily, it's not in Guix yet, but you can build it from my channel (as I mentioned yesterday).
<Kingsy>ieure: yeah sorry. was just hoping to find something in the guix channel for now.
<Kingsy>something with a substitute would be ahndy. haha! :D
<nckx>ACTION uses their own Firefox package. It removes some ‘bloat’ I guess but it's not an obsession. And substitutes are straight out.
<ieure>Kingsy, The options in Guix are Chromium (which is IMO ethically untenable), IceCat, which is weirdware Firefox that won't run non-GPL'd JavaScript out of the box, Torbrowser and Mullvad, which IMO aren't great for daily use.
<yaslam>to elaborate on my previous question, i am looking for a way to do "system level" configuration of exwm or smthin like that
<ieure>Kingsy, ...which is why I'm trying to get LibreWolf into Guix.
<Kingsy>ieure: ugh, yeah that isnt very nice in terms of choice.
<ieure>You can get stock Firefox from third-party channels, but IMO stock Firefox is also unfit for daily use due to the increasing enshittification pushed by Mozilla.
<ieure>I guess if you love having your user preferences ignored so it can show you full-page ads for their VPN or w/e, it's... fine.
<ieure>But Mozilla the org has proven themselves to be unfit stewards of the open web over and over and I am personally completely done with their shit.
<Kingsy>I just tired o these browsers using literally gigs of ram.. its really starting to p*ss me off
<ieure>Yeah that's never gonna change. Sorry.
<Kingsy>I was desperate to settle on nyxt, it has emacs bindings which is just right up my street. but it crashes every few minutes. (on both debian and guix)
<ieure>I haven't tried it, but, not surprised.
<Kingsy>they are in the middle of a rewrite so likely I will try it after the next big release.
<ieure>I'm ethically opposed to anything Chromium-derived, because even though it doesn't lustily slurp all your data like Chrome does, it's still part of the system of control Google is employing to destroy the open internet.
<jackhill>What about GNOME Web?
<jackhill>Also, Guix's ungoogled-chromium is out of date, but I understand why it's difficult both computationally and package definition wise to upgrade.
<jackhill> Learning nyxt is on my list (like so much else) :)
<Kingsy>jackhill: its not about learning it for me. I couldnt use it long enough to even find out if it was any good before it crashed :D
<Kingsy>ieure: so, do you mind if I quickly ask you about this startx idea you had, so I have added xorg-server in the packge list in my system config, xinit is the package that gives startx, I need to add that to my home config? or system?
<jackhill>Kingsy: yeah, I just haven't used it enough because of inertia to observe the crashing. Other webkitgtk browsers (well, GNOME Web) work fine for me, so that's interesting.
<Kingsy>jackhill: yeah it was super strange. its been very very unstable on both debian and guix for me
<Kingsy>what is wrong with this -> https://bpa.st/6CFA
<peanuts>"View paste 6CFA" https://bpa.st/6CFA
<Kingsy>I get error: dbus-root-service-type: unbound variable <- which is weird because I have (use-modules (gnu services desktop))
<Kingsy>well it worked with (gnu services dbus)
<Kingsy>ieure: so adding xorg-server and xinit to my system config didnt work unfortunately :(
<nckx>iK0u: I've run ‘guix system image -dt iso9660 -e '(@ (gnu system install) installation-os)'’ on two quite different x86_64 systems, once with --no-grafts and once without, and they both return the same hashes. /gnu/store/krc9nma636wh5ibkj37bjv1s6crq0p9f-image.iso.drv and /gnu/store/sm650wj4biafx9d148bzmik728qh5yqq-image.iso.drv respectively. I didn't look at CI because I'm too tired to stare at hashes, but that's secondary. I can't reproduce y
<nckx>our own disparity.
<nckx>Guix hashes don't assume reproducible builds, they are hashes of *inputs*, so subtle differences in compilation, race conditions etc. shouldn't™ affect .drv hashes at all.
<nckx>I don't know what's going on. There might be an uncontrolled variable that we both missed.
<nckx>ACTION → 😴💤
<iK0u>nckx, thank you
<iK0u>However this is interesting
<iK0u>I have the same hash sm650*
<iK0u>on my other device..
<iK0u>As you
<Kingsy>if I am just using base-packages and xorg-server what else do I need to properly run gtk, qt etc etc apps? gsettings seem to be missing for one