IRC channel logs

2021-06-07.log

back to list of logs

<nckx>sundbry: No need to sign off on your own patches.
<ixmpp>hey, is there a way to peek inside and mutate a #<gexp> object
<ixmpp>oh, i guess that's ungexp
<ixmpp>dumb question, brb
<bdax>hi everyone, just wondering, can guix be used as a source-based distro like gentoo and crux?
<bdax>i.e. compiling everything locally rather than downloading pre-built binaries
<drakonis>Yes sure
<drakonis>But why?
<bdax>because if you don't compile it yourself you have to trust the binaries you're downloading, defeating a lot of the purpose of open-source
<drakonis>Okay so, you're preaching to a distro that strives to bootstrap the binaries and be reproducible
<bdax>of course you have to get your compiler from somewhere, so not everything can be built locally, but source-based distros seem a step in the right direction
<vagrantc>you also have to trust the source code you download and compile :)
<bdax>preaching? you asked why
<bdax>yes true vagrantc
<vagrantc>and, as you've noted, the toolchains used ... though honestly, guix probably has the best story for handling that issue of any distro
<bdax>does anyone know any links to the guix docs where it says how to switch to a source-based model?
<vagrantc>it actually bootstraps everything from a small set of bootstrap binaries
<bdax>and then compiles everything else from source, e.g. firefox, etc?
<vagrantc>bdax: you just remove /etc/guix/acl (or is it acls) i think
<vagrantc>basically, the list of keys for approved substitute servers
<bdax>ah right, that's an interesting model
<drakonis>The notion of a source based distro is a trap though
<vagrantc>if guix finds no signatures on something, it builds from source
<drakonis>Because they all have to compile
<vagrantc>no signatures from the list of approved signatures, including as many as zero approved signatures :)
<nckx>You should set (substitute-urls '()) in the guix-service-type's guix-configuration. You can still remove /etc/guix/acl if you're paranoid.
<vagrantc>that too
<nckx>Otherwise you're pinging the substitute servers every time and rejecting everything they offer :)
<vagrantc>i guess if you just remove the acl file it'll still check the servers and reject everythin...
<nckx>Yep. Not very neighbourly.
<nckx>(Actually, there might be a short-circuit, I admit to not checking, but it's still… backwards.)
<bdax>right, well I'm glad to hear guix has thought this through, thanks for fielding a noob question
<vagrantc>i did a talk on guix once, prepared from a virtual machine that disabled substitutes in order to get an idea of how reproducible it was
<vagrantc>bdax: guix is source-first, with substitutes as an optimization for those who need them
<nckx>Eh, we were all noobs once.
<nckx>Except Ludo', who wrote Guix 1.2.0 fully-formed in a single drunken night. All the history on the Web site is fictional.
<drakonis>Hahaha
<nckx>Nobody would run it otherwise.
<drakonis>You what we have to do? Improve the pitch
<drakonis>Gotta steal people from other distros
<vagrantc>what do you mean by "steal" exactly?
*nckx was wondering the same thing. Interesting proposal. I own a van. Continue.
<vagrantc>a crux of my debian talk(s) was that you don't necessarily have to choose between guix and $DISTRO
<drakonis>Hmm
<drakonis>I meant a compelling pitch to convince someone to embrace the guix world
<drakonis>Not specifically just the distro
<drakonis>There are facets of the community in which the landing page does not touch on
<nckx>Interesting drakonis. Like?
<drakonis>The focus on archiving software through software heritage and disarchive
<drakonis>Software reproducibility is already represented through the reproducible builds project and then bootstrapping with the bootstrappable project
<rndd>hi everyone!
<drakonis>The ways it can help achieve these goals
<drakonis>Greetings
<rndd>i have problems with guix on foreighn distro
<vagrantc>rndd: tell us more
<rndd>i added "GUIX_PROFILE="/home/user/.guix-profile" and "$GUIX_PROFILE/etc/profile" to my .bashrc
<rndd>guix is /usr/local/bin/guix
<rndd>
<rndd>instead of one from profile
<rndd>as a result cannot pull channels
<rndd>well, i can
<rndd>but cannot install packages from them
<drakonis>Is this debian?
<rndd>kinda
<drakonis>Hmmm
<drakonis>Clarify
<vagrantc>i don't think "$GUIX_PROFILE/etc/profile" in .bashrc is correct
<vagrantc>when i was running on debian i did a simple trick to avoid having to mess with environment variables ...
<vagrantc>i make ~/bin/guix a symlink to the appropriate current-guix/bin/guix
<vagrantc>and then ~/bin gets added to path on login
<vagrantc>but you'd miss setting some of the other variables...
<rndd>meh
<rndd>i solved this problem several time
<rndd>but dont remember
<vagrantc>any reason you're using ~/.bashrc instead of what the documentation recommends?
<rndd>neh
<vagrantc>there's also /etc/profile.d/guix.sh
<rndd>is there better solution?
<drakonis>nckx: i wonder how to best convince people to migrate to it
<drakonis>Play to our strengths by showing what it has been doing?
<drakonis>Nix had a website redesign a while back but it feels sterile
<drakonis>Corporate sterile
<rndd>guix package --search-paths -p "$HOME/.guix-profile" also didn't help
<vagrantc>honestly, convincing people to switch to guix has some potentially undesireable consequences ... people are a bit change resistant, so if you convince them to use it, and something goes wrong ... they might forever blame guix
<rndd>soooo, my PATH "/home/user/.guix-profile/bin:/home/user/.guix-profile/bin:/home/user/.guix-profile/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
<vagrantc>as opposed to demonstrating the benefits of it, honestly describing the challenges, and letting people decide for themselves to experiment with it ... and decide for themselves
<rndd>i've exported several times
<vagrantc>you're missing current-guix, i think
<rndd>vagrantc: mmm, could you suggest where it might be?
<vagrantc>i don't have a guix handy at the moment
<rndd>oh
<rndd>okay
<vagrantc>find .??* -name guix
<rndd>.cache/guix
<rndd>.cache/guix/authentication/channels/guix
<rndd>.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/guix
<rndd>.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/po/guix
<rndd>.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/etc/completion/bash/guix
<rndd>.config/guix
<rndd>that's it
<vagrantc>or /var/guix/profiles/per-user/USERNAME/current-guix
<vagrantc>should be _GUIX_PROFILE="$HOME/.config/guix/current"
<vagrantc>export PATH="$_GUIX_PROFILE/bin${PATH:+:}$PATH"
<vagrantc>in .config/guix/current/bin/
<viivien>What compelled me to use guix was how easy it is to self-host services. I was on debian before, and I must say that after half a dozen of "Oh exim/apache/dovecot/wesnoth/minetest/prosody services look cool,let’s set them up!" followed with some "well, that’s not very useful / the config is a pain" a few months later, I could not tell reliably which services were running, which were meant to be running and which were meant to
<viivien> be turned off.
<vagrantc>rndd: are you logged in as the same user that you're running guix pull?
<rndd>vagrantc: yes
<viivien>All you professional system administrators are laughing right now, but I don’t care, now it works way better with guix :)
<vagrantc>rndd: and there's nothing in .config/guix/current ?
<rndd>GUIX_PROFILE="/home/user/.config/guix/current" helped
<rndd>GUIX_PROFILE="/home/user/.guix-profile"
<rndd>now works
<vagrantc>rndd: how did you install guix in the first place?
<rndd>vagrantc: binary installation script
<vagrantc>that should've installed /etc/profile.d/guix.sh which does all this for you
<vagrantc>presuming your distro supports profile.d
<rndd>hmmm
<rndd>soooooo
<rndd>how i should treat this file
<rndd>?
<vagrantc>well, "apt install guix" is on it's way to future debian-derived distros
<rndd>meh
<rndd>wanna use guix 4life
<vagrantc>rndd: treat how?
<rndd>vagrantc: i'mean, how i should use it
<rndd>something like "source ..."
<vagrantc>at login, it should be loaded
<nckx>All major(?) distributions do the equivalent of ‘for i in /etc/profile.d/*; do source $i; done’ (but hopefully better); it ‘should’ just end up sourced when you source /etc/profile.
*nckx got pulled AFK and is now off to bed, g'night Guix.
<vagrantc>and that should be done automatically, not require any manual interaction
<rndd>i think i also should go to sleep
<rndd>vagrantc: thank you
<rndd>good night guix
<vagrantc>rndd: good luck tackling it another day
<vagrantc>hah
<nckx>…or not, because Savannah just went down again :) Sorry for the false hope.
<bandali>gnu and fsf are experiencing a partial network outage at the moment, affecting many servers/services
<bandali>the sysadmin team is aware
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ Network outage: https://hostux.social/@fsfstatus | 1.3.0 is out! https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<nckx>Now my spirit can rest.
<ix>sharlata` (~user@84.64.227.115) has joined #guix
<ix>sharlata` (~user@84.64.227.115) has quit (Read error: Connection reset by peer)
<sss1_>hi all, guix pull failing for me right now, is it problem on my side or on servers ?
<bandali>hi, known problem (gnu/fsf experiencing network outage)
<bandali>i think they're slowly coming back online though
<sss1_>understood
<vagrantc>i wonder if guix pull shouldn't have some fallback mirrors...
<papaya-salad>Guix pull/reconfigure now working for me
<vagrantc>wow, https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://git.savannah.gnu.org/git/guix.git as far back as may 22nd
<apteryx_>mbakke: Hi! I think it was just refreshing the patch so that it'd apply to a newer version of NSS, from the top of my head
<apteryx_>mbakke: in any case, I don't have strong feelings about getting rid of that patch, if you manage to do without it (its purpose seem to have a .pc pkg-config file installed)
<sss1_>is it possible to have "guix pull" state shared for all users ?
<ecbrown>sss1_: the best i've thought of is one's own git repo for guix, where users pull from that. git admins can put new things in master, and everyone can pull to that. (vs. e.g. follow guix git, which keeps going and going)
<ecbrown>i can't think of a way around preventing e.g. guix ... --commit=
<ecbrown>sss1_: (one makes a "channel")
<vagrantc>sss1_: or do you mean when one user runs "guix pull
<vagrantc>" all users get the same guix?
<sss1_>no no, i just want to run guix pull from root for example
<sss1_>on some systems it's nice to have different state, on other it's more convenient to have same repo state for all users
<vagrantc>i *think* you could write a wrapper script that uses /var/guix/profiles/per-user/root/current-guix/bin/guix
<vagrantc>unless those directories are permission-protected
<vagrantc>or guix pull --profile=/some/common/path/ and then all users use /some/common/path/current-guix/bin/guix maybe by way of a wrapper script
<vagrantc>but if any of those users does guix pull independently, they'll end up on their own guix branch...
<ixmpp>ecbrown: thats what i do
<acrow>ls
<ecbrown>sss1_: you can also distribute files for "inferiors"
<ecbrown>sss1_: basically manifests
<sss1_>thx for hints, i need to process this information, it's already too much )
<ixmpp>acrow: ls: no such file or directory
<sss1_>basicly it would be nice to avoid somehow costly guix pulls for each user on servers
<sss1_>where many services dedicated to separate users and separate profiles
<sss1_>does guix planing to use apparmor ?
<ixmpp>It uses selinux
<ixmpp>Afaik
<vagrantc>apparmor is *like* selinux in some ways, both are a bit hard to create policies that work with guix
<vagrantc>as the binaries are in essentially arbitrary directories of /gnu/store rather than on a system path in a predictible location...
<vagrantc>a default policy that says /usr/bin/SOMEPROGRAM can do x and y but not z ... won't work at all on guix and needs adaptation that's aware of the store paths
<kts>How do I install ttf font onto guix?
<emestee>kts: there are -ttf packages if that's what you're asking
<kts>It's for myanmar font and is absent.
<sss1_>wrap binary symlink into sh script is trivial enough and work just fine with apparmor
***Kimapr2 is now known as Kimapr
***Kimapr0 is now known as Kimapr
<raghavgururajan>Hello Guix!
*raghavgururajan thinks go-packages are crazy
<leoprikler>Rust is not saner :)
<raghavgururajan>xD
<raghavgururajan>I get "No such file or directory" during substitute* for any combination of path.
<raghavgururajan>Hard to know which is CWD for each phase.
<raghavgururajan>*PWD
<leoprikler>(invoke "tree") :D
***Kimapr7 is now known as Kimapr
<viivien>Hello, there is a new nettle release that fixes a really bad bug, "Upgrading is strongly recommended.", according to the announce in the list.
<raghavgururajan>phew! finally.
<civodul>Hello Guix!
<raghavgururajan>hello civodul o/
<mbakke>apteryx_: the old version of the patch applied cleanly on the newest version of nss, I reverted it in https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=79878c64b4bda523f50974c3f61b796309b1b8d9
<efraim>hello everyone!
<raghavgururajan>efraim: o/
<sss1>hi all again
<sss1>is it possible to install just one or few packages from older generation ?
<sss1>into user profile
*raghavgururajan screams "In the name of the Father, and of the Son, and of the Holy Spirit; someone please combine C, Go and Rust into one simple language."
*raghavgururajan bows down to Scheme
<cbaines_>morning all :)
<cbaines_>I need to actually get around to ticking things off my list regarding bordeaux.guix.gnu.org...
<cbaines_>on that subject, nckx, do you mind if I use https://guix.tobias.gr/about/ as a template? I like it's style, and I should probably put something here https://bordeaux.guix.gnu.org/
***cbaines_ is now known as cbaines
<abcdw>hey guix!
<civodul>o/
<abcdw>Do someone succesfully switched to pipewire on Guix System?
<abcdw>civodul: How are you doing? Have you had a chance to play with Guix Home?
<solene>I'm trying to play with "guix publish" but I don't have much results... on a new computer I've done guix pull --substitute-urls=http://192.168.1.150:8080 , I see some GET to the publish server but the new computer doesn't seem to enjoy the packages and download sources from the internet to compile it itself
<solene>this is not what I expected to be honest ^^'
<roptat>solene, did you authorize the key from that substitute server'
<roptat>?
<roptat>(if you don't want to, you should add ci.guix.gnu.org, so that you can get substitute info from ci, which will help authenticate substitutes from your own substitute server
<roptat>if you put ci at the end of the list, your local server will be prioritized)
<solene>roptat: I'm not sure how to do that, Ifollowed https://guix.gnu.org/manual/en/html_node/Getting-Substitutes-from-Other-Servers.html but this isn't clear: "(list (local-file "./key.pub")"
<roptat>that means you need a file called key.pub in the same directory as your configuration, and that file contains the key from "/etc/guix/signing-key.pub" on your server
<solene>ah, I did run "guix pull" as root but not as my user, that may explain things. I'm using "guix weather" to check if my remote computer has X or Y package and it has some
<pineapples>abcdw: I had but then I switched back to PA because there was no easy way to daemonise it, without the likes of `guix home' :')
<solene>roptat: the key in a lisp format?
<roptat>yes
<pineapples>s/had/had done
<roptat>just copy the file from the server
<roptat>you need to reconfigure afterwards, pull is not necessary
<abcdw>pineapples: Can you share the steps you performed please?
<apteryx_>is this still a thing? TLS error in procedure 'read_from_session_record_port'
<apteryx_>I just had it
<civodul>apteryx_: not a thing!
*civodul sticks head in the sand
<civodul>that said, if you're sure it did happen, please provide guix-daemon version etc.
<pineapples>abcdw: Do you want to just get it up and running dirtly and quickly, or do so but properly?
<abcdw>pineapples: I'm interested in both options, will start quick and dirty, will cleanup and setup it properly later.
<pineapples>abcdw: To quickly replace PA with it, terminate a running instance of the PA server, and then run `$(guix build pipewire)/bin/pipewire & $(guix build pipewire)/bin/pipewire-pulse'
<civodul>abcdw: hi! i started my home config but haven't yet made the Big Switch
<civodul>i need to make sure it doesn't take over ~/.config inadvertently, things like that :-)
<civodul>AIUI, the activation snippets will typically overwrite ~/.bashrc, ~/.config, and the likes, right?
<pineapples>Keep in mind that a session bus instance of d-bus daemon must be running, and `DBUS_SESSION_ADDRESS' or something alongs these lines must be exported
<pineapples>for PipeWire to work start and work correctly
<abcdw>pineapples: Yep, seems working, at least pactl shows it. But I got this and few similar warnings: [E][000005067.483206][bluez5-dbus.c:2582 get_managed_objects_reply()] GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown
<yoctocell>civodul: If you already has things in ~/.config or ~/.bashrc it will create a backup directory ~/guix-home-legacy or something like that
<yoctocell>s/has/have
<yoctocell>so you can just move them back if you really wanted to
<abcdw>civodul: Yup, it's true, files will be backed up. For implementation details take a look at https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/symlink-manager.scm or https://youtu.be/ZRQtCvo8MoM
<civodul>yoctocell, abcdw: thanks!
<civodul>so for now, i need to complete my config, mostly
<civodul>(and watch the video to get up to speed!)
<civodul>longer-term, it'd be interesting to see what tool we could provide to ease transition
<civodul>sorta like "guix package --export-manifest"
<civodul>maybe "guix home init"
<pineapples>abcdw: As for setting it up properly, you need to either uncomment a line that contains the `"-c pipewire-pulse.conf" }' string in the `$(guix build pipewire)/etc/pipewire/pipewire.conf' configuration file and have PipeWire read it somehow (I couldn't get this to work even if I placed the configuration file in my `/etc' directory) or to have guix home/shepherd start it like this: pipewire -c
<pineapples>pipewire-pulse.conf, which should automatically launch the `pipewire-pulse' binary
<apteryx_>civodul: hehe
<yoctocell>civodul: that would be a good idea
<abcdw>civodul: to export list of packages from current profile is not a hard task, should be relatively easy to implement.
<civodul>abcdw: yes, that's what --export-manifest does
<civodul>but we also need something that would scan "known" config files and offer a config template
<apteryx_>mbakke: sounds good
<solene>when defining multiple substitute url, how does guix choose among the list?
<pineapples>abcdw: Be advised that the `pipewire.conf' and `pipewire-pulse.conf' configuration files may be different in newer PipeWire releases.
<abcdw>pineapples: Thanks a lot for the information! I'll come back tomorrow with some results I hope.
<pineapples>See <https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon> for up-to-date configuration files
<yoctocell>civodul: when you say "config template" do you mean that we would read the contents of say ~/.bashrc, and then generate a guix home config that contains that content?
<pineapples>abcdw: You are welcome!
<yoctocell>or would be just say create a default guix home bash config if we see a ~/.bashrc file?
<abcdw>yoctocell: I got the patches, I'll try to handle them in next few days. Thank you!)
<yoctocell>abcdw: you are welcome! The run-on-change service would be nice to finish soon
<abcdw>civodul: We partially covered gradual migration to Guix Home topic during previous meetup, we already have an approach to do so by including already existing config files as a part of home service configuration (not a tool, just an approach for user). I can elaborate on that later, probably have to write it in the manual.
<civodul>abcdw: nice! yes, a section in the manual would be a good start
<abcdw>See you around, guix!)
<pineapples>Until the next time!
<apteryx_>civodul: could be due to one of my offload machines lagging behind in terms of guix-daemon
<apteryx_>I retried with --substitute-urls=https://ci.guix.gnu.org and it didn't crash that time
*apteryx_ touches wood
<vldn>how do i force reinstall of packages?
<vldn>i got an error:
<vldn>guix install desktop-file-utils; guix install: error: opening file `/gnu/store/99px2khsxccbczbb2dzgjvjg3xsrfh8l-desktop-file-utils-0.26.tar.xz.drv': No such file or directory
<apteryx_>civodul: restarting guix-daemon on that offload machine updated it from /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec/bin/guix-daemon to /gnu/store/hgk21jf5plhijh7vdvyz81imsgn4887f-guix-1.3.0-1.771b866/bin/guix-daemon, for the record, and I could still trigger the crash :-(
<civodul>:-(
<civodul>note that, if you're offloading, substitution happens on the head node
<civodul>vldn: hi! could it be that you modified files under /gnu/store?
<civodul>that can lead to inconsistencies
<civodul>see https://guix.gnu.org/manual/en/html_node/The-Store.html
<vldn>got an error because of a file system crash and deleted this file, isn't it possible to force rebuild this specific derivation?
<apteryx_>civodul: I see! guix-daemon on my local machine (what you refer to as the head node, correct?) is /gnu/store/9zh3bg8d4y08jnkqyrk6xczahiahhcy4-guix-1.3.0-1.771b866/bin/guix-daemon
<vldn>thanks for the link, the little "guix gc --verify" seems to help :)
<apteryx_>from guix commit bb325c5611553a6db21ee7499ac07d5757d24fc3, I believe.
<apteryx_>on the offload machines I still have a mix of guix-daemon versions: https://paste.debian.net/1200283/, even after issuing 'herd restart guix-daemon'; I'm not sure why.
<yoctocell>civodul: have you seen this https://issues.guix.gnu.org/48872 ?
<nckx>cbaines: I don't mind at all, I've noticed suspiciously similar pages elsewhere :)
*nckx really really needs to get that house back up & running. It hosts the actual build nodes & off-line Overdrives…
<cbaines>nckx, cool :) I've got something simple up now: https://bordeaux.guix.gnu.org/
<cbaines>I might try and work your styling/CSS in at some point...
<apteryx_>civodul: eh, the parent PID of all these forgotten v1.2.0-21 guix-daemons are Shepherd (pid 1). Hm.
<apteryx_>gently terminated those process with kill
<civodul>cbaines: yay!
*civodul is working on https://guix.bordeaux.inria.fr for work and will surely mix up the URLs :-)
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 1.3.0 is out! https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<cbaines>haha, yeah, I still have to double check I'm spelling bordeaux right...
<cbaines>anyway, after some more time getting distracted by code stuff, I've finally made some progress towards making https://bordeaux.guix.gnu.org/ a thing
<cbaines>I need to work out what the next steps are now
<apteryx_>civodul: yeah, still getting 'guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.'; should I open an issue with it? I'll note the offload and head node guix-daemon versions, something else?
<nckx>ix: Was there… a reason you copy-pasted someone's join/part message last night?
<ixmpp> https://xmpp.xa0.uk:5281/upload/fMQxd-sygqY7EyCq/20210607_153553735_d388.jpg
<ix>nckx: ^
<mbakke>raghavgururajan: what was the reason for enabling OpenSSL support in glib-networking (commit a1dd57ce83de42b115392816606e810d13864e41)? AFAIK it is discouraged, and Guix prefers GnuTLS when possible.
<civodul>apteryx_: yes, please open an issue; try to reproduce locally with offloading out of the picture
<civodul>TIA! :-)
<nckx>ix: …oy.
<nckx>(That part gets lost when I reconnect to ZNC.)
<ix>Seems to have stopped, since 1h
<ix>*10h ago
<ix>Ohi, matrix bridgebots
<ix>Oh thats how they get past the ip limit, they use ipv6 subnets. Clever
<nckx>ix: If it restarts, ping me.
<ix>👍
<nckx>They should rDNS each one to something fancy smh.
<papaya-salad>Does anyone know if there is a guix data-science or statististics and/or bioinformatics irc or listserv? Would also love to chat with individuals in those spaces
<nckx>Hm, there's https://lists.nongnu.org/archive/html/guix-devel/2020-07/msg00088.html .
<nckx>It's not that active though.
<papaya-salad>Ah I see, thanks!
<civodul>papaya-salad: there's the #guix-hpc channel right here, and the guix-science mailing list
<ixmpp>nckx; yeah, the rdns could have the matrix user id in it or something
<nckx>Durp, I was trying to join #guix-science.
<apteryx_>civodul: seems to always happen downloading libreoffice-6.4.7.2
<apteryx_>even without offloading/custom substitute urls
*apteryx_ opens the issue
<nckx>ixmpp: Wait what the heckity on-screen keyboard even is that thing, but?
<ixmpp>nckx; ha, it's er
<ixmpp>OKeyboard
<ixmpp>styled in the fashion of messagease
<ixmpp>cause i used to use messagease until about a week ago :D
<ixmpp>oo, bye filks
<nckx>Whee.
<nckx>With that info, I was able to read <https://en.wikipedia.org/wiki/MessagEase> and get a clue. Thanks.
<ixmpp>i reccomend it! it's very convenient.
<nckx>I don't use machines without a keyboard, but this looks like one of the less unusable layouts if I ever get one.
<apteryx_>civodul: http://issues.guix.gnu.org/48903
<mitzman>the uncultured questions that keep on giving -> if gcc-mesboot1 depends on glibc-mesboot0 (which has "disable-shared" flag), then why does gcc-mesboot1 try to use the dynamic linker? now it fails because it can't find ld-linux. does it build the .so even with disable-shared conf flag?
<civodul>apteryx_: thanks! i'll look into it
<bone-baboon>I am trying to use inetutils from core-updates because inetutils 1.9.4 fails to build for me. I have cloned the Guix repository. I have applied a patch to /gnu/packages/admin.scm so it has the definition for inetutils 2.0 from core-updates. When I run `sudo ./pre-inst-env guix system --no-substitutes reconfigure config.scm` or `./pre-inst-env guix build inetutils` it tries to build inetutils 1.9.4 instead of inetutils 2.0. Further I
<bone-baboon>want inetutils to be used as a dependency for all the other packages I build instead of inetutils 1.9.4. What do I need to do to get this working?
<ixmpp>ah ok
<civodul>sneek: later tell mothacehe looks like Cuirass can't build, say, 'version-1.2.0', due to assumptions about the (gnu ci) module i think; thoughts?
<sneek>Got it.
<ixmpp>hey, what would give me /etc/fonts
<ixmpp>or fonts.conf
<dongcarl>Oh no did the merge already happen? :-0
<cbaines>merge of what dongcarl ?
<dongcarl>core-update
<cbaines>I don't believe so
<dongcarl>Okay good phew
<dongcarl>just saw a merge of master into core-updates and was worried haha
<jra>When running "guix build --file=ring_c.scm", I get "Unbound variable: mkdir-p". I have "#:use-module (guix build utils)" in my ring_c.scm, which I thought would get me mkdir-p. What am I missing?
<roptat>when does that happen? is it during the build, or before the build?
<jra>It is during the build.
<roptat>if it's during the build, you need to make sure (guix build utils) is imported (which should be the case for all build systems, except the trivial-build-system maybe)
<roptat>I mean, imported on the build side
<roptat>it doesn't matter what your file imports
<jra>I'm new to Guix. Do you mean I need to do something like "guix package -i guix/build/utils"?
<roptat>ah no, sorry. do you mind sharing the content of the file, using paste.debian.net for instance?
<jra>Sure thing. I've not done that before ... I'll figure it out.
<roptat>you just copy the file to the text field, submit and share the link here
<jra>paste.debian.net/1200308
<roptat>jra, after the (begin, I think you can do (use-modules (guix build utils))
<rovanion>Any ideas as to why my guix environment created through direnv with the line `use guix --ad-hoc texlive --root=.direnv/guix-gc-root` gets garbage collected even though `guix gc --list-roots` lists it?
<roptat>the content of the builder is the whole file that's executed on the build side, it doesn't have access to the context of that file, so it doesn't import (guix build utils) by itself
<roptat>rovanion, grafts?
<roptat>I think your profile contains the grafted texlive, so gc removes the ungrafted texlive, but then when you need to enter the profile again, guix needs the ungrafted texlive to know what it wants to graft, and notice it already has the graft
<jra>roptat: I got a different error "no code for module (guix build utils)"
<roptat>so it looks like gc collected your profile when it didn't really?
<roptat>jra, ah it needs to be available on the build side, give me a sec, I don't remember how you do that :p
<roptat>jra, I think you need to add another argument, that would be #:modules '((guix build utils))
<lfam>Bah, Guile 3.0.7 is failing to build on the ungrafting branch
<lfam>I'm bisecting it now
<lfam>"bisecting" by hand
<lfam>I guess it will save time to write a bisecting script
<jra>roptat: another error, I probably incorrectly added that line. here is the new file and error below: paste.debian.net/1200311
<rovanion>roptat: Is the ungrafted version of texlive ever used? Sorry, I'm trying to understand grafts but its not clicking for me.
<roptat>rovanion, it's not part of your profile, that's why it's gc'd
<roptat>but to compute the graft, guix needs to have the ungrafted version, so it knows which dependencies it needs to graft
<roptat>once it knows that, it can notice it already has the grafted texlive, and doesn't actually apply any graft
<roptat>so the ungrafted texlive becomes useless again
<cbaines>lfam, guile 3.0.7 seems problomatic on the master branch as well, I think this is the derivation http://data.guix.gnu.org/gnu/store/djr1vmhnl8z8yy4ymkszw5srvfmfv943-guile-3.0.7.drv
<lfam>Oh, thanks cbaines
<roptat>maybe a good solution to that issue would be to have gc liveness propagated to the ungrafted origin of a store path somehow
<lfam>Huh, so how are things "still working" on master cbaines?
<rovanion>And figuring out what needs to be grafted is done by essentially grepping for hashes on the ungrafted version?
<roptat>yeah
<roptat>that's why guix needs the ungrafted version
<rovanion>Could that information not be lifted into a metadata file kept alongside the substitute?
<cbaines>lfam, I think it's possible to build, just difficult. There's at least one issue about this I think
<lfam>Hm
<lfam>Tricky
<lfam>Maybe it requires a low level of parallelism? I'm trying to "help" by throwing many cores at it
<roptat>rovanion, not the substitute for the ungrafted version, because the same ungrafted version can be grafted to multiple different things, depending on your guix version
<lfam>cbaines: Have you identified the actual "error" in the log? I'm having trouble finding it
<cbaines>seems like you're already on top of this issue lfam : https://issues.guix.gnu.org/48392
<roptat>jra, you're missing a quote before '((guix build utils)) but otherwise it looks good
<lfam>cbaines 😭
<cbaines>lfam, I also find reading the log difficult, I guess this line is relevant: FAIL: check-guile
<lfam>Well, yeah :) But I struggled to find out where check-guile fails
<lfam>I'll try doing it again with --cores=1
<cbaines>I'm going afk, but good luck :)
<lfam>Thanks
<lfam>Tries something weird: --max-jobs=8 --cores=1
<jra>roptat: I got a wrong ype argument: quote ... paste.debian.net/1200313
<roptat>oh you're right, there's no quote needed there, sorry
*lfam wishes that --clear-failures could handle multiple outputs gracefully
<roptat>ah nevermind, I read your error message too quickly, it had nothing to do with #:modules, if just shows it's running the content correctly, so go back to when there was to quote
<roptat>the issue is that "mpicc" is not found, and that's because there's no $PATH on the build side
<rovanion>roptat: Me not understanding again: Does the substitute not contain a fix number of hashes no matter the Guix version? If more information than just the hashes is used to then filter the hashes, perhaps that can be brought too?
<roptat>rovanion, oh I see, that makes sense
<roptat>jra, instead of (invoke "mpicc" ...) try (invoke (string-append (assoc-ref %build-inputs "mpich") "/bin/mpicc") ...)
<lfam>The hashes are recorded in the Guix database, but when the store item is garbage collected, that information is deleted too
<lfam>I agree it would be nice to improve how this works
<lfam>(Or have fewer grafts... hopefully that will be a reality soon)
<lfam>We never intended to have so many grafts in place all the time
<nckx>ixmpp: ‘Creating /etc/fonts or fonts.conf yourself.’
<rovanion>Downloading 2,9GB of texlive just to run grep on it seems a bit wasteful on the projects resources too :D
<lfam>Yeah, I think we agree :)
<ixmpp>nckx; so there's no mechanism to do it using guix? how do packages that need a fonts.conf usually get made to work?
<lfam>rovanion: Grafts are a (refined) kludge. There are a lot of problems with them
<ixmpp>nix doesn't have grafts, but because of that one small change can mean your entire system needs to be rebuilt from source without substitutes
<ixmpp>for that reason, i feel grafts are pretty neat. not sure how they work though
<drakonis>ixmpp: there is a blog post on grafts
<drakonis>it is fascinating.
<drakonis>nix has something that can work like grafts, but it isnt used because they swear that hydra can catch up fast enough to be unnecessary
<ixmpp>you mean uh, replaceRuntimeDependencies?
<ixmpp>cause yeah, that also isn't pure, so cannot work with flakes
<lfam>drakonis: It may very well be true that their CI is fast enough
<ixmpp>i looked into it too
<lfam>Our CI can be fast enough too, at least for x86
<drakonis>i think there is too much emphasis on purity by nix's side
<ixmpp>that's why grafts is cool, cause rather than being held back by purity requirements, guix can just have that stuff builtin
<ixmpp>but i still don't get how the grafts themselves are generated
<drakonis>rather, its not about hydra being fast but about how fast nixpkgs can move forward
<drakonis>but hydra locks up too frequently
<lfam>ixmpp: What don't you understand?
<drakonis>and there are too many gigantic commits that cause hydra to freeze
<ixmpp>drakonis; that's part of the reason i really wanted ipfs, so there's no more dependency on hydra and no more need for nixos to be slaves to corporate investors
<ixmpp>lfam; well, how do they get generated?
<ixmpp>do you create two derivations then diff them?
<lfam>It's not fair to say they are "slaves" :(
<lfam>Slavery is a real thing and accepting donations is not it
<ixmpp>well, no, but nixos is heavily influenced by what is useful to the companies that fund the servers
<drakonis> https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix
<drakonis>this is the one
<ixmpp>and that's a big part of why it's so stagnant
<lfam>Okay, that's fair ixmpp. I just don't think it's reasonable to call it slavery
<drakonis>ixmpp: like i told you elsewhere, the framing is the problem
<ixmpp>it can't move forward because creativity leads to instability
<ixmpp>and instability means less investment
<ixmpp>yeah, fair
<lfam>Anyways
<ixmpp>drakonis; it's ok, i'm used to misunderstandings in this direction, i have autism :p
<drakonis>sure.
<drakonis>anyhow
<lfam>When you add a replacement field to a package definition, you have "grafted it". Then Guix knows that it should rewrite any "references" to the store items generated by that package definition with the store items generated by the replacement
<drakonis>i think i'm doing grafting wrong though
<lfam>"References" are literally just strings found by scanning the store item for what looks like a store path
<drakonis>because i'm trying to graft a bunch of packages and it is trying to engage in a mass rebuild
<ixmpp>oh! i thought it was more like a binary diff thing.
<ixmpp>so it literally is replaceRuntimeDependencies then, just builtin to guix
<lfam>drakonis: Hold on, I can share my "guide to grafting"
<drakonis>and regarding nix's stagnation, it has far more to do with the ecosystem that developed around it to take care of deficiencies
<lfam>Looks like the goggles search isn't working well
<drakonis>lfam: can that be cleaned up and merged into the cookbook?
<lfam>drakonis: It's on my todo list
<drakonis>cool.
<lfam> https://paste.debian.net/1200317/
<lfam>Let me know if it helps
<lfam>It explains how to set up a graft and test that it works correctly
<drakonis>its far easier to build something around nix than to upstream large changes to the nix CLI
<lfam>This link is better because it wraps the text properly: https://paste.debian.net/plain/1200317
<drakonis>excellent, thanks internet browsers for wrapping text around
<jra>roptat: another error ... https://paste.debian.net/1200318 ... I tried adding gcc, but it didn't seem to help.
<drakonis>i need to graft mesa for my very own dastardly purposes
<drakonis>thank you very much
<roptat>jra, right, as I told you, the trivial-build-system doesn't set $PATH at all
<roptat>so it's not surprising it can't find anything
<ixmpp>lfam; very cool. i see :)
<ixmpp>i haven't had need to graft anything yet
<roptat>so... let's make a $PATH ourselves, in the let, you can define something like (path (string-join (map (lambda (pkg) (string-append (assoc-ref %build-inputs pkg) "/bin")) '("mpich" "gcc")) ":")) and right after the let, add (setenv "PATH" path)
*lfam afk
<roptat>whenever you add something to the inputs, you'll have to add it to the list that defines path
<roptat>what we're doing here is, for each input specified in the list, look for it, append /bin (that's the map), and join each element of that list together with ":". That creates the content of the PATH variable, which we set later
<dstolfa>oh no
<dstolfa>here we go again
*dstolfa wonders why matrix keeps breaking
<ixmpp>dstolfa; cause it's matrix, it's held together by toothpicks and duct tape...
<dstolfa>ixmpp: i think it's something to do with their irc peering
<dstolfa>it's obviously very unstable
<dstolfa>matrix itself runs fine (i host a homeserver)
<dstolfa>it's just that this bridge keeps on blowing up
<ixmpp>i used to too, wasn't much stable
<ixmpp>i've peeked into the protocol and the protocol peeked back
<ixmpp>i now detest matrix
<dstolfa>the protocol is not too bad, it's the implementation that is
<dstolfa>reCAPTCHA is an issue with it
<ixmpp>well, at any rate, i won't start a matrix argument here
<dstolfa>yeah, it's offtopic here anyway
<projectmoon>The libera bridge isn't stable yet. I'm using heisenbridge in the meantime. Works perfectly fine
<vup>is there a way to get the parameter passed to `--system` from within a script (for example a operating-system definition)?
<ixmpp>heisenbridge?
<projectmoon> https://github.com/hifi/heisenbridge
<mbakke>I wonder if we could have a channel dedicated to bikeshedding.
<mbakke>I don't want to throw all my random ideas into this channel :P
<ixmpp>ooh.
<drakonis>we probably should
<drakonis>i dont know if i should offer #nonguix for this or just do something like #guix-bikeshed
<drakonis>#guix-chat ?
<drakonis>pick your poison
<apteryx_>if it's offtopic to Guix, I'd rather guix not appear in the channel name.
<drakonis>its in the namespace
<muradm>hi, any pointer on where to look for solution for this problem? http://paste.debian.net/plain/1200323
<apteryx_>which dot language backend is the fastest? SVG takes ages.
<apteryx_>I think -t references reduced the graph size by half
<apteryx_>which helped a lot
<jra>roptat: looks like progress, new error: "gcc: error trying to exec 'as':execvp: No such file or directory". https://paste.debian.net/1200325 It looks like `as` is in the same place as `gcc`. Maybe execvp doesn't see PATH?
<roptat>it should
<roptat>as is not in gcc, it's in binutils
<jra>so just add binutils to mpich and gcc?
<roptat>jra, yes
<roptat>actually, you probably need all the packages from the default set that the gnu-build-system brings in, like glibc
*raghavgururajan just got first-dose of vaccination :D
<dstolfa>raghavgururajan: hopefully no "feeling bad" after effects!
<lfam>A little bit of bikeshedding is healthy mbakke :)
<lfam>Any luck with your graft drakonis?
<drakonis>i'll work on that later
<drakonis>got to finish something first
<lfam>Gotcha
<lfam>I'd appreciate any feedback on that text
<lfam>I want to add a section "how to graft" to the cookbook but it's hard for me to approach with a beginner's mind
<raghavgururajan>mbakke: IIRC, it generates two libs and any software that uses glib-net can choose either of them. I thought if a project specifically looks for glib-net-openssl.so then it might be useful.
<raghavgururajan>dstolfa: Yep, but that's a good sign. :)
<roptat>lfam, sorry, which text?
<lfam>roptat: https://paste.debian.net/plain/1200317
<roptat>thanks
<lfam>I'll also write a section explaining "references"
<lfam>This is about "how to set up a graft and check that it worked"
<jra>roptat: I added binutil and glibc. It looks like ld cannot find crt1.o. I'll try adding LIBRARY_PATH like you showed me for PATH.
<roptat>jra, yeah, that should help :)
<roptat>the trivial-build-system is only trivial in name ^^'
<roptat>I wonder if you could instead use the gnu-build-system, remove all phases and replace one to build/install your package?
<jra>ha ... yeah ... but I think it will be helpful for me to know what is needed, and what you get for free in the other build systems.
<lfam>My text also assumes some knowledge of what a "derivation" is
<lfam>I think that's reasonable if somebody is grafting
<roptat>jra, true, but that's painful ^^'
<roptat>lfam, I don't like when you write "currently", these things get out of date very quickly
<lfam>Sure, roptat. It's a first draft
<lfam>On the other hand, anyone can check out that Git commit
<jra>roptat: I'll work a bit more with trivial and then pursue gnu
<lfam>It's important to have an example, in my opinion
<roptat>agreed, I think it's just the wording that's bothering me
<lfam>At least, that helps me learn. To follow the examples and try them myself.
<lfam>I'll change it to more accurately state that the graft "was in place as of commit XXX"
<lfam>Or something like that
<lfam>There's another thing like that later in the text that needs to be adjusted
<raghavgururajan>mbakke: Hmm. I also didn't know that GnuTLS was preferred over OpenSSL. The latter seemed ubiquitous. Shall I make a commit to disable OpenSSL support? Revert will also disable libproxy support.
<lfam>I think it's a matter of taste within Guix. We like to use GNU software, although GnuTLS is not part of GNU anymore. OpenSSL is definitely better from a technical perspective
<lfam>There are some license compatibility issues with OpenSSL that should go away whenever OpenSSL 3 comes out
<yoctocell>lfam: I am working on adding the `github-cli' package (https://issues.guix.gnu.org/47539#101), I ran into a problem when trying to package https://github.com/muesli/reflow. It has multiple directories that contain Go code, but #:import-path only accepts a single string.
<lfam>yoctocell: In Go, those directories each contain a different program
<lfam>Thus, they could each be packaged separately
<lfam>Sometimes, clever use of #:unpack-path can help
<yoctocell>lfam: OK, I will try to create multiple packages and see if it works
<lfam>I'm a bit rusty on my Go packaging, so I can't say exactly what you should do
<yoctocell>How should I name the packages? go-github-com-muesli-reflow/DIRECTORY or go-github-com-muesli-reflow-DIRECTORY ?
<lfam>I would look at some existing uses of #:unpack-path and see if that pattern applies
<lfam>Use the hyphen
<roptat>lfam, do we have a section in the manual that explains what a graft does?
<lfam> https://guix.gnu.org/manual/devel/en/html_node/Package-Naming.html
<lfam>roptat: https://guix.gnu.org/manual/devel/en/html_node/Security-Updates.html
<roptat>when you say "we had to use a graft", it would be nice to link to that section if it exists, or explain the concept :)
<lfam>Sure
<lfam>Remember, this text is an excerpt of something that will be a little more comprehensive
<roptat>oh, ok
<lfam>But, it is not meant to be canonical documentation. More like a how-to
<ixmpp>figuring out gexpressions reminds me so much of figuring out monads in haskell
<lfam>I am editing based on your feedback :)
<sarg>pkill9, lfam: could you please advise if https://issues.guix.gnu.org/46337 looks fine to merge?
<lfam>sarg: I'll test it now
<lfam>To clarify, it's the version of the patch from this message? <https://issues.guix.gnu.org/46337#9>
<sarg>yup
<lfam>Great
<sarg>I'm using it on my machine already and pkill9 has built it also on his own
<lfam>Okay, thanks for testing it like that and letting me know. It helps a lot
<pkill9>yea im using it too
<nckx2>ixmpp: Which package needs a fonts.conf?
<ixmpp>you won't like it :p
<nckx2>I've never encountered such a horror.
<nckx2>Oh.
<ixmpp>(not even i do)
<BlackMug[m]>test
<BlackMug[m]>... eh very empty
<BlackMug[m]>can someone confirm he can see my typing? testing matrix-> guix libera.chat first time
<roptat>hi BlackMug[m]
<nckx2>Yes BlackMug[m].
<ixmpp>i'm thinking i can get away with FONTCONFIG_FILE
<ixmpp>it's cause it uses electron, which has weirdness with fontconfig
<nckx2>ixmpp: Can you get away with ~/.config/fontconfig/fonts.conf ?
<nckx2>I have that, just to reduce eye-bleeding, not because it makes anything work.
<nckx2>Or that, yeah.
<ixmpp>apparently not :/
<ixmpp>i already have one of those and it wasn't working
*nckx2 borked their laptop again and gets to use KiwiIRC as punishment :)
<nckx2>Ah.
*nckx2 is very happy KiwiIRC exists TBF.
<ixmpp>:D
*lfam got Guile 3.0.7 to build
<nckx2>Just because Electron needs to die yesterday doesn't mean I don't wish I could think of a possible solution, ixmpp. Does it have to do with sandboxing?
<nckx2>lfam: Reproducibly?
<lfam>nckx2: Nope! It's still suffering from nondeterministic test failures. But it was blocking evaluation of the ungrafting branch
<nckx2>That's still good. Thanks.
<ixmpp>nckx2; yeah, something along those lines. i'm trying to run the discord from zaijab's github channel
<ixmpp>turns out that doesn't work, so i tried my old nix one
<ixmpp>that doesn't either, same reason
<ixmpp>so i added my /etc/fonts from nix, suddenly the nix one works. guix one still doesn't. i added FONTCONFIG_FILE and removed /etc/fonts, again, nix one works now, guix one doesn't
<ixmpp>so yeah, sandboxing
<raghavgururajan>nckx: Sorry to hear that.
<raghavgururajan>Hope it works back well soon.
<BlackMug[m]>i saw you replied to my question here:
<BlackMug[m]> https://logs.guix.gnu.org/guix/2021-06-07.log
<nckx2>It's my own fault. My 'copy stuff to /boot and don't break the world' script broke the world. But thanks ;-)
<BlackMug[m]>but there your typing doesnt appear/syncing to matrix
<BlackMug[m]> * but here your typing doesnt appear/syncing to matrix
<nckx2>...and my 3-month-old rescue USB is too old to mount the file system. Hmdear.
<lfam>sarg: While the package builds, I wrote the commit message. I wrote the title as "gnu: qtwebengine: Enable H.264 WebRTC encoding." Is that accurate?
<nckx2>BlackMug[m] (well, if you see this): Do you know if this affects other Matrix(.org) users too?
<sarg>lfam: more accurate would be "Enable H.264 decoding and encoding" :)
<lfam>Hm, well it should already support that to some degree, as we discussed
<lfam>I thought this was specifically about webrtc
<lfam>And the main thing seems to be that `rtc_use_h264` argument
<yoctocell>Is there a way to make the Guile backtrace expand the "..."? I got an error "1 (copy-file "/gnu/store/0zv0zwppkf8vajccd99iqynnkhx8zzj…" …)", but I can't see what file it's trying to copy.
<yoctocell>
<ixmpp>+1
<lfam>OpenH264 is basically about realtime encoding, and is otherwise considered a poor implementation of H264
<BlackMug[m]>nckx2 i dont know
<lfam>Like, you wouldn't choose to use it in any other context
<nckx2>dstolfa: My excuses not to test your strongswan patch will only become more elaborate. By Friday I will have hit a shark with my car.
<sarg>lfam: it's just that the build scripts are written that way that enabling h.264 decoding with ffmpeg indirectly enables h.264 encoding for WebRTC with openh264
<lfam>Oh, I see
<BlackMug[m]>i think this is due to this issue:
<BlackMug[m]> https://github.com/matrix-org/matrix-appservice-irc/issues/1324
<lfam>nckx2: I call dibs on the fin
<BlackMug[m]> https://anonfiles.com/Z2BdU4z8ue/whatisee_png
<BlackMug[m]>this is what i see from my side
<nckx2>Literally any other day I could log into my matrix.org account and test.
<nckx2>...whelp.
<nckx2>'There is likely an issue with the Matrix bridge.'
<nckx2>lfam: You'd only use it for evil to scare children at the local pool.
<lfam>nckx2: I've heard the soup is good
<lfam>But your idea is good too
<nckx2>BlackMug[m]: So what you don't see in the logs is that just after you posted that image, there was a wave of disconnections from the bridge, mentioning SIGTERM.
***whonix[m] is now known as BlackMug[m]
*lfam afk
<BlackMug[m]>test 123
<BlackMug[m]>nckx2 i see, seems to be im trying in bad times
<BlackMug[m]>i will wait couple of days/weeks hope this is going to be fixed
<nckx2>It would appear so. I don't know if it affects other Matrix users or just you.
<nckx2>I'm sure it will be.
<nckx2>A broken bridge is worse PR for both ends than none.
<BlackMug[m]>oh cool wait now i can see your comments
<BlackMug[m]>brilliant
<nckx2>:D
<nckx2>That's probably why they restarted.
<BlackMug[m]>yeah maybe some upgrades or so they have done glad it worked
<nckx2>Welcome!
<solene>I wrote about using guix publish in discovery/advertise mode https://dataswamp.org/~solene/2021-06-07-guix-packages-publish.html maybe I should propose it to put in the cookbook?
<nckx2>That's a great idea solene.
<BlackMug[m]>does guixsd face the same issue as debian:
<BlackMug[m]> https://forums.whonix.org/t/issues-with-removal-of-specific-packages-by-users-builders/653
<bauermann>hello! I'm doing `guix pull --branch=core-updates` and in the process, Guix is building ‘texlive-amscls’. is there a way to make it not do that? I just want it to update the package definitions (and guix itself, of course).
<bauermann>I don't know why it is building that package. I've been trying to build it with `guix build` but I don't remember actually ever trying to install it...
<nckx2>Which exact issue, BlackMug[m]? Guix doesn't have the concept of conflicts or recommendations at all, so everything is 'fixed'. Package A either refers to package B or it doesn't.
<bauermann>also, in any case just to be sure I did a `guix package -d` and also `guix package -d -r .config/guix/current` to get rid of older generations of my profiles, followed by `guix gc`. so guix shouldn't have any reason to go and built ‘texlive-amscls’. I'm very confused about why it's doing that...
<nckx2>If Guix upstream has packaged A to require B, and you don't like that, you could create a custom A variant with (say) --disable-b if A supports that. But there's no 'Installing A will ask you whether you want B, and if so will treat B as a heisendep of A' nonsense like in Debian and I'm grateful for it.
<BlackMug[m]>issue if x distro base itself on debian then one want to remove a package which already coming by default with x distro the package wont be only removed but it will take other packages as well <- This scenario is mitigated by guixsd design or still face the same issue?
<lfam>bauermann: Presumable, texlive-amscls is a dependency of Guix itself, or it's required to build a profile. Building a profile is something that happens for `guix pull`
<nckx2>Removing a Guix package can't remove other packages. Guix doesn't work like that.
<rekado_>BlackMug[m]: nothing will ever be removed as long as it’s needed.
<sneek>rekado_, you have 1 message!
<sneek>rekado_, roptat says: https://logs.guix.gnu.org/guix/2021-06-04.log#190630
<nckx2>And there's no way to express 'package A is allergic to package B' so installing something won't ever remove something else either.
<rekado_>BlackMug[m]: Guix knows what needs to remain in /gnu/store because it has a record of all references.
<lfam>bauermann: If you only want access to the package definitions on core-updates, I recommend using the 'pre-inst-env' mechanism, as explained in the manual sections Building From Git and Running Guix Before It Is Installed
<lfam>It lets you use Guix from a Git repo
<nckx2>You're sometimes forced to update packages together because of propagation, but that's it.
<lfam>However, my understanding is that core-updates is currently unusable bauermann, so the only reason to try using it is to fix bugs and get it into shape :)
<bauermann>yes, that's the reason why I'm trying to use it :-)
<BlackMug[m]>nckx2: thats brilliant, just to make sure again it doesnt matter/effect if the package from guix level (userspace) or from the system level (root)? both will react as a independent and nothing going to effected if any package removed right?
<dstolfa>nckx2: i thought you actually hit a shark with your car...
<dstolfa>see, i would have believed you
<rekado_>bauermann: texlive-latex-amscls is part of texlive-base
<bauermann>lfam, I wondered whether it related to a profile. that's why I did the `guix package -d` thing. but for some reason it wasn't enough. The only package I have in my profile is ‘glibc-locales’ so I'm confused. I'll use ‘./pre-inst-env’ then. thanks for the tip
<nckx2>dstolfa: It's not out of character let's put it that way.
<lfam>bauermann: There is software used to create new profiles
<dstolfa>on another note... i find it extremely difficult to update the system when i have local changes i depend on
<bauermann>rekado_, ah, and guix depends on texlive-base?
<lfam>Texlive may be part of that group of software, bauermann
<dstolfa>i wonder if this could be improved
<lfam>dstolfa: What kind of local changes?
<dstolfa>lfam: changes to guix itself, not just a package
<nckx2>What kind of local changes, dstolfa?
<nckx2>o_o nvm.
<nckx2>Still: how so:
<nckx2>*?
<lfam>Changes to Guix itself? How do you use these changes?
<rekado_>bauermann: no, but the texlive-configuration profile hook uses it
<nckx2>dstolfa: Built from git?
<dstolfa>well, one example is the service in vpn.scm that is in my system configuration
<dstolfa>so if i do a `guix pull` and update all my packages, i can't use that guix to reconfigure my system
<dstolfa>so i need to do a manual `git pull` in the local build to then reconfigure
<dstolfa>(with ./pre-inst-env)
<rekado_>bauermann: but a whole bunch of things do depend on a subset of the texlive distribution at build time.
<nckx2>You can point channels.scm to your local directory instead of Savannah.
<nckx2>Then just remember to git pull that before you guix pull.
<dstolfa>nckx2: hmm, does that work with my commits in there?
<BlackMug[m]>rekado_: you are talking about packages from guix thats nice but what about packages preinstalled within guix which only get upgrade with .scm reconfigure (root level) same thing?
<nckx2>Yes.
<dstolfa>oh.
<dstolfa>well silly me.
<dstolfa>thanks
<nckx2>You'll have to pass --disable-authentication (I think it's called, Guix will tell you) because you're not a committer, but it will work.
<rekado_>BlackMug[m]: I don’t understand the difference between “packages from guix” and “packages preinstalled within guix”
<bauermann>rekado_, lfam, ok, that makes sense then. I was getting a bit frustrated with not understanding what guix was trying to do. thank you very much for your explanations
<lfam>Let us know if you have more questions! We are happy to help
<rekado_>all Guix stuff ends up in /gnu/store and is protected from deletion through the daemon and its database of references
<nckx2>dstolfa: You'll still have the two-step <update local copy>, <guix pull> but you can script around that if it really bothers you.
<rekado_>bauermann: it *is* frustrating not to know why Guix does certain things
<dstolfa>nckx2: nah, that's okay. i don't mind it that much :) thanks
<rekado_>but the answer usually is: because it has to.
<rekado_>it’s not a very satisfying answer
<lfam>I agree with rekado_'s summary of the answer :)
<rekado_>what’s good about this is that Guix shaves all the yaks that need shaving.
*nckx2 AFK.
<dstolfa>nckx2: can i just give it a path somehow? (maybe with url?)
<dstolfa>as in... (urel "/path/to/checkout")
<dstolfa>url rather
<bauermann>lfam, awesome! thank you very much!
<rekado_>you don’t know that you needed yak wool, but Guix knows that glibc needs python at build time, and python needs a glibc without python, etc.
<nckx2>Yes, that's what I meant, a file:/// URL.
<dstolfa>ah alright. thanks
<nckx2>dstolfa ^
<nckx2>Gotta go now!
<BlackMug[m]>rekado_: guix upgrade wont upgrade packages which are pre-installed right? the packages will be upgraded if i type sudo guix system reconfigure /etc/config.scm
<bauermann>hahaha, picturing guix shaving all the yaks for me is very satisfying!
<rekado_>BlackMug[m]: what is “pre-installed”?
<rekado_>“guix upgrade” operates on user profiles such as ~/.guix-profile
<rekado_>“guix system reconfigure” builds a system (it also ends up in /gnu/store) and switches the current system symlink to the new one, restarts some services etc
<apteryx_>uh. If you ever have a Qt application crash mysteriously in QQmlPropertyCacheCreator<QQmlTypeCompiler>::propertyCacheForObject, try wiping out its qmlcache directory under ~/.cache.
<lfam>Well that's good to know
<rekado_>~/.cache is very frustrating
<rekado_>there are a number of applications that are affected by bugs relating to stale caches
<rekado_>I wonder if we can fix this generically
<rekado_>(and I don’t mean by “guix home”, but earlier)
<roptat>:)
<lfam>*/10 * * * * rm -r ~/.cache
<lfam>;)
<asdfuiop>hi!
<lfam>Howdy
<BlackMug[m]>rekado_: DE , NetworkManager , iptables...etc these are preinstalled packages
<apteryx_>lfam: haha
<apteryx_>ln -s ~/.cache /dev/null (untested ;-))
<lfam>BlackMug[m]: No, it's not correct to say they are "pre-installed", although I understand what you mean
<lfam>You can say that are part of the system
<apteryx_>more like the reverse, eh, I never remember the ln semantic
<lfam>target, link name
<lfam>Say it 10 times whenever you brush your teeth
<apteryx_>yeah 'what's new at the end, like copy'
<apteryx_>but I still manage to get it wrong
<lfam>Heh
<lfam>Somehow I managed to memorize it after a few years
<lfam>Right click, "Create shortcut"
<apteryx_>my logic is hardwired to something that points to something else a -> b
<jackhill>lfam: thanks for reviewing/commiting the dino upgrade
<lfam>Thanks for taking care of that package jackhill!
*jonsger hopes that the history contains a correct `ln` command :)
<lfam>Somehow I find "target, link name" to sound more 'fluid' than "link name, target"
<lfam>So it just works for me
<lfam>Funny how our brains work
<BlackMug[m]> https://forums.whonix.org/t/guixsd-distro-preview/11727
<BlackMug[m]>This is guix preview from couple of months experience.
<yoctocell>lfam: I have something like this in golang.scm: https://paste.debian.net/1200340/. When I try to build `go-github-com-muesli-reflow-indent' I get an error "In procedure copy-file: Permission denied". Any ideas?
<lfam>yoctocell: Please share all the output from the command on <https://paste.debian.net>
<yoctocell>lfam: https://paste.debian.net/1200341/
<lfam>I mean, all the output
<lfam>Not just the errors
<yoctocell>Oh
<yoctocell> https://paste.debian.net/1200342/
<lfam>It's probably the same issue fixed by the many other uses of 'make-gzip-archive-writable'
<lfam>It's common for Go
<lfam>BlackMug[m]: I agree with most of your conclusions
<lfam>"** Not useful for old or weak resources PCs, ** Not useful for low/limited disk space, ** Not useful for slow Internet Connection"
<lfam>It's definitely true for a build-from-source distro like Guix
<lfam>It's looking to the future where those constraints don't really exist
<lfam>It's exclusive to many people but it's a reality
<yoctocell>lfam: Hmm, I don't see any .gz files though
<lfam>yoctocell: Then it must be something else
<lfam>Does go-github-com-muesli-reflow-ansi build okay?
<yoctocell>yup
<BlackMug[m]>lfam: thank you glad i didnt write something which didnt represent the current situation. appreciated <3
<lfam>It's a good collection of issues BlackMug[m]
<BlackMug[m]>i hope to see the future as well to overcome these restrictions
<lfam>A lot of usability issues
<lfam>I don't think that making Guix work well for slow / no internet or slow computers will be something that happens soon, if ever
<lfam>yoctocell: Hm, not sure
<lfam>You'll have to get creative debugging it
<BlackMug[m]>yeah sadly thats true
<lfam>yoctocell: I would build it with --keep-failed and poke around. I'm not sure if it's crashing on the last copy action that it prints, or something that hasn't been printed yet. But I would take a look at that final copy action and see if it could possible succeed
<lfam>BlackMug[m]: We are working on improving the availability of binary substitutes and fixing problems that break substitution, so that will help people using old computers with substitutes
<lfam>There's nothing we can do for people who don't use substitutes but want to use old computers
<lfam>Or, there's very little we can do
<lfam>But, there's a long way to go to make Guix as easy to use as we'd like
<yoctocell>lfam: yeah, I have done that, all the files in the /tmp/guix-build folder are read-only, but I think thats normal
<lfam>Hm
<lfam>If it were me, I'd skim gnu/packages/golang.scm to see if any other package seems to be working around this kind of thing
<lfam>I wish I knew how to make the backtrace print full filenames, instead of truncating them
<dstolfa>would it make sense (at some point in the future), let users opt it to binary only packages? perhaps the simple way to do it is to have a "release" branch which gets automerged into from the master branch once a binary package has successfully built or something along those lines?
<dstolfa>in case someone really doesn't want to build anything?
<yoctocell>Hm, I see that `go-github-com-alcortesm-tgz' has a `make-git-checkout-writable' phase, I will try that
<lfam>It sounds tricky dstolfa. The "release" branch would end up with a different order from the master branch
<dstolfa>that
<lfam>And that would mean that derivations might not match, and thus substitutes wouldn't be available
<dstolfa>that's true*
<lfam>I think we should focus on improving the build farm and the substitute delivery mechanisms to be more reliable
<lfam>There is still a lot of low-hanging fruit three
<lfam>there
<lfam>The build farm has always barely worked, at best
<lfam>Now it is improving rapidly
<lfam>I think we are on the cusp of a sea change, at least for x86
<dstolfa>fair, it was just a thought :). maybe at some point in the future it would make sense to poke at in a way that respects the ordering, but then i guess the question becomes: "what if the package *doesn't* build on the build farm?"
<lfam>It could be that the "release" branch is simply a delayed feed of the master branch
<lfam>That would preserve ordering
<yoctocell>Hmm, `make-git-checkout-writable' doesn't seem to help...
<lfam>Well, if it doesn't build on the build farm, then one can just use Guix as we do now
<dstolfa>yeah, i guess "successful" build could be replaced with "any kind of build/failure"
<lfam>The build farm is like the canonical "does it build" environment for Guix packages
<dstolfa>but in any case, delaying the branch might be sufficient
<lfam>So, if it doesn't build there, that's a bug. If it doesn't build on my laptop, that's my problem
<lfam>I mean, I could file a bug about my problem. But it's not as serious as if it fails on the build farm
<dstolfa>yeah, that's reasonable
<lfam>It's why I don't usually reply to bug reports about "libreoffice fails to build on my potato"
<lfam>It's like, "Well, yeah"
<dstolfa>developer time, focus and all that :)
<lfam>But, it also fails to build on the build farm a lot (or, its dependency vigra fails to build). And that's a serious problem for Guix users
<lfam>We aren't too far off from combining `guix weather` with `guix upgrade`
<lfam>A delayed branch could be a "good enough" solution for now
<lfam>And conceptually it's simple
<dstolfa>yeah, how far back would it make sense? ~6 hours to ensure operating sys... i mean chromium builds?
<lfam>I was thinking it would be delayed based upon completion of CI evaluations corresponding to a Git commit. So, not based on time
<lfam>Successful CI evaluations, of course
<lfam>We'd have to make hard decisions about architectural support that we've punted on for a while now
<lfam>And that would be a pity because the users who need substitutes the most are using the types of computers (ARM boards) that we don't have enough of in the build farm
<lfam>64-bit ARM should get better with time, but armhf is never going to be something we can build every package for quickly
<dstolfa>what would the policy be for "commit 1: pass, commit 2: fail, commit 3: pass"? would it just merge regardless and just rely on the users using guix for rollbacks and so on?
<lfam>I'd say it would stop at 2
<dstolfa>hmm, how would it proceed then?
<dstolfa>manually?
<lfam>I guess that the idea needs work then :)
<lfam>I don't know
<dstolfa>i guess if the commit messages are standardized it could sort of pull information from there, but that sounds... fragile
<lfam>I'm not sure I follow...
<lfam>I don't see how commit messages are relevant here
<dstolfa>well, if a commit message always mentions the thing that is changed, you could read the commit message and say: "right, package X is failing a build", and then when it sees "package X" being touched again with a passing build, it could fast-forward the branch to that commit
<dstolfa>but that seems incredibly fragile and susceptible to typos
<dstolfa>the idea is similar to Signed-off-by, but for say, packages
<lfam>The CI doesn't use commit messages at all when keeping track of failures
<lfam>I think I understand. You are talking about "fixing" a broken package
<lfam>And how to make that understood
<dstolfa>yeah
<lfam>So, I watched a talk at FOSDEM from Ubuntu about quality assurance (QA)
<lfam>They "gate" their commits
<lfam>You push to some kind of queue, the CI builds everything based on your change and, if it works, then your commit is applied to the real branch
<dstolfa>that means the CI is ahead of the actual repository and wouldn't need a delayed branch then, right?
<lfam>It could be a bit annoying, since commits might land on the master branch in a different order than what the contributor intended. But, that intended order would not ever be "canonical" (no pun intended), so it wouldn't really matter much
<lfam>I'd say it would be based on "pushes" rather than "individual commits"
<lfam>Yeah dstolfa
<lfam>I mentioned it briefly to the FOSDEM Guix crew that year but I didn't explain it very well and it did not seem as important at the time
<lfam>I'll try to find the video now
<lfam>(I don't even remember which years I attended)
<lfam>Or what the rooms are called...
<lfam>It's the really big main room, auditorium style
<dstolfa>heh... i know the feeling :)
<dstolfa>at least it's FOSDEM, easy enough to remember that it happened at FOSDEM rather than at some side event which you forgot the name of
<lfam>Janson
<lfam>Heh
<lfam>Happy memories
*dstolfa remembers the first conference he went to... 18 hour trip and severe jetlag
<dstolfa>was still very fun, though
***lukedashjr is now known as luke-jr
<jab>hey guix! I'm trying to set up the substitues from https://bordeaux.guix.gnu.org/ ...where in the guile procedure (public-key ...) defined?
<solene>jab: https://guix.gnu.org/manual/en/html_node/Getting-Substitutes-from-Other-Servers.html
<solene>jab: for a real world example https://tinyurl.com/4nsjvz9y
<solene>what does bordeaux.guix.gnu.org provide compared to ci.guix.gnu.org?
<jab>solene: thanks for the info, but would you mind looking at https://bordeaux.guix.gnu.org/
<solene>I visited it but I don't really see what it provides except the arches
<jab>He lists the key, but not in a key file format...he lists it as the guile function (public-key ... ) How can I copy that guile code (aka where is the guile procedure (public-key) defined)....or how do I turn that public key into a file?
<lfam>dstolfa: I found it: https://archive.fosdem.org/2017/schedule/event/distribution_ci/
<solene>hmm, i586 and armhf maybe
<solene>jab: copy / paste for the key
<jab>solene: I don't know how to use the key that he mentioned...
<jab>solene: here is my code...and it doesn't work.
<jab> https://pastebin.ubuntu.com/p/qB9nXzy7B6/
<cbaines>jab, what you do with a signing key for substitutes depends on whether you're managing the Guix ACL declaratively or not
<solene>what do you mean it doesn't work?
<jab>cbaines: are you saying that I can use substitue servers with the signing key?
<jab>ice-9/read.scm:731:20: In procedure lp:
<jab>In procedure length: Wrong type argument in position 1: max-silent-time
<cbaines>jab, even though the key is an sexp, the Guix configuration expects a file, so you need to do something like this https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm#n936 (like 936 beginning (plain-file )
<dstolfa>lfam: great, thanks!
<dstolfa>i'll take a look
<solene>good night guix people :-)
<dstolfa>solene: gn!
<rekado_>jab: “public-key” is not a procedure.
<rekado_>the snippet there is data in S-expression format
<rekado_>it’s not code to be executed.
<jab>thanks!
<rekado_>(there’s a typo: “Using these substiutes” –> “Using these substitutes”)
<jab>just out of curiosity...what is (public-key ) ? a macro?