IRC channel logs

<OriansJ>sneek: later tell janneke that I have a special surprise bubbling up at the moment. :D

<OriansJ>sneek: botsnack!

<benny>I installed a packge with guix package -i, and then I uninstalled it with -r but it's still in my path. even after a reboot. I checked if it's in the system's config.scm but it's also not there. How would I find out why this is ?

<lfam>benny: Do you see the package in `guix package --list-installed`?

<benny>lfam: no, it's empty

<lfam>benny: Okay, what is the value of the $PATH environment variable?

<benny>/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin

<lfam>benny: Okay, the package must be available as a system package, rather than a package installed by your user

<benny>oh, the package is "zile", maybe it's part of %base-packages

<lfam>That's right, it's part of %base-packages: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system.scm#n508

<benny>lfam: thanks!

<lfam>You're welcome, benny!

<taohansen>would this be a correct way of defining TearFree for my Intel driver in my config.scm? https://paste.pound-python.org/show/SoJQyO1jRrwctDXsgH0s/

<OriansJ>has anyone taken up the task of packaging the tor-browser yet?

<buenouanq>taohansen: does that work?

<buenouanq>I can show you how I did it, but yours is nicer

<kevinfish>how can you list the files in a package?

<buenouanq>taohansen: https://rectilinear.xyz/p/132133dcc2+ is how I do it

<lfam>kevinfish: If you just want to list the files, you can do `find $(guix build foo)`

<lfam>Is that what you meant?

<taohansen>buenouanq: haven’t tried it yet. thanks for your config. :-)

<buenouanq>the commented section is what goes in that file if that wasn't clear

<buenouanq>rather than reading from an external file, you could prolly define whatever to just be that string

<brendyn>How do I check what substitute servers I'm using?

<kevinfish>lfam: will that work if its uninstaled too?

<xelxebar>Dang. I got disconnected it seems

<xelxebar>Just installed vim and it's complaining that I need to relink libpng and libfreetype with libpthread

<xelxebar>There's an email thread where someone was seeing the same problem, but for them a guix pull && guix package -u got rid of the error.

<xelxebar>That's not working on my end. Is it likely that some grafting operation screwed up some libraries?

<xelxebar>Actually, how do I find out exactly which commit my guix-latest is at?

<bavier1> xelxebar: 'guix --version' should show the commit if you've done a 'guix pull'

<xelxebar>bavier1: Thanks. That's an obvious one :P

<Guest85319>That's strange, I've just "guix reconfigured" my openssh service from port 2222 to port 22, but it still seems to be running on 2222. I've tried "herd stopping/starting" it which work, but doesn't change the port.

<rekado_>Guest85319: you need to stop ssh-daemon and then reconfigure.

<rekado_>it’s a known missing feature of the shepherd.

<Guest85319>thanks rekado_

<Guest85319>that worked - now running on port 22

<boskovits>hello guix!

<boskovits>I'm now at the Reproducible Build Summit, and I would like to package python-networkx, so that we can have better understanding of our dependency graphs.

<boskovits>I got some strange error from python-build-system, in phase 'reset-gzip-timestamps' I got In unknown file: 0 (open "/gnu/store/vl8wngq035vkk9s5y2apvkgyss397624-pyt…" …) ERROR: In procedure open: ERROR: In procedure open-fdes: Permission denied

<boskovits>I can build with this phase disabled, but the result is not reproducible.

<boskovits>I also have a .lock in the store with the output name.

<boskovits>Anone has seen this error already?

<cbaines>boskovits, could you perhaps post the package definition, and full build output to http://paste.lisp.org ?

<efraim>from owncloud-client: Built from Git revision 57bc79 on Jan 1 1970, 00:00:01 using Qt 5.9.2, OpenSSL 1.0.2l 25 May 2017

<efraim>looks like there's a timestamp somewhere to remove

<wingo>always a bad sign when you upgrade guix and it starts building glibc

<xelxebar>wingo: All the fun of Gentoo for your pleasure :)

<wingo>it is a bit of a lottery isn't it, whether guix is debian or gentoo -- depends on the state of hydra :)

<xelxebar>That reminds me of that image of a "Don't Turn off" sign on one of the first computers running "The Internet"

<xelxebar> https://en.wikipedia.org/wiki/CERN_httpd

<xelxebar>It's the first file server :P

