<civodul>i can't believe Julia stealthily exposes people to generic functions
<nixo_>civodul: yay! However, I love julia the language but I hate the reproducibility problems they have (and the way they aren't even trying addressing it. It's impossible to compile the same module twice, let alone the full julia install)
<kori>doing it with guile-xcb as it is is kinda hard :/ I have trouble understanding how to use it
<civodul>nixo_: yeah the build system, all the things they bundle, that's terrible
<atw>kori: the last time I looked at guile-xcb, it was sorta "top down", starting with its usages in guile-wm. IIRC I was trying to spelunk in guile-xcb looking for where it turns the PascalCase identifiers into lisp-case. Not sure if I figured it out...
<rekado>kori: autotools is kinda gross, but it works. Having packaged countless packages for Guix I found packages using autotools much easier to get working than packages using any other build system.
<emacsomancer>trying to build a linux-kernel-module, but getting errors about linux-libre-headers as an unbound variable, despite including it in inputs, and native-inputs: http://dpaste.com/3ZG45C0
<atw>rekado: yeah...I forget exactly why they made that decision but I think it had to do with making documentation first-class. So there's a function that gives you a description (as a data structure) of what CreateBucket wants
<emacsomancer>(on foreign distros I have the relevant kernel modules available already)
<gnutec>emacsomancer: Well... I think you shouldn't do that cause Hurd is coming (I think). But if you wanna. I guess the guix, because it is real free software, they don't have all the tools for this. Try install a non free kernel linux with "make install". I hope you have a backup.
<nckx>emacsomancer: No 5.1 since we don't ship that kernel, either. We only provide linux-libre-headers for the linux-libre kernel versions in Guix. You can make your own with (@@ (gnu packages linux) make-linux-libre-headers). Obviously the @@ means it's not officially supported 🙂
<emacsomancer> (arguments `(#:linux linux-libre-4.19)) results in a build error: "In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): linux-libre-4.19"
<nckx>I can tell you that building a kernel module for linux-libre version <foo> is as trivial as adding (arguments `(#:linux linux-libre-<foo>)), and we only support the versions in Guix (although it's pretty easy to extend that but let's keep things simple for now…).
<nckx>emacsomancer: My bad, I forgot a ‘,’ since we're inside a quasiquoted list of arguments. Try ,linux-libre-4.19
<emacsomancer>gnutec: ultimately the second, but I'm starting with the more modest goal of the first
<gnutec>emacsomancer: I always try to follow GNU. Like Btrfs.. Now I use Trisquel with EXT4. I'm just wait a new HDD to install guix system.
<emacsomancer>gnutec: openZFS is free & open source software, under a weak copyleft licence.
<emacsomancer> I'm using btrfs on my guix system right now, but I'm not very comfortable with it, and ext4 I've suffered data loss (bitrot), so I try to use checksumming file-systems, and zfs is the one I'm most comfortable with.
<gnutec>quiliro: Guile is the program language of the gnu project. Lisp is the language use by Richard Stallmann before create Emacs Lisp. Guile is a implementatin of Scheme is a implementation of Lisp. Is the most easy to learn programming language.!
<quiliro>sneek_: Guile is the programing language of the GNU project. Lisp is the language used by Richard Stallmann before Emacs Lisp was created. Guile is an implementatin of Scheme, which itself is an implementation of Lisp. It is the most easy to learn programming language!
<sneek_>From what I understand, Guile is the programing language of the GNU project. Lisp is the language used by Richard Stallmann before Emacs Lisp was created. Guile is an implementatin of Scheme, which itself is an implementation of Lisp. It is the most easy to learn programming language!
<quiliro>sneek_: Guile is the programing language of the GNU project. Lisp is the language used by Richard Stallmann before Emacs Lisp was created. Guile is an implementation of Scheme, which itself is an implementation of Lisp. It is the most easy to learn programming language!
<roptat>I'm not completely sure how I want to integrate all that though... maybe we should have a bootstrap phase that builds maven as soon as possible, dropping as many dependencies as possible, and then use the maven-build-system to rebuild the dependencies
<roptat>or maybe a modification to the ant-build-system is enough for most cases
<roptat>the devel version of the online manual doesn't seem to follow master, the last version is from July 18th
<lfam_>JayStrict: The first one is used by `guix pull`, which is the tool used to update the Guix tool itself, and the to update the list of avaiable packages
<lfam_>JayStrict: The second is contains the packages you've actually installed
<lfam_>The second is used by default when you do things like `guix package --install vlc` or `guix install vlc`
<lfam_>You can make `guix package` work on the first one like this: `guix package -p ~/.config/guix/current --list-generations` or `guix package -p ~/.config/guix/current --delete-generations=2m`, which would delete all the generations of that profile older than 2 months
<jonsger>civodul: I don't have any objections regarding guile-json3, I already prepared the update for openSUSE. Maybe a release of guix 1.0.2 would be an idea, but I don't have a strong opinion...
<JayStrict>lfam_: Ah, I see. That makes sense. :) That is why I used to get a warning about running 'guix pull' when I already did run it. (I mixed up both paths)
<JayStrict>But then why are there two different profiles in the first place? Would one profile not suffice? It's rather confusing to have two.
<lfam_>JayStrict: Basically the two profiles do two different things. I'm not familiar with Arch so I can't suggest an analogy, but if you are familiar with Debian / Ubuntu it's sort of like `apt update` and `apt install`
<lfam_>The first profile is basically just used to keep track of which packages could be installed, or what packages are available. The second profile is used to keep track of what you do have installed
<lfam_>As always it's somewhat more complicated when you really look closely at it but I think that's what you need to know if you just want to use Guix
<nckx>The fact that there are two profiles is already an implementation detail. It shouldn't leak through, but sometimes it does (‘hash guix’ &c.).
<lfam_>We should just put everything in a database so nobody gets confused while poking around on the filesystem 😬
<JayStrict>lfam_: Thanks, that analogy to 'apt update' and 'apt install' helps.
<quiliro>minall: ya solamente tienes jueves y viernes
<JayStrict>nckx: Well, it matters for me. I want to install guix on my computer correctly. Currently I am stuck at configuring all the $PATH, $INFOPATH, etc. variables. It's not clear to me what to include and how. I think a deeper understanding of the guix architecture would help me.
<brendyyn>JayStrict: did you follow the manual very carefully? people often miss details like this
<nckx>JayStrict: Oh, I didn't mean to imply that it doesn't matter.
<roptat>i don't think the manual tells you about how to get the proper variables available when you start a new shell, does it?
<lfam_>I feel like the only things that need to be exported are GUIX_LOCPATH and ~/.guix-profile/etc/profile
<lfam_>So one variable and one file that must be sourced
<lfam_>They should be handled for login shells, not interactive shells. For Bash this means either ~/.profile or ~/.bash_profile
<JayStrict>Ok, so ~/.guix-profile is apparently called the "default profile". How do you name ~/.config/guix/current?
<lfam_>civodul: Seems like a common pitfall for new users
<roptat>lispmacs, there is a manifest in your profile, but it's not the right format. You can list installed packages in your profile with "guix package -I", then copy that list to a fresh manifest instead
<civodul>lfam_: i wonder how users come to run that command though, and what for
<roptat>JayStrict, the current profile, or the guix pull profile :)
<lispmacs>roptat: wow, okay, I'll try to save that somewhere
<roptat>but really, you probably don't have that many packages that you can't copy their name by hand? :D
<JayStrict>lfam_: I am not sure what a "profile hook" is. There are info pages in ~/.guix-profile/share/info but in ~/.guix-profile/etc/profile there is no $INFOPATH variable set, even after opening a new login shell as you suggested.
<lispmacs>roptat: well, right now I'm only up to like 20, but I've only been using it for a week
<lispmacs>and it is isn't even my production laptop
<lfam_>JayStrict: What are you trying to accomplish right now? Are you just trying to make the info manual available?
<roptat>JayStrict, I wonder if you need the info reader in the same profile for the variable to be set?
<lfam_>JayStrict: Okay, did you export INFOPATH as described in section 4.6 of the manual?
<roptat>(that is because each package can define search-paths variables, and only when they are installed do they take effect)
<roptat>(then guix knows about the variable and sets it according to the specification)
<roptat>if you run "guix edit texinfo" you'll see its package definition, and in there, there is a native-search-paths entry that defines what INFOPATH should contain
<ryanprior>lispmacs nckx I found the fact that manifests in profiles aren't the same as manifests passed with "-m" to be a big missed opportunity.
<nckx>I agree, so I wonder what the good reason was to change it, if there was one.
<ryanprior>Even if there were an easy converter utility between the two, it's quite unforutnate that the word "manifest" is used in guix to refer to two non-fungible concepts
<JayStrict>lfam_: No, I didn't yet. You said that I only needed to source ~/.guix-profile/etc/profile . I am trying this approach now.
<JayStrict>roptat: Wow that is more sophisticated than I imagined. Trying to grasp that now.
<lfam_>JayStrict: It's possible I was wrong, especially if it requires you to do `guix install guix`. When in doubt follow the manual :)
<ryanprior>Using npm as an example, if you "npm install --save some-package" it adds that package to your npm manifest. Then you can copy that manifest to another machine (using git perhaps) and "npm install" will grab all the same dependencies.
<ryanprior>I love & rely on that behavior when I use npm. Makes it easy to create portable environments & share them with people.
<ryanprior>I would like to adopt the same kind of workflow with guix, and the fact that profile manifests aren't equal to CLI manifests is a bump in the road where you have to slow down and convert things instead of get on with the task at hand.
<roptat>we could have a guix package --generate-manifest thing maybe
<roptat>but I'm not sure how to do that, there's some information loss between the commands you used to install things and the content of a profile
<nckx>The function of the .guix-profile/manifest is obviously to store information that's entirely redundant at installation time (output store paths, propagated inputs, search-paths), but would be expensive to look up afterwards once Guix has been pulled to a new version.
<nckx>roptat: True, but there's the same level of information loss with ‘guix package --list-installed’ and it's still useful. I have no guarantee that the ‘gnupg 2.2.17’ in my output wasn't installed with some crazy --with-source option that makes it something completely different than Guix's, but I don't really care.
<nckx>And this is just another output format (recutils vs. manifest) for that same info, no?
<nckx>(Salient excerpt: c++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.)
<nckx>davidl lfam_ The OOM killer will have written an overview of the processes it considered in dmesg too. The ‘pgtables_bytes’ should tell you which other memory hogs (if any) were around at the time and how much RAM the ill-fated cc1plus was using.
<rekado_>re manifests and manifests: I’m equally confused. One is an output the other is an input. I’d love to see them become one and the same, especially now that we have inferiors and channels, so the state of Guix can be recorded.
<nckx>I'm not confused, exactly. The ‘.guix-profile/manifest’ (OK, it doesn't help that we call the *other* ones ‘profile manifests’ in the manual) solve a problem well but just unfortunately named.