<lyr3>hey the guixsd installer issued GUIX_WARN_DEPRECATED set to detailed or no...how I set it? maybe (GUIXX_WARN_DEPRECATE 'no)? <marusich>lyr3, you probably need to unset the environment variable before running the code/command in question. <marusich>Also, did you mean GUILE_WARN_DEPRECATED? I don't think Guix uses an environment variable named GUIX_WARN_DEPRECATED. <marusich>I think you just need to set the environment variable GUIX_WARN_DEPRECATED to what you want. <lyr3>you mean a bash env var? <lyr3>export GUIX_WARN_DEPRECATE=detailed? <marusich>For example, you could invoke "GUILE_WARN_DEPRECATED=no guix package --show=hello" I suppose <marusich>Yes, you could set and export the variable in one bash command like that, too. <marusich>The possible values appear to be documented in "(guile) Environment Variables". <marusich>Do you know how to view that manual section? <lyr3>installing guixsd out of bravery haha <marusich>No problem; everybody starts somewhere. :-) Do you use Emacs? <lyr3>stallman > emacs > gnu > guixsd <lyr3>thats pretty resume it all <marusich>You can view all GNU software manuals, which are written in TexInfo, by invoking 'C-h i', typing m followed by "guix". <marusich>Er, well, that's how you view the guix manual <marusich>but you can vie all manuals in the same way <lyr3>oh, cool...that will come in hand when I am offline <marusich>If you're new to this, it would be a good idea to press "h" after typing "C-h i". It will open up a tutorial for how to use Emacs to read the manuals. <lyr3>Ive hear about some (woman) <marusich>If you don't have Emacs handy, you can also view the manuals by executing "info" on the command-line. The interface is similar; the help tutorial I mentioned just now also discusses that reader. <marusich>Most of the GNU software is written in TexInfo. A well-written TexInfo manual is much easier to navigate than a generic man page (woman page? I haven't used woman myself, so I don't know how different it is). <lyr3>Do you have installed GuixSD? <marusich>Here's an example to whet your appetite. Suppose you're reading a Makefile. You see a symbol like $<. What's that? Well, you can easily look it up in the index of the GNU Make manual. If you have it installed ("guix package -i make", I think), after opening the manual, you can just type "i", then "$<", and hit enter, and it'll take you to exactly the page where it's defined. <lyr3>Does that guix system init generates grub entries of installed distros? <marusich>No, it doesn't create entries for other distros automatically. However, you can add them manually if you want, by declaring an appropriate "menu-entry" in your operating system configuration file. <marusich>If you want to do that, the details can be found in the manual here: (guix) Bootloader Configuration <lyr3>$ grub-mkconfig -o /boot/grub/grub.cfg, works on terminal after everything is installed, doesnt? If so, then its similar to gentoo <marusich>That might work, yeah, but it isn't really the expected way that users will manage their bootloader configuration in GuixSD. <lyr3>wow, guixsd has another way to set grub entries? <marusich>Instead of manually generating the file, it is preferred that you declare what the file should contain in your operating system configuration file, and then rely on commands like "guix system reconfigure" to update the config. <marusich>The idea is that you should not have to destructively mutate your system, since it is risky. <lyr3>waaaaaat...brainfuck literally <pkill9>just put it in the file and you won't have to think about it <marusich>The benefit of doing it this way is that you can be confident that you will not break your system. <marusich>GuixSD makes sure to put old system "generations" into the menu entries, so if something goes wrong, at boot time you can always select an older generation to boot from. <pkill9>i think also your grub configuration would get wiped everyttime you run `guix systemr econfigure` <marusich>It's like having instant access to previous versions of your system. <marusich>Yes, that's also true. Your manual modifications will not be saved. <vagrantc>guixsd kind of has built-in configuration management ... if you've ever used puppet or ansible or whatever ... <lyr3>reconfigure is literally generating copies of a earlier state of the whole system? <vagrantc>so managing configuration files by hand kind of breaks that <marusich>The motivation for doing this is to follow a functional paradigm for system configuration: you declare inputs, you get a system as output. It's all immutable, so it's easy to flip from one version of the system to another. <lyr3>so its an incremental copy? <marusich>When you run "guix system reconfigure my-config.scm" it will build everything that is declared in your config file. If anything is the same as a previous generation, the new generation basically will re-use what was built before. All these built components reside in "the store", which is a directory at /gnu/store that contains immutable build artifacts which are managed by the guix-daemon. <pkill9>there's basically a link to each generated state <marusich>So, it automatically shares previous build results with the new generation. Your new system generation is a symlink (like a pointer) into the immutable store. <marusich>Because it's generated in this way, it is trivial to flip the symlink back to a previous version of the system atomically. <lyr3>Does Intel i7 runs well guixsd? <marusich>I don't have one, but I don't see why it wouldn't. That's an x86_64 CPU, which is well supported on GuixSD. <lyr3>The Guix documentation goes deep to that detail on guix reconfigure? <marusich>lyr3, Guix follows a "functional" paradigm; that's why we prefer to declarativly define the system, instead of destructively modifying the system in place, like most other distros do. For more information, the following manual sections are probably helpful: <marusich>(guix) Introduction, (guix) Package Management, (guix) GNU Distribution (in particular (guix) System Configuration). <pkill9>i like the `info guix` page, it's like the webpage with links <vagrantc>ACTION generally finds emacs to be a useable text editor... and mail client ... and struggles with the other built-in features <marusich>lyr3, and personally, if you find the "functional" aspect of this system exciting, I highly recommend reading the first 15 pages of Eelco Dolstra's Ph. D. thesis. It explains very clearly the problem that Nix solves. Under the covers Guix is basically the same as Nix, so everything in the intro applies to Guix, also. <lyr3>I do like, scheme is what got me here! haha <lyr3>info, never tried that one on cli <marusich>Yeah, Guix is basically the same as Nix, but it uses Scheme for everything above the nix-daemon. In Guix, the nix-daemon is caled guix-daemon. <lyr3>I beg your pardon, its time to install GuixSD for real! haha <marusich>Nix uses an "External Domain Specific Language" - nix expressions - to define packages and configure the NixOS system. In contrast, Guix uses Guile scheme for the same purpose. <thomassgn>lyr3: I ran guix on an intel i7 for a year or so. Works as expected <lyr3>Ive read some of the Guile Manual...got really interested in GuixSD by reading it! <lyr3>thomassgn: haha...I am safe then! <pkill9>what's the biggest conceptual different between Guile and Nix Expression Language? <lyr3>If everthing goes well, adieu Debian <pkill9>lyr3: you can also run Guix on debian <lyr3>Nah, I want full freedom <pkill9>it's a good way to get to grips with it <thomassgn>the nix language is a DSL, not meant for solving problems outside of it's usecase. <thomassgn>it is AFAIK turing complete, but not particularly good at other problems than packaging. <lyr3>lemme just git push some files before bricking my PC trying installing GuixSD haha <marusich>It was written by Ludovic Courtès, one of the Guix maintainers. <marusich>pkill9, you might find that interesting also. <thomassgn>guile is a full scheme lisp language, which, AFAIK is designed to easily be used from C, and to easily use C from guile. <lyr3>marusich: I will read it all! <thomassgn>I also like that guix has both SICP and th gnu C manual as packages for info... :) <marusich>From what I've heard, it sounds like the Nix expression language suffers from limited extensibility. It is good, but people wanted to do more, which is awkward since it started just as a specific-purpose EDSL. <marusich>Well, E for external, I guess, not E for embedded. That was ambiguous :) <lyr3>I hope that soon I will helping Guix team improving it <thomassgn>this. It's the main reason I switched from nixos <marusich>With Guile scheme, there is already great support for extensibility. And htere is an ecosystem surrounding it, although it may not be as big as an ecosystem surrounding C or Java. <marusich>So, it's a bit more complicated, I guess, but the idea is that its expressive power is better than an external domain specific language like nix expressions in the long run. <marusich>lyr3, it's a really welcoming project. We would love to have you helping out! <lyr3>hey..it really takes it time to download everything haha <lyr3>hey, it is issuing failed to install bootloader <lyr3>hey, guixsd failed to install bootloader efi <lyr3>hey, GuixSD is issuing: failed to install bootloader <lyr3>I will try installing GuixSD late...meh <rekado>lyr3: please send the error output and your system configuration file to help-guix@gnu.org <rekado>lyr3: it may be easier for fellow Guix users to help you there. <rekado>(I remember having some problems with GuixSD and EFI before, but I’m not an expert in that area.) <jD91mZM2>Is the "st" terminal configurable somehow? <oleo>yah, my bootloader failed too <soundtoxin>IIRC you have to configure the actual source for st, it's the main reason I have not switched to it yet <oleo>i think i specified the wrong device <oleo> /dev/sda1 stead of /dev/sda <oleo>cause mbr is on disk level not partition <oleo>i'm just redoing the init <oleo>seems to work with fetching packages etc <oleo>what happens when i init multiple times ? <oleo>i hope it resolves all issues <oleo>EFI installation is all outlined in the manual <oleo>tho i have chosen basic dos neither gpt nor anything else <oleo>not having virtualization enabled chips sucks ..... <oleo>i can't use x86_64 systems on x86_64 not having it <oleo>i can only use 32bit systems <oleo>tho on my laptop i can ! <ng0>jD91mZM2: yes, by doing the same configuration as every other OS does. You get the source, apply your changes, create a patch from it (or, if trivial, guix' substitute function, and create a custom st package <ng0>once upon a time I had a public example for this somewhere <jD91mZM2>ng0: So no special case, like NixOS lets you override the `conf` variable? <oleo>i removed the mapped devices module dependency <oleo>and deleted the encryption part from my config.scm <oleo>i just want it all basic <ng0>I ended up maintaining my own st etc these days. but this is how it can work. <ng0>disclaimer: I have no idea what's in the file, I just published the repo back to cgit.. sorry if anything bad is in it <oleo>i havent tried the setup on my laptop tho <ng0>it's obsolete and unused on my end. <oleo>i just booted into the image and already got some errors, maybe i should have just ignored them <oleo>about some missing drivers mostly <oleo>not sure it would fetch some on it's own when installing, for a dell laptop <oleo>as dell specific stuff is probably proprietary <oleo>i hope just there are generic drivers .... <oleo>i'll try it on the laptop too <jD91mZM2>ng0: What obsolete repository? By the way, that's just a patch. Can you replace the config entirely? <ng0>if you replace it in a source that's still a patch <ng0>you could copy a local file into the source and remove the original one.. <ng0>(copy does not mean manual copy here) <ng0>I think what you are getting at is trying to understand how to map "kept user modified config files" concepts as in Gentoo and Archlinux etc to Guix, right? <jD91mZM2>Actually what I was mostly thinking was just "does st have a special case in GuixSD like it does in NixOS so I can avoid manually wrapping the package" <oleo>installation finished. No error reported :) <ng0>a hypothetical "suckless-build-system" could read and write configs through the package definition, but suckless has too little packages to justify this. of course if you throw these build system definitions in your local path guix would catch them, but that's up to you. I found patches to be more predictable. <ng0>I have encountered some upstreams cnfiguring their builds similar to suckless. so I might end up doing this when I get too annoyed by a stack of repetive work <ng0>maybe describing how to modify st as an example would help to get people started, it's a frequent question. <IntoxicatedHippo>What could be causing this? "sudo: /gnu/store/...-profile/bin/sudo must be owned by uid 0 and have the setuid bit set" <mubarak>IntoxicatedHippo: did you add your username to sudoers file via # visudo? <mubarak>IntoxicatedHippo: did you add your username to sudoers file via # visudo? <oleo>ok, i booted and now am in it <mubarak>IntoxicatedHippo: also which groups you are in when you run # groups? <oleo>ok guix pull now gets some bootstrap files and binutils and gcc etc..... <IntoxicatedHippo>I found the issue, I'm meant to be using /run/setuid-programs/sudo, but when I source /run/current-system/profile/etc/profile the wrong sudo gets added to the path <oleo>how do you specify the network in the config file ? <oleo>i can always do a ifconfig blah up dhclient -v blah <ng0>IntoxicatedHippo: try .guix-profile/etc/profile <oleo>allright it still proceeds <oleo>patch sheban, perl not found on $PATH <davidl>How can I set a specific interface for the ssh service? Only the port option is mentioned in the manual and source, providing ip:port gives type error. <uniq10>How can I generate a <derivation> record corresponding to a package? <sahithi-ihtihas>what does the above error specify ?? I have got that when tried to write output from lamda expr <g_bor>we have been talking about something like that before fosdem. <g_bor>The idea was to list packages containing a vulnerability, the packages depending on these, and the profiles affected. <davidl>then you got a start to work from :) unless you want it to be just scheme. <g_bor>We also discussed that this detection functionality, or maybe even more linting metadata should be incorporated to channel information, when channel become a possibility. <g_bor>Then it would be possible to filter package sources by vulnerabilities, a unique security feature <g_bor>Yes , we have a channel proposal, it is in a draft stage <pkill9>davidl: I just tested your cve script, it sends the output to stderr, i had to do 2>cve.log to save it, also it makes an empty cve.txt file, and it doesn't run when this file exists <g_bor>it basically goes like, and organization can publish a list of guix packages, in a versioned repository. One can authorise such a source, and use definitions, or even substitutes from there. <davidl>pkill9: hmm, alright. I'll fix that. it's the guix lint -c cve that sends to stdout, I forgot about that. <pkill9>davidl: next step is to make the script fetch the description of the CVE from the website and display it in the log for each one :D <pkill9>well, stdout, not neccessarily log <pkill9>it's pretty insightful, there's a bunch of stuff with vulnerabilities on mine <g_bor>I would proposed to move the strip-jar-timestamps procedure to java-utils, but it might well be, that leaving the ant-build-system alone, and duplicating that code in the ant-bootstrap package definition would be cleaner. Do you think there is a better way? I currently see these two options, but I might be missing something obvious. <g_bor>We also discovered, that it would be nice to add some capability to the linter to print custom notices, or something like that. <g_bor>We have a possibility to suppress a cve warning, but we do not have the tool to add one. So sometimes it happens, that a cve is not reported, but the developers know, that the package is affected <davidl>pkill9: possibly :-) Im not sure that would be a good thing since you lose some overview. I considered to make lines org-mode-style, so you can put specific info like that in org-mode drop-down stars ('*' '**' etc). <civodul>davidl: nice indeed, i came up with the name 'guix health' for such a command :-) ***jonsger1 is now known as jonsger
<efraim>I was thinking about --recursive for guix lint, so you could also check all the dependencies of your installed packages also <efraim>Mostly for CVEs and upstream updates <g_bor>civodul: do we have anything to do currently about GSoC? Recently I wasn't on irc, but I checked the mailing list. I did not yet see too much related activity. <g_bor>I've also sent you the slides from my talk yesterday on the Hungarian Free Software Conference. The talk went great, the room was full, and it was really nice to present about this great software! Thanks to the community for making this possible. <civodul>g_bor: oooh, didn't know you were giving a talk, sounds cool! <civodul>re GSoC, i haven't seen much activity <civodul>i think tomorrow is the end of the community bonding period <civodul>so we'll have to decide whether or not to put an end to some of these projects <civodul>based on the activity during that period <g_bor>ok, tomorrow I will be available for discussion here. <ng0>On a recent commit, pulled and built 10 seconds ago, I get an error for a file which had been removed in march: guix challenge: error: racket-fix-xform-issue.patch: patch not found <uniq10>hi, when I am in ./test-env I keep getting this error: "unexpected Nix daemon error: guix download: error: lstat: No such file or directory: "/home/uniq10/guix/guix/gnu/packages/bootstrap/x86_64-linux/guile-*" <civodul>uniq10: it comes from the 'guix download' command in ./test-env <uniq10>civodul: is it harmless. Can I ignore it <uniq10>civodul: Sorry. Yeah with a question mark. <civodul>it's a genuine bug, i wonder why we didn't notice before <civodul>but you can safely ignore it, uniq10 <ng0>civodul: I simply wanted to run against all packages <efraim>I think it's worth filing a bug relating to the rust bootstrap source, if you're building for another arch you still get native arch's source <ng0>what I wanted to do is to run a test for reproducibility of the whole graph of our 2 public URLs + my private build server. <efraim>Also I can confirm that mrustc builds on aarch64 <efraim>I assume there are some packages that just fail? <ng0>but the patch file is weird. <ng0>I'll make clean and test again <ng0>who assembled the translated texi's oO boostrap fails for me now <ng0>automake: error: cannot open < ./doc/guix.fr.texi: No such file or directory <ng0>that was after running make clean.recursive <roptat>oh :/ in what folder is this executed? <ng0>*make clean-recusive <ng0>*make clean-recursive <roptat>I mean when it fails to find ./doc/guix.fr.texi where is it? <ng0>my script enters the environment with "guix environment --fallback --ad-hoc guix autoconf automake make guile guile-ssh pkg-config gcc-toolchain libgcrypt gnutls guile-json zlib bzip2 sqlite help2man gettext texinfo" <roptat>you will have to add po4a to your environment but that's not the issue <ng0>I'll try the new one, see if I simply forgot something <ng0>did you build guix with the translated texi? <ng0>because it's been a while since I had to clean <ng0>well.. what. git status: <ng0>deleted: doc/contributing.fr.texi <ng0> deleted: doc/guix.fr.texi <ng0>so I think you did not exclude it from make clean-recursive :) <ng0>when I restore them, it works <ng0>ah.guix challenge ignores to some degree the temporary unsetting of GPP <ng0>on my server it complains about a different package <ng0>without GUIX_PACKAGE_PATH="" it works, if your GPP is clean <lfam>Do we have any packages that can be used to read QR codes? <ng0>or what the name was <ng0>or like, read read.. human interaction.. ? <efraim>civodul: about robocut, qmake is in qtbase :) <efraim>I looked a bit harder and I've replaced (enlightenment-desktop-service) with (service enlightenment-desktop-service-type) <ng0>a build-server you include in the challenge is not good, even more so when you do it with the user profile that include custom repos: <ng0>7,653 store items were analyzed: <ng0> - 4,355 (56.9%) were identical <ng0> - 648 (8.5%) differed <ng0> - 2,650 (34.6%) were inconclusive <ng0>3 servers were used to compare <lyr3>I guess GuixSD does not like me <lyr3>at grub/efi install it does not budge <lyr3>maybe the configuration/desktop.scm file has some errors <ng0>the general idea, for a while, was to use the minimal template to install, and then reconfigure using desktop once you have rebooted <lyr3>Interesting. I can install GUixSD in a MBR partition...but as EFI ...meh <lyr3>it either does not see the /boot/efi, but the last one it lacks any bootloader packages <lyr3>There is any tutorial on how to install GuixSD through other Distro <efraim>the short version is to just run 'guix system reconfigure my-config.scm' <lyr3>Would be great if there is a iso of the .13 release <lyr3>So instead of guix system init /mnt/etc/config.scm /mnt <lyr3>guix system reconfigure /mnt/etc/config.scm <lyr3>well, wont hurt...I am about to give up for a while...or build aa iso myself from guix source code <civodul>lyr3: the latest release is 0.14.0 (not .13) <ng0>and I think .13 had no EFI support <lyr3>meh...I will try any other tools than dd to write it <efraim>i wonder if its dependant on the host kernel <ng0>works on x86_64 offloading to x86_64 <lyr3>oh and the /etc/configuration/desktop.scm file lacks a * on cons* of the fyle-system <ng0>failed: modprobe btrfs (on x86_64->x86_64 build machine) <efraim>didn't insta-fail on my other aarch64 board <efraim>the check phase, where it tries to modprobe btrfs <ng0>lyr3: cons* is for more than 2 elements. cons is okay here. <ng0>bah. git sucks at when it decides you "deleted" a file when you actually just renamed it and adjusted content before you commit it. <efraim>now that I copied btrfs-progs over, success from guix system build -e '(@@ (gnu system install) pine64-installation-os)' <efraim>from 'guix lint git' gnu/packages/version-control.scm:140:2: git@2.17.0: can be upgraded to 2.17.0. <pkill9>does anyone split up their guix user profile into different profiles? <alezost>pkill9: I do. I don't even have "~/.guix-profile" on my system :-) <lyr3>next release I will try again <jonsger>lyr3: what does not work? where do you need help? <lyr3>Everything works fine... <lyr3>But when it try to install bootloader in a efi partition <lyr3>I will try later...I just dont like to be defeated! haha <uniq10>Hi. Does building "hello" fail for anyone else from within test-env? (./test-env guix build hello). My build fails saying libstdc++ not found. <efraim>i don't think i've ever tried ./test-env <uniq10>This happens during the build of gcc-5.5.0. The linker is pointing to the libstdc++-5.5.0/lib in my test-tmp/store but this is empty. All the required libraries are in libstdc++-5.5.0/lib64. <uniq10>Anybody knows why this is happening. <lyr3>Still a total noob, cant help ya out! meh <uniq10>test-env uses the newly built daemon if exists, uses the temporary store, unsets user settings and runs the command in pre-inst-env <davidl>lyr3: last time I installed EFI you had to do it differently between install and reconfigure after you boot. It's a little weird. <davidl>lyr3: I think first install should be (mount-point "/mnt/boot/efi") and then after first boot you need (mount-point "/boot/efi"), and also you should use (type "vfat")) <lyr3>davidl: I KNEW...trying it later! <lyr3>GuixSD doesnt chroot as most distro that is a reasonable solution..if it works! <civodul>uniq10: building "hello" from ./test-env is very expensive because you have to rebuild everything <civodul>so instead, i'd recommend building one of the "early" packages when you're testing things <civodul>like: ./test-env guix build -e '(@@ (gnu packages commencement) gnu-make-boot0)' <civodul>check gnu/packages/commencement.scm to see which packages come after :-) <civodul>efraim: re 'guix refresh git', i've seen that as well, i wonder what's up! <uniq10>civodul: Thanks! I will try that.