<amz3>héllo #guix, what's up?

<mekeor>hello amz3 :)

<clacke[m]>xelxebar: ftp existed before that machine

<ng0>hey… I have an application that is using pkg-config to check for gst-plugins-good, in a way which obviously requires gst-plugins-good to have the gst-plugins-good-1.0.pc file in the pkg-config path. However this does not exist (neither for -good nor for -ugly (or was it -bad?)), and the source of gst-plugins-good only includes a "pkgconfig/gstreamer-plugins-good-uninstalled.pc.in" … I'm irritated by

<ng0>"uninstalled". The software in question is a gstreamer project aswell (gnonlin). Is it established in operating systems just to pass the path by hand? I looked at Gentoo and Nix, they don't change a thing for gnonlin.

<ng0>I could send a patch upstream, but maybe you have a better idea.

<ng0>*better ideas

<ng0>I can use GST_PLUGINS_GOOD_LIBS and the like

<ng0>but I think we will run into a check for gstreamer-plugins-good-$VERSION.pc on other occasions…

<brendyn>I noticed that things like 'killall emacs' don't work

<ng0>the process is not called emacs

<ng0>you probably want to find out the name of the process or the ID and use killall with that

<brendyn>what is it called then?

<ng0>Do I know the emacs version you use?

<brendyn>25.3

<ng0>"top", or it is usually emacs-VERSION-something

<brendyn>I tried that too but it didn't work either

<ng0>oh, you are right

<brendyn>for me the process is called /gnu/store/sq118zpg6kzqwjsldbspjkwn0cfl8rp3-emacs-25.3/bin/emacs-25.3 but killall /gnu/store/sq118zpg6kzqwjsldbspjkwn0cfl8rp3-emacs-25.3/bin/emacs-25.3 doesn't work either

<brendyn>killall pcmanfm works

<brendyn>Ok I figured it out

<OriansJ>brendyn: have you tried: killall emacs-25.3

<brendyn>The process name is /gnu/store/sq118zpg6kzqwjsldbspjkwn0cfl8rp3-emacs-25.3/bin/.emacs-25.3-real

<brendyn>'killall /gnu/store/sq118zpg6kzqwjsldbspjkwn0cfl8rp3-emacs-25.3/bin/.emacs-25.3-real' works

<OriansJ>also htop is rather handy for killing processes

<brendyn>I wonder if there is a way to make the process name simply emacs?

<OriansJ>ln -s ~/bin/emacs ...

<brendyn>I mean in Guix

<OriansJ>guix package -i emacs , did it just fine as far as I could tell

<bavier>ugh, subversion tests always take so long

<OriansJ>bavier: I've come to the belief that long running tests for software are simply the result of bad engineering decisions that need to be corrected.

<bavier>OrangeShark: in this case, I think they could be fixed, yes

<bavier>e.g. I see the process stalling on IO too much

<OriansJ>bavier: do you have an SSD?

<bavier>spinning disk

<OriansJ>archive drive?

<htgoebel>ng0: My distribution does not provide a gst-plugins-good-1.0.pc file anywhere.

<bavier>ACTION afk

<ng0>htgoebel: hm

<ng0>htgoebel: debian?

<ng0>and gstreamer-plugins-good-1.0.pc ? this is being checked for

<htgoebel>ngo: No, mageia

<ng0>I'm working on using the recommended env variables

<ng0>ok

<cehteh>puh .. so after some months, my guixfarm is up again on new hardware :D

<efraim>cehteh: yay!

<efraim>Subversion tests are really slow on SD cards, and I'm pretty sure all python tests are single threaded

<cehteh>still (2 months behind) guix pull is slow

<efraim>Except for building python 3.6 or 2.7.14 itself

<cehteh>16 core, 16GB mem

<cehteh>well i try a upgrade now to see whats fixed meanwhile

<efraim>4xA53, 2GB RAM

<cehteh>that hurts :D

<efraim>Tar's test suite has timed out for me before

<cehteh>long time ago i suggested that we should add some option to skip tests on packages, sometimes its really not bearable

<efraim>'Make an 8 GB sparse file and destroy it' took too long on my SD card

<cehteh>option as in per user, and maybe tag the generated binary package as 'untested'

<cehteh>one doesnt want to serve untested to the world, but for locally build --fallback and private packages it should be a choice for the user to prefer speed over safety

