<polyex>anyone got example handy of exact same config in guix vs nixos? wanna show someone why guile > nix for declarative config <polyex>anyone have guixSD project stats and graphs? or know where to look to see the data? i wanna see how the guix project is doing and hopefully growing, like number of active contributors, number of weekly commits over time, number of downloads of the installer, stuff like that <polyex>i tried looking at distrowatch trend but that's not a great metric and looked sorta flat <polyex>which cant be possible because guix is best implementation of best system CM style (fully declarative) so it has to be growing <tschilptschilp23>how would I set JAVA_HOME on guix? I've skipped my above attempts, and now try to bootstrap bazel itself. For that I started a shell using 'guix shell openjdk@11 gcc-toolchain zip unzip bash python', which should satisfy the prerequisites. I've searched the store to set it to what sounds most like it, but receive the error 'ERROR: JAVA_HOME (/gnu/store/6h5909qwpasmk67mn72gj1j0gsl9l8ld-openjdk-11.0.15/) is not a path to a working <tschilptschilp23>Also, the contents of the store-directory don't really look like, what it searches for (quite a bunch of .jar-file, which are under something like /usr/share/java on a FHS-distro). Where do we have these? <Aurora_v_kosmose>It builds with very few dependencies, but its installation part is a bit weird as by default it produces a self-extracting installer (the build.xml also supports just generating a tarball or the requirements for the tarball) <Aurora_v_kosmose>The Debian path patches would make it reasonably easy to patch with the right paths, I suppose. <seerlite>Hi! What would be the best way to have a command run once every boot? I'd like to delete all contents of a directory as root (I want the specific directory to behave as a tmpfs without mounting it as tmpfs). <zamfofex>Maybe investigate setting up your own custom service. I don’t have much experience declaring services, though. <xelxebar>seerlite: Check out any of the "one shot" service definitions, e.g. host-name, sysctl, etc. gnu/services/sysctl.scm is particularly straightforward. ***dgcampea-2 is now known as dgcampea
<lechner>Hi, should file-append (from gexp) be called path-append? <clarity_>Is it possible to install guix on top of armbian? I was reading (maybe dreaming) that I could use armbian and then install guix on the nvme (instead of eMMC). Then boot guix os off of that? <seerlite>xelxebar: Thank you! That example is very helpful. <vivien>lechner, It means "append something to a file-like" so ideally it would be called file-like-append <vivien>But file-append is good enough I guess <vivien>Also, be careful, a "path" is a collection of filenames or directory names that are searched in order for a known thing <vivien>eg, the content of the PATH environment variable is a collection of directory names that are searched for programs <vivien>I think that it is important to make a difference between a file (or directory) name and a path, especially for software like guix <zamfofex>The PATH variable contains multiple paths separated by a colon. And filenames (and directory names) are paths themselves, though relative rather than absolute. <vivien>If so, wouldn’t it be called PATHS? <zamfofex>UNIX made strange naming decisions. PWD is another such example. <zamfofex>I don’t think anyone would consider e.g. “/bin:/usr/bin” to be representing a single path. Unless you have a directory literally named “bin:” (with a colon) at the root of the filesystem. <vivien>I know the web people use something that looks like a “file name” in IRIs <vivien>I like the fact that there’s a word for /a:/b:/c <zamfofex>I see. I don’t think I’ve ever seen anyone use that nomenclature at all. Even APIs commonly don’t. I feel like you could just call it a “path list”, and that is succinct enough. <vivien>By API, you mean like, realpath and such? <zamfofex>Yes, though not only C APIs, also e.g. Python, Haskell, C#, JavaScript. <zamfofex>I don’t think I’ve ever seen (or at least noticed) anyone actually use the nomenclature suggested by that GNU document before today. <zamfofex>Interesting. I wonder what leads GNU to contradict the usual definitions people use like that. Normally they at least give a rationale for it, but here it is just told “do this, not that” without an actual explanation for it. <vivien>Maybe that’s too old to say who contradicted who <vivien>(but if I’m sure of one thing, it’s that Microsoft should never be trusted to name things) <zamfofex>GNU says to avoid following the UNIX practice (from your own quote), and I’m pretty sure UNIX predates GNU (GNU being created as a replacement for UNIX). <vivien>Yeah but did the *PATH environment variable predate UNIX? I don’t know <zamfofex>Good question, and fair argument. Though I think I still defend that people should prefer using the most common nomenclature (regardless of which is the original) in order to avoid confusing others, specially when it’s more common by far, as long as it’s consistent and doesn’t infringe ethics. <vivien>Also what’s said to be wrong with UNIX is that they use “pathname”, something that I guess is very rare nowadays <zamfofex>(Also: Note that I say “prefer” intentionally, rather than “definitely use”.) <vivien>In any case, now you know 1 person prefers to reserve the term “path” to an order list of file or directory names :) <vivien>Even if all the boomers of that early holy war died <vivien>(not to offend anyone that remember those days) <vivien>(the sentence above was not neutral, please pardon me, I should have thought a bit more) <zamfofex>It is fine, I feel, don’t worry. 🙂 Though I think that nomenclature usage at least warrants a written rationale in that document, given that it’s really uncommon nowadays. <Ribby>Elisha, that's not a libera chat domain. That's a ems.host domain. <Ribby>Opps, don't click that link above! <lilyp>On the PATH issue: Having ambiguities in something as common as file names and paths is not that great for non-native speakers (some of whom are translators), and I think that weighs into the reason to avoid "path" for file names. <Cairn>Am I reading the channel news correctly? Is native compilation enabled by default with Emacs now? <Cairn>I'm using the `emacs-next` package. Do I need to do anything to use it? <zamfofex>Ribby: libera.ems.host is the Matrix bridge’s domain. It shows up whenever a Matrix user sends a multiline message. <vivien>Why the missing ']' in the spammer’s name? <zamfofex>vivien: Maybe it would be too long otherwise. <vivien>[m] means matrix, not mod, right? <zamfofex>Yeah, I’m pretty sure [m] is for “Matrix”. 😅 <zamfofex>lilyp: I suppose so, though it’s not like GNU is abolishing the usage of the word “path”, it’s just using it for something different to the current usual. <zamfofex>Which I feel like ought to be more confusing than just adopting the current norm. <lilyp>Cairn: emacs has native-compilation by default now; the rest of the news entry just details how you get some of the pre-compiled binaries that it stores in your user-emacs-directory into the gnu store <zamfofex>If it preferred and recommended to avoid the word “path” altogether (since it’s jargon, and people unused to it might have a hard time understanding/translating it), I feel like your argument would make more sense. <zamfofex>And that wouldn’t be an unreasonable recommendation, I feel. <Cairn>lilyp: That's really cool. I've been a little OOTL, but I remember when this first started being talked about. The amount of work some of these great people put in makes me so happy :D <lilyp>zamfofex: GNU is not known for simply adopting problematic wordings. Also, with consistent use of "file name" and "search path", there is no confusion, there's just the weird "pathname" that never made much sense. <zamfofex>That is fair enough. Though I feel like “search path” is clear, whereas just “path” (to refer to a list of file names) might not be. <lilyp>IIRC the GNU recommendation is to use "search path", and Guix also does that. <zamfofex>How would you collectively refer to something that can be either a directory name or a file name under GNU’s recommendation? <lilyp>note the "file-is-directory" predicates in both Guile and Emacs <zamfofex>Ought I to say “relative file name” and “absolute file name” too? And how to refer to a single component thereof? (E.g. “dev” and “null” in “/dev/null”) <lilyp>p sure relative and absolute work as adjectives as always <lilyp>as for the components, I think "part" might fit, e.g. the non-directory part <zamfofex>Normally, at least the way I’d think about it, a “file’s name” (its “file name”) is just one component, not the whole absolute thing. <lilyp>A file name can be many things, right? (absolute, relative, truncated, ...) <zamfofex>Yeah, it was mostly a note about my own cognition, rather than an actual argument. <zamfofex>Though I will say: I don’t immediately mentally shun using “file/directory name” and “search path” the way you describe as much as using plain “path” as it was described before. <lilyp>but sure "dev" is just as much a file name as "null" is, but it might not be a valid file name depending on your current working directory and the operation you might want to perform <zamfofex>Though I do dislike that there is no good way to refer to the last part of a file name succicntly (other than having to say “the last part of the filename”), e.g. the “image.png” in “/home/zamfofex/images/image.png”, since I feel like that’s a fairly common thing to want to refer to. <zamfofex>Though now that I sent that, I suppose “base” or “base name” doesn’t sound inappropriate, though I’m unsure if it is recommended. <zamfofex>Something like “the file’s base name” or “the directory’s base name” sounds clear enough, I feel. <vivien>I’ve always called that a base name as opposed to the directory name and the file name extension <lilyp>zamfofex: basename or non-directory part ***taiju is now known as Guest3801
***taiju` is now known as taiju
<lechner>vivien zamfofex lilyp: thank you for your extensive discussion (and sorry about provoking it). my issue was more that file-append does not act on file contents, which i believe is the most common reading. <vivien>Not enough time is spent thinking about the names of stuff. That’s why we’re stuck with "master" as the default default git branch name, for instance. <flypaper-ultimat>xelxebar: yeah, they're aware of that, there's been a discussion on the guix-science mailing list about it. <lechner>Hi, how do i actually append something (like an input file) to a build file after the 'unpack' phase, please? <vivien>lechner, you mean to modify a file while building a package? <vivien>If so, you may want to add new phases in the build procedure, or add a patch or a snippet to the package source <lechner>maybe a snippet is better. i just don't know how to do that <lechner>i am not sure it exists. i am looking for cat (rocket-layout input)/share/xkb/symbols/rocket >> (build files)/share/X11/xkb/symbols/us <vivien>Does the file format accept some form of an "include" declaration? <vivien>There’s no shortcut to do the '>>' in guile <vivien>You have to open the file in append mode, write to it, and close the file <vivien>or rather, there’s no shortcut to do the '>>' in GUIX <lechner>i'll look at guile on how to do it manually <xelxebar>flypaper-ultimat: Nice. Thanks for the pointer. <vivien>I don’t know why it is a problem, if you replace a dependency with another one that provides the same binary, then the phase with search-input-file will still work <vivien>That looks like a good thing to me <unmatched-paren>where it does collide, use this-package-input or this-package-native-input <lechner>that looks like an unnecessary bit of fuzz to me, and a potential source of bugs <lechner>i do not doubt the syntactical convenience <vivien>Sorry I think I’m on the wrong channel <unmatched-paren>actually, since most programs are supposed to install to one prefix, instead of the gazillions provided by guix, there should almost never be collisions <unmatched-paren>i think the most common use of this-package-input might be referring to a specific instance of a directory, eg share/pkgconfig <jpoiret>search-input-file can create collisions if two inputs provide the same file, but that's not supposed to happen since you control which inputs you add to the package <jpoiret>lechner: do you have a concrete example of such an issue? <jpoiret>there are ways to work around that if needed :) <unmatched-paren>exactly, and collisions should be rare since packages need to assume that everything is put in /usr, in which case collisions would be Very Bad, as they'd override an existing file <unmatched-paren>i think raghavgururajan is working on reviewing aerc anyway, so i don't need to pester the channel about that one anymore :P <lechner>jpoiret: no, i do not have a collision, but with Guix's absolute paths into the store i find it easy to envision one, particularly if one were to work with different versions of the same software <unmatched-paren>it seems rather unlikely that you'd have two versions of a thing in the same inputs list <unmatched-paren>anyway, i think where that could happen the developers would namespace paths appropriately <vivien>(and then there’s libsoup that will abort your program if the other version of libsoup is already linked) <unmatched-paren>...and now I understand what all the grumbling about libsoup was about. :P <lechner>at a minimum, the momentary reliance on relative file names seems inconsistent with the functional approach but i really do not mean to argue the point further <lechner>it encourages a search when none may be needed ***Dynom_ is now known as Guest5058
<pkill9>does guix use secure/verified boot? and if not how viable would it be to make it work? <unmatched-paren>pkill9: (1) no (2) iiuc the process requires you to send a binary of the shim bootloader to m$ to be signed <lechner>unmatched-paren: thanks for the pointer. when i change it to "a+", guix package --install-from-file=guix/rocket-layout.scm says nothing to be done <lechner>it also says that for other changes to the phase, so i am probably doing something wrong *GNUtoo wonders if there is a bot that can relay messages here <sneek>Welcome back GNUtoo, you have 1 message! <sneek>GNUtoo, unmatched-paren says: like this <GNUtoo>seer: later tell gnucode: I booted on Guix system on my laptop and I cound't install gnome-clocks: guix package: error: package gnome-clocks@42.0 does not support i686-linux <GNUtoo>it's probably some auto-completion <GNUtoo>sneek: later tell gnucode: I booted on Guix system on my laptop and I cound't install gnome-clocks: guix package: error: package gnome-clocks@42.0 does not support i686-linux *GNUtoo didn't see the n in sneek <GNUtoo>I managed to make it compile under 4GiB at some point <GNUtoo>And I'm not sure 4GiB would be accepted, like it would require an x86_64 host like what the builders use to build rust <GNUtoo>yes I did something like that + some patches whose impact I'm not sure about <GNUtoo>And things keeps changing in mrustc <unmatched-paren>i guess they always have to be catching up to a move-fast-and-break-things project *GNUtoo wonders if it's not rather a design issue of the compiler <unmatched-paren>e.g. there was a let ... = ... else { ... } feature that got accepted <GNUtoo>like if for some reasons everything is in memory, then besides making code small (-Os) and stripping binaries I don't see how to reduce the memory consumation furthurer *GNUtoo doesn't know rust yet <GNUtoo>(where regex is embedded deep in the language) <GNUtoo>ah ok more like a function that outputs stuff <GNUtoo>Anyway I'm unsure what to do there, like I don't have the time nor knowledge to rework the mrustc compiler <unmatched-paren>match in functional languages like haskell, ocaml, and rust is a very useful feature that lets you deconstruct and switch on conjunctive and disjunctive types <GNUtoo>Maybe it would be possible to build the rust compiler with gcc's rust support? <unmatched-paren>and you can act on it using `match some_foo with | Foo x => ... | Bar => ...` <GNUtoo>Ah I start to understand, is it that people try to design a very good language but don't take the implementation difficulty into account? <GNUtoo>Ahh and that's there were the no standards starts becomming an issue I guess <unmatched-paren>they never put their foot down to an RFC and say "sorry, this would be useful but we'd rather not make the language so complex" <GNUtoo>because you can't say C11 or X89 <GNUtoo>Linux is developed in a similar way though <ulfvonbelow>the other half of the problem would be that rust developers commit to relying on new features super fast, so everyone relying on rust just gets dragged along the rails <GNUtoo>Ah that's a big issue, I'd suppose than when you do something like that you at least need to be ultra strict on backward compatibility <unmatched-paren>it's not like someone will actually want to reimplement linux, anyway <GNUtoo>And you also need to be ultra strict on defining the behavior <GNUtoo>unmatched-paren: right, but at least it makes linux usable: userspace applications can rely on it not breaking older applications. The caveat with that is that to get that compatibility you may need to recompile your kernel. <GNUtoo>At least with Linux both old and new stuff usually interact well, like if you enable oss compatibility, alsa still work for instance <unmatched-paren>still, the problem still stands: rust is a huge monolith that keeps getting bigger <GNUtoo>There is also strategical questions behind <sneek>Welcome back unmatched-paren :D <GNUtoo>Like is it OK to have a language that can only have 1 implementation? <GNUtoo>13:43 < GNUtoo> There is also strategical questions behind <unmatched-paren>time would be better spent on making a better language (which would not be hard :P) <GNUtoo>In the case of Linux it's a mixed bag, in one hand it prevented to have a GNU kernel, but in the other hand it's not that bad and it also prevents to have nonfree kernels for OS like Android for instance <unmatched-paren>well i think if linux didn't exist we'd all be using freebsd, not hurd *GNUtoo didn't have specifically HURD in mind <unmatched-paren>wasn't freebsd really close to finished when linux was written, they were just being hounded by lawsuits? <GNUtoo>In GNU, many times reusing code didn't work so they rewrote the code from scratch <GNUtoo>Well I was more talking about any kernel made by GNU <GNUtoo>Like if they started over and did something monolytic that counted as well <GNUtoo>As I understand the issue was more that the code they got wasn't great <GNUtoo>Like it was ultra buggy and so on <GNUtoo>And the code they got was the microkernel that came from an university <unmatched-paren>they were probably doing something wrong rather than any inherent problem with microkernels <GNUtoo>reference: The framasoft edition of RMS biography in French <GNUtoo>Yes but AFAIK it wasn't using the microkernel (that I don't remember the name) that was buggy at the time <GNUtoo>And Minix is also not the only OS that works that uses microkernels <GNUtoo>And many kernels of very small OSes <GNUtoo>There are also a lot of nonfree OS with microkernels <GNUtoo>There are also free software security OS for microcontrollers etc *unmatched-paren wonders if solaris uses a microkernel <GNUtoo>And QNX dates from 1982 for instance <GNUtoo>[[Opensolaris]] says the kernel is monolitic <GNUtoo>Though things also evolve, for instance in Linux you can have many drivers in userspace too <ulfvonbelow>hmm, does xorg.conf allow multiple "Option" directives on a single line? When a keyboard variant is specified, xorg-configuration->file puts the 'Option "XkbVariant" "<variant>"' on the same line as 'Option "XkbLayout" "us"' <pkill9>does anyoen run guix on a framework laptop? <GNUtoo>What boot software does that use? Coreboot? <pkill9>GNUtoo: sadly propietary BIOS, but they say they are exploring coreboot <pkill9>they say for now they are focused on getting the laptop out <GNUtoo>Many vendors (but not all) often promise to work to improve freedom and never do because they rather focus on making it possible to at least ship something <GNUtoo>I've seen that happen in a crowd funding for instance <GNUtoo>So if something related to freedom is promised later, usually just shipping the device takes precedence for obvious reasons <GNUtoo>The fix is probably to have the freedom thing not later but at shipping time <GNUtoo>Or to have separate funding and projects for both <GNUtoo>There is an issue: I'm the only person in the room <xd1le>yes it's not working, we can't hear <jonsger>internet connectivity seems to be struggling <GNUtoo>I forgot to stop sharing the webcam <GNUtoo>Maybe it'll use way less bandwith now <GNUtoo>On my side I'm connected through Ethernet <GNUtoo>On your side it might be worth trying to connect through Ethernet if it's not already done as WiFi in crowded places usually doesn't work well <jonsger>we trying a connection via cable, Ludo is on it <GNUtoo>Especially 2.4GHz saturates really fast <GNUtoo>I see a blank instead of the mic on your side <jonsger>and ##guix10years on libera.chat maybe worth a join for you :) <GNUtoo>If you join for listening there should probably be a earphone instead <olasd>GNUtoo: I'm sorry; we tested on wifi, but people came back to the room, and apparently the wired setup doesn't like the BBB ICE <apteryx>that's too bad, I was looking forward to learn more about Replicant and how it uses Guix :-). Hopefully I can catchup with the slides. <Jorge[m]>Hola, donde puedo leer como selecciona Guix los paquetes ? <Reventlov>Hello. How can I "install" a package I created (contained in foo.scm) inside a profile (using a manifest file) ***daviwil_ is now known as daviwil
<ulfvonbelow>Reventlov: if foo.scm is in the guile module search path, just add (use-modules (foo)) to your manifest and then add the package to the manifest's package list. If it's not in the guile module search path, use (load "/path/to/foo.scm"). If foo.scm doesn't define a variable to hold the package in it, but just returns it as the last expression in foo.scm, then 'load' will return it too. <flypaper-ultimat>Reventlov: either specifiy the path to directory containing foo.scm to -L of the guix package command, or better, create a channel (a git repo) with that file, and add that to your channels.scm ***taiju_ is now known as taiju
<tschilptschilp23>does the form '((guix licenses) #:prefix license:)' actually have a technical implication/benefit, besides having to write '(license license:gpl3+)' instead of '(license gpl3+)'? <acrow>tschilptschilp23: Sometimes symbols for licenses conflict with other symbols. This happened to me recently for 'openssl. So, the license prefix prevents this. <acrow>Maybe prevents is too strong but it helps enough to be a common practise. <ulfvonbelow>if you were told that one argument to symlink was named "source" and the other was named "target", which would you think names the file that gets newly-created? <tschilptschilp23>I just changed a bit of code, and changing to that syntax seems to actually prevent guix from issueing a warning about 'multiple imports of zlib' (from guix licenses and gnu packages compression), when using zlib as an input. neat. I'm pretty sure I saw this every time when spawning that environment until right now. <dirtcastle>i chrooted into guix from arch linux just like how it was instructed in troubleshooting tips in guix manual. I can't use ls , nano or cat tho. I can use only guix system , guix home so far. is this normal <Luk6655>Does anyone know how to specify a version of a package in another package inputs? Normally we have (inputs (list bash python-pytorch)), however there are two versions of pytorch and there are both in guix. This (inputs (list python-pytorch@1.11.0)) doesn't work btw. <rekado>dirtcastle: check the value of the PATH environment variable <rekado>dirtcastle: inside the chroot you may need to set up the PATH to point to a location providing coreutils and nano, and whatever else you may need <jonsger>Luk6655: I guess one of them is named python-pytorch and the other maybe python-pytorch-1.11 <Luk6655>jonsger: both are named python-pytorch, just different version <jonsger>its the name behind "(define-public" you should use, have a look in the source code <rekado>Luk6655: you can only specify a package variable as an input. <rekado>the module (gnu packages machine-learning) contains the definitions of Pytorch <rekado>python-pytorch is at version 1.12.0, and python-pytorch-for-r-torch currently is at 1.11.0 <rekado>these are the variable names you would use in a package definition <Luk6655>yes it does, indeed despite having the same name python-pytorch 11 uses define-public python-pytorch-for-r-torch <rekado>the “name” field is for the command line <Luk6655>ok, so in more general sense, there is no way to specify the version (or perhaps another variable) in inputs, correct? <rekado>correct, version numbers don’t mean much in Guix. <rekado>version strings are only a tiny part in describing a piece of software <dirtcastle>rekado: How to do that. should I do that individually for each package? <ulfvonbelow>I mean, specifying a package inherently specifies its version. <rekado>Luk6655: Guix takes the view that *everything* that goes into a package is potentially relevant, not just the version string of the leaf node. <Luk6655>I have various versions of packages that I need for development, they are all present in my custom channel, so basically I should use different names for each version, right? <rekado>so if you want a different version at any point in the dependency graph you define a package value and bind it to some variabe <ulfvonbelow>yeah, usually there's a "default" guile variable that holds the most-up-to-date package, and variants are named a bit differently <ulfvonbelow>so there's something like some-package and then an older version might be bound to a variable some-package-1.15 <two[m]>hi, what would happen if i apt removed guix? <two[m]>would guix be removed or its installer? <rekado>Luk6655: you can also use (specification->package "this@1.2.3") <ulfvonbelow>though note that specification->package won't create the package for you, just search existing bindings for one with that name and version <ulfvonbelow>so you'll have to define it in a public variable somewhere either way <jonsger>two[m]: I would assume that the guix binary from /usr/bin/guix will be removed and everything else in the .deb package. But if you at least run `guix pull` once I think you wont remove the guix you are actually using :) <two[m]>gonna autoremove guile-3.0 guile-3.0-libs guile-bytestructures guile-gcrypt guile-git guile-gnutls guile-json guile-lzlib guile-sqlite3 guile-ssh guile-zlib libc-dev-bin libc-devtools libc6-dev libcrypt-dev libexporter-tiny-perl libgc1 libgcrypt20-dev libgit2-1.3 libgit2-dev libgpg-error-dev libguile-ssh13 libhttp-parser-dev libhttp-parser2.9 liblist-moreutils-perl liblist-moreutils-xs-perl liblz-dev liblz1 libmbedtls-dev libmbedtls14 <two[m]>libmbedx509-1 libnsl-dev libpcre16-3 libpcre3-dev libpcre32-3 libpcrecpp0v5 libqpdf28 libsqlite3-dev libssh-dev libssh2-1-dev libssl-dev libtirpc-dev now! <jonsger>yeah those are dependencies from debian for the guix .deb package <zamfofex>I’ve been working on the npm importer thingie, and the script I have failed after nearly five hours with ‘HTTP download failed: 300 ("Multiple Choices")’ because an npm package <https://github.com/vega/vega> has both a branch and a tag with the same name. (v5.22.0) 🙃 😭 <two[m]>just had to change /usr to /var/guix/profiles/per-user/user/current-guix in the daemon service <two[m]><jonsger> "what does `which guix` says?" <- /home/user/.config/guix/current/bin/guix <two[m]>Computing Guix derivation for 'x86_64-linux'... | <two[m]>substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 0.0%guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function. <two[m]>guix pull: error: `/gnu/store/mhqwphnns5js5lr61fkisqkwsm7b7gsj-guix-command substitute' died unexpectedly <Luk6655>does anyone know how to set an environment variable for the cmake-build-system (to be seen during the configure phase) ? <Luk6655>I could add a phase before configure and use setenv, but will those env variables persist to next phase? <ulfvonbelow>but if it's something that could also be passed on the command line, there's always configure-flags <andrzejku>hello, how to use search-patches if the patch is a gz file from different link <vivien>Luk6655, if it is a Makefile variable, you can also pass it to #:make-flags <two[m]>hi, i've uploaded translations a few weeks ago, could you merge them please? <two[m]>* uploaded translations to weblate a few, * merge them to git please? <Luk6655>it looks like this in CMakeLists.txt: set( SOMELIBROOT $ENV{SOMELIBROOT} CACHE STRING "SOMELIB installation directory" ) <Luk6655>so I believe I need to set the SOMELIBROOT variable (or patch the CMakeLists.txt) <vivien>Either way you would need a new phase, so better do what the devs intended <unmatched-paren>andrezejku: the roots of every channel, along with gnu/packages/patches, are searched for patches <unmatched-paren>so just uncompress the patch, put it in one of those locations, and do ``(origin ... (patches (search-patches "my-patch.patch")))'' <awefawefawef>where is the install script for guix? I want to find what it does so I can manually replicate it. I only installed the EXWM wm but now want to enable more... <awefawefawef>also when I'm running `sudo guix system reconfigure config.scm` it gets stuck (maybe?) and I'm not sure why or if it's stuck (after installing bootloader) <tschilptschilp23>when I use inherit in a package definition, how can tell the inheriting package to use another version than the parent? The newest python-cython, which is needed for the newest python-numpy builds nicely, but python-numpy does not pick it up. I'm trying with this definition: http://paste.debian.net/1254209, but the backtrace tells me that python-numpy fails because it still tries to pick the python-cython from guix (well, <tschilptschilp23>python-numpy-next and python-cython ARE pretty new, I'm just playing around). Sorry for my rude scheme, it's the first time I try 'inherit'. <mbakke>tschilptschilp23: you probably need (native-inputs (modify-inputs (package-native-inputs python-numpy) (replace "python-cython" python-cython-newest))) <tschilptschilp23>awefawefawef: it can happen that after 'guix pull' your computer will start building certain packages from source, if those are not readily available as substitutes. This can feel pretty much like 'stuck'. eg my laptop dies if big packages like ungoogled-chromium are not ready when I reconfigure. gimp will also take about 2h until things are finished. Clearly I can not tell, if that's the case with your config, but it's somethin <antipode>tschilptschilp23: In such situations, you at still get build output, no? <antipode>awefawefawef: There is no 'install script' except for more Guix code. <tschilptschilp23>antipode: with gimp yes, with ungoogled-chromium the reconfigure kills my RAM and I stay on the old configuration <awefawefawef>antipode there is a 'graphical' install process when you install guix <antipode>I suppose you could look at the source code of "guix system reconfigure", in guix/scripts/system.scm IIRC <antipode>awefawefawef: This 'graphical' install is a bunch of Guix source code. <antipode>The source code of the installer is in gnu/installer.scm and gnu/installer/... <antipode>I thought you already had a Guix system installed, no? <antipode>awefawefawef: Why would it be in the manual? <antipode>It's the source code (implementation details) <awefawefawef>because if I choose to install or not install something based on an abstracted process (that generates code), I'd like to know how to reverse or apply that process afterward based on what I do in the graphical install <antipode>Would you like to know how to uninstall Guix System? <awefawefawef>I use xinit normally and it seems way more straight forward... <antipode>IIUC, you already have Guix system installed. I must recommend against running the installer again, that's sheer inefficiency. Instead, I recommend just modifying your configuration (replacing gdm by something else) and doing "guix system reconfigure". <awefawefawef>yeah, I wouldn't want to run it again, I would want to see 'this part adds this code', etc. so I can go through optionally doing the stuff it does <antipode>If with "go through", you mean: "look at the source code for how things are done", see most of the gnu/ subdirectory (except gnu/packages), and guix/scripts/system.scm and guix/scripts/system/reconfigure.scm. <antipode>However, it might be easier to paste the latest output of "sudo guix system reconfigure config.scm" (paste.debian.net), such that someone might recognise what's going on <awefawefawef>this is so confusing... /gnu/store is the only directory I see starting with /gnu/, and <hash>guix/ has doc or language files only... I never know where to go to find the location of anything... <awefawefawef>many guix-<something> packages (and duplicates w/o versions...) <antipode>The source code can be downloaded with "git clone", as mentioned somewhere in the manual. <apteryx>how can I extend polkit-service-type with a rule that isn't part of a package? I tried a computed-file gexp, so far getting: In procedure program-code: Wrong type argument in position 1 (expecting PROGRAM_P): #<<computed-file> [...] <antipode>awefawefawef: There will end up a few copies there, but I really recommend making a git clone. <antipode>Alternatively, if you don't want an additional copy (network IO savings?), then you can look in ~/.config/guix/current/share/guile/site/3.0/ . (With the caveat that that directory is an implementation detail, no guarantees it will be kept in future versions of Guix) <awefawefawef>the ../scripts/install.scm is too small to be the graphical installer <awefawefawef>ok you were right, guix/gnu/installer.scm... now wtf does it install nano... <antipode>awefawefawef: %base-packages-interactive in gnu/system.scm and gnu/system/install.scm <antipode>(Assuming you meant: where does it decide to install 'nano') <Reventlov>Small question: in a guix shell --container --network, I cannot type accented characters (such as é) <Reventlov>I tried putting glibc-locales in there put it does not change anything, is there something else I can do ? <antipode>awefawefawef: Because of no text editor were installed, then it's difficult for the user to modify the configuration to install a text editor. <antipode>(Not insurmountable, there's "guix shell nano -- sudo nano /etc/config.scm", but still rather inconvenient.) <antipode>I suppose that 'nano' could be removed, after all, 'ed' is installed by default and it's a text editor. <awefawefawef>I don't remember it asking for any... I would have picked neovim/emacs if the option was there... seems like something you'd expect from an installer... <antipode>awefawefawef: The installer is more for 'system' stuff, like the set of services and the time zone. <awefawefawef>if it's going to install a text editor I'd want to pick which one... and the root user does need one <antipode>You can easily add whatever text editor you like later, the 'nano' is just there to have some default that's relatively small and very easy to learn and use (compares to ed, emacs and vim) <antipode>You can also remove 'nano' (or even coreutils!) by overriding 'packages' and not making use of %base-packages <antipode>%base-packages-interactive can be found in gnu/system.scm <awefawefawef>yeah i gotta figure that stuff out... so if I see a variable how would I find it's definition/value <antipode>I usually (a) use "git grep -F" or (b) remember where it's located <antipode>awefawefawef: Beside providing a choice of text editor, should the installer also provide an option of which coreutils-like thing to use (coreutils, busybox, ???, none)? <antipode>I mean, the same reasoning seems to apply me (except for 'coreutils/busybox/...' being 'mostly' equivalent, while text editors are all quite different ...) <awefawefawef>maybe if the user selected advanced install? when I see it installed something I'm like 'what else has it installed', when, why, etc. <antipode>I suppose someone could extend the installer to allow such choices at installation time. <tom-1>Hello . Please advise matrix client . I care about end-to-end encryption, the ability to use the default tor or i2p. I have used element but it has issues like taking a long time to enter rooms and other issues. <pkill9>has anyone configured their guix to build things with musl instead of glibc? <pkill9>ignoring everythign that doesn't build/run properly with musl <zamfofex>pkill9: You might be able to use ‘--with-c-toolchain’ (from the command line) or ‘package-with-c-toolchain’ (from Scheme). *apteryx got past the earlier problems by wraping the list in a (lambda (config) ...). not sure why that's different from (compose list package) <zamfofex>pkill9: Hmm, I suppose ‘*-with-c-toolchain’ is mostly used for changing the compiler. Which you’d need anyway, since GCC and Clang are configured to use glibc by default on Guix. But it isn’t immediately straightforward, I suppose. <jonscoresby>I am struggling with pre-inst-env. Prefacing a guix command with ./pre-inst-env is suppose to cause the guix command to be run with my local checkout right? <pkill9>also out of curiosity does anyone use guix as a media centre, perhaps using kodi? <jonscoresby>Then say I change the hello package definition so that the description is different. If I run ./pre-inst-env guix search hello, the description is the same as in the normal repo <zamfofex>You need to run ‘make’ too. And also pass in ‘--localstatedir=…’ to ‘./configure’ <jonscoresby>Ok, Ill try that. Is there a reason that all of that info is not in the manual? It took me a lot of effort to figure out how to run the bootstrap and configure steps too. The manual just assumes that you have all the needed dependencies and it doesnt mention anything you just did. <jonscoresby>Oh wow. Lol. I stand corrected. I found the page after that one and somehow missed the "See Building from Git" link <Reventlov>(still searching for a way to be able to type accents in a very simple guix shell --container --network -m manifest.scm) <zamfofex>Reventlov: What happens when you try to? Also, does your terminal usually actually allow that normally? <Reventlov>and yes, my terminal allow that normally (but i'm not using guixos) <Reventlov>(debian host, guix installed from the binary install script) <zamfofex>Reventlov: Indeed, I can reproduce it with an empty ‘guix shell -C’ <zamfofex>It seems to be an issue regarding readline, at least from what I can see. <zamfofex>Maybe try setting up a ‘.inputrc’ on the container. <two[m]>i can't type my language in containers at all <two[m]>realine needs an environment variable but i can't figure out which one <two[m]>only way i could to that is to preserve the environment <Reventlov>(i'll try tommorow, gonna sleep right now, thanks for the hint) <zamfofex>(Without it, trying to type a non‐ASCII character is completely ignored.) <Kabouik>I am trying to install latest Remind with `guix install remind --with-latest=remind` but it fails because Perl is missing (if I understood correctly), do I need to usesome `guix environment` sorcery? Is that a typical step for --with-latest? <two[m]><zamfofex> "(Without it, trying to type a..." <- thank you! <lilyp>Kabouik: no, it's not, you have to actually type out a package description <lilyp>Kabouik: You're hitting the limits of transformations; if your package has a new dependency, then all bets are off <zamfofex>Maybe try ‘--with-source’. I can’t seem to get it to work with ‘--with-latest’ supposedly because of a GPG error. <Kabouik>I see, thanks. So in that case I guess Perl would be a new dependency indeed. Thank you. <ulfvonbelow>in theory we could add a --with-extra-input=<package>=<package-to-add> 