<lfam>So, I guess there is some very weird issue with my systemd... <lfam>Is anybody else fetching substitutes over https on a systemd-based OS, such as Debian? <lfam>I can also see in /proc that the daemon started by systemd has the expected filesystem path <lfam>I'm tempted to reinstall Guix from scratch, but if other users are having this issue, I'm willing to be the subject of debugging <rain1>looks like building firefox on guixsd is too hard :( <NiAsterisk>any problems you run into? I'd be glad to know, I plan to do torbrowser sometime in the next months <rain1>It wants a specific autoconf version 2.13, I cheated and one of guix's versions but the it ca't find some AC macros <mark_weaver>rain1: you shouldn't need autoconf to build from a tarball release <mark_weaver>but yeah, firefox is surely a difficult package. icecat certainly was. <rain1>ill try that! I was using hg <rain1>which is what i used to do on arch <mark_weaver>but I should warn you: if the autoconf issue seemed too hard for you, you're unlikely to get firefox packaged, because there are surely more difficult problems ahead for you <rain1>im not packaging ff just building it <rain1>also I just can't really be bothered debugging autoconf m4 macro search paths <rain1>these tools are terrible and dont' make life easier <mark_weaver>packaging it might be easier than building it manually <mark_weaver>lots of issues are handled automatically by gnu-build-system, and our icecat package would probably be a good start. <mark_weaver>version 45 will be the new ESR, so icecat will switch to it at some point and I'll need to update our icecat package to deal with version 45. <mark_weaver>lots of people complain about autoconf, but all of the replacements that people have come up with are much worse. <lfam>Doing Guix has made me love autoconf (as a packager). There's nothing I dread more than some hand-rolled build configuration system <lfam>Whereas the autoconf packages *just work* <mark_weaver>yeah, autoconf is the only thing that's robust enough to deal with unusual systems like ours without a lot of pain <lfam>Generally they just work ;) <mark_weaver>from a packager's point of view, I must say that epiphany is by far the sanest modern browser <lfam>I've noticed you saying that <rain1>does it suffer from the same problem as midori? <mark_weaver>rain1: no, it uses modern webkit, with process separation. <rain1>oh great, maybe i can use that instead <rain1>for some reason if i make guix environment icecat --ad-hoc gstreamer gst-plugins-base <mark_weaver>at present, it uses a version of webkitgtk that was just released within the last week or two, with fresh security updates from upstream work by apple. <NiAsterisk>mark_weaver: with this package (rust) after I already wrote my own I discovered one on paste.lisp.org with your name from around 2014. I suppose you don't remember where it failed or why it never was finished? <lfam>rain1: That only 'ad-hocs' gstreamer, but not gst-plugins-base <lfam>rain1: You have to put '--ad-hoc' for each package <mark_weaver>NiAsterisk: I've never packaged (or even used) Rust. what's the link? <mark_weaver>I might have tried to help someone else trying package it, though <NiAsterisk>I can't locate the bookmark. I guess you helped someone with it <rain1>the icons are all missing in epiphany <NiAsterisk>one of the many packages I need for panopticon which now uses too much cargo, so I need cargo import, which will happen at some point too because I want panopticon :) <rain1>wonder if i should take a screenshot <rain1>if anyone is interested in that <lfam>rain1: Heh, I think we can picture it in our minds <mark_weaver>rain1: interesting. I've only ever tried to use it from within GNOME and Xfce. maybe it depends on something else being installed in the system (or user) profile <mark_weaver>rain1: can you run it within strace and see what it's trying and failing to find? <rain1>I guess ill grep -v away the ones that aren't interesting <mark_weaver>rain1: in the environments where I run epiphany, XDG_DATA_DIRS is set to include many directories <mark_weaver>my first guess is that something is missing from that <rain1>here's the value of that variable for me: <rain1>/home/rain/.guix-profile/share:/run/current-system/profile/share:/home/rain/.guix-profile/share:/run/current-system/profile/share:/gnu/store/mbwk46a2a04fb8nkxf48v2984hizwvwn-xfce4-session-4.12.0/share <rain1>so other than defaults its just got xfce4 session <mark_weaver>rain1: I have adwaita-icon-theme installed in my system profile. maybe that's it? <rain1>oh I think this must be regular guix behavior <rain1>but it searches for every library in each thing in the gnu store! <rain1>so that's why there are heaps of ENOENTs <rain1>what is meant exactly by that being in system profile? I'll do this as my regular user: guix package -i adwaita-icon-theme <mark_weaver>I also have "Adwaita" selected as my icon theme in the xfce appearance settings <mark_weaver>rain1: but fyi, the system profile is /run/current-system/profile, and contains packages listed in the 'packages' field of your OS configuration. <mark_weaver>services can add packages to the system profile as well <lfam>The following package will be downgraded: guix 0.9.0.f888c0b → 0.9.0.71e2065 <mark_weaver>the system profile can only be changed by "guix system reconfigure" <lfam>Shouldn't we should use a "revision" integer between the version and the hash to prevent that? <rain1>I think this is a regression? <lfam>mark_weaver: I can make the change. Should it go to master, core-updates, the mailing list? <rain1>by the way I wonder about all these "warning: collision encountered:" <mark_weaver>lfam: civodul updated the guix development snapshot to fix the https problem. <rain1>mark_weaver, oh that got me all the icons! <mark_weaver>rain1: that's good! can you email bug-guix@gnu.org about it, so we don't forget to fix it? <lfam>mark_weaver: Do you think it's okay that `guix package -u` sometimes doesn't update to the lastest version of guix-devel due to the hash? I thought I understand what you meant by "it should already be done" but after a few minutes I realize that I don't <lfam>Currently it's version is defined like this: (version (string-append "0.9.0." (string-take commit 7))) <lfam>Ideally it should be (version (string-append "0.9.0." revision (string-take commit 7))), right? <lfam>Or, like that but with added punctuation to separate the revision from the hash <lfam>Anyways, this solved my https problem, thankfully! <rain1>does guix have something like lxc? containers <rain1>I guess this pflask thing, it's new to me <lfam>There is `guix environment --container`, as well some good tools for working with QEMU virtual machines in `guix system vm` and `guix system vm-image`. I don't know whether or not they meet your use case... <mark_weaver>rain1: there's also an experimental 'guix container' command <lfam>Wow, I didn't know that one! <rain1>I would like to run a different OS like arch linux or something <rain1>would that be possible with either of those? <lfam>rain1: You could use plain QEMU <rain1>that's true but it's so hard for my use case <lfam>By which I mean, without `guix system` <rain1>it's quite nice to use a browser inside a container, but if it's a VM it makes things like copy/paste between not work <lfam>True, that aspect is annoying. But, if I am running a browser in a container for security reasons, I don't want it to be able to access the host's clipboard anyways <Piece_Maker>theres a few docker packages available... not sure if the whole suit is available <Piece_Maker>well i mean, docker-compose seems to be available in guix repos but im not sure if thats all you need for docker containers <lfam>Piece_Maker: IIRC, davexunit added docker-compose so he could use it at his job. I don't think it's the whole shebang though <lfam>If you search the guix-devel archives there should be some context <lfam>BTW davexunit is also our resident container expert. I think he has some choice words about docker ;) <Piece_Maker>ive never liked docker... its a bit... i dunno, sort of makes me nervous in multiple ways <rain1>I may have to package debootstrap :/ <Piece_Maker>if i need docker-like containers ive used systemd-nspawn, thats a REALLY nice container solution but doesnt help guixsd as obviously that uses shepherd not systemd <lfam>rain1: detrout is a Debian developer. She may be able to give you advice <Piece_Maker>rain1: most container solutions i believe are built ontop of lxc <rain1>I wonder why there's lots and lots of alternatives, I didn'tk now about them and assumedi t was the default <Piece_Maker>docker is more or less a frontend for LXC, with a docker hub/other such nonsense built around it ;P <rain1>some program I wanted to build once uses docker during build for some reason <rain1>and I tried to build it inside my lxc container and it cannot work <rain1>why did they not make docker work inside a container? <Piece_Maker>i reckon packaging something like firejail for guixSD would be awesome... not sure how that would work though <rain1>I am thinking about trying pflask <Piece_Maker>and not sure how much itd really differ from the current guix package container command hehe <detrout>rain1: there's also cdebootstrap which can eventually be just a binary <tssseq>Is hydra down at the moment? Just keep getting 504 errors <NiAsterisk>this in #configure-flags looks a bit broken to me, the part with (which "llvm"), I am not sure. (list (string-append "--llvm-root=" (which "llvm"))) <rain1>does anybody have a tip on RUNPATH validation failing? <myglc2>Hello! I am seeking advice on submitting a patch to the doc <myglc2>introduction. Issue: patch has a .dot figure but doc.am <myglc2>DOT_OPTIONS make a mess of it. I have the output, a 29K PNG, <myglc2>which makes my patch weight in at 54K. Would it be horrible to <myglc2>submit a patch like this? If so, how should I put this up for <myglc2>discussion and recruit to mode doc.am? <myglc2>* hopefull recruit someone to modify doc.am? <chewieQC>Is guix participating in Google Summer of code via the GNU project? <chewieQC>As a student who wants to learn about reproducible software packaging, should I submit my candidature or is it too "simple"? <NiAsterisk>I am not sure, I think others are more informed about the gsoc to reply to that <NiAsterisk>all I know is that gnu.org/s/guix/ should have a news item and link to the gsoc proposed topics <NiAsterisk>sorry that I can't be of more help :) others will know more <duende>I am having strange problem installing guix <duende>Substitute: updating list of substitutes [...] finishes <duende>and then it starts echoing Substitute: updating list of substitutes [...] 100% nonstop <NiAsterisk>that might have to do with recent guix changes, I read something on the list about this. but I'm away now. good night and success with installing guix :) <duende>no I'm just following the installation guide <Piece_Maker>are there any other substitutes besides hydra...? (just curious) XD <chewieQC>You can roll your own with the guix publish command <chewieQC>But there are no other public ones that I now of <duende>Retying, it seems to be working now <Piece_Maker>i always thought itd be interesting to build a decentralised package repository running on something like syncthing or the bittorrent protocol... could be possible with the reproducability of guix... <chewieQC>It's exactly what you need to build that <chewieQC>I'm actually looking on how to add it to GuixSD right now :) <rain1>chewieQC, I've been thinking that would be a great idea too <NiAsterisk>Piece_Maker: check the plans / ideas of guix regarding gnunet distribution and steps in how to get there eventually. <rain1>oh guix packages over gnunet? that would be amazing <Piece_Maker>i did read that guix was eventually planned to be decentralised/p2p <chewieQC>rain1: Could I do that as a GSoC project? <Piece_Maker>the thing i was never able to figure out (i actually tried making what is essentially a decentralised repository for arch's pacman) is that all users neeed to mirror the entire repo... couldnt figure out how to JUST pull the packages that i actually want to install... <Piece_Maker>but i reckon with gnunet or ipfs that could be worked around <Piece_Maker>that is, unless EVERY package was its own bittorrent file... which would get messy very quickly <rain1>I had a go packaging lxc, it doesn't work yet though <rain1>you can run the programs but they give some strange errors <Piece_Maker>chewieQC: look good - i reckon your ipfs plan would work better though hehe <rain1>Piece_Maker, what's wrong with each file being its own torrent? <Piece_Maker>i suppose it wouldnt be THAT bad, openSUSE already does it <rain1>i think ipfs is exactly designed tto solve this though <rain1>ill look into that, that's pretty cool <Piece_Maker>openSUSE packages are pulled from ALL their mirrors at once via metalinks using aria2c <Piece_Maker>not quite decentralized, but like... if you could make them into torrents and allow all users of that package to seed <Piece_Maker>its rudimentary but it could work, and then you just need to figure out how to roll out updates (which i reckon guixSD has already solved too) XD <Piece_Maker>i reckon guixSD is the perfect distro to actually maket his work with, as all the packages are in /gnu/store and not scattered all over the damn place where youd have to mess about with symlinks and whatever <davexunit>gnome keyring is giving me all sorts of problems, and then I look at the logs to see a javascript backtrace <davexunit>I need to somehow remove this from the list of autostart applications <Jookia>davexunit: polkit is written in JS too. lots of fun <davexunit>I killed gnome-keyring and started gpg-agent as normal. things are better again. <davexunit>but I think the only way to really stop this thing is to modify the package recipe for gnome-keyring so that it doesn't install the gnome-keyring.desktop autostart file <Jookia>Can Guix generate shell scripts with inline replacements like '#$dhcp' ? <janneke>Jookia: i am thinking of releasing a template-substitution module <janneke>i don't think something like this is in guix yet <civodul>Jookia: there's 'text-file*' which does roughly what you want <civodul>though it's really Guile scripts that you should generate ;-) <Jookia>I'm still on the fence about using Guile as an init system given how much space its ccache takes up :( <civodul>there's a gnome-session warning about missing hardware acceleration <civodul>could it be that it's a fatal warning? <wingo>civodul: yeah we need to pass --disable-acceleration-check to gnome-session <wingo>alternately it would be nice to figure out how to enable acceleration in qemu <wingo>i don't know, proprietary solutions can do it so i assume qemu will soon i guess <civodul>i'll try --disable-acceleration-check in the meantime <civodul>i assume this does not disable hardware acceleration when it's available, right? <wingo>it disables an early check in gnome-session that aborts if acceleration is not available <wingo>and i think janneke said that adding that option worked for him <wingo>so probably we should enable it in whatever package it is that starts gnome-session <wingo>and marc-andré is a libvirt/qemu person <wingo>so it seems maybe we will have a nice solution there <wingo>oh that makes me happy. great stuff. <rain1>sorry from arch linux, onto guixsd <rain1>I get that I was just thinking it might interact weirdly with guixsd <Jookia>Guix wants control of /bin doesn't it? <rekado>you could use pacman in a container, though. <rain1>the script that I want to run to build a container needs pacman <Jookia>I think I may have ruined my Guix somehow <Jookia>Guix thinks I don't have a GCC install so I built it but now it give really bad errors <rain1>is there a way to build containers on guixsd already? <rekado>rain1: "guix environment --container --ad-hoc"? <rekado>Jookia: did you build gcc-toolchain? <rain1>how would I get pacman in that? <Jookia>rekado: I don't know, I compiled the entire system and compiled other stuff, so obviously I have a gcc. Maybe garbage collecting wiped out the gcc that 'guix environment --ad-hoc' wants, though I tried all three. Compiling gcc@4.9 gives me a compiler with weird errors <rekado>rain1: you first package pacman, then ask "guix environment" to spawn an environment in which "pacman" is available: "guix environment --container --ad-hoc coreutils pacman ..." <Jookia>did i accidentally overwrite files in my store <rain1>I'm trying to package pacman and guix build fails <rain1>it says: See ./test/test-suite.log <rain1>I think it's due to: /bin/bash: bad interpreter: No such file or directory <rain1>not sure how to trick it into thinking /bin/bash exists <rain1>I see that it generally has a patch shebang phase but it must not be getting applied to the test suite <Jookia>Is there a special package for linux/limits.h ? <Jookia>It's odd I need that for openssl <Jookia>I also need glibc to fix 'cannot find crt1.o' but then it seems to work <Jookia>trying to run the binary gives " error while loading shared libraries: libcrypto.so.1.0.0" :\\ <NiAsterisk>I want to work on coreboot without headaches (gives some errors I don't want to fix rn in guix), are there any gnu livesystems with git and developer tools included? <rain1>autoconf/whatever is giving me nightmares, think I need to give up <rain1>i couldn't package pacstrap because pacman had errors and I can't package debootstrap because of weird autoconf stuff in libdebian-installer <NiAsterisk>i have too many livecds.. asking because of that <jmarciano>please, the future users of GuixSD certainly need a pacman. <jmarciano>pacman is for fun I know. I like more productivity software. <rekado>Jookia: why don't you use gcc-toolchain instead of gcc? <Jookia>jmarciano: pacman is a package manager <Jookia>rekado: I don't know, should I? I have to rebuild gcc I think <rekado>gcc-toolchain contains the correct linker wrapper and other stuff you need to build software with Guix <NiAsterisk>should've bought that beaglebone.. now I am literally stuck with GuixSD until I get a beaglebone, because make of coreboot on guixsd is not easy. <rekado>are recursive module dependencies a problem? <rekado>I have a package that should go to "statistics", and it depends on packages in "machine-learning" and "statistics". But the "statistics" module cannot load the "machine-learning" module because "machine-learning" already imports "statistics". <rekado>Is this a problem or will this be lazily resolved? <efraim>as long as you don't have a cyclical package dependancy <rekado>I also should not use "#:select", right? <rain1>I came across this earlier and I just noticed they recommend guix <rain1>"Look at Guix package manager." <davexunit>rekado: re circular module dependencies: "it depends" ;) <rekado>kristofer: you can add this to the kernel command line: modprobe.blacklist=module,you,want,to,blacklist <rain1>is there a service to use it as a demon? <rain1>I'm just curious if there was more to the decision <rain1>was it really just because its GNU? <rain1>that seems odd because lsh is much less well known and used <davexunit>that's what motivated ludo to make a service for it <davexunit>apparently no one else has been motivated to make an openssh service <rain1>btw I think lsh is nice and am glad to learn about it through guixsd <davexunit>GuixSD is what you configure it to be. lsh isn't *the* ssh server you can use. <rain1>I packaged lxc but I wasn't able to package any of the tools needed t obuild container templates <kristofer>I'm getting an unbound variable xorg-configuration-file when I run guix system reconfigure <libreH4cker>how does guix as a package manager compare to other libre distros' package managers? <mark_weaver>kristofer: 'xorg-configuration-file' is exported by the (gnu services xorg) module. so you need either (use-modules (gnu services xorg)) or (use-service-modules xorg) at the top of your OS config <kristofer>mark_weaver: now the error says unbound variable slock <mark_weaver>kristofer: "guix package -A slock" will tell you that it's defined in gnu/packages/suckless.scm so add (use-package-modules suckless) <kristofer>I see.. I'm trying to define a custom set of %desktop-services <rekado>libreH4cker: there will probably be another GSoC project for that. <dptd>Anyone had such a problem before? <dptd>Happens all the time. It is log from the guix system init command. <dptd>rain1: I don't think so. I have 16GB and this is just a clean install (desktop.scm config). <jmarciano>ocrad - optical character recognition in GuixSD, very nice... let me scan the book of 280 pages. <chewieQC>Has anyone written a tutorial on how to package software for Guix? <NiAsterisk>#:configure-flags (list (string-append "--lvm-root=" (which "llvm"))) <NiAsterisk>errors I get are like ERROR: In procedure string-append: Wrong type (expecting string): #f <bavier>NiAsterisk: 'which' is only for binaries <bavier>you probably want (assoc-ref %build-inputs "llvm") instead <NiAsterisk>right, i did this some days ago... /me headdesks <NiAsterisk>i'm a bit under the weather or whatever.. thanks :) <redshelled>Hey guys, I moved farther on my install, but now after running the command guix system init, it is trying to build guix-0.9.0.71e2065 and fails during the store.scm test. Is there away to get around this so I can continue the install? <davexunit>redshelled: if you are using substitutes then it shouldn't be building locally <davexunit>so perhaps you aren't using substitutes? did you run 'guix pull'? <redshelled>davexunit, I am using substitute as it uses substitutes for everything else <redshelled>yes I ran guix pull before the guix system init comman <davexunit>well there is a bug here because the guix test suite should pass. what platform are you using? <redshelled>it does say at the end of the tests "testsuite summary for guix 0.9.1" Maybe that is intended? <davexunit>redshelled: it would be great to get the test-suite.log file from that build. <davexunit>if you have a way of extracting such a log off of the build machine, I could tell you what to run. <jmarciano>redshelled: your Lenovo e530 has working wireless with GuixSD? <davexunit>that will build guix and keep the failed build around <davexunit>which will allow extracting the test suite log <redshelled>davexunit, I am running it now, it may take a few minutes since this machine isnt exactly a compiling monster <davexunit>they all seem to behave differently on different machines. my guess is that a test that I wrote is failing. <redshelled>I could understand that. I imagine everything is ok with the build. I was just surprised that it wasnt using the substitute and trying to build it <redshelled>I tried guix system init <config> /mnt --substitute-urls=http://mirror.guixsd.org and it gave me the same result, still trying to build from source. Maybe the build command will yield different results? <redshelled>my machine is running the tests now so shouldnt take much longer <davexunit>either way, the build should complete successfully on your own machine so I'd love to know what's going wrong. <redshelled>when i get it do you want me to paste it to paste.lisp.org? <davexunit>redshelled: I can confirm that the latest version of the guix package builds locally for me as well. <rain1>nothing i can do seems to let my guix system init suceed <rain1>it always dies on python 2.7.10 <redshelled>i had to build that one from source as well if i remember correctly <davexunit>this could mean that either hydra has not caught up and built them *or* that the builds are failing on hydra <davexunit>it's non-trivial to find out which it is. I want to see that fixed sometime. I'd really like Guix to warn the user if they are about to build something that is known to fail. <redshelled>ah I see. That would be a useful feature. those two did build successfully on my local machine <davexunit>redshelled: guix built successfully on my x86_64 machine. <redshelled>looks like a hash mismatch for the substitute too <davexunit>redshelled: hmm, I'm not familiar with this particular test. could you email bug-guix@gnu.org describing this failure? include this test suite log, your platform (x86_64), and the package version string for the failing guix <davexunit>I believe the version string is 0.9.0.71e2065 <davexunit>to get your system installed, we could try a little hackery :) <redshelled>Well were starting at not working so cant make it worse :D <davexunit>could you try adding that to the top of your OS config file? <davexunit>what I'm attempting to do here is overwrite the 'guix' variable with a new guix package that disables the test suite. <davexunit>redshelled: I didn't test it so perhaps I've made a typo or some other silly error <bavier>could we perhaps have 'guix build --log-file foo' ignore grafting logs? <davexunit>redshelled: that means it ran tests, which means it didn't use our modified guix package <davexunit>a sure-fire way for it to work is to make a git clone of guix <redshelled>In the mean time, I have spare laptops, so I can just try it out on one of the others until maybe something fixes that. <davexunit>this should build a custom version of guix I made that disables the test suite for that guix package <davexunit>then you should be able to install the system <redshelled>ill be back here in a few mins, gotta do something, the build is running now. Ill report back with results <NiAsterisk>I advanced a bit through failures, but now: configure: error: program '/gnu/store/p5qnqhas3bfg281q1xpwzszbbxpii51y-llvm-3.6.2/bin/FileCheck' is missing, please install it <lfam>Hm, maybe that's a feature we should enable in our llvm package? <NiAsterisk>I can give you full context with the current .scm and log <lfam>Well, the error message says that it's missing from the llvm tree. Does that file exist anywhere in the llvm store directory? <lfam>I would look into the llvm source code and manual learn about it and how to build it <lfam>So, what could cause a python package to retain references to all its native-inputs via the wrapper? Or is that expected? <NiAsterisk>okay, I'm doing it. just had a short detour into linux from scratch with llvm and I just saw how incredible bporing lfs is, it's just like gentoo stage 1.. never looked into lfs. <lfam>I've found it helpful when trying to build some tricky things. It seems like a good resource <NiAsterisk>yes, but I always thought it was something other than a big manual, I had no expectations and never read into it. no idea what I expected.. <lfam>Yeah, I was pleasantly surprised when I first started reading it. It pops up often when I am debugging build failures <NiAsterisk>I think I might have looked at in '99 when I first looked at Gentoo and with a time limited, slow internet connection it was not pleasant to read into.. and now I have about 16 more years of experience with things. <davexunit>NiAsterisk: it's "fixing" things by allowing each application to have an isolated environment in which to run, so that you don't have to worry about application A's dependencies clashing with application B. <davexunit>and it works by using existing distribution tools to do the heavy lifting to create the necessary disk image <NiAsterisk>I know how it basically works, but what if apt-get breaks. or some tool included in the disk image is 4 years outdated, nobody checks that <davexunit>obviously, we know that there's a better way, but Docker is allowing people to do things that were more difficult to do prior. <davexunit>it's not good for user autonomy and control. <davexunit>it's good for developers to control how their software is run <davexunit>they just ship a disk image with a mini-distro that can run their application! <NiAsterisk>some do that with virtualbox and gentoo hardened based systems, the company sirrix for example. <lfam>A disk image that is then never updated or patched <davexunit>I'm (so far unsuccessfully) trying to demonstrate to others that with Guix we can do much better than Docker. <lfam>It's interesting to see what aspect of Guix / Nix systems turns people on. Different things speak to different people <davexunit>call-with-container trails behind Docker on important features like virtualized networking and cgroups to limit system resources. <lfam>To me it was the basic idea of putting software in a content addressed store where each package is named for it's dependency graph. With that base, you can go in many different directions <davexunit>but 'guix environment --container' was released with support for user namespaces *before* Docker did. ;) <davexunit>it's amazing the things that can be built on top of that foundation. <lfam>To others, it's the language (Scheme, or for some, Nix) <NiAsterisk>I think originally I was drawn by GNUnet, and the maybe future feature to have a GNUnet oriented distribution for software updates. then it became hey, when I fix enough and add enough I can run servers again without being angry at them that much. <davexunit>our container implementation has the luxury of being much simpler than Docker because we don't need the crazy disk image layering stuff that they do. <davexunit>we just use the provided foundation: the immutable store <lfam>I remember your announcement mentioned that angle, and it's true <davexunit>tell guix which store items you want in your container and guix will prepare it for you. <redshelled>Scheme brought me here. The only thing I was wondering about is the differences in scheme and nix. As far as I understand it, nix is lazier than scheme which may be an advantage <davexunit>and on top of that, data is shared between *all* containers, system-wide. <bavier>I was recently doing some personal web server work, and I was very much missing GuixSD; that I couldn't declare the system state was very frustrating <davexunit>containers whose dependency graphs overlap aren't duplicated. <davexunit>bavier: yup, I miss it every day at $dayjob. <lfam>redshelled: The fact that Scheme code is data is hugely powerful for us. I'm relatively new to Guix and Scheme, so I can't really take advantage of that, but it allows us to easily do a lot of stuff that would otherwise require hacks like scraping and parsing our own package recipes. <rain1>I think guix will win, it is the best :) <davexunit>it's nice that we can write code that the build daemon will run by simply quoting the expression <bavier>I'm kinda scared that my now-special-snowflake will break and I won't be able to get it back <redshelled>lfam, thats very true. I also appreciate the fact that there are many tools for guile and scheme already. <NiAsterisk>I hope to arrive at the point where I can configure and setup a gnunet node through the system file and have it on a dedicated headless server. <lfam>bavier: I know what you mean. I'm spoiled by Guix <lfam>I already hated having to document my snowflakes, but it's a different feeling when you have used something better <davexunit>we're getting closer to being able to handle web server type use-cases. <redshelled>plus scheme is pretty common to teach at universities <lfam>davexunit: What do you think we're missing? <redshelled>and a good intro to functional programming or so ive been told <lfam>Besides a letsencrypt package ;) <davexunit>lfam: zero downtime web server upgrades is one thing <NiAsterisk>redshelled: what? where? I only see js, java, c,.. <davexunit>lfam: nginx has the ability to be upgraded without downtime, but so far shepherd isn't smart enough to handle it yet. <lfam>davexunit: So, better service restarting within shepherd? Does the nginx shepherd service implement reloading yet? <NiAsterisk>then something happened and we are at Java everywhere ***Dezponia_ is now known as Dezponia
<redshelled>NiAsterisk: many big universities teach it in the US <davexunit>then step 2 is handling the nginx binary being upgraded as well. <lfam>I hadn't thought of that <NiAsterisk>interesting. where I looked (germany) at universities of applied science it was more or less what I mentioned plus some extensions to this <lfam>Yeah, I need to take a break from packaging and learn to write a service that does more than just execute a binary <davexunit>but we're set up for some really nice features <redshelled>NiAsterisk: UCLA, Brown, Michigan, and MIT I think all have some type of scheme classes <davexunit>for example, I wrote a patch that allows the nginx-service to be extended with additional config files <NiAsterisk>I want to package rust and then do rust cargo imports, after that one of the bigger tasks for this year is done, then I can write services I wanted to do and afterwards I can do Torbrowser :) <lfam>I could start submitting "stub" services that just execute a binary, for software that can be configured completely from a text file. At least they would provide run-on-boot <lfam>I'd *love* to see a presentation on services from one of the more experienced Guix developers <lfam>The written documentation is as dense as I am ;) <NiAsterisk>redshelled: I invst more time into this than I thought... I have a todo list stretching about 12 months for Guix alone I think, but I had the plan to learn C++, Guile and Lisp this year. this is shared time between a project where I would like to contribute code <redshelled>NiAsterisk: thats quite a 12 month plan. I just started with guix like two days ago and I may add lisp or guile for guixsd afer I get done with scala <NiAsterisk>what do you mean? there's guile and lisp in Guix already <redshelled>NiAsterisk: I mean personally learning so I can contribute <rain1>guix has icedtea as well, can run java <redshelled>rain1: that is good to know! I notice how much hate java gets in general in the oss community but i really enjoy scala <NiAsterisk>i consider learning more webdevelopment and java, so eventually if I decide that I want to study it'll be usefull, or if I don't get a job elsewhere I can do freelance webdev work.. anything to just get a start again. <lfam>Yeah, we have some new java stuff, too, like an ant-build-system to abstract the build process for software that uses Ant <redshelled>NiAsterisk: it appears that java will be around for a while, and its pretty well respected in corporate environments if thats your thing. I imagine a java programmer wouldnt struggle too terribly for work <NiAsterisk>yeah. my other perspectives are try to get into IT Sec. somehow (could've recently, but I'm not ready for fulltime stress again) or just work whatever I find part time and have enough time for the other projects around GNUnet. <rain1>is GNU net packaged andworking on guixsd? <NiAsterisk>be welcome to test and add a comment for gnunet-svn on the devel list <NiAsterisk>gnunet-0.10.1 is available, but (described in the threads i opened in the last time) it is old. <lfam>Indeed, it's great when people try patches from the list! We need more people to do that :) <NiAsterisk>I also have no idea if it's just due to 6 people having commit access, or me threading emails in a funny way and no more CC that patches I send sometimes only get accidental attention. <NiAsterisk>not that I want to be pushy, it's just that -devel gets more and more emails per month <rain1>I have to set up my guixsd system a little differently to test this <lfam>NiAsterisk: It's true, things fall through the cracks. The best thing to do if nobody responds to your patch is to try again <lfam>I'm one of the less experienced reviewers, so there are some things I'm not qualified to review. And still, I have a long list of emails to read! <rain1>is there a guide to follow? For patching against the guix packages <NiAsterisk>but isn't that confusing? should we, if infrastructure allows it, have a patches only list? <rain1>not applying patch, but having guix point to an editable repo <lfam>NiAsterisk: Is there any patch in particular you'd like to go over now, on IRC? Sometimes it's easier when the communication is faster than email <lfam>rain1: Can you clarify what you mean? <rain1>sorry I didn't explain it well <rain1>export GUIX_PACKAGE_PATH=/home/rain/Code/repos/pkgs/ <NiAsterisk>no, I'm just waiting for ludovic to review my reply on the gnunet.scm patch set, but that's all iirc. nothing which needs to be rushed. <lfam>NiAsterisk: Maybe it's confusing, maybe not. But "the squeeky wheel gets the grease" <rain1>but I would like to help test gnunet svn so I should git clone guix and point to there instead? (and patch there) <lfam>rain1: So, GUIX_PACKAGE_PATH is for your private package collection, but you can also have the full Guix git repo and work out of that <NiAsterisk>i mean, I did test gnunet-svn, -gtk-svn and 2 more people. I also added a bug which needs people to participate with results to narrow down the issues <rain1>or do I edit ~/.config/guix/latest/ ? <lfam>I do all 3 on my Debian system: Guix installed from the binary tarball, working out of git, and a private package tree <NiAsterisk>the only "issue" is that under certain environments, gnunet-fs stays black <lfam>rain1: You can do that, or you can just configure Guix from git and then use the ./pre-inst-env file that results <lfam>Some users *only* use Guix from a git repo. They never do `make install` or the binary tarball <lfam>If you want to contribute patches, you should have a copy of the Guix git repo that you can use. Whether or not you do everything from that repo is up to you <lfam>NiAsterisk: Can we talk about powwow? So, the issue is that the program works fine, but it's not really suitable as a chat client by default? <rain1>actually I am failing to apply the patch <rain1>patch -p0 < gnunet.patch, patch -p1 < gnunet.patch does not work <lfam>Perhaps the context has changed since the patch was generated? <rain1>could it be because of address@hidden ? <rain1>well if you can post the file instead of patch i could test it <NiAsterisk>sure. did my reply not come through? What I tried to further explain was: initially I had the assumption that powwow at the *.psyced.org location was not patched and the CMDSEP was changed from ; to § (legal) in a config file. When I realized it wasn't I started a powwow-chat.scm which will not be in the master tree ever and can be obtained elsewhere. powwow is a client which can be used to access chat servers <NiAsterisk>like psyced.org, but when you write sentences every ; breaks the line <lfam>Right, I think I understand that. So, your question is regarding what should go in the description? <NiAsterisk>that's why I removed the referencing lines. I can however send in a patch which adds a better explanation. <lfam>Yes, can you send a fresh patch? <NiAsterisk>if you want to, gmane.org does not alter the attachments <NiAsterisk>how you apply it, i don't know. it fixes gnunet description, fixes gnunet-gtk configure, fixes one other package, adds gnunet-svn, adds gnunet-gtk-svn <rain1>if the file exists somewhere I could get that - like a fork of the guix repo? <NiAsterisk>currently I have no web accessible version of this. I could upload the patch again, not rebased against current master, but the master it was based on <NiAsterisk>is this what you mean, having the .patch in a downloadable location? <myglc2>Anyone know why cloning (using dd) the GuixSD HD works to a HD but not a SSD? <myglc2>I get waiting for partition "b1sd" to appear (repeats) <myglc2>ERROR: failed to resolve partition "g1sd" <lfam>myglc2: What command line are you running when you get that error? <myglc2>lfam: Rebooting. The GuixSD welcome screen comes on the SSD and then the OS starts loading and then I get the above mentioned errors <lfam>Okay, is that related to `dd`? <myglc2>I do dd to clone the HD to SSD, then I pull out the HD and try to boot, then I get the above. <rain1>maybe the device numbers changed <myglc2>DUH! Of couse, the HD clone comes up /dev/sda but the SSD /dev/nvme0n1 <lfam>Cool, I hope that it works now! <myglc2>OK how do I tell Guix to run from the different disk? <myglc2>I guess I could reconfigure the system now? <myglc2>Run on the HD and reconfig to point it at the SSD and then It will come up running on the SSD clone? <lfam>I haven't done this yet, but I assume you'd alter either the 'bootloader' or 'file-systems' fields in your OS configuration <myglc2>That sounds right, I'll try it!! Thanks!!! <myglc2>lfam & rain1: re clone to SSD & reboot, no dice. I changed 'bootloader' to point to SSD: '(device "/dev/nvme0n1")' and rebooted but we don't find the root partition on the SSD, which was created with 'mkfs.ext4 -L g1sd /dev/sda1' and mounted with '(device "g1sd")'. <myglc2>Ahem, I did guix system reconfigure and then rebooted <davexunit>shared it earlier but I'm sharing it again ;) <davexunit>it's a rather nice half-way solution since I counted 178 ruby gem dependencies and don't have time to package all of that. <davexunit>I can tell you that it's way easier than making a Docker container! <civodul>i can imagine, for relatively simple cases like this at least <davexunit>yeah, plenty more to do, but I'm a happy camper. :) <civodul>one thing i don't understand: the lines after "openssl" are not executed in the environment, right? <davexunit>civodul: they are. this isn't a proper bash script that you can run. <davexunit>everything after 'guix environment' is run in the sub-shell <davexunit>guess I should have prefixed each line with "$ " to show that it's not a script <civodul>would be nice to use 'guix environment' as the shebang, somehow <davexunit>but I haven't seen an example that doesn't do /usr/bin/env nix-shell <civodul>we could use a fancy binfmt_misc hack! <lfam>Some recent update broke khal :( <davexunit>civodul: I am completely ignorant of binfmt_misc :( <civodul>it's just a way to extend the kernel's shebang handling <davexunit>civodul: I'd love one that extends the maximum shebang length ;) <davexunit>every time I think about the shebang length limit I get mad. <myglc2>civodul: /dev/mvme0 = Samsung 'SSD 950 PRO NVMe' plugged into an adapter in PCIe slot = ~4x faster than SATA partly because Linux Kernal supports alternate (NVMe) access mechanism with 'mvme' prefix instead of 'sd' <lfam>A test started failing. I'm going to try to find the change "by hand" since bisecting back to mid-January will be so expensive! <civodul>davexunit: for now, 127 bytes "should be enough for everyone" <civodul>lfam: could it be that the test is non deterministic? <lfam>civodul: I wish! I ran it several times <myglc2>civodul: I had the SSD it in my Debian server RAIDed with 2 HDs & set read preferrentially from the SSD. That is where I want to go on GuixSD now. <davexunit>now that I have a more-or-less working GNOME, I really feel like I'm using a "real distro" <lfam>khal's failing assertion: <lfam>E assert ('VCALENDAR',...set([]))]))])) == ('VCALENDAR', ...set([]))]))])) <myglc2>civodul: for now I am just trying to run from the SSD w/o RAID. <lfam>I assert those strings are the same! <lfam>Oh, there is a space after the comma in the second string <lfam>Of course, all the "likely suspects" in the commit history are my own commits ;) <lfam>Wow, the sheer volume of commits... <chewieQC>Does guix support projects written in Go? <bavier>chewieQC: someone has been working on a gcc-go package <chewieQC>Bavier: Nice! Is it coming along nicely? <bavier>I don't recall the latest status