<TeMPOraL>hi there; I'm testing Guix/GuixSD for the first time, and installing _everything_ takes hours; could anyone help me figure out what am I doing wrong?

<TeMPOraL>sorry, s/everything/anything/, e.g. "guix package -i htop" is downloading and installing stuff for the past hour, pausing in between each download for a minute or more

<ng0>Guix or GuixSD? There is a difference, but you could be lacking the binary substitutes for the package receipes you have locally as 0.13 is old (a new release is due), so if you already have guix running you should issue 'guix pull'

<mb[m]1>TeMPOraL: are you within the live USB environment?

<TeMPOraL>ng0: GuixSD

<TeMPOraL>mb[m]1: no, I installed GuixSD on a spare computer, but the same thing happened during installation; it took ~8 hours to finish

<ng0>htgoebel: I found an official explanation for my problem

<TeMPOraL>the biggest pauses are on "Downloading https://mirror.hydra.gnu.org/....."; it hangs on it for a minute or more, and after that it does the next step (actual installation?) in few seconds, and hangs again on the next "Downloading...." message

<ng0>a good while back gstreamer used to include .pc files for some complicated mix of it, so they dropped it recently

<ng0>gstreamer-plugins-* that is. I think I need to tell gnonlin about this

<ng0>one should assume internal communication works better, but sometimes it doesn't.

<mb[m]1>TeMPOraL: Did you run `guix pull` after installation?

<rekado_>TeMPOraL: is it compiling things from source or just downloading stuff?

<TeMPOraL>yup, took few hours

<TeMPOraL>downloading

<rekado_>no compilation in between?

<rekado_>what’s your bandwidth?

<TeMPOraL>LTE hotspot now, ~40MBPS download before

<lfam>cehteh: I think it's an interesting idea to make test suites a separate derivation: https://github.com/NixOS/nixpkgs/issues/26400

<rekado_>lfam: that would be lovely!

<lfam>cehteh: But, it's not so simple, IMO. The effect would be that every package with a test suite would have two different "final" derivations, because we can't be sure the tests don't effect the result of the build

<lfam>Idk, maybe I'm overthinking it. We've been bitten hard by failing test suites for core packages in the past

<cehteh>that could be checked/challenged, but having 2 final derivations would be fine, if not even intended, just keep the non.tested one private

<jlicht>lfam: you could keep the untested one private

<lfam>Would one expect substitutes for the untested package?

<jlicht>oh, cehteh was faster :-)

<rekado_>jlicht: that wouldn’t help much, because users would still need to run the test suite when building a “public” package.

<cehteh>i am only thinking about "hey i want to install package foobar here and now, and that fast, either give me a binary from the build server or build locally ASAP w/o lengthy tests"

<rekado_>but the idea of having separate targets that are to be built only by people with time / build farms / special interests is worth exploring, in my opinion.

<rekado_>for example, janneke came up with a diverse double compilation test

<jlicht>rekado_: I didn't think of that...

<rekado_>we wouldn’t force each GCC compilation to go through this, but it’s a package that could be built on powerful hardware as a sanity check.

<cehteh>some 'net of trust' with anyone can contribute a build farm and some trust/voting system about propagating binaries would be nice eventually, but i guess the project doesnt have the developer resources now to put that on priority, maybe someday

<rekado_>cehteh: we already have “guix challenge” and “guix publish”

<rekado_>users can share their store via “guix publish” and other people can download packages from them, or simply compare results with “guix challenge”

<cehteh>yes, i meant in an automated way, that needs more infrastructure

<lfam>cehteh: The issue would be that anything depending on that "no tests" package would have a different dependency graph, meaning you'd compile the whole thing

<lfam>So I think that, in practice, it would usually be slower

<cehteh>even if i publish my farm, no one going to use it unless he explicitly adds trust and my host

<lfam>The Nix suggestion was not really about speed but reliability

<bavier>many packages don't have tests that can easily be run against already-installed artifacts

<rekado_>lfam: not if we were to default to building the “no tests” package

<lfam>rekado_: Right, but then we'd basically double our list of builds :)

<rekado_>the build farm would build the “no tests” variant first, then “continue” the build by just running the tests on it.

<bavier>oh, but if the tested packages for a separated package graph, that wouldn't be an issue I guess

<rekado_>the “with tests” variant is a continuation, not a completely separate build.

