<cbaines>with that change, I'd hope ppc64le derivations would be computed, and once that happens, I can look at submitting builds for them <narispo>cbaines: okay!! will add that now!! *excited* :-D <lispmacs[work]>hi, something is confusing me: I'm running emacs-27.1 from Guix, and it clearly has an org-mode available, which gives version 9.3 when I run M-x org-version <lispmacs[work]>however, this appears to be separate from the emacs-org package in guix, which is at version 9.4.4 <lispmacs[work]>I see emacs-next also has org-mode built in but also the old version <kozo[m]>dftxbs3e: Are you a common lisp programmer? <cbaines>narispo, what's the exact system? Is it powerpc64le-linux or ppc64le-linux ? <dftxbs3e>cbaines, powerpc64le-linux because that's what Ludo committed initially but would've called it ppc64le-linux any day <lispmacs[work]>do other emacs users also get version 9.3 when they run M-x org-version? <luke-jr>how is the store hash produced, for bootstrap bins? (xz/make/bash/tar) <dftxbs3e>luke-jr, guix hash -r and for specifics I guess look at the code for that command <luke-jr>dftxbs3e: guix hash -r gives completely different hashes.. <dftxbs3e>luke-jr, I usually just rely on the "actual hash" vs "expected hash" in error logs <luke-jr>pi24r741hhr7axgsjvbg5bgmx7n9m5lv-xorgproto-2019.2.tar.bz2 vs 1fdink9hs0l4mfzx03p7rlbi55jd6cc6fqwmzmh6ia3gc9q2yrpr <luke-jr>dftxbs3e: knowing they're different doesn't help :P <luke-jr>gotta figure out *why* they're differnet <dftxbs3e>I know I just don't know here unfortunately *luke-jr wonders if he can make a bogus "substitute" to trick Guix to accept stuff <dftxbs3e>Scheme code is readable but agreed it's very different than the rest :-s <sundbry>maybe if we just reduce maximum file size to 2MB it will help you read scheme luke-jr <vagrantc>luke-jr: sets up a dangerous precedent ... :/ <luke-jr>vagrantc: but could just make all this work magically? :D <vagrantc>luke-jr: the hash of the file is not the same as the hash prepended to the file, no? <luke-jr>can I tell guix to find substitutes from a local dir? <vagrantc>magic historically requires making deals that backfire on their wielder <luke-jr>but the magic can go away after bootstrapping ☺ <luke-jr>vagrantc: what is the hash prepended to the file? <luke-jr>for `guix download`, it doesn't really know anything other than the file.. <vagrantc>luke-jr: that's the inputs used to generate the file <sundbry>in the file name is the hash of the derivation not the hash of the source <dftxbs3e>vagrantc, so hash of compiled Scheme derivation? <luke-jr>vagrantc: `guix download` doesn't know how the file was generated <vagrantc>the inputs that guix used, obviously not the inputs to create arbitrary files <vagrantc>i had assumed it used the URL to the file, but i'm not so sure now <vagrantc>so you just typed "guix download" and it guessed what you wanted to download? <luke-jr>guix download /tmp/guix-dl/xorgproto-2019.2.tar.bz2 <luke-jr>it imported it the same as if it had downloaded it, afaict <vagrantc>but i'll admit, i don't have a solid understanding of how guix download generates the hash used in the store item <vagrantc>but the hash in the store is not the hash used in guix ... two different hashes <luke-jr>the hash in the store is what guix uses to find the file <dftxbs3e>compiled Scheme derivation -> hash -> name in store <vagrantc>and if you run "guix hash [-r] /gnu/store/HASH-THING-VERSION.tar.gz" it will give you the nix-style hash of the file *luke-jr gets a sense that a fake substitute might be the better path.. <dftxbs3e>luke-jr, probably it's the guix-daemon that calculates the hash, so you don't have to read Scheme code to find out <dftxbs3e>it's passing algorithm, name, etc. to guix-daemon and the hash is not calculated in the Scheme code (expected, since that runs unprivileged) <sundbry>i dont understand what youre doing guix will recompile itself if you modify some super low level package like libc or mesboot or jemalloc which will trigger the whoel world to rebiuld from source <dftxbs3e>luke-jr, yes maybe if you explain what you are doing in full people can help you <dftxbs3e>like what commands you have run, with what output, etc. <luke-jr>dftxbs3e: setup guix, without running any binaries from third parties <sundbry>just change the description of jemalloc and install the package watch what happens <sundbry>ok how are you going to do that without an operating system <luke-jr>sundbry: no doubt it will fail because it wants bash,mkdir,xz,tar <dftxbs3e>luke-jr, you can't get rid of the bootstrap binaries until wip-full-source-bootstrap gets merged <luke-jr>dftxbs3e: I'm not going to get the bootstrap binaries. <dongcarl>dftxbs3e: He wants to bootstrap Guix from bootstrap binaries he compiled himself, even if it means changing the tree of hashes and not having any substitutes <vagrantc>and then you'll need wip-full-source-bootstrap-for-real once wip-full-source-bootstrap is merged, too :) <dftxbs3e>luke-jr, oh okay, so you want to reproduce the bootstrap binaries? <luke-jr>dftxbs3e: or just run the ones I have, either way <dongcarl>dftxbs3e: Yes, but from his own Gentoo install <luke-jr>if I need to recompile tar/bash/mkdir/xz again, no big deal <luke-jr>I suspect it would just work if I could add my existing ones to the store with a false store hash ☺ <sundbry>you should probably stop screwing around with hacking hashes etc and figure out how to write a package first <sundbry>then you could just write a package to provide gcc etc using your binaries <dftxbs3e>luke-jr, don't do that, instead, you can use make-bootstrap.scm to re-generate the bootstrap binaries. You need to find the exact commit that was used to generate those bootstrap binaries with gnu/packages/make-bootstrap.scm <vagrantc>luke-jr: fwiw, the filename passed to guix download affects the /gnu/store/HASH <luke-jr>vagrantc: just the name, right, not the path? <vagrantc>at least from some quick experimentation <vagrantc>and symlinks will resolve to the real file <luke-jr>is there a way to delete an object from the guix store/ <luke-jr>the official bootstrap binary doesn't get the expected store hash either :o *vagrantc wonders if the different store path is causing an issue <luke-jr>it was originally looking for /home/dev/guix/root/gnu/store/k1z4m06rl4l0mv8gvdykr2slhxjl250h-bash.drv <dftxbs3e>luke-jr, by the way if you want to reproduce the bootstrap tarballs for x86_64-linux or i686-linux you can use: guix build --target=i686-linux-gnu bootstrap-tarballs <luke-jr>if I guix download the official bootstrap bash, it gets /home/dev/guix/root/gnu/store/0la89mb2m118hck7y2ril8bx0xr21r20-bash <dftxbs3e>then you can replace the hashes to these in gnu/packages/bootstrap.scm <luke-jr>dftxbs3e: replacing the hashes is what didn't work <vagrantc>i suspect if you use a different store path, the hashes might come out different, as you have a cascading change of hashes <luke-jr>vagrantc: so it's actually impossible to install outside /gnu/store? <vagrantc>well, you'll get different hashes from some of the other binaries, as the paths to some of the bootstrap binaries get embedded ... but maybe i'm wrong here <luke-jr>I suppose I can setup a LD_PRELOAD to redirect it :/ <vagrantc>it's clearly not a well tested code path, at the very least <luke-jr>vagrantc: wait, but it was okay with xorgproto-2019.2.tar.bz2 … ? <vagrantc>well, if you build a simple C program, it will have /gnu/store/HASH-glibc-VERSION/lib/... embedded in it <dftxbs3e>luke-jr, replace what hashes, gnu guix calculates them for you if you change the file without the hash, you can then use that hash, if you write a gnu guix package to generate the bootstrap hashes it will give you their hashes outright, otherwise rely on the error <vagrantc>i might be mixing different issues, though <dftxbs3e>luke-jr, please explain precisely what you have done and the errors you're getting <luke-jr>I'm not getting an error as much as guix refuses to use that bash instead of the third-party one <dftxbs3e>luke-jr, do you have a local GNU Guix checkout? do you use ./pre-inst-env ? <dftxbs3e>the way to override bootstrap binaries is to modify GNU Guix's code, I am not sure you can tell it to get them from a local file, maybe with file:// URIs <luke-jr>dftxbs3e: I `make install`'d to a custom prefix <dftxbs3e>luke-jr, oh okay then do not install, you can work without installing <dftxbs3e>It's easier to iterate that way, modifying GNU Guix code along the way <dftxbs3e>You can run every command with --no-substitutes or simply do not trust any signing key for substitutes, it will not download any, but I recommend you keep /gnu/store <vagrantc>you sure it won't download bootstrap binaries? <dftxbs3e>It would download them, but you can easily remove all mirrors in the source code so it can't anymore <dftxbs3e>If you empty the list, or make it point to a local directory or URI, you are certain it will only get them from here if ever <dftxbs3e>Once full-source-bootstrap is here, I believe that will be much easier to achieve since there wont be any third party binary. Still can't find out how i686-linux bootstrap binaries were generated, still investigating. <dftxbs3e>Full Source Bootstrap already works AFAIK, it's just not merged yet <luke-jr>letting it fetch the file from localhost worked :/ <luke-jr>the URI is apparently in the store hash too <luke-jr>it seems the bootstrap blobs must not use the same download mechanism as everything else? *luke-jr wonders why gawk-3.1.8/COPYING is +x *shrug* <luke-jr>guix has a guile-2.0.9.tar.xz different from the official one? O.o <dftxbs3e>luke-jr, it doesnt really feel good expressing how annoyed you are in this channel, a bit accusatory to be honest. Full Source Bootstrap is ongoing work, if you want to participate, please do. And report binary blobs issues at bug-guix@gnu.org <dftxbs3e>And have a conversation with civodul (for historical knowledge) or OriansJ and janneke (for their investigations and work on full source bootstrap) about the bootstrapping, they may be able to tell you more. <vagrantc>so ... are the aarch64 substitutese being built again? i guess best way is to boot and start some updates :) <OriansJ>The bootstrap blobs are only: guile-static (being eliminated slowly) and bootstrap-seeds (kaem-optional and hex0) <vagrantc>dongcarl: i'll be getting access to some riscv64 hardware soon; i seem to recall you were interested in getting the guix port for that going? <dftxbs3e>OriansJ, they are trying to compile GNU Guix from their handmade bootstrap binaries set (they do not want to download any binary from online and want to reuse the ones from their Gentoo install) <dftxbs3e>They are not using Full Source Bootstrap yet AFAICT <OriansJ>dftxbs3e: fair and actively encouraged on the #bootstrappable side <OriansJ>which then runs MesCC to build TCC (which is then used for the rest of the bootstrap to GCC4.7.4 steps) <OriansJ>Now there is a little bit of cheating in Guix with the static guile running gash and gash-utils (and the use of generated files in a few places) <OriansJ>also the bootstrap binaries for Gnu Guix were hand made (individually toggled bytes if you want to be exact) <OriansJ>So I might have accidientally confused RMS when emailing and asking about the elimination of generated files in GNU. <luke-jr>OriansJ: am I making this harder on myself using 1.2.0? <vagrantc>wonder if i should patch the debian package to fix the gnutls build ... <dftxbs3e>cbaines, seems it doesnt keep substitutes for my branch for so long.. <luke-jr>guix install: error: cannot change ownership of ‘/home/dev/guix/root/gnu/store/56hrg4binmvl8vhcl6wwha64jh3hq30j-guile-bootstrap-2.0.drv.chroot’: Operation not permitted <luke-jr>oh, that's what the --disable-chroot is needed for I guess <vagrantc>oh, looks like python 3.9 is on core-updates ... i should test diffoscope against that branch <luke-jr>building /home/dev/guix/root/gnu/store/56hrg4binmvl8vhcl6wwha64jh3hq30j-guile-bootstrap-2.0.drv… seems to be stuck :| <luke-jr>dev 6902 0.0 0.0 0 0 ? Zl 01:43 0:00 [guile] <defunct> <entre-parentesis>The issue I'm running into is a build issue with the package because (from what I've gathered) I don't have the dbus development libraries installed (I'd be happy to share the exact error rust message, if it helps). <entre-parentesis>I have found the `dbus-c++` and `dbus-cxx` packages but am not convinced that either of them are what I need for building this package - i.e. equivalent to the `dbus-devel` package (for instance) on Debian. <entre-parentesis>Could anyone suggest if one of these are the packages I need or if I'm just missing something else? <lfam>entre-parentesis: Is it the 'dbus' package that you're looking for? <lfam>In general, in Guix, we don't separate out "development" portions of packages into a -devel package <lfam>Also, I recommend always sharing the error message. It can only help <entre-parentesis>thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Command { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"dbus-1\" \"dbus-1 >= 1.6\"", cause: Os { code: 2, kind: NotFound, message: "No such file or directory" } }', /tmp/guix-build-rust-system76-oled-0.1.5.drv-0/rust-system76-oled-0.1.5-checkout/guix-vendor/rust-libdbus-sys-0.2.1.tar.gz/build.rs:6:5 <lfam>I think the dbus package should satisfy that requirement. I would also add pkg-config as a dependency if you haven't already *lfam has to see what the difference is between dbus-c++ and dbus-cxx <lfam>I guess they are just different things, that wanted to have the same name <entre-parentesis>Okay, thanks! In that case, I'm assuming I'm configuring my package incorrectly, then. <vagrantc>'m guessing core-updates is not being actively built on the substitute servers? <lfam>I do recommend using the paste service to share your work-in-progress package definition <lfam>vagrantc: Only the "core" subset of packages *vagrantc wanted to test if diffoscope-166 basically depends on python 3.9.x <lfam>I don't recall where that is defined but it's extremely limited <vagrantc>maybe i should go back to my fallback plan of reverting the one upstream patch that i think breaks with python 3.8 <vagrantc>well, that seems to be going well, rather than tests erroring out and/or failing, i'm getting passed tests :) <entre-parentesis>lfam: Ah, yes... I messed up my configuration. I had `#:cargo-inputs` specified (which included "rust-dbus") but I forgot to include `#:inputs` (which would need to include "dbus"). Thank you, again, for your assistance. First package built! :) <awb99>I have some difficulty understanding the channel with all the patches. It seems for example that postgres and mongodb in the official main channel are 2 years old. But the patches repo is up to date. How would I use packages from the Patches? Adding the patches channel to my profile? Does it work like a normal channel? Or would I just have to select certain patches that are applied to the official channel? Thanks! <dftxbs3e>awb99, hello! what do you mean the patches channel? <dftxbs3e>Not as a way to run software, just review <awb99>There are 500 SCM files with up to date packages there. <awb99>Must be some way how to use them. <awb99>When official channel postgres is 2 years old .. then I want to run the patch.. <awb99>Then the review process is seriously behind time. <dftxbs3e>awb99, so basically if you want up to date postgresql, we basically need to review and merge the update in master, we don't always keep up <dftxbs3e>Yes, we are lacking contributors but still progressing steady <awb99>Contributors seem to be submitting lots of patches <awb99>The patches are not being merged. <brendyyn>yes the project is in that state. we cant be harsh and demanding towards volunteers, but thats how it is. need more reviewers <awb99>So I would have to clone the main Guix repo and then git Cherry pick the commits I like? <brendyyn>what do the reviewers need that they cant do by just downloading the patches and testing them? <dftxbs3e>awb99, yes you can do this, but as for postgresql, I think it's up to date <awb99>I have seen similar delays with most patches in the link above <brendyyn>there are multiple versions of postgresql available <dftxbs3e>brendyyn, that takes time and needs human intervention, while contributors could be guided by automated tools for example testing that dependents work and reporting issues <brendyyn>id like to make some small bug bounties for merging contributions. what would be the best service for doing this? <awb99>Multiple versions in the main channel <dftxbs3e>speaking of which, postgresql 13.2 was just out today <brendyyn>awb99: people enjoy adding new things more than updating old things or reviewing other peoples stuff, so thats how it goes. i wish we could get donation money to fund someone doing this important boring stuff <dftxbs3e>I think we instead have to make it funnier to review things <dftxbs3e>People don't like it because it's a repetitive and under-optimized process <awb99>Or patches are first moved to a unstable channel. And then somehow it has to be tracked how many people use the dev packages. Atvs threshold one could roll to stable automatically <dftxbs3e>awb99, I think two channels for "well-maintained" vs "left behind" would be great <awb99>Also what I think is missing is a list of public channels. <dftxbs3e>But we need reviewing always because the software provided can't be mislabeled or straight out malware <awb99>I had to google as few days to find channels <dftxbs3e>If you know any useful channel, please share them there!! <awb99>It is very easy to search for packages, but very difficult to search for channels <dftxbs3e>Yes, let's index all the third party channels in the awesome-guix list! :-D <dftxbs3e>welp I am hesitant to index the non-free ones though, because it's best if this list can be shared on the official communication channels :-D <dftxbs3e>Making a channel with no guarantee whatsoever that takes everything from guix-patches is a very good idea though <dftxbs3e>I am not sure it is possible to do it just from the top of my mind but definitely a good idea <dftxbs3e>cbaines, what do you think? Turning your guix-patches repo into a channel anyone can use? <dftxbs3e>It would need clear separation in the GNU Guix UI, because that's untrusted code execution basically <dftxbs3e>Maybe there's a way to do "sandboxed channels" <dftxbs3e>I am going to update postgresql to 13.2 :-D <awb99>I am pretty new to guix. I see it's huge potential. Now I am thinking how I can actually start using it. And so one of my first steps was to install all the stuff I normally use and then export the manifest. <awb99>And where I struggled was that a lot of stuff I am using right now is mainly in patches. <awb99>For data science a lot has been done is some of the channels that I posted above. <awb99>It is just not widely known that it is available. <awb99>I develop GitHub.com/pinkgorilla <awb99>I develop a notebook in clojure that can run also python and R via clojure <awb99>Database and storage is what gets used inside <dftxbs3e>And how exactly you want to use GNU Guix there? <awb99>Our dockerfiles would be a target to replace them by guix <awb99>Developing with Guix would also be Better <dftxbs3e>If you can make an exact list of dependencies I can try to help <dftxbs3e>And you should definitely learn to package things in GNU Guix <awb99>Docker Images are a pain in the ass to develop <dftxbs3e>Just look at the existing packages and copy things over as you need them, also ask me <awb99>This is a fantastic offer!!! <dftxbs3e>Can you write down a list of patches that you would need reviewed? <dftxbs3e>Usually when people come to ask for things they have a bit of a bad attitude towards people here, I am really happy to find someone friendly, easy going, and enthusiastic! <dftxbs3e>terpri, is it a money problem you think? <dftxbs3e>The financial situation is different with crypto-currency projects, since they are money themselves :-P <dftxbs3e>And the GNU Guix project has money, just not for employment unfortunately <terpri>dftxbs3e, responsding to funding ideas above mostly. i haven't thought about it much in relation to guix <brendyyn>somehow i ran out of memory. htop says 26GB is being used but then there are no processes using any more than 1 or 2%. so confusing <terpri>how credible the bounty site is* <brendyyn>its all in green in htop so that means user application? <terpri>snowdrift.coop might be promising in the future, although it's basically in alpha right now (hosted by hcoop.net of course :)) <awb99>So I am working on my developer laptop (running fedora) and use Guix currently only as a package manager. I am beginning to install stuff I need via guix. And then I am removing the apps that work via Guix from my fedora dnf package manager. <dftxbs3e>I run on GNU Guix System myself, but a Fedora user myself as well <awb99>I started with this approach because I need nonfree drivers and I am not yet there with the iso image I am building with nonfree drivers. <awb99>Fedora selinux made lots of problems. <dftxbs3e>Yes that's the pain point, rules arent written correctly, unfortunately I can only suggest: "sudo setenforce 0" <terpri>yeah i don't think guix is ready for selinux, though i could be wrong <awb99>What I am concerned is that I sort of mix using fedora apps with Guix apps. <dftxbs3e>I don't understand SELinux rules so well yet <terpri>besides my main Guix System workstation, i use in on a laptop alongside debian with no issues <awb99>Does the Guix environment feature help me with this? <dftxbs3e>awb99, mix in what way? You mean you would want to test if GNU Guix things work on their own? <dftxbs3e>You can basically define a manifest and invoke it with guix environment --pure <dftxbs3e>There you have a guarantee things works on their own then <awb99>So then all search paths and all environment variables would be changed to the ones in the Guix profile? <terpri>also --container and --share=$HOME=$HOME (and similarly sharing r/w, or exposing r/o, other paths) might be useful <terpri>...and -N for containers that need network access <awb99>And how would I go back to my normal settings? <dftxbs3e>awb99, it spawns a subshell, just CTRL-D <awb99>Just close the terminal Session? <awb99>This little fact has been hiding in the docs. <dftxbs3e>You can also directly spawn the program you like with: guix environment --pure --ad-hoc jq -- jq --help <dftxbs3e>The documentation is a bit lacking I think yes <terpri>and with --pure, you might need to preserve some env vars with -E (e.g. $DISPLAY) <dftxbs3e>On GNU Guix System it's handy because it happens a [env] to the prompt so you know you are in an environment <awb99>Is there a zsh plugin for Guix? <awb99>So in a way using this approach is similar to editing a dockerfile and then running an interactive terminal Session <terpri>(info "(guix) Invoking guix environment") shows how to change the prompt on foreign distros (it's just based on $GUIX_ENVIRONMENT existing) <dftxbs3e>awb99, also nothing prevents you from writing package definitions in your environment manifest yourself, you can take those package definitions from guix-patches as well! <awb99>The environmental manifest I the one where I add the custom channels? <dftxbs3e>awb99, well you can also define channels in there with an inferior AFAICT <dftxbs3e>the environment manifest is just a Scheme code file that evaluates to a list of packages to include inside the environment <awb99>(specifications->manifest '("emacs" "frozen-bubble" "git")) <dftxbs3e>awb99, with some uses at the top, something like that yes, not sure about the specifics of the syntax but it has to be a package or list of packages as the evaluation result <awb99>Are there two files (environment + profile) <dftxbs3e>awb99, I think profiles are just another manifest <dftxbs3e>They can be used in either situations, I think <awb99>And all the file references are relative to the current directory? <dftxbs3e>awb99, You'll have to test that but probably. I havent played that much with manifests yet. <awb99>In some docs I found files in ~/. and in others they are working in a local guy repo that keep all the SCM code. <awb99>So I am a little confused about this differences. <awb99>If I understand the philosophy then whatever I am working with via Guix cli is sort of manipulating the current profile/Environment <awb99>But I can sort of load all I want from disk from a local folder. <awb99>So If I do quick Tests in the cli then I can rollback etc. <terpri>or *a* profile (e.g. guix package -p $PROFILENAME ...) <awb99>And if I want to save it to my git repo then I export it either via the repl or via Guix command. <terpri>yes, as long as you don't mutate files explicitly shared with the environment <dftxbs3e>yes, with guix package --export-manifest <dftxbs3e>I don't know what you are comparing it to exactly <awb99>So I should save Profile.scm and a environment.scm ? <dftxbs3e>You can do everything with a single manifest <dftxbs3e>Inferiors allow you to fetch channels, then you can use that inferior to lookup packages in channels from your manifest and return them <awb99>But the Guix cli exports me either profile or Environment or channels? <dftxbs3e>It exports a manifest, it can be used anywhere it asks for a manifest in the GNU Guix CLI <terpri>a manifest listing the packages in the current profile, to be clear <awb99>Interiors? I did use 'cat ~/.config/guix/current/manifest' to shows all channels that I am using <terpri>and an environment is an ephemeral thing (just a process tree/container/whatever) ***sneek_ is now known as sneek
<terpri>inferiors, which you can (i think) define in the manifest file <dftxbs3e>inferiors can reference any channel or older versions of GNU Guix (up to a certain point because it needs support code in the version you try to use I think) <awb99>Only lisp makes my head explode like this :-) <awb99>Completely abstract concepts <awb99>That make the head explode until it clicks and everything is clear. <dftxbs3e>I am new and learning to Lisp-y things as well, but don't you do Clojure? <awb99>I am struggling to understand the way guix works. <dftxbs3e>When replacing your Dockerfiles, do you also mean to keep the isolation? <dftxbs3e>I see, so you can also generate docker images <awb99>And each web Notebook user gets a dedicated docker image <dftxbs3e>It does not support OCI images yet I think, but that wouldnt be too hard <awb99>I thought they are qemu images? <awb99>I am so happy I started playing around with it. <awb99>I already have been testing nix. <awb99>But with lisp language this is another level. <dissoc>i need to use a binary provided by coreutils in my system's config.scm file. do i need to include coreutils as a package? <awb99>It's a little sad that the desktop customization of guix has not yet started really. <awb99>What I mean is that there are amazing beautifully made desktop (KDE/gnome/xfce/i3/away) distros out there. <awb99>And with guix one can be happy that xfce is somehow working at all. <dissoc>it's also included with base-packages so I think i can just use that <awb99>I guess that any kind of distro creator would be able to do their beautiful customization much easier in guix. <terpri>how so? by customizing packages (with "inherit") and the like? or maybe just creating meta-packages with matching themes, etc. included? <dftxbs3e>terpri, I think a configuration interface somehow <sundbry>hey fellas does anyone know the function thats the equvalent of #$(file-append package "/bin/whatever") OUTSIDE of a gexp? <sundbry>I want to get the path to a programand pass it as a configure flag <brendyyn>i think you neet (assoc-ref inputs "out) <terpri>gnome is good enough for me, but i do sometimes miss tinkering with wm configurations, setting up clocks and widgets just so, etc. <terpri>i'd like to get a real GNUstep environment running under guix someday, both for fun, and i need it for guile-emacs testing anyway :p <terpri>heck, maybe even CDE now that it's free <sundbry>never mind i think what i was trying to do was too much of an anti-pattern <ryanprior>dftxbs3e: Docker images and OCI images are the same thing <dftxbs3e>ryanprior, there's two formats, legacy docker and OCI <dftxbs3e>I don't think GNU Guix supports multiarch in its images for example, one feature of OCI images <ryanprior>Hmm, interesting. Docker has used OCI images by default for some time. <ryanprior>dftxbs3e: sorry for correcting you unnecessarily then, it would be nice to bring Guix up to the state of the art. ***MidAutumnHotaru5 is now known as MidAutumnHotaru
<dftxbs3e>iyzsong, hey! how are you doing today? :-D <iyzsong>dftxbs3e: hello, i'm fine! finding some guix patches and issues to work on :) <dftxbs3e>What do you think about my request for commit access? I'd love to spend my days reviewing stuff like you! :-( <iyzsong>i think that should be great, I'm in, what could I do for you, reply to some email? <dftxbs3e>iyzsong, super cool! well I will need to email some mailing list and mention you so you can reply with a signed email! <iyzsong>dftxbs3e: sure, I support your application. glad to help! <dftxbs3e>Thanks a lot! I will prepare the email now! I need to setup some signing stuff. You will need to sign your email too. *dftxbs3e fires up the manual <dftxbs3e>iyzsong, 1. Find three committers who would vouch for you. You can view the <dftxbs3e>of them should email a statement to <guix-maintainers@gnu.org> (a private alias for the collective of maintainers), signed with their <dftxbs3e>iyzsong, my email is: lle-bout@zaclys.net by the way <wonko_the_sane>Is there no .onion for git.savannah.gnu.org only for ci.guix.gnu.org ? <PurpleSym>Is it somehow possible to emit Guile comments in a package importer? (i.e. the printed package has comments on certain lines) <iyzsong>dftxbs3e: yeah, I had sent the email, hope I did it right.. <dftxbs3e>iyzsong, thanks a lot! :-D Sending mine now! <dftxbs3e>Just saw a PowerPC 64-bits related patch there! <cbaines>yeah, I'm looking at submitting the builds <cbaines>I need to change the database schema so it's fast to work out what the valid system values are, but for now I've just added an entry to the list in the code <cbaines>I'm deploying that now, and afterwards, I should be able to submit builds <cbaines>currently, I don't think there's a way in the Guix Data Service to compare build status across architectures, like find packages that build on x86_64-linux but fail on powerpc64le-linux, but that might come in useful maybe <dftxbs3e>cbaines, by the way last time I told you about sending info about builds to the mailing lits, you told me "added", what did you mean exactly? Since I've seen no automated follow up to any bug about successful builds for example. <cbaines>My longer term plan for things like notifications is to get the Guix Data Service sending out a stream of events, and then support subscribing to those via an intermediate service <dftxbs3e>cbaines, maybe integrate into mumi's or debbugs UI without spamming automated messages to the mailing list? Well on the Linux mailing lists for example, they send out automated emails from some build farms to patch authors. <leoprikler>Can someone fix our docs? db6b9d2f inadvertently broke `guix pull` without itself being related to the error message. <dftxbs3e>cbaines, well it seems that substitute problem came back <cbaines>So, are you saying the agent is trying to substitute a dervaition, and that's failing? <cbaines>If so, what command line arguments are being passed to the agent? <dftxbs3e>cbaines, it also happens when I do any build with guix unless I use --no-substitutes <dftxbs3e>I can't extract the error because it only prints the first line of it which is not helpful <cbaines>but first it would be good to know what command line arguments are being passed to the agent? <iyzsong>leoprikler dftxbs3e: fixed guix pull now, it seems that we are somewhat strict with @pxref.. <cbaines>dftxbs3e, I think that looks right... can you share an error that you're seeing? <dftxbs3e>cbaines, yes I added all keys, it's the error I sent you but I am confused how to get the full backtrace <avalenn>Is there any project to cross-validate substitutes servers ? <cbaines>avalenn, the Guix Data Service can tell you where output hashes match or differ between different substitute servers <dannym>cbaines: I'm "interested" in the sense of "I want to do actual work on core-updates and not hunt these things one by one"... <cbaines>dftxbs3e, right, I don't seem to have any problem substituting that derivation, but I also don't really have any good suggestions on how to find out why the substituter is crashing... <cbaines>dftxbs3e, the closest I've got, was to strace -f the guix-daemon, watch for the substitutor being started and talked to, and then try and replicate that outside of the guix-daemon <efraim>dftxbs3e: I built cmake-minimal with no problems on my wip-ppc branch with your glibc patch <dftxbs3e>sneek later tell marusich so efraim built cmake-minimal successfully with the glibc ldd patch, so good news! <dftxbs3e>cbaines, that's what I have been doing, trying to <dftxbs3e>cbaines, thing is, --query works with standard input, but with what protocol.. <dftxbs3e>cbaines, oh well.. I rebooted and it works. <dftxbs3e>cbaines, it's a bit slow not sure why but works! <dftxbs3e>cbaines, I am thinking GNU Guile is slower on PowerPC 64-bits (without JIT) <dftxbs3e>Especially because POWER9 is especially an SMP-heavy CPU, it is not the best at single core performance but it is very good at running many things in parallel <dftxbs3e>or it is the disk performance being a bit meh <dftxbs3e>cbaines, here's monitoring for one of the machines (the one hosted at my home): http://[2a01:e0a:2a2:1351::1ec]:19999 <dftxbs3e>I really need to take a look at these PCI-e 4.0 NVME M.2 SSDs and PCI-e 4.0 x16 to 4x M.2 adapters <pkill9>apparently nyxt browser supports webengine <awb99>I am reading about guix services. Is there a way to use them in guix package manager on foreign distro? Say to start a database and cron tasks whenever I run a profile? <awb99>Can this be done with guix environment --container ? <iyzsong>i think it's possible, with 'guix system container' <iyzsong>we don't have shepherd user services builtin now, so profile won't work, the guix services are for the 'system'. <pkill9>awb99: you can run shepherd as a user, i think that's what you really wnat <pkill9>hmm then again you can't use guix services with that <pkill9>so yea, maybe guix system container <pkill9>maybe there is a way to read guix services that use shepherd and run them with shepherd itself <gn21[m]>Hello, my default browser on trisquel and abrowser, but when I click on a link in telegram-desktop installed via guix opens the browser chromium also installed via guix. I would like to open in my standard browser. Thanks <awb99>Does shepherd run on a foreign distro? <runejuhl>damnit, wrong channel again. think I need to fix the colors in my weechat setup :/ <pkill9>awb99: you can yea, shepherd is just a program in a package <pkill9>or guix environment --ad-hoc shepherd <bqv>pkill9: webengine support is not complete, ne <pkill9>it says on the webpage it has webengine support <pkill9>it needs to say 'incomplete webengine support' heh <bqv>Almost all development has been on webkitgtk. I think webengine might just about build but probably not work <bqv>It's been mentioned in a few issues <bqv>Anyway, I think I will end up leaving nyxt, for emacs-webkit <bqv>One ecosystem is better than two <rekado_>(this is one of those cases where the metaphor breaks down. More ecosystems are definitely better for biodiversity than one.) *rekado_ does not like the term “ecosystem” when used for software <bqv>I meant common lisp vs elisp. <bqv>Having everything in elisp is demonstrably easier than maintaining an elisp config and a clisp config <bqv>Obviously diversity is good, I'm still glad nyxt exists. I just prefer not having to use a whole separate language <rekado_>I was only talking about the original meaning of the word “ecosystem” <bqv>Oh, in literal terms <pkill9>I want everythign to be configurable in guile <pkill9>so it's all one language including the OS <kondor>After long while, I am running Guix as an OS again. Can someone tell me how does one update packages inside `(packages ...)` section of the system configuration file. Is it enough to do `guix system reconfigure ...` after a pull? <pkill9>sometime I want to create a separate profile available to all users, that replaces the system profile <pkill9>well, replaces teh (packages) section of teh guix config <kondor>Oh how I like `(skeletons ..)` :D <kondor>pkill9 but, that separate profile then needs to be initialised by each of them <pkill9>you can change /etc/profile in teh system config <kondor>Unless you do this automatically for them as well <pkill9>so it would do that automaticlaly <kondor>I don't know, maybe a single system profile is enough for moi <pkill9>not sure if I could set up login managers to look for xsessions in that other profile <kondor>See, that's my beef with multiple profile setup <kondor>There"s always something to tweak <kondor>Texlive profile doesn't ralk to my emacs profile, fonts cannot be found from my browsers profile, etc <pkill9>idk, maybe you don't have XDG_DATA_DIRS set up <kondor>I do, i have an elaborate init in dot profile <kondor>It took me a while to figure all that out <pkill9>yea there is also schemas which only seem to work with dbus in .guix-profile <kondor>Now, I just can't be bothered :) <pkill9>do you keep everything in the default profile then? <kondor>My current plan is to have a global 'packages' profile to hold everything all users will need and a default profile for a particular user <bqv>Isn't that how it works anyway <kondor>Sometimes guix manual sounds lime the Anarchist Cookbook. <kondor>> Today, each individual's control over their own computing is at the mercy of institutions, corporations, .. <bqv>Come to think of it, I could use nyxt on my guix system <bqv>Since emacs isn't on there <brown121407>What's the official position on using #:skip-build? #t for Rust packages? I see the importer does it by default, but the manual says "we try to refrain from ... using #:skip-build? when possible" <luke-jr>pivoting: how do I get a SSH server on the official VM image? (not sure why it isn't just enabled by default..) <luke-jr>don't see any mention in the docs where the operating-system file thing is supposed to be <brown121407>luke-jr: I think the system config after installation is in /etc/config.scm <dissoc>im not familiar with the official vm image but you could create a vm image with ssh server <roptat>luke-jr, if you're lucky, there's a definition at /run/current-system/configuration.scm <roptat>you can copy the file anywhere else to edit it <luke-jr>ugh, why is it downloading everyting already installed? <roptat>luke-jr, I suppose that's because it's using a different guix package than the one that was used to build it <roptat>so some packages might have different versions/dependencies <roptat>the VM was built from a given version of guix, that can only have a package of guix for a version that's older than itself, so it installed that into the VM <luke-jr>why can't it package the same version? <roptat>also, the guix you have in the VM can only know about an older version of guix than itself, so you're also installing an older guix. Unless you run guix pull in there, you'll keep downgrading the VM <roptat>because a git commit is not predictable <roptat>so the best we can do is package a guix from the previous commit <Noisytoot>luke-jr: Because it's a new version of Guix, so the code is different <dannym>what's the difference between "string=" and "string=?" in guile ? <luke-jr>is this because the packages are mixed in with the package manager? <luke-jr>so how can I get the commit that the VM image was made with? <roptat>in /run/current-system/provenance, you should find the commit number <roptat>use it in "guix pull --comit=<the commit number you found>" <Noisytoot>Would it be possible to package the same version if the packages were separate? <roptat>if they were separate, I don't know which package set you'd get exactly, but I think you'd have a similar problem <roptat>luke-jr, it should contain something like (provenance (version 0) (channels ... (commit "...")) ...) <roptat>so maybe in /ran/current-system/channels.scm <roptat>wait, did your reconfigure succeed? <roptat>if yes, you want to look into /run/booted-system instead or current-system *kondor thinking out loud: isn't it better to create *package bundles* (a virtual package listing bunch of propagated inputs) than multiple profiles? Easier to combine these bundles together than different profiles. <jackhill>argylelabcoat: Yes, I use guix gopy over ssh. I assume it's not working for you. What goes wrong? <roptat>arg, how was that vm generated? :/ <argylelabcoat>jackhill, I get this error: guix copy: error: unknown error while sending files over SSH <luke-jr>guix pull doesn't let me put a tag name :/ <roptat>luke-jr, you can try and pull with this commit, if that's the official VM from version 1.2.0: a099685659b4bfa6b3218f84953cbb7ff9e88063 <roptat>that's the commit which is tagged with "v1.2.0", so it should work well for you <dissoc>argylelabcoat: can you ssh into it normally? <roptat>obviously, you can pull to something more recent, but you'll have to get substitutes or build some packages <jackhill>argylelabcoat: indeed that error doesn't reveal what's going on. What's the fill command line that you're running, and perhpas try with guix copy -v3 for more verbosity. <roptat>maybe the reason you're building is that you haven't authorized substitutes? <luke-jr>I just want to add a SSH server, without touching anything else -.- <roptat>yeah, but the VM doesn't come with the same set of packages, so you'll have to build something at some point anyway :/ <roptat>I'm not sure how to do it, but I'll send an email to other devs, see if they have ideas. Then, we should be able to propose VMs that won't need to rebuild anything <roptat>well, at least not rebuild what they already have <argylelabcoat>jackhill, can ssh, copying a derivation from a node12 package I created myself. command looks like this: guix copy -L $PWD node@12 --to=engineering@10.10.200.200 <luke-jr>I would have expected with Guix's design, it'd be difficult to make a VM image with an inconsistent package set <roptat>it's not inconsistent, it just doesn't know about the package set it's using <roptat>so it rebuilds another set of packages <argylelabcoat>jackhill, -v3 does not seem to give me any additional output <roptat>that are independent from what is already in the store <argylelabcoat>with --debug=4, I get it to say that it's "exporting path" and "starting agent" <roptat>I think the best way to fix that is to install an initial guix pull profile for each user that correspond to the guix profile used to build the VM <luke-jr>roptat: so there's *some* commit I could use, to avoid any package changes? <roptat>but you'll need to build that commit (or get substitutes for it) <luke-jr>would have expected v1.2.0 to be that commit for v1.2.0 images <>< <roptat>that should be the commit I gave you <luke-jr>that commit should already be in the image? <roptat>no, because it was on the system of the person who built the VM <roptat>but it's not needed to run the VM, so it's not in its store <luke-jr>so it wants to rebuild what it already has… why? <roptat>because it's a different version of what it has <luke-jr>why isn't that the version in the tag? <roptat>the version that was on the machine that generated the VM, but not on the VM itself <roptat>anyway, I'd like to treat it as a bug on our side, but pulling this commit should help you <jackhill>argylelabcoat, dissoc: hmmm, I think someone else is going to have to step in for help wiht the ssh authorization. I have mine set up with passwordless keys (perhaps bad, but I have a need for the copies to be automated sometimes). <dissoc>jackhill: i was under the impression it had to use ssh key and no password. that's how i used it <roptat>afk, but I hope we can fix it for the next release :) <jackhill>dissoc: since that's how I use it too, I didn't look any further :) <argylelabcoat>Do I need to publish my package specs to a public git and add that as a channel for `guix copy` to work? <jackhill>argylelabcoat: but keys without a password? No, I don't think so, copy should work on the level of store items. <argylelabcoat>I can also say that when I `guix archive --export > archive.nar` on machine A and on the remote machine do a `guix archive --import < archive.nar` I get a corrupt archive error <argylelabcoat>same package, but I make sure to do a `-r node@12` so that it grabs the libuv or whatever else is needed <ngz>Sanity check: "if let Some\\(version\\) = sys.get_version.+\n.+" should match two lines in a file, the first one starting with "if let Some(version) = sys.get_version", right? <argylelabcoat>I have no problem publishing my node-12 spec somewhere if that would be helpful in answering my question, I just haven't bothered yet <orbz>Hello! Have a problem with `guix-eval' from emacs-guix. *luke-jr recreates teh VM to make sure it wasn't past stuff bloating it <jackhill>argylelabcoat: another thing to check: you've authorized the signing key of the sending machine on the receiving one? <argylelabcoat>jackhill, yes, I copied the signing_key.pub over there and authorized it <luke-jr>roptat: does guix pull --commit actually tell git to only get what it needs for that commit? :x <luke-jr>just that one step pulls in 187 MB; would think it'd be much smaller <dissoc>argylelabcoat: ussing ssh from command line works with no errors? <jackhill>argylelabcoat: Unfortunately, I'm out of ideas. I was hoping that I could look at my working configuration and help, but there doesn't seem much to my configuration, it just worked. I do continue to think it's independent of the package definition, but since I don't know what the problem is, who am I to say :) <argylelabcoat>yeah, I can ssh just fine, no password prompt, I just am instantly over there, running Ubuntu 20 on both machines and guix at same commit on both <jackhill>argylelabcoat: oh! All my hosts run Guix System. I wonder if it's a PATH or environment issue, and it's not finding the right guix command on the remote host. <argylelabcoat>I see that if I do an archive of a C-header file (lame, but a test) that it's essentially a text file <argylelabcoat>I can't believe that scp would jack up a file like ftp used to <argylelabcoat>I'm worried that to be able to function, I'll have to do something awful and wrap a binary distribution of node@12 in a guix package with the copy build system <jackhill>argylelabcoat: yeah :/ Hopefully someone else will step in an save the day <argylelabcoat>jackhill, thanks for trying, I greatly appreciate the helpfulness of the guix community <orbz>The following string is working as expected using guix-eval-in-repl: "(use-modules (guix packages) (gnu packages emacs-xyz)) (package-home-page emacs-guix)" and returns a string of url (in guix repl). But with guix-eval happens this: <argylelabcoat>I'm hoping I get competent enough with this tool to be more of use to others <luke-jr>guix pull --commit=<v1.2.0> pulled in 1.4 GB of new stuff <orbz>Sorry for the language. More general description: expected same strings with code to work for both =guix-eval= commands, but it works only with guix-eval-in-repl <ejh>in gdm usually there is a cog graphic for changing desktop environments but I'm not seeing it in guixsd <ngz>I want to hack on the crate importer to fix a bug. I modified it locally. But when I want to test my changes using "./pre-inst-env guix import crate foo", I get a backtrace unrelated to my change. What is the proper way to test them? <luke-jr>roptat: while you're fixing issues with the VM image.. can there be *some* way (ideally just preinstall SSH server) to access it without a GUI? :P <roptat>luke-jr, yeah, that shouldn't be too hard ^^ <lf94>So yesterday I decided to look into Guix. Mind=blown. <lf94>The manual is super well done. Excellent work to whoever put it together. <luke-jr>roptat: well, the hard part would be communicating a SSH key to it safely ☺ <leoprikler>kondor: regarding virtual packages, that does not actually solve all problems, that multiple profiles solve <leoprikler>sure, you get easy environments and "simple" installations, but you still blow up the default profile <awb99>I am starting guix environment --container <awb99>And I want to run guile scripts I side the container <awb99>That load other guile scripts <awb99>I guess I need to set environment variables for that? <roptat>if you have guile in your environment, guix should set them for you already <roptat>just add --ad-hoc guile to get it in the environment <fpp>I've been trying to update some existing golang packages. Is there something in the works to amend the golang build process to incorporate the go.mod functionality? <awb99>I have guile in the environment <awb99>I essentially have a got repo that stores all my SCM files <awb99>And I want to load sub scripts in the container <awb99>Can I print out search paths? <fpp>In addition what are we to do with oddball licenses like that on go-google-golang-com-protobuf? <cage_>Hi! I am trying to learn how to make a package with guix, i wonder if there is a way to download the package definition files (guile code), any suggestion? <cage_>i would like to use one of those files as a starting point to write a new package definition file <brown121407>cage_: If you're saying you want to view the package definitions for existing packages, you can use for example `guix edit package-name'. <brown121407>It opens up the definition in your preffered editor. <cage_>brown121407, exactly what i was looking for,thank you! <cage_>pkill9, also useful hint, thaks! <fpp>Would it be appropriate to classify it as an expat license? or do we need another license type? That seems crazy. <brown121407>Is there a way to source "$GUIX_PROFILE/etc/profile" from the fish shell? <fpp>Maybe it's more akin to the giftware license. <ngz>fpp: this looks like expat to me. <fpp>ngz: Thanks, bsd-3 it is. <terpri>ejh, the cog doesn't show up in gdm unless you have multiple desktop environments installed (e.g. wayland gnome and x11 gnome) <jonsger>sneek: tell mothacehe is it inteded that a reconfigure with a cuirass-service creates a 'dbname=cuirass host='/ folder in your current directory? <sneek>mothacehe, jonsger says: is it inteded that a reconfigure with a cuirass-service creates a 'dbname=cuirass host='/ folder in your current directory? <lf94>Hm, ouch... guix environment guile install 600MB of dependencies. <lf94>I can't find it in $GUIX_ENVIRONMENT/bin... <roelj>lf94: You need guix environment --ad-hoc guile <lf94>Why? Isn't ad-hoc the default? <lfam>`guix environment guile` creates a development environment for working on guile <lf94>So then I should now do guix package -i guile <dissoc>has there been any effort to implement some MAC LSM in guix system? are there known problems to do so? <dissoc>like apparmor would be better because of X or selinux because of Y? <lfam>Does anyone know how to run guix-daemon from a development tree? <lf94>Check custom guix channel in the manual? <dissoc>i would image writing the policies for selinux would be interesting since the programs exist in non standard locations <lfam>I configured the build with "--localstatedir=/var --sysconfdir=/etc", built it, and then ran `sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild --substitute-urls=https://ci.guix.gnu.org` as recommended in the manual section Running Guix Before It Is Installed <lfam>Does anyone know how to make it work? <QsDDC>anyone knows how to disable amdgpu driver from GuixSD installation USB? <Noisytoot>brown121407: Or just: exec bash -c "source $GUIX_PROFILE/etc/profile; exec fish" <roptat>lfam, do you get messages from the daemon itself? <lfam>roptat: Only messages like this: "accepted connection from pid 30910, user lfam" <Noisytoot>brown121407: *exec bash -c 'source "$GUIX_PROFILE/etc/profile"; exec fish' <roptat>I don't think there's anything wrong with the command you ran to run the daemon, maybe a recent bug, related to the new code that provides hints for guix subcommands? <roptat>I don't know how you can debug that <lfam>Can you see if it works for you? <lfam>Maybe something is messed up with my environment <lf94>lfam: you tried with a custom channel? <lfam>No, from a development environment <roptat>well, for me it fails even earlier: guix build: error: got unexpected path `Backtrace:' from substituter <lfam>roptat: Did you set the sysconfdir argument to ./configure? <lf94>lfam: try doing it with a custom channel. <lfam>--sysconfdir=/etc, so it can find the acl <lf94>I'm new to guix, but this seems to be "the way" to do it <lfam>lf94: I'm not sure that would help me work on the guix-daemon <roptat>I'm pretty sure I always set sysconfdir <lf94>I wonder if `guix environment guix` would help you :) <roptat>but I might have messed something up with the environment <lfam>roptat: I got that error message in some cases where I diverged from the instructions in the manual <lfam>I think, specifically, using `sudo` instead of `sudo -E` <lfam>But, that hints are problems related to the environment <lfam>But, overall, it doesn't really explain anything <roptat>ok, inside the guix environment guix, the daemon works correctly for me <lfam>Indeed, the environment must have been incomplete or broken somehow <lf94>lfam: I've probably run literally 3 guix commands total, I'm glad it helped <roptat>no wait, I forgot to stop the daemon from the system <lfam>Everyone has something to contribute! <lf94>lfam: the manual is super super well written <lf94>it's blowing my mind what is possible <lfam>I agree that the manual is good. But let us know if you find something confusing or incorrect <lf94>why does anything else exist to manage software <lfam>The eyes of a beginner are valuable and hard to reproduce <lf94>we need to rip apt out of debian and replace with guix <roptat>and it's still working after I stopped the daemon from my system <rekado_>lf94: there are downsides to the functional package management model; they may not matter to most of us, but they can be showstoppers for others. <lf94>The biggest downside currently for me seems to be space <lf94>is it though with substitutions? <rekado_>not everything, but some things that you’d expect to be fast aren't <roptat>there's room for improvement in guix, it's not necessarily a limitation of functional package management <rekado_>computationally it’s also way heavier than traditional package management <rekado_>(this one *is* a limitation of functional package management) <stikonas>depends on what is traditional... portage is quite slow <roptat>but functional package management doesn't need to use a constraint solver, so there's that :) <lf94>rekado_: you probably know best; at what point do you think functional package management is feasible ? In terms of CPUs/memory <lf94>(I guess storage space too) <lf94>Obviously in the days of 500MB drives, this is a no go <roptat>my slowest server takes a few days to run guix pull + reconfigure (but it's armhf, so very slow and doesn't have substitutes :/) <stikonas>if you don't have substitutes, that's definitely not practical <stikonas>substitutes probably need at least 4 GB ram... <roptat>with substitutes, you don't need any ram <lfam>lf94: I also think that Debian should replaced apt/dpkg with Guix :) To me the value of Debian is primarily as a social organization. The actual technology of dpkg is not that compelling anymore <lf94>So ram requirements dont matter <lfam>But, it's easier said that done :) <roptat>I have a server with 512 MB of ram, it works perfectly well <lf94>glad to see we have the same vision <lfam>Anyways, our best argument is to make Guix excellent! <lf94>Ok so RAM is not important then (mostly) <lf94>So what about cpu speed and storage <roptat>as long as you can get substitutes <rekado_>lf94: I’m using Guix on a i686 netbook with an Atom CPU and 1GB of RAM <rekado_>but I’d never *develop* on this machine <lf94>I imagine the common case is with substitutes if guix becomes more popular <rekado_>upgrades on that machine have to be well-planned, because substitutes might not be available and the machine might freeze <rekado_>(“freeze” is an odd way of saying “overheat”, hmm) <lf94>Im surprised there is no flag to say "stop installation if no subs" <roptat>for a server, 10 or 20 GB of storage are enough, for a desktop machine, you'd need 50GB or so to feel confortable (honestly I have a few big packages and 120GB are sometimes not enough) <lfam>One *huge* impediment to replacing apt/dpkg with guix would be that Debian doesn't use a monorepo. Packaging workflow is totally decentralized, for better or (definitely) for worse. Socially, that would be impossible to change, I think. It would probably destroy the Debian community to really push for a change on that <lfam>I just replied to your email <lfam>I'm open to tweaking the new plan <lf94>roptat: why the difference for server vs desktop <lfam>I do think my approach has some advantages and is based on experience <nckx>Oh good. I wanted to reply to your other mail but mu4e is being a little turd. <roptat>server doesn't need all the fancy graphics stuff <lf94>roptat: what if I run xorg on a server :^) <roptat>that's plenty, if the server doesn't store too much outside of guix <lf94>IMO these are good numbers <nckx>lfam: Anything you still needed/expected from me in the ‘security’ thread? I think I said all I wanted to say & will leave it at that if not. Even though I said I'd write more. <jackhill>for what it's worth, my experience with Guix on a 512MiB of RAM VM, was that I needed to enable swap for guix pull's "Calculating Guix derivation" step to succeed. <roptat>lfam, maybe your issue is a mismatch between the guix daemon and guix versions? <lf94>Do you think 1GB would be sufficient without swap jackhill ? <nckx>About branching, I'm interested in your experience and what advantages this rename-both manual-sync (as it seems to me) method would have. <nckx>I just can't open any mails at the mo. <lfam>roptat: Hm, not sure. It's working overall, now that I'm doing within the `guix environment guix` environment <jackhill>lf94: I didn't monitor it very closely, I was using the small VM to test other stuff, but probably, I don't think it ended up using that much swap. Naturally, it depends on what else guix is competing with for resorses :) <lf94>jackhill: fair. I would then say 1GB is "safest" <lfam>nckx: Regarding branching, people kept pushing to the wrong branch even after we merged the latest staging branch into master. I thought by forcing a choice between -frozen and -next, it would make people think about what they were doing and investigate the right course of action <roptat>I kinda remember before I added some swap to the server, I had to stop my nginx service for guix pull to complete ^^' <roptat>then I created a small swap file, and I haven't had to stop the server since then <nckx>lf94: One of the (not insurmountable) issues with a ‘--substitutes-only’ flag is that some profile derivations always get built locally, and there's no way to draw a line without doing so manually, which is a bit ick. Possible, though. <lfam>nckx: It's not really normal to only have a -next branch. That was something I ignored for a bit while we discussed improvements to the workflow <nckx>lfam: Git won't warn that you're creating a new branch unless I'm mistaken? <lf94>nckx: I think it'd still be good even if some manual intervention is needed. <lf94>Document it well, and all's good. <lf94>Then people like rekado_ can use it on their weak machines with less worry! <nckx>I meant manually marking some derivations as acceptable to build locally, and maintaining that. Not manual for the user. <rekado_>lf94: one way around this is to use a more powerful machine to build packages when needed. <nckx>Tab-completing both lf94 and lfam is fun and doesn't confuse HexChat at all 😛 <rekado_>the i686 could ask the more powerful x86_64 laptop to build things <lf94>rekado_: not everyone has more powerful machine. <nckx>lfam: To be clear, I'm suggesting never having a -next branch, and sometimes having a -frozen fork that receives no or minimal (fix-build-style) updates before being merged & deleted. So ‘staging’ is *always* the right place to push, unless you're fixing the build of staging-frozen (in which case, you're very aware that it's the branch you want). <lf94>I think it's important for software to be accessible to most hardware. <nckx>Does that not make sense? Maybe it does not make sense. <lfam>nckx: Yeah, it makes sense. But I think people will end up pushing their fixlets to e.g. "staging" instead of "staging-frozen" <roptat>it makes a lot of sense to me :) <lf94>I'm reading build-system/node.scm <roptat>it's like a package, but lower level <lf94>Ah that's why it's called `lower ... <nckx>lfam: I don't actually think so, since they'll be very aware that they are fixing the build of the frozen branch, but it seems we're not misunderstanding and just disagreeing, which is fine ☺ <roptat>if you look at other build systems, they do the same thing <lfam>Yeah, I think we are disagreeing <lf94>It doesn't seem trivial to write a build system <lfam>How about we try this plan for the next cycle and then see if it needs revising <lf94>lfam: you guys don't use gitflow? or similar? <lf94>devel branch with feature branches <roptat>lf94, in a package, you have build systems, descriptions, different types of inputs, ... a bag has no build system, but build instructions, only native and non-native inputs, some other minor differences <luke-jr>roptat: another thing: apparently the UEFI partition is AFTER the rootfs, which makes it a pain to resize the Linux one <nckx>Never heard of it but ‘devel branch with feature branches’ sounds like us. <roptat>luke-jr, I'd encourage you to send a bug report then :) <lf94>nckx: ah ok. it's the popularized term for it <lf94>of course many people "get to it" naturally <nckx>Although there are many methodologies that fit that description of course, ours might differ from theirs. <lf94>yep I find everyone adjusts it for their needs. <roptat>lf94, for instance, a package has implicit inputs through its build system, a bag has only implicit inputs (inputs + implicit after the build system added them) <lf94>roptat: not sure I understand because I'm not sure I see implicit inputs for the node.scm build-system <lf94>nckx: okie dokie, then disregard X) <lfam>nckx: Did you see my private messages? <nckx>lf94: I will not! Maybe we can learn, even if it's not 1:1 applicable. ☺ <lf94>X) well that's what I meant - it may be *similar* but not exactly the same. <lf94>To me the concept is more important rather than the specifics. <roptat>lf94, in (guix build-system node) you can see it's adding node to the inputs, and standard-packages (from (guix build-system gnu)) to the host-inputs <lf94>also guix build json and guix build union right? <roptat>those are implicit inputs, because they'll be present for the build, but are not declared in the package declaration <roptat>json and union are not build systems <lf94>not build systems but build inputs no? <roptat>they're build-side modules that can be imported <lf94>could you tell me what build-side means? I was wondering earlier X) <roptat>it's not counted as inputs, because it's part of the builder <roptat>when you build a package, the build occurs in an isolated environment, that's what I call build-side <lf94>like it also uses `gnu packages node` - wouldnt this be some sort of "hidden" input too? <lf94>"build-side module" then is...a module...built on the side...? X) <roptat>no, because that only comes from (guix build-system node) which is host-side :) <roptat>build-side module means a module that can be used inside the build environment <lf94>I hope you see my confusion <lf94>why cant I use any other modules <lf94>why are build-side special <roptat>they need to be "imported", with their dependencies <terpri>you can, you just have to tell guix what modules you'll be using in the build environment <lf94>Why even use the term build-side <lf94>Why not just say "modules to be imported" ? <roptat>but they can affect what's happening on the build-side, so we try to keep their number small <lf94>As a reader, it makes me think there is some corner of knowledge which is hidden by this term <roptat>in particular, if you import (gnu packages *) on the build side, you'd get a different has for every package every time you change something in them (even update of an unrelated package) <lf94>wouldnt that be because you used * ? <roptat>again, build-side = inside the build container <lf94>Is the term defined in the manual? <roptat>but if you import (gnu package node), the result could depend on its content, so the functional package management mandates we compute a different hash for the output <lf94>"build-side = inside the build container" explains it totally :) <rekado_>lf94: there are two separate worlds: the host side and the build side. The host side prepares code to be run on the build side. <terpri>for example with trivial-build system's #:arguments: `(#:modules ((guix build utils)) #:builder (begin (use-modules (guix build utils) (srfi srfi-1) (rnrs io ports)) ...)) <roptat>so if you update an unrelated node package, and import the module, the hash will change, for no reason <nckx>lf94: Because it matters *where* they are imported into, not that they are imported. And the ‘build side’ is that place, where things are built. No name is perfect but it is accurate. <lf94>roptat: it should depend on its content though I thought? <rekado_>think of there being a barrier between these two worlds; one side is the host side, the other the build side <rekado_>they must be kept separate for reproducibility reasons <lf94>nckx: yep, it makes more sense now that "inside the build container" was said <rekado_>this is a concept called “code staging” <lf94>"build-side modules" just feels like an "iceberg term", where there's a lot more to learn about "build-side modules" - get what I mean? <rekado_>you will notice when reading package definitions that some have an “arguments” field; the value of that field is not code, it’s actually data <rekado_>that expression is evaluated in a different world <rekado_>the code is split into separate stages <rekado_>this is not only true for the arguments field, but also for modules. <rekado_>some expressions refer to modules that are not available on the other side, so we need to also throw copies of those modules over the barrier <roptat>you might see guix build some modules-import and modules-import-compiled sometimes, that's it: it throws those modules over the barrier :) <rekado_>ensuring reproducible builds begins with limiting the amount of code that is available on the build side <roptat>(well, preparing them to be thrown over, I guess) <rekado_>and if we throw something across we need to be sure that it stays the same <lf94>That linked page is *super* useful <rekado_>G-expressions are deployment-aware S-expressions <lf94>I would maybe change the heading <lf94>Like I didn't know about this host-side build-side barrier at all, and I read most of the main parts of the manual ***Guest87973 is now known as guix-noob
<lf94>Will read later for sure :) <rekado_>it’s not something that comes up a lot when using Guix <lf94>not for regular users maybe, but users who want to build packages or support new languages? <rekado_>you can use Guix and write packages for it without knowing about code staging. <lf94>seems like something super important! <rekado_>it’s an implementation detail. An important one. But it’s not something a new contributor needs to know. <rekado_>case in point is that the “arguments” field does not make use of G-expressions at all. <nckx>$partner just snuck up behind my, called emacs ‘dark magic’, and left. Can't blame her... anyone else having ‘weird issues’ with Guix's latest mu package? <nckx>No breakage, just long random slowdowns. <lfam>That's an interesting question <lfam>I don't use mu interactively, but I have had some extreme slowdowns in the last week or two <lfam>Not with mu, but with other packages <lfam>`mu index` is still blazing fast for me <nckx>Thank you. Good to know it's not just me at least. <ngz>I have a question about hacking Guix. I want to fix a bug in the crate importer. So I apply some changes, add some (pk ...) around, but when I try ./pre-inst-env guix import crate whatever, I get unrelated errors. So, how am I supposed to check my changes? <ngz>(a video on how to hack Guix proper would be terrific, BTW) <roptat>ngz, well you'd have to fix these errors first <lfam>ngz: You might try `guix environment guix -- ./pre-inst-env guix import ...` <ngz>lfam: that's what I did. <lfam>Also, I remember that the importer might have some optional dependencies <lfam>Maybe --ad-hoc guile-semver <ngz>I get "error: string->semver-range: unbound variable" <lf94>Not sure I read, but can I rollback a `guix envirnoment` ? <ngz>It's not so much optional, then :) <lfam>It's optional for Guix proper ;) <roptat>lf94, a guix environment is temporary by default, so it doesn't have generations <lf94>Hm, yeah, let me rephrase. <lf94>How do I delete the dependencies `guix environment` downloaded <roptat>oh, "guix gc" will take care of that <lf94>I wasnt sure the garbage collector was suitable for that. <roptat>it collects everything that is not a gc root or is not (transitively) refered to by them <ngz>It works, thank you. <lf94>Would be useful to mention that in the manual <lf94>For sure you will get other "space conscious" users like me <roptat>wouldn't it make more sense to have that in "Invoking guix environment"? <lfam>I fixed the (related?) bug in xterm <lf94>Better question: how the heck can I contribute to the manual? :) <lfam>It's stored in doc/guix.texi and doc/contributing.texi <roptat>clone the repository, change the manual, create a patch and send it to guix-patches@gnu.org :) <lfam>Test your changes with e.g. `guix environment guix -- make doc/guix.html` <guix-noob>hi, is it possible for someone to help me with my config.scm? I recently installed guix and I wanted to make my xorg configured right so I tried to use set-xorg-configuration but it looks like I did it wrong. guix system configure suggests that I forgot a use-modules; unfortunately I don't know much scheme/lisp currently so I'm kind of flying blind <lfam>I guess I don't understand the relationship between screen and xterm. Do they share some code that makes them both vulnerable? <roptat>guix-noob, what's the complete message from guix? <lfam>guix-noob: I'm not sure, but try (default-user "user") <lfam>guix-noob: That would match the documentation for the code that isn't working <lfam>default-user (default: "") <lfam>It suggests a string, not a variable <roptat>guix-noob, ah sorry, I didn't you pasted the error too ^^' <guix-noob>hmm ok, now I'm getting error: service 'xorg-server' provided more than once <guix-noob>i guess it's part of %desktop-services and I need to remove from there? <apteryx>hmm, diffoscope is not being useful by raising a diffoscope.exc.RequiredToolNotFound exception but not telling me what that tool is. <lf94>guix has been around since 2012? <apteryx>yes, that's when Ludovic created the project <lf94>I wonder which, Guix or Nix, has the nicer code base. <roptat>guix-noob, sorry, I've tried a few things but I don't understand where that error comes from <lf94>my gut tells me it's probably Guix. I've seen too many posts about Nix complaining about documentation and seen Nix code.... <roptat>er... something is screaming in the room when I show blue lines in my terminal... <roptat>I mean if I scroll back a few line, it stops, and it gets louder the more blue lines I have <lf94>lfam: make doc/guix.html didn't do it <lf94>I'm inside the env but that isn't a build target. <lfam>fl94: Maybe you didn't build Guix itself yet? <lfam>It's definitely a target in the Makefile <lf94>Oh I need to build the whole thing - gotchya <lfam>No, but you do have the Makefile? <lfam>Maybe you only need to configure the build, not sure <lf94>Ah no, just Makefile.am (IIRC this is not an actual Makefile but some template) <roptat>oh well, it seems to do that when I have a wall of text in the terminal, not necessarily colored ^^' *lf94 runs `info -f doc/guix.info "Contributing"` <roptat>guix-noob, if you can't get an answer here, I'd suggest sending your questions to help-guix@gnu.org <lfam>Within the development environment, `./bootstrap && ./configure --localstatedir=/var` <guix-noob>thank you, I will try that if I can't get it running <lfam>Right, you can also build the info manual <lf94>Alright, running the bootstrap + configure <roptat>after fixing user -> "user", your paste looks good to me, I don't know what's wrong <roptat>guix-noob, unless you decommented the second slim service? that might be it <roptat>I don't think you can have two slim services at the same time <roptat>(or two login managers of any kind actually)( <guix-noob>with two slim services was how I copypasted it from the manual. I commented the second because I didn't think I'd need it. Anyways I uncommented and it had no effect <guix-noob> (eq? (service-kind service) gdm-service-type xorg-server)) <guix-noob>to remove the extra xorg-server in the same way i removed gdm but I suspect that doesn't make sense <lf94>doc/guix.texi:13246: @include: could not find os-config-bare-bones.texi <lf94>(After a successful ./bootstrap && ./configure) <lf94>I really did need to run `make` by itself firsnt. <lf94>So now I'm thinking how can I use Guix to replace my Ansible usage. <lfam>Oh yeah I forgot about the templates <lf94>I guess there is no really replacing configuration management <lf94>So for some complex website, it would be composed of my sub packages <lf94>then you can do guix packages -i mywebsite <lf94>but then for configuration you'd use ansible <lf94>(I suppose you'd also use ansible to invoke guix.) ***ece38 is now known as ece3
<awb99>Can someone tell me which Debugging tools are good? <awb99>I am writing my first SCM files <awb99>All info about current profile Container variables loaded modules vwiukd be good <roptat>usually, I just pk stuff to know what intermediate values are <roptat>it prints its arguments and returns them <roptat>like (+ (pk 2) 3) prints 2, and returns 5 <roptat>you can use it to check intermediate values <awb99>Can I see somehow which variables have been defined? <awb99>And name + version number of packages <awb99>And to see which variables are exported from a package or module <roptat>if you have a package object, you can use package-name and package-version <roptat>exported variables from a module are harder to get <roptat>but I think you're probably going too far... what are you trying to do, and what's the error guix/guile gives you? <rekado_>lf94: we use “guix deploy” for deploying Guix systems in the build farm. No need for ansible. <lf94>I'll have to look into it :) <awb999>Loading service /gnu/store/bqz75p0zrhqc15645f1ab74zk1pmyvxc-profile/share/guile/site/3.0/guix/packages.scm ... <awb999>Loading service /gnu/store/bqz75p0zrhqc15645f1ab74zk1pmyvxc-profile/share/guile/site/3.0/guix/packages.scm ... <awb999>;;; WARNING: loading compiled file /gnu/store/bqz75p0zrhqc15645f1ab74zk1pmyvxc-profile/lib/guile/3.0/site-ccache/guix/build-system.go failed: <awb999>;;; In procedure load-thunk-from-memory: incompatible bytecode version <awb999>I try to load user services with shepherd in a container <awb999>I think I have a bug in guile module path inside container <awb999>and then I guess there is a difference between guix sd services and user services