<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>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 firstname.lastname@example.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.
<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>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.
<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.
<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
<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
<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?
<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
<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
<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.
<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
<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 :-(
<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?
<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.
<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.
<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.
<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)
<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?
<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?
<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>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 email@example.com
<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.