IRC channel logs


back to list of logs

<Pooff>Is it possible to replace the broadcom wifi-card of a Macbook Air with an Atheros one?
<brendyn>I just started reading the GNU hello source code. WTF
<brendyn>I thought this would be a nice introduction to how to make GNU sotfware
***kelsoo1 is now known as kelsoo
<ng0> , this train of thought especially about how distributions is weird
<brendyn>ng0: Send them an email maybe?
<ng0>I don't have the time and energy to invest in every tiny problem. I just found this and thought 'this is weird'. that's all
<ng0>oh... we ship that software. we can update to 1.1.6 as far as i understand licenses, and afterwards we are no longer allowed to distribute, ah even 1.1.7 .. the license was after the release.
<brendyn>Maybe we should fork it and make it better just to annoy him
<OrangeShark>ng0, davexunit is the one who added it to guix. He was talking about the license change a day or two ago on here.
<brendyn>Are you sure? I'm trying to install 1.1.7 and it's showing me the EULA
<brendyn>Is it just me or does thes EULA seem very unprofessional
<amz3`>I'm coming back to guix land thx to janneke debian-guix
<amz3`>janneke: let's continue here
<janneke>amz3`: yes, i must have built it by's in sid and stretch
<amz3`>while following the README from I got this error when I exec dpkg-buildpackage on ubuntu 16.04.1
<amz3`>janneke: ^ see the paste I posted
<amz3`>while building it says guix/ui.scm:254:7: source expression failed to match any pattern in form (report-error (_ "failed to load '~a': ~a~%") file (strerror err))
<janneke>amz3`: i suspect gettext
<janneke>i.e. (_ ....)
<amz3`>you mean that gettext must be installed?
<amz3`>ah yes
<janneke>yes, possibly a missed dependency
<amz3`>sorry I though that the _ was something else
<amz3`>sometime guile debugger, replace arguments with that i think
<amz3`>gettext is installed
<amz3`>I retried the whole process, it still fails with the same error
<rekado>I’m at QtCon 2016 / FSFE Summit in Berlin now
<rekado>there’s an AppImage poster in front of me as I’m typing this.
<Petter>Is it slightly behind a much bigger Guix poster??
<janneke>amz3`: i'll have a look ... no clue in configure output?
<amz3`>janneke: configure output of guix?
<jmd>Is LaTeX beamer packaged somewhere?
<amz3`>janneke: it seems to be ok, but here is the config.log
<rekado>Petter: hah, I wished. No, the poster session was yesterday. These posters are remnants.
<brendyn>In guile how can I copy files like main/Praat_128x128x32.png to /usr/share/icons/hicolor/128x128/praat.png? copy-file doesn't create directories as necessary, and install-file doesn't let me rename files
<rekado>brendyn: copy-file is the right procedure here.
<rekado>you’d just have to create the directories before-hand.
<rekado>brendyn: arguably this should be done by the build system.
<brendyn>I'm trying but it's getting complicated
<brendyn>Yeah, I found about 10-20 instances of redundant mkdir-p in the package definitions
<brendyn>Copying a file should be such a basic thing to do
<rekado>you could write a procedure that checks if the target dir exists, mkdir-p it if it doesn’t and then copies the file.
<brendyn>I'm trying but It's going to be like 10 lines of procedure
<rekado>it *is* a basic thing to do but the Guile procedures follow the system’s separation of concerns here.
<brendyn>I've been stuck with syntax errors for a couple horus
<brendyn>Like I want to contatenate "/" but when sometimes I get /.foo instead of /foo because the working directory is .
<janneke>amz3`: somehow you are using guile-2.1.3 to build guix..that does not work; you need guile-2.0
<brendyn>So I'm thinking maybe there are more advanced procedures I need.
<rekado>ACTION wonders if we could just switch to guile-2.1.3…?
<janneke>amz3`: that's prolly why the ui.scm problem
<amz3`>this is chicken egg problem to have guile 2.0 I need guix to have guix I need guile-2.0...
<janneke>ACTION is trying to build jesse packages to make it easier and find amz3's problem
<amz3`>janneke: the jessie problem is json
<amz3`>janneke: don't!
<rekado>brendyn: (let* ((file "/tmp/test.png")
<amz3`>janneke: I will fix that later, my server is busy doing something else
<rekado> (target "/tmp/some/place/else/abc.png")
<rekado> (dir (dirname target)))
<rekado> (mkdir-p dir) (copy-file file target))
<janneke>amz3`: sure, doing that esp for the next person
<janneke>amz3`: i have a guile-json deb for jessie
<rekado>amz3`: on new machines I always bootstrap with the binary release of Guix.
<rekado>then I fetch the git repo, enter “guix environment guix” and then build Guix from source.
<amz3`>rekado: The thing is that I'd like to use a deb package for installing guix on my server, to be able to recover (hopefully) from any issues
<amz3`>also it would be nice to have a deb package for ubuntu and debian
<amz3`>to help people get started
<rekado>amz3`: the Guix binary release comes with its own pre-populated store.
<amz3`>janneke: did you push guile-json deb somewhere?
<rekado>it doesn’t change anything outside of /var/guix and /gnu
<amz3`>rekado: so you say, it's of little use to have a deb?
<brendyn>rekado: I need it to be a procedure so I can do it with many files
<rekado>amz3`: yes.
<rekado>amz3`: if you use Guix you will use /gnu and /var/guix anyway.
<rekado>using the binary release gives you that.
<rekado>if you decide to get rid of Guix you just need to remove these directories.
<rekado>(and maybe /etc/guix)
<janneke>rekado: you still have to create the build users and setup the systemd daemon and publish things
<rekado>janneke: oh, you’re right.
<rekado>haven’t done this in a while :)
<rekado>brendyn: (define (install-file* source target)
<rekado> (let ((dir (dirname target)))
<rekado> (mkdir-p dir)
<rekado> (copy-file source target)))
<amz3`>janneke: build on jessie is on-going
<rekado>brendyn: but that’s weird because mkdir’ing for each file is overkill.
<brendyn>Is it?
<rekado>brendyn: that’s why that’s better handled case by case.
<rekado>brendyn: in the context of Guix it probably is. Usually the build system of the packaged software should take care of this.
<brendyn>Well the software I package is shit and I have to do everything myself
<rekado>I encounter situations like this often. I try to send patches to the developers to improve the software in these cases.
<brendyn>I've thought of that but it would take a couple months of work
<rekado>it usually takes a while. I’m not saying this should delay your packaging work.
<rekado>but sending patches upstream makes it possible for us to eventually simplify our package expressions.
<brendyn>Yeah. I could send some basic .desktop files and .png files, but if the package has no internationalisation to begin with
<brendyn>but the*
<rekado>brendyn: we don’t usually patch packages in Guix to add big features like translations.
<rekado>that’s work for upstream
<brendyn>How hard is it to add autoconf to a project?
<rekado>brendyn: I’ve done it a couple of times.
<rekado>depends on how much “alternative” build system stuff there already is.
<brendyn>I tried looking at GNU hello and decided it was too hard
<rekado>GNU hello is not the best intro.
<rekado>it’s a complex example.
<rekado>here’s something I did:
<brendyn>rekado: This is how it builds atm:
<rekado>I’m using this to check for the presence of tools that are called by the script, store the paths in variables and then substitute placeholders in the code with the full paths.
<brendyn>Plus a set of makfiles.def files you need to copy and paste depending on the operating system
<rekado>This doesn’t look too hard to convert to autotools, but you should check with upstream.
<rekado>some developers resist *very strongly* to changes to the build system.
<rekado>(because it “works” for them)
<brendyn>I bet they think this is really simple
<brendyn>And infact it does look quite simple
<rekado>but it only builds things.
<brendyn>But they have forked like 3-7 other code projects just to cram them into their build system
<rekado>it doesn’t have a proper installation target.
<rekado>are you saying that all the stuff under “external/” has been modified?
<brendyn>Atleast 3
<rekado>that’s the worst.
<brendyn>espeak, flpk, flac
<jmd>Running guix package -i xxx -p /run/current-system/profile returns an error:
<rekado>jmd: -p comes first.
<jmd>rekado: That has to be a bug.
<brendyn>That's what I'm reluctant to start talking to upstream. It feels like jumping down a rabbit hole
<rekado>jmd: maybe. Would you like to report this to
<jmd>rekado: I get the same error if I put -p first.
<jmd>(yes I am root)
<rekado>now I see
<rekado>you’re trying to install things to the system profile.
<rekado>I’m not sure if this is supposed to work.
<rekado>the system profile is governed by the OS configuration.
<jmd>system reconfigure ?
<rekado>suppose you succeeded to install something to the system profile like that and then did “guix system reconfigure“ later.
<rekado>your change to the profile wouldn’t stick around.
<rekado>system reconfigure is the right way to modify the system profile.
<jmd>Do I have to reboot after?
<rekado>I don’t think so.
<rekado>There’s /run/booted-system and /run/current-system
<rekado>current-system should have the changes, if I’m not mistaken.
<jmd>rekado: Thanks.
<brendyn>rekado: I just realised it make have been simpler to just use (system* "install" "foo" "baa"), but I suppose that is cheating
<rekado>brendyn: that’s certainly less elegant.
<rekado>you could, however, patch the Makefile to add an ‘install’ target where that’s done.
<rekado>then your Guix recipe would be leaner and you’d have a patch you can submit upstream.
<brendyn>Seems like a much better idea
<wingo>ACTION installs racket via guix
<alezost>jmd: rekado: it's impossible to install/remove anything to/from a system profile using "guix package -i"; only "guix system" should be used for this
<jmd>alezost: It might be an idea to have a warning on guix package if the user tries to do this.
<jmd>Somebody needs to update git
<janneke>amz3`: more jessie debs @
<amz3`>janneke: my build is in progress, it trying to pass the tests but some are failing
<janneke>ACTION is amazed by npm and jlicht's importer
<janneke>the `babel' package, a prerequisite for the the gulp build system which is needed to build the har-validator library needed to run the node-gyp build system, has a list of over 6000 dependencies
<janneke>i would be amazed if it's at all possible to build any except the most trivial npm package from source
***frafra_ is now known as frafra
<davexunit>janneke: npm is absolutely horrifying
<dvc>how can I guix graph bare-bones.tmpl? I'm trying to find out where the locale-2.23.drv comes from...
<brendyn>Can anyone help me figure out how to turn this into a mirror:// link?:
<janneke>davexunit: in an effort to be more humble in my attempts i'm now trying to build `q' from source ... a fairly essential library, to see if i can still support the usage of npm
<janneke>that is...if we cannot build from source, do we still want to us it?
<janneke>atm, i'm at 900 packages needed to build npm's `q'
<janneke>and counting
<dvc>brendyn: look at guix download
<janneke>davexunit: i sent you a somewhat uninformed websocket patch, any ideas on that? i figured trying to use it that handling multiple clients must first be addressed?
<brendyn>Ok now guix build is running configure in an infinite loop
<dvc>guix graph -e '((@ (gnu system) operating-system-derivation) ((@ (guix scripts system) read-operating-system) "gnu/system/examples/bare-bones.tmpl"))' doesn't work :/
<davexunit>janneke: haven't looked at it, so I don't know.
<davexunit>janneke: just looked at it. I don't think I want to apply it, sorry.
<davexunit>the websocket server isn't really an http server
<davexunit>I already use the guile web modules to handle the initial http request
<davexunit>now I should use the new async ports in guile 2.2. to handle multiple clients on a single thread
<janneke>sure...iwbn to use the same port for websockets and http (think corporate firewalls, proxies)
<davexunit>I don't see an issue.
<janneke>OK, i'll probably have to look better then
<davexunit>if a service has an http server component and a websocket server component, simply putting nginx in front of them and routing requests as necessary will do the trick.
<janneke>ah! we've been doing that using npm's express and websockets...i intended to support that with guile's webserver and your websockets too
<janneke>ACTION never looked at nginx
<brendyn>Can I require libng 1.2.x instead of having exactly 1.2.57?
<jmd>What's wrong with this fragment: `(#:configure-flags
<jmd> ,(string-append "--with-pluginpath=" (assoc-ref %outputs "out"))))
<jmd>I get Unbound variable %outputs
<brendyn>jmd: use outputs
<rekado>jmd: configure-flags needs a list
<rekado>brendyn: no, ‘outputs’ is not available at this point
<rekado>jmd: I think you shouldn’t unquote.
<brendyn>I feel like (assocref %outputs "out) appears so often it should be bound to "out" by default
<rekado>brendyn: packages can have multiple outputs.
<brendyn>But the are things like "doc" "bin" ...
<jmd>rekado: Thanks.
<rekado>jmd: the whole arguments expression is quoted. It is ‘inert’ data. That’s passed to the build side and evaluated there.
<rekado>when you unquote the code is evaluated *right now*.
<rekado>%outputs is only available on the build side, so it shouldn’t appear in an unquoted expression.
<wingo>what libre wifi drivers are people using?
<brendyn>My wifi cuts out quite a bit now compared to when I had a wifi card with nonfree drivers
<wingo>hmm, my wifi cuts out even with nonfree drivers (iwlwifi)
<wingo>maybe it is an unrelated problem
<wingo>i have a funny bug right now -- just upgraded my profile and all the "fi" ligatures in firefox are now an upside down lower-case omega with a bar on top
<wingo>pretty weird :)
<ng0>someone yesterday(?) said that they had the haskell package shelly packaged in the past? This is the last package which is missing in the dependency chain of darcs
<ng0>shelly had a dependency issue where I need to bootstrap: A depends on package B, B depends on A and C, C depends on C and B or what it was
<ng0>some forgotten wip patch of it would help
<janneke>ngo: darcs isn't dead?
<ng0>2.0.12 .. idk. I packaged it
<ng0>doesn't read like it is dead
<ng0>otherwise enjoy 28 new haskell packages
<janneke>we used it for lilypond before git because it seemed neat until it got stuck too often in infinite loops
<ng0>I need darcs... I want to checkout some other dvcs which provides its source through darcs
<ng0>that's the only reason
<ng0>if it helps someone.. good
<ng0>but that's a sideeffect for me
<ng0>I have sent everything now, the only wip-patch is darcs.
<wingo>i think darcs improved in the last year or so, fixed some fundamental issue
<ng0>i'll comment the darcs patch in an email.
<wingo>that was causing their complexity to explode or so
<ng0>we have a birthday party here later, I need to do some housework now.. so if someone feels like reviewing the 28 patches minus darcs that's good, otherwise I'll try to work on shelly the next days
<ng0>there's also another big package in there, ghc-graphviz
<ng0>i've done my best to rely only on "tests succeed, build succeed == it works"
<ng0>to discover the working or broken state is up to me when I try darcs, or up to people who use haskell.
<ng0>*up to myself
***marxistvegan_ is now known as marxistvegan
<brendyn>It's certainly a learning experience maintaining my git repo while nobody has accepted my patches and I keep pulling from upstream :p
<jmd>git pull --rebase
<brendyn>I'm using magit
<jmd>Oh well, that's your fault!
<brendyn>Excuse me?
<jmd>Use the proper tools for the job.
<brendyn>Do you know how to view a diff showing the changes I just pulled from upstream?
<OriansJ>jmd: Some people need more time to get comfortable with tools like raw git
<brendyn>What's wrong with magit?
<jmd>OriansJ: I wasn't suggesting that he use the git "plumbing" commands.
<OriansJ>brendyn: it is a good beginner tool but it hides alot of the power in git itself. But it is much better for people who are not comfortable with the requirements of total control.
<brendyn>Fine, I guess I'll learn it then
<jmd>It's not that those things hide the "power". It's that they hide the principles. If one never learns the principles, then one will never learn further.
<OriansJ>brendyn: Small steps work best, simply do a couple things you'd normally do in magit in git and you'll learn what you need as you go [if something seems painful or hard, there probably a better way to do it]
<OriansJ>jmd: I fear few will ever choose to learn the principles, as quite frankly it is harder way to enter a problem set.
<jmd>OriansJ: That is not correct. In fact, the opposite is true. The only reason that some people are afraid to learn, is because there are those who try to tell them that "it will be too difficult".
<jmd>Of course the hidden message there is "it is too difficult for YOU. You are too incompetent to learn that. I know it, but YOU couldn't possibly hope to."
<jmd>I prefer to treat people as adults and get them to learn adult tools.
<OriansJ>jmd: the difficulty is never about cognative load but rather amount of work they are willing to do to learn a new skill.
<OriansJ>I have even known a blind man moderate mental retardation, who literally memorized everything he needed to know to become a PC field technician.
<jmd>OriansJ: Well I don't know if you have children. But if you do you would probably want them to learn to read and write. But that is a big learning curve. It's much better if they just look at the pictures and guess what the words say.
<ng0>when i started using git, i did not even know maggit etc existed.. and even when someone starts with tools such as magit, they still learn something and they can decide on their own when/if they feel like learning plain git.
<OriansJ>jmd: I agree with several of your general points but I think our disagreement is about who decides if it is worth it. My perspective is that it is up to the learner to decide if it is worth the time investment for them. I allow them the choice to choose badly, even if I feel it is a skill that might really improve their life.
<brendyn>My problem is that it's hard to find situations to need to learn the things I want to learn.
<jmd>Sure. Everyone has the right to make their own choices. But I do think it is right to point out to them the consequences.
<jmd>brendyn: Well if you want to learn git, then hacking on guix is a good way to start.
<OriansJ>brendyn: Make as many excuses as you can to learn. I wanted to learn assembly, now that I am working on Stage0 I HAVE to learn it to make any progress.
<quigonjinn>brendyn: you can rebase using magit as well
<OriansJ>jmd: I'm not sure we can accurately know the consequences but rather point out some potential benefits; most of which probably will not be the problem set which this skill will benefit that person.
<ng0>brendyn, remind me later (via sneek?) to paste you the link to the classroom archlinux classroom project gave on git for beginners recently
<brendyn>I have done several simple rebases
<jmd>OriansJ: Right! Rote learning a the solutions to a set of problems, only helps you with that set. Learning principles allows you to apply those principles to problems which you hadn't anticipated.
<brendyn>What is the command to build the GuixSD iso?
<rekado>I haven’t followed the discussion (moderating discussions in meat space now), but I should say that I’m using magit as well, daily. Great tool.
<brendyn>I'm still wondering how to setup Guix from git properly. at the moment I just use GUIX_PACKAGE_PATH to a directory where I symlink the files I've edit to, which works but then guile complains about haven't old .go files
<rekado>brendyn: I think it’s the ‘guix system disk-image’ command.
<alezost>ACTION uses magit all the time and almost never uses git directly :-)
<rekado>brendyn: Guix from git is explained in the manual somewhere.
<brendyn>I think I've read it
<rekado>brendyn: you use an existing Guix to do ‘guix environment guix’, then bootstrap the git checkout.
<rekado>can’t send any more info right now because I’m kinda busy.
<kete>I didn't know about Arch Women.
<brendyn>We need to start Guix gals
<kete>or Gal Guix
<kete>or assert that Guix includes gals
<brendyn>Maybe. I pronounce Guix as gwuix because I think geeks is silly
<ng0>personally I see no need for it in Guix, the community is welcoming enough, open enough, problems can be solved.. guix coc includes this already, I'll only start thinking about it if guix starts to fail there or someone feels not secure and welcome here
<ng0>I should maybe add to this sentence that I fall in one or more of the groups mentioned on the archwomen page. so far my experience with guix was great
<brendyn>I'm not a part of any community to begin with really so I've never seen these issues
<ng0>issues are often overlooked by the people not affected :)
<ng0>though there are elements I feel worth adding to guix as a community, but I have no time now.. /me afk
<brendyn>I'm trying to run a system* command that contains ` foo bar `. It seems the back ticks aren't playing nicely
<jmd>brendyn: You could try $(foo bar) instead
<brendyn>I just end up with everything as a single argument of running in the shell
<jmd>brendyn: If you don't want that, then use "system" instead of "system*"
<jmd>(That is somewhat dangerous though.)
<brendyn>I'm trying to run gcc -std=gnu99 -o sendpraat -DUNIX `pkg-config --cflags --libs gtk+-2.0` sendpraat.c
<brendyn>Ok I quit. I can even run a single command line after a coule hours of trying
<brendyn>Ok I got it working
<brendyn>However there is another problem
<brendyn>The compilation uses pkg-config to get flags but it errors by default
<jmd>what is the error?
<brendyn>No package 'gtk+-2' found
<brendyn>No package 'gtk+-2.0' found
<brendyn>I tried a few combinations
<jmd>Well do you have gtk+2 installed?
<brendyn>When I run guix environnment guix; guix package -i gtk+@2; export....; pkg-config.... it works
<jmd>Try pkg-config --list-all | grep gtk
<brendyn>Well It's in the inputs
<jmd>If your package has a misbehaving build system, the you may have to set PKG_CONFIG_PATH
<brendyn>I'm also confused about if I should type gtk gtk+ gtk+2 gtk+2.0 gtk+3 gtk3 gtk2 or what?
<jmd> `(("gtk2" ,gtk+2) should be gtk+-2
<jmd>And are you sure that you need both gtk2 and gtk3 ?
<brendyn>That was just to test it out
<brendyn>`(("gtk2" ,gtk+-2)) or `(("gtk+-2" ,gtk+2) ?
<jmd>Why don't you have a look to see what some of the other packages do?
<brendyn>Last time I did that I was looking at two pacakges doing it differently
<jmd>Most have ("gtk" ,gtk+-2)
<jmd>but in fact, the first value - the one in "" can be anything. It's just a label.
<brendyn>Where does the label appear?
<jmd>Have a look for example, at rep-gtk
<brendyn>The mailing list is at peak hour atm
<brendyn>jmd: Perhaps gtk is simply not isntalled with header files?
<brendyn>I cant seem to find them
<jmd>Oh wow it seems that substitute* doesn't work with badly endoded files.
<snape>hi, what is the core-updates branch?
<efraim>when changing a package or function will cause a large number of rebuilds it often gets put in core-updates
<snape>I see, and how often is it merged into master?
<jmd>What are our rules about .desktop files ?
<civodul>jmd: it's better to have them :-)
<jmd>Do they have to go in any particular directory ?
<jmd>etc ...
<snape>is there anyone working on packaging postfix?
<paroneayea>snape: the core-updates branch is where things that will take a lot of work to rebuild (possibly due to being a major dependency to many other packages) go until enough binaries are built to where they can be put to master
<civodul>jmd: in 'share/applications'
<snape>paroneayea, so if I understand well, without core-update, everybody would have to rebuild, say, linux-libre every time someone updates perl
<snape>s/linux-libre/rebuild linux-libre/
<snape>ohh im tired forget it :)
<civodul>snape: yes, exactly
<jmd>civodul: thanks.
<snape>so I guess that in some way, core-updates changes must trigger the guix build system
<snape>by build system I mean the equivalent of jenkins
<snape>the build farm
<snape>thats it
<snape>isnt it?
<paroneayea>snape: yes, Hydra
<paroneayea>is the Jernkins equivalent
<snape>I understand. thanks paroneayea
<snape>is guix pull equivalent to checking out the origin/master branch?
<snape>or is it a bit late
<snape>and is there a way to know to which commit a guix pull "instance" refer?
<civodul>snape: it's equivalent
<civodul>currently there's no way to know what commit it pulled, but there are plans to change it
<snape>ok thanks civodul
<civodul>basically by having 'guix pull' simply run 'git pull' in a cached checkout
<snape>also, what is guix policy concerning packaging
<snape>I mean
<snape>more archlinux (we dont patch upstream)
<snape>or debian (we add a lot of patches so user are happy)
<civodul>snape: we patch as little as possible
<civodul>i'm not sure if it's written down somewhere, but that's the tradition :-)
<snape>got it :) thanks civodul
<efraim>efraim@scw-81fda2:~/workspace/guix$ time ./pre-inst-env guix build hello
<efraim>substitute: error: executing `/usr/local/libexec/guix/substitute': No such file or directory
<efraim>guix build: error: build failed: substituter `substitute' died unexpectedly
<efraim>i might have to work on it tomorrow, getting late here
<efraim>my scaleway arm vps didn't like the armhf release and i seem to run into all sorts of trouble building from source
<civodul>ACTION notices that the closure of (guix ui) contains... 105 modules
<civodul>efraim: something's wrong! :-)
<civodul>howdy paroneayea!
<paroneayea>ACTION needs to fix eir home backup server! or rather, get a new one
<efraim>lol, you think ;)
<paroneayea>anyone running a small, power-light'ish computer with guix for this kind of stuff?
<paroneayea>I might get but wouldn't mind something cheaper.
<efraim>hmm, ./guix-daemon or ./pre-inst-env guix-daemon ?
<civodul>efraim: the latter
<civodul>unless you've already run 'make install'
<efraim>i skipped make install
<civodul>so you definitely need ./pre-inst-env
<efraim>I was planning on `sudo guix -i guix` and going from there
<efraim>hey, its working now
<efraim>* for various definitions of working
<efraim>efraim@scw-81fda2:~/workspace/guix$ /./gnu/store/jbsy0d2ya7cllj7r9qlxw8k1ga0xfssk-hello-2.10/bin/hello
<efraim>Illegal instruction
<civodul>paroneayea: i don't have anything like that!
<paroneayea>I had something like that
<paroneayea>but the server broke :)
<civodul>efraim: perhaps it's not an armhf?
<paroneayea>and I've been backing up to a usb drive, but now my wife's PHD work is not backed up
<paroneayea>I used to use dirvish on debian so that I had nice incremental backups
<snape>paroneayea I use
<efraim>model name : ARMv7 Processor rev 2 (v7l)
<efraim>Hardware : Marvell Armada 370/XP (Device Tree)
<efraim>Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
<efraim>no neon
<snape>its much cheaper, with coreboot, low power
<paroneayea>snape: hm interesting
<snape>and (killing feature) 3 ethernet ports
<demotri>In which module is %standard-phases defined? I can't find it.
<paroneayea>well I don't need 3 ethernet ports :)
<snape>aha :) I thought I needed them but I never actually used them
<paroneayea>snape: the killer feature you didn't need? :)
<paroneayea>would be useful on a DIY router though
<snape>I can be useful for playing with routing stuff, yeah
<paroneayea>hm, though
<paroneayea>maybe the MinnowBoard is enough
<paroneayea>I have a beaglebone black but,
<paroneayea>no grub for that yet
<paroneayea>and u-boot is sooo close to being merged for guix :)
<paroneayea>maybe I should wait a week and see if that lands :)
<efraim>yeah, armhf needs hard float, thumb-2 and neon
<civodul>snape: i learnt about PC Engines recently; does it run Coreboot or Libreboot?
<snape>they sell it with coreboot, which is great. I just works. I didnt try to reflash it.
<snape>probably porting it to libreboot should is not too much work
<civodul>yeah, depends on hardware details
<civodul>but anyway, i've been pleasantly surprised by PC Engines
<snape>I own two of them
<snape>and one of them is my mail server
<snape>which unfortunately isn't running guix
<snape>I want to spend some time to try to package Postfix
<civodul>that'd be great
<jmd>Wasn't there a freedom issue with postfix?
<snape>it is packaged by parabola...
<demotri>OK, I "found" %standard-phases: I forget to`(quasi-quote...
<efraim>civodul: so it looks like this arm vps doesn't actually support guix's armhf port, so i'm going to test building hello on master, and if that works I'll call it a "success" and keep it around for fun. and testing gcc-6.2.0 default
<civodul>BTW, i'm trying to build GCC 4.9.4 minus the gcc/config/arm 4.9.3-to-4.9.4 changes
<civodul>to see if it "solves" the bootstrapping issue
<efraim>3 euros a month is a great price, even if it is slower than the armv8 boards I have
<OriansJ>I am honestly suprised by how trivial it was to add dynamic execution tracing to the stage0 vm, which fyi is a new optional feature :D
<civodul>OriansJ: which VM?
<OriansJ>for platform indepent reproducible bootstrapping of the root binaries
<OriansJ>Which when stripped to the minimal required functionality can be implemented in 64KB, thus allowing even C64s to validate the results :D
<OriansJ>The vm's code is written in a form that could be manually converted to assembly by hand should any individual desire to spend the time on the task.
<OriansJ>I haven't bothered to optimize for performance, largely because it can execute 278186 instructions in 0.08 seconds on my old computer
<OriansJ>[time taken and number of instructions executed to self bootstrap the stage1-assembler2 with itself]
<OriansJ>or about the same performance as a 3.5Mhz CPU which completes every instruction in exactly 1 clock cycle
<efraim>got a backtrace from guix graph
<efraim>I piped it to `dot -tpdf`
<efraim>graphviz printed --help, and guix graph wasn't happy