IRC channel logs

2021-10-22.log

back to list of logs

<podiki[m]>nckx: I mean when you said the build farm sits idle mostly, implying we can give it more work
<rekado_>the build farm is not necessarily idle because we didn’t give it something to chew on, but because it bamboozles itself.
<vagrantc>Scheme Procedure: string? obj ... Return #t if obj is a string, else #f.
<rekado_>there are known bugs that mothacehe is working on (and has been chipping at)
<vagrantc>but ... if i use (if (string? #f) ... i get a syntax error ... what's the use of string?
<vivien>If all the build farm does is say "cannot build missing derivation", do we really need it?
<rekado_>vivien: that’s hardly a correct assessment of what it does
<vivien>(if (string? #f) "yes" "no") gives me "no"
<vivien>vagrantc, are you sure that the syntax error is because of string?
<vagrantc>vivien: https://paste.debian.net/1216333/
<vivien>vagrantc, one-legged if is "when"
<vivien>(when (string-contains ... ...) body ...)
<vagrantc>don't feel like i even have one leg to stand on here
<vagrantc>vivien: so i should use when instead of if, then ?
<vivien>Yes
<vagrantc>ERROR: In procedure string-append:
<vagrantc>In procedure string-append: Wrong type (expecting string): #<unspecified>
<vagrantc>so ... the string-append is still getting nothing
<vivien>Your (if (string? correction) ...) has one leg too
*vagrantc is surely holding it wrong
<vivien>So if it’s not a string, it will be unspecified
<vagrantc>vivien: yeah, i switched that to "when" as well, same issue
<vivien>The return value for that is unspecified
<vivien>So you can’t use it in string-append
<rekado_>add a second arm to the if that is just ""
<vagrantc>rekado_: hah, just figured that out
<vivien>Ah, maybe arm is a better term then
<rekado_>that’s because the *outer* string-append needs a string there
<vagrantc>right
<vagrantc>so now that i have my "reduced" case ... *sigh* i can rethink how to write this patch
<rekado_>by the way: you can also use format here
<rekado_>(format #true "~{~a~}" (list "Description contains typo '" "the-typo" "'\n" …))
*vagrantc is torn between learning and running for the hills :)
<vivien>Or (format (current-error-port) ...) if you want to write to stderr
<vagrantc>but thanks :)
<rekado_>format strings implement a little language with loops and all
<vagrantc>just working on adding a lint check for guix lint
<rekado_>~{ starts the loop, ~} ends it
<rekado_>so ~{~a~} means: print each of these things one after the other, thanks .
<vagrantc>this is probably key to implementing this correctly ...
<rekado_>I only mention “format” because (display (string-append … (string-append …))) is maybe a little verbose
<vivien>You can also use a more useful format string: "Description contains typo '~a'\n" (if (string? correction) ... ...)
<vivien>It will be easier to translate with gettext
<vagrantc>right
<vagrantc>basically, i want to be able to ... specify something to check against the package description, and optionally pass a suggested correction
<rekado_>one more thing: the only point of check-typos is to print a message (or not), so you don’t care about the return value. So on line 17 I’d use (when …) instead of (if …).
<vagrantc>not sure how to sanely format that
<vagrantc>rekado_: the display is just for me to do print debugging
<rekado_>there’s a format string for printing something only if it is not #f
<vivien>vagrantc, I know guix has all the pieces to read a package description, fix it, and pretty-print it back in the source code
<rekado_>if “correction” is #f then it won’t be printed
<vivien>But I don’t think it’s what you want to do.
<vagrantc>this is all in the vein of me trying to finally get https://issues.guix.gnu.org/44675 : guix lint: support for spellchecker or basic grammar
<rekado_>(format #f "~@[The correction: ~a~]" #f)
<rekado_>vs (format #f "~@[The correction: ~a~]" "moo")
<singpolyma>vivien: there's a way to pretty-print a package???
<vagrantc>rekado_: this looks suspiciously like i'm i'm aiming for :)
<vivien>singpolyma, there’s a guix style command that’s currently sleeping in core-updates
<singpolyma>I'm currently writing all my package descriptions double-quoted so that I can bake versions back into source code. So package->source would save me a lot
<rekado_>vagrantc: (when (string-contains description typo) (format #false "Description contains typo `~a'~%~@[Should be `~a'~]" typo correction))
<vivien>Well, I don’t know, maybe it’s just syntactic
<rekado_>see (guix import print)
<rekado_>it can turn a package value into an s-expression
<rekado_>b
<vagrantc>rekado_: that is pretty spot-on, thanks!
<rekado_>glad to be of help!
*rekado_ —> zzzZ
<guest1350>what's gnu store?
<hrnz>it's like the nix store, but with a cooler name
<guest1350>it says read only
<GNUtoo>Basically in traditional GNU/Linux distributions when you install a package it ends up everywhere: the executable are in /usr/bin, the libraries in /usr/lib, the documentation in /usr/share/doc etc
<GNUtoo>While finding things is easier you also have many issues with such design, for instance you can have two executable of the same name in /usr/bin as they'd have the same path
<GNUtoo>it also doesn't support being interrupted in an update for instance (like quiting in the middle of apt upgrade is a very bad idea for instance)
<GNUtoo>So with guix each package is being installed in its own directory in /gnu/store/
<GNUtoo>This fixes all theses issues but you also got some disadvantages along the way
<GNUtoo>The guix manual has more information on all that
<GNUtoo> https://guix.gnu.org/manual/en/guix.html#The-Store
<GNUtoo>To simplify things, a derivation is very similar to a package in a regular distribution
<guest1350>thanks
<guest1350>how do i change torrc?
<GNUtoo>That's also one of the advantages or disadvantages of guix depending on what you are looking for, there is a scheme API for handling things like that
<GNUtoo>This is the documentation: https://guix.gnu.org/manual/en/guix.html#index-tor_002dservice_002dtype
<GNUtoo>but you need the bigger picture to be able to understand it
<GNUtoo> https://guix.gnu.org/manual/en/guix.html#System-Configuration is the bigger picture
<the_tubular>How do I set up network interfaces in guix ?
<GNUtoo>Same answer
<GNUtoo> https://guix.gnu.org/manual/en/guix.html#System-Configuration
<GNUtoo> https://guix.gnu.org/manual/en/guix.html#Networking-Services
<guest1350>thanks
<guest1350>and obfs4 bridge for client?
<GNUtoo>For that you probably need to create a service with some scheme code for that, or add support for it in guix as it would make the code cleaner
<GNUtoo>And you probably also need to package obfsv4
<GNUtoo>ah there is go-github-com-operatorfoundation-obfs4 now
<GNUtoo>so there is at least a package for it
<GNUtoo> https://guix.gnu.org/manual/en/guix.html#Defining-Services
<excalamus>good Evening, guix!
<nckx>Hi excalamus!
<excalamus>is the proper way to do a shebang in Guix with /usr/bin/env?
<robin>excalamus, #!/usr/bin/env ...? i'm not sure i understand the question
<excalamus>instead of the usual #!/bin/bash, since guix doesn't have bash there, use #!/usr/bin/env bash so that env will look up the right path to bash in the store
<robin>oh i see
<robin>yes, that'd be the correct way to invoke bash
<nckx>If you're writing scripts for, e.g., ~/.local/bin, yes. That will work across most distributions.
<nckx>If you're writing a Guix package, you refer to bash by its store name.
<singpolyma>Or make a symlink in /bin ?
<jgart>Hi, has anyone tried ssh'ing into a guix container?
<excalamus>okay
<excalamus>using env works, just wasn't sure if there was a better way or something
<excalamus>thanks
<nckx>Nope, it's the recommended bestest practice.
<robin>(#!/bin/sh is also bash iiuc, but might not be so forever, and possibly it might start in sh-emulation-mode that way, dunno)
<excalamus>cool
<robin>yeah, i should clarify that it's for nonpackaged scripts, not packages
<dstolfa>sadly there's no common "correct" way to invoke a shell :(
<dstolfa>but doing it via env is probably best
<excalamus>good point about package versus script
<robin>singpolyma, you'd use extra-special-file for adding /bin/bash if you wanted that on your system, v. (info "(guix)Base Services")
<robin>(the advantage being that the symlink would be kept up-to-date with bash's store location)
<singpolyma>robin: nice! Even better
<singpolyma>Way better than /usr/bin/env IMO
<nckx>Not really.
<nckx>It's less likely to work elsewhere.
<excalamus>man, there's something about getting a gui window on the screen that makes me is happy. Thank you to the people that got sdl2 packaged!
<apteryx>nckx: such as on another Guix System? :-) I can't think of common GNU/Linux distros shipping without /bin/bash; still, that's good enough a reason for me.
<apteryx>bah, seems I can't use ,(force some-promise) as an input, at least for 'guix show' -> error: lld-as-ld-wrapper: unbound variable
<nckx>apteryx: For example, but other distributions such as Nix still exist. I'm sure there are others. Expecting ‘portable’ scripts to use “/usr/bin/env $SHELL” is reasonable.
<apteryx>I agree :-)
<apteryx>is someone awaken enough to understand what's going on here? https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen-batched-changes&id=ad2d1c5b5c0fdcb5aedbbc2dfea6f802364e521d. I need to resolve this FIXME.
*nckx looks at clock.
<jab>apteryx: nope...looks interesting...
<nckx>…no, no it's probably not legal for me to debug things at 5 AM.
<jab>hahaha.
<nckx>Got to love non-trivial FIXME comments that themselves end with ‘well I guess it seems that this might something I guess’. You just know you're going to have a great time.
<apteryx>hehe
*nckx takes own advice, goes to bed; night all o/
<apteryx>night!
<apteryx>jab: thanks for checking, eh
<apteryx>seems a cycle when evaluating make-ld-wrapper; I recall seing it had to do about the inputs it pulls (guile and bash)
<apteryx>but I can't reproduce this anymore (I just see the not so useful 'ice-9/eval.scm:293:34: error: make-ld-wrapper: unbound variable')
<apteryx>one idea is to lazily reference these make-ld-wrapper inputs (default arguments) and see if it helps
<apteryx>(and provide them explicitly)
<apteryx>perhaps something like this: https://paste.debian.net/1216354/
<apteryx>well, the rough idea (the diff is not quite there yet)
<apteryx>nope, that's clearly bogus; the variable needs to be defined outside the gexp
<apteryx>I guess I'll follow nckx soon ;-)
<apteryx>ah, canonical-package is already lazy
<apteryx>(which make-ld-wrapper uses)
<apteryx>I guess what is happening here is that by applying make-ld-wrapper at the top level, we defeat these lazy references (we try to resolve them at the time the modules are loaded)
<apteryx>and there's a cycle accessing these references from (gnu packages llvm) somehow
<apteryx>I've now made it a package, the same as the original 'ld-wrapper'
<lilyp>Hmm, does --verify=contents,repair perhaps miss certain files?
<apteryx>what makes you think so?
<apteryx>nckx: fixed :-)
<ArneBab>Why should I *not* start shepherd in ~/.bash_profile via shepherd 2>/dev/null >/dev/null — and what do use instead? Requirement: I want the same shepherd instance running for all my logins. I want it to keep running when I log out. I only want it to stop at shutdown or reboot.
<ArneBab>I want it to run with user-permissions
<ArneBab>Can I get the make-kill-destructor to wait until the process in question has exited?
<apteryx>look at the jami-service-type, I think I do something like this using waitpid
<ArneBab>Thank you!
<ArneBab>where is it defined?
<ArneBab>(ripgrep does not find it in the guix repo)
<drakonis>do a git grep jami-service-type instead
<drakonis> gnu/services/telephony.scm
<drakonis>oops
<ArneBab>ah, got it, thank you! My repo was old …
<ArneBab>somehow (waitpid PID) always complains that there are no child processes
<ArneBab>and does not wait
<civodul>Hello Guix!
<mothacehe>hey guix!
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, apteryx says: any clue why core-updates-frozen-batched-changes on the CI keeps failing the evaluation stage?
<vivien>Hello guix!
<mothacehe>apteryx: the evaluation logs are not really helpful here. I'm running a "make cuirass-jobs" to see if I can get more details.
<civodul>howdy mothacehe!
<mothacehe>hola civodul :)
<qzdlns[m]>hi guix!
<jonsger>morning guix :)
<abrenon>good morning guix
<civodul>nckx: hey! "two month old" or "two months old"?
<civodul>we say "nine inch nails", but OTOH "nails" is a noun and "old" isn't
<civodul>hmm
<brendyn>both of those phrases are correct but imply different meanings
<brendyn>A two month old baby
<brendyn>... is two months old
<thorwil>hi! ingen has an optional dependency on webkit. i added ("webkitgtk" ,webkitgtk) to inputs, but it still says during configuration: Checking for 'webkit-1.0 >= 1.4.0': not found
<thorwil>guix webkitgtk version is 2.32.4
<thorwil>ingen’s src/gui/wscript contains "conf.check_pkg('webkit-1.0 >= 1.4.0'" and i did not find anything more specific
<brendyn>thorwil, if its optional maybe dont bother adding it?
<thorwil>brendyn: i think it’s used for showing plugin info html, which does sound useful enough
<brendyn>I think it is looking for a very old and deprecated webkit version. it will use pkg-config to look for webkit-1.0.pc. webkitgtk ontains webkit2gtk-4.0.pc, and qtwebkit has Qt5WebKit.pc, so I don't think we have it in guix.
<thorwil>i see ... guess i could ask the author / file a ticket about that, as i have little hope just manipluating the wscript would be enough
<thorwil>thanks brendyn
<wigust>hi guix
<qzdlns[m]>=jupyter notebook= should make a server which forwards to my LAN right?
<qzdlns[m]>from another device, I can ssh to the hosting device, but nothing from an hdevicettp GET on the inet4 ip + port
<qzdlns[m]>okay, fixed -- so it was a default config thing, and some options were required for my network - if you have a secure LAN, then make it wide open with =JUPTER_CONFIG_DIR="$HOME/.config/jupyter" jupyter notebook --generate-config= -> then edit as described https://stackoverflow.com/questions/42848130/why-i-cant-access-remote-jupyter-notebook-server
<excalamus>good morning, Guix
<jpoiret>alright, finally `guix system reconfigure`d with the swap changes, and it works!
<excalamus>sweet!
<jpoiret>so, i'm wondering what would be the best way to transition: 1) no deprecation, everyone has to change their config 2) deprecate for a bit, keeping both in swap-devices 3) use new field swap-space (better name imo) and deprecate the old one
<jpoiret>also when i'm done, should we slate it for inclusion in c-u-f?
<apapsch>Hi! Emacs doesn't like Victor, it seems. After installing font-victor-mono, it doesn't show up in the font selection menu. font-jetbrains-mono on the other hand does show up
<apapsch>inspecting victor and jetbrains .ttf files with the file utility: http://codepad.org/3tFNqXbG
<apapsch>a difference is "Macintosh" in Victor and "Microsoft" in Jetbrains
<jpoiret>anyone using a swap partition (not swap file) on core-updates-frozen that'd be willing to test it out with the swap-device patch?
<jpoiret>i don't have a partition handy for that and don't really know the ins and outs of guix system vm to make it have a swap partition
<apteryx>nckx: I think the reason the single 3900X machine seemed faster is probably due to faster per-core performance and SSD storage; the longest things to build often happen serially (bootstrapping rust for example), where this matters. I'm just the build farm would take the win if there would have been 60000 packages to build (say no multiple architectures)
<apteryx>I'm sure*
<black_syntax>is guix available for 32 bit systems?
<apteryx>yes
<jpoiret>apapsch: are you seeing it with fc-list?
<jpoiret>there might be some caching shenanigans
<jpoiret>are you running on 'master' or 'core-updates-frozen'?
<apapsch>jpoiret: thanks, fc-cache -f did the trick. I assumed guix does the necessary steps when it prints "creating font directory" (or similar in English)
<jpoiret>see https://issues.guix.gnu.org/49107 for the related issue
<jpoiret>it will soon
<apapsch>nice!
<apapsch>what is the policy regarding static libraries? e.g. libsodium includes .a file, while zeromq is built with --disable-static
<apteryx>they're usually not enabled, removed or kept in a "static" output if they're needed/wanted
<apteryx>the reason is they take a lot of disk space and are typically unused in Guix (where almost everything is dynamically linked)
<vivien>And, you can’t apply security fixes
<jpoiret>well you can, just not graft them right?
<mbakke>apteryx: unless something has changed recently, I think cross-module inheritance should be avoided (ref nss<-> nss-certs)
<apapsch>thanks for your inputs. my use case is creating binary of a go program that runs anywhere. i'll look into guix pack
<jpoiret>i added a new swap space section in the manual, but makeinfo is complaining of node difference between menu and sectioning
<jpoiret>i added swap space in the detailedmenu at the beginning too
<jpoiret>any ideas?
<jpoiret>my bad, just found out there was another menu i had to add it in (ie the one of the big subsection i was adding it in)
<black_syntax>what does 'sudo guix system reconfigure /etc/config.scm' do and how often do I need to run it?
<jpoiret>it reads your configuration and computes a system derivation according to it
<mbakke>apteryx: IIRC 6500c9a5b364616e38a7e03aa4516fc2d7cee876 came to be due to some "unbound variable" error; perhaps a workaround could be to explicitly export an %nss-source variable
<jpoiret>mostly, you want to run it whenever you want to update your system
<roptat>hi guix!
<jpoiret>when you `guix pull`, you upgrade guix-the-program (containing the list of all guix packages for example, and also guix system definitions). So whenever you do that, you'd then want to use those updated package list and guix system definitions to update your own installed packages and guix system
<jpoiret>hope that's clear enough
<jpoiret>and that's what `guix package -u` and `guix system reconfigure` are for respectively
<roptat>basically, "guix pull" then "guix upgrade" and "sudo guix system reconfigure ..."
<roptat>thorwil, isn't webkit different from webkitgtk?
<jpoiret>can the availability of a device depend on more than one other mapped-device? i'm not sure personally but i don't really know about setups like raid or multi-disk btrfs
<thorwil>roptat: there is no plain webkit package, there are many references to webkitgtk and ingen is also a GTK application.
<black_syntax>how do i know if my hardware will support gnu guix?
<mothacehe>black_syntax: you can use an ISO installation image to check if your hardware is detected
<black_syntax>how?
<jpoiret>well, you should mostly check if your network card/graphics card has completely free drivers (no binary blobs). the rest should probably be ok
<jpoiret>the iso installation image has no graphical session though right?
<vivien>The installation image won’t tell you if your graphics card is supported
<mothacehe>the ISO is available here: https://guix.gnu.org/en/download/latest/, you can copy it on an USB drive an boot from it.
<mothacehe>but it won't help with graphics indeed
<black_syntax>also, will stable be a better choice in terms of harware support or latest
<black_syntax>hardware*
<mothacehe>should be the same but the stable image has known installer bugs
<vivien>If you install h-client on your laptop, it will search for user reviews for your hardware
<black_syntax>what does reconfiguring /etc/config.scm do?
<black_syntax>and how often should i run it
<roptat><jpoiret> when you `guix pull`, you upgrade guix-the-program (containing the list of all guix packages for example, and also guix system definitions). So whenever you do that, you'd then want to use those updated package list and guix system definitions to update your own installed packages and guix system
<roptat>mh, maybe this is more relevant: <jpoiret> it reads your configuration and computes a system derivation according to it
<vivien>You can use the unattended-upgrades service to run the reconfigure automatically
<mothacehe>black_syntax: reconfiguring will possibly update all your services, root install packages, bootloader and kernel version
<jpoiret>in more simple terms: it upgrades your system with the version of guix you're using (that's why you need to `guix pull` to get the latest guix version before updating)
<black_syntax>then what does update and upgrade do?
<jpoiret>upgrade simply upgrades the packages you have installed in your user profile
<vivien>update does not exist
<jpoiret>you should read https://guix.gnu.org/manual/en/guix.html#Package-Management
<jpoiret>with the caveat that it doesn't talk about the system profile at all
<jpoiret>but you can think of it as a profile 'for the system' rather than for a user, it contains the kernel and everything needed to boot
<apteryx>uh, h-client depends on python-2
<singpolyma>If there have been any changes might want to link to the up-to-date manual
<roptat>guix has multiple profiles, most importantly there is a per-user profile and a global profile on the guix system; the global profile contains services and packages available to all users and is configured by your system config with "guix system reconfigure", your user profile is managed separately by "guix package" and friends
<apteryx>let's rewrite it in guile 3 ;-)
<singpolyma>apteryx: nothing wrong with python2 :)
<vivien>In all situations, guile 3 is better than python 2!
<roptat>:)
<vivien>(except in the lexicographic order)
<apteryx>mbakke: ah, fun, I'm repeating myself in time :-o
<black_syntax>is there a base package package in guix that install the necessary packages
<roptat>%base-packages
<roptat>(you can only use this in your system config though)
<jpoiret>necessary packages for what?
<apteryx>mbakke: hmm I don't seem to trigger it so far, but thanks for the heads up
<vivien>A set of base packages will be installed by the system configuration.
<black_syntax>jpoiret: like git ncurses etc. (arch has its by the name of base-devel)
<jpoiret>no, these have to be installed seperately
<jpoiret>if you just want to work on something that is already packaged in guix though, you can use `guix environment the-package` to drop into an environment with all the necessary build tools in it (no git tho, since it's not a build dependency most likely)
<jpoiret>see https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-environment.html#Invoking-guix-environment
<jpoiret>this is the recommended way to develop under guix: you don't want to install libraries like ncurses globally, only use them when you need to
<roptat>also, some of us provide a guix.scm file in our projects, that you can use to develop with "guix environment -l guix.scm --ad-hoc git", or a manifest.scm that you can use with "guix environment -m manifest.scm --ad-hoc git"
<jpoiret>is it just me or is the linux package not installed in the system profile?
<jpoiret>how does guix gc not collect it then
<roptat>it's not part of the profile, but it's part of the system generation, which contains more than a package profile
<roptat>the system generation is a gc root, not the system profile
<roptat>*system package profile
<jpoiret>oh right
<jpoiret>guix package -p really is handy
<black_syntax>how do i set GUIX_PROFILE variable
<jpoiret>it depends
<jpoiret>if you're running on guix system, the default /etc/profile will do it for you
<black_syntax>wdym guix system?
<jpoiret>well you can use guix as a package manager on any linux distribution
<jpoiret>and also use guix as a distribution itself
<black_syntax>i have the distribution
<jpoiret>the latter is called guix system
<black_syntax>ok, continue to explain
<jpoiret>ah, well then you can look at /etc/profile to see how it's done, and most likely your shell sources it on login (or if you login with a supported DM)
<black_syntax>but i always get a hint after installing a package to source GUIX_PROFILE
<jpoiret>oh, well you may be using a .bash_profile, .zprofile or something similar, no?
<jpoiret>if so you need to source the default /etc/profile in it, so that it can setup the default profile for you
<rekado>black_syntax: the hint is longer than that. It says to set GUIX_PROFILE and then to source (“.”) the generated etc/profile file.
<black_syntax>yes
<black_syntax>it is
<rekado>the reason is that the etc/profile file now contains more variables than before
<black_syntax>i added both lines to ~/.bash_profile, but nothing happens
<rekado>so if you want these variables to be available in your *current* shell session then you should follow the hint.
<rekado>you will not see the hint when no *new* variables are added to the etc/profile file
<rekado>if it’s sourced in .bash_profile then it’s up to you if you prefer to start a new shell session or follow the hint to change your *current* shell session.
<rekado>Guix cannot change the environment variables of your current shell session.
<black_syntax>done, just added it to my bashrc
<rekado>uhm, don’t set GUIX_PROFILE in .bashrc.
<rekado>and better don’t source the etc/profile file there either
<rekado>doing so effectively breaks “guix environment”, which launches a sub-shell with new environment variables.
<rekado>setting this in .bashrc will override these environment variables again.
<black_syntax>so what should i do?
<rekado>setting this up in .bash_profile, on the other hand, only sets the variables for login shells; this means that sub-shells still work fine.
<black_syntax>bash_profile isn't recongnizing it for some reason
<apteryx>mbakke: are you looking at the cufbc branch? I fixed a problem with lld-as-ld-wrapper (guix show ungoogled-chromium would complain of an unbound variable) and got rid of gdk-pixbuf+svg entirely. If you have time to test it I'll repush the branch (for the last time I'd hope).
<apteryx>I'm rebuilding it again or berlin; it's currently at rustc-1.44.1
<roptat>black_syntax, bash_profile is only run on login shells, which your new shells (or current shell) are not
<roptat>black_syntax, so, you should put that in bash_profile, *and* manually run the hint commands on your current shell
<vivien>If you can, log out and log in again
<vivien>That way, every shell you open will be set up.
<mbakke>apteryx: I'm referring specifically to d7691a1dbb2d48cff8ea84e862d844db5f6a8507 :) I'll see if I can find a way to trigger it
<mbakke>I've built the branch locally and haven't spotted any regressions
<vivien>I wish guix system could set up guix home for the users
***wielaard is now known as mjw
<mbakke>I do suspect a regression with elogind's polkit support though, but did not verify it yet (would be good to have a system test for it): https://github.com/elogind/elogind/issues/206
<nparafe>For some days now I am trying to find a solution. When I install a certain package (gnucash and/or gadjim), after restarting my system it cannot get pass the login screen. When I type the password it get's back to the login screen without showing the desktop. I need to do guix remove gnucash in order to see my desktop.
<apteryx>nparafe: is this on a foreign distribution?
<nparafe>@apteryx yes
<apteryx>mbakke: OK! we don't have libpolkit as an input at build time?
<mbakke>apteryx: no, that would cause a circular dependency
<apteryx>I see
<apteryx>then perhaps we need to apply this patch: https://github.com/elogind/elogind/commit/715ce0a6459e418f92e74c7ce52df3244c18f383
<mbakke>apteryx: I've had an update for elogind with that patch for ages, but never got around to properly testing it :-) I'll give it a go on Sunday
<apteryx>neat :-)
<nparafe>if it helps I am using trisquel 9 (ubuntu 18.04)
<rekado>nparafe: I wonder if this might be related to XDG_* variables that are set by etc/profile
<roptat>I think I had that before, although I wasn't able to find the culprit
<apteryx>it could be PYTHONPATH, I think there were reports of it messing a login in the past
<roptat>what the difference in ~/.guix-profile/etc/profile, between when you have and you don't have gnucash?
<roptat>nparafe, ^
<nparafe>roptat: I will try to investigate it and post my findings
<nparafe>rekado: if you can, please explain
<florhizome[m]>hello all^^ so the matrix room was an unofficial one lol.
<florhizome[m]>Well, I‘m exploring guix and it’s pretty cool but when I‘m trying to „sudo guix system reconfigure ~/...system..scm“ it just does nothing, no output. Before that I got some errors that I fixed.
<nparafe>roptat: The differences before and after --> https://paste.debian.net/1216405/
<civodul>comrades, zimoun wrote about reproducible & verifiable Docker images: https://hpc.guix.info/blog/2021/10/when-docker-images-become-fixed-point/
<roptat>florhizome[m], you mean it's frozen, or it returns with no output?
<roptat>nparafe, I think the issue is with XDG_DATA_DIRS; maybe you can try to set it in .bash_profile? something like "export XDG_DATA_DIRS=/usr/share" in ~/.bash_profile
<roptat>I suspect there is simply no value by default, so without gnucash, the default is used, and when guix sets it, the default disappears; if you set the default in .bash_profile, it will be extended instead
<roptat>(although now I'm not sure anymore if /usr/share is the right default)
<roptat>nparafe, should be "/usr/local/share:/usr/share" according to archlinux
<nparafe>roptat: so, to verify that I understand, In order to try your fix, I need to add the line: "export XDG_DATA_DIRS=/usr/share" in /home/nparafe/.bash_profile is that correct?
<roptat>yes, somewhere near the top, so ~/.guix-profile/etc/profile is loaded *after* that
<roptat>or maybe better: export XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}/usr/share:/usr/local/share"
<mahmooz>anyone have any idea what i would have to build an iso for my raspberry pi from my laptop?
<mahmooz>what is the command to generate an iso for aarch64
<roptat>mahmooz, see https://guix.gnu.org/manual/devel/en/html_node/Building-the-Installation-Image.html#Building-the-Installation-Image
<roptat>instead of armhf-linux, use aarch64-linux
<roptat>although, I don't think we support the raspberry pi
<mahmooz>wdym
<mahmooz>you dont support it as in guix doesnt run on raspberry pi?
<mahmooz>or as in you dont like it?
<roptat>as in I think the raspberry pi needs a propriatory blob to even boot, though I might be mistaken
<mahmooz>oh ye i heard about that somewhere too
<mahmooz>i see
<mahmooz>alright thanks i hope it works probably gonna have to modify my config to fit an arm64 board lol
<roptat>maybe you can use another technique: boot on another distro, install guix and run something like "guix system init /etc/config.scm /", basically use the foreign distro as the install system, and install over it
<mahmooz>ye but currently my raspberry pi has no distro on it
<roptat>but I don't see a u-boot definition for a raspberry pi, so it might be tedious
<mahmooz>dont wanna install a distro specially for that
<nparafe>unfortunatelly adding this lines didn't help. After isntalling gnucash and logout I cannot log back in without removing it.
<roptat>nparafe, can you check when loging in on a tty that XDG_DATA_DIRS is set properly?
<roptat>it should have both /usr/share and /gnu/store/...
<nparafe>btw my /home/nparafe/.bash_profile was empty.
<roptat>mh, so maybe the line I gave you should go in /etc/profile
<nparafe>roptat: sure how can I check that XDG_DATA_DIRS is set properly?
<roptat>just print it: echo $XDG_DATA_DIRS
<nparafe>Ok
<roptat>what I want is that it's set to /usr/share and /gnu/store (in any order, maybe /gnu/store first) when gnucash is also installed
<florhizome[m]><roptat> "florhizome, you mean it's frozen..." <- It returns with no output.
<roptat>florhizome[m], can you share the content of the file (using paste.debian.net for instance)
<nparafe>before and after gnucash installed echo $XDG_DATA_DIRS command gives the same output: usr/local/share:/usr/share
<nparafe>pleae note that export XDG_DATA_DIRS=/usr/local/share:/usr/share exist in .bash_profile
<roptat>oh wow, I just saw disarchive in action :D
<nparafe>correction export XDG_DATA_DIRS=/usr/local/share:/usr/share IS THE ONLY THING THAT exist in .bash_profile
<roptat>nparafe, ok, sounds like this is not the culprit then
<roptat>mh, but I don't see what the issue could be then...
<nparafe>roptat: thank you for your efforts
<roptat>sorry I couldn't help in the end
<nparafe>no problem. I will try on a fresh install again in a couple of days
<nparafe>btw is it possible to install an older version of gnucash?
<apteryx>civodul: the bug https://paste.debian.net/1216410/ seems to trigger more easily when the remote is under high load (currently building ungoogled-chromium)
<roptat>nparafe, with the time-machine, if you find a commit that had the version you want, or with a transformation option
<nckx>civodul: You can also say ‘a two-month-old generation’. But you can't say ‘nails that are more than nine inch long’; only ‘inches’ is correct.
<civodul>apteryx: oh, i had almost forgotten about that one; selective memory maybe?...
<civodul>i should look at it
<civodul>nckx: oh i see; so "nine inch nails" but "nine inches long nails" or "nine-inch-long nails"
<civodul>do i get it right?
<nckx>Almost: the hyphens don't change the spelling; they are for disambiguation. ‘Nine inch nails’/‘nine-inch nails’, ‘nine inch long nails’/‘nine-inch-long nails’ in both cases.
<nckx>English hates you and wants you to be unhappy.
<nckx>But hey, so does French.
<civodul>hmm!
<civodul>so if it's "nine inch long", shouldn't it be "two month old"?
*civodul is confused
<nckx>A generation that is more than two months old is a two-month-old generation.
<nckx>That's not semantically correct but whatever.
<nckx>Spellinglingly it is.
*dstolfa never really learned english by learning the rules, he just kind of learned it by the sound of things
<dstolfa>"yes this sounds about right"
<nckx>‘Gweks.’
<nckx>dstolfa: To be fair, that's how us mere native speakers learnt it.
<nckx>So ‘are more than two month old’ looked like an obvious mechanical typo to me, I didn't realise it was this confusing if you dared think about it :)
<apteryx>is there a way to tell NetworkManager to always leave my default nameserver at the top of /etc/resolv.conf?
<Olivetree>Hey! Anyone available to spend some time helping a guix noob? Got some path issues (libs and perl modules not found)
<mitchell>Hello all. Can someone tell me how I can create a --pure environment with nothing but the packages used by the gnu-build-system? I imagine it looks something like "guix environment --pure --ad-hoc -e '(@ (guix build-system gnu) %build-packages)" but there is no such list.
<mitchell>I can't imagine this is an uncommon use case
<Olivetree>Perhaps some of these nice people can help me figure out why I get this when I run mpv:
<Olivetree>ALSA lib dlmisc.c:341:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/gnu/store/z1iyvbvnkd7zkjxsx157n6qx2iwzxq7p-alsa-lib-1.2.4/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
<Olivetree>I mean, it's looking in the wrong place: /gnu/store/m8phwrlpkky6cj2fbr0lar5b306882jp-alsa-plugins-1.2.2-pulseaudio/lib/alsa-lib/libasound_module_pcm_pulse.so
<mitchell>are you running guix system?
<Olivetree>But why? And more importantly, what can I do about it?
<Olivetree>No, I'm on top of void-linux
<mitchell>What do you mean its looking in the wrong place? I assume 1.2.4 is the place it's looking and 1.2.2 is the place you want
<Olivetree>I don't think it's about the version. Some lib from alsa-lib package is essentially looking for a lib from another package (alsa-plugins) inside alsa-lib/lib/
<Olivetree>since ldd finds all libraries, I'm assuming it's dlopening $(dirname /path/to/itself.so)/alsa-libs/libasound_module_pcm_pulse.so. This will never work, as that package doesn't have that lib
<mitchell>Somehow there is an inconsistancy in what guix thinks is happening on your system. Those paths get set via RPATH at build time
<mitchell>ldd takes hints from RPATH to look in non standard locations such as gnu/store
<Olivetree>The packages we're not built locally, they're from substitutes
<Olivetree>Would that matter?
<mitchell>no, all that matters is the derivation is the same
<Olivetree>Also, ldd correctly finds packages in /gnu/store from other packages
<mitchell>according to my guix, mpv has a declared dependency on alsa-lib@1.2.4
<davidl>Is it possible to leave to an interactive shell from a build process specified by the "trivial build system"? I have this problem that I can run tests for a software Im trying to package when using guix environment, but it doesn't work when I use the invoke procedure from a "manual" build spec using the trivial build system.
<davidl>(or rather some tests only succeeds in guix environment but not others)
<Olivetree>ah, it appears it's working now
<Olivetree>I think the solution was calling guix package -u several times
<mitchell>lol
<Olivetree>I do not quite understand it.. If I don't change anything and not do any `guix pull` it can still say that dependencies changed
<Olivetree>Multiple times in a row.. I just did guix package -u and it's changing a lot of packages again. Why?
<mitchell>I'm afraid that is a question for someone more wise than me. I've only been using guix for a few short months
<Olivetree>Oh, it's not working after all. I just changed directory and it couldn't find audio file
<Olivetree>I mean, I had changed directory so got an error about missing file. But if I give him an existing/valid input file it complains about missing shared libs again
<Olivetree>I started yesterday and have a bunch of questions. But first, getting it to work is more important. tlmgr also can't perl modules, I believe it's the same issue
<Olivetree>can't find perl modules*
<Olivetree>Can't locate TeXLive/TLConfig.pm in @INC (you may need to install the TeXLive::TLConfig module) (@INC contains: /gnu/store/texmf-dist/scripts/texlive /gnu/store/tlpkg /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_per
<Olivetree>l/5.30.2 /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2) at /home/raimundo/.guix-profile/bin/tlmgr line 100.
<Olivetree>Can't locate TeXLive/TLConfig.pm in @INC (you may need to install the TeXLive::TLConfig module) (@INC contains: /gnu/store/texmf-dist/scripts/texlive /gnu/store/tlpkg /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_per
<Olivetree>l/5.30.2 /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2) at /home/raimundo/.guix-profile/bin/tlmgr line 100.
<Olivetree>Oops, sorry. $ locate TLConfig.pm gives/gnu/store/0zv1sl91fz3ddq8namdfvf6yr0j1p2vx-texlive-bin-20190410/share/tlpkg/TeXLive/TLConfig.pm and /gnu/store/6dcw9z9s6lw14ky1sryqgv12kgjb6cjp-texlive-bin-20190410/share/tlpkg/TeXLive/TLConfig.pm
<mitchell>mpv-0.33.1 installs and runs correctly for me on guix system
<drakonis>Olivetree: as far as i'm concerned, texlive's been updated in core-updates-*
<drakonis>with a variety of fixes to it
<Olivetree>@drakonis I did a pull and install -u today, I should be up-to-date
<drakonis>you're pulling from master, no?
<Olivetree>Probably... whatever's the default of running the installer on another distro, I'm using it
<drakonis>it is master, yes.
<Olivetree>mitchell: does it run with alsa?
<Olivetree>I just remembered I can switch it to pulseaudio, and it started working! It doesn't solve the underlying problem though
<mitchell>i am running with pulseaudio
<mitchell>Correct me if I'm wrong but isn't pulseaudio just a layer on top of alsa?
<drakonis>yeeeeeeeeahhhhhhh
<tissevert>hi guix
<mitchell>hi
<drakonis> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/tex.scm?h=core-updates-frozen#n241
<Olivetree>It may be a layer on top of alsa, but the pulseaudio server I'm running is the one from void, not guix.
<apteryx>it'd be fun to collect resource usage statistics for each package built
<Olivetree>drakonis: how can I get that version of texlive? (probably the question is how do I pull from core-updates?)
<lispmacs[work]>I think it is more accurate to say that PulseAudio is the layer between your software applications, and whatever produces/receives sound in your system
<lispmacs[work]>which is usually ALSA devices
<drakonis> http://guix.gnu.org/manual/devel/en/html_node/Channels.html
<drakonis>here
<Olivetree>Hmm.. I know about channels, but I still don't know which channel would give me core-updates. Gonna browse some more
<mitchell>lispmacs: I see. As I understand, alsa has a kernel component + userspace libs to interface with such. I wonder if it causes problems to have multiple versions of such a library running at the same time
<Olivetree>Ah, just add (branch "core-updates-frozen").
<drakonis>yup
<drakonis>that's what you do
<lfam>Olivetree: You need to install alsa-plugins and alsa-plugins:pulseaudio
<Olivetree>I think that broke my guix.. guix search now gives a bunch of warnings of failed to load '(gnu build svg)', '(gnu installer final)', etc...
<lfam>This was tracked as bug <https://bugs.gnu.org/40832>
<Olivetree>lfam: thanks! will try that when I can
<lfam>I don't recommend using core-updates
<lfam>It's not something that is considered "usable"
<Olivetree>not even core-updates-frozen?
<Olivetree>guix install alsa-plugins alsa-plugins:pulseaudio did not fix my mpv when ao=alsa
<lfam>Using those branches is something that Guix developers do in order to find and fix bugs
<lfam>Olivetree: Regarding Pulseaudio, you probably need to make a new login shell
<lfam>What installing those packages does is make Guix set up the environment variable ALSA_PLUGIN_DIR
<lfam>And, environment variables are set when starting a login shell. For example, with `bash --login`
<drakonis>hmm, i'm curious about how that works
<lfam>Take a look at <https://bugs.gnu.org/40832>
<lfam>And commit ed1c72c3d7d6b6d3b110817fcc037cd5582ac848
<lfam>Basically, it sets up a native-search-path in alsa-plugins
<lfam>My test case for the ALSA plugins thing is `mpg123 -o alsa file.mp3`
<lfam>It will work if the plugins are set up correctly, and it won't if they are not
<Olivetree>was reading the bug report. indeed, my .guix-profile/etc/profile has ALSA_PLUGIN_DIR now. after relogin alsa works. Thanks!
<lfam>Awesome!
<lfam>It's a bit annoying that one has to install these packages... maybe there is an easier solution
<Olivetree>hmm.. I can only think of a warning message during installation or even better in package description. If I use pulseaudio I don't need these packages. If I use alsa-lib/alsa-plugins without caring about pulseaudio I don't need to install alsa-plugins:pulseaudio. So it's can only be documented, not guessed. Unless there is some suggestions system w
<Olivetree>hen certain package combos are installed
<lfam>Now, I don't remember why a better solution didn't present itself. But we did try really hard to find one
<lfam>I do remember that the upstream code in alsa-lib makes a lot of assumptions about filesystem layout and really doesn't account for something like Guix. It took some effort to even get this solution implemented upstream
<lfam>And also, this stuff "just works" on Guix System. My understanding is that these manual steps are only required on other distros
<Olivetree>what manual steps?
<mitchell>setting up your login environment
<lfam>Installing alsa-plugins and alsa-plugins:pulseaudio
<lfam>The login environment should be handled automatically on both Guix System and other distros
<mitchell>On my ubuntu machine I had to take additional steps to make sure the guix profile was available for my window manager for example.
<lfam>Oh, right. But once you've done that, you never have to do it again
<mitchell>also library search paths for development
<mitchell>yea but it took me a while to figure that out haha
<lfam>I'm curious, was that in addition to the steps listed in the Binary Installation section of the manual?
<lfam> https://guix.gnu.org/manual/en/html_node/Binary-Installation.html
<mitchell>I'm trying to convince our IT people to support guix system along side ubuntu and fedora
<mitchell>lfam: I just ran the install script and went to getting started. Probably would have been better to keep reading
<lfam>I see. I guess the installer script should just make everything work
<mitchell>In theory
<mitchell>For the most part it did, I just wanted to package libraries I wrote for work and install them like any other and to do that gcc/clangd wanted additional environment variables to make the LSP work and correctly find system headers without having to put -L flags in my makefiles
<Olivetree>I used the installer and it should contain a message informing you to relogin (or maybe it does and I was blind). If I had relogin after the installation I wouldn't have lost so much time setting my GUIX_PROFILE=~/.guix-profile (as per the `guix install` hint) and then to ~/.config/guix/ (as per the `guix pull` hint)
<Olivetree>Then I got confused about it and how I was supposed to get both my profile's guix and apps. I chose the apps. Later when I rebooted I noticed that I had both and found /etc/profiles.d/guix.sh, read it and was enlightened
<lfam>There's definitely some room for improvement around all that
<Olivetree>AFAIK, just changing the hint on `guix pull` to use _GUIX_PROFILE (like /etc/profile.d/guix.sh does) would suffice. Or remove the environment variables altogether, since they aren't used anywhere else (right?) except that hint
<Olivetree>Oh, mentioning relogin after installer would do wonders as well. The installer "just worked" for me
<Olivetree>Oh great.. after trying to use core-updates-frozen as the guix channel (because I wasn't getting texlive-bin version 2021 with just adding it to the list), guix complained that it wasn't a direct descendent of some commit. I rm'ed channels.scm and now `guix pull` returns git error: http 502
<Olivetree>Is it general? looks like server issue, but in current system state I really don't know
<Olivetree>Oh, was server indeed, it's working
<drakonis>Olivetree: for it to switch to core-updates-frozen you need to use the flag --allow-downgrade
<drakonis>i think that's the one
<drakonis>you can simply have a differently named channel instead of replacing the default guix channel
<Olivetree>But then it's package (versions) don't show in guix search or install
<drakonis>they actually do!
<Olivetree>Not here, they weren't :(
<drakonis>huh, strange.
<Olivetree>gonna try again, then
<drakonis>please notice that the default repository is guix, try naming it guix-core-updates-frozen or something
<drakonis>so it doesnt collide with the default
<drakonis>i sadly haven't tried that yet :(
<Olivetree>I'm quite confident that I had given it a different name, yes.
<Olivetree>But I must've done something different, I'm getting deprecation warnings now (packages renamed). Probably worked
<Olivetree>Now, there's something else I want to talk about here: The huge size of /gnu :P what gives? It keeps telling me it's saving plenty of space with hardlinks, yet I have 3 ffmpeg4.4 with some tens of MB each and none hardlinked
<mitchell>try guix gc :)
<Olivetree>and if I do `guix gc` and then remove a package it downloads hundreds of MB just for that
<Olivetree>But even with `guix gc` and not touching anything else I get the abusive ffmpegs (and probably lots of other similar things)
<lfam>Guix uses a lot more disk space than older distros
<lfam>For a package like ffmpeg, it's expected to have two different store items, because one will be grafted (security updates) and the other ungrafted
<lfam>3 is interesting...
<lfam>But, this isn't the sort of thing I pay close attention to. Overall, Guix only downloads the software that it definitively needs.
<mitchell>depends on your work. I'm following the great Mathieu Othacehe in trying to replace yocto/buildroot with guix. If i can use it more than one project I will save lots of space
<lfam>It's designed in a way where it needs a lot more than old distros like Debian
<drakonis>guix benefits from filesystems with deduplication
<lfam>It makes sense to me because Nix and Guix were created in the era when storage space was several orders of magnitude cheaper than when distros like Debian were founded. So the design reflects that
<mitchell>I dream of a day when I can have a build server that is building for the targets i'm working on and my poor laptop will never have to build a root file system again! Substitutes are the future for me :)
<drakonis>plus the reason it consumes a lot of storage is that there's too many small files
<lfam>And of course, storage has gotten even more radically cheap since then
<lfam>It's definitely worth making some effort to reduce space usage, but unless it's something that a person is specifically motivated to do, the opportunity cost of that effort is rather high given what else could be accomplished
<Olivetree>drakonis: I'm using btrfs. Maybe they aren't hadlinked but are CoW'ed, is that what you're suggesting?
<apteryx>lfam: I think it's worth it; it opens Guix to more devices and is often not too difficult (e.g. just adding a "doc" output and moving stuff).
<lfam>I'm not saying it's unworthy
<apteryx>perhaps one day we can have Guix on routers :-)
<Olivetree>if they never guix pull, maybe there's a chance
<lfam>I wonder how much of the "bloat" is due to not using things like a 'doc' output and how much is due to a maximal dependency graph, grafts, and multiple generations
<lfam>Like, how much can we improve without changing our values and core technology
<lfam>(I think a fully-featured dependency graph is one of Guix's values)
<drakonis>well, guix seems certainly open to improving itself
<drakonis>which puts it above others
<lfam>Grafting is a big problem for space usage
<lfam>I feel like "frequent rebuild cycles to ungraft" is always just around the corner, but we can never actually make it happen
<drakonis>maybe working on implementating more of the build systems a la carte paper could help with that?
<drakonis>it has a surprising amount of features to remedy that
<drakonis>early cutoff seems to be a way to achieve it
<drakonis>Sqqq
<drakonis>oops
<mitchell>Does anyone have a good example of a package setting an environment variable?
<lilyp>apteryx: I content-repaired my store, but some files are still empty
<lfam>mitchell: You mean, while buidling?
<lfam>Building?
<mitchell>I mean after installation
<mitchell>I think i found what i'm looking for with "native-search-paths"
<lfam>Yeah, that's the way
<Olivetree>erm.. are there no substitutes for core-updates? ^.^'
<lfam>It's likely there aren't many
<lfam>Not yet
<lfam>Like I said, the branch is not considered to be "usable"
<Olivetree>that's a shame. then I need to find another way to fix my texlive installation
<thorwil>lilyp: sounds familiar. in my case it was due to a faulty ssd ... all attempts at repairing the empty files failed and only switching to a new ssd and install helped
<lfam>You could take a look at the CI status pages: >https://ci.guix.gnu.org/>
<lilyp>just to be sure you do mean core-updates-frozen, right?
<lfam>Specifically, the core-updates-frozen-batched-changes job does not even evaluate successfully yet, let alone build any packages
<lfam>It looks like there may be some substitutes for core-updates-frozen, but that won't correspond with what actually lands on master, which should be the revision with batched changes
<Olivetree>So that's what I did differently... using core-updates-frozen (instead of core-updates) I again get no texlive-bin 20210325
<lilyp>I know for certain that an SSD is not the source of my issues
<mitchell>is there a reason there isn't an octave-build-system to replace octaves built in forge?
<drakonis>Olivetree: well, i'd suggest creating your own channel and copy the definitions for texlive
<mitchell>Seems like it wouldn't be the most complicated thing to implement
<thorwil>lilyp: for whatever it’s worth, here’s the issue for my case: https://issues.guix.gnu.org/issue/49811
<drakonis>provided it doesn't require any changes only available in core-updates
<drakonis>mitchell: you could make one yourself
<mitchell>I'm thinking about it, but I was wondering if there was a reason it wasn't done before. Like some techincal pitfalls I'm to inexperienced to see
<drakonis>nah, it is only a matter of getting it done
<mitchell>Right now i'm trying to make a package for the zephyr-rtos toolchain/build-system
<drakonis>ah, neat.
<mitchell>hopefully that can get merged if it works
<mitchell>the process has taught me so much about how things that build things get built
<Olivetree>drakonis: that's not a bad idea at all
<drakonis>i'm curious right now, why do we have so many new users, did something happen?
<mitchell>I just like lisp is all haha
<Inline>yes i joined you with my troll troops ....
<Inline>lol
<mitchell>I saw a talk about guix and it was like a dream come true
<mitchell>everything can be lisp
<drakonis>hah
<drakonis>nice
<Olivetree>I was casually reading stuff from rms and got into gnu's list of truly free OSes and read about guix. It seemed to boast some quite impressive features, which actually solve a problem I have for years: I have a dual-head setup with intel+nvidia desktop. But intel can't have opengl accel because opengl drivers from nvidia conflict with intel's in tr
<Olivetree>aditional distros/package managers.
<mitchell>And i was looking for an environment management solution that wasn't "use a vm for every project" that my coworkers use
<mitchell>I do mostly embedded work and there are lots of hardware bugs that require special patches to programs and trying to pass that stuff along to other people is a nightmare
<Olivetree>Yeah, I'm also thinking I will be able to keep my main working packages separated from per-project packages that make my system have every single python3 package possible or hundreds of *-dev packages. I'd like to have a hygienized system for once
<Olivetree>the *-dev packages are there usually just because I wanted to try a software that wasn't packaged for my distro once.
<mitchell>yea I got fed up when I was trying to maintain 3 separate yocto projects on my machine for the same processor but different projects
<mitchell>each one takes like 50-60GB
<mitchell>And its nice being able to manage all the variants and special purpose software with the same package manager for everything
<Olivetree>ouch... I'm not actually expecting to save disk space. I still need the packages. It's just that it's easy to cleanup afterwards.
<Olivetree>Oh you mean the import? Yeah, that's also a thing. I hate having distro packages mixed with pip packages
<mitchell>That and stuff like the suckless packages that require you build from source
<drakonis>using inherit to point to your custom code is great
<mitchell>it really is
<Olivetree>Speaking of which, I was expecting to run something like guix import pypi matplotlib and it would install it. Turns out I need to make a package for it before, but I can't directly use the output from guix import. What gives?
<Olivetree>Yeah, suckless packages.. I use dwm, but can never use distro packages, they don't have my changes
<rekado>Olivetree: the importers are of mixed quality. They are really meant for contributors to Guix, because they can be pretty rough.
<rekado>on the other hand we also have importers that generally work so well that they can be exposed to users directly
<rekado>an example is this thing for the R language: https://git.elephly.net/gitweb.cgi?p=software/r-guix-install.git;a=blob;f=guix-install.R;h=2766aa1f2d248a8ed2a4eb4c3244b85574d326e2;hb=HEAD
<rekado>it imports packages recursively on the fly, adds them to a user module, and then extends Guix with that user module to install the newly imported package with Guix.
<singpolyma>rekado: nice. I keep meaning to try something like that for ruby.
<LibreAlex>Hello . Please tell me if I can ask questions about using papa guix ?
<drakonis>hmm
<drakonis>sure?
<drakonis>ask away
<drakonis>dont ask if you can ask, just ask
<drakonis>i should make a sign
<LibreAlex>Thank you ! I use guix as a package manager, not as a basic system
<LibreAlex>I'm going to write a question now
<Olivetree>Found this regarding my tlmgr issue: https://issues.guix.gnu.org/47830 April :|
<LibreAlex>I installed virt-manager through guix , now I have two programs in my system , when I run virt-manager with privileges ( sudo) the system runs the version that is installed in Trisquel , when I run through guix the new version runs , but the problem is that this program can not work without privileges. How do I fix it?
<lfam>Use `sudo --login` instead of `sudo`
<lfam>LibreAlex: I made a mistake. I think you should use `sudo --preserve-env`, not `sudo --login`
<LibreAlex>lfam, thank you. This option does not work!
<lfam>preserve-env does not work?
<ss2>git.savannah's down..
<ss2>all good again.
<robin>LibreAlex, i don't think virt-manager should require privileges, unless i'm misunderstanding what you're doing...is your user in the libvirt and kvm groups? (dunno if both are necessary, but i think adding your user to those groups should let you use virt-manager without sudo)
<LibreAlex>lfam, To test it, I used 'which virt-manager ', answer ' /home/user/.guix-profile/bin/virt-manager'
<robin>s/require privileges/require sudo/
<lfam>LibreAlex: That looks correct. Is it not?
<jpoiret>what's define-as-needed?
<jpoiret>i see it used in guix/build/syscalls.scm
<LibreAlex>lfam: that's why I wrote here)) no, unfortunately not. Trying to figure out what the reason is
<lfam>LibreAlex: What would be correct?
<LibreAlex>lfam :How do you highlight my name for a reply?
<lfam>I type it in
<lfam>Eh, I see it's not working for me either
<lfam>That's unexpected
<LibreAlex>lfam, did you write me back?
<lfam>Yes
<LibreAlex><lfam> Did you also encounter this problem?
<lfam>I just tried it on Guix on Debian and, yes, it doesn't work in the way I expected
<lfam>For example, on my Guix / Debian:
<lfam>`which git` -> /home/leo/.guix-profile/bin/git
<lfam>`sudo which git` -> /usr/bin/git
<lfam>`sudo --preserve-env which git` -> /usr/bin/git
<lfam>I expected the final example to give a different result
<lfam>LibreAlex ^
<Olivetree>It's working fine for me on void + guix
<jpoiret>sudo by default preserves PATH anyway
<jpoiret>you'd need to check the sudo security policy
<jpoiret>maybe it's different on debian
<jpoiret>what happens if you do sudo -E export?
<jpoiret>(-E is just --preserve-env)
<LibreAlex>lfam ^ Thank you for helping me with this problem!
<lfam>It seems that preserve-env is not working on Debian anymore
<lfam>I'm sure it used to work in the way I expected
<lfam>I'm not familiar with `export`
<lfam>But, `sudo -E env` shows the unexpected result
<LibreAlex><jpoiret> Hello.
<lfam>That is, it shows the "sudo PATH" rather than my user's PATH
<jpoiret>you may have to check the sudoers file for something along the lines of `env_reset`
<jpoiret>or something similar
<jpoiret>but it is weird
<lfam>Yeah, it has env_reset
<jpoiret> https://wiki.debian.org/sudo documents that behavior (default now on Debian apparently)
<lfam>Apparently the file is unchanged for a long time, so maybe my memory is wrong
<jpoiret>maybe we could document this gotcha in the manual?
<lfam>I guess? I don't think that `sudo --preserve-env` is a typical part of the workflow on distros besides Guix System
<lfam>It *is* part of the workflow on Guix System
<jpoiret>depends, as PATH is by default preserved
<lfam>The string 'preserve-env' doesn't even exist in the manual
<jpoiret>more often than not you can just sudo something
<lfam>Or install it as root
<jpoiret>yes, it might be just -E
<lfam>Ohhh
<lfam>Right
<lfam>It would be nice if sudo warned you that the option was not effective
<jpoiret>it would warn you if you ran "sudo --preserve-env=PATH" i think
<jpoiret>by default it just filters out the variables it's not supposed to preserve according to the policy
<lfam>It actually works altogether with your example
<jpoiret>weird
<lfam>What doesn't work is `sudo --preserve-env=$PATH`
<lfam>🤷
<jpoiret>nono, you have to specify environment variables not their values
<lfam>Yes, as I am learning :)
<lfam>And have learned several times over
<lfam>Whenever I step out of Unix-world for a couple months, I forget all these fine points
<jpoiret>since PATH is treated specially by sudo, i guess -E by default does not try to preserve PATH as it should already be preserved, but if reset_env is used it is not
<jpoiret>so if you try `sudo --preserve-env=PATH` it will try to preserve PATH just like it would for any other envvar and then it works
<jpoiret>we should roll our own sudo
<jpoiret>a simple suid program that execs, nothing else
<jpoiret>no more worries
<jpoiret>:)
<LibreAlex>Guys, what's the final solution?)
<lfam>Try `sudo --preserve-env=PATH virt-manager`
<jpoiret>for a more long-term one, you should remove reset_env from /etc/sudoers
<jpoiret>or maybe it's secure_path=somethingsomething, given what the debian wiki says
<robin>hmm "sudo -i ls" segfaults for me on Guix System
<robin>i normally use sudo -E though i'm not sure the -E is needed
<ss2>It doesn't segfault for me.
<LibreAlex>doesn't work , the version is turned on `sudo --preserve-env=PATH virt-manager`
<ss2>Is reset_env usually in /etc/sudoers? That lign is missing in my file.
<LibreAlex>`sudo --preserve-env=PATH virt-manager` doesn't work , the version is turned on Trisquel
<lfam>g2g
<ss2>(in my Guix system)
<robin>i guess i'll investigate later and file a bug if it's not my fault (although i don't think i've done anything particularly weird with sudo configuration, just allowed my main account to run some commands w/o password, etc.)
<robin>LibreAlex, does running "groups" say whether you're in the libvirt and kvm groups? i understand wanting to figure out sudo issues, but for virt-manager specifically i don't think it should be necessary to run it as root
<jpoiret>LibreAlex: i think you should maybe paste your /etc/sudoers file to paste.debian.net AFTER expunging all the personal information in there
<jpoiret>robin is right though, iirc virt-manager doesn't need to be run as root
<LibreAlex>jpoiret :Thank you so much for your help, I using Trisquel
<jpoiret>oh, i forgot, since lfam was running on Debian. Still, the paste website we use is paste.debian.net
<robin>umm...does gdb have a completely blank man page for anyone else?
<LibreAlex>well another example !
<LibreAlex>'which gparted'
<LibreAlex>home/user/.guix-profile/bin/gparted
<LibreAlex>Root privileges are required for running GParted
<ss2>does sudo -i gparted make any difference for you?
<ss2>Have you installed Guix on a foreign system?
<LibreAlex>Hello ss2
<robin>ss2, LibreAlex is using trisquel iiuc
<LibreAlex>sudo -i gparted
<LibreAlex>command not found
<ss2>right, I've never tried that on a foreign system before.
<robin>wouldn't you use sudo -E, if you wanted it to use gparted from your guix profile?
<LibreAlex>Hello robin
<LibreAlex>sudo -E gparted
<ss2>A possibility would be that you install, say, gparted into your root account. Though that might not be necessary.
<ss2>robin: was that directed to me?
<LibreAlex>command not found
<LibreAlex>'which gparted'
<LibreAlex>home/user/.guix-profile/bin/gparted
<ss2>sure, that's your user account.
<robin>ss2, yeah, re: sudo -i gparted. iiuc -i wouldn't work since it's in their user's guix profile, not root's
<ss2>ah, so -E should be used in this case?
<apteryx>yes, but I think Debian & others have 'safe' settings that won't allow this to work anyway
<robin>though i admit i've always found the -E/-i stuff slightly confusing (-i: "The command is run with an environment similar to the one a user would receive at log in", what *exactly* does that mean?)
<apteryx>i.e., they reset sudo's path to some strict default, or only allow some specific extra paths
<apteryx>I mean, the environment (including PATH, etc.)
<ss2>I also had to learn -i after coming to Guix. :) This new habit has surprisingly saved me in other situations on other machines without Guix available.
<LibreAlex>sudo -i gparted
<ss2>LibreAlex: Iit could be that root will not find the extra binaries in distant folder that may be coming from a package manager like Guix.
<ss2>*it
<LibreAlex>gparted: command not found
<ss2>and you may install it into you root profile. But you would not need to do this for gparted. That package should be available in Trisquell anyway.
<robin>also i think there are different distros that effectively default to -E or -i, depending on distro...not sure though, as i only use debian and guix
<robin>(it's been long enough since i had to deal with anything low-level on debian that debian vs. guix system might be an example, actually, for all i know)
<LibreAlex>ss2 : Ok, thanks, how do I run the programs?
<ss2>It could be that I've run into this myself at some point. The only solution was to take what the host distro offers for root, or set up a Guix profile for root, and call the binaries from there.
<ss2>Which programmes?
<robin>ss2, yeah, i didn't know about -E or -i before switching to guix
<ss2>:)
<LibreAlex>ss2: virt-manager and gparted ?
<ss2>virt-manager doesn't need to be run as root. Where's your hypervisor? For gparted, you better install it from your host repos directly.
<LibreAlex>Thanks for the advice! If I run vm without sudo, I will not be able to use the program properly ss2 :
<robin>LibreAlex, that's not how virt-manager works, if i understand your message correctly
<ss2>Your user account may not be in the group that allows connections to your hypervisor. In Guix's case, the group is libvirt, and guessing for Trisquel, the group should also be libvirt.
<robin>^
<robin>LibreAlex, "groups" is the command that tells you which groups you're in
<robin>if you're not in 'libvirt', that's the problem (or *a* problem, anyway)
<LibreAlex>robin hello
<LibreAlex>groups
<robin>hi
<LibreAlex>plugdev libvirt-qemu lpadmin sambashare libvirt etc
<jpoiret>hmmm, is it normal that changing some files in guix cause all shepherd services to be rebuilt?
<jpoiret>watch me boot into an unusable system
<LibreAlex>ss2 : thank you for your response. I wrote an answer in which groups.
<robin>LibreAlex, hmm...virt-manager depends on libvirt (w/ libvirtd & friends), i'm uncertain how well that works on foreign distros
<ss2>virt-manager can also connect to libvirtd instances on other hosts.
<ss2>In theory. This I've not achieved yet with Guix.
<robin>LibreAlex, for example, is libvirtd running as root (ps aux|grep libvirtd)?
<robin>ss2, interesting, is there a bug report for that yet?
<LibreAlex>robin : I am using Trisquel
<robin>LibreAlex, right
<ss2>robin: don't think so. I haven't looked into this properly yet. Chances are that a setting or a package is missing. Or something else has to be done, and I haven't figured it out yet.
*robin nods
<robin>i have like a dozen "proto-bugs" like that :P
<LibreAlex>robin : your question 'ps aux|grep libvirtd ' the answer is yes
*ss2 is installing Trisquell
<LibreAlex>ss2 : ok
<LibreAlex>ss2: Trisquel 9. virt-manager version 1.5 Guix virt-manager version 3.2
<jackhill>ss2, robin: I had success running virt-manager on guix to connect to a remote libvirtd also running on Guix System …
<ss2>heh, first time the installer speaks to me with a voice..
<ss2>jackhill: nice! how did you do this?
<ss2>100%.., now it said 0%
<jackhill>ss2: my service definition: https://paste.debian.net/1216446/ The user I log in as is in the libvirt group. The connection uri in virt-manager is qemu+ssh://user@host/system
<LibreAlex>ss2 : orca speak ))
***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill
<robin>LibreAlex, hmm, so you're running trisquel's libvirtd & friends, and the virt-manager client from guix...i'm honestly baffled as to what could be going wrong, such that it's broken *unless* you use 'sudo virt-manager'
<ss2>jackhill: Permission denied (publickey).
<ss2>that might be a reason too.
<jackhill>eichin: hi!
<robin>but one complication that guix's libvirtd, etc. is *also* installed
<jackhill>ss2: hmm, my pair of hosts hosts has unprotected keys…
<ss2>the keys are exchanged here too.
<GNUtoo>Hi, how can I install libatomic.so.1, libstdc++.so.6 and libgcc_s.so.1
<jackhill>ss2: does plain ssh work?
<ss2>sure!
<ss2> https://paste.debian.net/1216447/
<ss2>though only key authentification.
<GNUtoo>for virt-manager I personally do 'sudo -E virt-manager' as mu user doesn't have permission to use the local libvirtd otherwise
<GNUtoo>Though I also seem to have ssh issues somehow
<robin>oh, interesting, sudo has a *third* default setting if your specify neither -E nor -i
<ss2>GNUtoo: have you added yourself to the libvirt group, and set up the service as https://paste.debian.net/1216446/?
<robin>(with behavior different from both)
<GNUtoo>I didn't, I'll look at that later on
<jackhill>ss2: I figured, but wanted to check. Unfortunately, I don't have any leads on why that might be (except our ssh package doesn't provide the ssh-askpass command). I'll have to try testing with password-protected keys at some point.
<ss2>(welcome to the libvirtd self help group, no one has theirs running properly apparantly.)
<jackhill>lol!
<GNUtoo>But even without that I managed to access some machines still but not other with virt-manager
<GNUtoo>When ssh-agent is used it doesn't ask me about the password and it works for me
*ss2 is re-enabling password authentification
<ss2>I've also got ssh-agent running too.
<GNUtoo>I've sshed into the machine where it failed (with a similar error than you) and it asked me for the key passphrase and now virt-manager can connect to it transparently without asking me any password
<LibreAlex>robin : Thank you for your help, I'll take a break and try to figure it out myself
<GNUtoo>Though as suggested before that's just a workaround and the real solution would be to make it find ssh-agent
<GNUtoo>*ssh-askpass
<jpoiret>i'm running on c-u-f right now, and it seems to ignore my timezone and choose UTC for everything (`date` for example), but /etc/timezone is the right timezone
<ss2>something in you $LOCALES?
<jpoiret>nope
<robin>LibreAlex, no problem. good luck with your next attempt, and don't be shy about asking questions here if you run into more problems (i have a hunch there might be some guix and/or trisquel bugs causing that behavior...)
<robin>GNUtoo, re: the *.so files, they're all part of gcc (so you'd likely want to install gcc-toolchain)
<robin>and if you happen to be trying to run a random binary, you'll also want to familiarize yourself with patchelf :)
<ss2>looking at this error, ssh-askpass is missing.
<robin>could someone run "man gdb" and report whether it's empty or non-empty?
<ss2>No manual entry for gdb
<robin>on my system it exists but is 0 bytes long
<robin>weird
<robin>ss2, meaning you get an error, rather than a blank manpage?
<GNUtoo>oh ok, I already installed gcc-toolchain and the binary I'm trying to run (which is part of a free software browser) still didn't find these, though it found other files like libpthread.so.0, libm, etc
<GNUtoo>And ideally I'd like not to modify that browser for various reasons (it's also shared with Parabola + it would be a privacy risk to modify it)
<ss2>robin: that was the output.
<ss2>yes, an error.
<robin>ss2, an error message, then. fun, this is broken in at least two different ways then
<GNUtoo>for ssh-askpass it seems that there are several implementations, so did installing ksshaskpass work?
<GNUtoo>or lxqt-openssh-askpass ?
*GNUtoo guesses that maybe there is a way for applications to try several of them and fall back on the ones that are installed if the other ones are not found, but I didn't check if it worked that way or not
<ss2>it looks like that virt-manager is looking for askpass from openssh.