IRC channel logs
2023-08-25.log
back to list of logs
<Guest96>I see. That gives: Wrong type to apply: #:phases <Guest96>oh wait, that's because I got rid of the quote. <nikolar>so shepherd seems to get stuck sometimes <nikolar>and it was making progress until a point <nikolar>i tried loggin into another tty which immedietely exited for some reason <nikolar>but it made the reconfigure progress a bit <radio>I am dealing with some problems with the fish shell in guix. The first one is that files on the /gnu/store/<hash-here>-fish-foreign-env/share/fish/functions aren't being sourced by fish by default (IDK if it should, tho, in either case, it's not working) and was asking myselt the proper way to make fenv always avaiable within fish in a declarative way (I'm using guix home) <radio>It's also possibly related to fish: When I open emacs outside a guix shell, I'm currently unable to execute any command, even M-x gives me the same error message: "Symbol value as variable is void: /bin/sh" <radio>Even if I run emacs with --no-init-file <radio>Anyone can help me with any of these? <Gooberpatrol66>is there a way to view the local guix manual in the browser so the formatting is prettier than info pages but it's more up to date than the website? <mirai>the website has a “devel” version <Guest96>My package is using pyproject-build-system. 'checks defaults to running "pytest". I want to add flags to pytest so I can exclude certain tests (which look for a gpu) <Guest96>Is there some place other than guix/build-systems* that I should be looking? <Guest96>Alright, I am able to access files during a build with #$(origin (uri "http://...")...), but inexplicably for exactly one instance, I am unable to access that file within the build <Guest96>The file is in my /gnu/store already, but when I guix shell -C ... in the build directory, I am unable to see that file in /gnu/store <Guest96>I'm doing something like this for arguments: (arguments (list #:phases #~(modify-phases %standard-phases (add-before 'check 'pre-check (lambda _ (symlink #$(origin (uri "https://...")...) "./dataset.zip") <Guest96>What I can't understand is why it would break *inconsistently*. <iyzsong>Guest96: '-D' use 'package-development-inputs' to get inputs for a package, look like it only include inputs/native-inputs but not gexp embeded ones? <Guest96>iyzsong: I think that is right. I think the "inconsistent" one is actually breaking in an unrelated manner <wone>What's the fastest way from a system configured with the default %desktop-services to get vnc on there so I can remote in? <wone>(I'm on windows right now, forgive me) <Guest96>wone: look in "VNC Services" in the guix manual <wone>There really is everything in there. <Guest96>And when it's not, start grep'ing your clone of the guix git repository <wone>My main curiosity is now one of specifics: If I use vnc or rdp, will applications that use vulkan be using my local (guix) gpu? <podiki>not sure how vulkan works or not like that; i assume wherever it is running on needs vulkan, it being shown on a remote host is just up to X i would think <wone>Ah, okay. I'll run and let you know if anything explodes. <podiki>so whatever is actually running the application needs vulkan, the displaying on a remote screen is a different <podiki>just my guess though, typically to use different hardware it is something more complicated, like vfio on vm <podiki>(direct hardware access from a client to host) <wone>Will restarting xorg-server be enough after the reconfig to start vnc? Let's find out <wone>Hmm. "No WSI support on physical device" <wone>I'll investigate that later: Until then, cable moving time. <dcunit3d>hey i'm getting an error about license:arphic-1999 for quite a few guix commands on my system. i've checked the code used for `guix pull` in both system/user current profiles, but it has that declared in there. <dcunit3d>thanks itd, i'll try it and see. i was considering guix time-machine, but i haven't quite used it yet. <dcunit3d>i haven't been using my laptop as much lately, so i need to edit my system to update. <itd>The discussion did sound like time-machine also shows this behavior, so I didn't try that. <dcunit3d>yeh, i tried rolling back either way. i don't think --roll-back is an option on guix pull anymore <dcunit3d>i'm trying `guix pull --switch-generation=nnn` for two generations back, then basically guix pull again. <dcunit3d>it proceeded past the other point where it was stuck, so i think i'll be alright. <dcunit3d>ok that seems to have worked. i'm trying to update profiles, which seems to work as well. thanks itd <nckx>ACTION puts out coffee & tea. <jpoiret>was it a mistake to do cycle analysis on the dependency graph of guix modules? probably <jpoiret>now i'm pretty certain it's impossible to disentangle that mess <jpoiret>loading (gnu packages guile) loads about 361 modules <jpoiret>that contributes to the steep guix pull times, because guix pull uses the guile package from the new guix which is not yet compiled <janneke>ACTION is trying to collect some gc stats for guix pull as civodul suggested -- but without any useful results yet <janneke>jpoiret: why would disentangling be impossible, "just" because of the sheer amount of work or do you see an inherent impossibility? <janneke>ACTION has attempted logging of 6 series of `make as-derivation' or `guix pull' actions on the hurd, and *all* of them failed today, resulting in a childhurd hang <janneke>most out of memory, one or two with a bus error <janneke>ACTION was pretty confident that one of my last split patches really fixed guix pull on the hurd, but is getting more and more confused by the experiment results <janneke>it could be the not-hiding of compilation warnings and printing of gc-stats that break things -- observer effect <janneke>ah, a spontaneous reboot -- that's new <andreas-e>janneke: Recently I learnt about the observer effect (in the Guix context, a package test failure) when doing floating point in C. Just printing a double variable can change its value, because it may be moved from a register to main memory, and since they have different size, may be round in the process. <andreas-e>A Heisenbug, nice term. It could be considered a compiler bug, because it is not compatible with a programming language semantics (assuming C has one). But it is difficult to fix, since one also wants to be efficient and use CPU registers with their available instructions :) <nikolar>Well the value depends on if it was observed or not, so definitely an appropriate term :) <janneke>jpoiret: iwbn if you could use a graph analysis tool to make suggestions where/how to break the dependency chain <jpoiret>that's why I was trying to do that. But i'm no expert, and also it seems that there are a *ton* of cycles <jpoiret>not just one that causes all of the others <jpoiret>texinfo is one big source from what I can see <janneke>i found the texinfo to be quite "expensive" while bootstrapping for the hurd <jpoiret>I'll add a commit to add graphml output to guix graph, with that and the "module" graph type you can export that and use it in networkx (which I've just found out about) <janneke>almost to the point where i was thinking about creating bootstrap/build versions of some packages without doc <janneke>dunno, maybe something like that could help <jpoiret>I've also thought about having a seperated bootstrap directory <jpoiret>and we could ensure that nothing in the bootstrap directory uses modules from the general (gnu packages ...) namespace <jpoiret>otherwise it's very hard to keep track of when cycles are created <ngz>Could anyone having monolithic installed tell me what is linked to "bin/splitindex"? A Perl script (.pl) or a a TeXLua one (.tlu)? <ngz>monolithic TeX Live (`texlive' package) I mean <mirai>jpoiret: what's this “cycle analysis” on the dep graph? <jpoiret>well, just finding dependency cycles <jpoiret>dependency cycles force all files in the cycle to be compiled together iirc <mirai>is this done by eyeball or is there some automation for this? <jpoiret>i added GraphML output to `guix graph` then just throw it in networkx <jpoiret>the graphml output will be pushed soon <jpoiret>`-t module` gives you the module graph <mirai>What's the purpose of the `upstream-name' within the properties of a package? <mirai>is “properties” exclusively used by updaters or is it free for other purposes as well? <nckx>Any sane usage is acceptable, as long as it doesn't become a key-value dumping ground. <nckx>What do you have in mind? <nckx>mirai: There's also cpe-name and lint-hidden-cves for the linter, for example. <mirai>I was thinking the following two uses: a) specify that a package has a system test (and should also execute this, somehow, perhaps by means of an additional check phase) <nckx>I like the idea, but wonder if it would be possible to scan the 'inputs' of the system tests instead. <nckx>Automation > manually curated lists. <mirai>in essence, a XML catalog helper within guix search (or perhaps it can be made even more useful by providing something like (inputs (list … (catalog-resolution #:publicId "-//OASIS//DTD DocBook XML V4.2//EN"))) <mirai>automatically returns docbook-xml-4.2 package <mirai>since unless you happen to know that <package with perhaps unrelated name> is the one that provides the URI/SystemId/publicId resources <nckx>The fact that changing 'inert' properties in a package would then change many derivations might be a (design, not technical) issue. <nckx>Like, you could write a package today that looks up an input by 'upstream-name', but it isn't actually *done*. <mirai> /gnu/store/74rb4yrph1yf6whfp7vz9xcyda8jml5i-libxft-2.3.4/include/X11/Xft/Xft.h:39:10: fatal error: ft2build.h: No such file or directory <mirai>even though freetype is a propagated input for libxft? <mirai>its occurring within a package build <mirai>see if you can reproduce the libxft x freetype failure <mirai>I've tried adding it to native-inputs but didn't change much? <mirai>barring some silly error like not saving the change before a ./pre-inst build <jpoiret>cause I don't really see how the proper include path could be found without pkg-config mirai <aarcov>What I don't know, is if I should add it as a new package file (sirikali.scm) or if it should be added to another multipackage file? <aarcov>And, if it goes in as a new package file, do I need to define a sirikali.go file as well (and what is the purpose of these <package>.go files?)? <mirai>jpoiret: adding pkg-config didn't help <jpoiret>just adding it won't be enough, it has to be used at some point by the build process <mirai>jpoiret: hmmm… it complains about it if you remove it <jpoiret>mirai: xfig's build system seems... suboptimal for this <jpoiret>freetype's pkg-config specifies an include path that is not just /include, but without pkg-config xfig can't possibly know about this <jpoiret>huh, xfig's configure.ac mentions they explicitely don't use pkg-config because it doesn't work the way they expect :( <jpoiret>you'll probably need to patch pkg-config usage in <ulfvonbe`>could also maybe just bypass the build system entirely and manually use setenv to add the missing subdirectories <Guest96>The module I'm packaging tries to download a file during checks unless it is found in "~/.cache/...". I take it the only options are through "patches" and through disabling checks. <Guest96>Is one of those preferred, or is there a third option? <ulfvonbe`>and copy said file from the store to there before the check phase <Guest96>Now thats the clever hacky hack I like to see!! <Guest96>Oh wow, that's a large file. Getting checks to work has involved a lot of downloading models files which don't end up in the final build. Is there a point at which it is "not worth it"? I don't know if these inline origin references will end up in the substitute server or not. <mirai>what's the meaning of “cycle detected in the references of `/gnu/store/7r0k6d9536qkx6wi1knp9rvhrdi0l6aw-xfig-3.2.8b' …” <ulfvonbe`>I believe the only cycles allowed in the reference graph, ever, are zero-length self-cycles, as in "output OUT of package FOO refers to output OUT of package FOO" <ulfvonbe`>so, for example, if OUT --> DOC and DOC --> OUT, it will whine about it <ulfvonbe`>this makes sense because one of the main reasons for split outputs is the ability to download / install only one of the outputs <ulfvonbe`>but if there's a cycle, you're always going to have to get all of them together - they're effectively just one output <mirai>I can't spot exactly what's wrong with <mirai>(arguments (list #:configure-flags #~(list (string-append "--docdir=" #$output:doc)))) <ulfvonbe`>(also doing nontrivial cycle checking that allows that particular kind of cycle would complicate things) <ulfvonbe`>well, it sounds like for some reason the "out" output is maintaining a reference to doc <ulfvonbe`>and doc is maintaining a reference to out. Not sure which one of those is considered "wrong". <mwette>Does guix or guix system build for risc-v? <vagrantc>mwette: efraim or ekaitz might have the best idea of riscv64 status ... if i recall correctly <vagrantc>has been a while since i poked at it ... but it was getting there <roptat>mwette, the manual says: This platform is available as a "technology preview" <ekaitz>mwette: you can build for riscv, for sure `guix build --system=riscv64-linux` <mwette>Thanks. I expect to get a mini riscv64 next month. It comes w/ debian. I will give it a spin. <mirai>ulfvonbe`: huh, nevermind about arguments, simply this `(outputs '("out" "doc"))' will cause it to complain about cycle blablabla <ulfvonbe`>if it's gnu-build-system, that's to be expected, it automatically sets --docdir if there's a "doc" output <nikolar>tmux is complaining about invalid LC_ALL, LC_CTYPE, LANG <vagrantc>mwette: the pre-packaged guix on debian was building successfully ... although it is in the middle of transition and does not appear to be currently working <vagrantc>mwette: riscv64 is currently in the middle of getting re-bootstrapped in debian as it transitions to an official architecture ... <nikolar>can anyone help with the locale stuff= <mwette>vagrantc: thanks -- any estimate on how long that will take? <roptat>mirai, you could grep for the doc output's hash in the out output, to see were the reference is <vagrantc>mwette: it has been slower than i had hoped ... i think it is blocked on guile <mwette>vagrantc: Then I could start w/ guile, I guess. <vagrantc>mwette: appears to just be waiting to build ... <nikolar> can someone tell me why tmux is complaining about invalid LC_ALL, LC_CTYPE or LANG <mirai>roptat: right, I see some references in the manpages <roptat>shouldn't they go to the doc output too? <mirai>iiuc doc output is for things like share/doc/<html/other bulky stuff> <mirai>manpages usually aren't moved to doc except in some circumstances (curl?) <roptat>ah that would make sense, yes. Can you easily remove that reference? If not, I'd say it's a circumstance :) <mirai>roptat: well, neither moving (via phase) or using --mandir worked (still complains about cycle) <mirai>though grepping the #$output for #$output-doc shows that it is clean <ekaitz>mwette: a friend just let me log in a visionfive2 and I installed guix as a package manager there <mirai>ah, nvm, it wasn't highlighted <mirai>grep: /gnu/store/ydv2ah0idcvv7cz0208k88xbb0zf3mk8-xfig-3.2.8b/bin/xfig: binary file matches <ekaitz>mwette: the instalation worked but I didn't try anything else yet <nikolar>ekaitz: what even is the state of guix on non x86 <ekaitz>nikolar: it works in aarch64, riscv64 and some others afaik <Guest96>nikolar, are you using guix on a foriegn distro? <roptat>mirai, it might have logged build flags, you could try and open it with a text editor and see what the string looks like <nikolar>Guest96: no, it's a guix system in a vm <Guest96>nikolar: are you using %desktop-services, or other? <roptat>mirai, you should find a way to patch that... <nikolar>Guest96: i only have %base-services with ssh, dhcp, gpm and ntp <nikolar>the default by the installer basically <Guest96>I've had that problem on foriegn distro. Try setting GUIX_LOCPATH=/path/to/profile/lib/locale, where /path/to/profile/ is a profile with glibc-locales installed <nikolar>h apparently i don't have glibc-locales <ulfvonbe`>if xfig has documentation links built in to the program itself, maybe it should just be one output... how big is the doc output? <Guest96>You could probably do something sneaky like "export GUIX_LOCPATH=$(guix build glibc-locales)/lib/locale", but probably it would be fixed by adding glibc-locales to the packages list in your guix system config <nikolar>i am kind of on a shitty wifi at the moment so i'll just use the hack until i can reconfigure :) <nikolar>also glibc-locales should probably be added to the installer <nikolar>seems to me that no gui case is a bit less tested <Guest96>I think the idea is that %base-services should be very (obscenely?) minimal. <Guest96>To be fair, this problem IS mentioned in the manual, "2.6 Application Setup" <nikolar>well guess i should read through the whole thing <Guest96>looking at it now, it does seem a little opaque. That section is for installing the package manager on a foreign distro, and your situation is a genuine guix system install. In general, if you want things to "just work", you should use %desktop-services over %base-services. <Guest96>Though, if you are struggling to open tmux, then you made it pretty far, so maybe you are fine <nikolar>wonder what %desktop-services have over %base-services <Guest96>* work being packaging ultralytics * <nikolar> ;; Since GDM depends on Rust (gdm -> gnome-shell -> gjs -> mozjs -> rust) <nikolar> ;; and Rust is currently unavailable on non-x86_64 platforms, default to <nikolar>ulfvonbe`: how do you search for that <ulfvonbe`>well, the way I did it was by having a bajillion packages installed and then running readlink -f $(which clear) <ulfvonbe`>the "proper" way has something to do with 'guix locate' IIRC <nikolar>but that only works if you have it installed already <ulfvonbe`>the root of the problem is that the only way to know which files a package provides is to build it, and building every package in guix is absolutely beyond the capability of most people <ulfvonbe`>it would pretty much have to be the substitute servers providing that kind of database <ulfvonbe`>I think there were discussions along those lines, but I didn't follow them. For all I know, it may already be done <aarcov>Does anyone know how to tell guix to build a cmake project where the source is in a subfolder in a git repo? aka, to build from within a `build` folder, I use `cmake ../src` instead of `cmake ..` <aarcov>(this is for the cmake-build-system in a package definition) <mwette>ekaitz: thanks -- I ordered a VisionFive2 starter boxv <Guest96>aarcov: iirc, cmake-build-system defaults to having build and src parallel to eachother <Guest96>so I think it already does what you want, no? <aarcov>hmmm, it seem to be giving me issues when I try to create a package file <aarcov>I've been able to build other projects where the source isn't nested inside of a 'src/' folder <mirai>aarcov: I think you need #:out-of-source or a simple chdir in a phase before 'configure <aarcov>it is throughing a warning about ignoring extra path '../source', so I guess maybe it is checking for that instead of '../src' <aarcov>would #:out-of-source usage look something like #:out-of-source src <aarcov>skimming through maths.scm makes it looks a bit awkward to rename the srcdir? I ultimately went the route of using chdir, and that worked <Groumf>Hi, how would you go about testing a package definition you just wrote? <Groumf>I don't really want to install it in my system <Groumf>ha yeah silly me, I can just make a drv <efraim>vagrantc, mwette: there's a system definition for the hifive unmatched which I'm running on my machine. I have a visionfive and visionfive2 but no image for either yet <Guest96>I have a module with checks that succeed on everything BUT the tests related to exporting. The exporting tests utilize several backends, each of which is orders of magnitude larger/more complex than the module itself. The module is still very useful without those export backends (I personally don't use any of them). <Guest96>Is it ok to package the module without the backends for now? If so, should I disable tests, or try to patch the tests to exclude testing those backends? <Guest96>Alright, I know I've seen some instance where the source code for a package needed to be modified for guix. Where can I find documentation on how to do this? <Groumf>I am not sure if there is a specific doc for that, but maybe we can just have a look. <Guest96>Oh wait, are "patches" just generic g-expressions? <Guest96>no, I see guix/gnu/packages/patches/ has a lot of files with a peculiar syntax <nikolar>can someone tell me why shepherd would hang <nikolar>because it's not starting all of the services and it doesn't respond to herd status for example <Guest96>nikolar, you need to invoke as root. Not sure if that is your problem <roptat>there's a bug in the Shepherd that makes it hang as soon as your date jumps to the future <Guest96>Groumf, I see the def for python-pillow uses (origin ... (patches (search-patches ...))), but there are no docs on "search-patches" in the guix manual <roptat>well, the bug is in guile-fibers actually <nikolar>it's jumping into the future because of the ntp presumably <roptat>depends how fast your computer is and how much it jumped to the future <Guest96>nikolar, ropat, if the bug is newish, you could create the image after guix pull'ing an old (pre-bug) commit <Guest96>oh, you mean wait for it to stop hanging <nikolar>can i somehow disable ntp service and then reboot <Guest96>do you have a privous generation without ntp? <roptat>isn't it part of %base-services? <Groumf>Guest96 It just searches the current path. It's a wrapper around search-path <roptat>you can boot with no network, disable ntp and then connect <nikolar>well it was added as an additional service by the installer <nikolar>so it was there since the first generation <Groumf>Guest96 Honnestly I have given up on reading the docs and just read the code. It's clean and relatively well commented. <nikolar>how do i permanently disable a service <nikolar>without guix reconfigure since no net <roptat>you have to reconfigure without that service <roptat>oh but you can reconfigure even if the shepherd is not responsive <Guest96>Groumf Haha, that sounds like the right move as far as personal development goes, but docs are important to new users, so probably something about source patches should be added in the future. <Groumf>Guest96 I would be willing to help on that front. I am not sure how. But I am pretty sure there are some teachings to be shared from my little guix journey in packaging the stuff I need. Sadly I'm not a lisper. I mostly chose guix bc it comes from GNU and is not implemented in C++. But I wouldn't call that a positive choice. <Groumf>Guest96 Honnestly I have rarely seen a codebase that is so clean (build tools are usually very complex and obtuse). Paradoxicaly, it may be partly because it's in lisp. <nikolar>well scheme macros let you do a bunch of neat things <Groumf>I would go as far as saying that the code is the doc is not a joke for guix. Well, non-coder won't like it. Tbh, I don't think there are many people who don't code using guix. Using guix *is* coding. <nikolar>can you have /gnu on a different partition/fs <Guest96>Groumf, for now, using guix is coding, but I think that once it matures, that it will be able to support computer novices. I think it genuinely has such a superior design philosophy that it will win out. <Groumf>Well, building a comunity is hard. nix is full of haskellers. I am sure the average guix user is your typical emacs user who love lisp. <Groumf>I feel a bit like an oddball in here. OCaml/Erlang dev using vim :D <Groumf>At the end of the day, I think GNU provides some sort of *comprehensive user experience*. It's fine. It's great actually. But it doesn't necessarily promote diversity. <nikolar>how about a lisper (schemer) using vim <Groumf>I feel that's gross but I don't mean to offend :D <nikolar>well the whole poing of guix is that it manages everything <vagrantc>i daresay i cargo-cult most of the package definitions ... mostly learning by looking at what other packages are doing <vagrantc>hardest part is finding another package doing something similar enough to what i am doing <vagrantc>i learn by example better than documentation generally ... so may not fit everyone's learning style ... <vagrantc>but i still would not say i understand the lisp/scheme/guile stuff that guix is made out of :) <Groumf>Yes I am on the same boat. The cargo is very understandable but the doc is clearly not aimed towards packagers. <nikolar>well it's macros and functions all the way down