IRC channel logs
2017-05-11.log
back to list of logs
<castilma>I'm getting a supstitue error on gmp-6.1.2. crc errro check fails/invalid compressed file <brendyn>Gyah!! Roel added the package I was going to add! I'm offended, except it's such a relief <enderby>how do i do a 'gem install <pkg>' with guix. am I just not allowed to? <brendyn>Does it install into your home directory? <enderby>it tries to install to the gem environment directory guix tells me to use <DoublePlusGood23>Sometimes when I run `guix build` it will just return it's store value? is this supposed to happen? <brendyn>Because what `giux build` really does is return the location in the store of the build package. If that requires actually building it, then it will, if it's already there, then it'll just return it <lfam>DoublePlusGood23: Finding new sources for the things that used to be on fedorahosted.org would be awesome :) <lfam>DoublePlusGood23: I think that's a good idea <lfam>DoublePlusGood23: You can use it repeatedly. It's really a matter of taste, and 99% up to the person writing the patch :) <Corin>Hey, question. Are any other distros utilizing Guix and Shepherd besides GuixSD? <DoublePlusGood23>Corin: GNU/hurd uses Shepherd, and I think ng0 has an OS in dev that uses guix. You've probably heard of NixOS which GuixSD takes a lot of inspiration from and uses a similar package manager. <lfam>DoublePlusGood23: It's not `git send-email`, but debbugs, that had the problem. In any case, no big deal. The patches will still apply <lfam>Yeah, everything will work <Corin>DoublePlusGood23: What's GNU/Hurd? You mean GNU? <lfam>Basically, debbugs doesn't handle multi-email patch series well. To keep all the patches in one "bug", one would have to send a dummy email, get a bug number, and then mail the patch series to that bug number. <Corin>Er, not like Linux. Kinda like Minix's. <Corin>Linux is just a mess of shit. <DoublePlusGood23>Corin: not as it's main package manager afaik, there's been efforts to get it to function, and it mostly works. <Corin>DoublePlusGood23: It's true though. It's basically just a patchwork kernel. <Corin>But lots of tech is patchwork that ends up being used en masse. <DoublePlusGood23>Corin: You sound like my one friend. Currently he's on a crusade to solve "the #BrokenSystem" as he calls it. <Corin>Yeah, but the project is very deliberate in its design. Linux wasn't really planned out. Was just made on a whim. Linux in its current form ESPECIALLY wasn't intended. <Corin>Oh. I'm not on a crusade or anything. I'm not good with computers. I'm a linguist. <DoublePlusGood23>Corin: I'm not good with computers either, I end up spending so much time on them because of that. <Corin>Although this page does speak to me. <DoublePlusGood23>Corin: drop him a line, he's always looking for more crazies ^H^H^H^H^H help. <Corin>No time for anything like that. lol <Corin>Was just here wondering if anything else was using Guix/Shepherd. <Corin>Was thinking of switching to GuixSD, 'cause I like the design and all, but wanted to know if there were other similar options is all. <DoublePlusGood23>Corin: I wouldn't recommend switching full time, it's still pretty unstable. You can install it on top of another distro and it will function in tandem, but I've had issues with that as well. <lfam>DoublePlusGood23: If so, I can make that change locally; no need to send a new patch. I had already split that patch into two commits <DoublePlusGood23>lfam: agreed :-) One python lib used pythonhosted which seemed more offical. <Corin>Oh, hm. I've dealt with similar before though. It's pretty funny finding workarounds for bugs and making a usable system out of an unusable one. <DoublePlusGood23>lfam: How would I send different changes to the same file as separate commits? I opted for just the one, but useful info <DoublePlusGood23>Corin: If you have the computer to test on it's always worth a shot. Sending in bug rps and patches is nice to. <lfam>DoublePlusGood23: There are a million ways :) I like to use `git add --patch`, which offers an interactive interface for staging changes <lfam>So, `git add --patch` and then `git commit` <lfam>You end up with multiple commits, and then you can run `git send-email` or `git format-patch` as normal <Corin>DoublePlusGood23: Oh, I hate doing that. Sending reports/patches. I'm a very selfish person, you see. <Corin>(and my patches are always bad) <lfam>Maybe, maybe not, but we are constantly trying to grow new contributors to Guix. Everybody starts somewhere :) <lfam>If you use Git regularly, it will "click" after a week or so, and then you will be a master <lfam>When I get frustrated by my workflow, I assume there is a better way and I search for it. I figure there must be since its 12 years old and used by many. And usually, there is! <lfam>That's how I learned of `git add --patch` <lfam>I "used" Git for a year or two before I really started it using it heavily. That's when I started to need a better workflow <DoublePlusGood23>lfam: I don't really program that often either, I just know enough to cause damage :p <brendyn>I just dump everything into commits, then when I'm done I update master, make a new branch and remake all the commits manually <DoublePlusGood23>brendyn: at least with these commits, I pulled, made a separate branch, edited my files, then added and commited per file. Seem to work mostly OK - the --patch flag should especially help with package expressions. <lfam>See, a million ways to accomplish the task! <lfam>It's hard to say until you start. I would start by checking if that package's built output includes the missing program. If not, I'd poke around in the source code and search the internet for mentions of the program, to see where it is supposed to come from <lfam>I remember looking for a new libaio source when fedorahosted shut down. It's a bit disturbing to see things disappear like that! <DoublePlusGood23>lfam: Yeah, I'm surprised they shut it down and how many projects haven't migrated. <marusich>I have noticed that, somehow, when I log in, gnome-session seems to be sourcing (perhaps indirectly) my ~/.bashrc file. <marusich>Does anyone know how that might happen? I can't see anything in /etc/profile, /etc/bashrc, or my home directory's dot files that would cause this <marusich>To answer my own question: on GuixSD, we have implemented (in (gnu services xorg)) a slim-service (see 'info (guix) X Window') that runs a command like the following to start the graphical session: $SHELL --login -c $SESSION, where $SHELL is the user's login shell, and $SESSION is the session chosen at login (e.g., GNOME on X11). <marusich>Therefore, in my case, when I log in, slim actually executes something like: 'bash --login -c gnome-session' <marusich>That is a non-interactive login shell, which causes (accoring to 'info (bash) Bash Startup Files') the following files on my system to be sourced: /etc/profile, then ~/.bash_profile. My ~/.bash_profile in turn sources ~/.bashrc. QED. <marusich>The upshot of all this is that, even though it is not (yet?) documented in the Guix manual (as far as I can tell), this means that it's easy to set environment variables for both terminals and graphical sessions in GuixSD, which is nice. <reepca>So I finally got my desktop set up \\o/ <reepca>and holy moly the difference between hydra and --fallback is... extreme. <marusich>Such is the price of building from source without substitutes. <reepca>also, it turns out that applications only search the "assumed" info page locations if INFOPATH is either empty or ends with a colon. So if you install texinfo and source ~/.guix-profile/etc/profile in your .bashrc like you should, then you end up unable to find any of the non-guix info pages (in /usr/share/info or /usr/local/share/info, for example). ¯\\_(ツ)_/¯ <rekado>since ‘git add --patch’ was mentioned: magit (the Emacs UI for git) makes this even nicer by showing you the changes and allowing you to stage individual hunks right there. <rekado>brendyn: instead of remaking all commits manually you can do this in the same branch: git fetch origin; git rebase origin/master <rekado>brendyn: this will try to apply your commits on top of the latest version of master. <brendyn>surely I don't want to mess with origin/master? <Apteryx>brendyn: the git rebase thing means rebase *onto* origin/master, essentially rewriting your commits on top of current master. <Apteryx>reepca: Interesting. I didn't know about INFOPATH values needs to end by ":" if I want the standard locations to be looked up. <rekado>brendyn: you cannot mess with origin/master as you don’t have permission to push there. <efraim>git rebase also takes the '-i' flag for interactive, if you want to drop or rearrange or edit commits first <efraim>I do that when regular rebase fails from one of my branches <efraim>or 'git rebase origin/master' if I haven't pulled on my local master copy yet <rekado>it also makes it easy to amend commits that are a few commits back <rekado>you just make a new commit ‘tmp java’, then interactively rebase, move the commit right after the one it modifies, then mark it as a fixup commit <rekado>interactive rebase is very convenient in magit <rekado>it’s a bit rough without (e.g. you have to cut and paste lines to move commits and you have to manually change ‘pick’ to other commands) <reepca>Apteryx: yeah, I couldn't find any documentation of it in the man page for info or in the info pages for info. Only C-h v actually mentioned it (and now that I look, some people on stackexchange), but both emacs and the standalone info reader seem to behave the same way in that regard <efraim>I use it also when working on packages where I also have to package a dependency, which should be commited first <marusich>Does anyone know what the following line means in doc/local.mk? <marusich>info-local: $(DOT_FILES=%.dot=$(top_srcdir)/%.png) <marusich>What I don't understand is the stuff after it. <marusich>What feature of make is that, where you can do $(DOT_FILES=%.dot=$(top_srcdir)/%.png) ? <marusich>Since it involves two equals signs, it does not seem to be what is described in (make) Substitution Refs, since that involves a colon and an equals sign....... <brendyn>reepca: Do you know how to do that in Magit? I think it might be broken for me since I tried something like that with it's rebase feature and M-j but it didn't not respond to those key presses. <rekado>brendyn: are you using Emacs in a terminal? Dependent on your terminal you may need to do special acrobatics to get the meta key to work. <rekado>brendyn: I only use the graphical Emacs <rekado>(without it I couldn’t view pdf files) <brendyn>I use graphical emacs, but I have the colemak layout, and i use spacemacs, so it tends to bring about even more issues ;) <efraim>i have a working package for cli usage of google (and others) translate, dictionaries.scm? <rekado>efraim: dictionaries seems to be the closest match <sneek>civodul, you have 1 message. <civodul>pretty cool to see this kind of service in Guile! <rekado>we offer the software also as a Guix package for R, and it’s on bioconductor too. <rekado>(though there’s no need for the web interface when you use it directly in R) <efraim>for anyone interested, i ran `guix pull' on my aarch64 board, built guix with guile@2.0.14, and then ran `guix pull' a second time and now it's building guix2.2-ssh, presumably to build guix with guile@2.2.2 <efraim>python2-pandas FTBFS on aarch64, no taxtastic atm <civodul>efraim: 'guix pull' won't automatically switch to Guile 2.2.2 <civodul>it sticks to the currently used Guile <civodul>(a limitation of the current 'guix pull') <civodul>efraim: BTW, do you have an aarch64 board you could give us ssh access to, for the release? <civodul>or we could make the release without an aarch64 binary tarball <efraim>maybe a ./pre-inst-env guix pull for 2.2.2 <civodul>ah yes, that would pull with Guile 2.2 <efraim>i could set up something on my current board, i already opened a port to access it from the internet, but i've run into a few problems with my implementation <rekado>ACTION just built jamvm with jikes and GNU classpath 0.93 <rekado>jamvm is really small and is more recent than kaffe <civodul>rekado: so how long is the road? :-) <efraim>namely, i created the filesystem on /gnu with a newer version of coreutils than the board has, so every now and then when it fails to mount I need to transfer it to a different system to fsck it, but it hasn't been a real problem yet <efraim>i should really just update my board, that'll take care of it <civodul>efraim: well it would be best if the machine were reliable of course :-) <efraim>it's currently on debian stable, I must've run mkfs on debian testing <efraim>so its create a user and copy the "magic ssh key" to .ssh/authorized-users? <rekado>civodul: I don’t know yet. I need to try to build ecj next and then use that to build GNU classpath 0.99, rebuild jamvm with that version of GNU classpath, and then … maybe that’s enough to build icedtea already (i.e. jamvm + classpath 0.99 + ecj). <rekado>then we could cut GCJ loose and also get rid of the ecj bootstrap jar. <brendyn>I had to rebuild my whole git repo since I got all these funny errors ;;; ERROR: In procedure make_objcode_from_file: bad header on object file: "\\x7fELF\\x02\\x01\\x01???\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00" <civodul>brendyn: that's a sign you're almost on 2.2 :-) <civodul>brendyn: it's 2.0 complaining about 2.2 .go files <efraim>hmmm, infernal wants vmx or sse for parallel instructions <brendyn>;;; Failed to autoload make-page-map in (charting): <efraim>civodul: another issue, the guix-package.sh test fails on aarch64 <brendyn>I guess it's a bit bumpy is the Guix starship engages warp drive <civodul>efraim: that's no good, could you investigate or report details to bug-guix? <civodul>efraim: you can run "make check TESTS=tests/guix-package.sh" to run just this one <efraim>it might just be "guix: offload: command not found\\n guix build: error: build failed: unexptected EOF reading a line" <efraim>i already have --no-build-hook in my daemon <civodul>the tests use the daemon from the builddir, not the one running on your machine <civodul>so that's a misconfiguration issue: configure detected guile-ssh, but then guile-ssh is actually missing at run time <efraim>This showed up with guile 2.0 and 2.2 from './pre-inst-env guix build guix' <civodul>you probably need to "rm -f config.cache && ./configure -C ..." <civodul>so that configure re-checks whether guile-ssh is around <rekado>ACTION builds a bootstrap ant first, then uses that to build ecj <rekado>on i686 I get a segmentation fault when running make :( <rekado>it segfaults trying to compile all Scheme modules <rekado>must have been a fairly recent change as I just updated (last update was ~3 days ago), ran make clean-go, and make <rekado>it goes up to LOAD (guix download) and then segfaults on running compile-all.scm <efraim>now i'm running ./pre-inst-env guix environment guix -- ./configure --localstatedir=/var <rekado>civodul: hmm, okay. Will try again later. <brendyn>Riot is really sucky software is there really nothing better? <civodul>rekado: uh, also bad news for user namespaces i guess... <rekado>about the exploit: apparantly this is a local exploit, but it can be used within namespaces as well. <efraim>I've heard good things about jitsi meet. Meet.jit.si I think <brendyn>efraim: For me qtox has worked well, but people have said there are intractible problems with it. Do you know anything about that? <brendyn>How can I modify package definitions on the GuixSD installer <brendyn>tryng to build dogtool 0.8.2 but the source has died from linkrot <civodul>i think you could do "guix edit PKG" and do your thing, though that's a weird thing to do <civodul>brendyn: is it not available from the content-addressable mirrors? <civodul>hmm i don't see any "dogtool" package <brendyn>Perhaps guix fails to use the mirrors, since it actually redirects to a fedora wiki page saying the hosting is retired, which then causes guix to report the hash as incorect <brendyn>civodul: Another thing that I find odd is that the order in which guix chooses to build packages seems inconsistent. when I `guix system init ~..' again guix will start building another package usually, rather than the last one that just failed <brendyn>It's not exactly a bug, but it makes guix unpredictable <brendyn>maybe that algorithm can be made so that after the packages to be built are assembled, it is sorted alphabetically? <brendyn>In anycase I'm failing to build gnome stuff now, so I must be close to finishing the insallation <civodul>brendyn: one thing would be to find dogtail-0.8.2.tar.gz on the web, and then guix download it <civodul>normally the 0.12.0 binaries should have substitutes <efraim>Some of Julia's dependencies aren't version controlled and have disapeared <civodul>(BTW we have 3G of content-addressable source tarballs on mirror.hydra.gnu.org) <brendyn>source files are found via substitutes too? <brendyn>is dogtail on mirror.hydra.gnu.org ? <rekado>efraim: oh, I’ll try to fix that. <rekado>efraim: could you tell me which is not available? I still have all of them in my store… <rekado>it’s still available but upstream has changed it in place :-/ <rekado>so there’s a new hash: 0dp67hzjpv4pic3i29kc2fzwwipgl9b9y6fd0j1z7mly4y20vdgv <wingo>efraim: we use jitsi at work. you can install it on your own server and it works fine <wingo>thing is, for some reason it only really works in chromium tho <brendyn>i think there is/was an incompatibility between chromium and firefox's wbrtc. atleast with sharefest.me, you could/can only share with people using the same browser type <brendyn>;;; Failed to autoload read-pid-file in (shepherd service): <brendyn>;;; ERROR: missing interface for module (shepherd service) <brendyn>;;; ERROR: missing interface for module (charting) <brendyn>These are my latest errors, after updating guix and guilding from git <ng0___>would be good to fix before release, if we move forward as ludovic proposed <brendyn>ng0___: I have been worrying about GNUnet lately <brendyn>Seems like it could be 10 years before it's really ready for use <ng0___>if only everyone who worried about GNUnet would start fixing parts they worry about.. <ng0___>that's specifically why I do what I do <ng0___>and that's another issue, presentation <rekado>bleh, laptop frozen for the third time today <brendyn>I'm not exactly dosile, I'm working on guix in order to improve my programming skills <rekado>it’s not the best machine for compiling things all the time <rekado>ACTION already set up zswap but hasn’t rebooted since <brendyn>But the thing that concerns me is for example it may be useful to support other solutions in the mean time. the wait for GNUnet means proposals to use things like IPFS get rejected immediately <ng0___>brendyn: I hope to finish the documentation export soon, and dvn will start soon working on the new website for gnunet.org .. those are steps which are less obvious and not programming <rekado>looks like the class loader in jamvm doesn’t quite work when built with GNU classpath 0.93. <rekado>I need to find a faster way to get to a later version of GNU classpath. <ng0___>I don't want to reject GNUnet. You can add whatever you want for the system, I know I am working on solutions which will require GNUnet in the end, so if someone comes up with something as a middlepath for the time being, okay. <rekado>(actually, ‘frozen’ is a really poor term considering how hot this plastic case gets) <brendyn>ng0___: I'm not rejecting it, but I have a line of reasoning I wanted to discuss. I think the difficulty with switching to a GNU internet is that one cannot simply take someone elses HTTP site and magic it on to GNUnet or IPFS, atleast not easily. That is, part of the challenge is moving away from HTTP <brendyn>But if the internet largely used something like IPFS, it seems one could link it up with GNUnet much more easily <ng0___>wel lactually gnunet is ready for use. it just depends on getting towards a more reasonable release model, something which is on the roadmap. <ng0___>no, ipfs and gnunet aren't linkable <brendyn>How can it be ready for use? I have the latest git version. I cannot even download a copy of the GPL via file sharing, memory leaks and cpu usage cause me to have to kill GNUnet after 1 hour. Maybe this is just my build or config is broken and so my opinion is wrong <ng0___>part of why I'm so stuck on GuixSD and learning shepherd is so that I can create some kind of easiest, dead simple solutions cookbook where you can see usecases for servers etc.. right now it's terrible to setup <ng0___>it helps to report bugs if you think what you experience are bugs. <ng0___>there's gnunet-guile which needs fixes. <brendyn>I saw that but I couldn't undersand the code <ng0___>if you know rust, you can also hack on gnunet with rust <civodul>sneek: later tell bavier should we upgrade Open MPI to 2.1? <ng0___>there are some pieces and bindings to work on. <brendyn>How can I learn how to make bindings <ng0___>ah, the bindings for rust already exists.. or it is my impression as the others talk on mumble about it <ng0___>so I guess no one knows why lvm2/static fails. <ng0___>brendyn: probably also depends on where you use gnunet, dgolle helps to maintain it for embeded hardware like OpenWRT routers. but it's relatively common for certain types of software to use lots of resources ime. pybitmessage tends to do the same. <rekado>ng0___: maybe send an email to help-guix? I don’t think 20 mins is enough time to wait for something like this on IRC. <ng0___>it's not good, but in the end mobile devices with limited resources will not use the full build of gnunet <ng0___>I just came to check if someone else noticed the issue. <brendyn>GNUnet fails with no code for module (gnu packages geeqie). <ng0___>civodul: :+: is just an extension in bash, right? I have older exports which just leave this out <ng0___>the older exports just point to full paths <rekado>ng0___: I don’t know the context, but if I guess right that you mean variable expansion in Bash: the Bash info manual explains this syntax. <brendyn>Right, I can fix that and figure out how to send it upstream <rekado>ng0___: see section ‘3.5.3 Shell Parameter Expansion’ <brendyn>rekado: I ended up disabling zswap since it got real laggy <ng0___>how do I build the static variant of a package again? <efraim>I think we have a static e2fs package <ng0___>guix package -K lvm2-static is what i wanted <rekado>ng0___: I cannot reproduce any errors building lvm2-static <rekado>@ build-succeeded /gnu/store/pmqmi1dnggnf90zc1y6jny4v3xh86xcj-lvm2-static-2.02.168.drv - <civodul>efraim: oh, libffcall moved got git, sweet :-) <efraim>It still doesn't have aarch64 support so that was a fun upgrade :) <efraim>It sure is nice though to be able to work on two machines at once <efraim>I started on the aarch64 board and realized there wasn't actually any support for it <rekado>ng0___: could you provide more details on how you built it? <ng0___>guix system build /etc/config.scm <ng0___>pulls in lvm2-static for my config <rekado>do you get the same error when just building lvm2-static? <ng0___>could it be that this is related to the move to guile 2.2 and my way of handling that? <ng0___>root guix points to my user guix (in .config/guix/latest) and this in return points to my ~/src/guix/guix checkout, I briefly did a guix pull and updated the symlink again <Petter>I'm get lvm2-static error when I run `guix system reconfigure`. <rekado>ah, wait, I *can* reproduce this <rekado>it broke with 62ec02bf21a88330d5b9defef1152d6ec1e8541f, I think <rekado>the error seems to be that libdm doesn’t link with -lm? <fladnag>rekado: do you have an idea how to fix it? <rekado>fladnag: I don’t know. Maybe someone could contact upstream. <fladnag>in my opinion this needs to work in a release, as we point out cryptsetup things in the documentation. <fladnag>shortcut, they are on freenode as well <fladnag>rekado, or anyone else: who has worked on our lvm2-static? <fladnag>the conversation in #lvm is not my field of knowledge <fladnag>ie: i don't know anything about why, what, how <rekado>I was not on #lvm so I don’t know what was discussed there <rekado>ACTION is busy with java right now <fladnag>"why static" "it's not officialy supported" "dracut can do this without static linking" yadaya <rekado>well, they offer static linking with a configure flag <fladnag>they said that libm should be made available static <fladnag>and they regard the static solution as very fragile <fladnag>civodul worked on lvm2-static, no one else so far. <rekado>I think we need it statically linked for use in our custom initrd <fladnag>dracut generates an initrd aswell. so we need it because our initrd is different <rekado>fladnag: we build it from scratch with Guile. <rekado>file-system-packages in (gnu system linux-initrd) specifically needs statically linked packages for file system support. <fladnag>i noticed that for file-systems (which is why I have no xfs-progs finished so far) <Apteryx>reepca: re INFOPATH, the info about the column requirement to search for default locations is detailed in `info '(texinfo)Other Info Directories'` <reepca>Apteryx: Oh, I see - I was looking at the "info" info page, not at the texinfo one. <reepca>Well, over the course of the past week I got moved in back at home, got guix set up on my laptop, got my desktop set up, got guix updated on it, learned how INFOPATH works, learned that installing "hello" on a weak i686 laptop without substitutes takes several hours, and read various documentation. <civodul>did you install from the binary tarball? <brendyn>I updated libgpg-error locally and now I'm rebuilding zillions of things again. I guess that's why it hasn't been updated in guix? <civodul>brendyn: yes, see "guix refresh -l libgpg-error" <civodul>one of the most difficult packages i've ever made <reepca>Hm, I can't seem to run guix pull - I end up with "sed-hurd-path-max.patch: patch not found" <rekado>on my i686 machine I get “fatal: Unable to find remote helper for ’https’” when doing “git pull origin master” <rekado>has something changed in how git works? <rekado>and unfortunately I still get the segfault trying to compile guix from the git checkout (on i686) <rekado>maybe I just don’t have enough memory? <ng0>"guix pull: error: libtiff-CVE-2017-7593.patch: patch not found" <sneek>Welcome back ng0, you have 1 message. <sneek>ng0, efraim says: how about inxi source #f, replace 'unpack, one input of github/inxi.../raw/inxi.tar.gz/gitcommit <ng0>it is strange, with root it worked <ng0>just my regular user doesn't want it <ng0>nice, the guix for my regular user is completely broken. no actions possible <reepca>for me it's broken for both root and my user... can't remove "hello". And I'm stuck with the "bad header on object file" warnings since I can't pull. And rolling back isn't fixing it. <ng0>it is joy working with guix.. sometimes. <ng0>oh, there was another change with a second pull <ng0>copying and compiling to '/gnu/store/xdbd1sz8ql0ch02fxjzi9kczv4gklaaz-guix-latest' with Guile 2.0.14... <ng0>shouldn't that be 2.2? <ng0>normally I would attempt to just delete the user, but this is no option. <ng0>oh really? deleting the symlink was the solution... <ng0>at least for the unprivileged user. root, if this is broken, i have no idea right now <reepca>somehow it fixed it for root as well... strange. <ng0>as long as guix is your path that should happen (creation of this symlink with guix pull) <quiliro>i cannot boot the guixsd usb with rEFInd <quiliro>i installed rEFInd from Debian on this MacBook Air with nVidia chipset <quiliro>rEFInd is free software to replace EFI or UEFi <quiliro>how can i boot the guixsd usb on efi? <quiliro>has there an update in order to use claws-mail with spell checking? <bavier>quiliro: afaik the claws-mail spell-checking has not been fixed <sneek>Welcome back bavier, you have 1 message. <sneek>bavier, civodul says: should we upgrade Open MPI to 2.1? <bavier>sneek: later tell civodul updating OpenMPI is on my todo list <ng0>afaik that nginx conf is just for local mirrors, if you happen to run another computer in your network, which requires access to the internet (hydra) <quiliro>ng0: you mean that it will not work for making a mirror online and taking it to the offline lan in order to make a guixsd installation? <ng0>well as long as it can publish on another machine which is not related to the one you work on it will work <ng0>you might want (guix system disk-image) though <quiliro>is there a how to install and configure nginx as mirror? <quiliro>the idea is the the offline lan can install whatever package <ng0>regardin nginx mirror, no not as far as I know <ng0>is sites.google.com unrelated to code.google.com? <bavier>quiliro: I'm not very familiar with the mirror, but I think it only mirrors on-demand <ng0>i don't know what people expect as description and so called "use cases"... but I'm currently packaging more software to make the website writing less annoying. <ng0>the use cases I have and what this is the base for would simply be too much for people <ng0>what are use cases from your perspective? "you can use this to do foo bla"? <bavier>ng0: or a list of situations where pragmaos would be a good solution <ng0>sigh... i know why everyone hates documentation <ng0>i have more documented on paper and on whiteboards than on the website <bavier>yeah, I've got a bit of the same <ng0>i wasn't in favor of the media adverts designing parts of my highschool.. but I will get there with the website. I'm just doing so much at the same time <quiliro>ng0: i am sorry...i do not mean to be anoying....rather, if the impression i get of the use of pragmaos is correct, then i think it is great! <quiliro>if the impression i get of the use of pragmaos is correct, then i think PragmaOS is great! <quiliro>if, and only if, pragmaos = PragmaOS :-D <ng0>no it's not an expression of being annoyed. I'm just not so motivated to update the site. I knew about prep and think I will settle on moving most of it to prep and drop my attempt at writting something similar for now <efraim>sneek: later tell civodul 9 hours for make with guile2.2 on aarch64 <ng0>there are multiple use cases, if you tell me what you understood, it helps to refine the description. I have my view, but I can't talk about everything. There are features which are rough plans for now <ng0>a usecase is a base for 0, an application I'm currently designing. <ng0>*one of the usecases I meant <ng0>help? yes, it is very much welcome :) <janneke>not sure what i've changed, but "suddenly" i'm getting <sneek>janneke, you have 2 messages. <sneek>janneke, efraim says: mes failed on aarch64 like this: bash: out/i686-unknown-linux-gnu-mes: cannot execute binary file: Exec format error <sneek>janneke, efraim says: *** [module/module.make:14: module/mes/read-0-32.mo] Error 126 <janneke>/gnu/store/7k893g1r03vk2n4nkpj1a9ldchy7k9s1-gcc-4.9.4-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found <ng0>quirilo, would probably be better to move this to the mailinglist mentioned on the website as it is slightly offtopic here <ng0>though that is a matter of definition, almost all the tasks currently defined are for Guix <janneke>efraim: thanks...arm is still a bit out of reach for Mes <efraim>When I looked at the error message I said 'duh, cant work i686 binaries without qemu' <janneke>mescc can currently only compile to x86 <janneke>to bootstrap mes it reads the reader from a x86 memory dump <janneke>the x86 memory dump is [re]created by running an x86 binary <janneke>it's all very much work in progress :-) <quiliro>ng0: i still do not understand the bugs for pragmaos <quiliro>i will need to test so i can make documentation <ng0>quiliro, no there is no test version yet. the 'test version' is some more time down the road.. or more people and less time <ng0>I don't scale, correct. <ng0>the usual free software problem <quiliro>if i can understand what pragmaOS seeks, i can possibly talk about it <ng0>do you know texinfo? there's a very boring task mostly done by myself to fix the gnunet documentat. that is not developer centric <ng0>I will try to make it more clear then over the next couple of months. I'm just running multiple approaches at once, and one of them involves that I can't talk about everything which is attached to this system <ng0>but I can make it in general more clear who will use it, etc <ng0>talking about it would be cool :) which would require that I finish the writing tasks. I have a clear vision, but I'm not terribly motivated to write in documents. I prefer paper. Once the university applications are done I can do it I hope <mbakke>efraim: which bootloader are you using on the aarch64 cards? <ng0>quiliro, okay i see the problem and will fix it soon. website needs more information and documentation, intention, design, shortcomings, a hint on future connected projects etc. <quiliro>ng0: the idea is to motivate the user to use your distro....what kind of person would be interested in its features <ng0>to use would imply that there is something to use other than the upstream work ;) <ng0>right now there is nothing on its own <ng0>but I get what you mean, I knew this as long as the page was in its current state <efraim>mbakke: I think the odroid uses uboot <ng0>is someone interested in a small suckless editor in assembly? I could edit the description, move it from package path to master and prepare a patch against master <ng0>mbakke, unfortunately this did not fix the lvm2-static build <mbakke>ng0: which platform are you on? it builds here for x86_64, at least <ng0>now cryptsetup can't link against it <quiliro>please help to boot guixsd on rEFInd <ng0>I see why the developers told me that this is fragile <quiliro>my plan is to install it on the macbook air and run debian as a virtual machine on top of guixsd <mbakke>ng0: line 506 and 507 seems to be the issue, will investigate <ng0>imagine my virtual thumbsup :) <mbakke>quiliro: the next release should be UEFI compatible <ng0>the goal is to release next week if nothing breaks <mbakke>it also requires some other patches that are not in master yet <mbakke>I can push a branch somewhere, then you can pull it and generate a disk image <nikita1>does anybody know which version of libgrcypt / gpg-error is required to build guix? <mbakke>quiliro: would you like to try it? I haven't tested it on a macbook. <mbakke>you'll need a guix machine to generate the image, but I can also make one <mbakke>I haven't addressed ludos latest comments yet, but it should work <ng0>the alpine homepage disappeared. I hope it's just a technical error <mbakke>use "./pre-inst-env guix system disk-image --image-size=1200M gnu/system/install.scm" to build the installation image <mbakke>and then dd it onto a USB drive as usual <mbakke>quiliro: it takes a couple of minutes on my old-ish x86_64 laptop <mbakke>quiliro: you can add it as a git remote and then just checkout the branch as usual <mbakke>however, I doubt you can build a 64-bit image from 32-bit <mbakke>you can try with "--system=x86_64-linux" <quiliro>i am using guixsd on a 32 bit machine and have debian on the 64 bit macbook air <quiliro>perhaps git clone on the debian mac and then install over it <mbakke>quiliro: I think you'll need to install guix on the debian machine first <mbakke>not guix, just the foreign binary installation <quiliro>"./pre-inst-env guix system disk-image --image-size=1200M gnu/system/install.scm" <mbakke>quiliro: it's easier to start off with the binary installation <mbakke>otherwise you'll need to build guix and the daemon from source <mbakke>once you have guix installed, use "guix environment guix" <quiliro>gpg --verify guix-binary-0.12.0.system.tar.xz.sig <mbakke>did you import ricardos public key? <rekado>gpg --search-keys rekado@elephly.net <reepca>"if that comand fails because you do not have the required public key..." - right underneath the key-verifying part. Maybe we should instead assume that most people don't have rekado's public key and put that before it. <rekado>reepca: I’m shocked! Most people don’t have my public key…? :) <rekado>the segfault when compiling Guix on i686 disappeared, by the way <rekado>just waited a couple of hours while compiling webkitgtk in the background. <rekado>quiliro: could you show us the full command you’re running? <quiliro>gpg --verify guix-binary-0.12.0.x86_64-linux.tar.xz.sig <rekado>you need to append guix-binary-0.12.0.x86_64-linux.tar.xz <rekado>verify the signature for the data <rekado>gpg --verify guix-binary-0.12.0.x86_64-linux.tar.xz.sig guix-binary-0.12.0.x86_64-linux.tar.xz <quiliro>gpg: ne povas malfermi subskribitan dosieron 'guix-binary-0.12.0.x86_64-linux.tar.xz' <quiliro>gpg: can't hash datafile: eraro ĉe malfermo de dosiero <rekado>I don’t know. That’s what gpg expects. <quiliro>guix-binary-0.12.0.x86_64-linux.tar.xz.sig exists <rekado>you need both the detached signature and the signed data <quiliro>ftp://alpha.gnu.org/gnu/guix/guix-binary-0.12.0.x86_64-linux.tar.xz was not downloaded <rekado>the git error I reported earlier: caused by a wrong GIT_EXEC_PATH. The “.” before “guix-profile” was missing. Odd! <rekado>quiliro: it’s generated from the texinfo sources. <rekado>quiliro: they are in the git repository under doc/guix.texi <ng0>the first guix pull with guile 2.2 takes ages to compile <mbakke>ng0: the cryptsetup problem should be fixed now, sorry for the delay <mbakke>forgot to credit in the commit message, sorry! <mbakke>ng0: I've noticed compilation times are longer in general <mbakke>but guix is also noticeably faster, yay <ng0>no problem, and no rush :) <reepca>should I be using the emacs interface from melpa or from the guix package? <rekado>reepca: I would use the Guix package.