<lfam>Right

<cehteh>lfam: just keep the untested things private .. i mean really private, nothing published should depend on it

<rekado_>what’s not so great about this is that more builds would succeed

<lfam>I have to go AFK, sorry to say!

<bavier>hmm

<rekado_>we’d have to monitor the list of “with tests” variants that fail.

<rekado_>build continuations are also relevant for grafts.

<jlicht>rekado_: is that a problem? Could we not just tag these builds as being "private", and not count them for these purposes?

<rekado_>what I mean is that we would attempt to build more things, even though the “with tests” variant of one of the dependencies had failed.

<cehteh>build package, run tests, if successful build package again, check that we got the same package twice, the first package might be installed locally, but never ever published, and taint any package which depend on it as private as well

<rekado_>I guess we could deny users the download for packages like this, but it’s something that has to be thought through.

<cehteh>the 'with test' variant should still be the norm, the 'without-test' is the exception

<rekado_>cehteh: this would make each build more expensive.

<rekado_>or do you mean we build twice out of band?

<rekado_>that would be the same as having two separate derivations.

<cehteh>rekado_: no .. only the packagein step

<cehteh>make; 'generate guix package (thats essentially a make install)'; if make test; then generate guix package again;

<cehteh>first package is tainted as 'private' if thats somehow possible

<bavier>a "testing continuation" could invalidate the "build continuation" if it fails

<cehteh>if the second one results in the same package, then this taint is revovked

<cehteh>mmh can we have 2 stores? one private store and one public store? .. would be nice when one could *just publish* a public store while maintaining a private store with own packages maybe even package things which wherent meant to be packaged before, like things which contain private key stuff (CA's etc)

<cehteh>just needs to be damn sure that this never ever can leak out

<jlicht>cehteh: See https://github.com/NixOS/nix/issues/8 for a discussion the Nix devs had about keeping private information in the store

<cehteh>i'd feel a bit anxious about having a single store with private things as well, having separate stores would allow reasonable dumb publishing and make it easier to write backends for that (gnunet, ipfs, torrent, ...)

<lfam>Okay, I'm back after all. This issue of separating the tests is more complicated than it sounds at first :)

<cehteh>ideally one should be able just to serve the store without worries

<rekado_>you can’t have anything private in the store.

<cehteh>yes

<cehteh>but if we could have a /gnu/store and a /gnu/store_pivate then this becomes feasible

<cehteh>+r

<lfam>Rather than try to bend the store into a mechanism for storing sensitive data, I think it would be good to research how people who are deploying many servers do it. Presumably there are some good ideas that we haven't heard of yet ;)

<cehteh>and if packages/derivations are private or public doesnt affect their hash, just the place where they are stored defines it

<lfam>Like, how do people deploy servers automatically along with sensitive data without exposing it unnecessarily. I'm sure many people have been trying to invent a solution since the rise of "devops"

<cehteh>those tend to make things more complicated .. see ACL's on store

<cehteh>eventually you need that when you want to deploy things site wide w/o exposing it elsewhere

<ng0>yep. lfam: for example the system of A/I, and how they switched from the deployment they described in the original Orangebook to where they are now

<lfam>One could say the same thing about functional packaging. It's more complicated than old-school mutable packaging, but it enables a much simpler workflow and way of reasoning about what's installed and how it's built

<lfam>cehteh: I didn't know people were using ACLs on the store. Has anyone published anything about it?

<lfam>ng0: What's A/I? I'm having troubling finding relevant search results along with "orangebook"

<ng0> https://www.autistici.org/who/rplan/how

<lfam>Aha!

<lfam>I've also heard about this thing "vault", which seems to address this use case: https://github.com/hashicorp/vault

<ng0>the current document is outdated, but still interesting. I've asked them a couple of years ago about their current system

<lfam>...but I haven't looked into it

<ng0>large parts still apply iirc

<lfam>Going off-topic slightly... it's too bad we still have to live with Unix filesystem permissions as the basic security model.

<cehteh>lfam: i am hypothezing

<lfam>Ah, cool :)

<ng0>oh, who they are: http://networkcultures.org/blog/publication/kaos-ten-years-of-hacking-and-media-activism/ this was created a couple of years back, they exist now longer than 10 years

<ng0>it's now using issu? urgh. I got the book just like this. hm

<ng0>ah, still accessible

