IRC channel logs
2024-11-13.log
back to list of logs
<ieure>ArneBab, I dislike the scanners, because they lie about the state of code to people without the time or inclination to understand the context, who then make me waste time fixing nonexistent problems. <ieure>meaty, Have a paste/channel/branch or something? <ArneBab>ieure: can’t you just say "doesn’t affect us"? <ieure>ArneBab, Yes, and I do, and that part of the org is very tired of hearing me say so, because whatever exception process they have in place is burdensom. <meaty>I have tried just removing the patches, changing phases, etc. but that just leads to more cryptic errors <ieure>meaty, I'll take a look in a little bit. If you paste the error(s), someone else may be able to help you sooner. <meaty>admiteddly I'm taking a naive approach here but tbh I don't think I fully understand what's going on w/ the package process here <mange>While it complains about the file being read only, I don't think that's the issue. I think the diff is failing to apply to the updated source. <mange>Yeah, on master I get the same "File src/d_main.cpp is read-only; trying to patch anyway" line, but the patch application succeeds anyway. <ieure>Probably a good idea to extract the upstream source tarball, I've run into some wacky ones that unpack with like 0440 modes. <meaty>so I should pull a userland copy of the repo and write some new patches <mange>It's a git source, which are always read only. <mange>But yeah, I would pull the upstream repo and see if you can fix the patch (or maybe it's not needed any more?). <ieure>meaty, How are you building this? `guix build -f file-with-your-code.scm' gripes. <ieure>"guix build: error: #<unspecified>: not something we can build" <ieure>Oh, have to put the package var at the end of it? That's weird. <meaty>`guix build gzdoom-new -L ~/.../wwchannel' <meaty>but the -f way would prolly be better for prototyping package defs <ieure>Yeah... don't have the channel, though. Or the patches. <ieure>And patches don't work the same way in Guix as they do in external channels. <ieure>All good, I just transplanted your changes into my staging Guix checkout. <ieure>But now I have to refresh that. <meaty>I decided to "start from scratch" and work my way up. it complains about missing zmusic so I put the substitute* clauses back in but now fix-file-names phase fails claiming mkstemp is missing i think <meaty>I'm gonna try just packaging zmusic seperately instead of whatever was done previously <ieure>meaty, Looks like zmusic isn't included in libraries/ anymore, which is why that phase is failing. <ieure>Yeah. Looks like zmusic needs to be packaged for this to work. <unmush>is there no way to specify a search-path-specification that includes only directories with certain contents? <unmush>I have some search paths that require that the top-level prefix is specified, but it needs to be limited to only ones that contain certain subdirectories <Rutherther>unmush no, search paths will be provided when the folder they refer to exists, there is no other mechanism that would mask them <Rutherther>@jck something like #!/usr/bin/env -S guix time-machine xxx -- shell -m $@ <p00f>hi, is there a way to bypass the nscd requirement in guix's emacs? archlinux doesn't have nscd <futurile>polyedre: thanks - appreciate the vote of confidence in the design - spent quite a bit of effort on it - hope it shows some interesting results :) <futurile>And we have 424 full submissions to the survey, so that's great. I guess most people who are here or on the mailing lists will have seen it now <futurile>I didn't think of the reddit - I only ever read it - heh <futurile>I've also asked on #lobsters about submitting it to https://lobste.rs/ - not sure if it's the sort of thing that's interesting to that board <futurile>jaft_r: oh nice! Hopefully that will get it seen by a wide set of users and people who've experimented with Guix <efraim>the guix architecture question is missing riscv64 (and 32-bit powerpc) <fnat>futurile: Is it 424 submissions as in completed surveys (as opposed to started but left along the way)? That seems like a great number! Yay! <hapst3r>anyone present who uses guix to manage zsh and plugins? I installed zsh-completions but somehow these don't work as I'd expect them to <divya>ekaitz: Hey, just pinging about that last patch. If you get time, do check :) <ekaitz>the way you aligned the phases is not the most common one, but there are other packages that do the same so I just kept it <divya>Okay, sorry I didn't seem to get an email so I wasn't sure. <ekaitz>it's ok i understand the excitement <divya>haha, once again ekaitz thank you for taking the time with this and teaching me the essentials. <ekaitz>don't worry mate, i was there not that long ago <ekaitz>hopefully soon you'll be a known guix hacker <marmar>in emacs, installing emacs-magit is not enough and would download additional packages when I setup magit using use-package with errors about transient. is there a way around this? <xelxebar>For the past week or so, guix reconfigure keeps trying to build u-boot-tools, which fails the check phase due to a segfault. <Rutherther>xelxebar most probably dont as they dont use u boot bootloader. But those who do use u boot see it. It is broken. <futurile>efraim: oh I'm sorry, I thought I got everything <efraim>I'm sure if I put down ppc32 it would've made it obvious it was my response :) <futurile>fnat: it's 445 completed submissions, 151 incomplete ones. An incomplete one can be someone going to the entry page and leaving, there seem to be fewer drop-offs now I added a note about it at the start and some text on the last page (I surmise the 'submit' button was not obvious on the last page). <futurile>efraim: I probably should have asked you to check that question, as I had to check Wikipedia for the correct architecture names - not my area of knowledge for sure! <fnat>futurile: It seems like a remarkable number to me, well done! <futurile>fnat: It's a good number, I think/hope it will be representative of users/contributors across the community with that many people. <futurile>fnat: I've tried to submit it to other places where less 'involved' users might see it. So lets see if people keep coming to it as they see info about it. <bunk>Hi, is/will there be a CVE number assigned for the Build User Takeover Vulnerability mentioned in the topic? <efraim>bunk: perhaps eventually, it's not been easy to request an actual CVE number in the past <divya>Does someone have experience with guix and cups? I'm trying to get this printer to work for a month, but nothing's been working. <orahcio>Hi, does someone can help with guix install on nixos? Can I use the same method to install on any foregein distro? Debian or Arch, for example. <futurile>orahcio: I don't know about nixOS, but the install on Debian/Arch is to use the download script that's linked from the home page <dariqq>orahcio: afaik there is a nixos module <orahcio>thanks futurile, I think on nixos is a little different because nixos has no FHS like Debian/Arch or Ubuntu <orahcio>dariqq: I did the `services.guix.enable = true;` to enable guix on my nixos, but I could see a error when I did `guix intall hello` <orahcio>"guix pull: erro: reading file `/gnu/store/4pkx3vg8wml374ab6fs2w0cgknl5abyg-tar.drv': No such file or directory" <orahcio>I could not find this error on google <dariqq>mhh maybe try 'guix gc --verify=contents,repair' <orahcio>I could to do that commando with root privilages <orahcio>Thank you very much dariqq, after this I could to do `guix install hello` <dariqq>Great, not sure why your store got corrupted <orahcio>maybe the nixos service can not build a minimal store <bdju>is guix home mandatory for using pipewire on guix system? <rekado>bdju: no, but it makes it much easier <rekado>otherwise you'd need to run things manually and set up variables. <rekado>it cannot easily be configured "passively" <icepic->xelxebar: When you give me the command to reproduce the Issue I can look into it during the next days. <wakyct>bdju, there are some configs out there that pre-date the new home service, but yeah the home service is pretty much plug and play <wakyct>one wrinkle might be if you use jack a lot <dariqq>is the tests/go.scm test failing for anyone else aswell? <dariqq>the error is unexpected-url in the url for go-check <futurile>has anyone ever had `pseudo-headers` work with debbugs.gnu.org? <ieure>Is there a way to authorize substitute servers on a `guix' commandline? My situation is: I reinstalled a machine because there was some issue with the bootloader when I first installed it, so it had to be booted off a USB drive. <ieure>It's installed and booting, but I'm having a hard time configuring it, because my home configuration configures channels, but my home config depends on my personal channel, which is a dependency cycle. <ieure>I used `guix pull -C channels.scm' and can configure it now, but substitutes are in the system guix config... and if I `guix system reconfigure', it wants to compile a bunch of stuff ex. my personal version of LibreWolf with WASM sandboxing enabled. <ieure>I gave `--substitute-urls="..."' on the system reconfigure commandline, but it refuses to use them because they're not authorized; authorization happens in the system config, so, another dependency cycle. <ieure>I guess I could make bootstrap versions of all the configs to get it to the point where I can do all this, but it'd be much easier if there was a way to tell guix to trust the manually-specified substitute servers. <look>ieure: You can use `guix archive --authorize < key-file.pub` <ieure>look, Because I use declarative config, I don't have the keys handily sitting around in files; and I don't wish to durably mutate the system state, only tell it that it's okay to use these substitutes at this particular moment. <look>ieure: I'm pretty sure the substitute authorizations on acl will get overwritten once you system reconfigure (it might even be at reboot too, I don't remember right now) <luca>In guix what is the appropriate way to remove a package from the repos? Transitive dummy package? Or just remove it at once like a band aid <futurile>luca: there's a way to specify that a package is superseded <luca>Got an example I can take a look like? <futurile>luca: I've never used it, but if you search in gnu/packages there's a bunch with a superseded property <luca>Thanks, will take a look <futurile>hmm might be a deprecated-package function luca <luca>Anyone got tips for a `OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /etc/ssl/certs/ca-certificates.crt` error during the check phase of a python package? Not sure what dependency may provide that (or if that's even the right way to go about this) <Rutherther>luca: no package provides /etc folder, it's not in the chroot at all <nckx>luca: The certificate[ root]s are provided by nss-certs-for-test. <Rutherther>(at least for the build of normal packages, it's possible that for fixed-output it's there, I am not completely sure) <nckx>If you're lucky the $SSL_CERT_{DIR,FILE} search paths will be honoured by your package and you're done. <nckx>The -for-tests variant is there just to allow swift updates to the proper nss-certs package without rebuilding the world. <nckx>luca: What's unclear about (or not addressed by) the manual section on deprecation? <nckx>(If you didn't find it, your manual is out of date.) <luca>i didn't look for deprecation, as I didn't know that's what it was called in guix <orahcio>Hello, why we have difference between packages.guix.gnu.org site and `guix search` command? I can not find texlive-scheme-context on guix seach command <nckx>It's also worded as ‘package removal policy’ but I can see how that gets lost amongst the ‘uninstall’ meaning. Not sure if there's a good solution. <dariqq>does anyone else have problems with sway@1.10 and wlgreet? the login menu does not seem to render properly <nckx>orahcio: I'd say your Guix is severely out of date. <nckx>We have no such difference. <dariqq>The list of custom tweaks to packages and services in my config/home.scm keeps growing <nckx>orahcio: You can check with ‘guix describe’. <orahcio>nckx: maybe is the version of nixos guix package <luca>nckx: regardless, thanks for the manual tip! <nckx>In general, distro-packages guix packages are suitable only as ‘bootstrap’ guixes to run ‘guix pull’. <nckx>You should run that regularly and not rely on your host OS to update it. <nckx>In Guix, packages are not separate from the package manager. So, no guixpkgs here :) <orahcio>but I could did `git pull` I need to do also with root privileges? <nckx>‘guix describe’ should answer the question of whether the guix you are invoking is up-to-date. ‘command -v guix’ will tell you whether you're invoking the *right* guix, which should be $HOME/.config/guix/current/bin/guix. <nckx>Some shells (bash) remember the location of previously invoked binaries in the same session, so don't use ‘which guix’. <nckx>If that's the issue, ‘hash guix’ will make bash forget and search PATH again, or just open a new shell. <Rutherther>also you have to first actually properly source ~/.config/guix/current/etc/profile if you don't do that anywhere now <nckx>I'd hope that NixOS sets that up but good point. <nckx>It must be doing some set-up for the daemon to work(?)… <nckx>Sweet gods, this years makes a decade since I last used NixOS. <Rutherther>nckx: it does try to do that, but it has a bug that evaluates the path of the profile to /guix/current instead of $HOME/.config/guix/current for most people (it uses XDG_CONFIG_HOME variable early when it's not set for most people) <Rutherther>possible solution is to set "environment.sessionVariables.XDG_CONFIG_HOME = "$HOME/.config";" <Rutherther>it's quite a pity. It has been reported, but no one maintains the guix module anymore it seems, so it's not been resolved <futurile><sigh> annoying when you set out to do some dev, and what you land-up doing is debugging your builds <gnucode>nckx: I'm doing a-ok! Are you still busy with guix? <jaft_r>I don't suppose there's, possibly, a gradle-build-system out there…? <ieure>jaft_r, Not that I'm aware of.