IRC channel logs
2024-10-03.log
back to list of logs
<oriansj>is there any reason why there are no sid players in guix? <podiki>we only have or don't have things because someone packaged it (or not) <talos>I believe vlc can play sid files btw, just a FYI. Probably not what you want, but yeah <meaty>How can I set up my emacs so that I get completion and documentation when editing my config? <meaty>I know it is possible via scheme-mode/geiser but I am not sure exactly how <meaty>the guix.el package seems to start a repl, maybe there is a way to hook that up to geiser as an inferior scheme? <elpogo>meaty: try setting geiser-guile-binary to a shell script that contains 'guix repl "$@"' <meaty>elpogo: actually I just found guix-devel-mode <apoorv569>When you add a new feature or field or something to a package or service, you document the new change or whatever, do you always have to the copyright line on the top of the each file you change? or is that for specific people and/or specific cases only? <apoorv569>because I have sent patches before that got merged, but I never added or was asked to add a copyright line on the top of the file. <apteryx>apoorv569: it's up to you, but if you want your copyright to appear, it should be for changes of > 15 lines of added/changed code or similar <apteryx>anything less is likely not copyrightable <apoorv569>apteryx: I see. ATM the changes I'm submitting is not > 15 lines, but in the past I have submitted patches that included > 15 lines, but didn't add any copyright. But I guess I can keep this in mind for future patches. <nckhexen>'Code' needs to be stressed here. How many lines you add or change in the diff is irrelevant, it's how much original work they contain. You could easily submit hundreds of lines of uncopyrightable code. That said, reviewers tend to be quite lenient. <nckhexen>There are certainly bogus 'copyright' lines in Guix, maybe many, but hey, proving that's more work for anyone who wants to steal the code, at relatively little cost to us :o) <apteryx>nckhexen: isn't mot anything typed out 'original work' enough in the copyright sense? <apteryx>ah, original work meaning not copied from other places I reckon <nckhexen>Yeah, 'original work' was my poor attempt at excluding automated changes, or 'collections of facts' like a list of eleventy hundred syscalls, etc. And there's a lot of etc. <nckhexen>People seem to latch on to the 'N lines are copyrightable' meme because... I dunno, programmer brain, like that's how copyright works. <lilyp>"You could easily submit hundreds of lines of uncopyrightable code." – That's the `guix import crate` to `git commit` pipeline :) <apteryx>nckhexen: for it it's just a good rule of thumb to explain why tiny changes shouldn't be adding copyright notices <apteryx>It's mentioned somewhere in the GNU maintainers manual, IIRC <apteryx>info '(maintain) Legally Significant' <apteryx>and I think this manual comes with Autoconf <nckhexen>apteryx: Oh, thanks for that ref, even though I can't find it now (in auto{conf,make}) I will eventually. <apteryx>nckhexen: readlink $(find -L ~/.guix-profile/share/info -name maintain*) -> /gnu/store/rf07x8272y0pl6x5mrzll51kf2jk1a0c-gnu-standards-2020-11-25/share/info/maintain.info.gz <apteryx>refined: guix locate -g 'maintain.*' <olndrxyz>Hello! Does anyone on EXWM get this message when shutting down with loginctl poweroff: ====AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run /gnu/store/...xf86-video-intel.../libexec/xf86-video-intel-backlight-helper as the superuser ? <futurile>do we ever get any insight into GNU's problems with their systems? Are they under attack, or just overloaded? Is it volunteers or do they have paid people? <futurile>feels like the instability has really ramped up in the last six months <civodul>futurile: the Savannah admins emailed guix-sysadmin a couple of weeks ago, stating the machines were being hammered <civodul>(it’s really just about savannah.gnu.org; the rest i have no idea) <civodul>now people on #savannah are usually responsive and open <apteryx>snippet, to expand a "mirrors://..." string (here $7), in case that's useful: (uri->string (car (maybe-expand-mirrors (string->uri $7) %mirrors))) <Lumie>is guix.gnu.org down too? I can't reach gnu.org <lilyp>apteryx: why not (map uri->string …) instead? <apteryx>futurile: there's a mastodon feed somewhere where they post problems they experience <apteryx>yesterday there was a network outage outside of their control <apteryx>lilyp: ah, because I had a single item, but you're right that's more general <apteryx>first time I see this one: guix build: error: getting attributes of path `/gnu/store/7qwncqckfsjm3lr5y0qq604bknznw3sm-glib-2.80.5': No such file or directory <lilyp>did a previous build leave a corrupt store? <apteryx>that happens attempting to build enchant on the gnome-team branch <apteryx>I did 'guix gc -D that-non-existent-store-dir' and now I'm back in business <lilyp>I got `/gnu/store/1par9fx6bh1jlzwjj8i2k522klk66726-enchant-2.6.9` <apteryx>I was using --rounds=2 with with -K and -c32 <lilyp>If you have the resources, can you build #73525 for me? <lilyp>it looks like python-packaging-bootstrap can't be cross-built and that's causing evaluations to turn up empty <lilyp>ahh, upstream is already aware <apteryx>no single python package can be cross-built. that's entirely guix's fault <apteryx>I have a change enabling cross-built python packages, it's on our tracker <apteryx>sadly it's tangled (built on top of) another change, it'd need to be untangled. <civodul>lilyp: it could be that one of the jobs defined in (gnu ci) attempts to cross-build some Python thing that it should not <lilyp>on gnome-team, said python package is currently an input to GLib (sadly) <apteryx>(python packages don't need to be cross-built at all, their byte code do not contain platform specific information, unlike Guile's bytecode) <apteryx>the challenge is where C is also involved <apteryx>the tangled matter was making native-inputs remain as native-inputs in the build code, instead of being lumped together with inputs in the case of a native build (no cross-compilation) <lilyp>I also see some stuff with procedure-name <lilyp>But yeah, the lumping has led to more workarounds than actual solutions imho <apteryx>yeah the reason this change need more work is because the procedure-name is a hack to special case this new build system <apteryx>it was argued all build systems should be adjusted the same, but that's a big ordeal <apteryx>I think the new cross-compilation should be split from that tangled change and reviewed separately <apteryx>lilyp: the lumping of native-inputs and inputs is essentially a simplification (in other words, an optimization); which I suggest should be dropped to retain that useful information <lilyp>yeah, it leads to odd behaviour in native builds too – like build inputs being retained in search paths <civodul>oh indeed, hadn’t opened it in a browser :-) <civodul>would be nice to set up an official mirror or two <nutcase>Dear respected guixers. I had to move to another laptop and realized that it could have been very useful to manage two more things in my operating-system's config: 1. CUPS printer configurations and ppds (I need to reconfigure the printers I use) and 2. Network Connections managed by Network-Manager (wifis, (wireguard-)vpns, broadband). <nutcase>Are there guix ways for that? For cups, it could be sufficient to create a /etc/cups/printers.conf file, but not sure <civodul>nutcase: hi! i don’t think it’s possible right now, but it would be nice to support it <nutcase>civodul: thank you. I just wanted to make sure, if I should've checked something else than cups-configuration, before thinking about how to invent a wheel again. My first naive approach would be a etc-service-type. <civodul>nutcase: i guess cups-configuration could have an optional field where one could specify printers, something like that <civodul>and by default it’d remain as it is now: imperative/stateful printer management <nutcase>civodul: yes, that would be more integrated. The issue (you already noticed) is, that cups modifies printers.conf. Not sure about the effects, but upon system reconfigure the cups managed attributes (printers and configuration settings) will be removed again. This would reset intermediate states <civodul>nutcase: cups modifies it only if you add/remove/modify the list of printers, no? <nutcase>civodul: it may modify printers.conf for other reasons. E.g. CUPS may retrieve toner status from a printer and save that information into printers.conf. Losing that information is probably not an issue. I'm not sure, where CUPS counts printed pages to care for quota etc. <nutcase>I'm also not an expert, just a lay user <meaty>could someone with more rust expertise help me diagnose a compilation error when building rust-fast-image-resize-4 <futurile>meaty: probably not - but if you put a link to a paste I can look at it <meaty>it mentions a missing 'testing' module but I'm pretty sure it's not the 'testing' crate cos that one's description says its for the 'swc' project, and it wasn't imported automatically <futurile>meaty: actually the existing definition of the package already has testing off because there's an unresolved crate <futurile>meaty: so looks like the developer has a testing crate which guix won't be able to find - therefore you can set tests? to #f just like the existing package does <civodul>nutcase: if it modifies it routinely, then it’s trickier <atweedie>one day I hope to grok all you're talking about here :) <apteryx>apoorv569: I've just posted some comments <apoorv569>apteryx: I am not using GNOME or any other DE I am using standalone WM DWM. So I mostly use terminal to enable disable wireguard. <apoorv569>Also I'm not sure what is expected in v3? should I set the default to #t instead? so other people don't face any issues. <apoorv569>Sorry I am not used the patch and email workflow, I have mostly used the PR on github/gitlab kind of thing. <apteryx>you could use nmcli for NetworkManager from the command line; for one time setup you can use 'sudo -E nm-connection-editor'. <apteryx>apoorv569: in the v3, yes, I think just the default value hasn't been covered yet <apteryx>lilyp: stumbling on reproducibility failures along the way to build webkitgtk <apteryx>just documenting and skipping a fix for now <lilyp>out of scope for gnome-team but good to see it found and documented <lilyp>tex reproducibility is historically not that great :) <apteryx>if it builds and tests fine, OK with me pushing it to the gnome-team branch? <apteryx>(I'll also reply + close the ticket) <apteryx>yeah, the 4 commits of that small series <lilyp>sure, you're in a better position to make that call than me :) <apteryx>a comment says: ;;; An older variant kept to build libsoup-minimal-2. <apteryx>can we get rid of this vala@0.52.0 variant? <lilyp>apteryx: interesting find – though vala needs bootstrapping too <sepeth>lilyp: what does 'drop --tune' mean? <lilyp>sepeth: --tune does not work for your cpu, don't use it or specify one that works <apteryx>hm, vala 0.56.17 is also not reproducible... <apteryx>lilyp: would that help with reproducibility? <lilyp>I'm not sure, I haven't tested for reproducibility yet. <lilyp>I'd hazard a guess that timestamps are embedded <futurile>civodul: well I guess you need nckx or mbakke to tell you why it says it's broken <civodul>futurile: yeah, i’ll check with them <futurile>civodul: it says it was broken in Dec in the README, but last pull was in Jan so maybe they managed to fix it <lilyp>if you have a patch or pointer for vala reproducibility, that would be in the scope of gnome-team :) <apteryx>just a bunch of diffoscope diffs though, I haven't researched for a fix <lilyp>hmm, worth looking into the doclets thing, since it's the only one that appers broken from the diff <apteryx>maybe it doesn't honor SOURCE_DATE_EPOCH or something <lilyp>if they're timestamps, they don't make sense tho <lilyp>hmm, what does objdump say is at that address? <apteryx>sorry, my attention span is like 2 minutes at the moment. I should get some sleep ;-) <apteryx>could not be reproduced on a 2nd run <apteryx>logged it to bug-guix at least. moving on <f1refly>what's my best shot at ripping a bunch of episodes from dvd on guix? <f1refly>my wife handed me a box of gilmore girls and would like it digitized so she can watch it on her tablet and I'm honestly not sure how to approach that :/ <apoorv569>apteryx: Yes, I could use nmcli but those are too many steps then doing herd start/stop wireguard-wg0. Also the wireguard-service-type already provides a shepherd service so.. <apteryx>I'm not against having auto-start? with it being #t by default <elpogo>f1refly: you can install vlc on the tablet, and share your ripped files over ftp/sftp <fireking04>Hi everyone, I am trying to download a tarball during a phase of a package. This tarball isn't included in the source tarball. What's the correct way of doing this? Adding a phase after 'install and performing curl could not resolve DNS for some reason. <f1refly>elpogo: yes, but I'd neet to rip them first <Rutherther>hmm, I am wondering why is there the tests? argument when we could just remove the check phase? Is it expected check phase could do something even with tests? disabled / something else can change with tests? enabled than the check phase? <Rutherther>nutcase: btw from the list you asked for managing between systems, wireguard has a service, so that one is already possible. Seems like no one mentioned it yet. <ieure>Rutherther, Using #:tests? is much more convenient than mucking around with build phases, especially for packages that don't need to touch them otherwise. <mirai_>Rutherther: usually packages are built with tests enabled <Rutherther>mirai_ yes, I meant that if we wanted to disable tests we could remove check phase <Rutherther>ieure manually changing it can be inconvenient, but I would expect there to be a simple function for that. <Rutherther>It being a separate argument is just begging for some packages to accidentally not honor it <jaft_r>Is there a way to tell Guix home where to put backups? Placing them directly in my home directory is sort of cluttering it up. Even just making them hidden directories, instead, would help. <dariqq>what do i do when i get a "could not find proper ls" error when tramping to a guix machine? <wizard>dariqq: (add-to-list 'tramp-remote-path 'tramp-own-remote-path)) <dariqq>wizard: thanks, that is working. <nutcase>Rutherther: thanks, that could be part of a solution, which also does not require to store credentials in the operating-system definition. However, a more general solution for all NetworkManager configured connections would be more useful. Setting up a wireguard connection is one of easier tasks, because you can use /import a config file that is often provided by your peer. At least that's the case for my two wireguard peers I use. <ieure>Rutherther, The #:tests? flag is part of the build-system, packages have no leverage to "honor" it or not. I guess they could run tests in `make all' or w/e, but that's a You(r Package) Problem. <Rutherther>ieure of course they have leverage to honor it. If you make a custom check phase you have to make sure you use it. <ieure>Rutherther, Again this is a You(r Package) Problem. Or if you prefer, a "Doctor Guix, it hurts when I do this" problem. <ieure>Why would you want "a custom check phase?" It's built in. Makes no sense. Don't do that. <Rutherther>I agree its a package problem given the current bud system structure. But that is what I am asking about, about the build system structure <Rutherther>Some packages in guix channel use custom check phase and some of the packages have forgotten to check for tests? And test unconditionally <ieure>And I answered your question: The #:tests? flag exists because it works universally and is more convenient than mucking around with build phases. <ieure>Rutherther, Sounds like cases where patches to fix that would be welcomed; perhaps the package definitions predate the #:tests? facility. <Rutherther>ieure: yes, one was reported by someone here recently and as far as I know it's fixed already <futurile>Rutherther: yeah, I guess you're supposed to do 'when tests?' blah blah - I assume lots of custom test phases don't do this <Rutherther>futurile: yeah, so that led to me wondering why this is the case, I wouldn't expect a slight convenience to be of more weight than error-prone behavior. I expected more reasoning behind it that I was missing <futurile>Rutherther: well I believe that option to provide --with-tests (or whatever the switch is) was only added a couple of years ago. When the first 'customising builds' stuff was added. I don't think it's used that much, so I guess that's why most people don't test for it. <Rutherther>futurile: it is --without-tests, and it would be equally possible to just make --without-tests remove the 'check phase rather than changing tests? to #f <futurile>Rutherther: it's one of the transforms - uh guix build --help-transform has it <futurile>Rutherther: yep I guess so - I've literally never used that option. I didn't even cover it in a post I did on transforms. <futurile>Rutherther: it might even do that to be honest, I was just surmising that it's why some of them have that 'when tests' clause heh :-) <futurile>Rutherther: ah interesting, so that clause is useless. Hmm I need to look at a few examples to see why it's there. <Rutherther>futurile: that is the reason for the clause, that this argument is used <freakingpenguin>I've been having trouble building elogind via qemu riscv64 builds due to a failing test, but a build must have gone through at some point because it's in the store now. <omar_b>I am trying to add the module (gnu packages commencement) to be able to use gcc-toolchain. But I am getting a lot of errors that are unrelated and that I don't understand. <omar_b>Any idea of what's the right way to be able to use the gcc-toolchain in the lisp.scm file? <freakingpenguin>futurile: I wish haha, but I don't think Cuirass is doing RISC-V builds yet. <futurile>freakingpenguin: oh what will riscv shows as an architecture - I saw riscv64-linux and assumed that was RISC-V <freakingpenguin>I know the output hash hasn't changed between the successful build and what I'm doing now. It's a bit spooky because I didn't think I touched RISC-V for a few months, yet there's the build. <futurile>omar_b: you couldn't find any other examples of someone doing it? Nothing on the mailing list? <omar_b>futurile: I see the module used in other places like /gnu/tests/install but it's not user for gcc-toolchain <vagrantc>freakingpenguin: hopefully not a time-bomb test suite failure or something ... e.g. it built N months ago but will systematically fail to build today due to an expired certificate or some such <vagrantc>there is a service to set up a virtual build machine and set the clock on it for timebomb workarounds <abbe>is there anyway to have discoverable substitute servers using dns-sd, not the mDNS ? <abbe>I have a few VMs not part of same LAN, so can't be mDNSed, yet I wish to be able to have them pull from each other <abbe>and i can keep the list updated in a SRV records. <futurile>omar_b: are you actually compiling Janet - you seem to be using the copy build-system. Your best option is to work with Jgart. He's got a lot of experience, and from the thread he's offering to help you. <freakingpenguin>vagrantc: I don't think so, it's something to do with mount point IDs. <omar_b>futurile: Yes, Suhail and Jgart are the one helping me and they had some comments on the patch. I now got it to work by copying how gcc-toolchain is used in the packages/engineering.scm <futurile>omar_b: but why did you start there, why didn't you use the gnu build-system, is it not using standard configure/make to compile? <futurile>omar_b: only that gnu build-system has gcc in it - so it seems like you wouldn't have to fight so much <omar_b>futurile: No, it's not using the standard configure/make/install flow. It is running a custom janet script. I'm not using gcc for compiling but rather for replacing hardcoded "gcc" paths in the jpm source code. I originally started with the trivial-build-system but then Suhail suggested using the copy-build-system instead. <omar_b>futurile: also I need gcc-toolchain and not just gcc because I have to also replace the absolute path for g++ <vagrantc>trivial-build-system should be renamed tricky-build-system <futurile>omar_b: ah interesting - wow - looks supper hard. <futurile>uh super hard even - that's my stomach typing <omar_b>I've been working on this patch for over a month now <omar_b>And I'm very new to guix so I really need help <Rutherther>omar_b: "gcc" contains "g++" as well. The difference from gcc-toolchain is that the toolchain has also the standard libraries for c (glibc) and c++ (libstsc++) <omar_b>Rutherther: I didn't know that will try it now. Thanks <Rutherther>btw could you share the errors you got when including gcc-toolchain from commencement? <omar_b> ~/gnu/guix [env]$ ./pre-inst-env guix build jpm <omar_b>hint: Did you forget a `use-modules' form? <omar_b>error: googletest: unbound variable <omar_b>hint: Did you forget a `use-modules' form? <omar_b>hint: Did you forget a `use-modules' form? <omar_b>Rutherther: sorry for the long message. The only way I found a work around for was in the packages/engineering.scm where the module is Lazily loaded in some package's inputs <futurile>omar_b: I don't think it sent them - paste them into here - https://paste.debian.net/ and give Rutherther the error message. You can't paste long error messages into IRC. <futurile>omar_b: sorry I mean give Rutherther the link it gives you <Rutherther>omar_b: right, so a circular dependency of: commencement -> lisp -> maths -> compression -> commencement (prepending gnu packages to each of those) <Rutherther>you would need to ensure to import commencement with resolve-module to load id lazily <omar_b>Rutherther: yes, this is what I did for it to work. <omar_b>I'm now having another issue. I need git in the propagated-input but now when I run a pure guix shell and run the command "jpm install -l sh" which is using git it is getting an error: <omar_b>error: command failed with non-zero exit code 128 <omar_b>I think that now it's more of a git configuration issue maybe? <omar_b>I've tried git config --unset https.proxy but that did not work <abbe>omar_b: nslookup git.savannah.gnu.org <abbe>or: getent hosts git.savannah.gnu.org <omar_b>abbe: this is the output of nslookup: <Rutherther>don't paste multiple lines like that or you are risking getting banned <ieure>Suggest using dig over nslookup, personally. <Rutherther>and any git clone with domain is giving you an error? <abbe>omar_b: then maybe something intermittent, try again <omar_b>Rutherther: no this is from the propagated-input git only in a pure guix shell. <Rutherther>omar_b: huh? propagated-input in a guix shell? there are no propagated-inputs in guix shell <Rutherther>are you building a package/derivation? and if so, you have to make sure to fetch everything in a fixed output derivation, it's not possible to fetch something from internet inside of normal derivation <omar_b>So, this is not my system git this is the git from the package inputs when I run "./pre-inst-env guix shell jpm --pure" <Rutherther>okay, then what I said applies. Make a fixed output derivation with the needed sources / vendored dependencies if that's a thing with Janet, and make sure your derivation will use those sources, and not try to access the internet <Rutherther>omar_b: no, it's not propagated-inputs. It is the sandbox that disallows internet when building derivations <omar_b>Rutherther: can you have a look at the patch and let me know if I'm missing something <Rutherther>omar_b: I don't know what janet commands are doing, so I can't say what accesses internet and what not. But you patching curl strongly suggests something will use the internet and you have to get rid of that. <omar_b>So, the issue is with the "--pure" flag? or what do you mean by sandboxing? <futurile>omar_b: the build servers in Guix don't have access to the Internet. So a 'fixed derivation' means preparing the source before hand. You have to grab everything - patch it - do anything that is needed to get 'pristine source'. Then the source is passed into the build command <Rutherther>omar_b: no. There is no relation to shell. The pure flag doesn't have anything to do with build of the derivation. Every package is built inside of a sandbox. <omar_b>futurile: can you elaborate more. can you give an example of what I need to do? <omar_b>I'm substituting the source code files with the absolute paths to the needed packages. <futurile>omar_b: sorry - it's beyond me - it's super advanced - the most I've done is download the source and altered something with a substitute <Rutherther>omar_b: an example is that we don't use git clone inside of a build phase, but instead specify source with git-fetch that will make a fixed-output derivation. So whatever is currently fetching via git, you need to instead obtain it yourself with git-fetch, and tell the tool to use it, without it fetching it automatically. <omar_b>I think there is a mis understanding here. The issue is not with the building of the package. The package now builds fine. My issue is when running the package in a pure shell <omar_b>nothing is fetched inside of the build phase. <omar_b>The issue is when running the "jpm install -l sh" command which is under the hood using the git package that I supplied as an input during the package build. <Rutherther>okay, my mistake, so when you do git clone yourself in the shell, what happens? <omar_b>I tried with different repos. it's not about a specific repo. Besides, when I run this outside of a pure shell, everything works fine. <Rutherther>does running in "guix shell --pure git" produce the same result for you? <meaty>sometimes I wish guix had a command to separate end-user software from all the texlive/rust/lisp/r/etc. libraries <omar_b>Rutherther: I understood where the issue is. I needed to run the shell with the --network option as well. so instead of initially running guix shell -D guix -CPW, I needed to add N for network so it's guix shell -D guix -CPWN <omar_b>Thanks everyone who tried to help. <ieure>omar_b, Problem would have been solved immediately if you'd pasted the actual command you were using, or mentioned you were running inside a container. <ieure>Just as a FYI if you need help again -- give us the info we need to help you. :)