IRC channel logs
2024-08-06.log
back to list of logs
<sturm>I really like that Guix --pure and --container environments are still running *on the same host*, unlike the way Docker environments are on on a separate host. Is that inherent in the way Docker works, or can you also run environments without separate networking infrastructure? <sturm>(I guess that's more of a Docker question than a Guix question - just curious if anyone knows.) <sturm>It's relevant for me when running a program that, for example, wants to access a PostgreSQL database using a unix domain socket. <ieure>sturm, Docker containers also run on the same host. <sturm>ieure: yes, but they're a separate host from a networking perspective right? <ieure>sturm, It depends on how you run the container. I believe "host networking" is the Docker term for containers which don't have separate network interfaces. <ieure>Both system use the Linux kernel's cgroups and namespace features, so both have the same fundamental abilities. their specific behavior depends mostly on their respective defaults and how you tell them to run things. <sturm>hmm, maybe the difference I'm thinking of is really between --pure and --container also. I'm using --pure heavily because it gives some isolation in terms of dependencies, but it's convenient than --container. <ieure>--pure just prevents the invoking shell's environment from getting inherited by the subshell, which means the subshell can't see anything installed in the profile it was invoked from. <ieure>Can help if you're building a package and want to make sure it's properly using stuff in the store, rather than working accidentally because some program it execs is in the profile of the parent shell. <ieure>--container is kind of a hassle to use, because it defaults to no networking, and you have to tell it to pass a bunch of environment variables into the container if you want to use a graphical program. <ieure>sturm, Sorry, not trying to tell you that you're wrong here, just trying to increase understanding of how these things work. <PuercoPop>I stumbled into the same error as https://issues.guix.gnu.org/63238. However I'm unclear as to what is the workaround. The rust project this is happenining is literally a fn main () { prinln!("hello world") } so I'm not even sure why it would happen in this scenario but not others <ieure>PuercoPop, If you're building a Guix package, put (glibc static) in its inputs; if you're compiling outside the guix build infrastructure, `guix install glibc:static' or `guix shell glibc:static', then build in that. <ieure>PuercoPop, I have no idea if this works, but that's the workaround suggested in the linked issue. <PuercoPop>ieure: from where is glibc:static exported? I see glibc in (gnu packages base). <PuercoPop>Ahh, it looks like static is an output of the glibc package <PuercoPop>So do I only need to import glibc and then the symbol glibc:static is available in the manifest? <ieure>No. I'm not sure how to express the non-default output of a package in a manifest; it's probably in the manual. <ieure>(specification->package "glibc:static") maybe? But not sure. <PuercoPop>ieure: I think I can use guix shell --export--manifest glibc:manifest to find the incantation. <PuercoPop>Makes sense, as an output is not a package and I was trying to pass glib:staic to packages->manifest <PuercoPop>ieure: Thanks, that did trick! Now I'm running into a different error, progress! <Altadil>But when I apply it to my own package (just for a simple test guile script), I can’t build with "guix build -f guix.scm". It tells me "no code for module (guix)" <Altadil>I’m really puzzled here. How could it be unable to find that module? It works when I just copy and paste the guile example. There must be something obvious I’m missing. How can I further investigate? <futurile>Altadil: are you running it inside a guix shell? <futurile>Altadil: from the same directory that has the package from definition from 'Getting Started' <Altadil>futurile: I get the same result with or without the guix shell. <rekado>Altadil: do you have any files or directorise named "guix" here? <rekado>could you perhaps share your guix.scm? You say that the example from the manual works, but that's truncated, so I wonder what exactly works here. <fnat>Hm, I added '--expose=/etc/ssl/certs/' and included 'nss-certs' as a package, but that didn't help. <fnat>Ha... this seems to work though: 'guix shell --container --network beets nss-certs guix -- beet import /path'. <fnat>The best incantation seems to be 'guix shell --container --network beets nss-certs openssl -- beet import /path'. (Which I understand is just a bit of a work-around, but probably the best option all considered?) <ohyllad>Anyone else having issues with sway segfaulting on xkb? <rekado>Altadil: hmm, this looks fine to me. What does the file that actually works look like? <ohyllad>figured it out, it turns out if you don't have a /dev/shm fs mounted, sway just dies when you touch your kbd <Altadil>To be accurate, the build of guile does file later on, but it is really a build failure and not a problem with the guix.scm <weary-traveler>are guix services the right abstraction for describing processes that communicate back and forth? or would something like GWL be better? i'd like to describe computation where process A and B have two-way communication with each other (perhaps with pipes or something else) <PotentialUser-34>Hello. Does anyone of you use https://trac.edgewall.org/ inside Guix? I tried the package today and configured it, but I get an Response not started error for every change I want to do on the running wiki. The debian package I tried afterwards with the same config works well. <PotentialUser65>am I updating guix incorrectly? I do a guix pull and see that it's building "guix https://git.savannah.gnu.org/git/guix.git 892a915" but when I do a guix describe afterwards I see i'm still at "8e2f32cee982d42a79e53fc1e9aa7b8ff0514714" which is the commit tagged for v1.4.0 <Rutherther>are you using the correct guile command? did you "source ~/.config/guix/current/etc/profile"? <PotentialUser65>that fixed it, but I'm confused why I needed to source that. after running "guix pull" it tells me to run "hash guix" to ensure my shell is pointing to ~/.config/guix/current/bin/guix, which it is <Rutherther>it was pointing to ~/.config/guix/current/bin/guix even before you sourced it? it just adds it to path, so I don't really see how it could've fixed it in that case <Rutherther>when you do "which guix", it still points to ~/.config/guix/current/bin/guix now? <futurile>PotentialUser65: are you on a foreign distribution like Debian where you installed Guix from the Debian package? <PotentialUser65>I am on ubuntu and installed using the guix-install.sh from the docs <weary-traveler>are guix services the right abstraction for describing processes that communicate back and forth? or would something like GWL be better? i'd like to describe computation where process A and B have two-way communication with each other (perhaps with pipes or something else). i have experience with neither, and wondering where i should start my journey <futurile>PotentialUser65: ok - try doing guix pull --list-generations and it should show you when it did the pull <futurile>PotentialUser65: don't forget you have to also pull the root and then restart systemd's guix service to update the 'guix daemon' that's running <Rutherther>futurile: is it important the daemon guix revision is the same? if so, why exactly? <futurile>Rutherther: no it's rarely important - which is why I asked how they'd installed guix - but 1.4.0 was about 1.5 years ago so I'd say that's too long for sure <futurile>Rutherther: when you do a command 'as a user', you're talking to the guix daemon, so the daemon and the user's version of Guix have to be 'compatible' - I tend to update both at the same time just because it's easier <Rutherther>futurile: if I may ask, why was there no release for such a long time? it's a pity distros are usually synced with releases, so because of that it's very outdated <futurile>Rutherther: it's a rolling release - so every time you do 'guix pull' (on both root and your user profile) you get the latest version of the Guix daemon (therefore any new guix commands) and all new packages/services <futurile>Rutherther: so for an end-user you can get the latest-and-greatest all the time <futurile>Rutherther: it's not totally 100% true, there are big things that don't get integrated so fast - so there is some pressure to do a full release again <Rutherther>futurile: I understand that guix pull itself is rolling. I just don't understand why there were no releases, I just wanted to ask due to the _problem_ that other package managers will use only the release, leading to outdated guix version <Rutherther>futurile: but on that rolling note. It's proving hard to me to actually get information about the process of merging stuff into the branch you get the data from when you do guix pull. For example with nixpkgs everything first goes into "master", and then to "unstable" when stuff builds and tests pass, so people then get substitutes, and sort of guarantees. Is there something similar for "guix", do you happen to know resources that would explain this?... <futurile>Rutherther: technically what happens is that where there is a 'team' they can work on a branch (example is the python-team), and then those are merged into master on a regular basis. <futurile>Rutherther: the situation with packages that go to these branches is that they all go through CI first - so master should always be usable and it's better if things go to a branch first - this change to 'team based branches' is relatively new <futurile>Rutherther: in 'Submitting Patches' it refers to how package changes are scored - basically if a package would cause the whole world to be rebuilt then there's a special branch called 'core-updates'. This branch - when merged - has all the things that cause a big 'release'. <Rutherther>futurile: so these branches are per 'team' only? if there was parallel work in "python" 'team' and "rust" 'team', some packages from python team can depend on rust for example. Will they make sure merging both branches to master will be fine? <futurile>Rutherther: correct - generally doesn't happen - but everyone's still getting used to it - there was a recent discussion about this on the devel list - to try and basically have teams only pull in master onto their branch (no rust->python merges etc) <futurile>Rutherther: effectively other time there's an attempt to make each branch short-lived - core-updates is a problem right now because it has so many changes from 1.5 years of effort <Rutherther>futurile: okay, this seems fine. Though I am surprised they didn't just use something more similar to what nixpkgs uses, as that really makes sure everything goes through CI, even stuff combined from multiple 'teams' <Rutherther>futurile: is there an estimate for when will core-updates get merged? does that change somehow how packages are written, guix operating system made, guix home made etc.? <vagrantc>futurile: heya, curious if you had a chance to check out if the recording of the reproducible builds talk went ok <futurile>Rutherther: well nix and Guix are so different in reality - Guix has about 30-50 people contributing at a stretch - most of the 'teams' are 1 person or maybe 2. So some of the things that make sense for a massive project are just too much overhead for something like Guix. <futurile>Rutherther: no I don't think there's an estimate - core-updates looks hard - it's mostly things like architectures that are impacted - not user command <Rutherther>all the more reason for me to learn Guix sooner rather than later and start contributing :D <Rutherther>futurile: thank you very much, sorry for spamming you this much with questions, I would have like a thousand more questions, but I will keep them for some other time <vagrantc>automated signed commits are a bit tricky without doing lots of merges ... and the signed commit model woudl have to trust ... the automated process which is a bit ugly. <futurile>vagrantc: I have basically not done anything on the videos - mixture of being too hot and honestly attention elsewhere - I'll try and look before I travel, otherwise it's going to be a few weeks <vagrantc>futurile: ok. nothing urgent, just curious :) <futurile>vagrantc: yup, yup - it's a good reminder - I should have got it done - just bleugh 'feels like holiday season' <futurile>Rutherther: no worries - the manual is very good and nobody minds questions on the mailing list <Rutherther>vagrantc: is this recording public? would you happen to have a link? <Rutherther>yeah, I am trying to read the manual first, this was just stuff I wasn't able to find anywhere <vagrantc>you'd need termrec or ttyrec, which as far as i know is not yet in guix <vagrantc>i toyed with packaging it just for the talk, but decided that was too much yak shaving. <vagrantc>could have used asciinema, but found it to be harder to use and missed some nice features <Rutherther>vagrantc: this is cool, didn't know about tool like ttyrec. I have it from nixpkgs, working fine. Thanks <old>I have a package that I can build from source myself but whenever I ask guix to build it with `guix build --with-git-url=package=URL' I get the following error: <old>autoreconf: running: /gnu/store/kngd1h8b65kdnawd9mfxarwhkaxwq0lz-autoconf-2.69/bin/autoconf --force --warnings=all,error <old>configure.ac:1: error: possibly undefined macro: dnl <old>When I build the package myself, I have the same version of autoconf, althought not the same store object as when Guix is doing so