IRC channel logs


back to list of logs

<littlebobeep>jab: Awesome thank you for links ^_^
<jab>littlebobeep: of course. guix-devel is a fun place to read. :)
<tribals>Still didn't get the point: do i need to run `guix shell` in order to be able to run `./pre-inst-env`? ^_^
<sneek>atka: wb
<atka>sneek: botsnack
<tschilptschilp23>does anyone have an advice how to properly use the ~with-eval-after-load 'geiser-guile~ settings as proposed on in my init.el? I'm asking, because after applying it, my ~guix-help~ sometimes(always?) seems to be confusing my actual installation with the checkout I'm pointing to.
<tschilptschilp23>or is the proper way just to comment it out, when I want to make sure to browse the definitions of my installation?
<tschilptschilp23>s/definitions/package and service definitions + all the rest/
<florhizome[m]>civodul: but what is a systemd/inetd container? :D
***rekado_ is now known as rekado
<jab>tschilptschilp23: I know that I have tried to set up the perfect setup before....I could not quite get it to work either.
<jab>I am having issues just with geiser proper. Minor issues like geiser locks up my Emacs, and I have to re-start the geiser REPL.
<jab>I have tried connnecting geiser to a remotely running guile, which messes up the prompt in emacs.
<tschilptschilp23> The link to the geiser introduction manual ( on seems to be broken. I interprete this as a sign for me to get some sleep ;)
<jab>And company no longer completes the module procedure names as I type them.
<atka>hi guix, so I just deployed a config, the users were created with their home directories and everything but they are completely empty. the prompt is "-bash-5.1$" instead of "user@host" and when trying to guix pull
<atka>guix pull: error: while creating symlink '/home/atka/.config/guix/current': Permission denied
<atka>when creating multiple users the syntax is "(users (cons* (user-account" correct?
<atka>so it appears when the configuration was applied root owns all the home folders
***iyzsong-www is now known as iyzsong-w
<atka>ok, I think I know what happened, it has to do with the btrfs subvolumes for home directories
<atka>so what happened was that I created the home directories as btrfs subvolumes and naturally they were owned by root, I didn't specify (home-directory "/home/foobar") in my config. during install the correct directories were used but the permissions were not set and root remained the owner. should this be considered a bug? do I just need to remember to apply the correct permissions before I run guix
<atka>system init or should the config handle permissions for directories that already exist?
<jackhill>atka: I've run into the same thing. Easy enough to fix up afterwards (copy the files from /etc/skel/ and chown), but I agree with you that it shouldn't be nessisary.
<jackhill>I didn't file a request/report thought becasue I wasn't sure what the right behaviour should be. I think ideally Guix could be told to create the subvoulumes in the system config
<jackhill>what do you think?
<atka>it would be handy to have filesystem/subvolume creation but probably a bit of an undertaking, I think at least if a home folder already exists the correct owner should be set by guix system init because what is the point of a home folder you don't have ownership of.
<atka>does each user need to hash guix after their first guix pull on a multi user system?
<littlebobeep>WARNING: IceCat 91 has not yet been released by the upstream IceCat project.
<littlebobeep>This is a preview release, and does not currently meet the privacy-respecting
<littlebobeep>standards of the IceCat project.") (license license:mpl2.0)
<littlebobeep>Okay how does it not respect privacy
<littlebobeep>does it not rip out mozilla telemetry
<jpoiret>atka: `hash guix` is just convenience, basically what it does is ask bash to lookup the binary again in the PATH (because otherwise the mapping `guix` -> actual path might be cached)
<jpoiret>so you could just do nothing and it will take effect on next login
<jpoiret>littlebobeep: i think the preview releases are not scrutinized as much for new changes in firefox behaviour that would entail ie telemetry and the like
<jpoiret>it should still be reasonably better than stock firefox, but the thing is that mozilla churns out releases all the time, and icecat can't really manage to follow their release schedule
<jpoiret>so there's the trade-off between security updates and proper icecat release
<littlebobeep>jpoiret: Interesting that is unfortunate
<littlebobeep>kind of stuck... what about librewolf?
<atka>jpoiret: thank you
<Lumine>Was just going to say, that LibreWolf is nice but it sports proprietary bits
<atka>hey Lumine
<Lumine>Hello atka
<jpoiret>Lumine: are there any additional proprietary bits compared to firefox
<jpoiret>it would seem weird to me that they would add some
<Lumine>No they've taken most of it away iirc
<Lumine>And added some nice defaults for privacy
<Lumine>I need to look into what parts of it are proprietary
<jpoiret>i mean, if it's FSDG-compatible, it would probably be a good alternative to icecat
<Lumine>I use Pale Moon, LibreWolf and Icecat interchangeably
<Lumine>But since I'm on Emacs most of the time now, I'm shifting towards lightweight browsers
<Lumine>Qutebrowser and even w3m
<jpoiret>be careful though, Pale Moon is an actual fork of Firefox and might lack the security of the big browsers
<Lumine>I know, and they are now making the leap to a more vanilla Firefox
<Lumine>With v30
<Lumine>So I'll probably drop it
<the_tubular>Lumine check out eaf-browser, it's not yet in guix yet
<Lumine>Oh sweet, thanks the_tubular
***iyzsong-www is now known as iyzsong-w
<f1refly>I have an issue with thunar and I'm not sure it's guix related. When I change any settings they will not be remembered and the menu bar which usually can be toggled with ctrl+m will only get hidden and not reappear when pressing the keys again. when I close thunar and re-open it the menu bar is back and no settings are saved.
<f1refly>I made sure that the configuration files in ~/.config/Thunar and the directory itself are rw accessible
<f1refly>Not sure how to progress now
<unmatched-paren>is there a guix command to check if a dependency chain contains mutually recursive dependencies?
<unmatched-paren>i'm trying to package aerc again, this time using `guix import go`, but there seems to be a recursive dependency because guile runs out of memory when i try to build it
<unmatched-paren>i have the graph from `guix graph` open in imv, but i can't really see any problems
<unmatched-paren>ah, there's one...
<unmatched-paren>go-google-golang-org-protobuf depends on go-github-com-golang-protobuf and vice vers
<unmatched-paren>okay, apparently those protobuf packages will require a bootstrapping chain...
<hexo>howdy! can I rebuild guix from outside of guix and obtain qemu image? or install iso?
<hexo>i'm playing around a bit with sources
<hexo>so, bootstrapping, is it? :D
<hexo>hope i'll wipe the host system... :D
*unmatched-paren does `guix graph ungoogled-chromium-wayland | dot -Tsvg > chromium.svg && imv chromium.svg` and dies inside
<hexo>this is ubuntu...
<hexo>guix isn't even installed, yet
<hexo>I did some changes and want to rebuild it and try to install
<hexo>my thinking about the way who it's done might also be very wrong...
<unmatched-paren>hexo: if you want an ISO, try `guix system image --help`
<hexo>i dont have $guix yet
<unmatched-paren>you'll probably want to install regular guix before making modifications....
<hexo>i running current guix in qemu would help. that what i can do. no problem
***iyzsong-www is now known as iyzsong-w
<hexo>but, i did incompatible changes....
<unmatched-paren>you can just install guix on ubuntu
<hexo>thats why i want to rebuild it from outside
<unmatched-paren>and then use `./pre-inst-env` in the guix repo to test your changes
<jpoiret>hexo: you can just build guix from source on any distro, as long as you install the dependencies, see
<unmatched-paren>wdym by incompatible changes? what did you change?
<jpoiret>no need to already have guix installed
<hexo>i'm playing with store
<jpoiret>then you can do ./pre-inst-env guix system image
<hexo>epic, thanks a lot. i'll try to satisfy deps first
<hexo>unmatched-paren: some hackish stuff with path names in used-to-be-nix-daemon
*hexo having fun
<unmatched-paren>this chromium dependency graph has so many colourful lines it looks like abstract art
<littlebobeep>unmatched-paren: What does chromium.svg look like can you share
<unmatched-paren>i spot texlive, ruby, python, perl, rust (the entire bootstrap chain), javascript, go, yasm, three implementations of json, gtk, llvm, xcb, pcre2, gnome-backgrounds (???), gmp, and there's probably a lot more
<unmatched-paren>littlebobeep: where do you suggest i post it? it's... a bit big
<unmatched-paren>3.5MiB, to be precise
<unmatched-paren>and that's the SVG version :P
<littlebobeep>unmatched-paren: maybe
<unmatched-paren>500 Internal Server Error
<unmatched-paren>--, 2022
<unmatched-paren>also there's a bunch of MySQL errors
<unmatched-paren>i'll put it on cloud.disroot.rog
<unmatched-paren>the graph might actually be bigger than what it looks like, since i spotted a go package that did not appear to depend on go...
<hexo> error: possibly undefined macro: GUILE_MODULE_AVAILABLE
<hexo>seem like i'm not building today :(
<hexo>thats from bootstrap
<unmatched-paren>littlebobeep: sorry, laptop ran out of battery :)
<unmatched-paren>here it is:
<unmatched-paren>hexo: maybe you have an old autotools version o
<unmatched-paren>r something?
<hexo>this is ubuntu 20.04... no idea
<unmatched-paren>does `autoconf --version` tell you anything?
<unmatched-paren>latest release was apparently 2.71, according to wikipedia
<hexo>> pkg-config --libs guile-3.0
<hexo>Package guile-3.0 was not found in the pkg-config search path.
<hexo>i'd say. this is the problem.
<jpoiret>you'll need the guile autoconf macros, not sure if guile installs them for you on ubuntu
<hexo>ubuntu-typical problem.
<hexo>i'll try to deal with it
<unmatched-paren>in true Guix fashion, you'll probably need to build Guile from source
<unmatched-paren>nothing's more likely to install the package correctly than the official installation method
<AwesomeAdam54321>hexo: There's a guile-3.0-dev package available that you can `apt install`
<hexo>i have it installed, didnt help
<littlebobeep>unmatched-paren: wtf is this resoltion size 74098x5732 I cannot see all these dependencies
<littlebobeep>How can I possibly trust something this complicated >_<
<unmatched-paren>"how can i possibly trust something this complicated" <- *exactly*
<littlebobeep>wow it goes all the way back to mes and gash and tcc this is very complete
<littlebobeep>why is guile-bootstrap first shouldn't mes be first?
<littlebobeep>Is literally everything on the bottom right just to produce guile@3.0.7
<unmatched-paren>littlebobeep: yeah
<unmatched-paren>they are working to eliminate that guile-bootstrap binary
<littlebobeep>unmatched-paren: what you saying "yeah" to
<unmatched-paren>eventually it should be replaced by mes, but currently mes requires guile (not sure what the point is then...)
<littlebobeep>okay I don't understand hy guile-bootstrap is currently needed
<unmatched-paren>i'm saying yeah to `is literally everything...`
<unmatched-paren>me neither
<littlebobeep>why does mes need guile it needs a C compiler not Guile
<unmatched-paren>Well, i think it gets compiled with mescc? idk
<littlebobeep>then the mescc should run on mes the Scheme interpreter
<unmatched-paren>now let's try icecat >:)
<littlebobeep>lol plz share
<hexo>(i'm building guile just to get those pesky .pc files... :D)
<littlebobeep>unmatched-paren: Do you need to build icecate to see or does guix graph do it's magic by scanning Scheme-based package definition source files and you don't need to build anything
<littlebobeep>hexo: wat is .pc
<unmatched-paren>littlebobeep: you can replicate these with `guix graph ___ | dot -Tsvg > ___.svg && <image viewer> ___.svg`
<unmatched-paren>you don't need to build the packages
<littlebobeep>Why does MIT/GNU Scheme package definition have bogus ISA ith bogus SHA-256 hash:
<littlebobeep> (base32
<littlebobeep> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")
<unmatched-paren>littlebobeep: pkg-config is a part of the typical C build system
<littlebobeep>guix graph is pretty amazing I never seen something like it
<unmatched-paren>btw, `dot` is from the `graphviz` package
<unmatched-paren>`guix graph` generates a `graphviz` graph file, and `dot -Tsvg` converts it to an SVG
<unmatched-paren>.pc files contain information like: what other C libraries does this package depend on, what's the name of the .so file, which compiler flags does it need
<unmatched-paren>littlebobeep: i think that `aaaaa` is to intentionally raise an error
<unmatched-paren>so if you try to build it on an unsupported architecture, it'll throw a hash error
<littlebobeep>OKay hmmm
<unmatched-paren>very ugly :)
<janneke>littlebobeep: guile is needed in mes to run gash and gash utils
<unmatched-paren>icecat.svg is generating...
<unmatched-paren>janneke: so will gash be ported to mes at some point?
<unmatched-paren>mash :)
<janneke>unmatched-paren: yes, samplet and I are working on that
<littlebobeep>janneke: Oh thank you! So Mes does not fully support Guile Scheme atm?
<littlebobeep>not sure if this is lack or r5rs or r6rs or some srfis in mes or what
<littlebobeep>janneke: Are you modifying gash and gash-utils to be more mes-like or are you modifying mes to support something closer to guile scheme?
<janneke>littlebobeep: that's right; mes only supports just enough to run mescc with nyacc
<unmatched-paren>icecat.svg is STILL generating...
<janneke>to be fully guile compatible, many, many things are missing
<janneke>most notably: guile module support, which is in the works
<janneke>to run gash we will do probably do both, work on mes and work on gash
<unmatched-paren>littlebobeep: um, i think icecat.svg is actually BIGGER...
<unmatched-paren>yes, it is, 3.8MiB
<unmatched-paren>littlebobeep: <- icecat
<unmatched-paren>welcome to The Web, motto "The only winning move is not to play" :P
<littlebobeep>janneke: so basically guile-static-stripped will eventually disappear from mirrors like this:
<littlebobeep>also why is it only 32-bit x86 binaries on these mirrors I vaguely remember ludovic's signed bootstrap binaries for amd64 several years ago
<unmatched-paren>littlebobeep: TCC only support 32-bit afaik
<unmatched-paren>so there's no point to having 64-bit ones
<littlebobeep>unmatched-paren: Well you are part of the problem by not sending direct URL to SVG file :P I have to visit this stupid site with 4 cookies and 29 javascript elements just to get the REAL link to image
<unmatched-paren>sorry :)
<unmatched-paren>hm, i wonder if supports images
<unmatched-paren>apparently not
<unmatched-paren>littlebobeep: rest assured that all the JS in that site is free though
<littlebobeep>unmatched-paren: Yeah well license doesn't help much it just means I can modify and redistribute it might be minified or malicious even if libre I dunno without reading it
<unmatched-paren>i'll make sure to send the actual link if i post an image again :)
<hexo>yea. time for firejail + selinux
<littlebobeep>there are better links :P
<littlebobeep>these SVG files break my image viewer >_<
<unmatched-paren>littlebobeep: try `imv`
<unmatched-paren>it works on them
<unmatched-paren>very slowly, but it works
<littlebobeep>imv still lags hmm
<littlebobeep>and I need like a 32K resolution display for this
<hexo>i'm waiting for such displays for like an eternity already
<littlebobeep>unmatched-paren: Why is bootstrap path in icecat.svg on bottom left but it is on bottom right in chromium.svg what logic is guix graph using to place these
<unmatched-paren>guix graph doesn't place them
<littlebobeep>hexo: nanoaugmented eyeball HUD hacks
<unmatched-paren>guix graph generates a description of the graph, which is converted into $IMAGE_FORMAT by graphviz's `dot` command
<hexo><3 i need that badly!
<unmatched-paren>not sure what logic `dot` uses
<littlebobeep>what language is dot written in
<hexo>i'd say C
<littlebobeep>hexo: "you'd say" ?
<littlebobeep>did you check the source from ubuntu or something?
*hexo checks
<unmatched-paren>littlebobeep: graphviz is written in C, according to the package definition
<unmatched-paren>the source code is on gitlab, which also has ridiculous amounts of JS, so i think it'd be wiser not to post a link :P
<hexo>i've looked there, seems too C-ey :D
<littlebobeep>lol okay gitlab
<littlebobeep>does gitea require JS not sure >_<
<unmatched-paren>`git clone`
<unmatched-paren>littlebobeep: yes
<unmatched-paren>cgit,, and gitweb don't
<unmatched-paren>gitea is designed to basically be a self-hosted github clone
<littlebobeep>right I know it is I did not mind gitea's interface much but yeah I dunno how many JS scripts it requires
<unmatched-paren>i don't think basic things like viewing files and opening directories require JS, but (say) posting issues and pull requests does
<littlebobeep>why are linux-livre-headers required for bootstrap
<unmatched-paren>well, linux-libre-headers provide C interfaces to the kernel, no?
<unmatched-paren>so it would make sense if something needs them
<unmatched-paren>ok, i'll need to go now, bye :)
<janneke>littlebobeep: hopefully...although for guile-static-stripped to disappear we would also need some way to build [guix] packages, for which guile is the driver
<littlebobeep>janneke: Hmmm righ well we need some kind of Scheme interpreter I guess no matter what
<littlebobeep>Why is guix-daemon not in list of bootstrap binaries
<littlebobeep>don't you need that to do basically anything
<AIM[m]>I can't remove packages I've installed after I setup guix home
*AIM[m] uploaded an image: (111KiB) < >
<AIM[m]>bash profile
*AIM[m] uploaded an image: (113KiB) < >
<AIM[m]>I can't remove packages I installed with `guix install` command
<AIM[m]>Nvm I think it was due to me not sourcing the profile script in bashrc
<Guest66>Hi ya. Since a while I'm trying to work on guixSD. Heve no knowledge of guile really. But it is running. Sort of. My store is getting filled with every reconfigure and guix gc does not seem to work properly. There is plenty of packages which are beeing left. Also invoking sudo -i guix gc does not remove the profiles. I can still see them in the
<Guest66>grub menu. Root is lvm. Currently 222 packages and 55G! What am I doing wrong?
<jpoiret>Guest66: you need to remove the previous generations before they can be gc'd
<jpoiret>otherwise the rollback feature of Guix would be rendered useless by a random gc
<jpoiret>you can see guix system generations with `sudo guix system list-generations`, guix package generations with `guix package --list-generations`, and guix pull generations with `guix pull --list-generations`
<Guest66>jpoiret Thanks. What is the command?
<Guest66>jpoiret Cheers
<jpoiret>you can delete them with delete-generations instead of list-generations, see the option's description in the manual
<jpoiret>once that's done, `guix gc` will happily get rid of unused store paths for you
<jpoiret>no need to sudo it, sudo is only needed for `guix system` commands
<Guest66>jpoiret I'm reading it all in between but it's a huge library
<jpoiret>(you'll need it to delete system generations)
<jpoiret>more generally, you can use `guix gc --list-roots` to list all the things that are preventing store paths removal
<Guest66>jpoiret I did: sudo -i guix package --delete-generations (also as user) & guix gc. It did remove some (11G) of the packages. 40G is left. Now, again, guix system reconfigure install these packages back.
<gnoo>perhaps there was an update of those packages?
<gnoo>if you don't want it at all, remove it from the config.scm
<gnoo>you should install very few things globally (i.e. in /etc/config.scm) and install most of your packages as normal user
<Lumine>I remember when I started first using Guix, I had 120 packages declared in config.scm
<Guest66>Lumine That's where I put all my packages now.
<Guest66>Lumine I'm trying to avoid potential problems with the permissions
<jpoiret>`sudo guix system delete-generations` rather?
<jpoiret>if all your packages are in your system config, that's where the big generations should be
<Guest66>jpoiret Thanks. Links are gone. x 117
<Guest66>I did paste my packages declaration. Can someone point out what should not be globally declared, please
<jpoiret>first thing, why would you have so many libs explicitely installed?
<gnoo>Guest66: you don't need to install grub-efi maybe even smartmontools ...
<gnoo>only install the ones you will need for every user in the system
<Guest66>Yes, some I did just to try to sort problems I encountered. When for example building gnunet from git.
<jpoiret>i see glibc, readline libcap libtool, libusb
<jpoiret>the whole gnunet deps
<Guest66>jpoiret Yes. As I did not know how to build it otherwise
<jpoiret>isn't gnunet already packaged?
<Guest66>This worked together wit definition of gnunet git package in the config.scm
<gnoo>Guest66: maybe install alsa-utils, sway, alacritty ungoogled-chromium/wayland, emacs
<jpoiret>if it's about compiling a newer version, it can be achieved easily using package transformations
<gnoo>maybe even wl-clipboard, dment, openssh, rsync, file and lynx
<gnoo>but that's about it
<jpoiret>i'd say even more
<jpoiret>gimp, yt-dl, etc.
<gnoo>Guest66: if you want to build something, you'll use guix shell -D <packagename> <extra packages>
<gnoo>yt-dlp should probably be installed per-user since it's to be updated frequently
<Lumine>I have less than 10 packages in config and the rest is managed by home, and whatever development packages I need, I use shell environment
<Guest66>jpoiret Easily?'=(
<jpoiret>well, yes, you can try it right now with `guix build --with-latest=gnunet gnunet`
<jpoiret>(no warranty, it needs to be able to autofetch the newest sources. If not, you'd have to update it manually but that's not that hard as well)
<gnoo>Guest66: the `guix shell' command will temporarily "install" the packages so it won't stick around for long
<jpoiret>same for tomb, password-store, protonvpn-gui
<jpoiret>i mean, that's just my opinion too, but those are not "system" packages, they're specific to your user
<gnoo>Guest66: as a rule of thumb, only install essential packages system-wide (i.e. in config.scm) and the ones you use regularly with `guix install' (no sudo needed) and then development packages with `guix shell -D'
<Guest66>Yes, my config is a mix of info I have found around. You don't want to see it. :')
<Guest66>Oh yes. The reason I got here was gnunet in first place. Had to make some execs suid. But now I use simple-service to configure it so I don't need them in the config.scm. Fine
<Guest66>jpoiret Thanks a lot. guix gc: freed 23,258.56600 MiBs
<Guest66>jpoiret "guix build --with-latest=gnunet gnunet" seems doing the job. '=D  You have no idea how long I was trying to build it before. Awesome
<jpoiret>if that works you can just `guix install --with-latest=gnunet gnunet`
<jpoiret>i don't suggest running big binaries as suid, esp. if they're not written to be run that way
<Guest66>Can I install ie gnunet or qemu as user and then set some execs setuid in the config? Gnunet needs some helpers suid/guid. Seems qemu bridge helper too.
<rekado>hey, could we merge wip-pyyaml into the master branch? says it built out fine.
<rekado>it’s hard to compare branches, but from what I see the obvious failures on that branch also happen on the master branch.
<rekado>this branch has two commits.
<Guest66>I'm struggling now with qemu networking. After debian client update, net is gone. Anyone have it running with networking? Or can give me advise on setting bridge in guix?
<jpoiret>if you need setuid binaries, for now you need them in your config.scm. But you should still be able to something akin to --with-latest=gnunet instead of adding all dependencies and manually building gnunet
<Guest66>jpoiret I will check. I had to when I was using setuid-programs but now I have a services like this: It gives an error if not present but boots.
<tschilptschilp23>it looks as if the links to the geiser introduction as on has moved to (one node), respectively (all on one page).
<m4t3>Hello GUIX? Can GUIX packages be installed via Gnome-Software (GUI App Store)?
<jpoiret>m4t3: i don't think there is a packagekit backend for Guix, so it would seem that the answer is no
<jpoiret>Guest66: the issue here is that the suid programs will be using the standard Guix packaged gnunet, not the one built from the latest dev branch
<jpoiret>m4t3: note though that guix itself can be installed on all linux flavors
<jpoiret>and it won't conflict with the distro's package manager, many people actually use it this way (including core maintainers)
<Guest66>jpoiret OK. How to point to the latest version in config.scm?
<jpoiret>you'll need to define your own gnunet package, that will simply inherit from guix's default one but with a new source
<jpoiret>it's a bit more technical compared to the CLI flags but it does the same in essence
<Guest66>jpoiret Yes, I've had it this way. Can I declare all the dependencies that I have in packages definition in the gnunet definition like native-packages?
<Guest66>jpoiret Sorry, native-inputs
<jpoiret>there's actually a simpler way to do that, hang on
<jpoiret>currently compiling 0.16.3, let's see if it builds
<jpoiret>i have no idea how gnunet is supposed to be used though, so i won't be able to test it
<tschilptschilp23>jab: I've now put all the suggestions from the 'perfect setup' into an interactive function in my init.el. This seems like a comparatively comfortable solution for me.
<Guest66>jpoiret I am too. "your way". My way I have had to remove tests phase. Shall see.
<jpoiret>these tests are taking a while, but they're all passing for now
<gnoo>Guest66: you can use git like so: (define-public gnunet-git (package (inherit gnunet) (name "gnunet-git") (source (git-checkout (url "")))))
<gnoo>which needs the modules: (define-module (gnunet-git) #:use-module (guix packages) #:use-module (guix git) #:use-module (gnu packages gnunet))
<Guest66>jpoiret sudo -u gnunet gnunet-arm -s & gnunet-arm -s . With suid declarations. Then gnunet-arm -I to check running services & gnunet-peerinfo to check connection
<Guest66>jpoiret I think will fail. Had the same problem. Without the phase it finish though
<Guest66>jpoiret sorry, tests phase
<Guest66>but now when I try to build gnunet-gtk with latests, it pulls a default (13.1) gnunet as dependency.
<Guest66>gnoo I did it with .
<jpoiret>you'll need to use package transformations for that
<jpoiret>they're used to modify a whole dep tree
<jpoiret>because the gnunet-gtk has the original gnunet package as its dependency, not the newer one
<Guest66>jpoiret Yes. We all should be on the gnunet now. Strangely, no one is helping them.
<Guest66>Maybe it is not supposed to be functional. Controled opposition?
<Guest66>Or people belive the wrong god, MONEY = suseJdoG
<Lumine>Okay, what have I missed
<mariobb[m]>Hi Guix Community,... (full message at
<Guest66>Lumine ticket to freedom
<Guest66>How to avoid getting ie gtk%2B-3.24.30-debug or any other -debug in config.scm
<civodul>Guest66: hi! what do you mean?
<civodul>these are things that get displayed when downloading substitutes but that's about it, no?
<civodul>yes? :-)
<Guest66>civodul can I avoid pulling of the -debug dependencies? I think qt one is >300MB  and I have 40KB/s
<civodul>Guest66: in general they should be downloaded only when needed; however there's a glitch with "grafts" (security updates) that leads them to be downloaded more often than necessary
<Guest66>civodul In my case it's the definition of kde related packages in the config.scm.  With every "guix gc" it downloads all the packages again.
<Guest66>civodul I mean after "guix gc"
<Guest66>Will clean up the mess as soon I get my head around it.
<Guest66>Did you know, we've had pandemics every 100 years?
<Guest66>Myself, I've made a vacation out of this one. Next one I will miss aparently.
<wdkrnls>Dear Guix, I am stuck on an old revision because upgrades take forever and there is always a conflict.
<wdkrnls>I would like to clean up my profile, but I noticed there isn't an option to remove packages according to those listed in a file.
<wdkrnls>Atleast, that is true on my ancient revision.
<wdkrnls>I would like to learn how to greatly reduce the set of packages in my default profile, but it seems like there are no tools to do that.
<wdkrnls>Except one at a time.
<f1refly>when I submitted my patches with 54299 I seem to have made some wrong assumptions. Can someone help me clear things up with the cargo-build-system?
<f1refly>For example when I look in the definition of rust-winit-0.24 rust-bitflags-1 is included with #cargo-inputs
<f1refly>according to the documentation #cargo-inputs is for source only crates. but the definition for rust-bitflags-1 doesn't has skip-build? #t set, so it should exist as a linkable binary
<civodul>wdkrnls: hi! you can pass "guix remove" several packages, but of course only you can choose what to remove
<civodul>typically i'd suggest using "guix shell" for development environments and for things you rarely use
<civodul>and keep in the default profiles only things you use all the time
<f1refly>My though process now was that it's common to treat library crates as source only, so I defined my packages with skip-build? #t and included them in #cargo-inputs instead of inputs, but then I was told that I shouldn't use skip-build? #t because we always want to build
<jpoiret>f1refly: linkable binaries don't exist in the cargo ecosystem i believe
<f1refly>I thought so as well, but apparently they produce intermediates that can be used by the rustc jpoiret
<jpoiret>cargo-build-system uses cargo, not rustc directly
<jpoiret>there's a recent discussion about a new build system on the MLs
<Guest66>:@  You care about Bill the Gates of Hell not dictating you what you run, but not what you eat and inject?
<wdkrnls>civodul: thanks, as usual the best answer is to not get in a mess in the first place.
<Guest66>We are in a big trouble
<singpolyma>f1refly: I think we can always use regular inputs now. Cargo inputs is historical
<jpoiret>you could try using manifests instead wdkrnls, it gives you a cleaner overview imho
<wdkrnls>jpoiret: I believe it, but my issue is undoing a bunch of naive damage I already did and learning to be much better at the shell.
<f1refly>singpolyma: they aren't, apparently
<singpolyma>f1refly: that's an outdated manual
<f1refly>where's a new manual?
<wdkrnls>I wish there was a safe way to know what I could get rid of in the default profile. If I delete everything, would that really be that bad?
<singpolyma>Though I'm not sure if the manual is up to date for inputs working with cargo or not
<singpolyma>f1refly: latest manual has devel in the url
<wdkrnls>I was originally thinking of having multiple profiles like in the Guix Cookbook.
<jpoiret>wdkrnls: in what sense?
<jpoiret>you'll lose programs for sure, but you won't bork too much i think
<jpoiret>you can always roll back too
<f1refly>....can I close a patch and just redo the work and submit it again after I read the new documentation?
<f1refly>also the devel manual says the same thing as the 1.3.0 manual
<singpolyma>It still says inputs don't work? Probably no one has updated the manual yet then. It's withing last few months that got fixed
***Guest66 is now known as suseJdoG
<jab>howdy guix!
<jab>tschilptschilp23: did you get your problem sorted?
***iyzsong- is now known as iyzsong
<tschilptschilp23>jab: kind of! I put all the info from the perfect setup into an interactive function in my emacs-init-file. Now I can load it on demand, and after an emacs-restart my 'shell' still works without this glitches!
<tschilptschilp23>I labelled it 'hack-on-guix' ;)
<jab>tschilptschilp23: haha. That's pretty cool.
<f1refly>singpolyma: no, that was never written anywhere. It says there that #cargo-inputs should be used for source-only inputs (?) and inputs should be used for inputs that are... not source only i guess?
<f1refly>I'm not sure how rust is supposed to be packaged at all judging from from both docs and other crates
<wdkrnls>jpoiret: in the sense of `guix package -i emacs -p ~/my/editor`
<wdkrnls>I haven't quite figured out to what extent that these other profiles are supported. They are documented in the Cookbook and part of the package command interface, but no one seems to recommend them.
<wdkrnls>Instead they talk about guix environment or guix shell, even though those seem better for the final stages of development instead of the very early stages when you are just trying a lot of things.
<jpoiret>internally, shell and environment both use temporary profiles
<nouun>I'm trying to run valgrind but it says the symbol 'strlen' is not found while processing, I have gcc-toolchain. Am I missing something else|
<jpoiret>so you'll get the same functionality, but in an imperative (vs. declarative) fashion
<jpoiret>you can totally do what you suggested!
<nouun>The full valgrind output:
<jpoiret>don't let there be too many profiles though, since you have to update them manually etc...
<jpoiret>i use -p to test `guix pull` related changes and all but there are uses for non-default profiles :)
<jpoiret>nouun: you'll need glibc:debug i think
<nouun>I did `guix environment glibc:debug` but still same error.
<nouun>Oh, found a workaround on a mailing list.
<jpoiret>guix environment gives you the dependencies of the given packages by default
<jpoiret>you want either `guix environment --ad-hoc glibc:debug` or `guix shell glibc:debug`
<jpoiret>either way, i think you'd need to include gcc-toolchain in the shell invocation, otherwise it won't set the proper search paths
<wdkrnls>Since a profile is just an object in the store, I guess it makes sense that I can just archive it and export it to other guix systems. That sounds nice.
<jpoiret>it's not just a thing in the store though, it's also a special gc root that lives in /var/guix/profiles/per-user/xxx/
<jpoiret>this lets you account for generations
<jpoiret>but you could definitely export it to other guix systems. The preferred way would be via a manifest though, so that you're able to cross-compile
<wdkrnls>That makes sense.
<wdkrnls>guix package: error: rename-file: Is a directory
<anadon>jpoiret: Are you someone with merge access?  54630 has been waiting a few days and I want to get it merged so I can better work on libantlr4-dev and libantlr4 packages.
<wdkrnls>that seems quite an unusual error message to me.
<jpoiret>wdkrnls: -p doesn't take a trailing slash, be careful
<jpoiret>that usual POSIX behaviour i think, you want to operate on the symbolic links
<jpoiret>anadon: unfortunately not :)
<anadon>Gah!  It has been sitting for days, ready to review or merge but it got pushed so far down the stack I'm worried that it has been forgotten.
<jpoiret>as is unfortunately the case for a great deal many patches
<anadon>Just not enough maintainers?
<wdkrnls>hmm, I didn't use a trailing slash, but I did use the tilde.
<jpoiret>this won't mean that your patch gets merged faster, but you could try reviewing other patchsets, ie testing them locally and all
<jpoiret>anadon: yes
<jpoiret>wdkrnls: the tilde should be expanded by the shell automatically, so i'm not sure what's wrong here
<jpoiret>are you sure you're operating on a profile symlink?
<anadon>I wish there were a DoD or DoE grant Guix qualified for.
<jpoiret>most maintainers are based in the EU
<wdkrnls>no, what happened was that I got some error about the profile.lock file being missing and I wildly missinterpretted it.
<jpoiret>also, i'm not sure all maintainers would agree with a DoD grant :p but alas
<wdkrnls>So, I created a directory for the profile.
<wdkrnls>And that seems to be what has caused that error.
<wdkrnls>I deleted everything and tried again and it worked.
<anadon>jpoiret: It is really more of a source of money than a stand on US Military action.  That's how it seems to be treated these days.  Fund everything from the perspective of the military, even if it has no real military purpose.  Because MERICA.
<jpoiret>right, but I know that in some maths academic circles im familiar with, there was a debate about DoD-funded research
<jpoiret>the issue though is that researchers tend to need financing dearly, so i'd tend to agree with you
<anadon>Just need Boomers to GOOTW.
<florhizome[m]>The weasyprint package goes on endlessly at 80% testing, I doubt this is normal. It’s a dependency for something I‘m building
<florhizome[m]>Just try ‚guix build weasyprint‘
<sneek>Yey! atka is back :)
<atka>sneek: botsnack
***sneek_ is now known as sneek
<Guest66>Trying to build gnunet-gtk from git. Glade is one of the deps, but when I put it in the config.scm, it does not find it. I have gnome packages definition. Any idea?
<jts>Is there a way to append to .profile using guix home the way one can do with .bashrc and .bash_profile?
<jts>I make a few additions to the default home-bash-configuration so I'd rather not have to rebuild it by hand XD
<jts>really, the main issue I'm having is that GUI packages installed in special profiles don't show up in Gnome's application launcher. I'm sourcing them in .bash_profile but thought .profile might be needed for that.
<Guest66>in the package definition of the gnunet-gtk i find " (inputs `( ("glade3" ,glade3)" but it does not exist.
<anadon>Guest66: Looks like the package definition needs to change to `(inputs ( glade@3 ))` or something.
<anadon>`glade` exists, just without the numbering in its name, which is how package names are supposed to work.
<Guest66>anadon Yes but I have found with the "guix edit glade" that it is defined as glade3
<Guest66>Still guix search don't find it
<Guest66>libpangocairo is the next missing piece. Where does it sit?
<nckx>guix search glade will. The CLI doesn't deal with variable names.
<anadon>And the modules are imported correctly...
<anadon>Odd.  You'll need someone more experienced than me.
<Guest66>anadon Thanks anyways
<nckx>Add pango.
<nckx>There is no libpangocairo. It's a file provided by pango. Cuix doesn't index or search files (yet).
<nckx>*no libpangocairo package
<nckx>Looks like they left.
<anadon>nckx: Do you know who is active on here who has commit access that I can bother?  I need a patch merged so I submit two additional dependent packages.
<anadon>Or should I just start maintaining my own channels?
<nckx>Which bug?
<anadon>It adds the new version of utfcpp, sets a default version of utfcpp, and patches packages which don't built and test correctly using utfcpp.  Since utfcpp is a header only library, builting and testing should be sufficient to ensure correct behavior.
<nckx>WDYM bf 'should be closer'?
<anadon>To conform to Leo
<anadon>'s requests.
<nckx>So in fixes mkvtoolnix?
<anadon>Yes.  And Wargame2100, which also had an issue with the new version.
<nckx>I'll get me laptop.
<anadon>All other packages seemed happy with the new version, and so I left them with the utfcpp default.
<anadon> \nckx gets his mallet
<anadon>"Stupid guix!  Ooga booga booga!"
<nckx>I find that much as with computers in general, my exclamations of 'stupid guix!!!' are frequently followed by a '...oh. ah. right. oops.' somewhat later.
<anadon>I've done that twice this past week.
<the_tubular>I feel that.
<nckx>By the way, Leo's nick here is lfam.
<nckx>In case that's news.
<anadon>It is.
<anadon>I've been away for like 2 years.  Forgotten a bit.
<nckx>Oh, welcome back.
<anadon>Huh.  `guix authenticate` fails with `Permission denied: "/etc/guix/acl"`
<anadon>Good to be back.  I need to get the hell out of my current job, so that means outside projects for exercise and exposure.
<nckx>anadon: Running it as root will probably fix that, but it's not a supported user command.
<nckx>Ouch. Best of luck.
<nckx>error: required file 'build-aux/texinfo.tex' not found
<nckx>Hm. The laptop is a bit out of date.
<anadon>I have a senior coworker that skips build in object init, and then added a dummy setupMaster which only serves to call setup.  God forbid he have to change how he works, even slightly.
<nckx>I don't know what any of that means but will substitute my own, suitably scary, metaphor.
<anadon>Imagine the most anti-functional code you can.  Like Fortran pre-if-else block code.  That.
<nckx>Entrenched senior fake gurus are the worst.
<singpolyma>I once saw smalltalk written by someone who only knew C and Did Not Want To Change
<singpolyma>It was super fun
*nckx bootstraps Guix to appease the Guix gods.
<nckx>As always when I think ‘I have 10 minutes, I'll commit to committing something’ :-/
<anadon>The worst part?  He's like 35, and he somehow pulled this_in python 3_.
<singpolyma>I presume you're using "35" as young but it's hard to tell
<nckx>Ahem. 35 is young, bud.
<anadon>Refuses to actually engage with me as if I know anything.
<anadon>That's what I'm referring to.  He's young and this messed up.
<singpolyma>nckx: not when it's older than oneself 😅
<anadon>Hey, I'm 30.
<singpolyma>anadon: child
*nckx sits on a bench, feeding the birds.
<anadon>I'm here to learn decades of experience faster than decades.  I don't have that long to live to fuck around.
<anadon>Relocating to a friend's house.  Might be on Monday or later this week.  Life gets busy.
<anadon>nckx: Thanks for the help!