<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)" <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>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 bug-guix@gnu.org 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? <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 <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' <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. <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>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 mirror.guixsd.org <rekado>I'll switch Guix at work to mirror.guixsd.org today <efraim>can guix-daemon be fed --substitute-urls? <civodul>i've changed the config to keep things in cache for 7 days ***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>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 <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 <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 <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>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 <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 ***fkz is now known as Guest29298
<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>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>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.. <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)? <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 ;- <civodul>ACTION prepares new security-updates branch <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 <Jookia>I also posted a reply patch fixing an issue in the RFC. Though maybe I already said that? <civodul>i'll look at this patch series, i swear! <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 <Jookia>For what it's worth I'm still trying to find testers for my patch, like paroneayea. :) <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>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/libpthread.so.0: 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>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 hydra.gnu.org, 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 hydra.gnunet.org <civodul>piyo: mostly likely hydra.gnunet.org didn't have the thing in cache yet, so it talked to hydra.gnu.org, which eventually timed out <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>for instance you can add new members, which is think non-admin cannot do <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 <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 <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 setup.py install" from source :) <Steap>I do not even get why we have eggs :D <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>Space is cheap, bandwidth is fast, everyone uses x86 <Jookia>Why should I bother with Unicode <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>or even worse, 'all i need is the BMP' <Jookia>there's an open source GUI library called librocket that deliberately only supports BMP <piyo>nobody uses the same 90% of unicode, is that how the quote goes? <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>So are we at that point with guix? I mean 90% and rapidly diverging? <Steap>civodul: I think they want to do reproducible builds using Docker <Steap>As long as I can still install my stuff from source... <civodul>the whole point of Docker is to use pre-built binaries <Steap>civodul: yeah but they distribute the built wheel <Jookia>Fantastic, binaries. Exactly what I wanted. <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 ;-) <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." <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 <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 <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>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 <Jookia>The difference is a lot of it is empty <JeanLouis>you have basically /bin/sh and nothing else inside? <JeanLouis>so scripts which requires /bin/ls will simply fail now? <JeanLouis>do you have some reference why is that better? <JeanLouis>I was watching FOSDEM videos, but obviously I did not pick that... <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? <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 <Jookia>most Unix is like that, where /bin/ls is a global variable <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 <Jookia>paroneayea: Who needs them to be in guix master when we can just graft all our updates forever? ;) <davexunit>paroneayea: the security-updates branch is currently being built <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 <Jookia>change it to $HOME/.guix-profile maybe <JeanLouis>/home/data1/protected/.guix-profile/lib/locale -- this is correct? <JeanLouis>OK at least I don't have that error any more <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>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. <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. <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 <davexunit>JeanLouis: okay, but it's not where the guix daemon really is. <Jookia>It sucks we have to explain this often <Jookia>/var/guix should probably be put in /gnu <JeanLouis>I was thinking simple configure will change environment <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 <Jookia>Then how did they install glibc-locales <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 <Jookia>It'll still search /usr/local/var/guix ? <davexunit>I'm sorry, I need to step away from this for awhile. <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. <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. <Jookia>-j then number of your CPU cores <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 <JeanLouis>I like the GNU approach, finally I feel "home". <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: Also I have the GRUB patch <Jookia>suitsmeveryfine: Do you want me to link it to you? <JeanLouis>Jookia: how many gnu/packages/*.scm did you make? <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>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/guix-hash.sh <JeanLouis>where do I start to make package definitions? <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>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 <davexunit>JeanLouis: most of us do not run 'make install' <paroneayea>what's the proper way to remove old system generations in guix? <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. <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 <davexunit>you can change it by running ./configure --prefix=/something/else/here <paroneayea>is there danger in running "guix gc" mid "guix environment" ? :) <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' <JeanLouis>davexunit: for testing, maybe I shall not install it, rather use the ./pre-inst-env, am I right? <davexunit>that was is especially convenient if you're going to write packages or otherwise hack the source <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 <davexunit>JeanLouis: you already have a daemon running <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 <davexunit>JeanLouis: oh you didn't use the binary installer? <suitsmeveryfine>Jookia: great, thanks. Will this break reconfigure afterwards or did you solve that issue? <paroneayea>JeanLouis: I don't know if the ./configure --localstatedir=/var is mandatory now or not <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>but starting from complete scratch gives you choice <davexunit>/usr/local/var is as good a place as any in that case <JeanLouis>error: creating directory `/var/guix': Permission denied <paroneayea>JeanLouis: yeah the tutorial you're reading uses sudo <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>JeanLouis: anyway, sounds like you're almost there <paroneayea>when I'm on Debian, I run guix-daemon in a screen. <JeanLouis>/gnu/store/wmrkm7rhn05fnim7wplz9p8vya4ph8li-profile/bin/guix <Jookia>Is that the same profile as before you reinstalled <paroneayea>JeanLouis: if you followed the instructions from my post <paroneayea>you shouldn't have a guix in your guix store probably <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 <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 dustycloud.org <paroneayea>*or* the one in the manual, using the binary tarball <JeanLouis>paroneayea: thank you for the blog, that is how I started. <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. <Jookia>suitsmeveryfine: What are you applying it to, master? <Jookia>suitsmeveryfine: Oh I think I know what's happened- Ludovic pushed a patch conflicting with my chnges <Jookia>I shall do that in a minute or so <suitsmeveryfine>I'm the only one awake now so I hope there will be less disturbance. <Jookia>git am --abort ? I'm not sure how to recover from git am failing <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) ? <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>Speaking of that, have you figured out the touchpad settings? <Jookia>I have a T400 and the touchpad doesn't have scrolling :( <Jookia>Perhaps it'd be worth checking NixOS code <pizzaiolo>suitsmeveryfine: that's what happens to me on xfce <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 <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 <suitsmeveryfine>but today I had a case of a "non-trunkated" log file with a non-working touchpad <suitsmeveryfine>...so 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. <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. <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. <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. <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? <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. <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. <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>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? <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>The following environment variable definitions may be needed: <JeanLouis> export PATH="/root/.guix-profile/bin:/root/.guix-profile/sbin" <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 <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. <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 <JeanLouis>and on Debian I started guix-daemon with: service guix-daemon start <JeanLouis>guix correctly recognizes glibc-locales package that was previously installed by root, so there is no new download <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. <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>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 <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. <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 <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. <civodul>mark_weaver: yes, i think there's a sorting issue somewhere, but i haven't found where it comes from <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..." <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>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 <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 <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? <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 <a_e>(I just typed from memory, please correct my errors :-)) <a_e>Right. I called it "root". <a_e>Just adapt your mapped-device to the name you chose. <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) <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. <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>"bug-guix if it's a bug, help-guix if you're buggy, guix-devel if you want to make bugs" <JeanLouis>ok that is bug in mutt documentation, no problem <janneke>paroneayea: and #guix if you're ... ? <suitsmeveryfine>a_e: I don''t quite understand this point: "cryptomount -u 1aa... where 1aa... is the result of "cryptsetup luksUUID /dev/sda2"." <JeanLouis> 2615 10460 138349 <-- this will hopefully grow to over 44,000 <rain1>I'm not sure how I'll work with UUIDs in qemu <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! <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>it gives me location of source, but not full path <rain1>~/.config/guix/latest/gnu/packages/mail.scm <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 <a_e>The best is to just read the definition and then copy it somewhere else - look got GUIX_PACKAGE_PATH in the documentation. <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 <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. <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>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 