IRC channel logs
2018-02-16.log
back to list of logs
<pkill9>i just need to understand the build process <OriansJ>pkill9: gnu-build-system can be just a simple makefile <pkill9>i'm running into problems though OriansJ <pkill9>their makefile builds into a folder called 'Main' <pkill9>and the build process changes directories and then can't find that filder 'Main' <OriansJ>pkill9: so you need some help understanding the makefile? <pkill9>since i don't know the build process, i.e. what goes where, what flags are used, I don't know what guix does when building <OriansJ>perhaps you should start with a simpler program first to help you understand how guix interacts with makefiles <pkill9>OriansJ: I'll post a link to the package definition i made, and a link to their makefile <pkill9>the lines with `(getcwd)` are for debugging <OriansJ>pkill9: looks like a standard configure, make, make install <pkill9>when it gets to make install, it can't find the directory it built into though <pkill9>and i tried adding another chdir after the build phase, but for some reason it didn't work <pkill9>maybe i'll try that again and look closer at the directory it's in <OriansJ>pkill9: the download directory is shown when you do: guix download $URL <pkill9>i mean when it's building, so where it is in the build directory <OriansJ>mescc-tools uses `(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out"))) to solve that problem <pkill9>i thought Guix automatically added the prefix <OriansJ>pkill9: if you look at the bottom of mescc-tools makefile, you'll see why that was required <pkill9>i get this error 'cp: cannot stat '/tmp/guix-build-veracrypt-1.21.drv-0/Main/veracrypt': No such file or directory' <pkill9>the path should actually be /tmp/guix-build-veracrypt.../src/Main/veracrypt <pkill9>or, maybe i can use fetch-url/tarbomb now that i added the PREFIX makeflag <pkill9>ah found where it's actually built the package to <terpri>pkill9, there are a couple problems with the makefile: it's using $PWD which won't necessarily work outside of an interactive shell, and it assumes the destination directory already exists <pkill9>so far it's built fine, it just doesn't look for the built files in the right place (including if i just manually make && make install) <pkill9>so i'll try just adding a phase where it moves them to the place it expects to find them <pkill9>pretty sure you're right about that makefile beign problematic terpri, after building multiple times it seems to arbitrarily output the final package files in different locations, presumably because each command I add to attempt to adjust around it changes the $PWD, thus changing where the final package files are placed <pkill9>so i guess best option is to patch the Makefile and request upstream change it <OriansJ>pkill9: well, upstream patches are a good way to start a good relationship with those developers <terpri>pkill9, yeah, it definitely doesn't seem portable <terpri>you can also change the source code from within the package definition, or use a patch file for larger changes <terpri>for veracrypt, an install phase like this should work: (replace 'install (lambda _ (mkdir %output) (substitute* "Main/Main.make" (("cp -R \\\\$\\\\(CURDIR\\\\)") "cp -R $(PWD)")) (invoke "make" "install" (string-append "PWD=" (getcwd)) (string-append "DESTDIR=" %output)))) <lfam>sneek later tell civodul: The web browser and terminals seem to work for GNOME / Xorg, GNOME / Wayland, and XFCE using desktop.texi with core-updates. <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, civodul says: tomorrow sounds good! <pkill9>thanks, it successfully built it :) sadly there is a problem for me with running that build of Veracrypt :( however that might be because I'm running Guix on a foreign distro. <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, lfam says: The web browser and terminals seem to work for GNOME / Xorg, GNOME / Wayland, and XFCE using desktop.texi with core-updates. <civodul>ACTION is running GuixSD on core-updates \\o/ <civodul>ACTION runs 'guix weather' to see how well we're doing on core-updates <efraim>civodul: not yet, my aarch64 build machine is still barfing after repeated reimagings so I might be dual purposing the firefly as Dev machine and build server <civodul>efraim: oh i just meant that berlin is already offloading to the OverDrive that's at my place <efraim>I know, I assumed you meant that it was up and working nicely :) <civodul>so which machine of yours has troubles? <efraim>I think I have a mount permissions error since it builds a few bits of the bootstrap and then says gcc-boot0 can't be used to build things <efraim>But when I rebuild it on the firefly it builds fine, and it built fine the first time also <civodul>could be that the store is mounted noexec or something equally weird <amz3>civodul: sorry, for letting you down on gnunet side, I hope to pick it up later if nobody does. <amz3>civodul: sorry to repeat my question, but I don't understand what are the technical difficulties related to guix store and data <civodul>amz3: i'm not sure what question you're referring to <amz3>civodul: I am refering to the thread about using guix to package datasets <civodul>well, let's keep the discussion in that thread if you don't mind :-) <civodul>the main issue was the size of datasets, essentially <rekado>should we stop the evaluation of core-updates since it doesn’t include the patch for ghc? <civodul>that's why 'guix weather' reports bad figures, right? <civodul>rekado: i've started a new evaluation on hydra.gnu.org <civodul>apparently berlin has already started building the latest ghc <efraim>Can I tell guix pack to pack up ungrafted versions only? <snape>Hi, how can I find out what glibc version gcc-toolchain is using? <rekado>snape: when you’ve built it you can run “guix gc --references” on it. <wigust>snape: Or only by generating a derivation of ‘gcc-toolchain’ -- ‘guix gc --references $(guix build -d gcc-toolchain)’ <snape>rekado: very helpful, thank you very much <rekado>AFAICS there is no patched ghc in core-updates. <efraim>among the suggestions the internets have for the signal bus error I'm getting on the odroid is either it trying to access out of bounds memory, or my arm board isn't compatable <efraim>i've copied over an ungrafted version of guix, maybe that'll make a difference <efraim>and /gnu's mount point is currently 'defaults,noatime' so that has to be fine <efraim>still signal 7 (bus error) using the ungrafted guix package <mbakke>core-updates is evaluating now, so I guess there's no use in merging the GHC patch <mbakke>I suppose the problem will "fix itself" once core-updates is merged. <civodul>rekado: can we just merge core-updates in master and be done with it? <civodul>ghc will have to be rebuilt, but maybe that's ok <civodul>mephi42: could you paste to paste.debian.net? pastebin.com blocks Tor users <lfam>I figured we could rebuild it after merging to master, because I didn't think there would be a large number of people using it and trying to update immediately after the merge. But we could go either way... but we should pick one and do it :) <wigust>lfam: Xmonad users (which were in #guix) will not be happy <lfam>It would not be a short period during which they would need to build it themselves rather than getting a substitute. <lfam>I mean... it would be a short period <lfam>We would not be breaking the package <lfam>I'm not sure there are any Xmonad users who pay close attention to when branches are merged, or they would have noticed the issue with GHC on core-updates earlier :) <lfam>civodul, rekado: Any preference? I can push the GHC patch to core-updates and start a new core-updates evaluation now. I can also merge core-updates -> master and evaluate master. <lfam>I see there is already a pending evaluation of core-updates, since 2018-02-16 14:11:45 <vagrantc>heh. i guess i was just used to the pattern of gcc and company and it's many language implementations <civodul>lfam: yeah, can you merge it in core-updates? <civodul>let's make it the very last evaluation™ <lfam>ACTION definitely not a robot <lfam>Can we cancel the currently pending evaluation and start a new one? <lfam>I also tested merging core-updates -> master. Only a couple trivial merge conflicts. I did `guix pull && guix package -u .` from it and everything seems okay <civodul>i didn't experience the slightest glitch after upgrading GuixSD, which is nice <pkill9>how do i isntall X with startx script etc on GuixSD <pkill9>trying to work out the workflow from the manual, but a bit confused <pkill9>i triedjust isntalling xorg-server and xfce and xinit for all users, but my non-root user didn't have permission to access /dev/shm or something, and running `startxfce4` as root (when if orgot i was still root) started xfce but it seemed to be frozen <pkill9>but since xorg is a service module, i assume i should be using that <pkill9>but i'm failing to understand what i need to put where in my /etc/config.scm <lfam>I've seen some configurations where the person was using startx but I don't remember how it works <cbaines>has anyone else seen this error: ERROR: find-long-options: unbound variable <lfam>cbaines: What is `guix --version` for root? <cbaines>I've got .config/guix/latest for root symlinked to a checkout of the git repository <cbaines>I'm on revision 6a3cf4e6c7d77634d67902215f0017c12455c6fb <lfam>Hm... I would do `make clean-go` and try again in case there was an ABI break <pkill9>how do i drop to console from graphical login screen? <lfam>pkill9: CTRL+ALT+F{n} to switch to another tty, where n is some number besides the current tty, which is probably 1 <lfam>If you are in QEMU, there are some extra steps to pass that command <pkill9>is there a way to send that keysequence to virtualbox session? <lfam>Surely, but I don't know what it is <wigust>pkill9: As I remember VirtualBox have somewhere in the menu bar a feature to send key sequence like CTRL+ALT+F{n} <wigust>Also if you chosed a ‘desktop.tmpl’ you could get to a shell from a terminal in a graphical environment. <OriansJ>pkill9: if you don't want to use %desktop-services in your config, you could just add (service slim-service-type) to your services or if you wish to eliminate a graphical login manager completely, you just need to install the appropriate xorg packages <wigust>Or remove some service from ‘%desktop-services’ if you don't like some service to be there. <OriansJ>one could even use the definitions to even reduce %base-packages/%base-services should they decide to do so <toon`>I install guixsd on uefi system. Why I get this error when install system? :: grub-efi-2.02/sbin/grub-install: error: failed to get canonical path of 'none'. <toon`>wigust: I only changed uuid for ufix parition <wigust>toon`: I have ‘(operating-system … (file-systems (cons* … (file-system (device "/dev/sda1") (mount-point "/boot/efi") (type "vfat")) …)) …)’ <wigust>toon`: So you could try without messing with UUIDs, too. <toon`>wigust: Actualy the message changed to "path of 'none'" after I was created /mnt/boot/efi. Before that it had contained "path of '/boot/efi'" <wigust>toon`: You should get it to recognize as ‘/boot/efi’ still, I think. <wigust>(mount-point "/mnt/boot/efi") is strange <wigust>toon`: To be clear, you should create and mount your EFI partition in ‘/mnt/boot/efi’ but use (mount-point "/boot/efi") <toon`>wigust: No actual sexp in scm (mount-point "/boot/efi"). I create path in host boot disk on mounted hdd where target installing directory is /mnt <wigust>toon`: Not only create a directory, but mount a EFI partition there. <toon`>wigust: O! I suppose that guix mount it by itself <wigust>toon`: I don't think so, but I don't remember. Better mount (suppose /dev/sda1 is efi partition) to /mnt/boot/efi <toon`>wigust: Ok. I'm going to try this right now. <toon`>wigust: Unfortunately it's stoped with the same error. <wigust>toon`: Well, I don't know more (if to tried a no UUID approch which I tell you). Could try to ask on the mailing list more folks will try to help you. <toon`>Yep... Maybe I should try this with your example. But uuid will be neat solution if it will work. <wigust>what SOURCE will ‘findmnt /mnt/boot/efi’ will show? <snape>wigust: I'm trying to find some time to answer your email about the cgit service :-) <toon`>wigust: ith show "target: /mnt/boot/efi source: /dev/sda2 fstype: vfat options: ...some generic mount options..." <wigust>toon`: if you efi partition is /dev/sda2 <snape>(I was too busy watching Federer becoming no. 1 again) <toon`>wigust: Yes it /dev/sda2. Maybe it need mounted /dev and /proc in target /mnt directory ? <wigust>toon`: Are you following the “(guix) Proceeding with the Installation” documentation by the way? <toon`>wigust: ok. It come to mind from gentoo installation process :-) <toon`>wigust: This exactly what im trying to do. Maybe I have read this not so carefuly how should... <toon`>wigust: I had changed scm like in your example without uuid. All the same. With mounted /dev/sda2 or with unmounted /dev/sda2 it does not matter <sneek>atw, Apteryx says: thanks (will use emacs-mocker) <toon`>wigust: When I done grub installation manualy like this: "/gnu/store/../sbin/grub-install --efi-directory=/mnt/boot/efi --boot-directory=/mnt/boot" grub was successfully installed. <toon`>wigust: Hmm.. Do i need to actualy mount efi system parition on host /boot/efi or /mnt/boot/efi before installation? <wigust>toon`: The ‘(guix) Preparing for Installation’ says “Also mount any other file systems you would like to use on the target <wigust>Also it does mention ‘/boot’ as a separate partition. I assume efi is the same. <toon`>wigust: Yes. It is clearly state this but I just mounted eif on host /boot/efi and system generation was done without errors <wigust> toon`: I recommend to try a “guix reconfigure” after booting to the installed system to look will it break or not :-) <toon`>wigust: scm configuration with uuid's work find with efi parition mounted on host /boot/efi