<rekado_>tribals: I used LVM way back, but on my laptop I haven’t missed it in years. <jab>johnjaye: you might need to generate the configure script <rekado_>johnjaye: use the ./bootstrap script <tribals>rekado_: In particular, if I could I would be using ZFS. Unfortunately, proposed patch has been discarded. <tribals>It was accepted partially. But, final part, which adds seamless integration of ZFS into Guix System, has been discarded. Specifically, `(zfs-service ...)` <rekado_>lots of unhelpful shouting in that discussion… :_/ <tribals>rekado_: I judge by technical characteristics, not by people. ZFS itself, as well as patch, is big advantege. I don't see any points why it was still not merged. <pizzapal>the hard drive only has 2 gb, that can still accomodate guix, right? <rekado_>tribals: if you’re interested in reviving this, please consider doing so. <rekado_>but note that people make this work. <rekado_>there are way more patches than there are active reviewers <rekado_>the discussion demonstrates a complete breakdown in communications, so nothing good can come from that <rekado_>feel free to comment on the issue; specifically the comments of the reviewers need to be addressed <gabber>is there an equivalent to special-files-service-type form home services? or how can i store their special config files (like ~/.emacs) in their home configuration? <tribals>I've read it top to bottom. There is another "vagues" about philosophical issues, not technical. And a suggestion to use BTRFS. Which is another mess (like grub), IMO. ***jesopo is now known as jess
<rekado_>tribals: lilyp had questions about complexity and maintainability. <rekado_>FWIW I’m not following the licensing discussion. IMO that’s unrelated to this patch and about zfs itself, which we have decided to offer as a package. <rekado_>also note that it has not been rejected. The submitter closed the issue. <tribals>rekado_: Thas't history now, let's move on. <rekado_>I’m not dwelling on anything. I’m just correcting an earlier statement. <rekado_>as I wrote earlier: feel free to adopt this patch and get it over the finish line. <pizzapal>i keep getting a 'uuid->string error when i try to format the hd partitions <ternary>Does the stdout of an mcron job get put anywhere? <rekado_>pizzapal: 2gb is very small for a comfortable /gnu/store; you’ll end up having to run “guix gc” all the time. <florhizome[m]>and gestures don’t work (maybe that’s a firmware issue though) <trevdev>ternary: Check ~/.local/var/log/mcron if it's guix home or /var/log/mcron if it's system <trevdev>I am banging my head against guixifying nim's whole build process (nim with it's included runtime binaries such as nimble). I can get the guix package to compile nim (nothing new) but the wall is at getting that built binary to compile anything that comes with <bjc>florhizome[m]: by default, gdm won't show wayland sessions <trevdev>For example, I need to use the freshly compiled ./bin/nim to compile kosh.nim. It starts, but then fails because something (can't derive _what_) is trying to call /bin/sh directly in the build environment. This is not a problem outside of a guix build. <trevdev>"CC: stdlib_digitsutils.nim" -> Searched the file, there is no hard-coded call for /bin/sh - I'm starting to feel a bit hooped here. Is there no simple way to symlink bash to /bin/sh within the build environment? <johnjaye>i've never even heard of this nim language before <trevdev>johnjaye: It used to be called "nimrod" <johnjaye>maybe it's trying to find the value of an environment variable. that's a common thing <trevdev>But if that isn't helpful, it's a compiled language that is trying to be as readable as Python but also have some really nice language features. <johnjaye>although it's weird it's doing it via bash directly <johnjaye>> Nim is designed to be "efficient, expressive, and elegant",[10] supporting metaprogramming, functional, message passing,[7] procedural, and object-oriented programming styles by providing several features such as compile time code generation, algebraic data types, a foreign function interface <trevdev>I agree. I hopped on their discord to ask someone (anyone) where this behavior is coming from. I can't seem to `grep` it <johnjaye>did you look at the disassembly with objdump <trevdev>johnjaye: I wish I knew what you were talking about <trevdev>Maybe that's part of why I, or whomever tried to package this fully before me, haven't sorted this out <johnjaye>meaning. if you look at the binary you might be able to see directly what command it's trying to invoke <trevdev>I will look into that. This has all been for the fun of learning Guix + do some of this nimrod stuff with a friend of mine who's absolutely chuffed with the language <trevdev>An English term I have no business using, but here we are <trevdev>Ah, apparently I can nim compile with a debug flag <johnjaye>how did you find it out needed to be incorporated into guix <trevdev>Well, nim is supposed to install with its package manager "nimble" by default. The current guix package does not include that (or any of the other included binaries) <trevdev>Specifically the part where we use the compiled nim comiler to compile its own features :P <trevdev>It's where we're compiling "koch" that's throwing these errors because of direct commands at /bin/sh from somewhere ***zuqjtuqbd is now known as john33
<john33>hey guys, i'm new to guix.. i searched for emacs using `guix package -s '^emacs'` and could only see emacs 27.x. i however, when i search `https://hpc.guix.info/browse`, there's a 28.x <ss2>have you pulled yet? <john33>i thought pulling is to update packages rather than some package list <ss2>Pulling is to update your package list, so to say, then you upgrade your profile. <johnjaye>trevdev: i feel like you have to know scheme c and also a little of autotools workings to do guix <trevdev>johnjaye: I can add that to my reading list. Definitely getting what I asked for by taking on guix (and scheme in general), and that's to try to broaden my understanding a bit more. A bit turned out to be a lot. Looking at the absractions built in the build-systems alone sent my head for a bit of a spin. I am a long way from JavaScript <johnjaye>trevdev: you can get most of the manuals on gnu.org <johnjaye>just type gnu <thing> manual and it should come up <johnjaye>the package names are a mess, usually you have to look for a package with -doc in its name <john33>i'm just reading the docs on `guix pull` and it seems to upgrade both the distro and package list. is it possible to makke it update just the package list? <john33>sorry if it seems like a lot. i'm busy with exams so haven't gotten around to read the docs. i just want to install emacs rn <johnjaye>in the case of autotools the info page for it is included in the 'automake' package <johnjaye>correct me if i'm wrong but i think that's the case? i don't see any info page for autoconf itself <johnjaye>john33: emacs is actually pretty easy to straight up download and compile from source. <trevdev>john33: This is an oversimplification, but think of `guix pull` as something similar to "apt update" <johnjaye>there's like an option to remove most of the dependencies <trevdev>By doing this you're updating the local "database" with updated state for what packages are out there. <johnjaye>i believe it's --without-all. so you'd invoke the configure as "./configure --without-all" for emacs and it leaves out as much of the deps as it can <trevdev>If you do a `guix pull` you will get local access to all fo the latest package versions <trevdev>But be warned john33, your next system or home reconfigure will update all of the packages concerned <trevdev>If you're like me and you have 60 home packages, some of which are compiled from source, you may be in for a bit of a ride just for trying to update your local env <trevdev>john33: No problem. Stick with using `guix install` for getting packages and maybe look into the new-ish `guix home service` later once you're more used to the new guix idioms. <trevdev>I jumped in head first and my head still hurts haha <john33>i have 0 packages. i'm using windows and plan to switch to linux after my exams. i've decided to go with guix, and i'm currently testing it on a vm. i'm a bit out of the loop with the guix terms (my fault), so even following advice is tough; it's nice to know i can come here if i stumble across an issue. i'd take a dive at the docs first tho <trevdev>john33: Guix is an interesting first distro choice. <trevdev>"Back in my day" my old man told me: "You want to try Linux on hard mode, and feel accomplished? Install Arch". I feel like Guix has superceded that challenge <john33>i've used ubuntu and deepin for like 2-3 years (was in high school). i mainly survived with stackoverflow tho lol. <trevdev>singpolyma: That's one way to look at it <trevdev>john33: Oh so you're not totally fresh! Either way welcome. Spread the word if you like what you find here1 <john33>i know c, and some lisps (chicken scheme, elisp). i couldn't get guile to work on windows, so have no experience. is there any other tech that'll make guix life easier? <trevdev>john33: So far as I can tell Guile is just Scheme with some unique features. I am probably newer to Scheme than you are. Lean on the manual for the Gexps and stuff <singpolyma>How is arch hard mode when Gentoo stage1 and LFS exist? <trevdev>singpolyma: It was near to Arch's first release that he made that challenge to me. I don't know when Gentoo happened, but I never considered it a prospect. It's Emacs/Lisp that largely pulled me into this space <trevdev>But in every thread about why "Arch is Great!" or "Arch is <anything at all>" you can hear the shrill cry of the Gentooian yelling "Gentooooooo!" <singpolyma>Gentoo is an established distro. I know it makes me look old, but I still consider arch "new" <trevdev>singpolyma: Anything a popular distro has done, GNU has done it in some less (unfortunately) popular way. I will try to remember this conversation if I feel the itch to try something 'new' <acrow>Guix goes places... After updating my Linux container on my chromebook to bullseye -- vagrantc's guix package easily installs and then following a 'guix pull' things are up to date. Testifying to the practicality of running guix on a chromebook. I don't expect it to be popular but I can testify it works just fine. <trevdev>sneek later tell acrow Oh it absolutely works. Part of what I like about guix is that it is portable. I am on Guix System now. If there were any reason for me not to be, I have my config :) I just feel challenged by learning the packaging, mostly. ***aeka` is now known as aeka
<johnjaye>you know i wish user interfaces of all sorts would have help keys <johnjaye>like. if you tap escape 3 times it shows you all the clickable elements. or 4 times it shows you all the togglable elements. etc <KarlJoad>I'm getting an error after a fresh guix pull. "In procedure write_wait_fd is unimplemented" <KarlJoad>Is this a temporary thing, or part of a larger change to Guix that I should not have pulled on accident? <KarlJoad>Seems to have been a glitch. Re-pulled and everything is fixed. <johnjaye>well doing ./bootstrap spit out a bunch of output about missing files <johnjaye>but when i ran ./configure in the gash directory it said ./configure: line 2386: `GUILE_PKG(3.0 2.2 2.0)' <johnjaye>well that's not what it said. the error was syntax error near unexpected token 3.0 <trevdev>Time appropriate greetings. Can anyone help me make it appear as though /bin/sh exists at /bin/sh in a build procedure? I have (substitute*'d) all that I could. I am still running up against Additional info: Could not find command: '/bin/sh'. OS error: No such file or directory 2 <sheertj>"#!/usr/bin/env sh" at the start of your script? Or "#!/usr/bin/env bash" <rekado_>johnjaye: you need to do this in an environment that contains development files for Guile 3.0 <unmatched-paren>johnjaye: do `guix shell -D guix` and then run the build commands (assuming you're building Guix...) <unmatched-paren>johnjaye: "i feel like you have to know scheme c and also a little of autotools workings to do guix" <- I think you only really need to know Scheme. No C or autotools knowledge is necessary <unmatched-paren>Unless you're hacking on the build system (Autotools) or the daemon (C++) <attila_lendvai_>is it smart to use /run/setuid-programs/ping in an mcron job? or am i doing it wrong? ***attila_lendvai_ is now known as attila_lendvai
<maximed>attila_lendvai: As which user is the job run? <maximed>In that case, you could do (file-append THE-PACKAGE "/bin/ping") *attila_lendvai needs to go AFK <maximed>to avoid the global /run/setuid-programs. *attila_lendvai will investigate later <maximed>(which I guess to be fine in practice but theoretically a bit messy w.r.t. global and mutation) <reyman>I'm searching some information about julia + Pgk managing in guix <reyman>i create a manifest.scm with Julia + using direnv to load this manifest <reyman>actually there a few julia packages in guix, <reyman>when i try to run Pkg.add("...") into julia i have curl error (but curl is installed), i miss somethings ? <fnstudio_>hi, i created a pure shell environment with a small subset of emacs dependencies; when i run emacs, my init.el throws errors because some dependencies are missing <abrenon>reyman: what do you mean "run" ? is that in a repl, or is that Pkg.add an instruction in your package compilation process ? <bruun>Anyone of you also having trouble running RetroArch from flatpak steam? I know it's not primarily guix related, but I've only had this issue on guix... <fnstudio_>maybe i should simply use emacs -q and stop complicating things in my head <abrenon>fnstudio_: what are you complicating ? <fnstudio_>hey abrenon thanks for getting back to me; here's the problem: i have this tiny emacs library that i'd like to ship with a guix.scm file with the bare minimum of emacs dependencies; but then my init.el won't work in a pure environment because of the missing deps <fnstudio_>i think the only solution is to use emacs -q <fnstudio_>and to manually load those init.el bits that are needed <reyman>@abrenon yeah, this is into the REPL using Pkg.add("bla") <abrenon>I don't use emacs so I don't know what -q does, sorry ^^ but I don't see why you couldn't achieve what you are trying to do <reyman>running Pkg.add("Agents") return : Error: curl_multi_socket_action: 8 <reyman>and └ @ Downloads.Curl /tmp/guix-build-julia-1.6.3.drv-0/julia-1.6.3/usr/share/julia/stdlib/v1.6/Downloads/src/Curl/utils.jl:36 <unmatched-paren>fnstudio_: guix shell -f guix.scm <all-the-other-dependencies-required-for-your-init-el>`? <abrenon>fnstudio_: ok, so you have successfully packaged that tiny library, but opening a pure environment with emacs an that library, emacs doesn't find it ? <fnstudio_>unmatched-paren: oh fantastic, i was probably assuming they were exclusive <abrenon>reyman: that's weird, that isn't supposed to happen I think (unless you are in a container without network access) <fnstudio_>abrenon: i think adding some extra deps (in addition to guix.scm) might be the cleanest solution <abrenon>does curl prints the URL causing trouble ? can you check it outside of Julia ? <abrenon>fnstudio_: what I don't understand is: are those "other dependencies dependencies of your personal emacs configuration in init.el or are they dependencies of your particular tiny library ? <abrenon>in which case I suppose they should be propagated or something, shouln't they ? <fnstudio_>abrenon: they're needed by my real-life Emacs configuration file <fnstudio_>abrenon: i can skip the conf file by using emacs -q but then i'll miss some config that i actually need for this small package <reyman>@abrenon i have network access, any url to Pkg.add() cause the trouble ... <reyman>i need to add julia curl specific package perhaps ? <unmatched-paren>fnstudio_: you could also write a manifest containing all the emacs-* packages your init.el needs <reyman>my manifest only contain : (specifications->manifest (list "julia@1.6.3")) <fnstudio_>unmatched-paren: wait... -m and -f... sounds interesting! let me try that <unmatched-paren>i've sent a v4 aerc patchset that updates all the packages to their latest versions... but now there's 6 more dependencies :) <abrenon>reyman: I don't know how packages are handled in julia <abrenon>what does the curl error look like ? are julia and curl installed in the same profile ? <reyman>curl is installed /available globaly and julia is defined into local manifest activated by direnv <reyman>i don't found tutorial to use julia + guix ***wielaard is now known as mjw
<unmatched-paren>rekado_: we could have teams for GNOME and KDE in there (though I wouldn't be part of either :P) <abrenon>rekado_: which people should consider joining teams ? <reyman>My direnv run use_guix() { eval "$(guix shell "$@" --search-paths)" } <abrenon>I'd have said context of the shell, profile being sourced or not but it shouln't matter if it's installed globally <abrenon>and I suppose it doesn't work either in a "regular" setup where you'd just open a repl from your regular julia install (or possibly from a shell which you opened from the command line) <jbv1[m]>reyman: can you show the error you get ? Normally guix's julia Pkg should work with most packages, at least the one that do not download binary artifacts. <reyman>~/Projets/ants-julia> julia -e "using Pkg; Pkg.update()" Installing known registries into `~/.julia` ┌ Error: curl_multi_socket_action: 8 └ @ Downloads.Curl /tmp/guix-build-julia-1.6.3.drv-0/julia-1.6.3/usr/share/julia/stdlib/v1.6/Downloads/src/Curl/utils.jl:36 <reyman>~/Projets/ants-julia> curl --version curl 7.84.0 (x86_64-unknown-linux-gnu) libcurl/7.84.0 GnuTLS/3.7.2 zlib/1.2.11 libidn2/2.3.1 nghttp2/1.44.0 <jbv1[m]>we should definitely update the julia package... <jbv1[m]>weird that I never got this bug, I'm not at my guix machine right now but I'll take a look this evening <reyman>is it possible to call an older version @jvbl[m] ? i try to call julia@1.6.2 but that fail in guix <jbv1[m]>I guess that you could, using something like guix time-machine but I have no experience with that. Also I'm not sure that would solve your problem. Best would be to update the julia package definition to 1.6.6 the currently supported LTS release. <jbv1[m]>1.6 is the long term supported julia which continues to be updated in parallel from 1.7 and 1.8 later <jbv1[m]>from 1.5 to 1.6 the update of the guix package was quite painful (changes in the build system) so I expect that from 1.6.3 to 1.6.6 it should be easier that from 1.6.3 to 1.7.3 <jbv1[m]>and since 1.6 is the LTS it makes sense to keep it in guix I think <jbv1[m]>that'd be great, as a next step I think we might skip 1.7 altogether, 1.8 is already just around the corner <efraim>got 1 test failure, will unmark the test as broken and try again <monadam>what's the easiest way to solve a package conflict in a profile? same version, different hash <apteryx>monadam: usually, upgrading all packages at once should resolve it <mekeor[m]>if i want to use cargo on guix system, should i install rust:out or rust:cargo? <apteryx>monadam: try removing your channel file, the conflict may well come from a channel package <ncbfg36>I have a simple config.scm with stumpwm, %desktop-services and a single user. Evrrything appears to work as root but as user account I am unable to run guix pull or install any packages. It always throws back "unsupported manifest format". I'm strugglinf to figure out what's going on <Franciman>hi, has anyone had a chance to try guix system on a thinkpad t440? <johnjaye>ncbfg36: is that from profiles.scm? i see the errror in there <johnjaye>also how does guix produce the cd images. just a shell script? <johnjaye>the "guix" repo is 97% scheme. and i can't imagine you could make an iso file system with schme <ncbfg36>johnjaye: It appears to be coming from ports.scm. I can't even "guix pull" as user. Digging around it appears that there has been no per user profile created for the user in /var/guix/profiles/per-user/ <johnjaye>i don't see ports.scm anywhere in the guix source <ncbfg36>johnjaye: I'm just reading that from the error on stdout <johnjaye>me too. i'm just reading from the output of grep. <jpoiret>monadam[m]: about yoru profile conflict, could you paste the ~/.guix-profile/manifest file as well as your guix describe output? <jpoiret>ncbfg36: are you logged in as root or your user? <ncbfg36>I'm confused. The docs just say run guix pull creates profile in .config/guix/current and to install packages with guix install <package>. Why is it concerned with a manifest when I haven't called it to read a specific manifest? I thought guix pull updated guix and packages for the current user <jpoiret>did you use `guix package` as root or user <reyman>i try to test guix time machine for an old version of julia, but i'm not sure because i obtain an error <dlowe>I think guix pull syncs the local guix store without affecting installations or configuration <reyman>my manifest is simple : (specifications->manifest (list "julia@1.6.2")) <reyman>i try to get the corresponding channels.scm using this guix time-machine --commit=02a67810e566e8402e0b927c81ae39391762767d -- describe --format=channels > channels.scm <ncbfg36>jpoiret: The user account has no .guix-profile. And there is no user folder in /var/guix/profiles/per-user/ <reyman>with commit 02a67810e566e8402e0b927c81ae39391762767d equal the commit of guix with this julia 1.6.2 <ncbfg36>jpoiret: I am trying to run guix package as user. It works as root but not as user <reyman>the error log return : (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (linux-libre-5.18)) (value #f)) <silicius[m]>Would guix welcome a package for a game launcher that downloads prebuild packages while both the launcher and the game itself have guix-compatible licenses? The game itself is already in guix, but there's an experimental branch that releases every few hours and a lot of people (including me) play it. <reyman>i suppose this is linked to the fact my channels contain other things than linux-libre <reyman>is it possible to change a commit of only one channel for guix ? <ncbfg36>jpoiret: running guix describe as user also returns "error: unsupported manifest format" <ncbfg36>jpoiret: the user was created with basic details in system config.scm and instantiated as root using guix system reconfigure /etc/config.scm <jpoiret>dlowe: `guix pull` only builds the latest guix from the tip of the master branch, and switches your guix pull profile at `~/.config/guix/current` to it <jpoiret>what does `comand -v guix` tell you? <ncbfg36>jpoiret: /run/current-system/profile/bin/guix <jpoiret>and you also have a ~/.config/guix/current/bin/guix, right? <ncbfg36>jpoiret: running that as root returns /root/.config/guix/current/bin/guix <ncbfg36>jpoiret: no in the user home dir there is no .confif/guix* <jpoiret>i think the issue is that you've `guix pull'd` using the old system-wide guix (which is updated way less often) and the new guix living at ~/.config/guix/current uses the new manifest format <jpoiret>you'll need to use the guix pull'd guix by sourcing its profile with `GUIX_PROFILE=~/.config/guix/current; source $GUIX_PROFILE/etc/profile` <jpoiret>it's weird then that guix describe complains about the manifest format <jpoiret>i think the problem is quite similar actually <ncbfg36>so when I ran guix pull as root it worked and prompted me to source the profile as you just described. When i attempted to run guix pull as user it complained about the manifest format <jpoiret>oh no, I think i know what's happening <jpoiret>did you guix pull before reconfiguring as root? <ncbfg36>I ran guix pull as root on first boot <ncbfg36>and then started working on a system config.scm <jpoiret>can you fetch the manifest version from /run/current-system/profile/manifest, and the guix commit which should be in /run/current-system/profile/share/guile/site/3.0/guix/config.scm (inside the define %channel-metadata block) <ncbfg36>okay i'll need a minute as i have irc on phone <jpoiret>only the first couple characters of the commit should be ok <jpoiret>the guix package was updated recently <reyman>hum, so my first use of guix time machine is not a success : "guix time-machine --commit=02a67810e566e8402e0b927c81ae39391762767d -- shell --ad-hoc julia" break <reyman>error returned continue to be "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (linux-libre-5.18)) (value #f))" <jpoiret>yet another issue with having out-of-date guix-the-package: any system installed (or reconfigured) using a commit between the introduction of the new manifest version and the updating of guix-the-package to a commit after the former will have a non-functional system-wide guix <jpoiret>it's ok for people that have already guix pull'd, but for people just installing it's an issue <jpoiret>that's because `guix pull` and `guix describe` both try to lookup the version of the current guix, which it does by sequentially a) looking at the manifest of the profile it's running from, to see if there's extra properties about the guix provenance (which is only present in `guix pull`ed profiles) b) looking at the guix/config.scm file which <jpoiret>should hold such info if guix was built as a package otherwise. <ncbfg36>the guix commit starts with 589f7289 <jpoiret>in case a) if guix cannot read the manifest, it instantly bails out instead of falling back to b) (I think) <ncbfg36>jpoiret: I remember it complaining about not being able to establish system provinance, but it ran without error otherwise <ncbfg36>jpoiret: but then why is it working as expected for root account? why does the root account habe a profile and is able to update/install packages? <jpoiret>this system is not a fresh install, right? <jpoiret>well, it worked because guix pulled as root before reconfiguring <jpoiret>hence the problem appeared with the system wide guix after reconfiguring <ncbfg36>yes i installed it yesterday. All I have done is added desktop environments to system config and ran guix system reconfigure. I was able to log in to graphical desktop as user account and use system wide packages e.g emacs. <jpoiret>your guix pull was yesterday, right? <jpoiret>righttt, so the problem should be solved now <jpoiret>guix-the-package was updated right after you guix pull'd i think <jpoiret>you need to guix pull as root, reconfigure and reboot <ncbfg36>jpoiret: that's what I just did. Like an hour ago <jpoiret>this issue should have been occuring between the two commits i highlighted above, and you just happened to run into it moments before it was fixed <jpoiret>what does `guix describe` as root tell you? <jpoiret>commit 06493e738825598447f5b45d7100ca7eff8b669d should have updated the guix package beyond 598f7289db9955584457ffc11c8504f3938a1618 <jpoiret>are you sure you reconfigured and rebooted? <jpoiret>the config.scm file should not contain the old commit in that case <ncbfg36>jpoiret: it seems to be working now. Guix describe as user returns c23e0aa <ncbfg36>I literally performed exactly the same thing several times. It seems this one did the trick <jpoiret>great, that's the commit corresponding to the updated guix package <ncbfg36>jpoiret: thanks again for your help. I've learnt something :-) <seer>uhhh guys can I get some package updates? <jpoiret>ncbfg36: the interplay between guix pull and guix-the-package-in-guix leads to such issues but is quite hard to grasp <rekado_>reyman: at that commit there must have been a problem in Guix where a package was renamed. <silicius[m]>hmmm. swftools I'm packaging is probably vulnerable to 42 CVE according to guix lint <reyman>@rekado, ok ! So the best things to do was probably to test other commit ? <lfam>`./pre-inst-env guix weather calibre` -> "100.0% substitutes available (1 out of 1)" <lfam>`./pre-inst-env guix upgrade` -> The following derivation will be built: <lfam> /gnu/store/rcfwjvikq10vs16h90xrwwmvak8byhbh-calibre-5.36.0.drv <lfam>`./pre-inst-env guix build --no-grafts calibre` -> /gnu/store/m22akdn9igd756irmx5wn0mssbhj264m-calibre-5.36.0 <lfam>Looks like the calibre package doesn't handle grafts as expected. It actually must be recompiled when grafts are enabled <cbaines>lfam, note that guix weather doesn't look whether you'd actually use a substitute, just whether substitutes exist <cbaines>I feel like I'm repeating this at this point, so I wonder whether guix weather should emit some kind of warning if some of it's output would be different if it took trust in to account <rekado_>reyman: hmm, I’m not sure… I’m getting a different error, which doesn’t make much sense to me. <rekado_>I also see that build of /gnu/store/dqva9ac05z1xxcbfm912pchna7bwbkpj-guix-package-cache.drv failed <rekado_>but the reason why is … the manifest version change…? <cbaines>digging the guix store item out, even the describe command fails: guix describe: error: unsupported manifest format <cbaines>I wonder if some recent manifest format change is actually breaking old guix'es <lfam>cbaines: Can we clarify the weather situation? My understanding is that `guix weather calibre` makes a derivation and then checks if a substitute for the derivation exists on the server. Is that right? <lfam>Well, the issue with weather is a red herring anyways, IMO. The issue is that `guix build` and `guix upgrade` are building different derivations for the same package, and I don't understand why that is the case <cbaines>right, I think I see the same behaviour locally <cbaines>guix build --no-grafts calibre doesn't build anything, since it's in the store <cbaines>but guix build calibre starts to actually build calibre <lfam>It's unexpected, right? Or am I missing something <cbaines>guix build -d calibre also confuses me, since it starts to build calibre <lfam>That's "expected" in the presence of grafts <cbaines>maybe... but only if it's building the ungrafted things <cbaines>which it shouldn't be, at least the ungrafted calibre, since I've got that in the store <apteryx>hmm, how do I get rid of: "configure.ac:11: error: version mismatch. This is Automake 1.16.3" <DynastyMic> Hello, why do i get the following error when trying to "source venv/bin/activate" in python-virtualenv package? <DynastyMic>"# This file must be used with "source bin/activate" *from bash* <apteryx>DynastyMic: do you have more exact steps of what you are doing? sourcing an activate script works for me, using virtualenv provided by Guix <rekado_>apteryx: what happens on line 11 of that configure.ac file? <DynastyMic>just cd my-project, run "virtualenv venv" which outputs "created virtual environment CPython3.9.9.final.0-64 in 385ms <DynastyMic> creator CPython3Posix(dest=/home/user/project/project-backend/venv, clear=False, no_vcs_ignore=False, global=False) <DynastyMic> seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/user/.local/share/virtualenv) <DynastyMic> added seed packages: pip==20.3.3, setuptools==51.1.2, wheel==0.36.2 <DynastyMic> activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator" <DynastyMic>then run "source venv/bin/activate", which outputs "Missing redirection target" <DynastyMic># This file must be used with "source bin/activate" *from bash* <DynastyMic> echo "You must source this script: \$ source $0" >&2 <DynastyMic> # ! [ -z ${VAR+_} ] returns true if VAR is declared at all <DynastyMic> if ! [ -z "${_OLD_VIRTUAL_PYTHONHOME+_}" ] ; then <DynastyMic> # This should detect bash and zsh, which have a hash command that must <DynastyMic> # be called to get it to forget past commands. Without forgetting <DynastyMic> # past commands the $PATH changes we made may not be respected <DynastyMic> if [ -n "${BASH-}" ] || [ -n "${ZSH_VERSION-}" ] ; then <vivien>oriansj, that’s too late I think <DynastyMic>VIRTUAL_ENV='/home/user/project/project-backend/venv' <DynastyMic>if ([ "$OSTYPE" = "cygwin" ] || [ "$OSTYPE" = "msys" ]) && $(command -v cygpath &> /dev/null) ; then <rekado_>I like that this sounds like a space ship’s self-destruct, unstoppable <DynastyMic>if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] ; then <DynastyMic># Make sure to unalias pydoc if it's already there <DynastyMic>alias pydoc 2>/dev/null >/dev/null && unalias pydoc || true <DynastyMic># This should detect bash and zsh, which have a hash command that must <DynastyMic># be called to get it to forget past commands. Without forgetting <DynastyMic># past commands the $PATH changes we made may not be respected <DynastyMic>if [ -n "${BASH-}" ] || [ -n "${ZSH_VERSION-}" ] ; then <vagrantc>DynastyMic: you can sacrafice yourself with honor at this point ... i mean, feel free to come back, of course! <nckx>Jus too late, but glad to see it was harmless. <oriansj>DynastyMic: you know you could have just asked what they polite way to share something and we would be happy to teach you <vagrantc>DynastyMic: you used the pastebin ... eventually. :) <nckx>Yes. No wake the nckx again ever kthx. <DynastyMic>It never crossed my mind there was a polite way to share something <vivien>Yes, that’s an oddity of IRC, you have to know that there is a problem before asking for the solution <nckx>podiki[m]: But seriously, thanks for the ping :) <oriansj>DynastyMic: can you imagine not wanting to be given something or be given to you in a way you don't feel comfortable with? <podiki[m]>nckx: wasn't sure if this was a beetlejuice situation and needed some more invocations... <nckx>I'm ill so went to bed early, but you did well. I realised too late that my mock crankiness could discourage future pings. Those are always welcome. <DynastyMic>i would just tell him/her politely, but not make a big deal about it nor try to humiliate him/her <podiki[m]>nckx: no worries, hope you feel better soon! <vagrantc>in a typical face-to-face conversation, you might ask someone if it's ok to read an entire novel to them before starting <oriansj>DynastyMic: basic consideration for others is important. As is trying to interpret what others express with the benefit of doubt is required for healthy communication on on this medium <nckx>IRC culture is opaque. Please, let's all leave it behind us not :) <apteryx>rekado_: I think I got around the issue by re-running ./bootstrap <vagrantc>yeah, let's switch to $NEWCHATPROTOCOL ! <nckx>Benefit of the doubt is key. Night! <DynastyMic>the guix site says "Join the #guix channel on the Libera Chat IRC network to chat with the community about GNU Guix or to get help in real-time." <DynastyMic>I'm a humble philosopher, I have no idea how IRC works <vagrantc>DynastyMic: you're learning, and so are all of us :) <oriansj>DynastyMic: no worries, we all make mistakes when we haven't had a chance to learn <apteryx>DynastyMic: don't worry, we all went through this initiation ritual at least once <oriansj>but we are here to help people learn and understand <oriansj>DynastyMic: well yes, it is mature communication between adults <dlowe>also it can be extremely different depending on the client you use <oriansj>dlowe: fine, manners on IRC have had a few decades to mature but which group will always indicate the level of politeness expected. <dlowe>don't paste multi-line stuff directly in channels <oriansj>DynastyMic: not everyone is on all the time and if you are gone you might want to check the IRC logs to see if anyone answered <oriansj>DynastyMic: everyone on a channel probably shares the same common interest as you do (Guix in this case) <oriansj>So you are with a big group of friends who do want to help you <oriansj>So be kind, caring and your honest self <jpoiret>rekado_, apteryx: ./bootstrap runs `autoreconf`, so i'd suggest doing that if it something configure-related doesn't work <apteryx>jpoiret: hey! it seems obvious now, thanks for the refresher <yewscion>vagrantc: Thanks for the link! I'm looking forward to reading that, now that I know it exists! <jpoiret>just send a whole novel to guix-devel about the different ways we build guix, hope it's not too daunting to answer :) don't hesitate to answer, even if it's because there's a part you don't really understand, so that everyone has a good understanding of the issue <gabber>i'm still not sure what you mean exactly <gabber>i think it's a Guile internal (see Section 4.4.4.8 System Commands) <gabber>yes, i see that now, too. i executed geiser-doc-look-up-manual in Emacs which lead me there.. sorry <unmatched-paren>took all the imports from guix/scripts/git/authenticate and removed them until it didn't work <apteryx>does 'make check TESTS=tests/guix-system.sh' fail for you too? <apteryx>t-guix-system-1715:3:0: error: %base-file-systems: invalid field specifier <silicius[m]>guix lint tells me pyparsing@2.4.7 and pyparsing@3.0.6 propagated inputs collide, not sure how I can I fix this <apteryx>it's wrong to propagate different versions of Python inputs <silicius[m]>cloudscraper#1.5.28 is the victim as it depends on pyparsing@2.4.7 ("last release supporting python2.x"), but I don't see why since cloudscraper at this and later version depends on python3 <apteryx>probably should be adjusted to use the latest version then <apteryx>so the line failing for the guix-system.sh test is "grep "service 'networking'.*more than once" "$errorfile"" <apteryx>bah, the error was local to my tree, hidden in the test output: "In procedure abi-check: #<record-type <image>>: record ABI mismatch; recompilation needed" <silicius[m]>Do we have v8 in guix? I see that there is r-v8 "R bindings for v8" but I don't see any obvious package that supplies the v8 itself <rekado_>that’s why r-v8 has node among its inputs <silicius[m]>I finally did it, hydrus-network and all other packages I added pass guix lint <silicius[m]>Now I need to sort it out into multiple patches with proper descriptions