<lfam>Anyways, having a better method for distributing secrets with GuixSD would be awesome

<ng0>from what I know my potential goals are introducing GuixSD as a second choice OS to IN-Berlin Vservers and eventually introduce it to the collective A/I to maybe improve some parts of the infrastructure if it fits their usecase (from my outside view it does). At least A/I would be an application of this which is very often under attack and gets regular stress-testing of their infrastructure for free.

<ng0>*from what I want (of the many tasks)

<mb[m]1>Having Vault in Guix would be great. Probably only requires a few hundred Go deps :)

<ng0>Go for it. (hur hur hur)

<lfam>Yeah... someone should write a Go importer ;)

<efraim>Go for it!

<lfam>Go in Guix still needs a bit of work

<efraim>Yay ADD, I read ng0's comment and then thought I came up with it independently

<lfam>I really need to find time to fix those superfluous Go compiler references. ~200 MB unecessary downloads :(

<rekado_>just arrived home after a very inspiring, caffeine and sugar fuelled three days of working on reproducible builds.

<rekado_>compared to last year bootstrapping got a lot more attention.

<rekado_>it’s still rather debian-centric, but that’s fine because changes in Debian simply affect the largest number of users.

<rekado_>any progress there is progress for everyone.

<rekado_>a short report will follow within the next few weeks

<rekado_>we had a few non-technical sessions about marketing/outreach and we’ve come up with a few projects that are not unrealistic.

<rekado_>hack time was rather short, but janneke helped me understand mes better and encouraged me to explore alternative bootstrap paths.

<efraim>I look forward to hearing more about it

<rekado_>I’m currently trying to make mes serve as Guile’s bootstrap scheme. Then we might have *unknown magic* –> mes –> (subset of) guile –> mescc –> … –> GCC

<ng0>sounds exciting

<ng0>the "unknown magic" wizzards and witches join the ranks of the eval-apply wizzards

<rekado_>with stage0 we have a way to get all the way up to Slow_Lisp — but it’s not clear if that would be sufficient to compile/interpret mes.

<efraim>looks like util-linux absorbed rfkill

<efraim>in 2.31

<OriansJ>rekado_: well, at this point yes slow_lisp has enough to write an interpreter/compiler for mes but is not itself good enough yet to run mes directly

<OriansJ>hand writing a garbage collecting and compacting lisp in assembly in a fashion that will run on every hardware platform isn't exactly an easy task.

<ng0>efraim: where did it go to? (I disconnected)

<efraim>util-linux@2.31 gained the rfkill command

<efraim>i haven't checked yet to see if it was absorbed

<OriansJ>That being said, writing a lisp in primitive lisp is just an exercise of time and patience

<ng0>oh, gained. then I didn't understand you right the first time

<OriansJ>heck, it can be done by any student. Simply rewrite Slow_lisp in slow_lisp and incrementally add the features that were missing

<rekado_>OriansJ: I suppose we could also translate mes from C to M1 and call it a day.

<OriansJ>rekado_: well that is a short term solution. janneke and I have discussed it and are willing to do it as a stopgap solution

<rekado_>ACTION nods

<OriansJ>basically stage0 is designed to solve the bootstrapping and cross platform bootstrap verification problem permanetly

<OriansJ>mescc-tools is designed to allow arbitrary hardware/software platforms to bootstrap stage0 and allow all other hardware platforms to verify each and every step in that process.

<efraim>rfkill-0.5 is from 2013, i'm going to have util-linux supersede it on core-updates

<ng0>hey.. should we adapt a --package-origin for packages build by guix, or should it remain: configure: Using Unknown package origin as package origin

<ng0>I've seen this multiple times

<ng0>I'm not sure what it would improve

<rekado_>ng0: could you explain the problem in other words? I don’t know what you mean.

<ng0>some packages have this for their autoconfigure, ocnfigure: --with-package-name= and --with-package-origin=

<ng0>some systems use --with-package-origin=SOMEURL-TO-THE-PACKAGE-SPECIFICATION-HERE

<ng0>or even just the OS name

<ng0>I haven't read into this, so I don't know why this is done

<ng0>for my current package:

<ng0>configure: Using GStreamer Editing Services source release as package name

<ng0>configure: Using Unknown package origin as package origin

<ng0>but this is not defined by the configure.ac … so nvm my rambling

<ng0>also I used the wrong build system

<ng0>long story short, there is no problem.

<quiliro>hello

<quiliro>saluton

<bavier>hi quiliro

<quiliro>mi pensis ke guix havas "kurso" pakagxo

<quiliro>bavier: how are you?

<quiliro>what are you doing with guix lately?

<quiliro>mi pensis ke guix havas "kurso"n pakagxon.

<bavier>quiliro: just playing around with guix on an aarch64 system

<quiliro>i installed mariadb but i don-t know the password of the mysql root user

<quiliro>bavier: cool...what devices use aarch64_

<quiliro>?

<bavier>quiliro: there are some nice hobby development boards lately that use aarch64, as well as some server boards

<bavier>quiliro: I'm looking at kurso's source right now

<lfam>efraim: Do we need to wait for core-updates to make that change?

<bavier>...which is written in esperanto... haha. I maybe shouldn't be surprised :)

<ng0>quiliro: in GuixSD, the mariadb is passwordless at the beginning

<ng0>in the beginning

<quiliro>ng0: thanks...will try to use openmolar now

<ng0>it's documented

<quiliro>openmolar does not allow mysql user without password

<ng0>it's documented <- I'd read the DB documentation of Guix

<quiliro>ng0: i ll check

<mb[m]1>Writing system tests is both fun and profitable.

<bavier>mb[m]1: sound like one of those books: "Write yourself some system tests for fun and profit!" :)

