<pkill9>see if it builds with `guix build --with-source=<newer version> gzdoom`, though the source file needs to be named in the form of "<package name>-<package version>.<ext>" <pkill9>if it does then run `guix package --with-source=... gzdoom` <pkill9>you can also write a package definiton that inherits gzdoom and uses an updated source <eubarbosa>I totally agree with ambrevar. Have to learn all those different programs configuration syntax is just too much! That is why lately Ive been just removing programs that I dont use that much so I can easy all that hassle <ecbrown>in guix-installed kdenlive, i see "Cannot find your MLT profiles, please give the path" A non-existent path appears (but it's close) and when i accept or correct it the program just exits to the shell <ecbrown>anyone seen, and hopefully found a solution to this? <ecbrown>wondering if i'm missing some KDE environment variable... <noobly>does something like gentoo's distcc exist for guix?: "distcc is a tool that lets you share the burden of software compiling across several networked computers" <noobly>networked computers of different architecture, is what it's specifically used for ***paroneayea is now known as dustyweb
<samplet>noobly: I don’t know Gentoo well, but that sounds kind of like “offloading”. It’s described in section 2.4.2 of the manual, “Using the Offload Facility”. <apteryx>yay! I'm ssh-agent free, using gpg-agent only. <apteryx>if someone's interested, I could post the config bits to guix-help *vagrantc would someday have interest, possibly <tune>getting a few youtube videos that won't open in mpv. I'm guessing guix's youtube-dl needs to be updated <dckc>guix describe: error: failed to determine origin <dckc>I'm quite surprised this error message isn't known to google. <dckc>I just (a) became root on my ubuntu 16.04 box and ran the guix install script, and (2) exited to my normal user and ran that `guix describe` command <dckc>`guix package -i hello` works, first as root and then as my normal user <efraim>i've updated youtube-dl, if you run 'guix pull' you'll get the newer version <tune>updating never seems to go smoothly anymore... not even just having to delete a current-guix file, I'm occasionally getting weird permission denied issues lately <civodul>tune: "Permission denied" probably means these files are owned by another user <civodul>e.g., because you ran "guix pull" as another user <civodul>re deleting 'current-guix' files, there must be something wrong with your install that would be worth investigating <tune>I basically attempt to do system upgrades and then user upgrades and just about every time they both fail on a similar error <tune>not sure if part of my process is flawed <ngz>Hello. It seems that #:out-of-source keyword is not documented in the manual. Is this an internal keyword only? <civodul>ngz: no, it's just that build systems are not fully documented in the manual :-) <civodul>it gives hackers an incentive to look at the code ;-) <ngz>That's what I did. I'd like to set it to #f in a package using cmake-build-system, but I don't know if it could have side-effects (beside the one I want) during derivation building. <ngz>It makes `validate-runpath' phase fail. <civodul>tune: regarding the migration, i suppose you have a "half-migrated" guix profile; ~/.config/guix/current does not point to /var/guix/profiles/per-user/$USER/current-guix, but /var/guix/.../current-guix exists <ngz>So, is there a way to get back to unpack directory instead of "build"? It seems that (assoc-ref inputs "source") wouldn't help, as it probably points to the tar file, not the unpacked directory. <ngz>Or do I need to build the directory name using version and so on. <efraim>note to self: telenet is not the same as telnet <ngz>Because `open-file' cannot find an executable. <ngz>civodul: the package definition or the build log? <civodul>tune: user "brad" is OK; for user "root", make sure ~root/.config/guix/current points to the right thing <civodul>ngz: the 'validate-runpath' bit of the build log <ngz>OK, but let me double-check. I wouldn't want to waste your time because a stupid error of mine. <tune>civodul: thank you, it looks like it was pointing to the wrong thing <ngz>civodul: Nevermind. It was indeed a mistake of mine. <ngz>Toggling #out-of-source seems innocuous. <pkill9>is anyone else unable to open kdenlive? <pkill9>it prompts for the path to mlt or something, and then you click ok and nothing happnes, no error message either <civodul>jonsger: i'll apply it if no-one beats me at it, thanks for the heads-up! <jonsger>efraim: rutger commented that you fixed there error already on staging <roptat>did you have some time to look at kotlin yet? <g_bor>roptat: I had a look, but did not make much progress yet. <g_bor>It has a huge bunch of modules, but at least at some places it seems they did the right thing... <roptat>I fixed the issues in my parser, so it's a bit faster now <g_bor>I've recently made some progress with openjdk reproducibility, it looks much better now. (I can diffoscope it without running out of memory...) <roptat>but at some point the compiler fails because it has no memory left :/ <g_bor>roptat: do you think it is leaking? <roptat>no, it's pure Java, it shouldn't <roptat>I guess it's building something really big for some reason <g_bor>roptat: yes, I was thinking along the same lines. <g_bor>can you isolate a file where that happens? <g_bor>Or is it happening every time? <roptat>when I run on every file, it happens on the same file every time, but I can parse the file when it's alone <g_bor>roptat: is it possible to work around this by parsing them one by one? How is this supposed to work? <roptat>no, because I'll be lacking type information *g_bor try building openjdk after guix gc <roptat>but there's no reason why it runs out of memory in the first place <roptat>there's tens of thousands of tokens, that shouldn't take that much memory <roptat>or maybe I'm wrong and there are much more tokens than that <g_bor>roptat: so a shared datastructure is build up from the files, is it possible that this shared datastructure goes big? <g_bor>Could you add some logging/statistics to find out how much token actually gets added? <mbakke>`guix build -e` fails for modules in channels. <mbakke>E.g. `guix build -e '(@ (chromium chromium) chromium)'`: <mbakke>In procedure module-variable: Wrong type argument in position 1 (expecting module): #f <civodul>mbakke: you can work around it by adding a package name on the command line :-) <civodul>that's because (guix scripts build) loads (gnu packages) lazily, and (gnu packages) is responsible for initializing the package search path <jonsger>mbakke: did you already pushed your "updates" to wip-gcc7? <roptat>arg, I found new mistakes in the parser <roptat>I'm using another computer, so the order of `find` is different, I get files that I didn't analyze before ^^" <roptat>ah, I hate that... "--^" is a valid identifier in scala <mbakke>jonsger: Sorry no, will do that later today! Not much have changed though -- I managed to lose most of my work on it by doing `git reset --hard` by accident :/ <mbakke>efraim: Nope, the work was not committed. I probably should not use `git reset --hard` (and reflog) as part of my daily workflow. ***rekado_ is now known as rekado
<rekado>I just pushed a texlive-configuration profile hook. <rekado>The hook is a bit ugly, but it works fine for me. <rekado>I added a few more texlive packages and fixed python-numpy-documentation. <rekado>if you want to give texlive a try, install “texlive-base” together with a few more packages you want to play with. <rekado>I had to install texlive-base, texlive-luatex-luaotfload, and texlive-fonts-lm to satisfy a run of “lualatex”. <civodul>now i just need to find out which packages i need :-) <civodul>perhaps we need a "texlive-essential" meta-package or something like that <rekado>I’m still a bit fuzzy on what a user should reasonably be able to expect from a texlive installation. We may add a few packages to “texlive-base” to simplify things. <rekado>texlive-tiny is for use in package definitions. <rekado>it wraps all executables in some environment variables, which are handled differently when installing to a profile. <rekado>it’s a bit ugly, to be honest. Maybe we can get rid of texlive-tiny later. <civodul>should we arrange to mark "texlive-tiny" as superseded by "texlive-base", while still using the actual texlive-tiny internally for packages? <civodul>that is, we could have a public "texlive-tiny" that's deprecated <civodul>and a hidden texlive-tiny that's the same as now <rekado>“texlive-tiny” inherits from “texlive-base”, so it doesn’t hurt to have it installed. <rekado>I changed the wrapping so that it uses “suffix” style environment variable definitions, so things should just work out fine. <rekado>but ultimately it would be nicer to have one fewer of these package definitions. <civodul>anyway, thumbs up for closing a 5-year(?) old issue! <rekado>unfortunately, the hook was still necessary after all, because I couldn’t convince TeX live to do the right thing when looking up parent and grandparent directories. <rekado>that’s why the hook builds a union first, so that the texmf.cnf it contains will have the union as its grandparent… <rekado>I’ll gladly revisit this in time for 2.0 ;) <civodul>yeah, we'll keep that in mind for 2.0 :-) <shidima>I'm looking for some info on running GuixSD in VirtualBox with the Guest ditions <shidima>Is there a package for that? If I search for one with guix I cant find any <bgardner>Hey guix, I reported an grub-EFI issue on boot a couple days ago - just wanted to circle back and say that switching to non-EFI boot fixed it immediately so I think I'm chalking my issue up to oddball hardware. <roptat>shidima, I don't think we have it <shidima>Ok, will have to look into making something myself then <roptat>I think there was some concerns about it being non free, but I don't remember the details <shidima>Yes, I understand that. But its what I have to work with. I would prefere KVM, but thats not an option <rekado>Guix is on the HN front page again. <shidima>Yeah, thats where I found it today :) <shidima>Tried NixOs before, but didnt like the Nix language. <rekado>civodul: do you think we can close bug #27217 now? There are now less than a handful of packages that don’t use texlive-union. <g_bor>any idea how the classlist file in openjdk is generated? <rekado>g_bor: could you provide more context? Where is that classlist file used? Is it installed or used during the build? <g_bor>I guess during the build, it lists class names, and the order of entries is not deterministic. <g_bor>I guess it propagates through to the modules file, which seems to be some classes concatenated... <g_bor>I am currently building openjdk11, will have more context when that is finished. <g_bor>The jdk output is now almost passes --rounds=2... <rekado>it might be generated via the Makefile with a glob pattern <rekado>the hardest part about splitting modules (or moving packages) is to update the copyright headers… <g_bor>rekado: I was thinking about this split the packages individually into modules, and it seems to me, that it could be done like this: <g_bor>do the splitting, but don't create them as separate modules, then create the dag that results from that. <g_bor>After that layer the dag, and concatenate the packages in one layer to a module. <g_bor>This would solve the too many modules problems in a very elegant way. <g_bor>Also, if it turns out that one layer consists of too many packages, we could spilt that up arbitrarily. This way even the size of the modules would become quite balanced <lsl88>g_bor: I am finishing my first video :) Was just recording the last audios <rekado>I’m sorry to everyone merging branches, but I’m now pushing the patch that splits python-xyz.scm off from python.scm. <lsl88>g_bor: am I connecting and reconnecting all the time? <rekado>lsl88: no, I’ve only seen you join once. <lsl88>ok, thank you :) I would like to share the first full video instead having to make you create it, shall I use ipfs? <g_bor>lsl88: yes, I've also only seen you join once. <lsl88>I guess I will have it finished in a couple of hours, I am testing the audio matching for cli sessions, since there is silence in between <g_bor>lsl88:I tried to send you a message through jami, I'm not sure it worked. <lsl88>g_bor: at least it did not appear as a notification <g_bor>I think I will write to the ML, to get someone check the scripts of the en_US videos, and also to do the voice recording. WDYT? <lsl88>g_bor: I got it please write again to see if it appears as a notification <g_bor>lsl88: I don't see you now as online... <rekado>g_bor: module concatenation does not seem possible with Guile. Or do you mean outside of Guile as part of the build system? <g_bor>I just tried sending, and it is red. <g_bor>rekado: yes, I thought about that. <lsl88>g_bor: in jami? i have allowed it to show notifications, do I appear online now? <g_bor>rekado: it would be almost trivial, once we have the graph part, then the concatenation part seems easy... I guess we could jsut union the public interfaces, and use all modules from the layer below. WDYT? <g_bor>lsl88: no, it seems to me that you are not available... <g_bor>lsl88: Maybe this is not reliable... <rekado>g_bor: do you mean concatenating the module *contents* as text? <rekado>g_bor: would we need to merge the module headers then? What about duplicate imports (“zlib” from licenses or from compression?), etc? <g_bor>lsl88:ok, leave jami for now, it does not seem reliable. One app thet worked for me is riot.im, the matrix client. <g_bor>I would go with something that works for now, as you will be quite far away from home... <g_bor>rekado: how is that solved now? <lsl88>g_bor: do I have to set something extra in settings? It shows me connecting but nothing else <rekado>g_bor: we address this in each module with whatever mechanism that works best. A dumb concatenator script won’t be able to find the correct way to merge these different approaches. <g_bor>It seems that something is broken on the DHT level... That should pass the online status. <g_bor>essentially this is the the same thing why licenses are sometimes imported with prefix, and sometimes without it, right? <g_bor>lsl88: there is also a flaw in jami, that I only learned yesterday. It does not delivers the messages sent when the reciever was offline later. <lsl88>g_bor: for me? what should I change in settings? <lsl88>g_bor: shall I uninstall it or give it a try again? <g_bor>lsl88: I think that we should not use jami yet, it does not seem to be stable. <lsl88>g_bor: ok. please, tell me what app I should install then :) <g_bor>You can uninstall it, but be aware that it seems that you cannot get back you username if you do that. <g_bor>lsl88: could you try riot.im? <g_bor>rekado: I feel that actually these duplicated imports are bound to cause confusion anyway, so it would be nice to get rid of them. What do you think? <g_bor>For example for the case you mentioned importing licenses always with prefix could solve this in a uniform way. <lsl88>g_bor: have just installed it. My username is the same than here <g_bor>lsl88: my username is g_bor there. <eubarbosa>how I make sure guix detect fedora so I have it on grub entries? <g_bor>eubarbosa: do you want to dual boot guixsd and fedora? <g_bor>eubarbosa: then it depends on from which system would you like to manage the bootloader from. <eubarbosa>g_bor: oh, ok! I will read more about how dual boot is done. Might be just that I dont know how to do it! <roptat>I think the menu-entries field is what you want to configure <g_bor>yes, that was also what I would suggest next :) <lsl88>g_bor: sent you a message with riot <g_bor>That is for the case when it is managed from guixsd, and I also recommend that. <g_bor>lsl88: strange, I did not receive it yet... <g_bor>also that app is working, I get the messages from this channel... <lsl88>g_bor: may you send me a message? yes, you appear as part of IRC <g_bor>lsl88: you username does not appear for me in the seachbox... <g_bor>it also seems, that my website client is connected throught only one way... <g_bor>I guess that's because the differing nicks, though... <lsl88>g_bor: you appear as offline, but I sent you hi! <lsl88>g_bor: you appear as g_bor(IRC) I am on Matrix :-/ <g_bor>that is strange... I am logged in as @g_bor:matrix.org according to my settings page... *jonsger has now the FOSDEM schedule on his N900. Just needed to do some packaging for Debian 4. The interesting guix/guile talks are already marked as favourite :P <g_bor>lsl88:ok, it seems I finally found you... <g_bor>I have to now, I will leave my phone client online. <civodul>rekado: i think we can close it, yes <rekado>I just packaged ydiff but noticed that it isn’t very usable. <rekado>it cannot be plugged in as a git diff program, for example; it produces an HTML document and depends on a js and css file that need to be in the same directory as the HTML file. <rekado>is anyone here working on adding IPv6 support to static-networking-service? <civodul>if you have questions we can discuss them here <civodul>i don't necessarily have answers but i fiddled with that part of (guix build syscalls) :-) <rekado>I just saw it in the roadmap for 1.0 and thought it would be nice to turn another TODO into DONE. <apteryx>hello, I'm trying to "build" a mini package (bash script): https://paste.debian.net/1060626/, but it fails with the error recorded within that paste (invalid hash 7c469e1adb762ca28e20bb8ab9a801608aebf3a5acfdc8d5f4a5f175d79c61931f). <apteryx>ti has nothing to do with the hash I record in the package definition, so I'm a bit at a loss. <bavier>apteryx: you mean, the hash of the git checkout is correct in your definition? <apteryx>hmm it's incorrect in the paste since I was testing, it should be 1z4v16lbpbwd5ykawizdclpryp2k006lbk2mv427a4b3nvcd9wikw, but yes, I tried it with the correct hash and had that same error. <apteryx>(given by 'guix hash -rx .' in the git clone of cqfd) <bavier>apteryx: and you checked out version 5.0.1 before 'guix hash -rx'? <apteryx>I did git describe and it gave me 5.0.1, so it should be good <apteryx>(of the package definition). I was under the impression the message was usually: expected XXXX actual XXXX rather than the more cryptic message I got. <apteryx>the package definition I added to the (gnu packages docker) module. <g_bor>rekado: how does the current static network service work? <g_bor>I am on mobile now, so I can't easily have a look. *bavier a bit sad to be missing GuixDays <apteryx>I got out of the weird hash error, not such how, but I'm happy ;-) <apteryx>probably using the wrong version tag string (5.0.1 instead of v5.0.1) <rekado>oh, I broke the scons build system, <civodul>rekado: where can ltxcmds.sty come from? <civodul>it's texlive-latex-base on Debian but not for us <rekado>it’s part of the oberdiek package <ebrasca>Hi , how is port for talos II going? <rekado>ebrasca: it’s not. We’d need a talos II machine for that. <pkill9>is it possible to write to files in guile modules? I'm curious how safe guix is from malicious package modules <pkill9>e.g. can a scheme module cause a file to be written somewhere if it's run with `guix build -f <scheme module>`? <ebrasca>rekado: I have tested debian , gentoo and parabola. <rekado>ebrasca: would you like to give porting it a try? <ebrasca>rekado: I have bad experience with porting Parabola GNU/Linux-libre ( I am no longer porting Parabola ). <eubarbosa>hey, does that mean, Guix wont ever have npm? <rekado>ebrasca: I don’t know this person. <rekado>eubarbosa: “ever” is too strong. It’s very difficult to do this right, but there’s ongoing work to import packages from npm. <rekado>ebrasca: I have also never seen anyone by the name Isengaara on IRC or on the mailing lists. <roptat>pkill9, the scheme module is actually a standard guile script, so yes it could <ebrasca>rekado: How hard is it to port GuixSD? <bavier>ebrasca: I vaguely recall someone here who mentioned guix on power9... <apteryx>any way out of: mkdir /var: permission denied error in a guix build container? <bavier>ebrasca: "jonsger" here has recently been trying to build bootstrap-tarballs for powerpc64el <apteryx>I'm trying to run a dockerd (daemon) instance to run the test suite of cqfd <bavier>apteryx: can you tell dockerd to use a different directory? <ebrasca>bavier: I allways think it is ppc64le. <bavier>ebrasca: "le", right, I typo'd that <efraim>I'm still undecided about porting to powerpc <ebrasca>Can I install GuixSD from other Distribution? <roptat>you can call "guix system init" on other distros <roptat>civodul, I'm trying to update php, but it's failing tests that it should skip :/ <bavier>ebrasca: from another distro you can get Guix built, and then, as roptat said, you can install the full system with 'guix system init'; but that is probably a future excercise <bavier>ebrasca: if you can get Guix built on top of another distro and can manage to build the bootstrap binaries, that'd be a great start <pkill9>as aresult of running `guix build --with-commit=obs=22.0.3 obs` <bavier>feature for 1.0: having the daemon chown build directories in /tmp when the build fails with 'guix build -K' <pkill9>feels nice when software bug is gone after updating <pkill9>how do i progress beyond the commit message of magit? <pkill9>i feel like a new user of vim right now <pkill9>oh i found out from a stackoverflow answer, it's C-c C-c <jabranham>pkill9: magit also told you that in the echo-area when the commit window first popped up. easy to miss though if you start typing quickly. <apteryx>bavier: good idea -- I'll inspect dockerd switches <reepca>anyone have any idea why our ftp client in (guix ftp-client) would get stuck reading at the end of a download? Specifically in the READ! used in the custom port returned by FTP-RETR? <pkill9>does anyone know of a way to make xfce4's update it's record of .desktop files without logging out+in? <bgardner>I apologize if this is covered in the docs and I missed it, but is the 'right way' for "Add package globally for all users" to edit /etc/config.scm, add package to list, then "guix pull && guix system reconfigure /etc/config.scm" or just (as normal user) "guix package -i package" and ignore /etc/config.scm? Or should that be "sudo guix package -i packagename"? <reepca>the "guix package -i ..." commands all install only into the profile of the current user - with sudo it installs into root's profile. Reconfiguring is the right way to do what you say, I believe. <ebrasca>Can I install GuixSD on btrfs subvolume? <eubarbosa>ebrasca: I think so! There is only a limitation warn: "Support for the Logical Volume Manager (LVM) is missing." <adfeno>Hi there, how to delete old `guix pull' generations? <reepca>now why would an ftp server not be closing the data transfer connection after it sends everything? <jlicht>How can we get icecat to accept self-signed addons? <pkill9>adfeno: `guix package --delete-generations[=<older-than>]` <adfeno>pkill9: For guix pull I use `guix package --delete-generations' too? <adfeno>Hi civodul, how to delete old `guix pull' generations? <rekado>adfeno: you can use “guix package -p ~/.config/guix/current --delete-generations=…”, I think <apteryx>what would be the best directory in which to install bash completions? <apteryx>I see various places are being searched for: bash-completion/completions/package-name or etc/bash_completion.d/package-name <apteryx>I think I prefer the first one (share seems fit). <civodul>apteryx: Guix installs its own completion files under PREFIX/etc/bash_completion.d <civodul>that's a fairly common convention, i think <apteryx>OK! I'll go for that then! thank you :-) <civodul>it's so cool that "guix build nothing" now runs in less than 0.1s with the package cache <civodul>jlicht: i just saw the hash change for emacs-closql, do you know why the hash changed? <jlicht>It _probably_ had something to do with the fact that I was messing around with several versions of emacs-closql before settling on the final one, but not updating the hash <jlicht>(which then worked because of the fun and interesting ways in which already-downloaded sources are referenced, I guess?) <reepca>civodul: any idea why get-bytevector-n! would fail to return EOF on a socket port and just wait forever, even when the other side has been closed and all data has been read? I'm really stumped debugging ftp-client.scm. Downloading the intended file works fine with wget, so I'd assume the data transfer connection is indeed being closed, but for some reason the client is getting stuck on that get-bytevector-n!. <civodul>jlicht: it'd be nice to check the diff and explain in the commit log next time, just to be on the safe side! <jlicht>anyway, I took some time to verify that that new hash is the actual one we want, using some vpn's and some contact with coworkers. My apologies for any bad dreams it may have given people <civodul>reepca: did you strace the thing? :-) <reepca>yup, got stuck on a read of a file descriptor that ls -l /proc/<that-pid>/fd tells me is a socket <civodul>but the read(2) doesn't return, right? <civodul>it may be a subtle protocol difference <reepca>texlive-20180414-texmf.tar.xz does, apparently <reepca>ftp://tug.org/historic/systems/texlive/2018/texlive-20180414-texmf.tar.xz <mbakke>bavier: Guix already chowns failed builds for the invoking user, no? <reepca>yeah, it only gets stuck at the end <reepca>which makes this perhaps the worst test case <jlicht>In trying to update our version of `docker-compose' and dependencies, I am running into several new circular dependencies. Et tu, python? <bavier>mbakke: not that I see, to clean up I have to 'sudo rm -rf /tmp/guix-build-...', unless that's changed recently <civodul>reepca: given that it's a huge file, there could be something in between that says "no more", maybe? <reepca>civodul: I've had similar issues with a smaller file, 40MB or so <reepca>don't have the url at hand, though <mbakke>bavier: The chown-failed-builds feature was added to guix-daemon a couple of years back and works for me. <rekado>eubarbosa: C-u M-x /path/to/sicp.info.gz <rekado>eubarbosa: or info -f /path/to/sicp.info.gz on the command line. <reepca>Gotta head to class, but I'll run wget with --debug and see what it can tell me about how it manages to succesfully get texlive <bavier>mbakke: hmmm, now I feel silly, I could have sworn I just looked at a few directories and they were still guixbuilder01:guixbuild. Indeed seems to be working here :/ <rekado>bah, I’m splitting modules like crazy but I still haven’t managed to decrease the module closure for “coreutils” <mbakke>bavier: Ha :) You probably looked too early, glad it works! *vagrantc tried to update u-boot in guix ... and the test suite for u-boot-tools is failing ... on testing the something related to audio/sound output <mbakke>rekado: How are you inspecting the module closure? <rekado>mbakke: ./pre-inst-env guix graph -t module coreutils > modules.dot <vagrantc>i guess u-boot-tools abuses the sandbox test suite build... which actually does have sound capabilities ... even if u-boot-tools doesn't use it <rekado>eubarbosa: oh, sorry, I meant C-u C-h i /path/to/sicp.info.gz <rekado>mbakke: I just moved gdbm and sqlite out of databases.scm, but in the end we drag in databases.scm anyway… <rekado>comes in via admin.scm, which comes in through linux.scm, which is used by way too many other modules. <mbakke>rekado: Woah. Even seasoned Guix users can still learn new tricks :-) <civodul>reepca: hmm, dunno what it could be then; if you manage to gather more hints, please email bug-guix <civodul>rekado: heh, thanks for the module splitting work, i know how frustrating it can be :-) <civodul>linux.scm was supposed to be for Linux-specific software but now it comes with the kitchen sink as well (which may or may not actually be Linux-specific) <civodul>vagrantc: uh, good luck with that one ***jonsger1 is now known as jonsger
<jlicht>civodul: perhaps it would make sense to have a per-file header, between the license blurb and the actual module definition, where we state what the purpose of each file is/ <civodul>yeah but sometimes the purpose changes over time :-) <vagrantc>it would be too expensive to do one file per package? ... i guess some packages re-use a lot of functions or processes or whatever <rekado>vagrantc: one problem is that Guile has one file per module; so we’d have a lot more I/O to load all of those modules. <vagrantc>i've also been chasing down new inputs for updating electrum, and it makes it kind of hard to know where to put the inputs that really are just a means to an ends and i'm not particularly interested in them <jlicht>maybe some guile modifications can be made to have multiple .scm files map to [offsets in] a bigger .go file ***PlasmaStrike[m] is now known as PlasmaStrike