IRC channel logs


back to list of logs

<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?
<lyk>one sec
<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
<lyk>trying that out now
<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
<lyk>ah, alright
<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
<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 issue (see the logs), and it seems as though their ftp has been decommissioned: <>. 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 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>marusich: Cool :)
<lyk>yeah, I don't see it here
<lyk>nor in the tty2
<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.
<lyk>lfam: aight
<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
<lfam>lyk: I think this is the upstream bug report about your issue:
<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
<lfam>lyk: Oh, maybe not.
<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.
<marusich>(in the installation section)
<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.
<rain1>I got MAME/MESS packaged!
<mood>lfam: Alright, thanks for the help. I'll have to see then
<marusich>mood, you should check out
<marusich>Some of those are known to work with GuixSD:
<marusich>And you don't have to sacrifice your freedom :)
<mood>marusich: Thanks
<mood>I see my laptop has Intel Centrino 2230 wireless. I guess that's not supported
<marusich>A dongle will help if that is the caes.
<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.
<rain1>fun to think about :)
<davexunit>it's totally possible to do
***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.
<lfam>"just" ;)
<davexunit>right :)
<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>lfam: I'd say go ahead and apply it
<davexunit>I'll build kodi after you do and tell you if there's problems
<davexunit>should be fine
<Steap>lfam: <- I'm getting this when trying to use the json module in guix/ui
<davexunit>speaking of Kodi, I'm very excited about the upcoming version
<Steap>I do have GUILE_LOAD_PATH=/home/cyril/.guix-profile/share/guile/site:/home/cyril/.guix-profile/share/guile/site/2.0
<Steap>and guile-json installed
<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>`make clean-go && make`
<lfam>Or, with a ./configure as well
<lfam>A bit of a hammer, I admit
<Steap>"reproducible software"
<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 :)
<davexunit>lfam: speedy!
<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>also hello package is not the same as hello.scm
<str1ngs>is there some module name spacing that is assumed?
<str1ngs>I dont know scheme :(
<davexunit>str1ngs: the documentation may be different in master
<davexunit>the docs on the site are from the 0.9.0 release
<davexunit>a lot has been done since
<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
<str1ngs>see 5.1
<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
<str1ngs>ok I'll work off master
<davexunit>that hello code looks fine
<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
<str1ngs>there is no module defines
<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>thanks for the help :)
<davexunit>see for more details about Guile's module system
<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
<str1ngs>upstream is #!/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>not a bug
<str1ngs>aye that makes sense
<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* '("") (("/usr/bin/env python") (string-append (assoc-ref inputs "python") "/bin/python3")))
<davexunit>something like that
<davexunit>add salt to taste
<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
<davexunit>str1ngs: both ways seem valid
<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
<rain1>ACTION looking into it..
<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?
<davexunit>I don't know actually
<rain1>they got the cat ascii
<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?
<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?
<str1ngs>yay! hows this look?
<iyzsong>jololo: hi, you can try the 0.10.0pre image (it will release soon) which shouldn't need you to build libarchive =>
<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>not for python3 only python
<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
<mark_weaver>that's the easy way, yeah
<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>and then: ,use (guix build utils)
<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>note that geiser loads ~/.guile-geiser instead
<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>Emacs is godly
<dmarinoj>When I watched the "Emacs of Distros" I was sold on GuixSD
<jololo>iyzsong, trying again with the 0.10 prerelease and following these directions: but when running "deco start cow-store /mnt" it says deco isn't found
<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
<lfam>Please do!
<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>have you tried
<str1ngs>will I goto hell if I build my own kernel?
<str1ngs>and enable firmware loading?
<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
<janneke>why a devel group?
<str1ngs>I need a working gcc toolchain
<str1ngs>get tedious piecing it together . but I can make a script I guess
<janneke>i just do: guix environment package-name
<str1ngs>I'm not working on a package
<str1ngs>unless I miss read that?
<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
<str1ngs>partly why I like guix
<janneke>make that: guix environment --ad-hoc ccache emacs gcc-toolchain git
<efraim>there's also gcc-toolchain
<str1ngs>gcc-toolchain might be whatI need thanks
<str1ngs>oh ld-wrapper :)
<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
<ziz15>lfam: i will ..thanks
<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 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
<ziz15>and guix system init ...
<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>efraim: thanks man !!
<efraim>np :)
<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>you're right
<rain1>yeah it can take a long time :[
<ziz15>rain1: yeaaaaaaaaaaaaaahhhhhhhhhhhhh :)
<rain1>I hope you get it it work
<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>set up mounts
<rain1>start cow-store
<rain1>guix pull
<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
<ziz15>rain1: KISS hahahah
<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...
<davexunit>it will also have substitutes available ;)
<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>currently listening to
<davexunit>apparently guix gets a mention somewhere
<davexunit>but they talk a lot about Snappy
<davexunit>and boy does it sound terrible
<davexunit>"snaps" are configured using a YAML file. :/
<davexunit>using the usual "it's just plain text!" messaging
<rain1>what is snappy?
<davexunit>a new package manager for Ubuntu
<davexunit>you will notice a number of similarities between Snappy and Guix
<rain1>oh cool!
<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>what does that mean? :)
<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
<jololo>redo it.
<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.
<janneke>davexunit: i presume you've read
<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>janneke: yeah
<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>iyzsong: that is my plan
<davexunit>I think we should still fix gnome-keyring for everyone else :)
<davexunit>but for me, I've grown fond of gpg-agent
<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
<davexunit>and called it "goo-ix"
<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
<rain1>is there any way I can help
<jololo>lyk, thanks!
<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
<rain1>not a patch
<ng0>the file exists
<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
<ng0>no, just 1
<rain1>why not past that whole patched file to
<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
<davexunit>ng0: sorry, what's the problem here?
<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.
<ng0>i know
<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>janneke: cross-compilation to what?
<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>then i get one of two things
<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 :-)
<janneke>yes, i was very happy with that!
<civodul>not sure what could go wrong, then
<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 
<janneke>phant0mas: it's about my mingw cross target, see
<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>one of the them I've documented in
<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?
<phant0mas>rain1: no I am using quassel :P
<janneke>phant0mas: yes, i have built mingw-w64 newlib and cross toolchain
<mark_weaver>but is the most important issue, because it raises questions about whether vulnerable code is still being used even after its been replaced.
<janneke>phant0mas: hello.exe runs in wine
<rain1>aha :)
<janneke>i cannot build packages that have (inputs), though
<phant0mas>janneke: what does it say?
<phant0mas>when you try
<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
<phant0mas>janneke: give me a sec to check your patch
<janneke>phant0mas: great, make sure you have the latest
<lfam>rain1: What do you want to know? The feature was announced with a nice text:
<mark_weaver>civodul: I just sent a followup to that bug report, with the contents of the guile-builder script
<lfam>rain1: This bug report could be interesting: <>. There are some other bug reports on the topic
<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>that makes sense!
<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
<janneke>phant0mas: great, thanks!
<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>rain1: re grafting, see
<civodul>or what mark_weaver explained, actually :-)
<civodul>anyone has ideas on the gnome-terminal issue described at ?
<civodul>would be nice to fix it now
<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 which instructions on how to easily reproduce the problem on your machine, using the commit on 'master' immediately before the 'security-updates' merge.
<mark_weaver>the needed substitutes should still be on hydra
<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
<optikalmouse>davexunit: precisely what I love ;p
<davexunit>which is a pretty notable difference with npm
<mark_weaver>rain1: it's easily decentralized
<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.
<mark_weaver>both of which can be easily changed.
<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>rain1: nope not yet
<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
<mark_weaver>*git branch
<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>yes thats what i said
<davexunit>there are several problems.
<rain1>lfam, I saw you packaged signify! do you have a plan with that?
<rain1>it's such a good program
<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?
<rain1>I think it was the same
<davexunit>ansible playbook for guix
<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)
<bavier>kyleschmidt: yes
<kyleschmidt>bavier: do you have any online resources?
<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.
<rain1>1 megabyte?
<rain1>use /dev/sda for bootloader
<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
<rain1>try 256MB
<str1ngs>jololo: I used --no-grub then installed grub by hand
<str1ngs>--target error?
<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!
<rain1>great :D
<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?
<rain1>oh okay
<str1ngs>lenovo x200?
<str1ngs>lscpi | grep Wi
<str1ngs>whats your wifi card?
<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.
<jololo>Intel 5100 AGN
<jololo>mark_weaver, I thought so
<mark_weaver>which GuixSD doesn't provide
<mark_weaver>jololo: I recommend flashing Libreboot and then replacing the wifi card with an ath9k-based card
<mark_weaver> 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? :)
<mark_weaver>no, but it should run on any ARMv7 board with NEON.
<mark_weaver>but I haven't tried it on small boards yet.
<rain1>ACTION research NEON
<mark_weaver>NEON is a feature of the processor itself.
<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>rain1: we are both working on the same goal, with some coordination via things like
<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.
<Steap>Does anyone know guile-json well enough to tell me why this does not do what I expect at all ?
<rain1>Steap, you used , but don't have any ' ?
<rain1>soryr `
<janneke>Steap: this looks difficult...
<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>hm :(
<civodul> <- how the Nix folks intend to handle security updates
<janneke>Steap: what about something like:
<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.
<mark_weaver>much nicer, IMO.
<rain1>good to hear
<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.
<janneke>Steap: that's okay
<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
<janneke>it's all just lists or alists?
<janneke>same for strings, just use symbols
<davexunit>ACTION needs to clean up that json patch
<davexunit>sorry for delays on that, I was feeling demotivated.
<Steap>janneke: it is a list of hashtables
<mark_weaver>no worries, I can understand
<Steap>davexunit: np :)
<janneke>Steap: okay, use hashtable->alist
<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
<davexunit>symbols are a lot nicer for keys, I think.
<janneke>or alists's just that you use the json/object/array constructs in your pastebin
<mark_weaver>ACTION goes afk
<Steap>janneke: well, I was under the impression that I had to do that
<janneke>Steap: that's why my comment
<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
<janneke>been doing that for quite some time
<civodul>davexunit: ok for the hack while waiting for a better fix
<davexunit>civodul: okay
<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
<paroneayea>or was that a joke?
<davexunit>they're inefficient in most cases where people use hash tables
<davexunit>which are small data sets
<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>so one can't replace the other
<janneke>davexunit: of course
<davexunit>we need persistent hash tables in guile core (that aren't vhashes)
<davexunit>now that would be something :)
<rain1>tries can work pretty good as persistent hashes
<rain1>you only have to replace the spine when doing an insert
<rain1>so its logn
<davexunit>yeah, that's the structure to use
<rain1>ACTION has scheme code of this
<davexunit>I've seen implementations in Guile
<davexunit>but we need one in core
<rain1>what would that entail?
<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?
<davexunit>rain1: awesome!
<davexunit>that was on my TODO list
<rain1>it took a bit of hard work :)
<davexunit>be sure to send the patch to guix-devel
<davexunit>I'd test it out
<optikalmouse>rain1: how does it look?
<civodul>ACTION tags
<optikalmouse>and what license do package defs fall under?
<rain1>GPL2 (and 3)
<davexunit>civodul: oh darn.
<rain1>I can make a patch for it off games.scm
<davexunit>civodul: I didn't get my fix in yet. oh well.
<civodul>oh i thought it was there :-/
<janneke>^C ^C ^C
<civodul>well next time!
<davexunit>I haven't had a chance to commit because I'm at work
<civodul>ah right
<optikalmouse>...I need to annotate this mame.scm
<wingo>civodul: yaay :)
<davexunit>but yeah, next time!
<wingo>next time could be soon!
<optikalmouse>rain1: yah as in comment on what each directive does and link to the manual
<wingo>maybe guix should do time-based releases!
<wingo>also guile
<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: that module list is quite excessive
<rain1>don't worry about it
<rain1>that's games.scm
<davexunit>rain1: also, use modify-phases instead of alist-replace and friends
<davexunit>this is cool!
<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.?
<rain1>I'll look into docs
<davexunit>rain1: do they really not have an installation script?
<davexunit>it's normally 'make install'
<optikalmouse>what's the syntax for :use-module?
<davexunit>optikalmouse: (use-modules (module name) ...)
<davexunit>unless you're talking about #:use-module with the 'define-module' form
<optikalmouse>so #:use-module is an alias?
<davexunit>then it's
<davexunit>#:use-module (module name)
<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>ah ok
<jmarciano>mame ROMs cannot be free...
<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>MAME alone does nothing.
<jmarciano>So functional software MAME requires non-free ROMs.
<davexunit>no, it doesn't.
<jmarciano>That is like blobs in kernel. Same thing.
<davexunit>no, it's not.
<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
<optikalmouse>davexunit: yeah I guess not
<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>you're preaching to the choir.
<davexunit>I am *committed* to software freedom.
<davexunit>some emulators are problematic.
<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".
<davexunit>so it's nonfree.
<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
<jmarciano>not for you maybe, but practically it is.
<davexunit>providing an emulator that presented a prompt to download and instruct users to run nonfree binaries would be a problem
<jmarciano>yes, but we cannot think like robots.
<davexunit>anyway, if you think this is a problem, you should petition the FSF. they produced the FSDG
<jmarciano>oh I will
<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.
<jmarciano>yes it does
<jmarciano>Wine should not be there
<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?
<davexunit>that might help clear things up
<paroneayea>jmarciano: so
<paroneayea>about wine
<paroneayea>I recently had a friend use Wine to run an old copy of Blender
<paroneayea>which is free software
<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
<rain1>rebuilt to test, all ok
<paroneayea>now that's also a static vs dynamic linking question I guess partly also ;)
<paroneayea>that was a totally legit use of wine
<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.
<paroneayea>jmarciano: but it didn't require any
<paroneayea>in the case I gave above
<wingo>wine is useful too for testing windows cross-builds
<rain1>146.3 MB :)
<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
<jmarciano>it gives incentives simply
<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?
<jmarciano>there is free software pacman
<jmarciano>there are numerous free pacmans
<rain1>just joking :p
<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>this is getting very large
<rain1>what about splitting it up?
<taylan>lfam: (re. nmap) ok, thanks!
<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
<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.
<lfam>taylan: Any feedback on the patch set?
<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.