<mb[m]1>:)

<mb[m]1>I might just have to pick up an actual programming book one of these days.

<quiliro>ng0: only found 6.2.7.8 Database Services

<quiliro>i will just check sql

<quiliro>for changing to some other password

<taohansen>trying to get pinentry to work on Guix. anything i'm missing?

<taohansen>through an Emacs buffer for what it's worth/

<taohansen>although my understanding is all Guix users use EXWM. ;-D

<ng0>I use pinentry with a combination of bash login hackery

<mb[m]1>Tao Hansen: if it's for GPG, I have this in my `~/.gnupg/gpg-agent.conf`: `pinentry-program /home/marius/.guix-profile/bin/pinentry`

<taohansen>mb: that's what it's for, thanks. let's try that out

<taohansen>ng0: yeah i assume some .xsession hackery may be in order

<ng0>with the combination of what mb[m]1 wrote: https://git.ng0.infotropique.org/config/tree/shell/bash/functions_gpg

<ng0>and some other things whcih might or might not be in the maze that needs to be restrcutured

<mb[m]1>Ah yes, I also have `export GPG_TTY=$(tty)` in `~/.bashrc`.

<quiliro>bavier: what can you do with those devices

<quiliro>?

<quiliro>ng0: it is indeed documented. i see it now

<quiliro>in fact i could change the password

<quiliro>but openmolar was not able to create the new user

<bavier>quiliro: my personal interest in aarch64 is in the ARM-based EOMA68 computers, which are for general-purpose use

<quiliro>bavier: i think is is a great project....please send news to the mailing list about it when you can

<quiliro>gotta go

<quiliro>my internet time is up

<bavier>quiliro: thanks for stopping by!

<lfam>bavier: The EOMA68 are armv7, not aarch64, right?

<bavier>lfam: for the current board, yes, but I think plans for future boards with aarch64 are in the works

<efraim>One small thing that I haven't worked o yet is the xorg service, which uses an Intel-only package, and should be rewritten to be swapped based on archtecture

<efraim>ng0: I looked at your dot-config files and I saw your bash alias 'clear = guix environment --ad-hoc ncurses -- clear', I added 'Control-l: clear-screen' to my .inputrc and now C-l works as expected and clears the screen

<ng0>what do you mean?

<efraim>Control-l wasn't working for me to clear the screen, but after adding that to my .inputrc it would clear the screen again

<efraim>i'm not sure if it was related to setting my editing mode to 'vi'

<ng0>ah, ok

<ng0>thanks

<efraim>i'm getting net-tools-for-tests FTBFS on core-updates for aarch64

<mb[m]1>The `itstool` update broke "gtk-doc" on master.

<xelxebar>So multiplication is iterated addition, exponentiation is iterated multiplication, tetration is iterated exponentiation, etc ad infinitum. What's a good name for the operation that takes maps an operator to the next highest order in this heirarchy?

IRC channel logs

2017-11-02.log