<bavier`>mray_web: and the installation image is a live cd <mray_web>so i could download the qemu image and start it just like that? would it contain gnome? <bavier`>mray_web: yes, so you could install it in the vm <mray_web>sudo apt-get install gnome-shell won't work I GUESS... <mray_web>well, the reference manual does not seem to give away credentials to log in to the QEMU image.... is there a default I'm not aware of? <buenouanq>you add desktop environments from the os config <mray_web>sorry if i'm not making sense. i'm not the typical GNU hacker i guess. <mray_web>I'm just very new to guix sd and only know debian based distros <buenouanq>you add (gnome-desktop-service) to the (services section of the os config.scm and run $ guix system reconfigure .../config.scm <happy_gnu[m]>Pretty easy to install on top of your current distribution <mray_web>oh so you mean i shoudl isntall guix on Ubuntu?! <happy_gnu[m]>But maybe if you find it overwhelming you will feel is not worth (even though it is) <mray_web>I failed at getting packages for ubuntu - ironically :P <mray_web>is there a repo, or downlaodable *.deb files? <mray_web>ACTION is too unskilled to build anything <mray_web>that is one of the few thigns i really got :D <mray_web>and what it looks like it is superior to whatever snappy and flatpack have to offer <mray_web>ACTION is really the GUI kind of guye.... GNOME and all... <mray_web>awesome. neither is mine. $design guy here o/ <mray_web>so how do i get the guix binaries to run on ubuntu? <happy_gnu[m]>Now you have to make sure your terminal is in the directory <happy_gnu[m]>So you have to download the pgp key (that's why the third command) <happy_gnu[m]>Most times I've seen errors because the key was just downloaded and has not been set to trust by the user <mray_web>well GPG complains about signature not being trusted. but that is to be expected I guess <mray_web>hm mv: cannot move 'var/guix' to '/var/guix': Directory not empty <mray_web>happy_gnu[m]: /tmp$ sudo mv var/guix /var/ && mv gnu / <mray_web>so that the extraction should ahve worked. <mray_web>but an issue like that should probably be fixed on the homepage :P <mray_web>after that i pointed to the tar in the correct sub-folder <happy_gnu[m]>can you tell me with your words what does it say mray_web ? <mray_web>it seems to extract a file into a folder with some extra flags <mray_web>not sure if there is sensitive info in the filenames - is this a good idea? <happy_gnu[m]>is the file guix-binary-0.13.0.x86_64-linux.tar.xz there? <happy_gnu[m]>mray_web: I knew that this was going to happen... however I let this happen because is with errors that we learn <mray_web>sudo mv var/guix /var/ && mv gnu / mv: cannot move 'var/guix' to '/var/guix': Directory not empty <mray_web>still being in the same folder as the downlaoded binary <mray_web>maybe the mv command needs an extra property to recrsively move everythininside it? <mray_web>yes - not sure to what degree it suceeded <happy_gnu[m]>ok we gotta delete those directories, this is very sensitive so be very careful <mray_web>a /gnu/store and a /var/guix folder is inside my Downloads folder currently, yes. <happy_gnu[m]>when you do "ls /path/to/directory/" you can see what is in there without having to do a "cd /path/to/directory" <mray_web>ACTION uses nautilus to look inside the fodlers :P <happy_gnu[m]>ACTION knows mray_web will stop using nautilus eventually and will appreciate this class even more <mray_web>ACTION thinks happy_gnu[m] does not know mray well enough ;) <mray_web>the root folder dos not contain gnu though. there is no "/gnu" <mray_web>$ ls /gnu ls: cannot access '/gnu': No such file or directory <mray_web>$ ls ./gnu ls: cannot access './gnu': No such file or directory <mray_web>checking for the both gnu versions the hidden one seems to be gone now :P <mray_web>~/Downloads$ sudo mv gnu / mv: cannot move 'gnu' to '/gnu': Directory not empty <mray_web>my Downlaods folder now does contain a /gnu subfolder <happy_gnu[m]>you don't need to put / before gnu /gnu because / stands for root directory <mray_web>~/Downloads$ sudo mv gnu/ / mv: cannot move 'gnu/' to '/gnu': Directory not empty <mray_web>somehow mv seems to expect to handle empty folders?! <happy_gnu[m]>that is how ls knows that you are looking at the /gnu of downloads <mray_web>so i do everythign in the root folder, too now? <mray_web>happy_gnu[m]: the second command seems to not work <mray_web>so the first box contains two commands, right? <mray_web>so i need to replace teh # with sudo in my case? <happy_gnu[m]>Move the page up and see how first commands start with $ <mray_web>and the whole bunch is one alrge command <mray_web>it is a different output if i paste with middle click <mray_web>so what about the second box on that extra page? <mray_web>ok running the extra command did in fact not work. <happy_gnu[m]>systemctl enable guix-daemon && systemctl start guix-daemon <mray_web># guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub guile: warning: failed to install locale warning: failed to install locale: Invalid argument <mray_web>the bot has taken over and is erasing all my files with 4mb/s now .... or something liek that :P <mray_web>The following environment variable definitions may be needed: export PATH="/home/mray/.guix-profile/bin:/home/mray/.guix-profile/sbin${PATH:+:}$PATH" export GUIX_LOCPATH="/home/mray/.guix-profile/lib/locale${GUIX_LOCPATH:+:}$GUIX_LOCPATH" <happy_gnu[m]>export PATH="/home/mray/.guix-profile/bin:/home/mray/.guix-profile/sbin${PATH:+:}$PATH" export GUIX_LOCPATH="/home/mray/.guix-profile/lib/locale${GUIX_LOCPATH:+:}$GUIX_LOCPATH" <happy_gnu[m]>The following environment variable definitions may be needed: export PATH="/home/mray/.guix-profile/bin:/home/mray/.guix-profile/sbin${PATH:+:}$PATH" export GUIX_LOCPATH="/home/mray/.guix-profile/lib/locale${GUIX_LOCPATH:+:}$GUIX_LOCPATH" <happy_gnu[m]>export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <happy_gnu[m]>export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <mray[m]>ok to summarize: I kernel-assembled my computer to make it say hello to me in the console? guix is great :D <happy_gnu[m]>export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" mray@Y50-70:~$ <happy_gnu[m]>export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <happy_gnu[m]>export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <mray[m]>ok i think this just my general linux ignorance at work - i have jsut no clue about all that stuff. <mray[m]>ok supposed i want to install inkscape (which i have installed already) <mray[m]>it complains about the locale but continues... <mray[m]>happy_gnu: despite all the horrible problems it feels really nice to finally actually text guix(sd) somewhat! <happy_gnu[m]>just open it with a text editor and put the command: export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <mray[m]>thanks a lot for guiding me this far - i would NEVER have done that by myself. <happy_gnu[m]>mray btw I am also on IRC on #lgn Libre Game Night, we only play libre games is fun actually you are invited to join <mray[m]>happy i made it in "time" but wondering how i would start the different versions of inkscape <mray[m]>inkscape seems to be installed via guix now <sadiq[m]>Why already installed packages downloaded again. When I installed adwaita-icon-theme it downloaded texinfo, guile, less and many other already installed software pieces <mray[m]>sure it seems stupid, but in terms of compatibility it is sometimes usefull to be able to do that. <mray[m]>it is a big advantage voer apt after all! <happy_gnu[m]>he did export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <mray[m]>so that is my ubuntu inkscape right? <happy_gnu[m]>and from GNOME icons you should be able to see either the one you already had or both <happy_gnu[m]>if you don't put export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <happy_gnu[m]>you will have to run that command everytime you want to run a guix program <adfeno>I wonder, is it ".bashrc" or ".profile"? <happy_gnu[m]>lets say you reboot and you just do "inkscape" on terminal <mray[m]>ok so i should open ~.bashrc? and add it there? <adfeno>I put these variables in my .profile :) <adfeno>mray[m]: It's a text file, called ".profile", which is in your user's home. <mray[m]>export PATH="/var/guix/profiles/per-user/mray/guix-profile/bin${PATH:+:}$PATH" <mray[m]>you are certainly not asking me... :P <adfeno>Personally, I like to put my "export" lines in the begining. <mray[m]>so now my .profile is pimped with GUIX power <mray[m]>ah ok because i installed hello via guix <mray[m]>what if a hello program was in ubuntu repos for example? <happy_gnu[m]>if you saw the video I send you there teaches how to search for packages too <adfeno>(no need to reboot, just log out and back in) :) <mray[m]>ACTION would like to see inkscape running side by side <mange>Instead of adding each specific variable that guix-package tells you, you can source ~/.guix-profile/etc/profile to set all the variables that your current profile needs. <mray[m]>"guix pull" is "sudo apt-get update"? <happy_gnu[m]>if you open both inkscape and /usr/bin/inkscape then go to <mray[m]>pull is doing its thing rigth now - what happens if i just rebbot during this? <mange>"guix pull" is not "apt update && apt upgrade". It doesn't change anything about your current profile, just your current package recipes. That means that "guix pull" is roughly equivalent to just "apt update". <adfeno>To contribute to mange: Besides, it's *per user*. <mray[m]>hm it could be that guix has the exact same version as ubuntu <mray[m]>"/usr/bin/inkscape" <-> "inkscape" turn up the same version <adfeno>So, root has to run "guix pull"; and also "guix package --upgrade"; this also applies to every user that *has* Guix installed/enabled. <mange>mray[m]: Can you run "which inkscape" and tell us the output? <mange>Try running ~/.guix-profile/bin/inkscape. <mange>Sorry, that '.' at the end was a full-stop. :P <mray[m]>the build info is the same in the about screen <mange>~/.guix-profile/bin/inkscape <mray[m]>bash: /home/mray/.guix-profile/bin/inkscape: No such file or directory <mray[m]>somethign is still compilin in the other shell <mange>Did "guix package -i inkscape" complete successfully earlier? <mray[m]>but there is the complaint about the locale again <mray[m]>so whose repositories am i now using? <adfeno>THe locale thing is another issue. I had that issue too, we'll fix that eventually. <mray[m]>find . -name "inkscape" > search.txt <adfeno>mray[m]: Can you do: cd "/gnu/store/mkr3w3izmvzv3myq3g4l2p5qhr2i7byw-inkscape-0.92.1" <mray[m]>i'll see how often i can make use of its repos :) <adfeno>Well, I'm like you: running Guix the package manager in some other system distribution. ;) <mange>I don't run GuixSD, I just run Guix on top of Debian. <adfeno>I didn't venture myself into trying GuixSD yet. <mray[m]>i really don't get the fuss about Snappy and Flatpak - looking at guix... <mray[m]>they probably are easier to get running ;) <marusich>mray[m], regarding your question of "what repos" you are using - the answer is that you are using the package definitions, written in Guile scheme, which are authored by the Guix devs. If you have defined your own packages and configured GUIX_PACKAGE_PATH to point to those definitions, you are also using those package definitions. <marusich>If you're using the default Guix configuration, you are probably also using substitutes that are published by the Hydra build farm, which is a build farm run by Guix devs for the purpose of continuously building all of the packages defined in Guix. <adfeno>mray[m]: The thing about Flatpak and Snappy being easier to get running is somewhat relative... For someone using a system distribution ("distro") with Snappy as default, it's easier to just use Snappy. <marusich>So, when you install something, Guix tries to download a pre-built copy from Hydra first, and if that fails, it tries to build the software locally from source. <adfeno>(continuing my last message) .... and more dificult to get Flatpak there. <adfeno>(cont.) .... although it is possible. <mray[m]>ok what about the compiling thing right after guix pull? - is this like compiling all packages from source?!?! <mray[m]>marusich: what about reproducible builds - is that a feature that comes with guix by default? <mray[m]>lol - i want flatpak and snappy packages in guix! <mray[m]>ACTION read about it in the news section <mray[m]>flatpak and snappy don't seem to have that. <marusich>mray[m], when you run guix pull, the guix source (Guile scheme modules in files named "foo.scm" and the like) gets compiled (to compiled Guile modules with names like "foo.go"). In other words, all of the Guile scheme source code that Guix uses gets compiled, including all of the package definitions. It isn't compiling all the packages that are defined; it's compiling the Guile modules that contain the package definitions. <marusich>As for reproducible builds, that is not a feature of that comes with Guix by default. This is true also for Nix, or any package manager that follows the same functional software deployment paradigm. <mray[m]>marusich: thanks that makes *some* sense to me. <marusich>Reproducibility is a property of the software that gets built. <marusich>However, Guix (and Nix) make it much easier to achieve and verify reproducible builds. That is one of the great benefits of the functional software deployment model. <mray[m]>my understanding is that snappy and flatpak snap very flat on that feature. <marusich>For example, in Guix, builds are performed in an isolated environment to prevent any possibility of unexpected interaction with the outside world or other installed components. The upshot is that IF software builds reproducibly, THEN everyone who runs "guix package -i foo" will get the exact same software, bit for bit. <adfeno>mray[m]: Don't worry. I also felt like that in the begining. :) <marusich>The same thing is not true for any traditional (destructive) package manager, like rpm or dpkg <mray[m]>it is all somewhat similar to haskell stuff i suppose <marusich>The problem with those is that they just spray files into the file system in an somewhat undisciplined manner <marusich>That kind of software deployment results in unexpected consequences and makes it very difficult to roll back changes if something breaks. <mray[m]>to be fair - you probably don't want to know what microsoft does cough - or "did"... <mray[m]>crap i have to go get some sleep now <marusich>If you want to read more about this topic, I highly suggest reading the first 20 pages of Eelco Dolstra's thesis. He succinctly describes the problems that Nix and Guix, and any package manager implementing the functional software deployment model, solve. <mray[m]>good night and thanks again happy_gnu !! <adfeno>mray[m]: Also about the "compiling" messages in "guix pull": as marusich said, its not building/compiling "everything", it's just preparing/organizing the recipes it knows about. <mray[m]>marusich: thanks I am but a humble non-coder though <marusich>Even if you don't code, it's very interesting and helpful to understand the motivation. <mray[m]>i'm more interested in the motivation of not sticking ti nixOS <marusich>mray[m], Oh, well, to understand the difference between NixOS and Guix, there is a paper for that, too! <adfeno>But I think I can work a bit more on the inkscape issue, if mray[m] wants to. <adfeno>There is no need to hurry though, at least for me. <marusich>It helps clarify the motivation for why in Guix we use Guile scheme instead of Nix's expression language. <marusich>Outside of this, I don't have a lot of good references for information about how GuixSD differs from NixOS... Their methods for implementing operating system features like services and bootloaders are significantly different, and I have not found any articles that explain ALL of the differences. <marusich>There are, however, some blog posts and papers that describe either the NixOS approach, or the GuixSD approach, to some of these things. In particular, I can think of the following... <buenouanq>`Lisp.' is all the argument that should be necessary <adfeno>I must go now, my eyes are failing ;) <marusich>The area outside of Guix/Nix package management can get very messy, since in some cases it seems you have to deviate from the purely functional paradigm. For example, the bootloader-related aspects of GuixSD are unfortunately rather stateful (e.g., the generation of the grub.cfg file, the installation of the grub bootloader image on the hard drive itself). <marusich>However, I like the way services have been handled in GuixSD; a lot of the configuration really is declarative and stateless, which is great because it makes it so much easier to reproduce the entire system. <marusich>If I need to copy the output of one package to another, should I just copy the files with copy-recursive (from (guix build utils)), or should I create a "copy" by just symlinking the things I need? <marusich>Specifically, I have a gnucash-docs package which builds one directory: /gnu/store/...gnucash-docs-2.6.17/share/... <marusich>Specifically: /gnu/store/...gnucash-docs-2.6.17/share/gnome/... <marusich>I want to merge the "share" directory built by gnucash-docs into the output of the "gnucash" package. <marusich>Since there is no share/gnome directory in the gnucash package, I imagine I could accomplish this by creating a single symlink that points from /gnu/store/...gnucash-2.6.17/share/gnome to /gnu/store/...gnucash-docs-2.6.17/share/gnome <marusich>However, it is not clear to me in general whether it is OK to use symlinks like this. <marusich>Are symlinks in the store that point to other store paths in the store (in entirely different components) OK? <sadiq[m]>No... Compiler segmentation fault on compiling webkitgtk :'( <marusich>To answer my own question, I'm pretty sure it's fine. Symlinks are explicitly part of the FSO definition, so not only is it expected that symlinks can be in the store which point to other paths, but the presence of this particular symlink will cause gnucash-docs to be detected as a retained reference of gnucash, which makes sense because gnucash refers to gnucash-docs. <marusich>is it possible to use gexps in "modify-phases"? <Apteryx>Has anyone got this when trying to use adb (connect to Android device): error: insufficient permissions for device: udev requires plugdev group membership <Apteryx>I also see this from dmesg but I'm unsure if it's related: RUN{builtin}: 'uaccess' unknown /gnu/store/a6cl12hddjr8nx18hlngfwp2cd2f9gn3-udev-rules/lib/udev/rules.d/73-seat-late.rules:15 <Apteryx>Should I try adding a "plugdev" group to my user? <bavier1>oh right, the whole bundled chromium thing... <bavier1>brendyn: no, we disable it in our qt package <bavier1>which I think is unfortunate, since it may be better security-wise than qtwebkit <bavier1>the package I'm looking has announced they'll no longer support qtwebkit in the next release, since they're moving to qtwebengine <Apteryx>How much behind is 'guix pull'? I'm finding something strange... (target) is missing from the bootloader-configuration record and I just did a 'guix pull'. <Apteryx>root's ~root/.config/guix/latest points to ~/.config/guix/latest... but it seems my ~/.config/guix/latest is corrupted, as `ls -alH ~/.config/guix/latest' says: Too many levels of symbolic links. Rerunning guix pull just now to see if it'll heal itself. <Apteryx>marusich: sounds like you're making progress on gnucash:doc :) This will be a neat addition! <Apteryx>happy_gnu[m]: do you mean, like to those of your Internet Provider? <pksadiq>what is the guixSD workflow of developing C softwares. Is there something like 'guix install build-depends gedit' to instll all required packages enough to build gedit? <Apteryx>pksadiq: easier than that: guix environment gedit <Apteryx>this gives you a non-persistent environment with every dependencies found in gedit's package inputs. <Apteryx>to use the same source as that of the package you could do: "cd /tmp; tar xf $(guix build --source gedit)" <pksadiq>that's great. So this is why make, python, etc are not available direct from shell <pksadiq>inside gedit env, gcc version 5.x is used. How can I choose gcc 7.2 instead? <pksadiq`>How to update grub.cfg to include other distributions installed? should I simpy install os-prober and grub and do grub-mkconfig? <janneke>happy_gnu[m]: i run dhclient, which sets it for me <janneke>pksadiq`, pksadiq``: see node: Bootloader Configuration in the manual ***Guest15044 is now known as sturm
<bavier1>happy_gnu[m]: yes, qutebrowser was what I was looking at <efraim>grub can't read my btrfs filesystem on my new guixsd machine <kmicu>#guix user peak: 182 (104d 11h ago) lowest: 116 (340d 20h ago) average: 154.81 users (29d period) <rekado>ACTION still has problems with the i686 server <rekado>it’s the little thing hosting elephly.net <marusich>civodul, I am trying to add gnucash-docs as a doc output for gnucash. I have found that after adding (outputs '("out" "doc")), that not all the directories I thought would wind up in the doc output actually went there. <rekado>it’s not powerful enough to compile things on its own, but it has to do that anyway <marusich>Do I have to do something special to tell guix what stuff should go into the doc output? <rekado>marusich: yes, you have to install it there. <marusich>I did, but it did not wind up in the doc output. <rekado>marusich: e.g. by setting some configure flags or specifically copying things there. <civodul>rekado: you mean there are not enough substitutes for i686? <marusich>So, specifically, I have modified the gnucash package definition so that it uses gnucash-doc as an input. gnucash-doc build the documentation, which lives at /gnu/store/...gnucash-doc-2.6.17/share/gnome/... <marusich>I then added a phase to gnucash which creates a symlink at /gnu/store/...gnucash-2.6.17/share/gnome which points to /gnu/store/...gnucash-doc-2.6.17/share/gnome. <rekado>civodul: and every upgrade to guix (from git) requires compiling, which results in OOM <marusich>I expected the "share/gnome" directory to wind up in the doc output of gnucash; instead, it remains in the out output. <marusich>So, what I'm saying is that I believe I've installed the documentation correctly, but that it is not winding up in the "doc" output of gnucash. <rekado>marusich: don’t you make the “out” output dependent on the “doc” output with that symlink? <rekado>marusich: could you show me the patch please? <marusich>I guess I don't understand the contract for adding documentation which is supposed to wind up in the "doc" output. My understanding is very vague...something like, "If I put files in 'the right' places, magically the files will be excluded from out and put into doc output" <marusich>This may take a minute; I'll email it to you privately in the next 10 mins. <marusich>In the meantime, can you perhaps point me to the code that is responsible for the "splitting" of content into multiple outputs? <marusich>I've tried looking in the past to find it, and I wasn't successful... <rekado>we set the prefix to (assoc-ref outputs "out"), which is a directory. <rekado>the build system does the rest to install the files there. <rekado>with other configure flags we can set different target directories for different files <marusich>That's true, but something is responsible for e.g. putting the "doc stuff" into the "doc" output, and for putting the "debug stuff" into the "debug" output, right? <rekado>marusich: the gnu-build-system does this <rekado>in (guix build gnu-build-system), the “configure” procedure <rekado>it checks for out, bin, lib, include, and doc. <rekado>and then it sets configure flags for prefix, bindir, libdir, includedir, and docdir. <rekado>if the build system does not support the docdir flag, then you have to do this yourself. <marusich>So, in this case, no, the build system for "gnucash" does not support the docdir flag for its docs, because those docs are not built as part of the "gnucash" release. <marusich>They are built in a totally separate release package with its own makefile. <marusich>That's why I have a separately defined package for it. <marusich>So, is the right thing to do for me to put a symlink in the "doc" output, myself? <rekado>I think it’s not right to use a symlink from one package to another. <rekado>would the symlink not be installed in any case? <rekado>or only if the doc output is installed? <marusich>My intent is to make it so that when the "out" output is installed by itself, there is no documentation pesent. <marusich>When "doc" is installed, you get the docs via the "doc" output. <marusich>I think I see how to do this thanks to our conversation; I'll give it a try. <marusich>Is it expected that man pages don't wind up in the doc output? I see that in gnu-build-system.scm, we set docdir to (string-append "--docdir=" docdir "/share/doc/" (package-name)), which notably does not include share/man <marusich>Hm, maybe I'm just confused. I guess gnucash is depositing man pages into $prefix/share/man, instead of into $docdir? <marusich>I guess I need to explicitly set mandir. <marusich>Is there a reason why we don't set --mandir explicitly in gnu-build-system.scm to point to the doc output? <marusich>It seems that --mandir must be configured independently of --docdir, at least for gnucash. I wonder if it's true for other packages, too. <civodul>i think there are arguments for both options <civodul>i.e., man pages within or outside of "doc" <civodul>"doc" is typically used for large files such as HTML or PDF <civodul>often we don't save much space by taking man pages away <marusich>In this case, gnucash is 1 GiB. Wow. According to "guix size", at least. <marusich>The doc output I created, which will contain the help docs you can view in GNOME Yelp, is 94 MiB. <efraim>that sounds big enough to split off <marusich>Maybe it should just go in the "out" output after all. <marusich>Even though it's a tiny fraction of 1 GiB? <efraim>i normally look at `du -sch $(guix build foo)` to see how much the different subdirectories take up <efraim>er, `du -sch $(guix build foo)/*` <marusich>Splitting out the man pages would not really buy anything here. <marusich>Anyway. I am happy having a separate output for gnucash's Yelp help docs, especially since I already wrote up a patch. Since the man pages are so small, civodul is probably right that it doesn't buy anything if we move it into the "doc" output. <efraim>plus I would assume that the man pages would be included with the package <marusich>That does usually seem to be the common way it's done. <efraim>and since I'm everybody, clearly thats right :p <civodul>marusich: Yelp doc takes quite a bit of space i think, so it makes sense to have a separate output or package for that <efraim>Does anyone have GuixSD on a btrfs root? Grub doesn't recognize my filesystems <efraim>Only have btrfs and swap partitions <civodul>efraim: mark_weaver apparently has btrfs on LUKS <civodul>and there's at least a test for btrfs for root <marusich>civodul, if I want to know the total size of the transitive closure under the references relation of the derivation that built my current system, how would you find that out? <efraim>Is there a flag for grub for including extra modules? Could I have forgotten to include it? <marusich>I thought it would be simple to find out what derivation built my current system since I know the store path of my current system, but I can't figure it out. <civodul>marusich: guix size $(readlink -f /run/current-system) <civodul>efraim: grub finds out by itself what it needs to do <marusich>Won't that show the size of the transitive closure of the *output* of the derivation that built my current system? <marusich>I want to know the size of the transitive closure of the derivation that built my system; i.e., how much space was taken up by all the software that was required to build my system? <efraim>I specifically wanted btrfs raid 1 since I have a bunch of similarly sized random disks <marusich>Maybe my understanding is mistaken; I thought that the derivation that built my system would have retained references to (transitively) every input required to build the system. <efraim>re: the `guix system build' errors we've been having over the past week, a test to build the example configs would've caught it <efraim>then again I know I don't normally investigate the failures on the system tests <civodul>marusich: i can't think of an easy way to get what you're asking <civodul>the size of the closure of the .drv would be something different from what you're asking <civodul>so you'd need to look at the size of the outputs of closure of the .drv <civodul>but even that wouldn't be quite what you're asking for i think <efraim>guix size $(guix build foo --sources) <marusich>"Guix size" would give me the size of all the derivations required to build the system, but that would be quite small because the instructions for building the system can be small compared to the source files those instructions would cause to be compiled, and the outputs that those actions would cause to be created. <marusich>In any case, is there generally an easy way to tell which derivation built my current system...? <sadiq[m]>installing webkitgtk always fail (compiler segfaults). How to use gcc7 instead.of gcc5 for build? <efraim>sadiq[m]: do you run out of memory? what's the output of `free -m' <sadiq[m]>hm.. there is a chance.. (memory is now free enough tho). when I built webkitgtk from Debian it always overflow (and uses swap spaces). Won't guixSD too behave the same? <civodul>how does one add a domain name to a Let's Encrypt cert? <civodul>i can't find the right certbot incantatino <civodul>marusich: for any store item, you can query its deriver via the 'query-deriver' RPC <marusich>OK, that's what I was suspecting. Thank you for confirming my suspicions! <sadiq[m]>Will it be possible to install webkitgtk without building? <civodul>sadiq[m]: it should be possible, yes <sadiq[m]>civodul: hm.. Right now it is always building locally. <civodul>sadiq[m]: are you on today's master? <sadiq[m]>probably. Updated using guix pull about 3 hours ago <sadiq[m]>Why package -i sometimes pull in the same package (with different hash prefix) twice? <civodul>cbaines: could you check if we can apply the rsync service patches? :-) <rekado>do you know how to get around the problem of guile-git having been moved? <rekado>I have a system with an old central guix installation. <rekado>everybody else uses “guix pull”, but the central installation cannot be upgraded because “guix pull” will try to build the old guile-git from its old URL. <rekado>I suppose I could use “guix build --with-source=…” <mray[m]>wow, upon installing a pacakge guix seems very verbose <mray[m]>ACTION wonders whether the install log is bigger than the blender binaries themselves... <efraim>people have also used guix pack to get around guile-git having moved <efraim>is there a reason we build xorg-xserver-xwayland with --disable-xorg? <civodul>rekado: i'm still confused as to why there aren't substitutes for the old guile-git checkout <civodul>i'm sure i asked before, but i forgot what the answer was <civodul>rekado: in other news, could you reconfigure berlin, so that it has the latest & greatest Cuirass? <Apteryx>sadiq[m]: if you configured to use swap in your operating-system declaration with GuixSD, it should use it yes. You can check if there's any swap available using the `free' command. <Apteryx>sadiq[m]: and by bad experience building webkitgtk uses like 2GB per thread, and GuixSD builds with multiple threads by default, so yes, that can bring a system down quick and will report errors like you've seen (compiler segfaults -- which I find confusing) <sadiq[m]>Apteryx: yes there is plenty swap space free. Anyway now building with single core <Apteryx>a way around that is to use "guix build --cores=1 webkitgtk" <Apteryx>Has anyone been able to backup an android device using 'adb'? I get some 'not enough permissions' error which seems to be caused by my user not being in a 'plugdev' group. <ng0>what's prefered: patching software so that it takes environment variables or wrapping it and providing PATH? Caja doesn't like native-search path because it records the CAJA_EXTENSIONSPATH or what it was at configure/build <ng0>pathcing would maybe help uostream, but wrapping would be a solution which works for us now <ng0>the only getenv's in caja are XDG_CURRENT_DESKTOP DESKTOP_SESSION SESSION_MANAGER MATE22_USER_DIR MATE and some more but not the extension dir.. My idea is to wrap, so that I can wrap it up for now <ng0>but: due to glib-or-gtk build-system caja is already wrapped. I think wrapping a wrap will not taste good. <ng0>I should read more to see if this is a problem or not <rekado>wraps are squashed automatically <ng0>I'd add the PATH wrap after 'install' phase. and at the very end comes the build-system included wrap, right? <ng0>before I do this I should first take a break because I have doubts if it works at all. Basically my situation is: Every Mate application which includes Caja extensions automatically picks up the caja extensions path inside /gnu/store/…caja-version… so I had to pass the configure switch to them to point to their own out/…same/path/as/in/caja. Now the code for extensions in caja is not that much and could <ng0>be changed easily to getenv, but for me it'd be very much testing and not knowing (still learning the language used there). <ng0>so we have caja, and caja-extensions and atril and some other application. caja needs to learn about the other applications. <ng0>I think I'm on the right way <efraim>ng0: does it help that the mate metapackage squishes everything into a common %out directory, so it is in /gnu/store/...mate-meta/path/to/extension <ng0>but that's just the meta package <ng0>if we change anything it is in libcaja-private/caja-module.c between lines 216 and 270 <ng0>I'm looking at our pidgin patch, maybe some of it can be copied <efraim>how do i run the %test-btrfs-root-os test? <efraim>i tried guix build -e '(@@ (gnu tests install) %test...)' <efraim>civodul: looking at the btrfs parts of (gnu tests install) I didn't specifically do the bios_grub stuff, I just marked the os partition as bootable <efraim>so that could also be part of whatever is going wrong with my install <civodul>maybe you should email help-guix if you think something's fishy <efraim>i also noticed that the btrfs-root-os test hasn't been run since may, the location of the symlink already exists <efraim>make check TESTS="that test" is easier than I was trying :) <civodul>what symlink are you talking about? :-) <efraim>yeah, i read down to the bottom finally <rekado>civodul: for the guix-hpc website “guix build -f guix.scm” fails for me with “asset processing failed with errno: "static" 2” <jonsger>why is it necessary to add "--ad-hoc guile-git" when building guix inside "guix environment"? <rekado>jonsger: try “make clean-go” first <Apteryx>Hmm, how to add a 'plugdev' group to my config? When I declare it as part of the 'supplementary-groups' field of the user-account record, guix system reconfigure fails with: guix system: error: supplementary group 'plugdev' of user 'maxim' is undeclared <jonsger>is there anything else to do after configure and make to get guix itself updgraded? <jonsger>but it's definitly not updated because "guix system search" is still missing. <jonsger>or is there anything to change between binary and from-sources install? <civodul>jonsger: well from your checkout "./pre-inst-env guix system search" works, right? <Myst_>hey guys I've been itching to try guix for over a yr. But lacked the tech skills to install. over the last month or so I moved to using gentoo based distros. Having compiled them from scratch following tutorials I've succesfully installed them <Myst_>I know have a clearer understanding of the process involved <Myst_>I assume I can install guix from an existing linux os <Myst_>what initially confused me where commands & phrases that I've not seen before. <Myst_>Having installed gentoo, they are not soalien top me anymore <Myst_>thank you just reading it now. <Myst_>are there any videos out there witha guide <Apteryx>Seems to have worked adding plugdev after adding "plugdev" to supplementary-groups and (user-group (system? #t) (name "plugdev")) to groups. <Myst_>assuming guix will be installed on sda7 on a gpt ext4 using rEFInd boot loader <Myst_>I will not have need to worry about grub etc <Myst_>my initiall concerns are chrooting and mounting the rootfs <ng0>there's an guix package in gentoo <ng0>I assume you want Guix not GuixSD <ng0>then you want GuixSD, and unless you have good reasons I'd go with using the USB Image (and not from top of an existing system) <ng0>which is possible aswell, but has some quirks for first time use <Apteryx>Myst_: yes, follow the user manual, it's well written. Don't try anything fancy at first to get going. <sadiq[m]>ACTION feels guixOS better. rhymes with geek's OS or geeks' OS :) <Myst_>so in my case assuming I'm using sda7 <rekado>civodul: I’m running “guix pull” on berlin and will reconfigure it. <ng0>If you want to test you could even 'emerge -a guix' and when the initial bootstrapping after 'guix pull' is done you could test a VM from within Gentoo <rekado>I’m still having problems running “guix pull” on an older system. I tried using a later version of Guix on the same machine, but “guix pull” fails to compile current master. <ng0>(assuming you have Gentoo on a spare computer. If not, nevermind me) <rekado>here’s the error: guix/scripts/graph.scm:101:15: return: return used outside of 'with-monad' in form (return (object-address a)) <rekado>it says it’s “Building from Git commit 3daea4f12b4c9fa48d4a964ee2d9e3d1de349054...” <ng0>so like "guix vm my-testsystem.scm" and you could re-use that "my-testsystem.scm" if you put it into a git (or upload it somewhere) and pull it later into the bare-metal system you install GuixSD on <ng0>sorry, "guix system vm foo.scm" <rekado>hmm, it worked this time with c694520bb13ef11c11c06cbc52e1dc27c24dc788 :-/ <rekado>I fear that maybe this is a problem with Guile 2.2.2 on a machine with many cores and lots of memory. <htgoebel>is it okay to push a new temporary branch for "QT install and search paths"? This would simplify collaboration <efraim>although I would shorten the name <htgoebel>efraim: shorter of course :-) Locally I named it wip-qt-paths. Okay? <sadiq[m]>No no no... webkitgtk build faild after 5 hours of build :'( <efraim>I found that 4GB total wasn't enough, and 8 was plenty, but i'm not sure where the cross-over point is <sadiq[m]>it said some file is missing (but I forgot to add -K arg) <sadiq[m]>4 GB ram, 5GB swap. Built using single core <efraim>i'm at 79% on aarch64, using 6 cores <ng0>here thinkpad t60 (with 3GB RAM afaik) went through it in the last 12 hours with some other updates and other computers were just yawning through in a couple of hours. <sadiq[m]>eh.. will the hydra build subsitute be soon ready? <sadiq[m]>hm.. any status page for that? amd64 arch btw <sadiq[m]>thats great.. so I should do a guix pull and try install again, right? <sadiq[m]>Btw, what is the timezone of hydra server? <efraim>hmm, kdelibs4support and python-pastel need some loving <ng0>hydra is in some part of USA, hydra mirror is at TU Munich (or one of its data locations) <efraim>that is a good question, if its local then EDT or EST, otherwise maybe UTC <efraim>by local i mean local to the machine hydra is running on <sadiq[m]>Hm.. setting timezone utc might help many (if not yet so) <ng0>it's easier on reviewers if I don't send a 20 packages proof-of-concept necessary batch of patches I think. I work on cinnamon, but that could take a while longer than Mate. I already have 1 cinnamon package ready but it just builds and serves no user-facing function. Got stuck at muffin. <jonsger>ng0: you wanna replace Linux Mint by GuixSD :P <htgoebel>efraim: Re kdelibs4support: interesting it passed two days ago. <efraim>htgoebel: i think it might have just been a timeout <ng0>kinda. A sub-item for something I want is to have some fully-featured DEs and DMs <ng0>so Mate is close to being easy to maintain and featureful. Plus probably easy to add unique themes to <ng0>cinnamon -> muffin right now is: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/(.*?){ <-- HERE / at /gnu/store/sd4gxwa0xln492nvy8j6l2ivpy7l1g42-gtk-doc-1.25/bin/gtkdoc-scan line 735. where I didn't have more time to find a solution to <efraim>yeah but it took 5000 ms, hence my timeout guess <civodul>cbaines: i'm looking at the mysql/popen issue, which turns out to be more involved than expected :-) <civodul>it looks like ice-9/popen.scm isn't found because we lack a pivot_root(2) call in the boot process <civodul>so at the point where we try to access popen.scm, we're looking at the old root, which has been emptied <civodul>anyway, i'm trying to check this hypothesis