<epronk>janneke: /gnu/store/deadbeef1234-system/boot starts with : (eval-when (expand load eval) <sneek>epronk, janneke says: re: dumb-init(1), is your dumb-init instead of doing exec invoking guile+shepherd? <epronk>sneek: My Ubuntu kernel in lxd can't run /gnu/store/deadbeef1234-system/boot directly so I try to wrap it with a bash script. ***Piece_Maker is now known as Acou_Bass
<janneke>the pstree output suggests that your dumb-init wrapper remains to be the parent (1) and invokes shepherd instead of exec'ing it? <reepca>Well, radeon r5 230 should arrive next week, according to h-node that should work for the multiple displays. In the meantime, do we have any variables along the lines of NIX_STORE_DIR in the scheme code? <efraim>reepca: there is in the configure script and 'guix import nix', but I've never looked at that part <rekado>buenouanq: I really don’t like wikis for things like this. It’s all in the manual. If the manual is not explicit enough we should change the manual. <rekado>buenouanq: our workflow for packaging is to send email to guix-patches followed by patches. <rekado>buenouanq: a wiki will not be useful for that. <rekado>we also don’t have a github-like workflow but an email-based workflow. <buenouanq>I think there was maybe a misunderstanding in whatever I said. <rekado>so instead of pull requests you send email to guix-patches@gnu.org. That mailing list is backed by debbugs, so we also don’t need Github issues. <rekado>sneek: later tell jsierles Code review happens on guix-patches, but since it uses debbugs you don’t have to browse the mailing list manually to access past discussions. You can use the debbugs interface, which is/looks like/behaves like a regular bug tracker (except that you don’t need an account). <buenouanq>a common question people come here and ask is `is anyone packaging/working on/thinking about X?' <buenouanq>I was just thinking aloud about how answers to this might be found. <rekado>all of this depends on how and if it’s going to be used. <buenouanq>Mailing lists could work, but more would have to use it for this. <rekado>a lot of people do use guix-patches <rekado>buenouanq: but you are right that usually people do not announce well in advance what they are working on. <rekado>but I suppose that’s because packaging usually doesn’t take a lot of time. <rekado>(except for things like splitting up texlive, etc) <buenouanq>if they did or there was a place made to cultivate and record that, they might find more help is available <rekado>I’ve also asked on guix-devel whether anyone would like to take care of haskell updates. <rekado>for very large projects like that announcing makes sense, but in the past this was rather ad-hoc. <brendyn>If i want to start packaging something, I'm not going to bother writing down the fact that I'm doing so, apart from maybe mentioning it irc <rekado>reepca My GPU is just the built-in VGA chip on my X200S laptop. <rekado>reepca multiple displays do work fine for me, though I’m not using them regularly. <rekado>sneek: later tell quiliro Re mirror: Have my previous hints about how to set it up not been helpful? Is there something specific you need help with? <rekado>sneek: later tell quiliro Re python/Qt: You have to make sure that you’re using Python from Guix and that the PYTHONPATH variable only lists module paths from Guix. <brendyn>are there any instructions on how to setup ssh for guix copy? <efraim>I couldn't get it to work on my aarch64 boards so I have them both acting as substitutes for each other <reepca>it looks like what I'm looking for is %store-directory, is that right? <reepca>Now if I could just find something like that for the name of the directory I currently know as "db", that'd be great. <cbaines>reepca, what is in this "db" directory? Do you have an absolute path I can look at on my machine? <reepca>in the C++ code I believe it's called nixDBPath <reepca>it's got the sqlite database with information about what's in the store and what references what <cbaines>I haven't encoutered that yet, hopefully someone else has <rekado>reepca: I think you can override the directory with NIX_DB_DIR <ng0>"ERROR: Could not read ISO9669 primary volume descriptor from "/dev/sda1" … hur oO this system sat happily running for some time and the update reported no errors <ng0>Okay, this is expected as the nginx config contained a try on running a buildserver which I did put on halt for now <ng0>no, that's not the issue. <epronk>janneke: Does kernel run guile script /gnu/store/abcd123-system/boot directly? <janneke>epronk: hi! Err, dunno! Let's google that? <janneke>epronk: btw, is there a reason you dislike dummy-init (1) in pstree, besides the fact that it looks silly? (i guess there is...) <epronk>Using the dumb-init could work, but it just starts shepherd, but not the child processes I see in qemu. <epronk>janneke: /gnu/store/abcd123-system/boot does a bit more then just execl shepherd. <janneke>epronk: shepherd is not started in the right way/does not find its config? <janneke>(i thought that was it) does it do even more? <janneke>ACTION needs to to afk for a bit bbl <epronk>janneke: Yes, I think the env that's get passed is not identical. lxd just lacks any logging so starting is hit or mis. No logging, no console. <epronk>janneke: so I tried: /gnu/store/abcd124-guile-2.0.14/bin/guile /gnu/store/abcd123-system/boot <epronk>When I boot the guixsd-usb-install in qemu the console looks fine until it switches font. From the point on the console has redraw issues. <thomasd>On GuixSD, I seem to have broken my guix installation... I get a ton of warnings about “loading compiled file ${HOME}/.config/guix/latest/... failed”, and guix pull fails with “error: libtiff-CVE-2017-7593.patch: patch not found”. What's a strategy to fix this? <epronk>janneke: yes. The point where it starts fbcon it all goes snowy. I'll try nofb as param in grub <janneke>Hmm, does qemu say: press `ESC' for boot menu? <janneke>yeah, it's ESC with my qemu, not F12 <janneke>epronk: yeah, i know what--but it all scrolls so fast...or do you enter fbcon manually? <epronk>janneke: no, was just trying to read during bootup what the last thing is I can read read before the screen goes bzr. <catonano>thomasd: point .config/guix/latest to a fresh checked out (and freshhely buiilt) branch <thomasd>catonano: yes, I'm doing that right now <catonano>tis will run guiix pull from within the checked out branch, thhat's supposed to be sane <thomasd>initially I panicked a little, because not even the checked out branch would run (due to my having run guix gc beofre :) ) <thomasd>luckily, I could adapt the #!/.../guile shebang in scripts/guix to point to a guile version that was still installed <janneke>epronk: scrolled back, i don't see a reference to `fbcon'...how weird <janneke>when is that in the boot process, any pointers? <thomasd>though I wonder how I ended up with the broken guix in the first place, and if it could've been fixed without a working checkout... <rekado>if we switch to using a profile instead of a single “latest” link it should be very easy to recover. <thomasd>I still have it in the store, willing to do forensics :) <janneke>epronk: i'm using qemu-2.9.0 -- do you use -enable-kvm and do you have rw permissions for /dev/kvm ? <thomasd>could it be related to the fact that I have guile-2.2 in my profile, but the old guix was still on guile-2.0? I get errors like “not an ELF file” or “Invalid or incomplete multibyte or wide character” <catonano>I even opened a tread on the mailing list <epronk>janneke: just after ssh-daemon has been started. waiting for udevd... <thomasd>catonano: yes, that looks like exactly the situation i'm in <thomasd>strange. but the problem should disappear once we've completely switched to guile-2.2 <epronk>janneke: FDC, cirrusfb and then *zap* <epronk>janneke: I filmed it with my phone. I learned that from testers. <janneke>ACTION was going...how /does/ epronk catch that? <janneke>epronk: here's what i'm doing: qemu-system-x86_64 -net user,hostfwd=tcp::2233-:22 -net nic,model=virtio -enable-kvm -m 1G -boot menu=on -drive file=guixsd.img -drive file=guixsd-usb-install-0.13.0.x86_64-linux <epronk>janneke: the default is that cirrusfb <catonano>now I'm gonna listen to the Sussman's talk about generic operations :-) <janneke>epronk: guess that became the default in 2.2? <epronk>janneke: 2.0.0; Ubuntu 14.04.5 LTS (sorry) <janneke>epronk: no need to `sorry' -- it would be good to add a note to the documentation about -vga std and qemu < 2.2 <janneke>or at least send a mail to guix-devel@gnu.org for others to find <brendyn>Anyone thought of building a Guix version of Replicant? <ng0>though i don't know bionic, so I'll be silent <Sleep_Walker>1] Replicant is using another libc - bionic which we don't have <brendyn>I wonder though, how would we organise something like Replicant in the Guix git repo? <Sleep_Walker>2] if you'd want some phone with vendor binaries, you need some glue via libhybris - not something one would like to do with FSF endorsed distro <brendyn>Would we just chuck all the android packages together in gnu/packages/? <Sleep_Walker>all in all - it's huge amount of work and not a bit related to Guix for long time <Sleep_Walker>package management for such android could be doable in the end :) <brendyn>I just find it interesting to think about how it would be done in theory <ng0>think about theory long enough and you end up doing it because no one is doing it :) <brendyn>I also wonder, how will we organise different GuixSD spins, like Scientific Guix? Currently we just have a couple example configs <ng0>in their own projects <ng0>the amount of developers in Guix can't handle ALL of it. eventually you will have projects which track and work together with GuixSD (like I do, though nothing of downloadable nature is there yet) or fork GuixSD for some reason.. the repetive circle of operating systems <rekado>brendyn: Scientific Guix is called just Guix :) <Sleep_Walker>brendyn: I'd like to see Android interface on top of Linux ecosystem as well <ng0>if you're good, it can be done with just upstreaming everything, keeping changes in a GUIX_PACKAGE_PATH repo and write config.scm's for systems and altering what generates disk-image… and some more. <rekado>Sleep_Walker: do you mean Android on GNU? <brendyn>I think it would be fun to use guix tools to launch qemu vms of android <rekado>glibc is not Linux, it’s the GNUest of them all :) <jsierles>if i want to trigger guix builds remotely, can I call the daemon directly via rpc or should i wrap the command line client? <sneek>Welcome back jsierles, you have 1 message. <sneek>jsierles, rekado says: Code review happens on guix-patches, but since it uses debbugs you don’t have to browse the mailing list manually to access past discussions. You can use the debbugs interface, which is/looks like/behaves like a regular bug tracker (except that you don’t need an account). <jsierles>ideally I could just point 'guix', running in a docker container, to a remote daemon. <rekado>jsierles: an intermediate step is to use Guix as a library <rekado>jsierles: remote daemons work already. You can use SSH to connect to a remote daemon. <rekado>before that feature was implemented by Ludo we would use socat to forward the domain socket over TCP <jsierles>didn't see anything in the manual about that. <rekado>the index item “SSH access to build daemons” explains it <jsierles>ok. can i specify an ssh key location for the client? <rekado>jsierles: with .ssh/config probably <rekado>…deviate from the Texlive directory layout <jsierles>guess there isn't much difference between that and running the 'guix' command line over ssh <rekado>jsierles: if you run guix locally you can use local modules <rekado>it just connects to the daemon remotely <rekado>if you run guix itself over ssh, you can only use modules that are available on the remote <jsierles>hmm. then could i share the store read-only to clients? <jsierles>so /gnu/store would be the same for all clients, and GUIX_PACKAGE_PATH could be different. <jsierles>but all builds would happen on the remote daemon <rekado>(or wherever the daemon offloads work to) <jsierles>nice one. so could I build a docker image using guix to provide the guix tool? <jsierles>alright. just wondering if that's better than using something line alpine. <jsierles>the goal there is just to have a minimal container to run that can trigger a build from anywhere in our cluster (docker based) <rekado>because no Guix software will use the libc from alpine <rekado>or any other library for that matter. <jsierles>yeah. i just found an old image on alpine <rekado>so you’re just carrying binary cruft <jsierles>ideally i can use guix to build two docker images. one for running the daemon and another for the client. <jsierles>i know it might be better to run GuixSD. but that seems like it would be some work to do on google compute engine. <jsierles>now we run coreos which uses docker to run everything. <rekado>jsierles: I think you just need to use “guix pack -f docker guix” and it will give you the image for the daemon and the client. <jsierles>has anyone installed guixsd on GCE or aws? <rekado>I have not, but I read of attempts to run GuixSD on some virtual server hosters. <civodul>rekado: though "-f docker" doesn't support --localstatedir, i think <jsierles>shouldn't it be OK to mount those directories from the host? <jsierles>i wouldn't keep such state inside the container. <civodul>jsierles: IOW, it would give you a Guix that you cannot really use to install software <jsierles>civodul: i see. no way to generate the local state database after packing the software? for example when it runs for the first time. <Sleep_Walker>rekado: yes, Android packaged as GUI, with linux distro bellow, Android apps support, etc. <rekado>Sleep_Walker: I find the term “linux distro” really hard to accept :) <civodul>jsierles: we should just fix 'guix pack -f docker --localstatedir' :-) <jsierles>civodul: i see. maybe i don't understand. do all clients need their own local state dir, or just the daemon? <rekado>Sleep_Walker: for some time now I’ve shifted to just calling the system “GNU”. <rekado>Sleep_Walker: isn’t that what an Android emulator would do? <jsierles>and if i were to share a store across servers, would i also be sharing local state dir? <rekado>jsierles: here at the institute we have a cluster with hundreds of nodes. All of them mount the same store over NFS (read-only). <civodul>jsierles: sorry i didn't follow the beginning of the discussion, so i wouldn't want to say stupid things <Sleep_Walker>rekado: I don't know. Can you make a call with Android emulator? <rekado>jsierles: the localstatedir is for the daemon to store, well, local state. <jsierles>rekado: right. so just /gnu/store is mounted. /var is only important for the daemon. <rekado>Sleep_Walker: I don’t know anything about Android. I think that wouldn’t work. <rekado>jsierles: a part of /var/guix is also needed by the client <rekado>jsierles: that’s where profile links are stored <rekado>jsierles: so in our setup here I export /var/guix/profiles as a writeable share. <jsierles>rekado: I see. so your clients mount /gnu/store read-only, and /var/guix/profiles as writeable. <rekado>jsierles: without write access you can still use “guix build” and “guix environment”, but you cannot use “guix package” <rekado>in your case you might not need it if all you do is run “guix pack” <jsierles>ah, the writeable database. i would still need /gnu/store and any other local modules mounted read-only. <rekado>jsierles: your clients might not need write access to /var/guix/profiles <jsierles>so for now, I can use alpine to run the daemon. <rekado>the database should not be writeable except for the daemo <jsierles>this will move the local state dir into /var at build time. so this image will include that dir <jsierles>so maybe I can initialize /var/guix once on my server. then mount the 'inert' image but with /var/guix mounted into it. <civodul>jsierles: the problem is that you'd be mounting the "wrong" database <civodul>that is, /var/guix/db/db.sqlite would not correspond to the actual /gnu/store <jsierles>civodul: if they are both initialized at the same time, why would it be an issue? <jsierles>for example, if i copy the distribution var/guix to a mounted volume, and then run 'guix pull'. <civodul>jsierles: if you're sure that they match, that's fine <jsierles>civodul: guess i'm not clear on how they match <jsierles>it looks like the database is distributed with the store. then, you use 'guix pull' to update the store. that also updates the database. i'd guess if i lose the database, it's bad <rekado>jsierles: whenever the store is modified (by the daemon) the database gets an update. <rekado>jsierles: you should not modify the store manually, nor should the database be changed. <rekado>it’s important that the two stay in sync <jsierles>ok. but guix comes with a pre-populated database right? <jsierles>what happens to it when you 'guix pull'? <rekado>interesting comment in the LaTeX docs under the section “Build Hints”: “The most important advice I can give: ‘Forget it’!” <epronk>janneke: trying a different approach, mounting the usb-install image via loopback and add Ubuntu kernel, so I can try booting in qemu. <rekado>jsierles: what the database initially contains (if anything) depends on how you install Guix. <rekado>jsierles: one installation method is to unpack a pre-populated store; that contains a matching db. <ng0>rekado: such encouragment \\o/ <ng0>Texinfo - Abandon hope all ye who enter here <jsierles>are there security concerns allowing users to issue remote builds? in other words, could they do anything destructive with a read-only store? or just clog up the build server (for example) <rekado>jsierles: I think the only thing they can do is denial of service by flooding the daemon with requests. <jsierles>rekado: since the result of 'guix pack' is written to the store, it should be available on the client then. and the client could do something with it, like push a docker image to a registry <epronk>janneke: vga -std does work. I'm just lazy and don't want to do an install. I want to replace libre kernel with ubuntu kernel and see how it breaks. <janneke>*is a lot of trouble esp. if it can be avoided <epronk>janneke: install in qemu needs qemu bridge network because installer wants to download additional stuff. <rekado>epronk: if all you want is replace the kernel package why don’t you use Guix for that? <janneke>epronk: you don't need bridge, i don't think so <janneke>the qemu curses as shown in the manual should suffice [note: ping won't work] <epronk>janneke: I'll have another try to get that working. <ng0>git-predicate is strange. when I add this to the guix-env.scm I have in gnunet it just sits there doing nothing at all. <ng0> #:select? (git-predicate %source-dir))) where %source-dir has been defined before <mbakke>re: android: IIRC android (bionic?) does not support RUNPATH, so Guix on phones (let's make this happen!) would have to run "below" android :-) <mbakke>I wonder why locales are not set up for my user on this newly-provisioned machine <mbakke>as a side note, qemu and tmux behaves very strangely when no LANG or LC_ is set <rekado>ha, I just built texlive-latex-base <rekado>next step is to test it by building a simple texlive package that depends on latex <rekado>this really works! I just built the amsmath package with latex-base. <rekado>time to write a texlive-build-system to keep the definitions simple. <Apteryx>Is it me or emacs-guix doesn't know about packages defined in GUIX_PACKAGE_PATH? <Apteryx>rekado: Thanks for the texlive effort! It'll be a huge improvement over the 4 GiB archive download ;) <Apteryx>I have a 'emacs.scm' package under ~/src/my-guix-packages which defines "emacs-matrix-client", the GUIX_PACKAGE_PATH is set to ~/src/my-guix-packages; yet when doing M-x guix b "emacs-matrix-client" it doesn't know about it. <Apteryx>Maybe the system emacs.scm is shadowing the GUIX_PACKAGE_PATH completely... although this behaviour would be different than when using Guix UI. <Apteryx>("guix build emacs-matrix-client" works just fine from the cli) <civodul>CharlieBrown: you need to make sure 'nix-instantiate' is in $PATH <civodul>Apteryx: maybe GUIX_PACKAGE_PATH is not defined in the environment of emacs itself? <Apteryx>civodul: I tried M-x getenv and it GUIX_PACKAGE_PATH points to the right location... hmm. I'll restart emacs to make sure. <Apteryx>civodul: OK, after renaming my module to my-emacs.scm *and* restarting Emacs, it works. <Apteryx>civodul: Do you sometimes use same module names (such as emacs.scm) to hold extra emacs packages? <civodul>the name in 'define-module' and the file name must match <civodul>emacs.scm is the file name, not the module name :-) <civodul>but for my own modules i use a different name space <Apteryx>OK. So my module name was simply (emacs) then. <Apteryx>civodul: Hmm. I've renamed to 'emacs.scm' and (define-module (emacs) ...), restarted Emacs, and guix-emacs still finds it. Not how I got to my original problem in the first place. Sorry for the noise :) <Apteryx>Looks like "restarting Emacs" was the cure. <lfam>CharlieBrown: It's from Nix. Is Nix installed? <lfam>Well, you are trying to use a Nix program (nix-instantiate). So, it's a reasonable question <CharlieBrown>No, I don't. But if I had Nix installed, I would give up on packaging this, because I don't care how the program runs. I just want it installed. <lfam>In many cases, the Nix importer will not offer a finished Guix package anyways. It can only do the basics. <Apteryx>civodul: Oh, looks like if the definition of a package is new (fresh written), guix-emacs won't find it. That's when I must restart Emacs. <civodul>CharlieBrown: if you don't have Nix installed, then "guix import nix" is probably not what you want, is it? <civodul>it might be just as productive to do the packaging work directly <Apteryx>Or maybe I had to compile it before... I had the "no code for module (emacs)" error before I did C-c C-k to build the module with Geiser. <CharlieBrown>Also, it's ugly that I have to write inputs twice as both a string and a quoted atom, when in Nix you just type it once. <Apteryx>guix downlod "git-url" always give me a different hash than when I build the package :/ <lfam>civodul, mbakke: What's the status of core-updates? Is it frozen? <civodul>lfam: kinda, although i just pushed changes :-) <civodul>i think i'm waiting for staging to be merged <civodul>yesterday i started an eval of core-updates but it was canceled <lfam>I sat out this staging cycle, so I don't know :) <civodul>mbakke said it's pretty much ready though <lfam>Right, there were some scattered failures IIRC <lfam>I asked about core-updates because I'm wondering if we can switch to the Artifex Ghostscript in this cycle or wait for the next cycle <civodul>because it's a safe change and we haven't built anything this far <lfam>Well, we'd be going from Ghostscript 9.14.0 to 9.21.0, so it might not be "safe" <lfam>Although I wonder how many features of Ghostscript are actually used by the main users, groff, curl, and cairo <civodul>i think it's just about processing good old PostScript <civodul>and the PS standard is almost immutable nowadays, i think <lfam>Okay, you convinced me :) I'll prepare patches to switch over completely <civodul>you actually posted some already no? <lfam>They were an intermediate that added a new package artifex-ghostscript. I built groff, curl, and cairo against this new package. <civodul>it would have been ideal to get an official statement from Didier Link <civodul>at the GNU level we should probably officially give up on GNU Ghostscript <civodul>but of course discussing this may be tedious :-) <azazel>gnu ghostscript has been around for ages... <lfam>I started this work after reviewing the discussion with Didier from late 2016. He said he would merge the security patches that Mark ported, but that didn't happen. <civodul>so in practice it's pretty much abandoned <civodul>all i'm saying is that it's a bit sad that we're not able to address such issues at the GNU level <lfam>Time to enjoy a glass of that fine wine you have nearby :) <alezost>Apteryx: you don't need to restart Emacs: just the *Guix REPL*, then after it will be restarted (when you do "M-x guix-generations" or any other command), it will read all the packages again, including the new ones you added <ng0>I'm updating neomutt now. I just couldn't be bothered to do it earlier. <ng0>Or is someone else doing it already? ***Introoter is now known as covfefe_the_grea
<ryanwatkins>Hey guys, how do I find the .xinitrc that is created by cons'ing wm's in the guix system config? <civodul>ryanwatkins: there's no .xinitrc created <civodul>only the WM provide .desktop files, and those are looked up by the login manager (SLiM) <civodul>the .desktop files are in /run/current-system/profile/share/applications <ryanwatkins>civodul: ahh, but then how could one do some-wm > some.log ? <bavier`>CharlieBrown: yes, you just need to make sure the "unzip" package is in native-inputs <civodul>ryanwatkins: good question, you can't really do that <civodul>you could watch the output on tty7 maybe <CharlieBrown>civodul: In my local dialect, "hey people" is rude and "hey guys" is gender-neutral. <ryanwatkins>civodul: I think it is /run/current-system/profile/share/xsessions <bavier`>CharlieBrown: dino looks like a nice program <SovereignBleak>So I'm *just* getting my feet wet with Guix after building a minimum system some time ago (finally!) and in my quest for sourcing the nonfree firmware my computer needs I stumbled upon this person's config.scm that looks awfully like he wrote a bunch of Scheme that replaces the Linux-libre kernel with mainline and pulls in the Iwlwifi for Intel cards: <SovereignBleak>Is that reality? I haven't yet learned enough Scheme to know for sure by looking at it. <bavier`>SovereignBleak: indeed, that's what's happening ***covfefe_the_grea is now known as Introoter
<CharlieBrown>What the... I did that one-liner to install Nix. Now, I can't do nix-env -i dino. :-( <sneek>Welcome back bms_, you have 1 message. <sneek>bms_, OriansJ says: that I am looking forward to his next update on Coquillage <bms_>Hello. Sorry about my disappearance. I haven't given up. <janneke>i made a bit of progress towards compiling tcc.c <gazon>hi #quix o/ -- is ftp://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.13.0.x86_64-linux.xz intended to assist with installing guixsd in a vm? if so, how is is supposed to be used? similarly to the usb image, but connected to the vm as a disk? <janneke>and had quite some nice chats with OriansJ <janneke>next up now is to change my lambda-based .o format into OriansJ' hex2 <lfam>gazon: It's not for installing GuixSD in a VM, but instead for running GuixSD in a VM. It's a regular GuixSD operating system image, not an installer. <gazon>i see, so might one use it as a backing store to a copy-on-write disk? <janneke>bms_: not sure if i had the chance to tell you...when i started my scheme interpreter in C i was thinking of it as a prototype that would have to be redone in assembly, once i got it working and small enough <bms_>I don't think we've actually ever talked. <thomassgn>If I remove the package names listed it reconfigures my system as expected, but I would prefer to have at least my default terminal in there <bavier`>thomassgn: the package variable is named "isc-bind" so as not to conflict with the 'bind' procedure in guile <janneke>bms_: you mentioned writing a scheme interpreter in assembly? <rekado>what license are these TeX metafont fonts? <rekado>they have this borderline non-free license statement <rekado>saying that you may not change them unless you rename them. <Gamayun>rekado: I vaguely recall some hubbub about those ... <janneke>probably out of respect for DK that all the software didn't get renamed instantly ;-) <Gamayun>LPPL / GUST as far as I can figure out..? <Gamayun>"The reason this requirement is acceptable for LaTeX is that TeX has a facility to allow you to map file names, to specify “use file bar when file foo is requested”. With this facility, the requirement is merely annoying; without the facility, the same requirement would be a serious obstacle, and we would have to conclude it makes the program nonfree." <slyfox>when guix unpacks tarball which timestamp does it chose to force on unpacked files? '0'? <thomassgn>bavier`: aha. I think you just taught me a bit about guile error messages. (: Thanks