IRC channel logs
2016-05-16.log
back to list of logs
<habs>lfam: Sorry for being late to respond here, but yes, I run guix pull with regularity. Remembering it now, I believe I got a kernel panic while I was trying to install emacs so I had to force reboot the computer, which could be a different issue than just getting disconnected. <habs>lfam: There were a few files listed for that echo, so I did a "for i in $(echo /gnu/store/*-emacs-* | tr ' ' '\\n'); do guix gc -d $i; done" but I'm still getting the same error when I try to "guix package -i emacs" <habs>Oh looks like he left, but if anyone can help me debug not being able to install emacs it would be much appreciated! Here is the error I get: http://sprunge.us/UKMT <kraji>hello. i installed guixsd today. is it possible to install telegram- <fhmgufs>kraji: telegram-messenger? Is that a free software package? <efraim>I don't believe there is a package written for it yet <fhmgufs>Anyway, I wouldn't use it, just because the server is proprietary. <fhmgufs>And I remember our "Stiftung Warentest" (German product testing foundation) to rate it as "critical" <kraji>mmh. so what would you recommend as chat application <efraim>I don't know how long the qt-base compile time is, but full qt-5 on hydra is 6-8 hours <efraim>everyone here, including my kids schools, uses whatsapp, so I side-load it on my phone regularly <fhmgufs>kraji: I dont know any good chat application, that respects your freedom and is commonly used. <kraji>the console command to clear the terminal <kraji>sorry for all the stupid questions .p <fhmgufs>Ah, I think it belongs to the ncurses package. <kraji>i-m checking the emacs interface and it seems that my system packages have some outdated packages - in red. <kraji>i try to upgrade but it says that i should do guix system reconfigure <fhmgufs>I don't know (not using GuixSD at the moment) but maybe just do what ir says? <kraji>yes. but i don't understand the procedure very well. <fhmgufs>guix system reconfigure rereads your system configuration if you changed it and applies the changes. <fhmgufs>With system packages, do you mean the ones you specified in your configuration file? <efraim>have you run `guix pull` since you installed? and as root? <fhmgufs>And you have run guix pull since you installed? <kraji>i was reading the documentation <fhmgufs>Then it will use the new package versions. <fhmgufs>Until I have a new (= old) computer which doesn't require non-free firmware <kraji>the texlive package in guixsd corresponds to the full installation of texlive? <fhmgufs>kraji: Yes, there's also texlive-minimal. <kraji>how to configure fonts? hinting, etc <efraim>sneek: later tell kraji I have font-terminus and font-dejavu installed in my profile to help with rendering <kraji>helllo. does anyone knows how to configure fonts in guixsd <sneek>Welcome back kraji, you have 1 message. <sneek>kraji, efraim says: I have font-terminus and font-dejavu installed in my profile to help with rendering <kraji>@sneek I installed dejavu but I want to configure hinting. <bon_>How does "guix import nix" work? It fails for me on all pkgs. <bon_>guix import nix ~/code/src/nixpkgs/ scheme48 <bon_>guix/import/snix.scm:215:6: Throw to key `parser-error' with args `(#<input: #{read pipe}# 11> "XML [22], unexpected EOF")'. <bon_>similar for all other packages <catonano>Ok I made a mistake. I posted the second one to guile-dev :-/ <efraim>bon_: I've never tried guix import nix, but I think we have scheme48 in guix already <bon_>efraim: scheme48 was just an example. It fails in the same way on any nix pkg. <efraim>yeah I have nothing other than the output of `guix import nix --help' <davexunit>bon_: you're better off just writing the package recipe. no importer can do all of the work for you. <davexunit>for example, with the Nix importer (when it works), you won't get an imported build script because those are written in Bash. <bavier>any way to force the daemon to always offload builds? <efraim>guix-daemon with N=0 is unlimited, maybe N=-1? <efraim>that is if N is number of simultaneous builds and not number of cores <efraim>not now since I'm with the kids, but i'll have to pick your brain later about setting up offloading <bavier>and I have yet to respond to your gsoc email. sry for the delay <bon_>davexunit: thanks, any pointers on how to write a guix package recipe from a nix one? <efraim>ah its ok, I think everyone was moving slowly with the servers down <efraim>although in the end my wife nixed the new computer, so I might have to get creative <bavier>efraim: I think for your project it shouldn't be an issue <bavier>hopefully it won't involve building much <datagrok>immediately after installing guix 0.10.0, if I run "guix package -A guix" it offers only 0.9.0. Am I doing something wrong? <davexunit>Guix cannot package the same version of itself <davexunit>its important to keep up to date by running 'guix pull' <datagrok>after running 'guix pull' successfully, 'guix --version' still reports 0.10.0. is this normal? <mthl>datagrok: it is a know problem <datagrok>mthl: ah, thanks. I should have looked in the bug database for that problem too before asking. <mthl>datagrok: Asking before looking at the bug database is not a problem. My answer was not meant as a critic. Sorry if I wasn't clear. :) <datagrok>given the existence of that bug, I would like to report a different bug I'm experiencing. What version number should i provide to the bug reporting system? <datagrok>in other words, how do I discover the version of guix I have installed after running "guix pull"? <mthl>you can report version 0.10.0 and precise that you have run ‘guix pull’. I don't know a better way. <datagrok>the error I'm seeing is "Error downloading release information through the GitHub API" upon "guix refresh." Is it expected that most guix users will need to set up GitHub API tokens? <efraim>I haven't tried, but you should only come up against the github api limit while doing `guix refresh -t github' <datagrok>efraim: -t github is included in the set of selected types when -t is unspecified, correct? if so then that's what I'm seeing. Should I not be running 'guix refresh' to keep my packages up-to-date? <alezost>datagrok: yes, as a user you never need to run "guix refresh" <efraim>yeah, its included when no updater is specified <efraim>guix refresh checks to see if there are updates, it doesn't update the packages by itself <alezost>datagrok: I think you confused it with "guix pull" <kyamashita>If someone is available to help me with a package definition, I'd appreciate it. <kyamashita>I'm trying to package Tor Browser using a definition from Nix as a reference. <datagrok>hmm. i've been under the (mistaken?) impression that 'guix pull' updates guix (the program) itself, while 'guix refresh' updates its list of available packages and versions, like 'apt-get update' <kyamashita>In the patch-binaries phase, guix says that (string-append (assoc-ref inputs [input]) "/lib") is not a string. <bavier>kyamashita: if assoc-ref returns #f for any of the inputs, string-append will complain. is that the case here? <davexunit>datagrok: no, 'guix refresh' isn't like 'apt-get update'. that's 'guix pull' <janneke>kyamashita: this looks fishy: (string-join ... '((string-append (assoc-ref inputs "gcc:lib") "/lib") <davexunit>datagrok: in guix, packages aren't binary blobs sitting on someone's server, they are source code that comes with the rest of the guix source code. <davexunit>so updating guix itself gets the latest package recipes, too. <janneke>don't you mean: (string-join (list (string-append ...) (string-append ...))) <kyamashita>janneke: I thought backquotes and (list element1 element2 ...) were equivalent. <davexunit>'guix refresh' is a developer tool for either updating package recipes in-place, automatically, or seeing what affect a package update would have on the rest of the system. <datagrok>davexunit: aha! i understand now (mostly), thank you <bavier>kyamashita: I think janneke has the right idea <bavier>kyamashita: is there a way to build torbrowser without downloading a binary? <kyamashita>bavier: Guile reports (equal? '(1 2 3) (list 1 2 3)) as true. <kyamashita>bavier: Yes, but it looks like the official tools are Ubuntu/Debian specific. <bavier>kyamashita: right, but that isn't true if there are evaluation sexps in the list <janneke>kyamashita: i don't see backquotes used, and you would also need to unescape it again, which I also do not see... <janneke>kyamashita: try: (equal? (list car cdr) '(car cdr)) <janneke>kyamashita: and then: (equal? (list car cdr) `(,car ,cdr)) <kyamashita>janneke: '(car cdr) doesn't return the car and cdr procedures. <janneke>yes, same goes for executing your: ,(string-append ...) <kyamashita>bavier: Also, even if I managed to package the tools for Guix, I don't think I have enough RAM to build and test on my machine. I only have 2GB RAM. <kyamashita>janneke: Right. I'm going to correct the definition and see if it works. Thanks to you and bavier! <bavier>yeah, I'm browsing the torbrowser build scripts for the first time now; seems like a mess <bavier>I'm just not sure about a recipe that downloads the bundle <kyamashita>bavier: That's understandable. Perhaps it should not be officially added if that is a problem? <paroneayea>content addressed storage support in guix master now??? <davexunit>bavier: this is the problem that I was anticipating <bavier>davexunit: we're already struggling with compiler binaries <davexunit>bavier: yeah, this is a pretty clear case of "no" for me. <bavier>I don't think we want to start adding recipes to download everyone's bundles <davexunit>a web browser can surely be built from source. <davexunit>bavier: right, we definitely do not want this. <ng0>kyamashita: many thanks for starting with this, this is one the huge things missing.. and I'm too much invested in debugging other things to do them :) <kyamashita>davexunit: Okay. Has anyone managed to build a Firefox-based browser on an X200 with 2GB RAM? <davexunit>and even if a beefier machine were needed, I'm not sure what your point is. <kyamashita>davexunit: I wasn't sure about how much computing power was necessary to do so. I've never had to build IceCat on this machine. <ng0>kyamashita: you need 4GB diskspace for 38.8.0 based torbrowser, ram shouldn't be a problem <davexunit>I've never built it myself, but I know other people here have built it with limited resources <ng0>8GB needed for debug+test <ng0>I also think the bundle shouldn't be officially included, the browser itself is no problem <kyamashita>davexunit: So I'll see about attempting to port the browser's build tools over. <ng0>the bundle like it currently is. torproject eyes with Nix i think, or at least some part of the trac mentions monitoring reproducible builds <ng0>bad translation sorry. "is looking into NixOS". I'm afk again <efraim>on my i686 guixsd machine I have 1GB of ram, 10GB of /tmp and 10GB of swap (and a dead power supply) <kyamashita>bavier: That would be cool if so! How does the inherit procedure work? I've seen it with regards to gcc. <bavier>kyamashita: (define tor-browser (package (inherit icecat) (name "tor-browser) ...) <bavier>kyamashita: the inherit form says to copy all fields from the named package, but override with any fields given. <efraim>the examples in python.scm are shorter and easier to grasp <kyamashita>bavier: Okay, simple enough. Would all of the modules imported in gnuzilla.scm need to be imported in tor.scm? <kyamashita>How do I inherit a package from a different file? <davexunit>kyamashita: you need to import the module that the variable belonging to that package <kraji>why is necessary root permissions to write in the .config in the home folder of a user? <davexunit>kyamashita: to dispel any sense of magic, (package (inherit foo) ...) isn't doing anything like trying to look up a package named "foo". 'foo' is simply the name of a variable whose value is a package object. <davexunit>any expression that evaluates to a package is valid for the 'inherit' field <davexunit>(package (inherit (package (name "foo") ...)) ...) <davexunit>(package (inherit (package-with-python2 some-python-package)) ...) <janneke>does that mean that gnome no longer crashes when dragging windows to different workspaces :-/ <datagrok>paroneayea: say more about CAS in guix master? I thought the package store was already a flavor of CAS? <paroneayea>datagrok: packages generally were downloaded from their actual origin, if not from hydra <cfd>Has anyone else experienced having trouble building guile? It seems to hang at the following line: UILEC ice-9/eval.go <paroneayea>this means that if a file went away from the web, and Hydra didn't have a cache of it <paroneayea>datagrok: the new CAS stuff, my understanding is, uses a mirror of tarballs by looking up their hash <paroneayea>so if the tarball goes down because maybe say sourcefrog.com disappears, it's ok, pull it down from the CAS mirror <bavier>cfd: compiling ice-9/eval.go generally does take a looong time <cfd>Is there a way to avoid building Guile without using the Substitutes. I'm using a non-default (/gnu/store) location. <datagrok>paroneayea: awesome! could it evolve into a distributed CAS, maybe use IPFS? where did you learn about this? I'd like to go read more <cfd>Alright! I'll keep on waiting and see what happens! Thanks! <davexunit>kyamashita: the same person keeps complaining about one particular bug and isn't very understanding. <efraim>can someone else try `guix build perl-uri -S --no-substitutes' and see if they get a backtrace too? <kyamashita>davexunit: I see now what you were talking about.. <bavier>efraim: no backtraces; some errors regarding gnutls module <efraim>i was getting some error about nix tarballs after it finished the cpan mirrors <lfam>efraim: I do get a backtrace with `./pre-inst-env guix build perl-uri -S --no-substitutes`, from 44877dcc6 <bavier>efraim: oh, might be the CAS code, I haven't pulled that yet <lfam>Yes, the backtrace seems to begin at uri->string <lfam>With a content addressed nix tarball URI <lfam>ImageMagick tagged a new release yesterday but they still haven't uploaded a tarball <lfam>But, there is another release between yesterday's tag and the recent bug fix. <efraim>debian-security tagged several CVEs against their version in stable <efraim>according to the screen printout in qtbase, the license is lgpl2.1, lgpl3 <lfam>efraim: I believe davexunit fixed those bugs in d663e5e600 <lfam>They continue to fix bugs that haven't received a CVE yet <davexunit>we should be quick to upgrade whenever they release a new tarball <lfam>Okay, I'm going to update to the latest tarball. They'll probably release another today, since the cut the tag last night <efraim>i'm working on qt-5.6.0 as modules atm <davexunit>lfam: there's been a release since 6.9.3-10 ? <davexunit>just making sure you weren't talking about the 7.x series <lfam>And they also tagged 6.9.4-2 <lfam>Yes, thanks for checking. I appreciate it <davexunit>which I imagine a lot of software won't support yet <davexunit>imagemagick bindings like rmagick do not, for example. <lfam>They just uploaded 6.9.4-2. Doing that instead <lfam>Oh, that's the beta release directory. Never mind <habs>lfam: Hi, sorry for being late to respond earlier <habs>lfam: But yes, I run guix pull with regularity. Remembering it now, I believe I got a kernel panic while I was trying to install emacs so I had to force reboot the computer, which could be a different issue than just getting disconnected. <habs>lfam: There were a few files listed for that echo, so I did a "for i in $(echo /gnu/store/*-emacs-* | tr ' ' '\\n'); do guix gc -d $i; done" but I'm still getting the same error when I try to "guix package -i emacs" <lfam>habs: you should send a bug report to bug-guix@gnu.org <GNUtoo-irssi>Maybe I should bugreport to parabola to add a way to configure guix-daemon <cfd>I'm having an issue compiling Guile. It reaches the following point and then errors out: GUILEC ice-9/eval.go <cfd>building of `/home/me/gnu/6z9y2gmhvzrxsrizijna4bss0ffc5f2y-guile-2.0.11.drv' timed out after 3600 seconds of silence <lfam>cfd: Check `guix build --help` for the --max-silent-time and --timeout parameters <lfam>I'm not sure you should need them, though... Is your machine not very fast? <cfd>It is pretty old. You think the timeout is just too short? I didn't know that option existed. I'll look into those. Thanks! <lfam>cfd: I think it fails because the build process is "silent" for 1 hour. <lfam>GNUtoo-irssi: I use a non-default TMPDIR but I don't chown it to anything special. The default of /tmp doesn't either. But, the individual build directories in TMPDIR are. <lfam>That is, the build directories are own by their build user <kyamashita>I don't think the plan to inherit IceCat to build the Tor Browser will work. The two source trees are too different. <kraji>hello. just to say that to configure fonts (hinting, etc) one can edit the fonts.conf file in /home/user/.config/fontconfig/fonts.conf <bavier>kyamashita: I'd assume the recipe would need some tweaking, yes <kraji>(for some reasons it needs root) <kraji>and to solve emacs and other apps problems create the .Xdefaults file <GNUtoo-irssi>kyamashita: Assuming the users don't need javascript nor any add-ons, why not disable both? <GNUtoo-irssi>kyamashita: Would blocking the tor-browser on maximum security, and disabling add-ons makes it automatically FSDG compliant? <lfam>habs: Thanks. You will get more readers there <kyamashita>GNUtoo-irssi: All of the add-ons are free software, and I don't think that they recommend nonfree software. <GNUtoo-irssi>kyamashita: if so we would have something that works, with the same network signature, and with less work from the developers <GNUtoo-irssi>ok, I didn't try, the Tor project strongly advise not to install any anyway <adfeno>There is a possibility that the add-ons repository doesn't have the *goal* to include only free software. <GNUtoo-irssi>(it could change the way the browser behanve, and hence change its network signature) <adfeno>Remember that one of the sections of the GNU FSDG talks about the repositories involved. <GNUtoo-irssi>and if you enable it, you end up making user use non-free javascript <GNUtoo-irssi>So I'd suggest to have the FSDG version of tor-browser have the security slider blocked on the maximum, and with add-ons disabled <davexunit>does compiling tor browser from source yield a different browser signature because it won't be bit identical to what tor project provides? <GNUtoo-irssi>Once we have an FSDG tor browser, we could also have a tails-like distro <GNUtoo-irssi>Currently, it's sad to have to use non-fsdg software to have annonimity <kyamashita>GNUtoo-irssi: Or we could just modify Tails build scripts. <davexunit>in GuixSD land, that would just be a special operating-system expression <GNUtoo-irssi>yes, anyway the lack of FSDG tor-browser is really problematic <lfam>You could also use the result of `guix system vm` so that it booted a bit-identical system each time <kyamashita>davexunit: If we don't use the Ubuntu/Debian build tools or a VM, it shouldn't be bit identical. <davexunit>kyamashita: right, that confirms what I thought. <davexunit>this is the point I keep trying to make when people bring up the tor browser bundle <lfam>We should make a demo of building it with Guix, and explain the advantages providing by specifying the dependency graph and build environment with our toolks <kyamashita>Also, it doesn't seem that the Tor Browser explicitly says "You should run this nonfree software". But the reproducibility won't be there if one doesn't build it using the tools they provide. <davexunit>lfam: right, but then what about NixOS users that want to build it with their tools? or another distro? <davexunit>there's a critical software freedom issue here. <davexunit>it's basically the same thing going on with Signal on Android <kyamashita>GNUtoo-irssi: I've done that personally using patchelf and LD_LIBRARY_PATH. <lfam>davexunit: Creating a Nix or Guix build recipe and publishing the git commit gives everyone the graph and content-named sources. They can build those sources with their preferred tools <GNUtoo-irssi>Can disabling the add-ons package manager, setting it to the maximum in the security slider, and removing the less secure level be done in a way that is visible with diff <davexunit>lfam: the "problem" here is that now tor browser users can be grouped by OS <davexunit>GNUtoo-irssi: you mean modifying the binary? I'm afraid that is not sufficient for inclusion in Guix. <lfam>If I use the Debian provided TBB, will I appear the same as if I use it on, say, Fedora? <davexunit>do Debian and Fedora build from source or use the pre-built bundle? <lfam>We can use Guix as a way to make the dependency graph transparent, and then work towards reproducible builds across platforms <kyamashita>lfam: Yes. But you are only anonymous if you use the officially compiled binary. <davexunit>lfam: the builds from different OSes, while they may be reproducible, will never be bit-identical across distros. <lfam>Debian uses the pre-built bundle <GNUtoo-irssi>reproducibility and the network signature are two different issues <bavier>I don't understand how the builds being slightly different might affect anonymity <GNUtoo-irssi>The annonimity depends on the network signature being the same accross different machines <davexunit>GNUtoo-irssi: I'd like to know with certainty whether Tor Project considers building TBB from source violates something they find valuable. <davexunit>if we can build it and appear the same as other users, then great. no issues here. <GNUtoo-irssi>The reproducibility between distros only increase the protection against tempering <lfam>Agreed. We should definitely work with them to do this properly <GNUtoo-irssi>I think that we should care the most about the network signature <kyamashita>davexunit: Probably not, it's just that their current official build process requires Ubuntu, Debian, or their specified VM. <GNUtoo-irssi>The rest can come later, we'd of course need to have it reproducible in guix. <bavier>I would expect our own tor-browser package to pass --rounds=... <davexunit>as long as we can build from source, with our own build tools, then there is no problem. <GNUtoo-irssi>And given that their build system requires a vm, they may even adopt guix for it later <davexunit>however, I suspect that there may be a problem. <davexunit>but I don't use TBB nor do I plan to, so someone else would have to find out. <GNUtoo-irssi>The tor browser is my main browser (The other ones are for localhost or captive portals only) <GNUtoo-irssi>And I'm not really sure I want to use it as a distro yet <bavier>GNUtoo-irssi: feel free to suggest packages <GNUtoo-irssi>bavier: I meant that guix package -i result in building stuff <davexunit>the mostly likely thing is that you are using too old of a release <kyamashita>GNUtoo-irssi: Hydra garbage collects old binaries on the server. <lfam>That's also important for receiving security updates <davexunit>its important to keep up with the master branch as best as you can while we're in beta <kyamashita>davexunit: What was the problem you suspected earlier? <GNUtoo-irssi>as a tool to build standalone applications (like the tor-browser) <lfam>habs: Okay, now we wait for some responses :) <GNUtoo-irssi>as a tool to build rootfs for embedded devices (assuming I find how to have global package configurations) <GNUtoo-irssi>as a tool to build development environment (think of old toolchains) <davexunit>kyamashita: I suspect that TBB has the same issue as Signal: building it yourself (with your own bootstrap binaries) breaks a critical feature, such as anonymity. <GNUtoo-irssi>Yocto for instance would do most of theses things, but it's not FSDG, adn it doesn't do the distro part <GNUtoo-irssi>so I cannot share builds with the distro I'd use for instance <davexunit>GNUtoo-irssi: for global packages, GuixSD has a system-wide profile in /run/current-system <kyamashita>davexunit: We'll see. I hope for more clarification from Tor Project developers. <davexunit>I keep a small list of essential stuff in my system profile <davexunit>but most things I install in my main user profile <lfam>Have we decided who will contact the Tor Project? <GNUtoo-irssi>davexunit: example of global configuration: strip binaries, remove -dbg, remove man <adfeno>I also don't use Tor Browser Bundle. I'm not too found of "extreme" security. I like to encrypt things using OpenPGP keys, but most of my contacts aren't using it. <adfeno>Actually... I don't use Tor all-together. <GNUtoo-irssi>davexunit: no need, at installation it would need to rm the man for instance <lfam>We need to get Sphinx to stop embedding timestamps in manpages <davexunit>you can modify package recipes to strip things <GNUtoo-irssi>davexunit: I get that, let's say you do guix vm-image, you produce an image from immutable packages <GNUtoo-irssi>the packages of course have to stay immutable once built, but you can produce an output that is modified from them, right? <GNUtoo-irssi>Example: immutable package -> some processing (strip, remove mans, etc) -> rootfs image <davexunit>sure, you can write additional build functions that make a copy of a store item and change some things <davexunit>usually it makes sense to change the package's build script <kyamashita>Example: Modify package definitions -> build package -> immutable and reproducible image <davexunit>but again, typically this is done in the package recipe's themselves <GNUtoo-irssi>ok, the goal would really be to produces rootfs images to be used in non-selfhosting ways <GNUtoo-irssi>Example uses cases: embedded devices (ARM) with very few storage space <GNUtoo-irssi>or even have a kernel and rootfs in less than 16M or 8M (to fit inside your BIOS's flash, along with coreboot or libreboot) <GNUtoo-irssi>Typically yocto or openWRT would be the tools to use for such things <GNUtoo-irssi>but I'd prefer to have something FSDG that is well maintained <GNUtoo-irssi>If you take libreWRT/libreCMC, it removed x86 supports and lags behind openWRT <GNUtoo-irssi>as for yocto, I'd have to free it myself, and in both cases it's not as well maintained as parabola for instance, it lags behind <GNUtoo-irssi>indeed, that's the interesting point for that use case, yocto is one too. <GNUtoo-irssi>and unlike yocto it's FSDG, seem to be well maintained, and also applies to my host machines <GNUtoo-irssi>so I could share configuration, management, packages and so on <GNUtoo-irssi>As I understand it, it's still beta and lack many packages (libvirt for instance), but that'll eventually be fixed <GNUtoo-irssi>Parabola is also very nice but has some shortcommings, namely no reproducible builds yet, no -dbg packages and so on <davexunit>I've packaged a bunch of stuff that I wanted. it's pretty easy to get started. <GNUtoo-irssi>right now with guix pull, I'd be able to try stuff much faster <GNUtoo-irssi>Since it's TV time here, my Internet connection speed is drastically reduced, but I'd be able to try making a vm soon <kraji>is there a way to decompress rar files using free software <lfam>kraji: There is a python module packaged as python-rarfile. It was a required dependency of beets, so I added it, but I can't say how well it works. <lfam>kraji: Let me know if you try it. I'm interested to know if it works or not. I wouldn't mind asking beets to remove it from their requirements <bavier>maybe we need an entropy-service for lsh :P <janneke>or an easy example for how to re-use a test key?