***zxz_ is now known as zxz
<mekeor>why don't we put each package definition in its own source file? <reepca-laptop>Hm, I can't seem to find the INSTALL mentioned in the online manual (2.2) in most recent git. <brendyn>That's odd. My local repo still has it <brendyn>reepca-laptop: It's in the .gitignore. I think it may be obsolete <reepca-laptop>Hm, well the manual says to refer to it for information about building, and says that the build process is the same as for other GNU software, but I can't find a ./configure <brendyn>reepca-laptop: Well I can help you with that. The manual hasn't been updated much in the last year I think <brendyn>reepca-laptop: I run ./bootstrap first <reepca-laptop>complains about "possible undefined macro: GUILE_MODULE_AVAILABLE" <brendyn>Before that, I run guix environment guix <Apteryx>OriansJ: Interesting; although I can't say I understood all that I read ;) <brendyn>Afterwards, you can use that version of guix to setup an environment to build the latest git version <brendyn>reepca-laptop: Can you explain how you are trying to install Guix? On what distro? <reepca-laptop>Lubuntu 32-bit 16.04, recently trying to install from git, downloading tarball now. <Apteryx>rekado: Is it me or most of the patch never apply? I'm experimenting with 'M-x cd ~/src/guix-review', followed by | git am in Gnus on emacs patches, and it doesn't work so far (patches fail to apply). <Apteryx>I guess for files which change often and where people add stuff at the end (emacs.scm), it might trigger this scenario (merge problems) ? ***j-r is now known as james-richardson
***james-richardson is now known as j-r
<j-r>emacs packages? Guess the best plan would be to package the ones I use from melpa and send in a patch to the list so it becomes an actual guix emacs package... <j-r>I can ask a similar question for perl, but then to package perl things, I'll probably have learn about inputs vs propagated-inputs vs native-inputs. <brendyn>j-r: native-inputs are programs that need to in the buid environment, but not installed with the package, like autotools, gcc, etc <brendyn>inputs j-r inputs are including with a package and are refered to by an absolute path. like lua might be included as an input, and use by a program by pointing to /gnu/store/…lua.…/bin/lua, but installing that program will not put lua in your PATH <brendyn>I think the manual explains it better than me anyway <j-r>I see the descriptions in the manual. I'll just build a package using each and see what happens. <Apteryx>CharlieBrown: the file containing the emacs package definitions <Apteryx>It's located at guix/gnu/packages/emacs.scm <brendyn>My install failed after 50 hours of building packages. It seems that it built some dependencies which were not reproducible, and so now nothing can use substitues anymore as all the hashes are different <reepca-laptop>Doesn't seem to be possible to get package "hello" from hydra (404) <rekado>reepca-laptop: it’s normal that GNU software does not have a configure script when you build it from a source checkout. <rekado>reepca-laptop: the configure script is only included in release tarballs, because it is generated code. <rekado>reepca-laptop: so the manual is still right <rekado>reepca-laptop: if you want to build from source, you need to first generate the configure script by bootstrapping with autotools <rekado>Apteryx: depends on the files the patch touches. Rebased patches usually apply just fine for me. <rekado>brendyn: the manual should be up-to-date and it is constantly updated. The last change I see is from May 1. ***cal is now known as CharlieBrown
<reepca-laptop>rekado: thanks for the explanation. I tried running ./bootstrap, but got an error about "possibly undefined macro". At brendyn's suggestion I installed from (binary) tarball, and am currently in the several-hour-long process of attempting to test it by installing the "hello package" using --fallback because hydra doesn't seem to want to give me that package, interrupted twice due to running out of disk space since I didn't realize it <rekado>reepca-laptop: that doesn’t sound right <rekado>hydra should still have binaries for the last release <reepca-laptop>Wait, I just realized I might have forgotten to do a guix pull before installing <rekado>using the latest release should be fine <rekado>becase we keep binaries from the release on hydra <rekado>“guix pull” should not be used when you work with a git checkout anyway <rekado>reepca-laptop: what is it building? <reepca-laptop>that's what's showing up all over the place in the output, anyway <rekado>reepca-laptop: I would abort this. <rekado>hydra returns 404 for items that are not in the cache yet. <rekado>after requesting an item it is slowly added to the cache, and after a while it should work to download it. <rekado>but wait, you said you’re on i686? <rekado>I had the same problem with i686; looks like Hydra hasn’t built anything new for i686 in a while; at least not since after my glibc patch for i686. <reepca-laptop>yeah, my laptop technically supports x86_64 but I didn't know that at the time I installed Lubuntu on it several years ago, and it would be difficult to migrate now, and I don't have my desktop set up yet (moved home on Saturday) <reepca-laptop>Even compiling from source, it seems a bit strange to use up 2GB just to get the infrastructure for hello world... <rekado>reepca-laptop: well, it’s not surprising if it’s building GCC and its dependencies from source. <rekado>reepca-laptop: it’s not *just* building the “hello” package, but it instantiates the package graph that Guix specifies at this particular version. <reepca-laptop>Does it have to do the full bootstrap process of building GCC from older GCCs from older GCCs all the way down? <rekado>reepca-laptop: Guix comes with a handful of bootstrap binaries. <rekado>reepca-laptop: this includes one binary of GCC <rekado>but we’re building it a couple of times in a pseudo cross compilation to get rid of any references to the bootstrap GCC. <rekado>it’s like (GNU+)Linux from scratch. <efraim>go build _/tmp/guix-build-go-1.8.1.drv-0/go/src/cmd/dist: : fork/exec : no such file or directory :( <efraim>i successfully built gccgo-7, now trying to build go-1.8.1 with it ***jonsger1 is now known as jonsger
<guix-user>is there complete guix how to import package and then install em from melpa or something? <catonano>There's only the manual, as far as I know <catonano>The manual has a paragraph about importers <guix-user>guide or tutorial. Now, after "import" I see some ((ackage ...) definition, then I save is to something.scm, and add (define-module, by analogy with other packages.scm... But where is complete guide? <guix-user>I have many questions, for example: how to update emacs load-path after "emacs-" guix-package installation? <Petter>Think you'd need to prepend with (define-public, not (define-module. <amz3>guix-user: feel free to ask your question <amz3>guix-user: feel free to ask your questions <guix-user>Petter, yes and (define-module ...) and (define-public package-name ...), and I try to install resulting module with nothing happens <guix-user>yes, new-file.scm, then try to "guix package -f ./new-file.scm" <guix-user>no output, no errors, nothing happens, as I see <rekado>guix-user: could you share your file with us? <rekado>guix-user: “guix package -f” expects that the file evaluates to a package. <rekado>guix-user: if you want to contribute to Guix I suggest working with a git clone and make changes there. <rekado>guix-user: the manual explains how to set this up <guix-user>(a result of "guix import elpa -a melpa tao-theme" and add (define-public) around than) <efraim>i hate building subversion, it takes so long <rekado>guix-user: if you use “guix package -f” you need to end the file with “emacs-tao-theme”. <rekado>Or just don’t bind the package value. <rekado>the way you have it now Guix will evaluate the file, and all that does is create a binding. <rekado>it is not evaluating the binding. <rekado>I never use “guix package -f”; I think it’s better to put this in a module and then add the directory to GUIX_PACKAGE_PATH. <rekado>this means that the file wolud have to be stored at $GUIX_PACKAGE_PATH/gnu/packages/emacs-tao-theme.scm <efraim>I wonder if subversion's tests can be run in parallel <guix-user>interesting, someone works on import from AUR? <efraim>if you search the guix-devel mailling list archive there's an importer from debian, but its written in python <brendyn>I end up just reading the AUR definitions and doing it by hand. I'm not sure there is a realistic case where automated imports would work well <guix-user>though what import from guix scheme packages to many other package formats is far simpler task than in other direction. If it is true, then guix is best distribution for package creators. <rekado>the recovery REPL isn’t really useful in my case. <rekado>whenever my disk gets corrupted and I’m thrown into the REPL bournish isn’t really usable. <rekado>does it work well for other people? <civodul>i almost never get thrown into that REPL <rekado>I find that “ls /gnu” just prints “/gnu” (replace /gnu with any directory), but “ls” alone does work (it prints all top-level directory). <rekado>I end up there because my hardware is failing <civodul>typically we could easily fix 'ls-command-implementation' to do the right thing upon "ls DIR" where DIR is a directory <brendyn>I think there is also a bug with root requiring a password to use `su' too. <Petter>It happens for me too. Have to input the user's password to proceed. <efraim>should we add bayfront.guixsd.org.pub to the guix repo like hydra.gnu.org.pub <rekado>Petter, brendyn: This could be a pam misconfiguration. <rekado>maybe su just needs to become a rootok-pam-service <rekado>I’m not sure I did this right, but I checked on Fedora and they load the rootok module as well. <brendyn>Thanks. I'm not properly on GuixSD, I juts noticed it in a VM <mbakke>efraim: any chance you have efi firmware on your aarch64 boxes? :) <efraim>mbakke: I think I do on my hikey ***az` is now known as guix-user
<rekado>worst of all, they cannot seem to be unrolled <civodul>efraim: re bayfront's key, yes, i was planning to add it <rekado>this is a bottomless pit, and after a few hours of falling all I have done was taking jars from shelves and putting them back in as I fell by endless rows of cupboards. <civodul>i was going to ask "how do people handle this?" but i'm afraid the answer would be disappointing ;-) <efraim>new wxwidgets release, if anyone wants to grab it <rekado>I suppose one way around this is to give up on packaging ecj, because it’s a bootstrap dependency of gcj anyway <rekado>and gcj is used to build the JDK <rekado>maybe we should just build the JDK with the included bootstrap JDK, not with gcj <rekado>gcj has a dependency on ecj (which cannot be built), and it includes the pre-compiled classpath libraries. <rekado>using the bootstrap JDK that comes with the icecat sources is probably not much worse. <rekado>on Debian, ecj depends on “java-common”, which is provided by a JDK <civodul>yeah, we'll have to give up on gcj anyway <efraim>Bootstrap GCC -> jdk -> exj -> gcj? <efraim>Not to mention GCC@7 doesn't even have gcj <rekado>it’s a pity that there’s no easy bootstrap path for the JDK. <rekado>with GCC we basically know what to do <rekado>but the Java situation seems more complicated. <rekado>write a simple interpreter with a “javac” implementation on top of Guile maybe…? <rekado>there *are* some alternative JVM implementations, but all I’ve seen require a JDK to build them. <civodul>there was a JVM written in C++ back in the day, by IBM <rekado>“the last […] version […] partially supports Java 5.0“ <rekado>I really wished GCJ had not been abandoned <rekado>there would have still been a chance to undo the dependency on ecj <ng0>hi… grub build is failing its testsuite with a pull from today <ng0>FAIL: grub_cmd_set_date <ng0>can't investigate more though, writing an application atm <rekado>ng0: please report this as a bug with as much info as possible <ng0>I can do so, in probably about 1 - 4 hours depending on when I'm done with the application form for the fellowship <ng0>i just notices my server failing its update <rekado>civodul: maybe using Jikes really isn’t a bad idea <rekado>because most alternative JVMs use the GNU Classpath libraries, and to build those one needs a Java compiler. <rekado>maybe there’s a convoluted bootstrap path after all <j-r>anyone running guixsd as a virtualbox guest? <rekado>wow, jikes compiled without errors on the first attempt <civodul>j-r: dunno, though i wouldn't recommend virtualbox because it depends on a non-free toolchain <j-r>civodul: I know, $WORK forces me to do such things *sigh*. That help me install it, the guest additions are problematic. I didn't really expect anyone really does this, but I thought I'd ask anyway. <brendyn>Building my own install image seems to have been a terrible mistake. I'm building p11-kit on a new laptop from an install image with the same version and dependency versions but the hashes are all different from the laptop I generated the image on. p11-kit builds fine on the first laptop but fails two tests on the one running the install image <j-r>guix-user: no. I have to run $WORKS official windows image on my (actually their) laptop, that severely limits me. <j-r>otherwise I would run kvm or run guixsd on the bare metal. <efraim>after 'compress-documentation the daemon frees all the used space in /tmp? It sometimes takes a very long time on my aarch64 board with /tmp on an sd card <civodul>efraim: after the build completes, the daemon scans the resulting directories for store references, and then removes /tmp/guix-build-foo <civodul>not noticeable on an SSD, but harder for an SD card <efraim>like when the tar test timed out for me on creating and destroying an 8GB image <civodul>does our linux-libre package cross build to arm-linux-gnueabihf? <efraim>I think we have a arm-linux-generic <civodul>if it does, we may be able to cross-build GuixSD <civodul>and if we can do that, we can have a VM that builds for ARM <efraim>I didn't do anything and the kernel compiled on aarch64, but I assume most boards would actually use a vendor specific kernel <civodul>i'm looking for a cross-build that's "good enough" for QEMU <efraim>Had to disable tests on grub and guix, comment out acpi and all other kernel modules and pass '-machine virt' to qemu <efraim>And I'm still not quite there yet. If we want an arm guixsd image it might take some hackery <efraim>I'm still using guix on Debian on the aarch64 board <civodul>yeah, but it's good that you're trying to get GuixSD on it <civodul>if you could send a summary of what needs to be done to the list that'd be great <efraim>The hikey board I has support from Debian's generic arm64 kernel so I'm planning on using that for a lot of install tests when it comes time <efraim>And efi, not uboot, so porting should be easier <rekado>I just built classpath 0.93 (the last to not require ecj) with jikes. <rekado>now I wonder if I can use the two to build an earlier version of ecj. <efraim>Are you doing this by hand or writing up packages snippets as you go? <rekado>I’m surprised that this is without much difficulty <ng0>rekado: done. I'll take a break and then I'll get to the grub bugreport <civodul>"guix build linux-libre --target=arm-linux-gnueabihf" works a leads a bootable zImage \\o/ <ng0>wicked. this time I was able to build the system <ng0>maybe some non-determinism in grub? <ng0>or some software I needed to pull in whic hwasn't there the first time <Apteryx>civodul: Do you know of a way to pipe MIME attached patches to git am in Gnus? '| git am' seems to work only when the patch *is* the message. <rekado>Apteryx: I just open the attachment in Emacs, get the file name, and then use ‘git am file-name’ <civodul>Apteryx: or you can hit '|' on the attachment itself <Apteryx>civodul: Neat! I didn't know I could do that. <Apteryx>civodul: I also discovered in the docstring that when there multiple git send-emails messages, you can add a prefix to apply multiple messages in a row. Haven't tried it yet though! <Apteryx>Still, maybe a nifty elisp script that would automatically 1) apply git am on the body of the message or 2) apply git am on the individual MIME attachments would be a nice automation touch IMHO. <ng0>nice idea… I think I will propose a similar idea for neomutt <snape>ng0: do you think I can push 0ad? <ng0>up to the point where my computer couldn't handle the units anymore it way okay for me. Did someone review it? You already tested the functionality, so I thought this is the only part missing <ng0>I can look at the code within the next 2 hours if that's missing <snape>that would be very much appreciated :) <snape>my computer couldn't handle the units too <snape>I thought it was the graphic chipset <snape>it's a libreboot x200 -> not very powerful <ng0>realtime strategy is demanding. <ng0>1 hour worked out for me <rekado>building kaffe now, so that we have a simple JVM. And then we can try to use jikes+kaffe+classpath to build ecj. <ng0>I did not test the human -> human match <ng0>are there some special conditions with the perl license, that someone has to just state on a couple of files that it is licensed as this and not on all of them? I'm packaging this for my own use, but I could try and convice the author that some files need licese specifications <ng0>the binary states "copyright since 1993 <name>". the .pm states "licensed under the same license as perl" and for the rest I haven't located relevant files yet <ng0>okay, the license is alright on all relevant files <ng0>but I'm not sure if the statement in the binary works out <ng0>oh, is bayfront now operational officially and stable? create mode 100644 bayfront.guixsd.org.pub <ng0>not good. ice-9/boot-9.scm:2903:6: no code for module (ng0 packages personalized) … this used to work (included in the /etc/config.scm to load custom packages) just yesterday. GUIX_PACKAGE_PATH is exported in the shell. <ng0>snape: 0ad-data: just a matter of style and saving 1 line: move the "http://…" part of the string one line up indent the version … part of the string. description of 0ad-data: this is my error so maybe use "0ad-data provides the data files required by the game 0ad." 0ad: same for the (uri … part, I'd move the http:// one line up. synopsis: maybe explain "RTS" and the "3d, " at the beginning looks odd. <ng0>"3D, historically-based RTS game of ancient warfare" --> maybe: 3D Realtimestrategy game with historic elements? <snape>I agree on everything except "with historic elements" <lfam> Perhaps we should disable that flaky GRUB test <lfam>Did it fail for anyone else yet? <snape>ng0: btw it's not your error, I did modify the descriptions and synopsis <snape>what about: "3D real-time strategy game of ancient warfare" <lfam>ng0: Yeah, anyone *else* :) <lfam>Probably we should just disable it anyways <snape>alright, thanks, I'll push then. <lfam>civodul: Based on Danny's commit addressing the circular dependencies between (gnu system) and (gnu system grub), should I start a new Hydra evaluation? <ng0>snape: now I need to write some software and call it simply "0" so that 0ad is no longer the first package in the list ;D <snape>ng0: oh :) are you talking on the list of the website? <ng0>well 0ad is always the first package everywhere :) <snape>yeah, that's a pretty good name :) <Petter>Have there been in any effort in having the hash of 0ad start with 0ad? /gnu/store/0ad...-0ad- <lfam>Unfortunately, it would change as soon as any element of the dependency graph changed <ng0>that's occupied by groff.drv atm <ng0>0adcw4hsz69sgjjwy04nm6bf9ic93az5-groff-1.22.3.drv <snape>The best I could do is trying to get the git sha1 to start with 0ad <lfam>No SHA1 nudging allowed, please :) <lfam>ACTION wonders how the Git SHA1 migration is going <ng0>woops, I haven't finished the fossil 2.0 update. <catonano>rekado: I am impressed by your work on those Java things ! <civodul>lfam: you can start an evaluation, though i don't think this commit helps <lfam>Well, I started it anyways. We'll see <civodul>DoublePlusGood23: i use "git send-email", even though i use Gnus <rekado>I use git send-email, too. I don’t really like it, but I usually stop caring as soon as a patch set has been sent. <rekado>catonano: I’m working on your guile-miniadapton problem now <catonano>rekado: I'm working on it too and I'm lost <catonano>it correctly processes ONE file and then it hangs <DoublePlusGood23>rekado: civodul: do you need some sort of guix package? git says send-email isn't a command <rekado>DoublePlusGood23: you need to install a separate output <rekado>DoublePlusGood23: yeah, what efraim wrote :) <rekado>DoublePlusGood23: it’s not really optional, though. <rekado>DoublePlusGood23: at build time you still need them all <efraim>i sometimes look at abcde when I think about truely optional runtime dependencies <rekado>but with well-separated outputs *users* won’t have to download substitutes for runtime requirements that are only needed by outputs that they haven’t installed <janneke>mescc passes 33/55 tests from the tinycc test2 test suite <efraim>as expected, mes FTBFS on aarch64 :) <rekado>catonano: your problem is with match <rekado>catonano: you don’t actually need it. Use ‘basename’ instead. <janneke>efraim: sadly, that's very much expected :) <janneke>it has a (supported-systems) entry, isn't that enough? <rekado>catonano: I’ll send you my version soon <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs <janneke>but you tried anyway? how did you find it FTBFS? <janneke>ACTION just received an arm account from a friend, yesterday :-) <efraim>I tried guix build -f guix.scm and guix build mes <efraim>I'll post it later, not at my computer right now <janneke>mescc (the C compiler bit) is quite badly infested with x86 stuff <janneke>that needs some love, but i wanted to close the (any) bootstrap loop first <catonano>rekado: okk, thanks. I tried with basename right now and it hangs in the same exact way as before :-/ <efraim>I thought about modifying the make-bootstrap code to replace some of the actual binaries with simplified shell scripts <janneke>efraim: not sure if shell scripts is the way to go if/when Mes takes off, but yeah <janneke>efraim: cool that you have been looking at that! <efraim>Maybe not long term, but while bash is a bootstrap binary it seemed like a 'meh, maybe' idea <rekado>DoublePlusGood23: is there a better module for this? It doesn’t really sound like a game to me :) <DoublePlusGood23>rekado: Maybe. I think it's like "fun and games". I didn't see anything else that fit it. <lfam>I'd put it in the 'admin' module <rekado>yeah, that was my first thought, too. <ng0>if scripts are used, I think ash or anything similary small (rc,es,) should be a choice, not just for size though. I find the size of fish funny. okay, mostly coreutils… https://ptpb.pw/qxxb <rekado>DoublePlusGood23: a little hint on Scheme conventions: for ‘end of the line’ comments we use just one semicolon. <rekado>DoublePlusGood23: the double semicolon is used when you have only the comment on the line. <rekado>DoublePlusGood23: it’s good that you used the ‘file-name’ field, but you forgot to add ".tar.gz" at the end. <rekado>I also think that you may not need to explicitly add ‘bash’ to the inputs. <rekado>if you’re okay with these changes I can just make them on your behalf before applying it. What do you think? <DoublePlusGood23>I'll see if I can make some more expressions. Eventually I'd like Telegram. <rekado>DoublePlusGood23: hmm, the are some more problems with the package. <rekado>DoublePlusGood23: 1) it installs into $out/usr/bin/ <rekado>DoublePlusGood23: 2) it doesn’t seem to work on my machine :) <ng0>regarding "more expressions"… do we have a policy on what's applicable to master in terms of pentesting software? I know I added one or two packages, but I have more "dormant" in my wild repository because my views might not be true for what everyone agrees upon <rekado>the first is easy: we’ll just patch the Makefile <ng0>I basically started porting whatever Blackarch, Kali etc have <rekado>DoublePlusGood23: the script makes assumptions about where it has been installed. <rekado>DoublePlusGood23: it assumes that there will be either ‘/etc/neofetch’ or ‘/usr/local/etc/neofetch’ <rekado>that’s why it’s always good to have a configure script <rekado>DoublePlusGood23: we can patch this, too <ng0>i guess i should read the mail <ng0>I was asking becasue i thought someone would have an tl;dr 1 sentence description :) <rekado>hehe, it says this: ‘Terminal: .guix-real’ <rekado>ng0: there’s a description in the package expression ;) <slyfox>'eix neofetch' says 'Simple information system script'. it shows nice ascii art of what your system looks like <ng0>i think while we are at it i should add this other admin game i have packaged <ng0>I'll move it to the master tracking repo and send the patch <rekado>DoublePlusGood23: I’ve added a new phase ‘patch-target-directories’ that replaces some strings in both ‘Makefile’ and ‘neofetch’ itself. I hope this still makes sense. <ng0>inxi has this internal game, where they include the release snapshot of HEAD in the repo at $commit and you have to delete it because you don't want the source twice ;D <ng0>this comment is okay I guess? ";; Upstream refuses to release, tag, or do anything other than commit." <rekado>DoublePlusGood23: the ‘\\\\’ is just a regular ‘\\’; we need to escape it in Guile strings. <rekado>DoublePlusGood23: the ‘\\’ itself is to escape ‘$’, ‘(’, and ‘)’. <rekado>because they have special meaning in regular expressions <rekado>(end of the line, beginning of match group, end of match group; in that order) <rekado>so the first substitute* call just replaces DESTDIR with PREFIX <rekado>(in that instance where it’s used with /etc) <CharlieBrown>I enabled a Tor HS. Why is there no hostname file in /var/lib/tor/hidden_services/hostname? <rekado>DoublePlusGood23: the next one replaces ‘"/etc/neofetch’ with the path to /etc/neofetch in the store. <rekado>DoublePlusGood23: and the same for ‘"/usr/share/neofetch’ <rekado>it’s a lot uglier because of regex syntax and string escaping <ng0>this is just stupid… but well, their decision to include the tarball :) inxi.tar.gz | Bin 201191 -> 201246 bytes <DoublePlusGood23>rekado: Hmm, actually it looks like it making the Makefile & neofetch into an..."object" of some sort <rekado>DoublePlusGood23: yes, ‘substitute*’ takes a file name or a list of file names, and any number of replacement clauses. <rekado>DoublePlusGood23: no, nothing there is turned into an object <rekado>DoublePlusGood23: it’s just a Scheme expression that causes these files to be modified. <rekado>DoublePlusGood23: yes, this is its purpose, so it better be able to do that :) <rekado>I think ‘substitute*’ is defined in Guix, but it’s defined with Guile. <rekado>just like we have ‘let’ and ‘let*’, which has slightly different behaviour. <rekado>DoublePlusGood23: all of this stuff in the ‘arguments’ field is quoted code. It is passed to the builder, which then executes it. <rekado>normally, you have to give a procedure arguments in a particular order <rekado>with keywords you don’t have to do that. <rekado>you can just match arguments by name. <rekado>in this case the ‘patch-target-directories’ phase is a procedure that only cares about the argument named ‘outputs’ <rekado>it will ignore other keyword arguments, hence the #:allow-other-keys. <rekado>the arguments are provided at build time. <DoublePlusGood23>rekado: I think I should brush up on some scheme before writing another package <rekado>it won’t get more complicated than this <ng0>you can pick up a fair amount of it by just doing <ng0>inxis ignorance on having any other release method than the git checkozt is bothering me… their small bashscript repository has grown to 70MB now because they don't understand that it's silly to include the tarball in it, but they are well aware of it. if they would put a version number to it… but no, what a revolutionary idea. let's just update it in place and grow MB by MB <ng0>ah, I wasn't finished, that's why it was sleeping in my packages repo <ng0>we could just tag a release if we use github… but that's a world gone topsy-turvy, we can't do that. let's grow our little tarball project. <ng0>git clone https://github.com/smxi/inxi ; cd inxi; du -h . this 512KiB script + 32KiB manpage includes a tarball, unversioned, with the release where their recommendation is to just git clone. <ng0>I put it in admin, but I'd rather put it in gnu/packages/games.scm because of this <ng0>the game is, grow the tarball, delete the tarball :) <ng0>if only we had shallow clone in guix ;) <lfam>The Git-related discussions on the inxi bug tracker are comical <ng0>I'm not working on that anymore though i have the patch wingo did in 2015 to some degree applied. it's just that so much changed and is changing again in git related modules that I stoipped <ng0>it's like this discussion I tried to have with repowhatever… "it's no problem because it's no problem" <lfam>ng0: Yeah, and also the many requests for tagged releases <Maginos>How would one replace the C standard libary in GuixSD? <ng0>"it's difficult" but doable with some dedication <ng0>we have musl… and if someone wants to debug it, we have uclibc-ng. in my imagination it can be a systemwide switch, but it depends on the depth you want. <ng0>I think the better reply would be, ask on the mailinglist and someone who put more thought into that matter or relevant parts of Guix will reply. irc is a bit sporadic for good async conversations 