IRC channel logs


back to list of logs

<castilma>I'm getting a supstitue error on gmp-6.1.2. crc errro check fails/invalid compressed file
<DoublePlusGood23>Any one currently working on this bug?
<DoublePlusGood23>was gonna give it a shot
<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
<brendyn>you can try `guix build --check`
<brendyn>or maybe guix challenge
<DoublePlusGood23>brendyn: thanks :-)
<lfam>DoublePlusGood23: Finding new sources for the things that used to be on would be awesome :)
<DoublePlusGood23>lfam: would a commit per package changed be the proper way to do it?
<lfam>DoublePlusGood23: I think that's a good idea
<DoublePlusGood23>lfam: awesome :-) expect some (small) patches soon
<lfam>Cool, thank you!
<DoublePlusGood23>lfam: if I have a url like `` should I only use the `name` variable for the final archive name?
<lfam>DoublePlusGood23: You can use it repeatedly. It's really a matter of taste, and 99% up to the person writing the patch :)
<DoublePlusGood23>lfam: sounds good :)
<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.
<DoublePlusGood23>lfam: looks like git send-email sort of buggered up my patches... oh well
<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
<DoublePlusGood23>lfam: that's good news - I think?
<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>Or Debian GNU/Hurd?
<Corin>I'm confused.
<DoublePlusGood23>lfam: huh, silly.
<DoublePlusGood23>Corin: I guess it would be just "the GNU system"
<Corin>Wait. GNU doesn't use Guix?
<DoublePlusGood23>I should checkout it's development again.
<brendyn>Hurd is another kernel, like Linux
<Corin>Yes, I'm aware.
<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.
<DoublePlusGood23>Corin: rude
<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.
<Corin>Like http.
<DoublePlusGood23>Corin: The IPC required for a microkernel gets messy real fast
<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.
<DoublePlusGood23>It's GPLv3 don't worry :p
<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
<DoublePlusGood23>Corin: whatcha here for?
<Corin>Was just here wondering if anything else was using Guix/Shepherd.
<Corin>Which you answered.
<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.
<lfam>DoublePlusGood23: Maybe this is a better home-page for kitchen:
<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 :)
<DoublePlusGood23>lfam: Interesting, I always end up doing it xkcd style - been trying to change that.
<lfam>Heh, classic cartoon!
<lfam>If you use Git regularly, it will "click" after a week or so, and then you will be a master
<DoublePlusGood23>Corin: I've found guile being really easy to pick up.
<DoublePlusGood23>lfam: I've been "using" it for at least 3y is the problem...
<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!
<DoublePlusGood23>lfam: pretty unix-y , not very pythonic
<DoublePlusGood23>how hard would this bug be? I've been looking at the ones tagged "easy"
<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.
<DoublePlusGood23>I'll try to tackle that bug tommorrow, for now I must sleep zzz
<lfam>Good night!
<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>yeah, it is
<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/
<marusich>info-local: $($(top_srcdir)/%.png)
<marusich>I get, vaguely, what info-local is, since I read
<marusich>What I don't understand is the stuff after it.
<marusich>What feature of make is that, where you can do $($(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.
<reepca>tab completion strikes again?
<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 ;)
<rekado>I use dvorak, but no spacemacs
<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
<civodul>Hello Guix!
<sneek>civodul, you have 1 message.
<sneek>civodul, rekado says: Yes, an instance of RCAS is running here:
<civodul>it's behind nginx
<civodul>pretty cool to see this kind of service in Guile!
<civodul>although it remains SaSS
<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>hmm, still 2.0.14
<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
<civodul>efraim: ok
<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?
<brendyn>Are we on guile 2.2 now?
<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 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/" 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
<efraim>do you mean config.status?
<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
<civodul>efraim: no, really ./configure
<civodul>rekado: ouch
<efraim>now i'm running ./pre-inst-env guix environment guix -- ./configure --localstatedir=/var
<civodul>rekado: FWIW it seems to build fine on hydra:
<rekado>civodul: hmm, okay. Will try again later.
<brendyn>Riot is really sucky software is there really nothing better?
<CharlieBrown>brendyn: Jitsi Meet.
<brendyn>I had thought jitsi was dead
<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. I think
<brendyn>is is in the browser only?
<brendyn>efraim: For me qtox has worked well, but people have said there are intractible problems with it. Do you know anything about that?
<efraim>i've never actually used it
<davidl>brendyn: I have heard so too. It might be that Tox doesn't cloak the ip-address innately and suggests tunneling through Tor instead.
<civodul>rekado: another bioinfo "worflow management" tool from work:
<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
<civodul> is 404 :-/
<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
<civodul>and is 404 too
<brendyn>maybe that algorithm can be made so that after the packages to be built are assembled, it is sorted alphabetically?
<civodul>not sure it'd buy us much :-)
<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>is it a GNOME dependency?
<brendyn>Required by evince
<brendyn>"for tests"
<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
<brendyn>source files are found via substitutes too?
<brendyn>is dogtail on ?
<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…
<efraim>rekado: objconv
<rekado>it’s still available but upstream has changed it in place :-/
<rekado>so there’s a new hash: 0dp67hzjpv4pic3i29kc2fzwwipgl9b9y6fd0j1z7mly4y20vdgv
<jlicht>hi guix
<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>because of webrtc support
<brendyn>i think there is/was an incompatibility between chromium and firefox's wbrtc. atleast with, 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)
<rekado>charting is optional
<brendyn>These are my latest errors, after updating guix and guilding from git
<ng0___>hi, has someone a solution or possible hint on the lvm2 static error?
<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..
<brendyn>I don't know how
<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
<civodul>ng0___: indeed!
<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 .. 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.
<brendyn>Can I hack on GNUnet with guile?
<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___>at least there's a gsoc project
<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 reported a bug.
<rekado>ok, never mind then.
<ng0___>I just came to check if someone else noticed the issue.
<brendyn>GNUnet fails with no code for module (gnu packages geeqie).
<brendyn>Maybe it needs guile 2.0
<ng0___>civodul: :+: is just an extension in bash, right? I have older exports which just leave this out
<efraim>Iirc geeqie got moved
<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?
<ng0___>man guix somewhere i guess …
<ng0___>ACTION looks it up
<efraim>I think we have a static e2fs package
<ng0___>oh, the :
<ng0___>it is exported...
<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 -
<efraim>Both on ext4?
<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
<civodul>err, *moved to git
<civodul>on two machines?
<efraim>I started on the aarch64 board and realized there wasn't actually any support for it
<efraim>Like for gprolog
<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
<ng0___>n ochanges.
<ng0___>x86_64 hardware
<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?
<Petter>This is the last part of my reconfigure output:
<ng0___>i see no -lm / libm though
<ng0___>Petter: should be the same as here
<Petter>Yeah, looks very much alike.
<ng0___>I'll be back.
<fladnag>rekado: do you have an idea how to fix it?
<fladnag>the lvm2 thing i mean
<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>I will get in touch with them
<fladnag>shortcut, they are on freenode as well
<fladnag>rekado, or anyone else: who has worked on our lvm2-static?
<rekado>git blame should tell you
<fladnag>the conversation in #lvm is not my field of knowledge
<fladnag>ie: i don't know anything about why, what, how
<rekado>is there a log?
<fladnag>one moment
<fladnag>probably no
<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>why do we link it static?
<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)
<rekado>ACTION has to go now
<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.
<civodul>heya reepca
<reepca>Hi civodul.
<civodul>how's everything? :-)
<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>reepca: awesome :-)
<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"
<brendyn>holy hell
<civodul>ACTION is done packaging PRoot
<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...
<reepca>~/.config/guix/latest ?
<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>is it possible to install guixsd offline by making a mirror with nginx and this configuration file ?
<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
<sneek>Got it.
<quiliro>thank you bavier
<quiliro>sneek: later tell civodul will installing guixsd offline be possible by making a mirror with nginx and this configuration file ?
<sneek>Got it.
<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
<quiliro>ng0: ^
<ng0>basically disk-image, poorly documented and online a minimal brain dump so far, similar to
<ng0>regardin nginx mirror, no not as far as I know
<ng0>is unrelated to
<bavier>quiliro: I'm not very familiar with the mirror, but I think it only mirrors on-demand
<quiliro> description has no use cases...searching in the site mentions something like being the secushare distro....that looks very interesting
<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
<sneek>Got it.
<efraim>sneek: botsnack
<quiliro>ng0: may i help?
<quiliro>if yes, how?
<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/] Error 126
<janneke>/gnu/store/7k893g1r03vk2n4nkpj1a9ldchy7k9s1-gcc-4.9.4-lib/lib/ 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
<ng0> covers some of the tasks.
<efraim>When I looked at the error message I said 'duh, cant work i686 binaries without qemu'
<janneke>efraim: right
<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>ng0: is there a test version?
<quiliro> is a bug which is too general
<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
<quiliro>ng0: so you need more devs
<ng0>I don't scale, correct.
<quiliro>well, i am not one
<ng0>the usual free software problem
<quiliro>if i can understand what pragmaOS seeks, i can possibly talk about it
<quiliro>as i did in FLISoL with Guix
<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
<quiliro>i can learn
<quiliro>i have no idea about gnunet
<quiliro>but i can learn too
<ng0> it's just a matter of fixing texinfo markup, and I'm just looking up most of the things I don't know myself.
<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
<quiliro>that is what i meant by "use case"
<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
<ng0>the error changed
<mbakke>ng0: oh noes
<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
<quiliro>mbakke: should i wait?
<quiliro>or should i install guix on debian
<ng0>the goal is to release next week if nothing breaks
<mbakke>quiliro: you can generate a UEFI disk image by taking the patches from bug
<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
<quiliro>mbakke: please
<quiliro>i have a guixsd machine
<mbakke>quiliro: you can fetch the branch here:
<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
<quiliro>i have a 4 Gb usb
<quiliro>4 GB
<quiliro>but a 32 bit guixsd machine only
<quiliro>and a very slow one
<quiliro>will it take long?
<quiliro>mbakke: should i git clone ?
<mbakke>quiliro: it takes a couple of minutes on my old-ish x86_64 laptop
<quiliro>git clone
<mbakke>quiliro: you can add it as a git remote and then just checkout the branch as usual
<quiliro>i don't understand
<quiliro>git remote
<mbakke>quiliro: if you have guix from before, use "git remote add mbakke"
<mbakke>otherwise just "git clone"
<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>i do not have guix on the macbook
<quiliro>what do you recommend
<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
<quiliro>boot and install over it
<mbakke>not guix, just the foreign binary installation
<mbakke>not guixsd*
<quiliro> yes...but after dd, i mean
<quiliro>i did "git clone" on debian
<quiliro>"git remote"
<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"
<mbakke>then "git checkout wip-uefi"
<ng0>oof :(
<ng0>wrong window
<quiliro>ok.... mbakke
<quiliro>and after that?
<quiliro>gpg --verify guix-binary-0.12.0.system.tar.xz.sig
<quiliro>verify signatures failed
<mbakke>quiliro: O_o
<mbakke>did you import ricardos public key?
<rekado>quiliro: you can get my key from or from a key server
<quiliro>not specified in
<quiliro>gpg-import what?
<rekado>gpg --search-keys
<quiliro>tñfoñpkñp oñpajd uacnñe
<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.
<quiliro>keyserver search failed
<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>I have not rebooted
<rekado>just waited a couple of hours while compiling webkitgtk in the background.
<quiliro>gpg: can't hash datafile
<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>oh...why is that?
<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.
<rekado>quiliro: does the file exist?
<quiliro>guix-binary-0.12.0.x86_64-linux.tar.xz.sig exists
<quiliro>i understand now
<rekado>you need both the detached signature and the signed data
<quiliro> was not downloaded
<quiliro>how to contribute to ?
<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
<reepca>quiliro: there's information about how to send patches in
<quiliro>ok...thank you both
<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.
<quiliro>on guix-daemon does not run