IRC channel logs


back to list of logs

<f0ff>i don't get it :P
<mark_weaver>f0ff: the hash is of the description of how to build the package, and the descriptions of all the inputs available while building the package, transitively, all the way back to the bootstrap binaries.
<mark_weaver>as well as the hashes of all raw inputs used along the way, e.g. of all sources and bootstrap binaries
<mark_weaver>f0ff: what part of the manual gave you the impression it was only a hash of the ./configure && make && make install ??
<f0ff>but what is the point of hashing the inputs? if a package is comprimised it wont show?
<kqb>mark_weaver: hi, using guix system with "bare bones" example on arch; getting KVM permission denied error; Kernel modules are enabled; BIOS: VT-d enabled; any ideas?
<f0ff>sheesh a test in libarchive fails and i can't continue :( one tiny test fails heh
<hyperreal>mark_weaver: Can you read my text above when you get a chance?
<mark_weaver>hyperreal: what is the output of "stat /gnu/store/...-harbuzz-1.0.6-bin" ?
<hyperreal>mark_weaver: I have the output of the stat command for that exact package, but since it is on another machine, I have no way of showing you. I can't figure out how to start ssh, because then I would just cat the output to a file and scp the file over to this machine, and then paste it into pastebin.
<hyperreal>Anyway, is there any specific info you're looking for in that stat output?
<mark_weaver>owner, mode (permissions), and type (i.e. symlink or directory) ?
<hyperreal>mark_weaver: "Access: (0777/drwxrwxrwx) Uid: (30001/guixbuilder01) Gid: (30000/guixbuild)"
<hyperreal>it is a directory
<hyperreal>But is also says "Links: 1"
<jesaispas>is Guix SD a distribution developped by GNU team?
<mark_weaver>hyperreal: the problem is that 0777 mode. if the output of a build is group or world writable, it complains. it's strange that the permissions are set like that
<mark_weaver>my first thought was that maybe the umask was set to 000 in guix-daemon, but guix-daemon sets the umask to 022 during startup to avoid this
<hyperreal>mark_weaver: hmm. I could try running guix pull again, but i did that right before I ran guix system init.
<hyperreal>that was 4-5 hours ago though
<hyperreal>or perhaps guix pull was what changed the permissions?
<hyperreal>this install image I got from the GuixSD website. should I use a more recent version?
<mark_weaver>hyperreal: how did you install guix, and what version did you install?
<hyperreal>mark_weaver: I haven't installed it yet. I'm running it from the usb install image. it is version 0.9.0
<hyperreal>I'm trying to run the install command, guix system init /mnt/etc/config.scm ...
<mark_weaver>hyperreal: can you email about this?
<mark_weaver>make sure to mention that the directory ended up with mode 0777
<hyperreal>mark_weaver: is there any specific format that is recommended for bug reports?
<hyperreal>like, for subject and body of the message
<mark_weaver>hyperreal: no, just describe the problem and try to include relevant information
<mark_weaver>e.g. that you were running this from our USB installer version 0.9.0
<mark_weaver>hyperreal: and i fyou ran "guix pull" before "guix system init", make sure to mention that as well
<mark_weaver>*and if
<hyperreal>Yep, will do
<hyperreal>bug report sent
<efraim>efraim@debian-netbook:~$ guix build vim-custom
<efraim>guix build: error: build failed: derivation `/gnu/store/kcfch6xs5rbxakvhzhl96wq6rlyhbyrv-vim-7.4.1008-checkout.drv' has incorrect output `/gnu/store/pfspp60wvc4bg3hgqla6mjxfqxd4z5n2-vim-7.4.1008-checkout', should be `/gnu/store/7k0zs9cbz3wy6p7hc8jiz1anl27ivr2d-vim-7.4.1008-checkout'
<efraim>any ideas?
<iyzsong>efraim: no 'hash mismatched' information? the git checkout is a fixed-output derivation, I think this only occour when the hash in reciple don't match the actually contents.
<efraim>iyzsong: thanks. no that was the whole error message. currently the hash is blank, its from a git-download
<efraim>i entered something into the hash field and it started working right
<efraim>I built a custom vim with ruby as an input, so it built vim, grafted ruby, and is now grafting my custom vim
<robsyme>Hi all. If I have a cloned version of the guix repo and make an addition to the package definitions, what is the best way to ensure my guix installation can see my new package definition?
<rekado>robsyme: you can either use GUIX_PACKAGE_PATH or use "./pre-inst-env guix" with your git repo.
<rekado>GUIX_PACKAGE_PATH is an environment variable holding a list of directories in which packages are to be found
<rekado>if you have changed packages in the git repo use "./pre-inst-env guix" instead of just "guix"
<rekado>it will use the current state of your git repo rather than what has been installed.
<rekado>I use GUIX_PACKAGE_PATH for separate package repositories containing packages that I don't intend to submit as patches to Guix upstream.
<robsyme>rekado: Thanks! The pre-inst-env is exactly what I was missing.
<civodul>Hello Guix!
<janneke>Hello civodul!
<rekado>I just remembered that I still have this patch to delete "gcc" and other conflicting executables from alternative gcc packages (such as gfortran or gcj). Since hydra hasn't been so busy these days I'll plan to push them today.
<civodul>sounds good!
<civodul>i would like to start rebuilding so we can make the release with a few grafts as possible
<civodul>only 11G of cached nars on
<rekado>I'll switch Guix at work to today
<efraim>can guix-daemon be fed --substitute-urls?
<efraim>i checked the manual, yes
<civodul>rekado: good idea
<civodul>i've changed the config to keep things in cache for 7 days
<civodul>we'll see how it goes
***nckx is now known as nckx|offline
<rekado>the built-in NFS attribute cache which is enabled by default really makes a difference.
<rekado>I disabled it to check if it works. "guix build samtools" takes 93 seconds without, 19 seconds with.
<rekado>(for an item in the store)
<rekado>it seems that I cannot get any more performance gains by tweaking NFS parameters.
<rekado>hmm, I'm saving almost 5 seconds with the "nocto" and "nolock" mount flags.
<rekado>yeah, down to 15 secs on repeated "guix build --no-substitutes samtools"
<jesaispas>is it a good idea to install Guix as the main system? Or it is better to do a dualboot?
<df_>depends on your tolerance for things breaking :)
<df_>note that you can use guix (as opposed to guixsd) on top of another distribution
<jesaispas>i don't really understand how it works if i use Guix on another distro : /
<df_>it's just another package manager
<df_>like say, installing stuff manually in /usr/local
<df_>only better
<jesaispas>and do i need advanced knowledges about Unix to use GuixSD? Or i can learn by using it?
<df_>you'll probably learn more about guixsd than about unix
<df_>depends really, if you're doing this just to learn then I'd say go for it, if you need to be productive from the outset I'd suggest a more mature distro
<jesaispas>Well, i want to learn Bash, C language and how a computer works. So i don't think that i need to be productive : )
<df_>well it's worth noting that not all knowledge gained from guixsd will be applicable to more mainstream gnu/linux distros
<df_>but they're obsolete anyway :p
<jesaispas>okya : )
<Jookia>jesaispas: Guix is mostly Guile so you'd be learning a lot of that. On the flip side, it's mostly Guile so you'd only need to be learning a lot of that instead of Bash/C
<Jookia>That said you should probably learn Bash if you want to be productive developing in the Unix world
<jesaispas>What "Guile" means ? : /
<jesaispas>: )
<Jookia>It's the language Guix is written in, it's a bit odd to outsiders but it's not that hard to get a hang of if you have some experience with functional programming
<jesaispas>i'm really interested. And it's a GNU project so... : D
<Jookia>FWIW if you're just packaging you won't need to know much Guile, you can just see how others write packages
<jesaispas>i should probably better install it in a virtual machine and then try it : )
<Jookia>Maybe, QEMU is a great VM system if you're on Linux
<jesaispas>Never tried
<jesaispas>In another subdject. Do you know if gNewSense is still alive? 'cause i'm on debian and i wanted to install gNewSense.
<Jookia>I don't know, sorry. Most free distros I know about are Trisquel or Parabola
<Jookia>I think gNewSense may be out of date but I'm really unsure
<jesaispas>i think the same.
<jesaispas>Jookia, you use GuixSD everyday?
<JeanLouis>info guile: Guile is an implementation of the Scheme programming language
<Jookia>jesaispas: I'm on a long road to getting it work on my system, but that's my goal. I have it set up on my thinkpad so I'm getting the hang of things
<JeanLouis>jesaispas: Guile is preferred GNU language and helps people to learn programming.
***fkz is now known as Guest29298
<jesaispas>Okay okay : )
<roelj>What exactly is the difference between "inputs" and "native-inputs" in Guix packages?
<roelj>(I don't quite understand what cross-compilation has to do with "native-inputs" in the manual)
<Jookia>native-inputs are on the build machine, not intended for the target running
<iyzsong>if i'm x86_64-linux and cross build for arm-linux, then native-inputs are in x86_64-linux (which can be run on the host) while inputs are in arm-linux (can be link by the cross compiler).
<roelj>So native-inputs are things that are platform-independent?
<roelj>For which it doesn't matter whether it's compiled on a specific CPU architecture, I mean.
<Jookia>When you build something it usually has scripts to run makefiles or whatever
<Jookia>In the end, your cross-compiler is native-inputs
<iyzsong>native-inputs is the same as your host platform, which can be 'native' run.
<jesaispas>thanks for help guys btw : )
<jesaispas>i think i will install parabola and GuixSD on a dualboot.
<roelj>So, is for example Bison a native-input, because it generates C code, which is the same regardless of the platfrom it is being compiled on?
<roelj>("it" being the code generated by Bison)
<Jookia>roelj: No, native-inputs are things that run on the computer doing the cross-compiling. Like the cross-compiler itself, the build tools (autotools). They don't have to be platform independent, they just have to run
<roelj>Jookia: So, then Bison would be just a regular 'input'?
<taylan>if e.g. bison were a normal input instead of a native-input, the build process would get the bison for the *target* platform, which would fail to execute during the build phase
<taylan>so the native-inputs field is for packages containing binaries that will be executed during build (and possibly other platform-dependent stuff)
<roelj>Yes, I start to get it now
<roelj>Thanks for the explanation :)
<Jookia>And normal inputs is for stuff that just needs to be in the environment but is of the target platform. So an ARM library for example, so the cross compiler can link it in
<roelj>Where would I place things that are absolutely only needed at build time, and not on run time?
<roelj>Like static libraries, interpreters (like Python) that are run in a Makefile to do something..
<roelj>Oh sure.. Now I get it..
<jesaispas>does GuixSD support UEFI?
<Jookia>jesaispas: Not yet but it wouldn't be too hard to add if someone knows how to set up GRUB to do it
<roelj>The whole idea is that the build host can build stuff for other platforms.. So things that belong to the build only, belong in native-inputs..!
<roelj>Then inputs are used for runtime dependencies (shared libraries)?
<jesaispas>Jookia, okay
<Jookia>jesaispas: If you know what commands need to be run I'll write up a patch
<jesaispas>Jookia, well, on Archlinux or Parabola, i install grub on UEFI.
<Jookia>Hmm, it would actually take a while to get a live USB set up with UEFI support. But for actually installing it I think it's possible
<iyzsong>our still grub only have i386-pc in 'lib/grub' now ;-
<jesaispas>i leave. ++ world : )
<civodul>ACTION prepares new security-updates branch
<civodul>you sound very enthusiastic ;-)
<Jookia>I am, because it means one day you'll look at my coreboot patches. ;) Joking. Though I think some EFI work needs to be added on top of it. I think it'd be a good idea to make 'device' platform-dependent, so on UEFI they can specify a partition
<civodul>heh :-)
<civodul>agreed on 'device'
<Jookia>I also posted a reply patch fixing an issue in the RFC. Though maybe I already said that?
<civodul>in the RFC?
<civodul>ah, ok
<civodul>i'll look at this patch series, i swear!
<civodul>sorry it's taking so long
<Jookia>It's okay, it just gives me more time :) I'm sure you're behind on a lot of more important subjects
<Jookia>That reminds me, I think gdk-pixbuf might be fine with 2G of RAM. I need to test that
<civodul>i lost track of that gdk-pixbuf issue
<Jookia>Me too but it's the only other patch I can remember sending :P
<civodul>ok, not so bad ;-)
<Jookia>For what it's worth I'm still trying to find testers for my patch, like paroneayea. :)
<efraim>"all_aboard_the_fail_boat" nice fail method
<Jookia>civodul: Is there a reason why the daemon doesn't override --cores and --max-jobs?
<civodul>Jookia: you mean a reasons why users are allowed to change it?
<Jookia>No, as in I run guix-daemon with it and I still have to set --cores and --max-jobs in guix since the daemon's settings don't seem to do much
<civodul>Jookia: ah right, see
<civodul>mark_weaver: you ok if i start the security-updates build? there are currently 110 builds for master, mostly armhf
<Jookia>civodul: How hard would this be to implement
<Jookia>civodul: It looks somewhat trivial
<civodul>not too hard, but we need a way to communicate current settings to clients
<piyo>help: I was downloading file-5.22? and guix reported it was corrupt, and said try to use the -tvv option without mentioning which command. Which command is it referring to?
<civodul>or to allow clients to refer to them
<rekado>trying to rebuild guix after entering an old profile containing all dependencies
<rekado>/gnu/store/gybk6iz6n659njzg56vqsy5bg7irk370-glibc-2.22/lib/ undefined reference to `__mktemp@GLIBC_PRIVATE'
<rekado>that's what I get when guix-daemon is linked.
<piyo>command was 'guix package -i emacs' on
<rekado>have a broken guix since doing "guix gc"
<rekado>apparently it was configured with a guile that has been collected since
<civodul>rekado: regarding building guix-daemon, you probably need "make clean && make"; perhaps some objects are referring to old libc things
<rekado>did that already.
<rekado>is it a problem that I'm using the host system's gcc and linker?
<rekado>(I don't have gcc-toolchain in the profile)
<civodul>mark_weaver: i went ahead and started an evaluation of security-updates, let me know what you think!
<civodul>rekado: could be, if the libcs are different, etc.
<civodul>piyo: maybe, from which you were downloading, was overloaded and dropped the connection?
<civodul>piyo: is it a bzip2 error that you're seeing? that's the usual symptom
<rekado>hmm, will use the guix installation on my workstation to install gcc-toolchain and see if that will fix it
<piyo>yes it was a bzip2 error. Also I am behind a http proxy with no ftp proxy capability so I cannot guix build?
<piyo>also I was I using
<civodul>piyo: mostly likely didn't have the thing in cache yet, so it talked to, which eventually timed out
<civodul>i would suggest retrying :-)
<piyo>will do. Is there a way to look at the partially downloaded file? also what does -tvv mean?
<civodul>it's a bzip2 error message, so these are bzip2 command-line options
<civodul>i think the partially downloaded file is lost
<civodul>rekado: i've given you admin rights on Savannah (no specific reason other than increasing redundancy ;-))
<civodul>so we're 5 admins there
<rekado>civodul: thanks!
<civodul>for instance you can add new members, which is think non-admin cannot do
<civodul>can be useful
<efraim>so I'm trying again to package newsbeuter, I think its time to start submitting bug reports/pull requests to mention surprise dependancies on perl/python
<Jookia>'surprise dependencies' - the worst kind
<Jookia>a bit like a surgeon discovering their watch is connected to your intestines
<efraim>I also had a runaway python process running for 4? hours while I was working on vim
<piyo>its not dead yet
<efraim>finally killed it, killed the frozen test when it first panicked
<rekado>after installing gcc-toolchain guix-daemon links just fine.
<piyo>rekado: is this on guixsd?
<civodul>rekado: and recompiling it with gcc-toolchain, right?
<Steap>"The first tool is a Docker image based on CentOS 5.11, which is recommended as an easy to use self-contained build box for compiling manylinux1 wheels [12] ."
<Steap>k the Python folks have gone braindead
<davexunit>where is this?
<Steap>I need to read this more carefully, but damn...
<Steap>I hope we can avoid the wheels
<Steap>I'm fine with running "python install" from source :)
<Steap>I do not even get why we have eggs :D
<rekado>civodul: yes
<rekado>piyo: no.
<Jookia>Can't wait to install a project and have to set up Docker, Vagrant, Wheels, NPM, Bundler, Python, Bundler, etc
<Jookia>this is all so convenient for my developing
<Jookia>eventually i'll have to buy another HDD since i can't fit all this on an SSD
<rekado>"what do you care? Space is cheap nowadays!"
<Jookia>Haha, yeah
<Jookia>Space is cheap, bandwidth is fast, everyone uses x86
<Jookia>Why should I bother with Unicode
<piyo>whoa wait up
<piyo>Keep calm and stay Unicode.
<Jookia>Heh, I've had countless arguments with game developers that think nobody uses Unicode
<davexunit>software development is terrible. news at 11.
<piyo>game devs do not need unicode?
<Jookia>only english people play games
<Jookia>or even worse, 'all i need is the BMP'
<Jookia>there's an open source GUI library called librocket that deliberately only supports BMP
<Jookia>It's amazing
<paroneayea>Jookia: ah yeah that's right
<paroneayea>Jookia: can you email me the patch?
<paroneayea>cwebber AT dustycloud DOT org
<piyo>nobody uses the same 90% of unicode, is that how the quote goes?
<Jookia>paroneayea: Sent
<Jookia>piyo: Haha, I think that's true about any collection of data
<piyo>Actually I only heard this quote about Microsoft Word and Excel.
<Jookia>It comes up a lot when people talk about slimming down C++ to a subset
<piyo>That makes sense.
<piyo>So are we at that point with guix? I mean 90% and rapidly diverging?
<Jookia>Who knows
<civodul>Steap: this PEP is terrible!
<Steap>civodul: I think they want to do reproducible builds using Docker
<Steap>but do we care ?
<Steap>As long as I can still install my stuff from source...
<civodul>"frozen pizzas" you mean
<civodul>the whole point of Docker is to use pre-built binaries
<Jookia>frozen pizza development
<Steap>civodul: yeah but they distribute the built wheel
<Jookia>Fantastic, binaries. Exactly what I wanted.
<Jookia>When's MIPS/ARM support
<davexunit>frozen pizza driven development
<rekado>argh, spent so much time trying to debug my ant-build-system only to find that there is no bug there.
<rekado>(the bug is in the code I tried to build with it.)
<rekado>i.e. hamcrest-core contains a class that is not reproducible.
<Jookia>Did Guix come at a bad time where now we have impossible packages to package
<civodul>rekado: that's rather good news i guess ;-)
<paroneayea>Jookia: thx
<civodul>Jookia: i'd say we are here to save the world from chaos
<Jookia>I love how the manylinux1 proposal seems somewhat portable up until they say a requirement "To be eligible for the manylinux1 platform tag, a Python wheel must therefore both [include long list of libraries] and work on a stock CentOS 5.11 [6] system that contains the system package manager's provided versions of these libraries."
<davexunit>that is so terrible
<Jookia>"Because CentOS 5 is only available for x86_64 and i686 architectures, these are the only architectures currently supported by the manylinux1 policy."
<civodul>i wonder how they determine whether something "works"
<davexunit>Jookia: some packages are approaching impossible
<Jookia>I'd really like to know why they chose CentOS over Debian
<davexunit>nodejs and java
<davexunit>in particular
<Jookia>"pip users remain free to use the "--no-binary" option if they want to force local builds rather than using pre-built wheel files." This is going to be a default?
<Jookia>The more I read this the more sick I feel. "Distribution of bundled wheels through PyPI is currently the norm for Windows and OS X." "This closely parallels the security implications of the distribution of binary wheels on Windows that,"
<JeanLouis>warning: failed to install locale: Invalid argument, after guix command, is there something i have to do?
<Jookia>JeanLouis: You have to set GUIX_LOCPATH
<Jookia>and install glibc-locales
<JeanLouis>./pre-inst-env guix package -i glibc-locales <-- like this?
<JeanLouis>do I understand correct, all packages in ~/.guix_profile use only that directory for work with system? Do they use Debain /usr /etc ?
<Jookia>All packages in Guix are installed in /gnu
<JeanLouis>aha yes
<JeanLouis>and they use exclusively those packages, libraries, etc. all is in /gnu?
<Jookia>GuixSD just takes this to the next level by putting all system config in /gnu too and using a system profile
<JeanLouis>how does your / looks like?
<Jookia>Like most / s
<Jookia>The difference is a lot of it is empty
<davexunit>and no /usr
<Jookia>'/bin/sh' and there's no /usr
<JeanLouis>you have basically /bin/sh and nothing else inside?
<JeanLouis>so scripts which requires /bin/ls will simply fail now?
<JeanLouis>I have to change them?
<JeanLouis>do you have some reference why is that better?
<JeanLouis>I was watching FOSDEM videos, but obviously I did not pick that...
<paroneayea>thanks for getting blender in, rekado :D
<Jookia>Because calling /bin/ls is hoping that it's actually ls ;)
<davexunit>JeanLouis: we can agree that global state in a program should be minimized, yes?
<JeanLouis>exactly yes
<Jookia>Maybe it's BSD ls, maybe it's someone's ls script
<JeanLouis>davexunit: what is "global state in a program"? Example?
<Jookia>The solution to all these problems is to use a script that finds ls and patches your code before you run it
<Jookia>JeanLouis: Variables that can be accesed from any code
<davexunit>JeanLouis: a mutable variable that is used from anywhere and everywhere
<JeanLouis>davexunit: aha I get the concept
<Jookia>most Unix is like that, where /bin/ls is a global variable
<davexunit> /usr is basically global state for your OS
<paroneayea>ACTION also wonders when non-grafted openssl and perl might land in guix master
<davexunit>the big problem that it creates is that you cannot install 2 different versions of the same thing without conflict
<paroneayea>grafting has certainly reduced the urgency
<Jookia>paroneayea: Who needs them to be in guix master when we can just graft all our updates forever? ;)
<paroneayea>Jookia: yurk
<davexunit>paroneayea: the security-updates branch is currently being built
<paroneayea>davexunit: ah :)
<JeanLouis>davexunit: yes I see.
<JeanLouis>where does GUIX_LOCPATH need to point?
<Jookia>JeanLouis: Just do this:
<Jookia>echo "source ~/.guix-profile/etc/profile" >> ~/.profile && echo "export GUIX_LOCPATH=\\"/root/.guix-profile/lib/locale\\"" >> ~/.profile && echo "export LANG=\\"en_US.UTF-8\\"" >> ~/.profile
<JeanLouis>yours is in /root?
<Jookia>Oh, yep
<Jookia>I run too much stuff as root
<JeanLouis>so for me just ~/ ?
<Jookia>change it to $HOME/.guix-profile maybe
<JeanLouis>echo $GUIX_LOCPATH
<JeanLouis>/home/data1/protected/.guix-profile/lib/locale -- this is correct?
<JeanLouis>I mean, it points to locale?
<JeanLouis>OK at least I don't have that error any more
<Jookia>Then it's fixed
<JeanLouis>wow thanks
<JeanLouis>and most important, once I build guix this way, I get everything in /gnu/store, and so on, do you think, I could simply switch from Debian to Guix without doing other changes on system?
<JeanLouis>without full re-install?
<JeanLouis>I will install it on new laptop anyway...
<JeanLouis>today, I have handled to install guix, took me 3-4 days, until I figured out why my /home was unmounted during guix process.
<JeanLouis>am I supposed to run daemon all the time? That I simply install it on startup.
<Jookia>There's a systemd file you use
<Jookia>JeanLouis: Why did it unmount?
<JeanLouis>well that is unsolved problem, I don't know but I figured out what to do, that I prevent it.
<JeanLouis>I had /dev/sda7 on /home. On top of that, I have mounted /dev/mapper/protected -> /home -- and I have done that for years, without thinking.
<JeanLouis>so during guix startup, it simply mounted or re-mounted (all guessing) what it found first, probably it found first /dev/sda7 and did that.
<JeanLouis>That is my guess. I don't know. But then instead of mounting /home on top of mounted /home, I have first unmounted /home from /dev/sda7 and now I could install guix
<Jookia>Interesting. Maybe you should unmount it before mounting it then
<JeanLouis>I did, but anyway, no program should ever unmount /home or change what is working.
<Jookia>This is true
<JeanLouis>and now I killed the daemon, to try to put it back in memory, but socket is already in use.
<JeanLouis>./pre-inst-env guix-daemon --build-users-group=guix-builder
<JeanLouis>error: cannot bind to socket `/usr/local/var/guix/daemon-socket/socket': Address already in use
<JeanLouis>and no guix-daemon running...
<Jookia>are you sure?
<JeanLouis>ps ax|grep guix
<JeanLouis> 4449 pts/0 S+ 0:00 grep guix
<davexunit>JeanLouis: ./configure --localstatedir=/var
<JeanLouis>where that?
<davexunit>/usr/local/var/guix doesn't exist
<Jookia>civodul: ^
<JeanLouis>on my side it exists
<davexunit>JeanLouis: okay, but it's not where the guix daemon really is.
<davexunit>it's /var/guix
<JeanLouis>not here, I don't know.
<JeanLouis>I did configure now, nothing changed
<Jookia>you have to rebuild
<Jookia>It sucks we have to explain this often
<Jookia>/var/guix should probably be put in /gnu
<JeanLouis>I know make, make install etc. I read file
<JeanLouis>I was thinking simple configure will change environment
<davexunit>Jookia: the docs mention this, I think.
<Jookia>davexunit: They don't
<davexunit>okay, well then that's an easy fix.
<davexunit>I am not in favor of changing the default from the autotools standard
<Jookia>JeanLouis: btw you need to delete /gnu and restart over
<NiAsterisk>a short question: if gnunet-gtk inherits gnunet in the original package, and I have written (or better fitted in and restructured Jookia's patch) a gnunet-svn which inherits gnunet, and now I need a gnunet-gtk which inherits gnunet-svn, is that possible with guile? I assume "yes" and I only ask to avoid some minutes of rebuild and rewrite if I figure out that this inherit chain does not work.
<Jookia>JeanLouis: Or rather, not delete it. But delete /usr/local/var/guix
<davexunit>Jookia: why?
<Jookia>davexunit: To avoid corruption
<davexunit>Jookia: there's no corruption
<davexunit>the daemon never worked
<davexunit>the connection to the daemon
<Jookia>Then how did they install glibc-locales
<davexunit>Jookia: using a different guix
<JeanLouis>Jookia: but my /gnu is gone! :O
<davexunit>if it really was installed
<davexunit>I have no idea what you folks have gotten yourself into
<Jookia>davexunit: A different Guix. So changing to the statedir will mean it no longer knows it's installed or the profiles
<Jookia>So i'll redownload stuff already in the store
<davexunit>no it won't.
<Jookia>It'll still search /usr/local/var/guix ?
<Jookia>How would it find the profiles
<davexunit>I'm sorry, I need to step away from this for awhile.
<Jookia>Okay :\\
<Jookia>davexunit: I'm sorry, I'm not trying to create friction and I sincerely apologize. I think this is probably miscommunication or mishearing on my end.
<davexunit>it's okay
<Jookia>I'm going to go write some documentation to fix this localstatedir issue
<JeanLouis>Jookia: I did not quite understand the last conversation between you, but, is it correct to use? ./configure --localstatedir=/var
<NiAsterisk>although too much inherits can cause complications maybe later on, so I will just avoid this by making gnunet-svn not inherit something.
<NiAsterisk>ACTION afk again
<Jookia>JeanLouis: I think so, yes.
<JeanLouis>btw, /gnu is still there...
<JeanLouis>PASS: tests/lint.scm
<JeanLouis>PASS: tests/publish.scm
<JeanLouis>PASS: tests/scripts.scm
<JeanLouis>It takes time to check, it is slow...
<Jookia>Try using -j
<Jookia>-j then number of your CPU cores
<JeanLouis>aha? let me see why
<JeanLouis>option to make ?
<Jookia>You can just use the same -j to make
<JeanLouis>info says, number of jobs, not number of CPUs
<Jookia>Usually you use the number of CPUs as jobs
<Jookia>one per CPU
<JeanLouis>aha? OK
<JeanLouis>I like the GNU approach, finally I feel "home".
<Jookia>That's nice
<suitsmeveryfine>Hi! Is today a good day to install GuixSD from USB or is the system broken?
<JeanLouis>I can see the future, if operating systems can be configured with one file, if I understand it well.
<Jookia>suitsmeveryfine: 'broken'
<pizzaiolo>hey suitsmeveryfine
<Jookia>suitsmeveryfine: Also I have the GRUB patch
<suitsmeveryfine>Jookia: that's great. I'd like to test it tonight
<suitsmeveryfine>if that's possible
<Jookia>suitsmeveryfine: Do you want me to link it to you?
<suitsmeveryfine>yes please. I'm semi-afk right now
<JeanLouis>Jookia: how many gnu/packages/*.scm did you make?
<Jookia>JeanLouis: 0
<JeanLouis>I was thinking you make those, to download, install packages.
<Jookia>No, I've been doing bugfixes and changing of stuff like bootloaders
<JeanLouis>ok, now I am doing new configure with /var, but did I forget bootstrap maybe?
<Jookia>You'll know shortly :P
<JeanLouis>checks take long time...
<Jookia>If you think that's a long time, try building Firefox on an ARM machine. 11 hours :) Though I haven't tried LibreOffice yet which may take a few days
<JeanLouis>yes, yes. I have this now: PASS: tests/
<JeanLouis>where do I start to make package definitions?
<Jookia>What are you trying to package?
<rekado>does anyone know if we should have a python-pygtk package?
<rekado>I have a package here that does "import pygtk", but it's written in Python 3
<JeanLouis>Jookia: I need IceWM (someone maybe have done that) and Courier MTA, plus ROX-Filer
<Jookia>Ah, well you should look at how other WMs are packaged. It's in gnu/packages/
<JeanLouis>Jookia: is it normal, I have only 667 files in gnu/packages?
<Jookia>There's often multiple packages in single files
<JeanLouis>aha yes, I see now in databases.scm
<JeanLouis>make install wants me to install in ‘/usr/local/bin/guix-daemon
<JeanLouis>but if I: which guix, it says: /gnu/store/wmrkm7rhn05fnim7wplz9p8vya4ph8li-profile/bin/guix
<JeanLouis>so I don't get it, where it should be
<Jookia>Just let it install
<JeanLouis>ok I did
<davexunit>JeanLouis: most of us do not run 'make install'
<paroneayea>what's the proper way to remove old system generations in guix?
<paroneayea>just remove the links?
<paroneayea>and then gc?
<davexunit>paroneayea: yup
<davexunit>we don't have a UI for it yet
<JeanLouis>davexunit: why?
<JeanLouis>I am on Debian, just using package manager. So, I shall rather not run install?
<davexunit>JeanLouis: 1) because we hack on it 2) because there's a better option
<davexunit>you can make ~/.config/guix/latest a symlink that points to the root of your guix source tree
<davexunit>and guix will always look there to load Guile modules
<davexunit>JeanLouis: but also, it's important to understand how the GNU build system works, which it seems you aren't familiar with.
<JeanLouis>davexunit: that is why I am here to learn
<davexunit>the reason it installed the guix script to /usr/local/bin is because the default installation prefix in the GNU build system is /usr/local
<JeanLouis>no problem, uninstall went good
<davexunit>you can change it by running ./configure --prefix=/something/else/here
<JeanLouis>I only tried to remove /usr/local/var
<paroneayea>is there danger in running "guix gc" mid "guix environment" ? :)
<davexunit>paroneayea: no.
<davexunit>they should be protected from the GC because we are holding open a store connection the entire time you are in the environment for just this reason.
<davexunit>civodul told me to do that way back when I first wrote 'guix environment'
<paroneayea>davexunit: whew!
<JeanLouis>davexunit: for testing, maybe I shall not install it, rather use the ./pre-inst-env, am I right?
<davexunit>JeanLouis: sure
<JeanLouis>I guess I have used it this way, until now
<davexunit>that was is especially convenient if you're going to write packages or otherwise hack the source
<JeanLouis>but I did get /usr/local/var/guix
<JeanLouis>instead /var/guix
<JeanLouis>I try this: /home/data1/protected/Programming/GNU/guix/pre-inst-env /home/data1/protected/Programming/GNU/guix/guix-daemon --build-users-group=guix-builder
<JeanLouis>error: cannot bind to socket `/usr/local/var/guix/daemon-socket/socket': Address already in use
<JeanLouis>ps ax|grep guix -- no daemon running
<davexunit>JeanLouis: you already have a daemon running
<davexunit>again, /usr/local/var is *wrong*
<JeanLouis>how to change?
<suitsmeveryfine>Jookia: how to I apply your patch?
<davexunit>./configure --localstatedir=/var
<JeanLouis>I did that exactly. After that, make
<Jookia>suitsmeveryfine: Run 'git am jookias-path'
<davexunit>JeanLouis: you must have done something incorrectly.
<davexunit>this is exactly what we all do to setup our development guix environment correctly
<JeanLouis>I did this:
<davexunit>JeanLouis: oh you didn't use the binary installer?
<davexunit>well you've done something wrong
<davexunit>I can't tell you what
<paroneayea>ACTION hids
<suitsmeveryfine>Jookia: great, thanks. Will this break reconfigure afterwards or did you solve that issue?
<Jookia>suitsmeveryfine: It's solved
<paroneayea>JeanLouis: I don't know if the ./configure --localstatedir=/var is mandatory now or not
<Jookia>It's always been
<davexunit>it's not mandatory
<paroneayea>my guix setup has diverged since I wrote that post
<davexunit>it's only needed when you have *AN EXISTING GUIX ALREADY INSTALLED THAT USES /var*
<davexunit>which most people have
<davexunit>because they use the binary intaller
<davexunit>but starting from complete scratch gives you choice
<Jookia>I see!
<davexunit>/usr/local/var is as good a place as any in that case
<paroneayea>JeanLouis: you did run the daemon though right?
<paroneayea>enter your password
<JeanLouis>I did not use functions
<paroneayea>that'll be necessary to do anything with guis
<paroneayea>according to my setup in that post
<davexunit>apparently it's not running
<JeanLouis>but now I am: guix-daemon
<JeanLouis>error: creating directory `/var/guix': Permission denied
<davexunit>JeanLouis: run as root
<davexunit>the daemon runs as root
<paroneayea>JeanLouis: yeah the tutorial you're reading uses sudo
<paroneayea>for that command
<JeanLouis>if I run by hand, it runs
<paroneayea>(if you diverge from the blogpost, which is already diverging from mainline guix instructions, it's more work to find out what's different :))
<paroneayea>(now you've diverged twice!)
<JeanLouis>paroneayea: yes you are right
<paroneayea>JeanLouis: anyway, sounds like you're almost there
<paroneayea>run the daemon and guix should work (in theory)
<paroneayea>when I'm on Debian, I run guix-daemon in a screen.
<JeanLouis>OK I run now daemon automatically from sudo
<JeanLouis>is this correct? which guix
<JeanLouis>in /gnu/store?
<Jookia>Is that the same profile as before you reinstalled
<paroneayea>JeanLouis: if you followed the instructions from my post
<JeanLouis>which post, please?
<paroneayea>you shouldn't have a guix in your guix store probably
<paroneayea>JeanLouis: the one you linked
<suitsmeveryfine>Jookia: failed to detect patch format
<paroneayea>JeanLouis: the goal of that one is to be able to run guix *from git* on Debian
<JeanLouis>yes, but then I changed PATH and so on... first in my PATH is /gnu/store/wmrkm7rhn05fnim7wplz9p8vya4ph8li-profile/bin
<JeanLouis>maybe that is why?
<JeanLouis>because later I installed guix by guix...
<Jookia>suitsmeveryfine: Using git am? Hmm, one moment.
<suitsmeveryfine>Jookia: wait, I used wget to fetch the whole URL and got the HTML as well
<paroneayea>JeanLouis: I would suggest, at this point, making use *either* the tutorial on
<paroneayea>*or* the one in the manual, using the binary tarball
<paroneayea>trying to mix both is probably chaos
<paroneayea>especially when you're first learning!
<suitsmeveryfine>or just wget this URL I guess:
<mark_weaver>civodul: looks like a full rebuild from scratch is happening on the security-updates branch. is that expected?
<JeanLouis>paroneayea: thank you for the blog, that is how I started.
<Jookia>suitsmeveryfine: Yes, try that
<paroneayea>JeanLouis: sure thing!
<JeanLouis>anyway, I will go back to original and try not to diverge, to learn, no problem. I guess my GNU store will be in that case removed.
<JeanLouis>But never mind, this is like one true GNU.
<paroneayea>JeanLouis: no worries, and good luck :)
<JeanLouis>First I go to buy this for mother in law and then back to guix
<suitsmeveryfine>Jookia: patch failed
<suitsmeveryfine>error: guix/scripts/system.scm:125: the patch cannot be applied
<Jookia>suitsmeveryfine: What are you applying it to, master?
<suitsmeveryfine>I built master earlier today and that worked fine
<suitsmeveryfine>(I mean the current master)
<Jookia>suitsmeveryfine: Oh I think I know what's happened- Ludovic pushed a patch conflicting with my chnges
<suitsmeveryfine>OK. If you wish to modify your patch I can try again
<Jookia>I shall do that in a minute or so
<Jookia>How long are you here for?
<suitsmeveryfine>I'll be here for several hours now
<suitsmeveryfine>I'm the only one awake now so I hope there will be less disturbance.
<Jookia>suitsmeveryfine: Try this:
<suitsmeveryfine>fatal: previous rebase directory exists
<Jookia>git rebase --abort ?
<suitsmeveryfine>"It looks like git-am is running. Cannot rebase."
<Jookia>git am --abort ? I'm not sure how to recover from git am failing
<suitsmeveryfine>maybe remove the dir ".git/rebase-apply"?
<Jookia>I don't know
<Jookia>That may break things
<Jookia>what's git status say
<suitsmeveryfine>No it seems to be working now. It was just a bit slow at aborting
<suitsmeveryfine>I'm buildning now. Let's see if it works
<janneke>ACTION reverts postgresql again
<suitsmeveryfine>Jookia: build is complete but I still got the "/boot/grub" not readable error
<Jookia>suitsmeveryfine: Did you set your grub-configratuion (platform 'coreboot) ?
<suitsmeveryfine>No, I forgot that!
<Jookia>suitsmeveryfine: soo
<suitsmeveryfine>almost there
<suitsmeveryfine>I really like the way the configuration is done here
<civodul>mark_weaver: yeah an almost-full rebuild, because of Perl
<civodul>annoying, but we have to do it, i think
<suitsmeveryfine>Jookia: well I guess that I'm exited about the whole guixSD way of doing things
<Jookia>Ah, cool
<suitsmeveryfine>now it's finished. I got no GRUB error this time. Will now reboot.
<Jookia>Have fun
<remi>Hello roelj
<suitsmeveryfine>Jookia: thanks, it's working
<suitsmeveryfine>Confirmed to be working on a MacBook2,1 with full-disk encryption
<Jookia>Extra yay!
<Jookia>Speaking of that, have you figured out the touchpad settings?
<Jookia>I have a T400 and the touchpad doesn't have scrolling :(
<suitsmeveryfine>Jookia: no, I've been trying to debug it
<suitsmeveryfine>I almost thought I had pinpointed the problem, but no
<Jookia>Was it working in GNOME 3?
<suitsmeveryfine>no, not really, only sometimes
<suitsmeveryfine>like flipping a coin
<Jookia>Perhaps it'd be worth checking NixOS code
<pizzaiolo>suitsmeveryfine: that's what happens to me on xfce
<pizzaiolo>sometimes it works
<Jookia>Oh wow, it's DE-independent issues?
<a_e>civodul: Not almost, really complete! Only the bootstrap binaries are not recompiled.
<suitsmeveryfine>sometimes the list of modules, including synaptics, libinput and evdev get truncated
<Jookia>a_e: I don't think they are?
<suitsmeveryfine>and sometimes you get a nice list
<Jookia>suitsmeveryfine: truncated?
<suitsmeveryfine>everything in one very long row
<a_e>No, they are not. But they appear as packages on hydra. A fixed output derivation I suppose.
<civodul>a_e: if you look at commencement.scm, you'll see that, strictly speaking, it's not a full rebuild ;-)
<suitsmeveryfine>Ludo thought this might be the problem and so this is what I thought also
<civodul>but yeah, you're right
<suitsmeveryfine>but today I had a case of a "non-trunkated" log file with a non-working touchpad
<suitsmeveryfine> that doesn't seem to be the problem. I've also tried to build without libinput and evdev but then I get no working keyboard.
<pizzaiolo>I wonder what's the cause for the touchpad issues
<JeanLouis>is: sudo rm -rf /gnu safe if I am testing guix on Debian, and want to start again?
<suitsmeveryfine>I have no idea, but the Shepherd is new in his profession and can't keep track of all the gnus
<a_e>JeanLouis: Yes, but then you should also remove all other traces. It depends on how you finally installed...
<rain1>The sheperd init system is really interesting!
<civodul>JeanLouis: it is, but make sure to also remove /var/guix (or whatever it's called)
<lfam>JeanLouis: You will also want to remove your local state directory. If you installed with the binary installer, that's in /var/guix
<a_e>Did you do a "make install"?
<rain1>JeanLouis, why not try guixsd in qemu?
<a_e>Or /usr/local/var/guix, from what I understood.
<rain1>it would be a little slower but it's nice to try
<suitsmeveryfine>rain1: I'd really like to try your setup with encrypted /home tonight but I've been told that the system is broken.
<JeanLouis>rain1: I tried guix boot on USB, but on qemu, not, it is same hard.
<rain1>JeanLouis, for qemu you can use a file, no need for a USB!
<Jookia>suitsmeveryfine: Someone set up encrypted /home. Why not try an encrypted / ?
<rain1>suitsmeveryfine, im not sure what is broken? would like to read about it
<a_e>Jookia: suitsmeveryfine: Did you read my message to guix-devel? I managed an encrypted /, unencrypted /boot without libreboot, following iyzsong's lead.
<JeanLouis>rain1: qemu is processor emulator
<rain1>JeanLouis, yeah
<Jookia>a_e: Nice!
<JeanLouis>so it will be slower I guess
<rain1>JeanLouis, that's true but it's ok for testing-
<rain1>a_e, i would be curious if guix system reconfigure breaks it?
<rain1>when I added myself to the kvm group and reconfigured it wasn't bootable anymore
<suitsmeveryfine>Jookia: I've got encrypted / on the MacBook but for some reason my libreboot-T60 refuses to decrypt volumes.
<JeanLouis>rain1: I try by this: and I failed due to system locales missing
<a_e>rain1: Yes. Right now, there are lines to add to grub.cfg. You could do so after each reconfigure. Ultimately, it would be nice to have guix take care of it.
<JeanLouis>so I have to make it somehow
<Jookia>suitsmeveryfine: Have you updated Libreboot to unstable?
<rain1>a_e, but even after re-adding my grub lines it would not boot
<rain1>I should try to reproduce it in a VM I guess
<suitsmeveryfine>Jookia: no, I'm using libreboot from before stable (July 2014) with a GRUB menu from 2016
<a_e>Strange. But I think I did not even try it. I used just a test machine to find out what needs to be done.
<suitsmeveryfine>on the newest revision of libreboot the keyboard stops working every other boot
<suitsmeveryfine>apparently this is a problem that affected T60 Windows users several years ago and it disapperared with a lenovo Bios upgrade. Apparently libreboot has instead regressed in this regard. I've not bothered to investigate this yet.
<suitsmeveryfine>a_e: interesting. I'm not on guix-devel. I should sign up.
<Jookia>You should
<a_e>But in fact, it was not to guix-devel, but to a bug report:
<suitsmeveryfine>Unfortunately I've not been able to get a fully working GuixSD on any of my computers so it's not yet my main OS.
<rain1>why not try without encryption
<rain1>i don't think encryption is 100% yet
<suitsmeveryfine>Yes, I'd like to install on the T60 with either no encryption or just /home but people tell me that tonight the USB installer won't work
<JeanLouis>rain1: if I run guix package -i glibc-locales as root, does that mean that normal user have no access to that?
<rain1>I don't know
<Jookia>It means they need to do the same
<JeanLouis>Jookia: alright, and I hope same package can be re-used for user?
<a_e>JeanLouis: Yes. On Guix, root is not special. Every user is responsible for themselves.
<Jookia>JeanLouis: Yep
<JeanLouis>aha like that?
<JeanLouis>so I don't need root at all?
<suitsmeveryfine>rain1: Maybe it will work if I create my own installer image from a git checkout, but I haven't tried that yet.
<a_e>The package appears only once in /gnu/store.
<a_e>Then there are symbolic links to the store from each profile.
<Jookia>JeanLouis: No root needed
<JeanLouis>I mean I don't need glibc-locales for root?
<rain1>i had better luck with the official dowload of guixsd than one I build myself
<Jookia>suitsmeveryfine: What are you hitting
<Jookia>JeanLouis: Not unelss you plan to run as root
<rain1>but I haven't read any of this you said about the USB not working
<a_e>Root is needed for running the daemon (and for the installation of course).
<JeanLouis>a_e: ok alright, thanks Jookia.
<suitsmeveryfine>Jookia: I've not yet tried to install on the T60 tonight
<JeanLouis>and if one user installs one package, the package need not be downloaded again?
<Jookia>Yes, unless you update (you can even update in another profile to keep the old ones around)
<JeanLouis>yes very nice, let me try first as root, then as user, to test if there is no download
<JeanLouis>In the end, I can put USB with GuixSD -- wget my-operating-system.scm and get only those software packages I want to?
<Jookia>i guess
<JeanLouis>Jookia: I am watching videos from FOSDEM, there are few. And I know the future is shaped by Guix -- but I would like to see the future target or plan, if you know some reference, how GuixSD will change future of free software, let me know
<Jookia>JeanLouis: See Docker, NPM, package managers that download dependencies or lets you deploy programs without caring about the underlying OS packages? Guix does away with that
<JeanLouis>Jookia: yes I understand, there will be sanity.
<JeanLouis>I got a problem, as root, I cannot run nothing
<JeanLouis>aha I solved it, it was wrong PATH
<JeanLouis>The following environment variable definitions may be needed:
<JeanLouis> export PATH="/root/.guix-profile/bin:/root/.guix-profile/sbin"
<JeanLouis>I did that, and had no "ls" any more
<JeanLouis>because root has installed guix -i glibc-locales, I got the above message
<a_e>JeanLouis: Do the following:
<Jookia>I like to just source ~/.guix-profile/etc/profile
<a_e>export PATH="/root/.guix-profile/bin:/root/.guix-profile/sbin":$PATH
<JeanLouis>a_e: let me try
<a_e>Or as Jookia said, that is probably even better.
<a_e>JeanLouis: Now it is too late.
<a_e>Log out and in again.
<JeanLouis>yes works
<a_e>The line I gave adds the new path in front of the old one.
<JeanLouis>yes I know that, I just got feeling that I must keep it like guix told me to keep it
<JeanLouis>now I did install glibc-locales, took long time, and now I still get problem with locale
<Jookia>did you set GUIX_LOCPATH
<JeanLouis>solved solved, yes, I forgot it again sorry
<JeanLouis>and on Debian I started guix-daemon with: service guix-daemon start
<JeanLouis>I have it working now, very nice.
<JeanLouis>guix correctly recognizes glibc-locales package that was previously installed by root, so there is no new download
<a_e>See! :-)
<JeanLouis>now I deletex ~/.guix-profile
<JeanLouis>how do I get it back again?
<a_e>Grafting texlive-texmf takes a long time. It "timed out" after one hour on my Novena, although Guile can use all four cores.
<a_e>JeanLouis: Create a symlink to /var/guix/profiles/per-user/LOGIN/guix-profile
<a_e>(assuming that /var is your localstatedir)
<JeanLouis>that guix-profile per-user, that is something like /etc/skel ?
<a_e>It is just a way to handle different profiles per user...
<a_e>Follow the links, and you will see what happens. This is what makes it possible to roll back.
<JeanLouis>yes. Now when I have nice functional package manager, it is time to read info on guix.
<a_e>Yes, reading the documentation is a very good idea!
<a_e>That is what it was written for!
<civodul>a_e: re texlive, it's a known issue, see #19811
<a_e>I see. Well, it is not a bug. But also not a feature.
<civodul>i think mark_weaver has ideas on how to optimize (guix build grafts) :-)
<a_e>Great! Ideas are what we need.
<JeanLouis>No menu item `guix' in node `(dir)Top'.
<mark_weaver>civodul: actually, I already have an implementation that makes it much faster, but I think it's not working quite right yet
<mark_weaver>(I've been poking at it on and off over the last couple of days)
<civodul>oh, cool!
<civodul>i'm a bit ashamed of that code
<civodul>but it's also hitting the performance limits of Guile 2.0
<mark_weaver>the basic idea is to scan for the '-' at the end of the hash. as we scan, whenever we encounter a character that's not nix-base32 (which is most bytes), then we can skip ahead 33 bytes
<JeanLouis>I see, I can use guix in multiple instances without problems, which is good in comparison to apt-get
<mark_weaver>and I read 1 MB bytevectors and scan them, with overlaps of 32 bytes between scans
<civodul>ok, i see
<mark_weaver>I just need to finish debugging it
<mark_weaver>civodul: do you know how to fix the problem where we end up with multiple variants of the same grafted package?
<mark_weaver>maybe something needs to be sorted to be deterministic?
<JeanLouis>I have followed the binary guix install, and it is in /usr/local/bin -- but I don't see info guix...
<suitsmeveryfine>a_e: I was just about to try your unecrypted /boot + encrypted / setup but now I remember this: on the particular computer I will try this on I won't be able to access GuixSD's GRUB menu.
<suitsmeveryfine>I have no working screen inside GRUB
<a_e>Access the menu? You mean you will not see it on an attached screen?
<suitsmeveryfine>I can see libreboot's GRUB menu in GNU Screen, but not the next loaded GRUB menu
<suitsmeveryfine>neither Parabola's nor GuixSD's
<a_e>If everything goes well, you do not really need to see it...
<a_e>It will start asking your password on the first grub screen; then move on automatically to the second one; and after a few seconds boot, asking your password a second time.
<suitsmeveryfine>a_e: so I won't need to modify the GRUB menu?
<civodul>mark_weaver: yes, i think there's a sorting issue somewhere, but i haven't found where it comes from
<suitsmeveryfine>a_e: Then I misunderstood your post on the email list,
<civodul>mark_weaver: well i think it's the order of the 'grafts' list passed to 'graft-derivation'
<a_e>No. You need to modify the grub.cfg.
<suitsmeveryfine>"What is needed are the following two lines at the beginning of grub.cfg: insmod luks cryptomount -u 1aa..."
<suitsmeveryfine>a_e: do you mean inside the USB installer?
<a_e>So you can do a "guix system init", then edit the installed grub.cfg, then boot.
<mark_weaver>suitsmeveryfine: you might be able to fix GuixSD's grub menu so that you can see it, by commenting out line 273 of gnu/system/grub.scm, the one that says "#$sugar"
<a_e>_re_boot, I mean.
<suitsmeveryfine>mark_weaver: why do you think so?
<a_e>Since when you do "guix system init" inside the USB installer, it does not reboot automatically. It just installs everything.
<suitsmeveryfine>mark_weaver: I've got an LCD that's not entirely compatible with coreboot
<mark_weaver>one of the things that the "#$sugar" (i.e. eye-candy) does is "terminal_output gfxterm" which may have the effect of switching the output away from the serial console and to a screen that you can't see
<suitsmeveryfine>mark_weaver: I see, so that I can see it in GNU Screen. I will try this!
<mark_weaver>we should probably be installing a separate libreboot_grub.cfg (or is it coreboot_grub.cfg now?) that avoids things like that
<Jookia>mark_weaver: I have a patch that that can be built on
<a_e>suitsmeveryfine: But even then, you should edit the grub.cfg _before_ you reboot.
<Jookia>It already creats coreboot_grub.cfg and friends
<paroneayea>time to update otr
<mark_weaver>Jookia: cool! I'm sorry I haven't found time to review your patches yet. I'm overloaded with other stuff right now
<mark_weaver>paroneayea: already done
<a_e>paroneayea: You are late to the party!
<suitsmeveryfine>OK! I will do that. Is the first OS configuration you posted working as is?
<rain1>i upgraded otr as well :)
<paroneayea>guix is too fast!
<Jookia>mark_weaver: It's cool, there's still work in progress (I'm replying to them)
<Jookia>replying to my RFCs with new RFCs :P
<mark_weaver>I actually tried to update it a while ago, and as I was about to push, I found that lfam had already pushed it :)
<suitsmeveryfine>a_e: also, how should I mount the encrypted /dev/sda2 inside the USB installer?
<a_e>That you need to do by hand. Set it up using cryptsetup:
<a_e>cryptsetup luksFormat /dev/sda2
<a_e>cryptsetup luksOpen /dev/sda2 home
<a_e>mkfs.ext4 /dev/mapper/home
<a_e>mount /dev/mapper/home /mnt
<a_e>mkfs.ext4 -L boot /dev/sda1
<a_e>mount /dev/sda1 /mnt/boot
<suitsmeveryfine>a_e: I already did this but called it "guixsd" instead
<a_e>(I just typed from memory, please correct my errors :-))
<suitsmeveryfine>I'm doing encrypted /, not encrypted /home
<a_e>Right. I called it "root".
<a_e>Just adapt your mapped-device to the name you chose.
<suitsmeveryfine>But don't I need to mount /boot as well?
<a_e>These are the last two lines above.
<a_e>You mount / to /mnt, so /boot to /mnt/boot
<a_e>Then "guix system init myconfig.scm /mnt" treats /mnt as /
<suitsmeveryfine>In my history I see that I've run the command `mount /dev/sda1 /mnt` (i.e. my small /boot partition)
<suitsmeveryfine>I guess that's wrong
<a_e>As the / it will become when rebooting.
<a_e>When you reboot, you should then get /boot/boot and so on.
<JeanLouis>substitute: warning: failed to install locale: Invalid argument -- even if I did set export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
<a_e>JeanLouis: The warning can safele be ignored.
<a_e>I think it comes from the daemon, which does not have the locales, or something like that.
<JeanLouis>a_e: yes like from one of builders probabyl
<Jookia>I can't wait to do a proposal to radically change the way the OS configures swap/mapped/filesystem devices
<JeanLouis>and when I see some weird behavior, of package, to whom to complain?
<Jookia>JeanLouis: bug-guix if it's a bug, help-guix if you're buggy, guix-devel if you want to make bugs
<JeanLouis>like mutt: Error in /home/data1/protected/.mutt/muttrc, line 32: header_cache: unknown variable
<suitsmeveryfine>So: can I run `guix pull` from the USB installer now, or should I download an earlier revision of GuixSD?
<paroneayea>dang, who has ops
<paroneayea>"bug-guix if it's a bug, help-guix if you're buggy, guix-devel if you want to make bugs"
<paroneayea>that should be the topic ;)
<JeanLouis>ok that is bug in mutt documentation, no problem
<janneke>paroneayea: and #guix if you're ... ?
<Jookia>a bug on the wall ;)
<suitsmeveryfine>a_e: I don''t quite understand this point: "cryptomount -u 1aa... where 1aa... is the result of "cryptsetup luksUUID /dev/sda2"."
<JeanLouis>guix package -A|wc
<JeanLouis> 2615 10460 138349 <-- this will hopefully grow to over 44,000
<JeanLouis>41,4400 to go
<rain1>I'm not sure how I'll work with UUIDs in qemu
<rain1>no copy paste ...
<rain1>could be really troublesome
<a_e>suitsmeveryfine: Just run the command "cryptsetup luksUUID /dev/sda2", it will give you a uuid.
<a_e>And then add the corresponding cryptomount line.
<suitsmeveryfine>OK. I need to debug my OS config first. I must have a missing paren or something
<a_e>If you do it by hand, you may as well use the line in my first message: cryptomount hd0,msdos2
<a_e>The uuid would just be something to make it more automatic.
<JeanLouis>where do I find predefined package definition to adapt it for my system needs? Like mutt.scm?
<a_e>This could be used when programmatically writing grub.cfg by "guix system init" or "guix system reconfigure".
<a_e>JeanLouis: guix package -A mutt
<a_e>Please do read the manual!
<JeanLouis>I am reading info yes,
<a_e>./pre-inst-env guix build --substitute-urls= --timeout=10000 texlive
<a_e>timed out after 3600 seconds of silence
<a_e>Oh, I need --max-silent-time. Nasty!
<a_e>Maybe I should read the doc...
<JeanLouis>-A gives me: mutt 1.5.24 out gnu/packages/mail.scm:173:2 --- but that is where?
<a_e>How did you install? If you want to modify things and know git, it would be easiest to build from git.
<a_e>This is still possible even if you installed guix differently.
<JeanLouis>no I am learning guix
<JeanLouis>it gives me location of source, but not full path
<rain1>this is on GuixSD
<rain1>I don't know if it's the same with just guix on another os
<a_e>You can also do "guix edit mutt". But drepending on how you installed, you may or may not be entitled to modify this.
<JeanLouis>nothing on my alien system "Debian" in .config/guix no such directory
<JeanLouis>oh I found edit, nice
<a_e>The best is to just read the definition and then copy it somewhere else - look got GUIX_PACKAGE_PATH in the documentation.
<JeanLouis>yes there is option to install from file
<JeanLouis>and how do I find "package maintainer"?
<a_e>Now your mutt problem just comes from the .muttrc in your home directory, I think, which may be incompatible.
<a_e>It is all collectively maintained in guix.
<JeanLouis>yes it is just with new mutt version, no problem
<JeanLouis>collectively of course, but isn't it that packages are assigned to package maintainers?
<JeanLouis>for example, to suggest ./configure option to mutt, like --enable-hcache
<JeanLouis>for example, I tried changing: at line 1008: of mail.scm: "mail.scm" 1008: "--enable-hcache" and now: guix package -f mail.scm fails with: ERROR: In procedure string-prefix?: Wrong type argument in position 2
<a_e>You can create a patch, try it out and send it to the mailing list.
<a_e>But in that case, you should start from a current git checkout.
<CompanionCube>ACTION is not using guix texlive because of it being a huge monolithic package
<a_e>That is what all developers use. And the line numbers are different.
<a_e>CompanionCube: Did you try texlive-minimal?
<a_e>Maybe it is enough. It is a medium-size monolithic package :-)
<a_e>Texlive is not made to be functionally split into pieces.
<rain1>I had to make my own version of the pari gp package without docs
<rain1>to install it
<JeanLouis>a_e: I did guix edit mutt, saved mail.scm in $HOME, and tried installing without patching or changes: guix package -f mail.scm, and I got this:
<JeanLouis>while my understanding it, that it should be possible to install it from file.scm
<a_e>I am happy to have all of texlive available in one go. No more sitting on a train and missing a crucial package.
<JeanLouis>or at least say "installed"
<a_e>Not sure what happened there.
<a_e>I think you need to add a line "mutt" at the end of the file.
<a_e>Because: guix package --help
<a_e>-f, --install-from-file=FILE
<a_e> install the package that the code within FILE
<a_e> evaluates to
<a_e>But it does not evaluate to anything, it just contains a number of definitions.
<a_e>So you need to return a value, namely the variable mutt.
<a_e>Better do the following:
<a_e>mkdir -p $HOME/gnu/packages
<JeanLouis>a_e: try yourself, edit any file, (don't change it, save it), and try installing by using the file