<ifur>both git and guix incompetent, but how do i get the sha256 base32 for a git download? <roelj>ifur: If you have it checked out, you could move the .git directory out and do "guix hash -r ." <ifur>roelj: the sort of hack i can remember, thanks :) <roelj>so: cd my-git-repo; mv .git ../.; git hash -r .; mv ../.git .; <mark_weaver>in order for that to work, there must not be any additional files in there. <mark_weaver>(which is often the case with git checkouts where you've been doing work) <bavier>do we have any guidelines on when to build with debug symbols and when it's alright to remove them? <bavier>e.g. building llvm@3.8.0 with -DCMAKE_BUILD_TYPE=RelWithDebInfo needs 13.8GiB of disk to build, but with BUILD_TYPE=Release needs only ~2.6GiB <mark_weaver>bavier: I don't think we have any official guidelines, but in this case I think we should not include debugging symbols. <bavier>mark_weaver: it seems reasonable to me. <bavier>if someone's willing to debug llvm, they're probably skilled enough to create a modified recipe and build it themselves <roelj>bavier: I've also been trying to build LLVM@3.8.0 from the patch Dennis sent. I think BUILD_TYPE=Release would be worth the saved disk space.. <bavier>roelj: have you managed to build clang@3.8.0? <roelj>bavier: I'm currently still building llvm@3.8.0. After that, clang@3.8.0 is on the list <bavier>I'm working from patches I started earlier last week on my own, but I wasn't able to build clang <bavier>if dennis's patch works, I'd be surprised <roelj>I'll find out later tonight :) <roelj>It seems such a trivial patch, right.. <roelj>I will let you know of course.. <lfam>I have a working random-seed thingy <lfam>Looking in (gnu services base), I see that sections seem to be delimited with ^L <lfam>It's some control character, not the actual ^L characters <lfam>Is it something that makes it easy to jump between sections in one's editor? <ijp>essentially yes. It's a form feed character <ijp>used for delimiting "pages" <lfam>ijp: Thanks! That's the sort of thing that search engines don't handle very well... <lfam>random-seed patch sent to the bug report <lfam>Testers and reviewers are invited :) <notadrop>I'm happy to report that I am booting into GuixSD for the first time on my machine <notadrop>I don't remember bring asked to set a password when I edited the config for Guix system init Emacsite <davexunit>you should set the passwords with the passwd tool <notadrop>but I know I did that one step to save the config file <davexunit>passwords aren't put in the system config because they are secret, stateful information <notadrop>oh man. this is from before I used computers <davexunit>you should add the xfce or gnome service so you can use those instead <davexunit>make sure the login screen displays the current session name <davexunit>it should say GNOME or XFCE or whatever at the bottom of the screen <davexunit>you can just switch to one of your pty sessions and kill X if you're confused <lfam>notadrop: You can also right-click to get a menu <notadrop>is if similar to other gnu Linux systems? <Emacsite>davexunit: In the Artanis mailing list, I showed my attempt at installing GNU Artanis from the GNU package maneger. <notadrop>keymap is messed up as well. I need to load the macbook keymap. <davexunit>notadrop: ah, a macbook. that explains some things. <notadrop>I have my work cut out for me to make this usable, but I expected nothing else <davexunit>we've had various users report problems about them <lfam>Emacsite: Help wanted! :) <notadrop>well I am here as another beta tester for you :) <notadrop>does anyone know why a USB mouse would not work? <habs>Where can I find what would normally be /var/log/syslog on GuixSD? <notadrop>oh, here's an odd thing: my touchpad worked just fine in the text only installer image to move a little highlighted block style cursor <notadrop>it doesn't work in the GUI or TTYs of the installed system tho <notadrop>also, all hardware on this machine worked in trisquel and parabola which both run the libre kernel <notadrop>so it's not a kernel issue or it shouldn't be if the proper modules are loaded <notadrop>okay, time to read "man guix" and the rest of the docs. I'll be back if I have questions <notadrop>I'll report back with my findings... is there a mailing list I should be joining? <notadrop>okay. I will join help for now, and work to earn my place on guix-devel <davexunit>if you've ever make a patch, guix-devel is the place to send it <notadrop>I guess if I develop then I am a developer <notadrop>as a certain individual who may or may not have been a CEO of a major software firm once said <notadrop_mobile>so I can install packages for myself as an unprivileged user... and I can roll back to a previous profile if an update has a serious bug or breaks things <notadrop>One thing I find a little confusing in the docs is: a lot of this assumes I am installing Guix on top of an existing GNU Linux system. <notadrop>I'm not sure what's already done for me by guix system init and what isn't. <ryan___>are there any virtualbox images of GuixSD? <OriansJ>I've been toying with the idea for the last week and I have decided for my next bootstrap phase to go the most wildly inefficient route possible. Implement a virtual machine in under 64KB, that interacts with virtual papertape readers and make a compatible version in C that works on top of linux so that more people can play with this really terrible virtual machine. <OriansJ>Which ironically only has the benefit that it can be integrated into 0x10c style games by people who want their gamers to have to work to produce something meaningful <janneke>OriansJ: my minimal lisp interpreter in C is getting to look quite nicely ;-) <janneke>I'm still fighting with if and how to make the C version a more minimal ancient LISP and bootstrapping into a full-fledged scheme interpreter written in that LISP <OriansJ>one interesting hint you might find fun is that you don't need to implement any types except strings <janneke>hmm, i now have number, symbol, pair and builtin function <janneke>i was planning to add strings later...hmm <OriansJ>and of course you only need to implement the maxwell equation functions of lisp, I'll try to pull that up for you <janneke>OriansJ: actually, my current working name of the project is MES -- maxwell equations of software :-D <janneke>and I'm trying to stick real close to that <janneke>yes, that and your hex->hex inspired me to start this...just wanted to see the minimal bootstrapping path. <OriansJ>I promise after I finish getting my minimal virtual machine, Getting your lisp working is going to be something I am going to enjoy :D <OriansJ>I'm basing the virtual machine on a design called the Tom Knight platform. Which has some rather convient features such as 16 registers, 3/4 op arithmetic and opcodes that line up on the nybbles. <koosha>I run Windowmaker on Guixsd . I use two monitors but when I'm using Windowmaker , one monitor is a bit blury . I had the same problem when I ran i3 on Debian but when I installed "disper" , the monitors were both good . But here disper is not in repositories . <joshuaBPMan_>hello, does anyone have any tips on how to dual boot gnu guix SD and another distro (I'm using parabola)? <joshuaBPMan_>I'd love to be able to use guix SD full time, but it's just not stable enough right now. <joshuaBPMan_>at the moment, guix SD is generating my grub.cfg file. I've added a file in /boot/grub/custom.cfg, but when I tell grub to generate the config file, it doesn't add the the menu entries for guix. What gives? <joshuaBPMan_>Thanks civodul. I hadn't thought of editing the configure.scm file to add another grub entry. I suppose that is what guix is trying to do. Thanks. I'll try to figure out how to do that. <joshuaBPMan_>janneke when I modify my config.scm, then I'll just run guix system reconfigure as root correct? <janneke>as I'm not yet fully on GuixSD, i usually do: guix system init config.scm /guix <joshuaBPMan_>janneke, why do you do guix system init? I thought you only needed to do that once? <janneke>dunno easy and otherwise you get a long history of menus in grub. <joshuaBPMan_>from debian!? What!? So you have guix installed in debian as well as in it's own root partition? <janneke>when in Debian, I have GuixSD's root mounted under /guix <roelj>Does anyone else have a problem with compiling the latest Guix git? <joshuaBPMan_>hey janneke, can you help me figure out how to run guix system reconfigure in parabola? I've got my root guix partition mounted, but I can't find the guix binary. <janneke>I have a debian package of Guix (the package manager) installed. I run that, or the debian-compiled-from-git version when on Debian <janneke>nice idea to run GuixSD's guix, what about: find /guix/gnu -name guix <janneke>what a great idea to run guix binaries from GuixSD :-) <joshuaBPMan_>If I ever figure out where my guix profile is on /guix/, then I could just copy that into my home dir path. <roelj>joshuaBPMan_: You could find that out by following the symbolic link from the ~/.guix-profile. <janneke>joshuaBPMan_: try: /guix/var/guix/profiles/per-user/ <ngz>Hello. I'm trying to create a package using trivial build system, so I need to unpack the source file (tar.bz2) manually. I use (system* (string-append tar "/bin/tar") "xvf" (assoc-ref %build-inputs "source")). I also used (setenv "PATH" (string-append (assoc-ref %build-inputs "bzip2") "bin")) before. <ngz>Yet, I get the following error: "tar (child): xz: Cannot exec: No such file or directory" <lfam>ngz: Without seeing "the whole picture" it's hard to say, but something is using xz compression instead of bzip2, or something like that <lfam>Or, the file that is supposed to be uncompressed does not exist <ngz>This is odd. I don't get any error from the source definition. And it is definitely a ".tar.bz2" file. <ngz>Do you want/need to see the package definition? <lfam>That's just how I read that error message. It's referring to xz for some reason <ngz>lfam: Unfortunately, -K option doesn't help much since it only displays an empty directory. Do you know how I could debug this ? <lfam>I think you should try with xz <lfam>Or, you should try decompressing the tarball by hand <ngz>I did (decompress the tarball) <lfam>In an environment without xz? <ngz>I'm going ot try replacing bzip2 input with xz, then. <lfam>I'm shooting in the dark now ;) <lfam>This is perhaps an embarassing (for me) suggestion for me to make, but when I get *really* stuck, I try to find some similar working code, and then adapt it to what I am trying to do until it works. Then, I compare it with what I had. Usually I don't get all the way, but have the "aha!" partway through <lfam>So, you could try adapting some other trivial-build-system package to decompress your tarball. Maybe there is a mistake in the string-appending <ngz>Actually, I borrowed that part of code from docbook.scm which does a similar thing. <lfam>civodul: I am currently building a VM with the urandom-seed-service using the extensible API <lfam>ngz: Once I send the patch for what I'm working on, I can take a look at your package. It should only be a little while. <lfam>random-nick: It's a crude and hurried expression of joy ;) <ngz>lfam: Thank you. Meanwhile, I'm waiting for the process with "xz" to finish. <lfam>Okay, so the error is probably spurious. Are you sure it finds your tarball? <ngz>It must be a mistake in the tarball name, indeed. <ngz>This still boggles me. <lfam>Or perhaps the tarball is corrupted? You didn't clarify if you manually decompressed the tarball in the store or some copy you downloaded separately <ngz>Also, maybe (assoc-ref %build-inputs "source") doesn't return what I think it does. <lfam>Maybe it's easier to use gnu-build-system and remove the extra bits ;) <ngz>I thought about that. But that means to remove everything bun unpack and patch-shebang phases, mostly. <ngz>I successfully decompressed (manually) the tar.bz2 file from the store, so it doesn't look corrupted. <civodul>ngz: 'tar' tries to run 'xz' from $PATH, so you need to make sure it's in there <civodul>ngz: often that means doing (setenv "PATH" ...) or similar <ngz>civodul: But xz isn't involved in decompressed a tar.bz2 file, is it? <ngz>civodul: I actually did the same as "docbook-xsl" from docbook.scm, i.e., I add bzip2 to PATH and call tar with its full name. <civodul>maybe you can add 'j' to force bunzip2, as in "tar xjf foo.tar.bz2" <ngz>I think I tried that too. Trying it again, just to be sure. <ngz>civodul: still no luck <ngz>Interestingly, the error happens after decompressing since I can see listed files in stdin <lfam>latest urandom-seed patch sent to the bug discussion <roelj>What environment variable is needed to display icons of packages in gnome-shell? I created a symlink from ~/.guix-profile/share/applications/ to ~/.local/share/applications, but the icons don't seem to get picked up. (I'm on Fedora, not GuixSD). <alezost>roelj: I don't know but my guess is: try to add "~/.guix-profile/share" to XDG_DATA_DIRS <kyamashita>I've been trying in vain to get NetHack to work properly through Guix. <kyamashita>It keeps trying to modify files within its store folder. Obviously, this doesn't go over well. <lfam>kyamashita: Yeah, that's not going to work. Most programs provide a way to configure the location of state files. <alezost>kyamashita: it should probably be configured --with-some-flag :-) <ngz>lfam: Would you have any spare time to take a look at my package? I'm still stumbling on the issue discussed earlier. <lfam>ngz: Sure, put it on paste.lisp.org <kyamashita>I'll try looking in generated Makefiles and work backward from there. NetHack has no configure script, just a directory of makefiles and setup scripts, so I've been patching them. <lfam>kyamashita: Debian packages nethack, and I doubt they let it write to /usr/bin or wherever they put it. So, you could check what they've done <lfam>ngz: Can you paste the results of `git format-patch` or `git diff`? <ngz>This package is not in the repo. <ngz>it is not finished either. But I cannot even start hacking on it since I can succeed the first step: decompression. <lfam>How can I test it? I'm used to packages in the Guix tree or a separate package module. <efraim>should it be (setenv "PATH" (string-append bzip2 "/bin")) and not just "bin"? <ngz>I add it to GUIX_PACKAGE_PATH <ngz>efraim: hmmm let me try <ngz>Still failing. I get "bzip2: (stdin) is not a bzip2 file" <ngz>At least, the error message is different. <lfam>efraim is right about that <roelj>alezost: Adding my profile path to XDG_DATA_DIRS worked! Thanks! <kyamashita>lfam: I just checked and Debian's NetHack appears to grant access to its own directory, /usr/lib/games/nethack, to store and modify its state files. <ngz>I have the feeling there's something wrong with `source', which is probably not the downloaded file. <lfam>ngz: Yeah, that sounds right based on the error "bzip2: (stdin) is not a bzip2 file" <ngz>So calling "tar xvf" on source yields peculiar results. <lfam>kyamashita: Is that the default or does Debian set it somehow? <ngz>Yet, "docbook-xsl" uses the very same incantation, probably successfully, so I'm very puzzled. <kyamashita>lfam: My mistake. Debian sets the playground directory to /var/games/nethack instead of /var/lib/games/nethack. <efraim>I just downloaded the file and ran `tar xf' on it an it uncompressed without problems <ngz>Apparently (display source) prints "/lfnr4c9yf9cg9v06py0cs149k5zg6s-geogebra-5.0.240.0.drv.bz2" <efraim>using the link from the package description <lfam>kyamashita: Cool. So we know it's possible to get nethack to not try to write to /gnu/store <ngz>efraim: So do I. I don't have any problem decompressing it. It's the tar call that is guilty here. <efraim>you take out the bundled JREs, when it gets recompressed it uses xz <ngz>So I just add "xz" to native-inputs ? <kyamashita>lfam: Is there a way to access the user's home directory from within Guix? <ngz>But then how do I uncompress a bz2 file ? <kyamashita>lfam: If so, part of the installation would write files outside of the store. I don't know if that is permissible. <efraim>the snippet gets applied during `guix download' i think <lfam>kyamashita: I would check how our other games do it. This can't be the first one that does this <lfam>I remember checking a game that downloaded files when it starts. Maybe pioneers? <ngz>efraim: Interesting. Adding xz to the inputs doesn't help. However, commenting out the snippet brings me further. So there's something wrong with the snippet part. <lfam>Kernel compile time survey: How long does it take you to build the Linux kernel on your machine? <lfam>I feel like this has been running for hours on my x200s <lfam>I should have exported the package from a faster machine <kyamashita>lfam: Scanned through all of games.scm, and it seems like NetHack *is* the first game that does this. <lfam>kyamashita: You could try seeing what other games do instead, and then making nethack do that <Pastaf>is it possible to install GuixSD without an internet connection? I've got a second USB to copy over anything needed. <Pastaf>possible meaning I can do it without manually downloading and moving every package <lfam>Geez, does the nix language not support comments? <kyamashita>Even when I change all of NetHack's changable variables to my home directory, it tries to access its folder in the store. <lfam>Where is {userDir} defined? <ng0>lfam: depending on the system building libre/pax/hardened sources for me is =<2 minutes to =<12 minutes for me, 12 when I do run other systems compiling their stuff on the host compiling the kernel <kyamashita>Wouldn't that necessitate that uninstalling package would remove that part of the user's directory. <ng0>gnunet suite on gentoo is like every piece of code somehow... i now spent 80% of the time fixing the 1% needed to satisfy developers in portage/gentoo <ng0>wasn't supposed to be a 4 months+ task <ng0>the old world is full of sadness. <lfam>kyamashita: Hairy. I would ask on guix-devel <lfam>kyamashita: I just noticed that all that code is in a heredoc. <lfam>So it gets run every time that nethack is ran ***pastaf is now known as Pastaf
<lfam>I would still ask on guix-devel. I would also ask nethack what their intention is. It seems strange they wouldn't make this configurable <kyamashita>Guile-WM crashed and killed emacs with it. Falling back to "Emacs as WM" setup. <civodul>i use ratpoison and i'm sure there's not much missing from Guile-WM to be usable day-to-day <kyamashita>civodul: It just stops, says "Failed to execute login command" (I believe that is SLIM talking), and drops to SLIM. <kyamashita>Other than that it's been useful to me. But when Guile-WM dies, it doesn't leave any thing odd in its log. <kyamashita>'#<xcb-connection (connected)>xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0.0"' <kyamashita>So maybe it's a problem with the interaction between Guile-WM and Guile-XCB. <kyamashita>I might take a look at it once I know enough of Guile. <civodul>probably best debugged in a 'guix system vm' than when used as the primary WM <janneke>ACTION throws in a wish for guile-wm ... <lfam>kyamashita: Create immutable QEMU VMs. There are also mutable VMs (guix system vm-image) and disk images (guix system disk-image), which is how our USB installer is created. <lfam>janneke: Do you have any problems with gnome-tweak-tools settings not being retained across reboots? I only use the "don't sleep on lid close" setting, and it is set after reboot, but I have to toggle it to make it actually work <kyamashita>Reading about it now in Guix's info documentation. <janneke>lfam: I'd have to check, I'm only using the workspace grid <lfam>janneke: No big rush, just curious if you'd noticed any issues <lfam>If you aren't using that feature, don't worry about it. I'll look into when I get annoyed enough ;) <janneke>lfam: I'm still not using GuixSD as my primary <lfam>janneke: It's my "stereo" computer, which is not primary but is still extremely important ;) <ngz>`wrap-program' expects bash executable to be available in PATH. However, <ngz>when using trivial-build-system, PATH doesn't seem to be set, even if "bash" or "bash-minimal" are among the inputs. <ngz>What is the correct way to use wrap-program in this case? <ngz>Use a (setenv "PATH" /path/to/bash) just above? <Pastaf>looks like I won't be able to install GuixSD <Pastaf>not until guix can cache downloads for future use, since there's no way in hell I'm going to try to figure out why guix system init is failing with no way to debug but && echo -e '\\a' <Pastaf>and I have no interest in running the machine back and forth for so far 20 times <ngz>Pastaf: AFAIK guix does cache downloads for future use in the store