<rain1>I'm doing alist-replace 'install <rain1>what would the working directory be? <rain1>I'm having trouble giving it the right path to the binary it needs to copy into /bin <lfam>rain1: First, it's preferred to use modify-phases instead of alist-replace. <lfam>Typically the working directory is the top level of the unpacked source code <rain1>if this fails ill add the directory then <lfam>If you can't figure out where the binary is, you can use --keep-failed and add a phase that stops the build, and then inspect the "in-progress" build directory <rain1>oh what a cool trick! that will save me a lot of rebuilding <lfam>Well, you will have to restart the build from the beginning. Once you stop a build, you can't restart it. But it's still helpful to poke around in there sometimes <lyk>hey all, I'm having a little trouble with the initial system init and was wondering if I could get a little help <lfam>lyk: Sure, go ahead. I'm not an expert on that topic but hopefully I can help. Or maybe someone else will jump in <lyk>it fails test 12, test_format_newc <lfam>lyk: It looks like that is part of the test suite for libarchive, which I assume you are building as part of the system initialization process. <lyk>yeah, libarchive is where it fails <lyk>I've tried it multiple times now <lfam>Okay, what version of libarchive is it? <lfam>There should be a string that looks something like this: /gnu/store/23jk32jhkj2fkj3bfk23hkjh23-libarchive-version/ <lfam>Can you say what is in the place of 'version'? <lfam>Or, you can execute this command in the shell: guix package --show=libarchive <lyk>sorry, I looked away to try to scroll up the tty, but zile had killed the scrollback, I think <lfam>Okay, did you ever run `guix pull` before doing the initialization? <lyk>I just followed the instructions after booting from usb <lfam>lyk: And, what installer are you using? 0.9.0? <lfam>Okay, the test failure is hopefully "obsolete". What's happening is that you are trying to initialize the system with the Guix package tree from the 0.9.0 release (November). However, our build farm has since garbage collected many of those binaries, and we have also fixed many bugs and security vulnerabilities since then. So, running `guix pull` will update your package definitions to the latest version, so you will not *have to* build so <lfam>much from source, and hopefully that libarchive bug will not manifest itself <lfam>Of course, you can build from source if you want to, with --no-substitutes. That will take a while <lyk>I wasn't aware that guix pull was available <lfam>The latest version of the installer actually suggests that users run `guix pull` in the MOTD. <mood>I believe I also ran into the lack of guix pull instructions in the manual, some months ago <mood>s/instructions/instruction <lfam>Yes, we have begun sprinklings reminders throughout the code base ;) <marusich>Now using GNOME on GuixSD 0.10.0. So good!! <sneek>Welcome back marusich, you have 2 messages. <sneek>marusich, xd1le says: mark_weaver didn't use ftp there though, that's a https url. i had a similar ftp.mozilla.org issue (see the logs), and it seems as though their ftp has been decommissioned: <https://bugzil.la/1250774>. However, they seem to have replaced it with https, so if you just change the ftp:// at the start to https://, it should hopefully work and have the same hash (use guix download to check if it's the same correct <sneek>marusich, xd1le says: ...hash). I'm about to ask a question to help-guix@gnu.org about how to override the source uri of just an old version of a package, so look out for that if it helps you. <lfam>lyk, mood: One issue with the online manual is that it is tied to the latest release, so it doesn't get updated until we release again. I suggest building the manual from our git repo. <lfam>We know this is a problem with 0.9.0, so we've added a bunch of reminders to 0.10.0 (not released yet) <lyk>good to hear there's usability updates going on, and not just system development <lfam>Well, we get tired of people having this problem, day after day after day ;) <lyk>I'll try to pay it forward <lyk>I'm learning as I go... <lfam>If you hit that test failure in libarchive again, then please come back <mood>How stable is GuixSD in day-to-day use? I'm currently on Arch Linux, and sometimes hesitant to update packages during hectic times at work/uni. I plan to look more seriously into GuixSD soon, but if it's not yet stable enough I'll hold off a little longer <marusich>mood, FWIW I'm using GuixSD for my daily workstation at home. <lyk>lfam: seems to be the same issue <lyk>will report back in a few minutes <lfam>mood: I think it's very stable once you get it installed. It doesn't have all the features of some other systems yet, but it is stable. For example, if you don't like your system after an upgrade, you can roll-back. <marusich>I think it works quite well. The biggest issue as far as usability are concerned is that there is still some unpackaged software. But it makes up for this with its many features, IMO <marusich>And you can add your favorite packages pretty easily. <mood>Alright, looks like I'll have something to do in a couple of weeks then :D <marusich>Also, Linux-libre does not support all hardware, so it is possible that your e.g. wireless card might not work out of the box. There are ways to work around this, but it's something to be aware of. The newest version of the manual has some information about this. <lyk>I'm installing on a spare laptop, didn't even bother checking if wireless worked, just plugged it in <lfam>The linux-libre kernel doesn't have any proprietary driver blobs, so if some hardware lacks free drivers, it won't work with linux-libre. <mood>Is there any chance of a linux-non-libre kernel in GuixSD, or would it perhaps be easy to package myself should I need it? <lfam>mood: No chance of including it in GuixSD, we are 100% committed to free software. But Guix is easily hackable, so users are free to use it as they see fit, with whatever software they desire. For the common case of wireless driver issues, I recommend buying a USB WiFi dongle that has free drivers. <mood>lfam: Alright, thanks for the help. I'll have to see then <marusich>And you don't have to sacrifice your freedom :) <mood>I see my laptop has Intel Centrino 2230 wireless. I guess that's not supported <mood>"does it work with free software? no" according to h-node, so that's a problem <marusich>Your ethernet card may work also, so you could use that in the meantime while the dongle arrives. <Steap>Do we have an issue with the compile-all build script? <rain1>I wonder if you could have GuixBSD <lfam>Steap: What do you mean? <rain1>just change the kernel in systemconfiguration to bsd right? easy :D <davexunit>(plus a port of the bootstrap binaries and dealing with getting major packages to build) <lfam>rain1: Well, I believe that the Hurd work should help isolate some "Linux-isms". I suppose that would be a first step. But, you'd have to find someone willing to do the work for a non-copyleft system <davexunit>lfam: Guix on BSD would use the BSD kernel, but would still use GNU libc, GCC, etc. ***joachifm is now known as Guest36473
<davexunit>it just requires enough interest, some people to do the hard work, and hardware donations to support building for that platform. <davexunit>it's *possible*, but it needs some serious people power to make it happen. <lfam>davexunit: Do you want to try building kodi on top of the ffmpeg update on the mailing list? Or do you think it's okay to just apply the update? <davexunit>I'll build kodi after you do and tell you if there's problems <Steap>I do have GUILE_LOAD_PATH=/home/cyril/.guix-profile/share/guile/site:/home/cyril/.guix-profile/share/guile/site/2.0 <Steap>GUILE_LOAD_COMPILED_PATH=/home/cyril/.guix-profile/share/guile/site/2.0 <lfam>davexunit: Now if they could just drop that dependency on jasper... <davexunit>lfam: their dependency list is massive and weird <davexunit>honestly I'm surprised that I got the damn thing to build <lfam>Jasper is like a bug generator <lfam>I remember it seemed like an ordeal! <Steap>lfam: well I get the same by just running ./pre-inst-env guix import pypi python-keystoneclient btw :D <lfam>Steap: That part of the code is still beyond me :p I remember some issue with guile-json recently, and it went away after I rebuilt my git checkout of Guix <Steap>we should make this mandatory <Steap>lfam: what do you mean by "rebuilt" ? <lfam>Or, with a ./configure as well <lfam>A bit of a hammer, I admit <lfam>Well, I don't remember if my problem was the same as yours <lfam>I've never needed to set #:out-of-source. Can someone say when it would be necessary? <lfam>Fetching substitutes at 7 MiB/s from my mirror :) <lfam>Yes, it's about 12 inches away ;) <str1ngs>what is the difference between native-inputs and inputs? <davexunit>str1ngs: native-inputs are built for the architecture of the machine that is performing the build, inputs are built for the architecture of the machine that is being targeted <davexunit>generally speaking, things that are used at compile-time should be native-inputs <davexunit>and things that are linked against or used at runtime should be inputs <str1ngs>ah good thanks. so useful for cross building and build time <davexunit>cross building is why we have the distinction <str1ngs>is there some module name spacing that is assumed? <davexunit>str1ngs: the documentation may be different in master <davexunit>the docs on the site are from the 0.9.0 release <davexunit>str1ngs: what specifically are you wondering about re: modules? <davexunit>in Guile, things are indeed split into modules to avoid the issues of a global namespace <str1ngs>Im using guix-0.9.0/doc/package-hello.scm <str1ngs>but the html docs has more module details in it <davexunit>str1ngs: you should use the latest guix in our master branch <davexunit>it's what is about to be released in the next couple of days <lfam>taylan: I am currently working on a synthesis of our nmap package definitions. I spent some time trying to make zenmap work, but no joy, so I'm going to leave it out of my submission. I like your way of installing to different outputs, though. I'll leave that in and when we figure out zenmap, adding it will be easy :) <str1ngs>but the docs example is different in guix.git/doc/package-hello.scm <rain1>it looks like I have to actually edit the C sources of zile to define a custom function <davexunit>str1ngs: yeah that is just a standalone snippet, not in a module <str1ngs>ok I'm not grokking scheme enough yet <str1ngs>hmm weird input python-2 reworked a python shebang but python doesnt <str1ngs>should I be adding that manually anyways? <lfam>str1ngs: I don't understand what you mean. Can you rephrase the question? <rain1>the python package gives a python3 binary <lfam>rain1: Yes, in Guix 'python' is version 3 and 'python-2' is version 2 <str1ngs>if I use an input of python-2 vs python python being python 3 . python-2 reworks the python shebang but python doesnt <lfam>What's the source shebang? <str1ngs>#!/gnu/store/kcc3cxnx9l2hbg7pjhxsa0r5yq2j2f38-python-2.7.10/bin/python is what I get with python-2 <str1ngs>but with python I get #!/usr/bin env python <lfam>What's the shebang in the upstream source code, unmodified by Guix? <str1ngs>no python-2 gets modified but not python <str1ngs>I'll have to check what the upstream is but I'm assuming #!/usr/bin/env python <lfam>That's not optimal. For now I would use substitute* as in python-ipython, and mention it on the mailing list or file a bug <davexunit>this is a case where you have to call patch-shebang manually <davexunit>we can't automatically patch shebangs if there isn't a binary on $PATH with the same name <str1ngs>ah so its the sources configure that changes it <davexunit>actually, sorry, patch-shebang won't do here. you'll need susbstitute* as lfam suggested. <lfam>And our python-3 package doesn't provide a 'bin/python' <lfam>Only the python-2 package has the unversioned binary name <davexunit>(substitute* '("whatever.py") (("/usr/bin/env python") (string-append (assoc-ref inputs "python") "/bin/python3"))) <lfam>Yes, the package does provide a 'bin/python3' <str1ngs>if I substitute python with python3 will it fix the shebang? <lfam>I might be misremembering, but I think the nmap build output picks some ascii art at random to display between phases. So, the build log could be different for each run, if I am right about this. <str1ngs>or best to just substitute the whole shebang? <davexunit>str1ngs: you could do that, too, before the patch-source-shebangs phase <rain1>is nmap the one with the dragon? :D <lfam>rain1: Sometimes! But sometimes there is a different drawing <lfam>Or perhaps I am just looking at different times <rain1>maybe the debian guys have a fix for it <lfam>Fixing that will be the *last* thing I do <davexunit>lfam: that's fine as long as that random ascii art doesn't make it into a file that gets installed into the store <lfam>Right, the build logs go to the localstatedir, right? <lfam>Yes, the build logs are under /var/log/guix on my system <lfam>I want to skip the 'check-ncat' target of the nmap Makefile because it requires the network. Is there a no-op I can use as the body of that target, or should I remove it from the list in the 'check' target? http://paste.lisp.org/display/311695 <lfam>I guess I'll make it echo something like "skipped" <jololo>hey! I have tried the installation a couple times and it keeps failing one test for libarchive-3.1.2.drv the test is called test_format_newc I think. This is on a thinkpad x200. What should I do? <iyzsong>str1ngs: the current practice is to use 'modify-phases' instead of 'alist-*'. also doesn't use 'python-wrapper' (it's python3 with bin/python) substitute it automatically? <str1ngs>unless I can specify use python3 binary other ways patch-python wont find the binary <str1ngs>I'll look at modify-phases aswell thanks <lfam>How do I load modules from the Guix source tree into the Guile REPL? <lfam>I want to try a substitution in the REPL <lfam>So, I think I need to load guix/build/utils.go <lfam>Oh, right, I have to start guile with ./pre-inst-env <lfam>I'm pretty sure you told me that the last time I had this question :p <mark_weaver>alternatively, (set! %load-path (cons "/path/to/your/guix/git/repo" %load-path)) <mark_weaver>doing the same for %load-compiled-path might be good too <lfam>That's what the GUILE_LOAD_COMPILED_PATH and GUILE_LOAD_PATH are doing in ./pre-inst-env? <mark_weaver>note the ~/.guile is loaded when running a guile REPL, so you could also put the %load-path and %load-compiled-path commands in there if you want <lfam>I might start doing "the hard way" by hand so that I remember it <mark_weaver>see the geiser-guile-init-file and geiser-guile-load-init-file-p variables <lfam>I'm not using geiser yet. I know I'm missing out... geiser sounds really nice. <mark_weaver>to be honest, I'm in the same boat. still using stone tools :) <lfam>No, you are at least using Emacs. I am not even using an editor that understands s-expressions. I have to use a Vim plugin to help with that. <mark_weaver>ah. yeah, I was a vim user for many years, but it kinda sucks for lisp dialects. <lfam>When I watch video presentations on Guix, I really feel like a cave man <mark_weaver>for years, I went back and forth between vim and emacs, but since being a schemer, I've settled on emacs and can't imagine ever going back to vim. <mark_weaver>(although I still use vim sometimes for quick edits, e.g. from root shells) <lfam>One day I will switch. I can only learn so many things at once :) <mark_weaver>fair enough, I can sympathize. hence the reason why I'm not yet using geiser regularly <dmarinoj>When I watched the "Emacs of Distros" I was sold on GuixSD <lfam>jololo: Use herd instead of deco <lfam>The online manual refers to version 0.9.0, so there may be a few inconsistencies like that. <lfam>We replaced the deco tool with the herd tool since then <jololo>awesome thanks lfam! will report back with how the install goes <jololo>lfam, when population /mnt I get a warning about ext2 not supporting embedding and that GRUB failed to install. <jololo>I have 2 partitions on /dev/sda : /dev/sda1 as a system partition with 20GB and /dev/sda2 as a data partition for the rest of the disk. <jololo>This was my first time using parted so I don't know if I messed something up there <jololo>It says GRUB can only be installed in this setup by using blocklists and then they say blocklists are UNRELIABLE <iyzsong>jololo: make sure yo use '(grub-configuration (device "/dev/sda"))' to install the grub into the MBR. <jololo>ah! that's it, I didn't see bootloader, I thought it was asking for the partition <iyzsong>Yes, unless you want to chain load it from an existed bootloader, in that case you may want to use "/dev/sdaX" as 'device'. <jololo>I'm still getting errors with GRUB and I think it is due to not having my partitions right and in the config.scm correctly. <jololo>In the config, I have the bootloader set to /dev/sda and the filesystem device (what I had to replace my-root with) as "/mnt" <jololo>Should I just repartition? I haven't since trying multiple times with 0.9 so there may be conflicting things on /mnt/ <lyk>replace my-root with root, and run fdisk -L root /dev/sda1 <jololo>lyk, thanks! gotta sleep, gonna run this and see how it work. I'll report back tomorrow <str1ngs>my wifi card has non free firmware :( <efraim>mine too, and my spare, and my spare wifi dongle <efraim>and I think if it's possible to have a non-free firmware ethernet port then I have one of those also <str1ngs>will I goto hell if I build my own kernel? <str1ngs>is there a user devel group for linux-header glibc gcc:libs gcc binutils? <janneke>if you're unaware that it's bad, then there is no problem ;-) <str1ngs>does guix even have a notion of groups? <janneke>str1ngs: guix+linux has, see the manual <str1ngs>get tedious piecing it together . but I can make a script I guess <janneke>i just do: guix environment package-name <janneke>what about something like: guix environment --ad-hoc ccache emacs gcc git <str1ngs>I work on C files and I have things I build on a regular basis in HOME <janneke>make that: guix environment --ad-hoc ccache emacs gcc-toolchain git <str1ngs>gcc-toolchain might be whatI need thanks <lfam>From the configure output of our tcpdump package: <lfam>checking whether to enable the possibly-buggy SMB printer... yes <lfam>configure: WARNING: The SMB printer may have exploitable buffer overflows!!! <lfam>Anyone ever looked into that? <ziz15>is there a way to download gnuixsd as an iso file to burn it or even to convert it to an iso??thanks <efraim>you can dd it to a usb stick as it is <ziz15>efraim: i d like to convert it to an iso so i could try it inside a vm <lfam>ziz15: Guix (the package manager) has tools built in to virtualize GuixSD in QEMU <lfam>ziz15: See the section of the manual "Invoking guix system" <lfam>The current version of the manual (in the git repo) has a section on how to create and boot a standalone GuixSD system in QEMU <lfam>I've been meaning to document how to install GuixSD in QEMU. Soon... <rekado>I want to play with GRUB parameters and LVM. Is there a way to do this in qemu? Or will I have to reboot my machine all the time? <ziz15>hi i am installing guixsd inside a vm right now..i'd like to ask: does it take so much time to installed the os?i mean it downloading packages for almost 2 hours now and keep downloading..thanks <efraim>did you run guix pull before you started? <efraim>if you pass the option --substitute-urls=mirror.guixsd.org it should go faster <ziz15>efraim: no i just do what the manual say <efraim>there's been a couple of changes since 0.9.0 was released <ziz15>efraim: i part the disk then deco start-cow store <efraim>unfortunately the manual online is only updated when there's a release <efraim>so before guix system init run guix pull <ziz15>efraim: so should i stop it? <efraim>and then with the `guix system init` command add the substitute-url option <efraim>guix pull will pull down the new package definitions <ziz15>so after i do deco start-cow store i create a /etc/config.scm inside /mnt/ect and then do what you say right? <ziz15>efraim: so after i do deco start-cow store i create a /etc/config.scm inside /mnt/ect and then do what you say right? <ziz15>hi one question after i start cow-store on mnt(mount /dev/sdX /mnt before) i edit /etc/configuration/bare-bones.scm or copy it inside the /mnt/etc directory after i create etc dir? <rain1>after setting up mounts, cow store is the first thing you should do <rain1>yeah, copy it into /mnt/etc and edit it <ziz15>rain1: so i do first cow-store and then mount root on /mnt? <rain1>mount root then do cow-store <ziz15>rain1: i see that /etc dir is not under mnt so i create it right?i havent done something wrong? <ziz15>rain1: i try to try guixsd the last 3-4 hours man.. <rain1>yeah it can take a long time :[ <ziz15>rain1: yeaaaaaaaaaaaaaahhhhhhhhhhhhh :) <jmarciano>bzip2: Compressed file ends unexpectedly, what to do when packages cannot be loaded? I tried to install lsh as root, while as user I already have it. <efraim>it's likely corrupted on hydra, add --fallback to the comman <jmarciano>hmm, it fails only for linux-pam, ok, I will try <jmarciano>anyway I like compiling, building approach, it is more trusted, packages come from source locations, not just from single distribution point. <jmarciano>It does not make absolute security, it increases security though <jmarciano>Now I got lsh, after --fallback to linux-pam, this is great <ziz15>So after create the /etc/config.scm i run guix system init /mnt/etc/config.scm /mnt and wait till its done right? <rain1>if it fails from network problems you can continue it by rerunning <ziz15>rain1: about three hours ago i was done the same steps and for 2 hours it was just downloading packages <ziz15>rain1: when i ask someone here he told me to first run guix pull <ziz15>rain1: so??what should i do? <rain1>make and edit system configuration <rain1>guix system init /mnt/etc/config.scm /mnt <ziz15>rain1: and the oscar goes to ..rain1 <ziz15>rain1: man in four lines you install the #@* OS <ziz15>and i have two years with arch <rain1>I came here from arch linux too <davexunit>ziz15: sorry about the bumps in the road. our upcoming release (coming in the next couple of days) will have improved installation instructions. <jmarciano>that is great, and pity that I did not install this beta yet... <ziz15>davexunit: No need for sorries man.i mean you working on something good and every start has its S#$!ts..keep up the good work <davexunit>that's the right expectation to have at this point. cool stuff with rough edges. :) <davexunit>"snaps" are configured using a YAML file. :/ <davexunit>using the usual "it's just plain text!" messaging <davexunit>you will notice a number of similarities between Snappy and Guix <davexunit>I'm biased, of course, but I think Guix clobbers Snappy in pretty much every way. <davexunit>but we aren't Ubuntu, so we'll remain niche while Snappy takes off like crazy. <janneke>ACTION waits for the day that alists become plain text <wingo>ACTION waits for the day that gnome-keyring works in guixsd <janneke>"{"a":true,"b":[2,3]}" <-- simple & plain text <janneke>((a . #t) (b . (2 3))) <-- scary parentheses that are impossible to match <jololo>Hey! My install is still failing when installing GRUB with the error saying "this GPT partition label contains no BIOS boot partition" I'm sure I messed up something with partition my hard drive. If I want 2 partitions, one small one for the root/system parition and a big one for videos/music/etc how do I properly set that up with parted? I thought I did it correctly the first time but install keeps giving me problems so I think I should <wingo>jololo: did you mark your main partition as a boot partition? <wingo>ACTION feels stupid every time he has to open parted tho <jololo>probably not! how would I do that? <iyzsong>jololo: an extra BIOS boot partion is required by grub to install on GPT. you need create it. <iyzsong>jololo: 1M is enough, also you can use fdisk too (I found it easier than parted). <iyzsong>jololo: in fdisk, after create it, type 't' to change the partition type to '4 BIOS boot'. <jololo>so in my case, where I want a system partition and a data partition, I would need 3 partitions? One for booting, one for the system and one for my data? It would look like /dev/sda1, /dev/sda2, and /dev/sda3 is that right? <jololo>and where should I partition these? Like I said I <jololo>'m new to parted and have only really used fdisk to list partitions. <jololo>Where should these partitions start and stop, assuming I'm using parted's mkpart command? can/should the boot partition start at 0%? And how big should the system/root partition be? Or do I have this all wrong? <iyzsong>I think 'sda1: 1M, bios boot (no mount point). sda2: 10G+, ext4, root. sda3: ext4, home' should be ok. <iyzsong>jololo: I don't know how to calculate the start and stop for parted, but if you can erase the whole disk, I think use fdisk is the way. <davexunit>wingo: I want gnome-keyring to be gone so I can use gpg-agent. I haven't done it yet, but I plan to just remove gnome-keyring from the gnome metapackage. <davexunit>that damn autostart .desktop file means that when I start my computer I have to kill gnome-keyring and then start gpg-agent <iyzsong>you can remove it for youself using a custom inherited gnome package. I don't think we should remove it from gnome :-) <davexunit>I think we should still fix gnome-keyring for everyone else :) <davexunit>gnome-keyring frightened me when I saw JS backtraces for it in a log <jmarciano>snappy may be good idea, but I support GNU + GuixSd <jmarciano>and seems like Guix is anyway far more advanced <ng0>hi :) can someone reply to my most recent message (sent some minutes ago, so it might take some time to arrive at you) to the gnunet.scm patch thread? <efraim>snappy looks like bundled dependancies to me <davexunit>I was hoping this show would talk about guix some more, but they just mentioned it very quickly in a list of other software <efraim>I don't think they really know what to do with it <rain1>I would test gnu net if I knew what to do <efraim>there was an episode on nix a while ago, must've been almost a year now <ng0>well it is tested. and noone commented on coding style. it's just that I'd like to have some kind of status after 3 weeks <jololo>iyzsong, wow fdisk is amazing! first time actually using it (not counting "fdisk -l") <jololo>I did the type for the BIOS boot but it said it would remain unchanged. Does it default to that type or is something wrong? Also does it default to making ext4 on the partitions or do I have to that with mkfs or something else <lyk>mkfs.ext4 -L LABEL /dev/sdaX <jololo>Okay I think I'm ready to try installation again. How do I specify that I want /home to be on /dev/sda3? Do I do that post-install? <rain1>- or tell me that I should resubmit all of them individually <rain1> because that's easier / quicker to test? <rain1>you should just post a file gnunet.scm <ng0>I just changed lots of its code <ng0>the nature of a version vo <ng0>control system requires that <ng0>if you want to, if I get no status reply this week, i'll put it all into secushares git and then you could test it there <rain1>were multiple files changed? <ng0>it will be there anyhow, but having -svn (and a recent gnunet) in master of guix would mean a shorter file <rain1>why not past that whole patched file to paste.lisp.org? <ng0>because i don't keep branches around for 3 weeks <rain1>I don't know what that means <ng0>i work with branches, every time i work on something it gets a new branch <ng0>when I post the patch, 3 weeks are a reasonable time to assume that it's no longer necessary to keep around <ng0>in this case apparently not <ng0>just wanting some kind of status on the gnunet.scm patch, that's all <davexunit>ng0: have you pinged the mailing list about it? <davexunit>we receive a lot of patches, so it's difficult to get to everyone in timely manner. <davexunit>especially if the patch is big or has other complications <ng0>i got one or two replies by civodul, that's it. because it wasn't content related I assume the style is okay. <ng0>*wasn't coding style realted <rain1>I'm offering to help test the patch, which you requested on the ML, but then you said "it's tested" <davexunit>would be good to make sure that it still applies and builds on the current master branch <ng0>for me it works, for jookia it works, apparently also someone tested it (see related bug on the bugs list) <ng0>I can get the patch and rebase it <ng0>and if it is easier, I can do small patches this time. it affects the whole file what I do <davexunit>I read the thread, and it seems like the major issue was that gnunet is unreleased software <ng0>i saw no issue there <davexunit>has that been resolved outside of thie list? <davexunit>okay, civodul seems to have made an exception here. <ng0>you can also see in the thread (or early gnunet related threads) why there will be no more early gnunet release candidates. i understood christian that it's just the matter of 1 bigger fix and then smaller fixes can be applied very fast, and then the next release can be made <ng0>i'll send in a series of small patches of what currently is this big patch, but it can take some time for all patches to finnish and send, i hjave a cold atm ***exio4 is now known as init
***init is now known as y
***y is now known as hacker
***hacker is now known as exio4
***joeyh_ is now known as joeyh
<janneke>ACTION has tried about 20 different things today to take cross-compilation beyond the `hello' package. nothing worked :-( <civodul>an example that works: guix build --target=mips64el-linux-gnu hello -n <civodul>oh but you said "beyond hello", you're demanding ;-) <janneke>civodul: to my new --target=i686-w64-mingw32 <janneke>as soon as i add a single input to hello, eg: (inputs `(("sed" ,sed))) <civodul>this one is more involved because it's a different libc <janneke>either: @ build-started /gnu/store/ir0xpyhm82ym3p1mf30gnsfwcy15aj1k-gcc-cross-sans-libc-x86_64-linux-4.9.3.drv - x86_64-linux /var/log/guix/drvs/ir//0xpyhm82ym3p1mf30gnsfwcy15aj1k-gcc-cross-sans-libc-x86_64-linux-4.9.3.drv.bz2 <janneke>that's the default...or, when i try to tweak standard-cross-packages, i get <civodul>but you managed to cross-build hello? <janneke>@ build-started /gnu/store/xd1xbny249y38l85zsxz37zvnpzfb2fp-make-boot0-4.1.drv - x86_64-linux /var/log/guix/drvs/xd//1xbny249y38l85zsxz37zvnpzfb2fp-make-boot0-4.1.drv.bz2 <janneke>civodul: yes, hello.exe runs fine in wine :-) <civodul>ok, that's already quite an achievement :-) <civodul>the "x86_64-linux" in the derivation name is definitely fishy <janneke>"something with dependencies/needing glibc" <civodul>maybe the wrong libc is picked up or something <janneke>something like that, i tried a lot of things <civodul>cross-building to GNU/Hurd as phant0mas did raises similar challenges <janneke>it wants to build a x86_64-linux -> x86_64-linux cross compiler, buth then without libc :-/ <civodul>i can investigate more, but not until after the release <phant0mas>this is a first, my irc client crashed when I got a ping <janneke>civodul: i would be *very* pleased if you could help/chat with me after the release, and i'd be very happy to provide any help you may need with the release <janneke>ah, talking to phant0mas may be a good idea too <ng0>sneding patches finished. I based it all on the same branch, so I hope this works. better start going from 1 to 4 <phant0mas>ACTION trying to catch up with the conversation <mark_weaver>civodul: while testing some grafting patches (wip-graft-improvements branch), I've noticed some problems with the existing grafts code <rain1>phantOmas, did you write the client? <mark_weaver>the other is that my attempt to avoid duplicate grafts failed, and ultimately it's because, e.g. I end up with two separate graph derivations for python-3, one that includes graphite2 as an input, and the other does not. <mark_weaver>graphite2 is not actually a runtime dependency of python-3, but it is one of the things that's grafted in the system I'm running (from before the security-updates merge) <mark_weaver>I guess maybe I should push something close to the private branch I'm testing this on, so that you can reproduce the issues. <phant0mas>janneke: from what I understood you want to crossbuild packages for mingw32 linked to newlib, am I correct? <janneke>phant0mas: yes, i have built mingw-w64 newlib and cross toolchain <janneke>i cannot build packages that have (inputs), though <janneke>when i add this to hello: (inputs `(("sed" ,sed))) <janneke>i get: @ build-started /gnu/store/ir0xpyhm82ym3p1mf30gnsfwcy15aj1k-gcc-cross-sans-libc-x86_64-linux-4.9.3.drv - x86_64-linux /var/log/guix/drvs/ir//0xpyhm82ym3p1mf30gnsfwcy15aj1k-gcc-cross-sans-libc-x86_64-linux-4.9.3.drv.bz2 <rain1>Where to learn about grafting? <janneke>so, it starts to build a x86_64-linux -> x86_64-linux cross compiler, without libc... (that fails ;) <janneke>phant0mas: my hunch is that standard-cross-packages is the culprit <janneke>phant0mas: great, make sure you have the latest <mark_weaver>civodul: I just sent a followup to that bug report, with the contents of the guile-builder script <ng0>i'll be afk again. good day o/ <lfam>rain1: And you should also read the commits where OpenSSL and Perl were grafted <lfam>And also the grafting code itself :) <mark_weaver>rain1: I'm not sure if we have a good description of the theory behind it written up anywhere <lfam>I thought the announcement on Savannah was a good overview <rain1>I will read these and learn more and ask if I get some questions, thank you ! :)) <df_>I'm struggling to understand how/where it's defined how to install a package into a profile (ie what to symlink and where) <rain1>I am curious how grafting will interact with the shadowing issue I posted to the ML about <df_>is it just implicit, eg things in bin in the package derivation are linked into bin in the profile? <phant0mas>janneke: I will build it to reproduce it on my machine <df_>or are there rules defined somewhere that I haven't found? <mark_weaver>but the basic idea is that if we want to replace glibc with a fixed version, we build everything with the bad glibc (which was already done on hydra), and then we build the new glibc, and then for every store item that contains references to glibc, we create a new store item that's the same of the original, but with all references to the old glibc rewritten to point to the new one. <mark_weaver>but it's a bit more complex because of indirect references. <phant0mas>guix needs some work on targeting non glibc systems ... <mark_weaver>let's say you have store item A that references B which references OLD-GLIBC. <mark_weaver>so, you need to make GRAFTED-B that is like B but with references to OLD-GLIBC replaced with references to NEW-GLIBC. <mark_weaver>and then you need to make GRAFTED-A that has references to B replaced with GRAFTED-B <mark_weaver>anyway, it's all still deterministic, no store items are ever mutated. you can still roll back to ungrafted versions, etc. <rain1>so when I try to use A how does it know to pick the grafted version rather than the previosu? <mark_weaver>well, store item A will continue to use the old GLIBC <mark_weaver>but when you ask to build the package associated with A, it will look through all the dependencies, and if any of them are grafted, it will know that it needs to make GRAFTED-A and that will be the result of the build. <mark_weaver>you still need to update your system, just as you would if glibc had been updated the old way. <mark_weaver>it's just that the update is a lot faster, because the only thing that needs to be done is to rebuild glibc and then do find/replace operations on eveyrthing else <rain1>what I don't really understand is, say I have a package foo which gives /bin/foo and I run 'foo' to use it <rain1>but now suppose that was grafted, would there be two version of /bin/foo in the store? <rain1>when I run 'foo' how can guix tell that it should run the grafted one? <davexunit>rain1: that's not the time that guix figures that out <davexunit>it's when you build the package that provides foo <mark_weaver>rain1: grafting does not mutate anything. it doesn't change any existing references. <mark_weaver>e.g. if your profile points to the old package 'foo' with a vulnerability, then it will still continue to do so until you update it explicitly. and then the updated version will be a new store item. the old one will still exist until all references to it are gone and it is removed by the garbage collector. <civodul>or what mark_weaver explained, actually :-) <lfam>civodul: I can try the change you suggested <optikalmouse>is it possible to use Guix as a replacement for things like Ruby Gems or Python PIP or Node.js NPM? <davexunit>optikalmouse: yes, many of us are working towards that goal. <paroneayea>optikalmouse: yes re: ruby and python, not yet re: npm <davexunit>civodul: should I try to push that nginx service thing before the release or just wait until after? <mark_weaver>civodul: I just sent another followup to https://debbugs.gnu.org/23132 which instructions on how to easily reproduce the problem on your machine, using the commit on 'master' immediately before the 'security-updates' merge. <optikalmouse>paroneayea: okay, because I was thinking of forking npm and patching it to be decentralized <optikalmouse>but when I saw that guix uses scheme, it wouldn't be hard to code up some package.json parsers <davexunit>npm and guix have different target audiences <mark_weaver>maybe it's related to the fact that the missing replacement for gnome-session is a "bin" output and not the "out" output. <rain1>optikalmouse, I think there is a google summer of code project to do exactly this <davexunit>guix isn't going to work on OS X and Windows <rain1>btw guix isn't decentralized <davexunit>rain1: but it doesn't have a single point of trust <davexunit>which is a pretty notable difference with npm <davexunit>optikalmouse: rain1 is right that we have a GSoC project to help bring node packages to guix. <mark_weaver>rain1: it's only centralized if you use the default substitute server and the default "guix pull" URL. <davexunit>I am mentoring it, as well as paroneayea here. <rain1>optikalmouse, did you see the new golang package manager gx <mark_weaver>(and both of which can be avoided entirely. I never use "guix pull", and on one of my machines I never use substitutes either) <optikalmouse>I'm looking to make sure our server deploys of node.js apps are solid; I couldn't care less about whatever OS X or Windows dev envs people have for node <mark_weaver>I also run guix on my own branch, on all of my machines. <optikalmouse>we had breakage from that idiotic left-pad package issue on our GNU/Linux servers <davexunit>optikalmouse: guix could be a good fit for your use-case, then. <rain1>optikalmouse, left pad is fine, the problem was npm forcibly removing peoples authorship and giving it to someone else <davexunit>currently we lack the build system and importer to support packages built with node <lfam>I think the problem is the mutability of the dependency graph when using NPM <rain1>lfam, I saw you packaged signify! do you have a plan with that? <lfam>rain1: No real plan. It would be nice for confirming things on IRC, because of the very short signatures <rain1>I also packaged libbsd for something else, i hope that gets into the tree <lfam>Yeah, I don't see why it wouldn't <lfam>Did my package make sense to you? Was yours different? <kyleschmidt>Has anyone successfully installed GuixSD on a Macbook? <optikalmouse>davexunit: indeed, I'm wondering whether to throw some dev time at guix for supporting nodejs/npm or to try and decentralize the existing npm crap (by hosting mirrors and/or making it easy to setup private repo-hosts) <jololo>Still having install problems. If i set the 1M partition to /dev/sda1 should I put /dev/sda1 or /dev/sda in the bootloader field for config.scm? <davexunit>optikalmouse: yeah, I'm not sure what would make the most sense for you. <optikalmouse>davexunit: we're also using Docker at work and it would be nice to not use it ;P <davexunit>long term, I believe Guix will be a huge win. short term, perhaps hacking npm will be quicker. <rain1>you could hack gx to support npm instead of golang <jololo>rain1, hmmm... I'm still getting GRUB install problems. What should I be testing for errors? <rain1>i don't know - i used DOS partition type, what did you try? <jololo>I'm using GPT. should I try DOS? <rain1>I couldn't say but personally I had sucess with dos, then cfdisk and make it bootable <rain1>someone else might know more about this <rain1>but I think 1 megabyte is too small <str1ngs>jololo: I used --no-grub then installed grub by hand <jololo>str1ngs rain1 iyzsong wingo et. al. Thank you so much everyone! finally got it. I thought I made /dev/sda1 bootable but I actually didn't. Install finished and working! yay! <jololo>Okay where to go from here? I have only really read the install instructions... <jololo>Also this is on an x200. How do I get wifi working? <rain1>did you do barebanes or desktop install? <jololo>"lscip: command not found" and I am unsure. I think it's on thinkwiki, lemme check <mark_weaver>jololo: the wifi card that comes with Lenovo X200 requires nonfree firmware. <mark_weaver>jololo: I recommend flashing Libreboot and then replacing the wifi card with an ath9k-based card <mark_weaver>libreboot.org contains instructions for how to do it, and the folks on #libreboot can also help <mark_weaver>the resulting laptop is the best thing we have right now in the free world. <jololo>Flashing Libreboot is a non-trival task, no? I was at libreplanet and it seemed to require accessing the motherboard, right? <mark_weaver>jololo: the first time you flash, you need to do so with an external programmer, yes. <mark_weaver>so you need to get to the flash chip and on it connected to an external programmer. a BBB (beaglebone black) is the recommended method. <rain1>Is there a list of small board computers like BBB which guix runs niecly on? :) <rain1>How does guix relate to the debian reproducible builds project? <jmarciano>I guess in some short time, Debian will be past GuixSD in that regard. <bavier>rain1: it's a cooperative relationship <mark_weaver>there was a meeting in Athens on this topic with representatives from several projects attended, including people from Debian and Guix and others. <rain1>Steap, you used , but don't have any ' ? <civodul>davexunit: it's ok to wait for after the release <civodul>mark_weaver: i'll look at it, but we might fix it after the release <rain1>this json library isn't nice <janneke>(scm->json-string '(((foo . 1)) ((foo . 2)) ((foo . 3)) )) <janneke>$1 = "[{\\"foo\\" : 1}, {\\"foo\\" : 2}, {\\"foo\\" : 3}]" <rain1>implicit quasiquote is very confusing <mark_weaver>yeah, davexunit came up with a different json API which we are planning to integrate into guile itself. <davexunit>civodul: is it okay if I commit a hack to handle the /etc/resolv.conf symlink case so that 'guix environment --container --network' isn't broken for 0.10.0 and then we'll continue to investigate the root cause going forward? <Steap>janneke: yeah, but I expect to have some of the objects to be returned by a function in a real-world scenario <davexunit>civodul: not sure if you saw my follow-up on the ML, but I am able to reproduce it by bind mounting any file from a tmpfs. <Steap>mark_weaver: yeah, I was some old thread about (ice-9 json) <janneke>Steap: i just don't see the (json ..) (array ..) (object ..) thing <davexunit>sorry for delays on that, I was feeling demotivated. <Steap>janneke: it is a list of hashtables <mark_weaver>I still have pending patches for guile that have been sitting around for years <davexunit>I have some potential changes I want to make to the format. I'm unsure if I want to use symbols or strings for keys in JSON objects <mark_weaver>terrible. I'm perpetually overloaded and too much of a perfectionist <janneke>or alists directly...it's just that you use the json/object/array constructs in your pastebin <Steap>janneke: well, I was under the impression that I had to do that <davexunit>and if symbols are allowed only in object keys, I can distinguish objects from "arrays" without the use of the special '@' character. <janneke>json is just a form of less-expressive s-exps with many differenc characters <janneke>davexunit: exactly, i recently submitted a patch to json to handle that <civodul>davexunit: ok for the hack while waiting for a better fix <Steap>janneke: is that from (rnrs hashtables) ? <davexunit>you haven't made the tag yet, right? I'll be working for a few more hours before I can get the patch in. <janneke>(define (hash-table->alist table) (hash-map->list cons table)) <janneke>ACTION used hash tables until he realised they're just inefficient a-lists <paroneayea>* janneke used hash tables until he realised they're just inefficient a-lists <paroneayea>janneke: hash-tables are far more efficient for larger datasets <davexunit>they're inefficient in most cases where people use hash tables <davexunit>citation: the common complaint of not having hash-table literal syntax. <ijp>that reminds me, did we ever start giving errors for mutating literals? <wingo>ijp: no, sadly -- that might require a sigsegv handler <janneke>paroneayea: i think alists outperform hash-tables until size ~100? <rain1>yes alists win on small sizes <ijp>that number gets bigger every time I hear it <rain1>hash tables win in the limit <janneke>we are talking about json messages, my use case has key size of about ~10 <ijp>wingo: I didn't think so <wingo>ijp: yeah i can imagine many cases that wouldn't catch... you're prolly right <janneke>and alists print and read much prettier than ,#(..) <davexunit>hash tables win on large collections but they aren't persistent <davexunit>we need persistent hash tables in guile core (that aren't vhashes) <rain1>tries can work pretty good as persistent hashes <rain1>you only have to replace the spine when doing an insert <rain1>ACTION has scheme code of this <rain1>"Shared reproducibility issue database" great :D <janneke>but then also more sensible way of reading+printing than srfi-10 <optikalmouse>you can add your hash literal syntax, but you can never take my SRFI-10. <janneke>srfi-10 is a beautiful hack, until you want to pretty-print long hash tables <rain1>I made a guix package for MAME, what do you think? <rain1>it took a bit of hard work :) <rain1>I can make a patch for it off games.scm <davexunit>civodul: I didn't get my fix in yet. oh well. <davexunit>I haven't had a chance to commit because I'm at work <optikalmouse>rain1: yah as in comment on what each directive does and link to the manual <wingo>maybe guix should do time-based releases! <rain1>oh, if you want to do that i'll wait and include it when I send a patch! <davexunit>I'll push the hack to master when I can, but now there's no rush. <davexunit>rain1: also, use modify-phases instead of alist-replace and friends <rain1>it's nice they merged mess in, so you just get one binary 'mame64' <davexunit>rain1: and instead of deleting the 'check' phase, just disable tests with #:tests? #f <rain1>ok! adding these changes now <davexunit>rain1: I'm surprised that there is really only one file. what about docs, images, etc.? <davexunit>rain1: do they really not have an installation script? <davexunit>optikalmouse: (use-modules (module name) ...) <davexunit>unless you're talking about #:use-module with the 'define-module' form <optikalmouse>just wondering if there's a way to compact that gigantic list of modules in mame.scm <davexunit>that list is copied from another module, they aren't all needed for MAME <optikalmouse>....wouldn't it be possible to also just use a macro? (defpackage '(a b c d...) ....) => (define-module (rain mame) #:use-module (a) #:use-module b ....) <jmarciano>we shall not encourage people to use non-free software <davexunit>jmarciano: mame doesn't come with any nonfree software <davexunit>and AFAIK nor does it recommend nonfree software for you to use. <jmarciano>so how to play games with free software and using mame? <davexunit>optikalmouse: I don't see how that improves anything. <ijp>optikalmouse: sure, but then you still need a use-modules before your define-module to pull in that syntax <jmarciano>all of MAME ROMs are basically not free. Including MAME gives incentive to people to use non-free software. While so many GNU GPL games are not included. <davexunit>that's not true. emulators do not violate the GNU free software distribution guidelines <jmarciano>So functional software MAME requires non-free ROMs. <jmarciano>give me argument, not only no. I used MAME before and I know there are almost no free software ROMs. <davexunit>the user may run free or nonfree software with MAME, just as they can with WINE <davexunit>the bottom line is that emulators *do not* violate the GNU FSDG <jmarciano>Well, cite: "To establish lasting freedom, just giving users freedom isn't sufficient. It is necessary also to teach them to understand what it means and to demand it." <davexunit>for example, PCSX, a playstation emulator, relies upon the user providing a dump of the Playstation's boot firmware in order to run. <jmarciano>if software does nothing but asks users to load non-free software, that is opposite to "demanding to use free software". <jmarciano>I am not sure what my virtual richard stallman would say for that... <davexunit>it's not asking the user to load nonfree software. <jmarciano>I would never include MAME in GuixSD, as I am using it because of principles above stated in that demand. <davexunit>an emulator will run any executable compiled for the machine that it is emulating. <jmarciano>but obviously I am not boss here so someone else will incite all the children and youth to use non-free ROMs, by including MAME in GNU distribution <jmarciano>take some time and reconsider that well. That is not free software spirit. <davexunit>there are hobbyists that make "homebrew" programs, some of which are free software, that target these antiquated machines. <davexunit>providing an emulator is not an enticement to run proprietary software <jmarciano>that is now analogous to Debian non-free thing. Sorry I don't agree <davexunit>providing an emulator that presented a prompt to download and instruct users to run nonfree binaries would be a problem <davexunit>anyway, if you think this is a problem, you should petition the FSF. they produced the FSDG <ijp>I bet the people on #scummvm are tired of this sort of argument by now <davexunit>jmarciano: does providing WINE in Guix present a freedom problem? <jmarciano>I don't care, this is free software distribution. <davexunit>many of us have given thought to this exact problem <jmarciano>or let us say this way, I am user of free software. I don't feel that including wine, mame or any kind of emulator that requires for functional software usage some kind of non-free -- that this kind of distribution does not respect me as user. <davexunit>does anyone know if the GNU website explains the emulator situation? <paroneayea>I recently had a friend use Wine to run an old copy of Blender <rain1>I've added the style improvements! thank you for the feedback <paroneayea>because he couldn't get the ancient version of blender to load in any modern gnu/linux distro <paroneayea>now that's also a static vs dynamic linking question I guess partly also ;) <rain1>mame is statically linking many many libraries it builds during the process <paroneayea>and even one that was for all free software purposes <jmarciano>I don't use wine -- if wine requires ANY non-free library or non-free software for ALL software runs, it should not be there. <wingo>wine is useful too for testing windows cross-builds <jmarciano>practically: 1 person will use blender, 1000 persons will use non-free software with Wine. Wine should not be there. One person can make Wine separately. <rain1>but it doesn't include any firmware or ROMs <rain1>it's purely implementations of CPUs and arcade machine hardware descriptions as source code <ijp>jmarciano: I think you are moving the goalposts <rain1>MAME's purpose is to preserve decades of software history. As electronic technology continues to rush forward, MAME prevents this important \\"vintage\\" software from being lost and forgotten. This is achieved by documenting the hardware and how it functions. The source code to MAME serves as this documentation <jmarciano>yes, sure, but MAME shall not be part of GuixSD. <jmarciano>because if I am to open games for my 3 children, and don't know about software, I will run using MAME and load non-free ROMs, as simple as that. It gives incentive to use non-free software. <ijp>jmarciano: it's fair to argue that emulation will encourage people to use existing non-free software for the emulated platform. It definitely does happen. Most of the disagreement you are getting here is that it *necessarily* involves the use of non-free software, which is false <bavier>obtaining non-free ROMs is typically non-trivial <rain1>what is the scope of the guix packages tree? <rain1>I sorta want an "AUR" type thing <rain1>instead of everybody having their own personal pkgs repo <jmarciano>I never said it involves "non-free software", I am speaking of demanding, demanding is not including MAME in such distribution. <jmarciano>To demand from someone to use free software means making MAME package with explanation "There is no MAME here because you would be using non-free ROMs, look elsewhere" <ijp>strengthening the adjective doesn't reverse the conclusion <jmarciano>So far I am done on that subject. Only without MAME and other emulators, or whatever is asking for non-free, GuixSd will be non-free. <rain1>what about the freedom to play pacman? <bavier>jmarciano: I'd like to reiterate davexunit's suggestion to take the issue up with the FSF, since it's something that affects not just GuixSD, but all other distributions who follow the FSDG <jmarciano>sadly in GuixSD there is no principle of what is priority. I cannot see priority including MAME, just to fulfill the quota of number of packages. <jmarciano>I did, waiting for the answer. And will continue paying to GuixSD. <rain1>I think a better reason not to include it is detracting time and bandwidth from the build farm, it's a pretty serious build and a large download <bavier>great, I look forward to their response <ijp>I don't see them forbidding it, any more than they'd forbid writing proprietary software in emacs <rain1>any more style improvements or other suggestions? <civodul>jmarciano: i don't understand what you're saying about priorities in Guix <civodul>jmarciano: instead of making assumptions about what Guix as a project is doing, please email guix-devel@gnu.org <jmarciano>when a developer of GuixSD puts ANY attention rather on MAME, which does incite people to use non-free ROMs, but not otherwise on numerous games available under GPL, that is OUT of priorities in regards to software freedom. <civodul>but look: this discussion has already taken more time than that about MAME itself <jmarciano>Or put yourself in my point of view, I am free software user, how I am going to use MAME or have any use of it? <civodul>i don't know about MAME, i know that Wine (i was skeptical at the time) can be used for very legitimate purposes <jmarciano>well I am done, I don't want to disturb any more. But issue is valid and certainly not solved. <civodul>but i think bavier is right, this should be discussed with other free distro people <civodul>like on the gnu-linux-libre mailing list for instance <civodul>i'm interested in reading what others think about it <rain1>I think MAME/MESS is an important history/preservation project <civodul>i guess it might be useful from a reverse-engineering viewpoint <jmarciano>I would leave history for historians. This is free software distribution, not conservancy project. <rain1>but really I wonder if /packages/ would not be improved by splitting it into a smaller "core" and then extra things like games/multimedia/networking <bavier>classification is tough; we already have a tough time with module organization. I don't think we want to get into the organization business for the website as well <rain1>alright! I just feel sorry for the build server.. <bavier>rain1: I see, you mean the build side. <bavier>there are more powerful solutions in the works <lfam>gnu: guix: Update to 0.10.0.