<pxc>wow. guix import is impressive. I"m on 0.9.0, so it only does nixpkgs packages. Should I 'guix pull' or is there somethjing in between the 0.9.0 release and current master? <xd1le>pxc: no i think 0.9.0 is the latest release <pxc>xd1le: I actually discovered that I had screwed up building the package, and I was using guix 0.3, hahaha. I'm rebuilding now <pxc>I'm trying to run Guix on NixOS, so I can practice it on the same hardware I use every day, with all of my Linux drivers and so on <pxc>but the NixOS package for guix is very out of date. I updated the src url, but not the hash... then it appears it fetched the old tarball based on the hash <pxc>I guess it was cached on NixOS' <Steap>Why on earth do we have 3 log files to look at when a test fails ? <pxc>NixOS' hydra instance <pxc>is there a better way to compile and install Guix on Nix? It needs to be compiled against Nix because it needs to be pointed to the nix store so that it shares derivations <bavier>pxc: it looks like the guix recipe doesn't include guile-json as an input <roelj>I'm having some trouble with Git from Guix. When cloning a repository, I get: fatal: unable to access '...': server certificate verification failed. CAfile: none CRLfile: none. Am I missing a package? <pxc>ah, cool! I saw it was json-related but I wasn't sure if that was it. I'm not fluent in Scheme at all <bavier>pxc: IIRC the 0.9.0 release had a bug that wouldn't do proper detection of guile-json's presence <pxc>bavier: should I build a different release? <bavier>pxc: 0.9.0 is fine, unless you want to do a git checkout; 0.9.1 should be out soon <pxc>what's the easiest way to do a git checkout for this? a link to the docs is fine <bavier>pxc: if you're interested in the importers, you'll want guile-json anyways <bavier>pxc: I'm not familiar with how Nix handles VCS checkouts, so you'll want to check their docs <pxc>I can't seem to find it. Looks like it's not packaged (separately?) in NixOS and the version of Guix I was able to install via Nix is too old <pxc>oh, you just mean modifying the package to pull from git <pxc>yeah, I know how to do that <bavier>pxc: you mean guile-json isn't packaged in Nix? <pxc>I thought you meant with the Guix packages tree <bavier>roelj: do you have nss-certs installed? <mark_weaver>roelj: you need to have GIT_SSL_CAINFO set to a single-file trust store of CA certificates. On GuixSD as well as Debian derivatives, it should be set to /etc/ssl/certs/ca-certificates.crt <mark_weaver>on GuixSD, you should have 'nss-certs' in the 'packages' field of your OS config. <mark_weaver>alternatively, you could install 'nss-certs' in your user profile and set GIT_SSL_CAINFO to $HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt <pxc>I think if I can get a newer Guix I can probably install guile-json with that, then my Nix package will find the guile-json derivation and use it <pxc>I can package guile-json for Nix later <xd1le>pxc: are there some docs/tutorial anywhere about guix/nix interop? <xd1le>pxc: oh i see they can share the same store somehow, that's cool. <pxc>xd1le: they can share the same store because Guix was once upon a time based on Nix, although it's not super Nix-y anymore <xd1le>pxc: yeah i know nix was first, but yes didn't know guix was actually based upon it <pxc>I hope the package names are largely the same in both so that the derivations stay mostly compatible <xd1le>pxc: but i guess that makes sense because i do see some 'nix-daemon' processes sometimes <pxc>NixOS and GuixSD could share binaries everywhere that they divide packages up + name them the same way <xd1le>pxc: good point, they actually may be different a bit <pxc>yeah. Both projects are so rich it seems sad not to be plugged into both <xd1le>pxc: what do you mean 'plugged'? <pxc>xd1le: I mean personally keeping up with the goals, features, and changes in each <pxc>running both on the same system with as little duplication as possible seems like a good way to do that <xd1le>i use nixos actually as my daily driver right now though, out of practical necessity <xd1le>pxc: ah i do try to keep up with both <pxc>exactly why I want to be able to run Guix on NixOS <xd1le>pxc: i like to keep up with nix because they support a lot more languages/packages, so when packaging for guix, it's useful to see what nix does <xd1le>but i find nixlang a bit harder to understand sometimes <pxc>xd1le: plus you can convert Nix packages to get started, right? <xd1le>pxc: yes there's a nix-expression importer, but never tried it myself <xd1le>the importers are not 100% perfect most of the time <xd1le>so you probably still have to do some manual work <pxc>I just ran a very old version of the importer on a package I made for nixpkgs three weeks ago, and it did surprisingly well <pxc>missed all the optional deps, though <pxc>oh, shit. It just occurred to me that since the derivation format is the same, if you wanted to maintain both guix and nix packages for a given piece of software <pxc>you could automatically test their equivalence by making sure they build the same derivation <xd1le>unfortunately, i guess if any of the names are just a little different, it would be a different 'derivation'? <pxc>I'm not certain. Sometimes nominal changes don't change the derivation <pxc>but differences will cause that sometimes, yes <xd1le>because nix does have a little bit different naming scheme i think <pxc>what's the difference? <xd1le>as in, with nix, the package names vs attributes are commonly different <xd1le>whereas with guix, the package name vs the scheme variable name is mostly the same <xd1le>not sure if that matters though <xd1le>but it seems becaues of that, there's different naming schemes <pxc>I wonder if it would be easy to make a tool that checks for packages that are in Guix but not Nix & vice-versa <pxc>and points out similarly-named things <xd1le>pxc: yeah that would be interesting <pxc>so that anyone creating a package could easily use the other as a basis <xd1le>nix does have guix packaged btw, iirc <xd1le>not sure if guix has nix though <pxc>and if there was developer interest, maybe in maintaining compatibility, at least for some important packages <pxc>the Guix in Nix is hella out of date <xd1le>ouch, yeah that looks like not much interest <pxc>I think maybe it was used earlier on in Guix development, before GuixSD was bootable <xd1le>i guess the first thing to figure out would be what the guix developers think about maintaining nix compatibility, i.e. some or they don't really care <xd1le>(so maybe an email to the mailing list, if you want) <pxc>I want to wait until I have a little bit more to offer before I do that <pxc>not an incompressible person of color <xd1le>no as in, i figured it out myself just then too <pxc>in any case, I want to at least play with having both on my system for a couple days, sketch a shitty version of the search tool, and then see who's interested <xd1le>nix has way more stuff than guix though, so i think it could be advantageous to see if nix derivations could be used directly <xd1le>pxc: i would probably be interested <xd1le>i just don't have a lot of free time right now, or for a while <pxc>xd1le: great! yeah, it might be of benefit to Guix developers <roelj>mark_weaver: Thanks, that worked! <roelj>Could I have read that somewhere? <iyzsong>I want cross build e2fsprogs-static for armhf with 'guix build --target=arm-linux-gnueabihf e2fsprogs-static'. hoping it will work :-) ***piyo` is now known as piyo
<rekado>our arandr package is broken. It depends on xrandr at runtime. <rekado>I tried to replace the paths to the xrandr executable, but it's not just defined in one place. <mark_weaver>rekado: another possibility would be to make a wrapper for arandr that sets PATH <rekado>mark_weaver: ah, yes, that would work too. <davexunit>what was the agreed upon way to format a version string if the source is a git repo? <davexunit>I packaged Byzanz, which is a GNOME project that hasn't seen a release since 2011. <piyo>davexunit: 15:02:09 <lfam> xd11e: Yes, see section 7.6.3 Version Numbers of the current version of the manual (in the git repo) <davexunit>piyo: oh cool, didn't realize it made it into the manual yet. <piyo>I just grepped the irc log tho. YMMV ;-) <rekado>piyo: you can read the manual locally. Either look at the sources (doc/guix.texi) or build the info. <piyo>Is savannah cgit browse page not working? (cloning now) <davexunit>I use C-u C-h i to open the local Guix manual in my git repo <piyo>so in the example "2.0.11-3.cabba9e" is the last "." (after the 3) uncontroversial? ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | videos at https://gnu.org/s/guix/help/#talks | 0.9.1 is in the works | avoid pastebin.com, it blocks Tor | channel logged: <https://gnunet.org/bot/log/guix>.'
<civodul>i've just added links to videos at fosdem.org, but it's mp4, not great <civodul>and to put a short video on the front page, as discussed before <mark_weaver>civodul: IMO, we shouldn't link to MP4 videos. I can transcode them <civodul>(OTOH free software can read them, but there's uncertainty in some regions of the world, i guess) <civodul>one need to be root to mount stuff though <civodul>anyway, the ELF+ISO9660 thing sounds like a neat hack <davexunit>except for the whole glaring security issues :) <piyo>Are you talking about users trusting Mint ISOs? <davexunit>because apparently everyone has given up on packaging <davexunit>doesn't help when Linus Torvalds himself hates package managers <davexunit>but of course I already disagree with him about a number of things <davexunit>but a lot of people will be influenced by his blessing of something like appimage <piyo>This is kinda like the new emacs maintainer not using package.el, amirite? ;-) <mark_weaver>the new emacs maintainer doesn't even use a free OS :-( <civodul>yeah that's a shame (though he seems to be doing a good job in other respects) <jjmarin>davexunit: I think xdg-apps seems to be a more promising took for containered desktop applications than portable linux apps. They are working in a sandboxing model to protect your system from containered apps <davexunit>jjmarin: yeah I'm familiar with xdg-app. it's better because it sandboxes, but it's still a step backwards IMO. <detrout>xdg-app looks interesting... though i wonder how source based distros <davexunit>guix can just as well sandbox applications without the drawbacks of app bundles. <rekado>I'm always running out of space because I'm only using a tiny fraction of my disk. I do that because this is an old installation of Guix with an even older installation of Fedora in an LVM. <jjmarin>davexunit: well, it has pros and con, as everything <rekado>I'd like to move my Guix installation to the LVM. <rekado>will this work if I just copy stuff from the small partition to the LVM and reconfigure? <rekado>(not sure if the problems were just with *encrypted* LVM or LVM in general) <a_e>You mean Guix or GuixSD? <a_e>Guix on another distro will not notice it is running on top of LVM. <a_e>I understood it did not understand LVM. <rekado>when I installed GuixSD for the first time on this machine I only resized the existing Fedora LVM to make space for an additional partition <rekado>this bites me now. I'd really like to use the whole disk again without too much effort (and ideally with LVM) <piyo>is lvm supported by guixsd now? <jjmarin>xdg-apps allows several new things, my favorites: 1) people can use and test new upstream versions in their distro of choice 2)people can use applications that are not packaged for their distro <rekado>do you know if someone is working on this? It bugs me enough to help out there. <rekado>(was updating my package definition for Blender when I ran out of space again.) <piyo>visual representation of rekado's HDD: ([LVM <fedora>])(GuixSD), where () is DOS/GPT partitioning <piyo>Please excuse the crudity of this model. ;-) <mark_weaver>rekado: I don't think anyone is working on it right now <civodul>rekado: Sleep_Walker did the initial work to support LVM a year ago or so; all my recognition to anyone who picks it up :-) <piyo>It's hard to tell how much more work is needed to make lvm2 work with guixsd. <efraim>I saw there's a thread about go-build-system, i'll post a detailed reply soon <mark_weaver>others to follow when my rather old computer finish transcoding them :) <civodul>mark_weaver: woow, that's efficient, thanks! <civodul>maybe i'll update the web page when they're all ready? <piyo>mark_weaver: watching this now <mark_weaver>for the record, here's the command to convert them: ffmpeg -i FOO.mp4 -c:v libvpx -crf 18 -b:v 20M -c:a libvorbis FOO.webm <mark_weaver>where the 18 is the constant quality value, to be tweaked as needed to roughly match the size of the original video. <a_e>I would like to create one with X11 and some additional packages. <a_e>Can I simply modify gnu/system/install.scm <a_e>by taking inspiration from desktop.tmpl? <civodul>mark_weaver: maybe you could abuse one of the build machines to convert them? <piyo>works on Windows Chrome, uh just checking?! <mark_weaver>civodul: the build machines have a lot of work to do right now, best not to add to it. <civodul>ACTION fiddles with grafts in the meantime <mark_weaver>that's good! critical openssl update coming on tuesday <civodul>not sure it'll perform well enough by then, but we'll see :-) <civodul>while at it, i've changed the thing to graft based on the run-time dependencies <a_e>So I add %desktop-services to the services and xfce to the packages, and that is it? And maybe then root can log in to xfce with an empty password? <civodul>a_e: something like that should work, indeed <a_e>It cannot be that easy :-) But I will see. <mark_weaver>a_e: there's a caveat: iirc, the entire system will be in a ramdisk, so if you have a lot of stuff in there you'll need a lot of RAM. (civodul will correct me if I'm wrong :) <a_e>Okay. I think there are 4 GB, so if it fits onto my small USB key, it should fit into memory. <mark_weaver>a_e: it will be compressed on disk, but uncompressed in RAM <mark_weaver>iirc, live systems that are designed to be full desktop environments typically work differently <mark_weaver>I guess maybe by mounting the disk read only and layering a ramdisk on top that changes are made to, or something along those lines <a_e>I just want someone on windows to be able to play a linux game. <a_e>So I need X and a way to start the program. <a_e>Even "startx" and then the name of the program would be fine. There is no intention to work with it and to change any data. <mark_weaver>why are free programs for POSIX called "Linux" programs? <a_e>"guix system disk-image" does not seem to take "--target". <a_e>mark_weaver: Maybe they do. We will see once we have the hurd. <mark_weaver>it's not good to use "Linux" as an adjective to describe free software for POSIX systems. <_`_>it's incorrect parlance, I agree. <df_>I would probably just say "free unix programs", but then I'm not too concerned about trademark lawyers coming after me <a_e>My newest package builds on arm, but fails on x86_64. Original! <a_e>Error: Cast from void* to int loses precision. It does not on 32 bit :-) <mark_weaver>heh, I guess that program hasn't been updated in a loooong time <a_e>To a point where I got the source code from the Debian package! <a_e>Well, my xfce boot image did not work. <a_e>It failed with the repeated message "waiting for partition 'gnu-disk-image' to appear". <a_e>Maybe I removed too many services.. <a_e>I first tried to apped %desktop-services to (installation-services); but there were collisions at least for nscd and udev. <a_e>So I used only %desktop-services. Is that maybe not enough? <zacts>I think the game engine for twinson's odyssey was released GPL <zacts>(my favorite game of all time) <a_e>Strangely, /dev/disk/by-label/gnu-disk-image exists and points to /dev/sdb1 as expected. <a_e>zacts: This does not mention the GPL. Where did you see it? <a_e>Are you ready for packaging it then? <zacts>I saw it somewhere let me try to find it <mark_weaver>a_e: that error would not have been caused by lack of services <a_e>I am trying the basic image now with the USB stick and the machine I intend to use. To see if this works or already fails. <a_e>Well, maybe I was missing union-fs. <a_e>This was downloaded for (installation-services) for the cow-store; although I do not intend to write anything. <civodul>a_e: the root partition has to be have the "gnu-disk-image" label <rekado>is it by design that the arguments to shepherd's "make-system-constructor" are concatenated without spaces whereas the arguments to "make-forkexec-constructor" are joined with spaces? ***Digitteknohippie is now known as Digit
<a_e>civodul: It does have the label! That is the strange thing. <a_e>I see the label when I plug in the USB stick and look at /dev/disk/by-label <rekado>I can confirm that adding "export GTK_DATA_PREFIX=/run/current-system/profile" at the top of my ~/.xsession file makes Xfce pretty. How can we set GTK_DATA_PREFIX by default? <mark_weaver>rekado: the problem is, what would we set it to? if we set it to /run/current-system/profile, then it won't find xfce in the user profile, and if you set it to $HOME/.guix-profile then it won't find xfce in the system profile. <mark_weaver>IMO, we need to patch whatever code uses that variable to accept something PATH-like <rekado>okay, I'll take a look at the GTK sources. <rekado>I'd really like to be have a declarative system for user configs <civodul>rekado: i've never used make-system-constructor, there could be bugs :-) <mark_weaver>rekado: regarding declarative system for user configs: do you know about "guix package --manifest" ? <mark_weaver>bah, ffmpeg has been working for 2 hours on my X60 to transcode only 25 minutes of video. <mark_weaver>I guess it's assuming that I don't have SSE or anything useful <mark_weaver>I should probably look into making ffmpeg/libvpx/libvorbis packages that are configured to use non-ancient features of my CPU <civodul>maybe you could build a variant that uses -mtune=native and all that <daviid>mark_weaver: you are converting the video because mp4 is not free? [don't know much about video format...] <rekado>mark_weaver: do you mean I should just add scheme code to my manifest to (over)write config files? <rekado>(bad connection at the moment, my apologies for the delay) ***necronian_ is now known as necronian
<mark_weaver`>rekado: no, I wasn't suggesting that. I agree that more work in this area would be useful, but I'm not yet sure what it should look like. <civodul>maybe we could set GTK_DATA_PREFIX in /etc/environment? ***kmic is now known as kmicu
***Gottox is now known as 21WAAAC87
<rain1>does guix have/support qemu kvm? ***the_ktosiek is now known as ktosiek
<rain1>I see the module in lsmod | grep kvm <a_e>Even the official guixsd installer does not work! It seems to be a problem with the USB stick. <a_e>I copied the official image to another USB stick and can then boot from it. <a_e>So I will try again with mine. ***fotis2 is now known as 16WAAFHEV
***14WAABC5T is now known as wgreenhouse