IRC channel logs
2024-05-08.log
back to list of logs
<singpolyma>Especially to encode just a shell script with no meaningful additional metadata... <cornflake__>hey y'all, are there any simple-ish firewall programs available for guix? My favorite is UFW, but I didn't find it in the repos. Firewalld isn't either there either, which is another common one. How do y'all set up your firewalls? <freakingpenguin>cornflake__: nftables can handle port blocking on a Guix System installation. Haven't used it myself yet but %default-nftables-ruleset looks intelligible enough. <Guest91>(previously Guest11 with the booting issue) ieure: Sorry I had to run an errand, thanks for the help earlier. I found out that my grub files are missing from the /boot directory! The only thing left is /boot/EFI/Guix/grubx64.efi <Guest91>On a typical GNU/Linux system I'd run grub-mkconfig to generate those files again - am I going to mess something up if I don't use Guix system to do so? <Guest91>Also does anyone know why grub files disappear sometimes? This is the second time that's happened to me when swtiching hardware aroun... <Guest91>Is ~/.guix-profile/etc/profile equivalent to ~/.guix-home/profile/etc/profile for guix home users? <freakingpenguin>Guest91: Equivalent as in you expect them to have the same contents? <freakingpenguin>IIRC .guix-profile/etc/profile deals with augmenting PATH for packages installed via $ guix install <package>, whereas guix home's profile adds the home environment packages to PATH + potentially a bunch of other stuff depending on the home environment. <Guest91>freakingpenguin: Equivalent as in performs the same function. The second message you sent answers my question perfectly, thank you! <Guest91>Hmm, my system reconfigure is seemingly stuck after "guix system: bootloader successfully installed ..." <Guest91>sudo herd status doesn't display anything (also appears frozen) <Guest91>I wonder what happened to the daemon <apteryx>uh! sysdig built; has anyone ever used that tool? <apteryx>will need to patch its default path to the BPF probe. something for tomorrow I guess <apteryx>Guest91: I had that too; I think perhaps an upgrade to shepherd caused it? rebooting cured it <apteryx>hm, libpman: prog 'BPF_TRACE_RAW_TP' is not supported <Guest48>Hi there, I have some corrupted files in my /gnu/store - just 4 files I need to remove due to btrfs corruption but I don't know the guix way to do that. My chimp brain wants to just nuke them... <Guest48>The man page for guix gc indicates I can specify PATHS, does that mean I can give it the exact files I want to slate for removal? <Guest48>Seems like it works that way with --delete, nice <jonsger>That is strange: if I do `./pre-inst-env guix build gnome-maps` one tests fails. If I do in another terminal `cd /tmp/guix-build-gnome-maps-46.10.drv-0/build && source environment-variables && cd build/ && meson test` this failed tests becomes green... <jpoiret>jonsger: probably because of the build environment? <jonsger>jpoiret: so environment-variables doesn't contain all necessary variables to do the build "locally"? <jpoiret>that's not what i'm saying: the build environment is very restricted, so some tests might fail because of it <jpoiret>also it might be a transient test failure <jonsger>jpoiret: can I somehow jump into the proper built environment? <jonsger>the tests fails stable. But its somekind of time test/check. So I assume some TZ/LANG whatever variables influencing it... <cbaines>maybe try setting (setenv "HOME" "/tmp") just to rule out the "Failed to create" warning having anything to do with the failure <jonsger>I can try. But this is also printed at other tests who passes... <jonsger>Seems it requires TZDIR set to the tzdata package... <cbaines>I guess that makes sense, given the test uses a named timezone <jonsger>yeah, now only getting it properly with Guix code + gexp :P <cbaines>jpoiret, hey! thanks for making it through cleaning up core-updates! Is there anything I can do today to help? <cbaines>I did spot that the data service failed to process the branch <jakef>any python team members around? <jpoiret>cbaines: weigh in on how we should proceed with updating glibc 2.39 in the ML if you've got an opinion on that <jpoiret>cause that's going to cause a world rebuild anyways so I don't think we should be spending cycles on this until then <rekado>I'm still working on it to try and fix more build failures <apteryx>oh, the Linux kernel doc has some section covering managing PGP keys (info '(TheLinuxKernel) Kernel Maintainer PGP guide'). Perhaps we could cross reference that somewhere in ours. <cbaines>jpoiret, I think I'm missing some context but I'll try and read the relevant bits on the mailing list <dariqq>has the format for how python tests are invoked changed? Trying to update python-argparse-manpage and tests fail to start with Command.__init__() missing 1 required positional argument: 'dist' <jakef>i feel like i'm missing something python-matplotlib <rekado>jakef: sorry, I don't know anything about this. I'm just cleaning up build failures. <rekado>dariqq: what build system are you using? <rekado>for pyproject-build-system you may need to add more packages to the inputs. <dariqq>rekado: thanks for the hint. switching to pyproject build system and adding pytest worked :) <rekado>remote: fatal: Out of memory, malloc failed (tried to allocate 56137 bytes) <rekado>remote: aborting due to possible repository corruption on the remote side. <rekado>is Savannah unable to serve our regular git cloning via guix pull? <h4>When performing a `guix shell` or really anything that'll get packages from substitutes, what will define default target version? Like what define the last git state, last date definition of the OS? It doesn't seem to be changed by `guix system reconfigure` anyway because it changes without even performing that <rekado>h4: the "guix" command determines what you get <rekado>whenever you run "guix pull" you get a new variant of Guix, which comes with its view on the world of software. <rekado>a Guix environment is fully specified by the version of Guix and the manifest / set of packages you request. <h4>rekado: I want to revert to an older Guix revision, that had older package as its target. More precisely I want the one I had before performing the last `guix pull`, because lot of cached packages and no bandwidth <jpoiret>h4: guix pull --roll-back does exactly this <jpoiret>it reverts your guix to the previous pull profile <h4>Would be even better to have a command to see cached package number per revision to know precisely the one we want rollbacking to <jpoiret>you can see your guix pull generations with `guix pull --list-generations` <h4>jpoiret: That command rolls back one pull? What if we want multiple roll backs or roll back to a precise state? <rekado>h4: this command also exists. It's called "guix weather" <jpoiret>--switch-generation=N to roll back to a specific generation number <jpoiret>if you want a specific commit, use guix pull's --commit argument <h4>jpoiret: Oh I didn't knew at all about generations of pull, only generation of reconfigure <rekado>you can also do arbitary jumps to commits you never pulled <jpoiret>you can specify an entire channels.scm file for that <rekado>either with what jpoiret just wrote or with "guix time-machine" <jpoiret>`guix time-machine` is to `guix pull` what `guix shell` is to `guix package` <dariqq>rekado: If i send the update to argparse manpage should that go onto python-team branch or master? <cbaines>jpoiret, having a diff between the glibc 2.39 branch and tag as a patch seems OK <rekado>dariqq: "guix refresh -l python-argparse-manpage" tells me that it could go to the master branch <cbaines>I do wonder why there isn't a 2.39.1 release with these changes though <dariqq>didn't know about that option for guix refresh, thanks <h4>jpoiret: > you can specify an entire channels.scm file for that\nAren't channels.scm to specify channels? Or you mean specifying commits on a channel basis on it like permanently, contrary to commands that are deemed temporary? <jpoiret>the guix channel itself appears in channels.scm <jpoiret>cbaines: upstream policy, they don't do bugfix releases iiuc <cbaines>I wonder why they bother cherry-picking commits on to a 2.39 branch then? <rekado>h4: yes, channels.scm is for specifying channels. Guix itself represents a channel. Each channel is made up of commits, and you can specify a channels file that requests particular commits for any of the given channels, including Guix itself. <h4>$ guix weather\nguix weather: warning: failed to load '(gnu packages agda)': Permission denied \nguix weather: warning: failed to load '(gnu packages cedille)': Permission denied\nice-9/boot-9.scm:1685:16: In procedure raise-exception: \nerror: python-ansible-core: unbound variable <h4>$ guix package --list-generations\nguix package: error: profile '/var/guix/profiles/per-user/$USER/guix-profile' does not exist <jpoiret>h4: what does `echo $USER` give you? <h4>jpoiret: My current username <jpoiret>do you have a non-default umask perchance? <h4>jpoiret: Afaik I've modified umask sometimes to perform some operation, but didn't that last only for the session/shell? <jpoiret>yes, but it might have affected the guix operations you might have done then <jpoiret>ie create files with the wrong permissions <h4>jpoiret: Is there a way to verify that a created file has permissions it shouldn't have? To be sure it's wrong permissions <jpoiret>first, can you `ls /var/guix/profiles/$USER/guix-profile`? <jpoiret>uhm, just `/var/guix/profiles/$USER/` actually <h4>jpoiret: cannot access: No such file or directory for both <jpoiret>have you ever used guix with this user? <jpoiret>you can't roll-back if you haven't pulled yet for example <h4>jpoiret: That's the only user on the OS since OS is installed, and I created some generations since installation <jpoiret>the good news seems to be that they also include the regenerated configure scripts in the commits, so no need to reconfigure ourselves <jpoiret>well, it's bad news wrt. building from source, but here it's nice :) <jpoiret>h4: ah, my mistake, I mistyped and forgot a folder, it should be `/var/guix/profiles/per-user/$USER/` <h4>jpoiret: $ ls /var/guix/profiles/per-user/$USER\ncurrent-guix current-guix-1-link current-guix-2-link current-guix-3-link current-guix-4-link <jpoiret>seems that you don't have created a package profile <jpoiret>`guix package --list-generations` will list the `guix package` generations, while `guix pull --list-generations` will list the guix pull generations <jpoiret>apteryx: wrt. the pkgconf-less version, I dropped the revert of the mpv propagation thing, which should be equivalent <h4>jpoiret: I pushed some config.scm, default manual configuration to have gnome and such. But otherwise I don't have the time to figure out that file so I live on `guix shell` for other than default packages. So officialy packages were installed <h4>jpoiret: guix packages list generations don't work because it can't find guix-profile <jpoiret>the system configuration doesn't create a `guix package` profile, but a `guix system` generation <jpoiret>if you've not used `guix package` to install something then you probably don't have a package generation <h4>jpoiret: You can either specify packages in config.scm and push through guix system reconfigure, either install in a package manager way with guix package, either use temporary package with guix shell. And my politic was so far to put permantnet packages thrgough guix system reconfigure and temporary ones with guix shell and abandon altogether the package manager way of doing things that is not *nix way <h4>But I do have system generations, they're even listed in GRUB <h4>Because I pushed through guix system reconfigure <jpoiret>h4: I wouldn't say that `guix package` is not the *nix way <jpoiret>but anyways, if you don't use `guix package` then you probably don't need `guix package --list-generations` either <jpoiret>if you want a declarative configuration for your user as well, have a look at `guix home`. I don't think installing all the long-living packages for your user should involve `guix system` <h4>jpoiret: Sorry I used the wrong term, I mean transactional or smth like Guix/Nix <h4>jpoiret: The long-living/permanent packages shouldn't be stated through config.scm? <h4>I thought it was the way to go there, I don't really know about guix home <h4>I don't quite get the difference between them. I seem to understant that guix system reconfigure is for system definition and guix home for user definition. But I don't get why everything can't be done with reconfigure alone <bienjensu>h4: The notion is that user configuration and system configuration are separate. You 'should' be able to move your user config to a different machine, and just have things work. On the other hand machines might need different services &c. <bienjensu>ideally a home configuration wouldn't need priviledges on a system, so you could use it in a shared environment <attila_lendvai>ACTION continues to deploy/test his shepherd and guix commits on an actual server <h4>bienjensu: Okay, so I should put as most as possible as what I want on other system on user configuration. But sometimes things I want can be binded only to one system, like idk, a driver doing wonderful things. Or like you said some system needs a particular twkeak because them <decfed>how do I install the guix manual as an info package and read it using emacs info-mode? <h4>decfed: Isn't it aleready available locally with a command? <acidbong>hi there, hello. a lil question on wine packages: as i understand from the sources, wine and wine-staging are 32bit-only and wine64 and wine64-staging are multilib, right? <h4>I performed mutiple `guix pull` in a row the same day. Does it create a new generation at each `pull`? At each new published commit in one subscribed channel? At each session opening? At each OS booting? <bjc>generations are only created when the system/home is reconfigured or you install/remove a package <bjc>guix pull doesn't do any of that. it is a bit of a weird one, because it does update your environment, but just the "guix" command, which lives in its own profile for reasonsâ˘, so i guess that doesn't count? anyway, âguix time-machineâ is effective at using whichever rev you want, though it's not strictly equivalent to generations <ieure>Adding some color: One per commit would be wasteful, because you don't need the intermediate states. One per system boot or session would make system behavior slow and unpredictable. <ieure>I'm not convinced that bjc is correct. `guix describe' shows my system at generation 18, and it's generation 19 after a `guix pull'. <bjc>huh. i may be misremembering <ieure>This makes intuitive sense to me, since `guix describe' lists the commits for each channel, which `guix pull' updates. <bjc>it should list the commits for the current generation, not whatever version guix you're using <bjc>i am! it's just slow =) <ieure>I know. :( It's why you answered before me. <bjc>well, it's behavior that makes sense, at least, since it is an update to your profile <podiki>guix pull has its own generations <podiki>try it: guix pull --list-generations <podiki>profiles and system have their own <bjc>sure, but this is going into the output of âguix describeâ <podiki>guix describe tells you your current guix pull, yes <bjc>i haven't used that command since first installing guix, so i guess i don't understand what it's supposed to do. <podiki>you can rollback guix pull profiles as well <ieure>Yeah, `guix package -l' lists profile generations. <ieure>`guix pull --list-generations' is unconscionably slow. <bjc>what âgenerationâ does âguix describeâ describe, then? <podiki>which is your guix pull generation <podiki>think of guix (and the package definitions) having a generation determined by guix pull <bjc>oh. man i'd just assumed it was the current profile <ieure>$ time guix pull --list-generations # -> real 0m35.551s <podiki>while a profile or system configuration has its own generation, when you do an install, reconfigure, roll-back, etc. <bjc>nono, i get what's going on, i just didn't understand the output i was getting <podiki>profile of what though, is key. guix (pull), system, home, another profile <bjc>the implied one that you get when you're not talking about home, system, or an explicit one. ie: ~/.guix-profile <bjc>i had been assuming its output would be different based on which profile you were in, but never tested, and i guess i'm wrong =) <podiki>depends on the command, guix package does operate on that profile by default yes <podiki>guix system on the system profile, guix pull on the.."pull profile" i guess? <bjc>âguix shell guix -- guix describeâ doesn't even list the generation? <podiki>you can specify a profile for guix pull as well (useful for testing, pulling to a profile in /tmp for instance, instead of your actual guix) <h4>When I `guix weather`, it spawns a lot of errors and ends up not giving me the weather at the end <ngz>rekado : I pushed a new "tex-team" branch, which includes a couple of fixes, and a proposition of a more modular `texlive-bin' package. Unfortunately, it doesn't fix the biggest "ls-R" issue. Please let me know what you think about it. <PotentialUser53>Hello, I've submitted a few patches to the issue tracker over the past few months and received very quick feedback on one of them and radio silence on the others. I'm assuming they just slipped through the cracks with the large volume of patches you receive. Is there specific etiquette for bringing those to someone's attention? <bjc>just send a follow up message <bjc>its helpful to mention that you're still using it, it still applies cleanly, etc <bjc>you may still end up in /dev/null, but that's the advice i was given <bjc>(didn't work for me) <vagrantc>PotentialUser53: do the patches fall under one of the teams in etc/teams.scm ? have the appropriate team members been CCed ? <PotentialUser53>vagrantc I'd have to double check who was cc'd. They're just some python and R packages. I had just followed the instructions in the docs for submitting patches, so I probably did not cc any additional groups. <prg>Hi - what's the proper way to uninstall guix? <prg>or am i supposed to manually purge all the _guixbuilder users and groups <dariqq>prg: how did you install it? Since somewhat recently the install script has an --uninstall option <rekado>cuirass is really weird sometimes <rekado>but the log is full of a failing qemu build <rekado>that build has been fixed, but the virt-manager build is marked as failed because qemu failed <rekado>that's for java-eclipse-xtext-xbase-lib-2.25.0 and for some reason it's a huge build log because the build of the JDK is included. <rekado>the build coordinator does this correctly <rekado>I don't understand why cuirass cannot guarantee that all derivations a build depends on are in fact fully built <podiki>i too have noticed that dependents often don't get rebuilt upon fixing a dependency <podiki>sometimes it takes a while for the built to automatically get restarted, but often nothing happens <graywolf>civodul: Hi! Out of curiosity, from guix git authenticate, is there any difference between --armor and --no-armor keys? The blogpost exports the keys in binary form, but Guix's keyring branch seems to have keys in ASCII armored form. <sneek>graywolf, you have 1 message! <sneek>graywolf, dsmith says: I was thinking something like (define (string-append-anything . args) (with-output-to-string (lambda () (for-each display args)))) <graywolf>sneek: bad bot, that was supposed to be in #guile <rekado>freakingpenguin: /patch-set takes an optional argument to select the revision <freakingpenguin>rekado: Neat, thanks! Do you know if there's another endpoint to get the number of valid revisions? <rekado>freakingpenguin: there is no such endpoint <rekado>but if you want to add it you could propose a patch <Kolev>LilyPond comes with an Emacs mode for editing musical score files. Where's the emacs-lilypond package? <freakingpenguin>rekado: Gotcha, thanks! Are patches for mumi still submitted to guix-patches? <jonsger>Kolev: not yet in Guix. But we are happy about a patch adding it <Kolev>jonsger: I'll look into it tonight.