IRC channel logs

<davexunit>the thing that all these Docker-alikes do that grosses me out is the complete reliance on disk image layering via overlayfs, aufs, or btrfs subvolumes.

<davexunit>people say "Docker is about containers, it's about packaging"

<davexunit>well, Docker is the worst package manager ever and Guix is clearly much better suited for the job.

<davexunit>so maybe I can work that angle to promote running containers with Guix

<ryouma>that could be a killer feature, iiuc

<rekado-> http://dustycloud.org/blog/why-i-am-pro-gpl/ <--- yay!

<amz3>héllo :)

<sir123>Hello everybody, me again :) I'm trying to work out why my make check is failing. I have two failures: packages and guix-register. I have the logs but nothing is standing out as obvious. I have added one custom package which I think works.. Any advice?

<sir123>hello amz3 :)

<sir123>i think it's something to do with the builder, I cant ./pre-inst-env guix build.

<sir123>How do I test around that?

<amz3>I will try the builder on my side

<amz3>sorry I just tried the builder, it works. Can you paste the errors and the package you've written?

<amz3>sir123: ^

<sir123>Sure

<amz3>I'l try to help...

<sir123>Thanks pal, i'm copying into paste.lisp now

<sir123> http://paste.lisp.org/+39CH is the package I wrote...

<sir123>and the test-suite.log is annotated.

<sir123>The guix-daemon isn't an online system, it's implemented locally on the machine you're using

<sir123>Mine just isn't building for some odd reason...

<sir123>I think it can't talk to the guix-daemon, although I don't know how to fix that

<sir123>There's some mention in the manual about setting up the daemon, but I have issues getting that to work anyway

<sir123>I assumed there must be a working daemon for the system to work at all, so I'm puzzled as to why it can't use that one

<amz3>sir123: can you build another program like guix package -i markdown

<amz3>I understand you use guix over another distro, isn't it?

<sir123>amz3: You can, or there is a distribution called the Guix System Distribution, which runs only free software, that is what I am running on :)

<sir123>or GuixSD

<amz3>then guix-daemon should be working

<amz3>what is the error when you do ./pre-inst-env guix build ?

<sir123>i have downloaded the source code for Guix, and have tried to get a new package working

<sir123>guix package: error: failed to connect to `/gnu/store/guix/daemon-socket/socket': No such file or directory

<amz3>ah!

<sir123>The newly built system doesn't recognise the daemon

<amz3>during configure phase you did not pass the correct --state-dir or something

<sir123>I assume it was /gnu/store

<sir123>I may be wrong

<amz3>here is what I have in my config.log:

<amz3>./configure --with-libgcrypt-prefix=/home/amz3/.guix-profile --prefix=/

<amz3>they are issue with fbset recipe

<sir123>so you set the state-dir to plain root?

<sir123>I'm confused

<amz3>but we will see that after you need to configure --... && make the guix git repo again with the above

<amz3>the statedir is not plain root

<sir123>you didn't specify it in your explanation

<amz3>it's computed by the configure script to guix_localstatedir='//var'

<amz3>/gnu/store is the stare library

<amz3> /var is the state library

<amz3>s/stare/store

<sir123>of course

<amz3>I'm trying to build fbset

<sir123>I'm rebuilding my system now

<sir123>thanks amz3 for your help :)

<amz3>nop :)

<bavier1>sir123: building guix on GuixSD from git, you'll need to pass "--localstatedir=/var --sysconfdir=/etc" to configure

<sir123>There's no mention og --sysconfdir in the manual

<sir123>*of

<bavier1>sir123: no, there's also not much else on developing guix on guixsd

<sir123>Or a suggested default for localstatedir

<bavier1>sir123: though looking at the package recipe for the "guix" package in (gnu packages package-management) is useful

<sir123>I was on here yesterday when mark_weaver told me to add new files to gnusystem.am, never would have guessed that on my own

<sir123>*gnu-system.am

<amz3>it's required to add files to gnusystem.am this is an optional step during the development of the recipe... kind of

<amz3>bavier1: because you do make, if you don't, you don't need it

<amz3>before submitting the patch you need to add it to the .am file

<amz3>otherwise it's not tracked by the autotools

<sir123>The manual makes it sound like the system will pick it up on its own

<sir123>When would you not need to make?

<amz3>well, Like i said I'm not a specialist, but I only use make the time and then before submitting the patch to check that my gnusystem.am rule is ok

<amz3>s/the time/the first i build guix/

<amz3>guix build will pick up the new recipe without having to run make

<sir123>wouldn't you have to rebuild to get the package registered to ./pre-inst-env guix lint && ./pre-inst-env guix build?

<amz3>no

<sir123>really? interesting

<sir123>that's awesome

<amz3>./pre-inst-env is setting environment variable so that you don't need to recompile

<sir123>civodul is a genius

<amz3>Sorry, it's guile behavior, if the source is more recent, guile picks up the source file

<amz3>sir123: I added two lines http://dpaste.com/3C98EN1

<amz3>it's still doesn't work for some reason

<amz3>it says that : No rule to make target 'modes.tab.h', needed by 'lex.yy.o'. Stop.

<amz3>also I think that the two new inputs I added should go to 'native-inputs' field, which means that they are not required to run the program

<sir123>The Debian info I adapted this from made no mention of flex or bison

<amz3>because it's build time dependency maybe?

<amz3>native-inputs means build time dependency (I think)

<sir123>I dunno

<sir123> https://packages.debian.org/sid/fbset

<sir123>check it out

<amz3>I'm sure, bison and flex are build time dependencies

<amz3>those are runtime dependencies

<sir123>maybe debian assumes they are already there provided by the base install

<amz3>there should be a debian build dependency somewhere

<amz3>I prefer to look at gentoo recipes, they have the same information as guix recipes

<sir123>smart

<sir123>gentoo forums have same problem you mentioned

<amz3> http://gpo.zugaina.org/AJAX/Ebuild/2896849/View

<sir123>what do you make of this:

<sir123> https://forums.gentoo.org/viewtopic-t-348186-view-previous.html

<amz3>DEPEND is build time dependency and RDEPEND is runtime dependency

<sir123>you are correct sir

<sir123>:)

<sir123>I never played with gentoo. Is it any good?

<sir123>i know they recommend non-free software

<sir123>at lease according to the FSF

<amz3>gentoo is fast but it's not very friendly

<amz3>less friendly that guix i think

<sir123>evidently that would be because every package is custom for the user

<amz3>you sent me the wrong link, no? I lookup duckduckgo and it seems like it's typo in the makefile

<amz3> https://github.com/joelagnel/meta-openembedded/blob/master/meta-oe/recipes-support/fbset/fbset-2.1/fbset-2.1-fix-makefile-dep.patch#L24

<sir123>no it was a forum

<sir123>maybe

<sir123>sorry i read it wrong

<sir123>maybe. I'm going to try this make check now

<amz3>another thing you need to move the package definition to xorg.scm

<sir123>does it relate to xorg.scm? I wasn't sure where it belonged tbh

<amz3>I think so, ask later mark or civodul or rekado

<amz3>fbset is a xorg tool

<amz3>the other thing is that the source needs to be patched to compile

<sir123>I just really wanted to resize my virtual consoles :)

<amz3>search for 'patches' in the recipes for examples on how to do it.

<amz3>:)

<sir123>how long you been hacking on guix?

<sir123>Spot the error! http://paste.lisp.org/display/152081#2

<amz3>not long enough to understand the error

<sir123>That's all there is

<amz3>I just packaged one or two software so far

<sir123>ok

<amz3>and started to write a new command

<sir123>I'm "working" on packaging this one

<sir123>and failing horribly :)

<amz3>nah

<amz3>make check error is something

<amz3>package is something else

<sir123>it's certainly challenging

<amz3>one thing at a time :)

<amz3>sir123: I gonne make some coffee do you want some ?

<sir123>White two sugars

<amz3>:))

<sir123>thanks

<sir123>:)

<amz3>sir123: here is your cup of coffee white two sugars [_]

<sir123>Tkank you sir *takes coffee*

<sir123>*puts on dark sunglasses*

<sir123>Let's do this!

<sir123>*start super hacking music with lots of jump cuts and screens of streaming text*

<sir123>Nuh I got no idea

<amz3>sir123: where you are blocked?

<sir123>i don't know the next step. What do I do with an error log tht doesn't explain what is going on

<amz3>forget the `make check`

<amz3>try to guix build the recipe

<sir123>AH! Invalid input eudev

<sir123>It's even got the solution! Awesome!

<amz3>replace ' by quasiquote char `

<amz3>ah :)

<sir123>What's the quasiquote character?

<amz3>antiquote

<amz3>`

<amz3>this allows to use unquote ',' inside the quoted form

<amz3>',' is a shorthand for 'unquote' it says, "eval this if inside a quasiquote"

<sir123>works like a charm

<sir123>except for

<sir123>modes.tab.c

<sir123>and lex.yy.c

<amz3>you did no use the paste I sent you

<sir123>which is exactly what you said

<amz3>no this not the same I think

<amz3>the last error I have is about modes.tab.h

<sir123>the makefile you mentioned fixed 'modes.tab.h' to 'modes.tab.c', this is failing 'modes.tab.c'

<sir123>check the forum thread i linked to on gentoo

<amz3>sorry i did not paste the link I will do it again

<sir123>of course flex and bison

<sir123>sorry my error

<amz3> http://dpaste.com/39TH41H replace the (define-module (xorg)) thing by something correct

<amz3>it's not a xorg utils

<amz3>ah!

<amz3>I read bgset

<sir123>what's your idea

<amz3>N

<amz3>?

<sir123>the 'ah'

<amz3>"it's not a xorg utils"

<amz3>I was reading bgset instead of fbset for some reason

<sir123>so what do we file it under?

<sir123>ok

<amz3>I don't know

<amz3>rekado-: where can we place fbset inside gnu/packages?

<amz3>sir123: anyway, you need to add patch like on the github link to fix the makefile

<sir123>yeah i was just thinking that

<rekado_>woo, congratulations on the new release!

<sir123>do i put it under the patch-source-shebangs?

<sir123>sorry I don't know how this works

<amz3>I don't know what is patch-source-shebangs

<sir123>the man of the hour arrives

<civodul>Hello Guix!

<civodul>it's out!

<sir123>congrats civodul

<amz3>congrats

***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | 0.8.3 is out! https://savannah.gnu.org/forum/forum.php?forum_id=8324 | This channel is logged, see <https://gnunet.org/bot/log/guix>.'

<sir123>*claps*

<civodul>:-)

<amz3>:)

<sir123>i'm really looking forward to Guix Hurd, that'll be awesome!!

<civodul>so if someone could put https://savannah.gnu.org/forum/forum.php?forum_id=8324 on HN, Reddit, and whatnot, that'd be great :-)

<amz3>I will do it on HN if it's not done in 8 min

<yenda>sir123: hurd is still alive ?

<sir123>following the mailing lists it seems taht way

<yenda>amz3: give the link when you do so

<sir123>is libreoffice complete in this release?

<sir123>guix size looks like it will be valuable

<civodul>sir123: yep, LO is there

<sir123>civodul: WOOHOOO

<sir123>oh yeah, civodul: what would you say about guix show showing the lit of executables the package provides?

<sir123>*list

<sir123>I think it'd be a nice feature to have

<civodul>well, often one can do: ls $(guix build thepackage)/bin

<civodul>what you suggest could only work if the package is on-disk, as things currently are

<sir123>i was thinking of the use case of:

<sir123>I want to get a program.

<sir123>I know the program's name

<sir123>but I don't know the package name

<civodul>yeah

<civodul>the short answer is: we don't know how to handle it

<sir123>so i do a guix package -s (nameofpackage)

<civodul>we could build a database of programs on hydra, but that's not necessarily desirable

<sir123>i guess so

<sir123>thanks civodul :)

<amz3> https://news.ycombinator.com/item?id=9928563

<sir123>nice

<sir123>guix edit looks AWESOME

<sir123>I'm so looking forward to using it

<civodul>heh

<civodul>thanks amz3!

<civodul>ACTION upvotes

<sir123>how do we upgrade a running GuixSD? guix pull?

<civodul>yes, guix pull && guix system reconfigure

<sir123>be back in a mo, I NEED to run this

<sir123>this is exciting

<amz3>indeed :)

<yenda>you need sudo do to guix reconfigure right ?

<alezost>yenda: if you mean "guix system reconfigure" then yes, you need root rights; for "guix system build" you don't need sudo

<yenda>I got the following error with guix system reconfigure http://pastebin.com/f62zBp4J

<amz3>yenda: there is a recent thread on the mailling check it to see whether there is relevant information

<amz3>I can't read the traceback

<davexunit>happy release day!

<davexunit>upvote our HN thread! https://news.ycombinator.com/item?id=9928563

<davexunit>also, upvote our reddit thread! https://www.reddit.com/r/linux/comments/3e6skl/gnu_guix_083_released/

<amz3>yenda: there is: no code for module (guix build syscalls)

<amz3>which means it doesn't find the file for that mofule

<amz3>it's bit slow on HN. Seems like people got bored or something

<amz3>davexunit: ^

<davexunit>amz3: I like to time my posts for the beginning of the US east coast work day

<davexunit>and promote the link on gnu social, pump.io, and twitter simultaneously

<davexunit>I've had pretty good luck getting guix announcements to the front page with that strategy

<amz3>you are GMT-6?

<davexunit>-5 I think

<davexunit>I honestly never remember

<amz3>the US is very different place than say France, at least by the numbers

<davexunit>daylight savings time and all that

<davexunit>sigh, the first comment about our release on reddit: "Still can't get device automonting in XFCE by default."

<amz3>he right, that what users look for

<amz3>even dev users

<amz3>I don't care myself, but it's helpful to have that

<davexunit>I agree

<amz3>maybe they are always pluging usb keys all day long

<amz3>at my previous job I was doing mount/umount dozen of times a day :))

<davexunit>but it's one of those comments that show that people don't know what "alpha" means

<amz3>the story about how people don't understand docker, made me realise how superficial the knowledge of lot of doers/makers/HNers. They use it but they don't really care what under the hood

<amz3>distro is said to be especially difficult to spread/adopt

<amz3>docker & containers

<davexunit>I wonder how we can get lwn.net to write about us

<davexunit>I'd like our release announcements to make it over there

<amz3>I don't follow lwn.net but it doesn't seem that difficult, they did an article about magit :))

<amz3>(I don't use magit, so far...)

<davexunit>magit changed my life

<davexunit>I never want to use git without it

<davexunit>do people still read slashdot? http://slashdot.org/submission/4664685/gnu-guix-083-released

<amz3>ACTION not anymore

<amz3>there is no article about nixos on lwn.net except a link to a blog article. which is nice but not a proper article

<davexunit>civodul: have you ever tried mailing lwn@lwn.net a release announcement?

<amz3>(i prefer the days of slashdot really)

<iyzsong>oh, new release, that's great!

<amz3>(also slashdot software is better)

<civodul>davexunit: i think i did that once

<iyzsong>I forget the reason why gvfs is still not packaged, needed for 'auto-mounting' I think.

<davexunit>iyzsong: ah okay

<civodul>davexunit: i've just resent it to lwn, we'll see

<davexunit>iyzsong: I thought it might be a bug in our thunar-volman package

<civodul>davexunit: regarding timing, i was also wondering whether whether we should wait until you wake up

<civodul>that would seem to be a good strategy, indeed

<iyzsong>davexunit: I don't know the detail yet, will look into it in the weekend.

<davexunit>iyzsong: cool, no rush. the release is done. :)

<iyzsong>sure :-)

<davexunit>civodul: yeah, either time it for the US east coast or the US west coast to get the silicon valley crowd.

<davexunit>though I've read some research that concluded that there isn't a strong correlation between time of posting and getting to the HN front page.

<civodul>heh

<davexunit>in my experience, getting several upvotes shortly after submission time does the trick.

<civodul>yeah

<civodul>i don't know why we got so few

<davexunit>I like to think it's my social spam but it could very well just be dumb luck

<civodul>:-)

<civodul>communication is hard

<davexunit>yup

<davexunit>I say we fire our entire marketing dept.

<davexunit>we're just not seeing the sales we expected

<civodul>haha :-)

<davexunit>I outbid red hat for ads at the Boston Logan airport and it still didn't increase industry adoption

<davexunit>(Red Hat frequently has large ads displayed there)

<yenda>next release I'll get you more votes

<davexunit>;)

<davexunit>I want to figure out how to better "market" guix to docker enthusiasts.

<davexunit>I had a bit of a disheartening exchange with one on HN last night.

<davexunit>they didn't care about Guix's ability to deduplicate files system-wide because Linux can deduplicate multiple instances of the same shared library in RAM and file systems like btrfs can do the disk deduplication

<davexunit>so having multiple container images that duplicate tons of stuff isn't a big deal.

<amz3>(why not publish another news?)

<davexunit>amz3: it would be a repost

<amz3>I think the best thing about guix container is guix. You sould maybe go the "puppet/docker-equivalent-of-puppet is not as good as guix"

<davexunit>well, as people say, docker isn't about containers, really. it's about the tools it builds around it.

<davexunit>the "packaging"

<davexunit>and of course my argument is that guix does the packaging part much better.

<amz3>maybe it's better to just to the thing, and people will get it one day

<amz3>without wasting energy

<amz3>docker is very strong

<davexunit>yeah, well of course I working both angles.

<davexunit>a bit of evangelism and a bit of hacking.

<davexunit>I'm*

<yenda>by packaging they mean the packaging arount docker, not of docker

<yenda>.ie the tools

<davexunit>they mean DockerHub and the "packages" that Dockerfiles represent.

<yenda>I know one of docker's top contributor I'll talk to him about guix once I'll know more about it to debate

<yenda>also the hype

<amz3>docker very strong is

<yenda>I'm still unable to guix reconfigure system

<amz3>unable to reconfigure system I am

<amz3>:o)

<yenda>execute "guix reconfigure system"

<yenda>what I meant it is

<civodul>yenda: could you paste details somewhere, but not on pastebin?

<civodul>davexunit: speaking of Docker, i added the screenshot at http://www.gnu.org/software/guix/screenshots/0.8.3/guix-system-vm.png in the hope that it would be "food for thoughts" for Docker fans ;-)

<yenda>ok, something is wrong with pastebin ?

<davexunit>civodul: I like it!

<davexunit>yenda: pastebin prevents tor users from using it

<yenda> http://paste.lisp.org/+39CN

<civodul>yenda: it looks like the bug davexunit fixed in 1e49bcf

<civodul>on July 10th

<civodul>did you try "sudo guix pull"?

<civodul>(assuming you were running "sudo guix reconfigure")

<davexunit>people at my office are beginning to be interested by guix

<davexunit>I might be able to work it in as a supplementary package manager for certain things.

<yenda>i'm trying to make them to and they are intrested too, but the force is storng with docker

<yenda>civodul: ty I forgot sudo for guix pull

<davexunit>yenda: the plan would be to use guix the package manager, not guixsd the distro.

<davexunit>that way we can work it into our existing Chef recipes and our developing Dockerfiles.

<davexunit>sounds like a very good stepping stone, to me.

<yenda>awesome guix edit

***jgay_ is now known as jgay

<yenda>if I add/remove a package from my config.scm file I just have to do sudo guix system reconfigure without the need to reboot ?

<iyzsong>yes, the reconfigure is for /run/current-system/profile, you can also use manifest (guix package -m) which manage ~/.guix-profile.

<davexunit>I shamelessly resubmitted the release notes to HN, this time using the mailing list archive: https://news.ycombinator.com/item?id=9929809

<davexunit>hn front page!

<davexunit>I truly do have the magic touch.

<davexunit>;)

<davexunit>and off the front page

<davexunit>that didn't last long

<iyzsong>yeah :-

<davexunit>oh well. maybe we got a few extra hits from it.

<rekado_>sourceforge is still down. wow.

<rekado_>(part of me hopes it stays like this, but I rather not feed that part of me.)

<davexunit>hahaha

<rekado_>ACTION imagines a point in the future where github fades away like sourceforge.

<civodul>rekado_: http://guix.mdc-berlin.de is pretty nice! :-)

<davexunit>civodul, rekado_: wow!

<civodul>davexunit: your code in production already ;-)

<davexunit>rekado_ is on the bleeding edge

<civodul>i can extrapolate that there's a clear trend of organizations all around switching to Guix for production

<davexunit>;)

<amz3>which kind of organisations?

<davexunit>the best ones

<init>not just the best, the best kind of the best organizations

<davexunit>phoronix summarized release notes: http://phoronix.com/scan.php?page=news_item&px=GNU-Guix-0.8.3-Released

<amz3>pfff

<amz3>is UN part of those organisations ?

<civodul>the Phoronix article is good

<civodul>often they would just copy/paste stuff, but here it's better

<remo_>Hello there! I just installed GNU Guix, and it's running fine (although I ran into a few minor bumps along the way). I'm excited about the project! Thank you for starting it.

<davexunit>remo_: welcome aboard!

<civodul>remo_: thanks for your warm feedback!

<civodul>remo_: what were the "minor bumps"?

<civodul>interesting paper on "truck factor": https://peerj.com/preprints/1233v1.pdf

<remo_>civodul: the biggest of the bumps was the fact that upon boot from the USB stick image, there was insufficient space on / to support the pre-packaged "desktop" config.

<remo_>When I did "guix system init" using the sample "desktop" config, the build failed a few hours in because /tmp filled up with about 1.3 GiB of stuff during the "mesa" build, which was too much for the root fs.

<davexunit>remo_: looks like you forgot to run the cow-store service

<davexunit>also, the installation shouldn't build anything from source

<remo_>I did run that; the problem was that nix-build seems to fill up /tmp (which is part of /) with temporary build artifacts

<davexunit>hmmm

<remo_>I performed the steps in the manual and it took about 6 hours to build on my laptop. I had to mount a larger file system on /tmp to get past the issue, though.

<yenda>the problem is the manual it's not clear in it that you have to authorize hydra key for prebuilt packages

<yenda>remo_: if you authorize hydra the whole install takes less than 20 min

<remo_>also, my laptop only has 2 GiB of memory, so that is most likely the root cause of the lack of space. Anyone with a little more RAM probably would have been fine.

<remo_>yenda: How do you do that? If there's a single step and it's easy, perhaps it should be in the manual as a suggseted step for those who do not mind using the cached artifacts.

<remo_>I mean, the prebuilt packages

<davexunit>ACTION thought that hydra was already authorized for the install images

<davexunit>civodul: is this not the case?

<remo_>I recall seeing the build download things from hydra and then alsobuild things

<remo_>But it certainly did compile many things, run many tests, and took about 6 hours, so it must have been building at least some things from source.

<yenda>no it's no davexunit , I did 5 installs in the last few days and everytime if I didnt' authorize first it would compile the world

<yenda>remo_: guix archive --authorize < hydrakey

<yenda>to find the key I used find / -name "hydra.gnu.org.pub" I don't know if it's the best method though

<yenda>since it's in the store you can even "find /store -name "

<remo_>so basically you have to feed in the public key to guix archive --authorize on stdin?

<davexunit>yeah

<davexunit>I really thought this shouldn't be necessary on our installation images. could've been an oversight on our part, but I'm not sure... waiting on someone with more knowledge.

<remo_>If I want to persist the output of guix system init for later inspection (e.g. to see if maybe it did try to get cached packages first, but fell back to fetching and building the source because of some failure), how would I do that?

<remo_>I will try rebuilding my system later today to see if authorizing the hydra key results in a faster build

<davexunit>you could redirect stdout and stderr to a file

<remo_>Oh, I suppose I could. I'll just do that, then.

<davexunit>you won't be able to see the output unless you tail that file from another tty

<davexunit>or use tee or something

<remo_>I'll give it a shot and let you know how it goes!

<davexunit>okay

<davexunit>good luck

<yenda>remo_: there's no question about it it will speed up the install since you won't build most of the packages anymore

<civodul>davexunit, remo_: the installation image normally has hydra.gnu.org authorized

<civodul>not sure what happened

<davexunit>okay that's what I thought

<civodul>remo_: could you check what's in /etc/guix/acl?

<remo_>Oh, more feedback: the manual did not mention that the user which comes from the provided "desktop" config file will be locked - i.e., its encrypted password entry in the /etc/shadow file starts out as "!". I had to remove that ! to be able to log in as the user account.

<civodul>remo_: it's mentioned at https://www.gnu.org/software/guix/manual/html_node/User-Accounts.html but often overlooked

<remo_>Most people installing guix might know how to fix such a basic thing, but it would be worth calling out in the manual (or, if it's possible to somehow address the issue in the config file template, that would also be good)

<civodul>so maybe we should mention it elsewhere too

<remo_>Oh. I didn't see it in the installation steps, so I missed it, too.l

<remo_>I think it should be mentioned there briefly, m aybe with a link

<civodul>yeah, good ideea

<remo_>The file /etc/guix/acl contains the hydra.gnu.org.pub RSA public key

<remo_>But I don't know if that means anything, since that file was probably installed during the build itself

<civodul>it means that substitutes are enabled

<civodul>does "guix build inkscape -n" suggest that things would be downloaded?

<yenda->maybe guix pull before system install ?

<yenda->that's what I had to do

<davexunit>shouldn't be necessary

<remo_>civodul: when i run that command, it says that 2 derivations would be built, and something like a dozen would be downloaded.

<remo_>correction: something like a dozen files would be downloaded, it says

<civodul>ok, so that means substitutes are working

<civodul>so the thing should be downloaded pre-built binaries most of the time

<remo_>I have to run, but I'll try some of these things and let you know what works (or doesn't work). Thanks for the suggestions!

<civodul>thank you

<davexunit>civodul: the FSF has posted about our call for hardware/hosting donations on the various social media sites they post to

<yenda->davexunit: you were talking about adding support for containers earlier what did you mean exactly ?

<davexunit>yenda-: using Linux namespaces and cgroups to create lightweight virtualized environments.

<davexunit>similar to VMs, but also quite different.

<yenda->and you'll have a system definition just like the one you install guix with ?

<davexunit>yes, that's one use-case

<davexunit>another use case is to just run an arbitrary program in a container

<davexunit>containers are cheap to create, so it's very easy to do this. this will be an extension of 'guix environment'

<davexunit>for example: 'guix environment --container --ad-hoc guile' would create an isolated container environment in which you can run guile.

<civodul>davexunit: do you have pointers to what the FSF wrote?

<davexunit>civodul: yup, it was short. <140 chars. one sec.

<davexunit>civodul: https://quitter.se/notice/3890901

<civodul>thanks!

<civodul>this is nice

<davexunit>I guess RMS suggested that they post about it

<davexunit> https://microca.st/fsf/note/MDEbPgWzQNutoNG8_UoXoA

<civodul>heh, you know how it works ;-)

<civodul>he got in touch with me after i sent a message on g-p-d mentioning it

<civodul>so yeah, that looks like the aftermath of that

<davexunit>cool

<paroneayea>wooo

<civodul> https://www.parabola.nu/news/parabola-support-for-mips64el-discontinued/

<davexunit>:(

<davexunit>I wonder what the long term viability of our mips port is

<civodul>yeah

<davexunit>we certainly need more mips users than mark if it is to stay maintaned

<davexunit>maintained*

<davexunit>and ever hope to boot guixsd on it.

<rekado->are there any usable mips machines available other than the early loongson devices?

<civodul>my understanding is that the latest ones require non-free firmware

<civodul>which makes them completely unattractive

<mark_weaver>the same is true of the latest intel and amd machines

<mark_weaver>I probably won't be putting a lot of effort into making mips64el support better, but for the moment I'm motivated to keep it from regressing, at least.

<mark_weaver>it may be that we should move it to the N64 ABI at some point.

<mark_weaver>I wouldn't be surprised if more things compile and run properly on the N64 ABI, since it is closer to x86_64.

<mark_weaver>some other things are broken because of my desire to support page sizes > 16K, which maybe I should give up on.

<mark_weaver>later Loongson laptops require a non-free blob for the video to work, but I suspect they could be run headless without it.

<mark_weaver>I'm not hopeful that we'll be able to run any future Intel systems without blobs.

<mark_weaver>some folks on #libreboot think that there's some hope that we could influence AMD, who is also moving in that direction.

<civodul>yeah, i wonder what's gonna happen

<mark_weaver>there considerably more hope in the ARM space, since there is so much more diversity there.

<francis7>I have very little hope. This business with the KGPE-D16 is a shot in the dark.

<mark_weaver>Last I looked, the situation with Loongson was not nearly as bad. Their choice of video accelerator is an issue, but that's not as fundamental as the issues in the Intel and AMD chipsets.

<mark_weaver>and video is a deep problem for us, not specific to Loongson.

<mark_weaver>ACTION goes afk for a while

<daviid>these processors running specific OSs is pretty depressing!

<davexunit>ACTION rebases wip-container on master, everything still works :)

<civodul>yay!

<civodul>damn, why can't i reproduce this tar timestamp warning?

<davexunit>:(

<davexunit>civodul: do you have any thoughts about how 'guix environment' could possibly work from inside a container with a read-only store? I guess it just can't.

<davexunit>maybe an overlayfs?

<davexunit>so the guix daemon inside the container can pretend it has a mutable store... but then the localstatedir needs to be there.

<davexunit>okay, this is probably just a bad idea.

<civodul>well you don't need guix-daemon inside the container, do you?

<civodul>and the store is read-only anyway, unless you run 'guix environment' as root

<civodul>so what's the matter? :-)

<davexunit>not really, but I was curious if I could launch a guixsd container that has the illusion of having its own store

<davexunit>such that 'guix environment' worked as if I weren't in a container

<davexunit>for recursive container fun times.

<civodul>aah!

<civodul>same problem with 'guix system vm' actually

<davexunit>yeah

<davexunit>seems to be a bridge too far right now.

<civodul>the installation image works around it by using #:volatile-root?

<civodul>which uses a unionfs

<davexunit>bam

<davexunit>need something like that.

<civodul>i don't remember why 'guix system vm' doesn't do that actually

<davexunit>though the container has an additional complication since it just bind-mounts /gnu/store

<davexunit>I guess the localstatedir needs to come along for the ride

<civodul>ah yes

<civodul>hmm

<davexunit>again, might be undesirable, since any builds/downloads that happen in the container will be tossed

<civodul>lost

<davexunit>might be best for 'guix environment' to be a first-order thing ;)

<davexunit>yes

<davexunit>thrown out when the tmpfs goes away

<civodul>well it would be nice eventually to have recursive things

<civodul>i occasionally miss the ability to talk to the daemon in VMs

<civodul>at worst, we could easily write services that mount unionfs on /gnu/store and /var/guix

<davexunit>so I could bind mount both the store and the localstatedir, but then there's still an issue, I think.

<civodul>but with luck, we might even be able to do that with 'file-system' declarations

<davexunit>what if the host system writes to the "real" /gnu/store

<davexunit>and daemon in a vm/container wants to build the same store item

<civodul>good question

<civodul>i think the host will win

<davexunit>or the sqlite db changes

<civodul>because the host will take a lock, which the guest will see

<civodul>whereas what the guest does will be invisible to the host

<davexunit>yes

<davexunit>but how does the daemon react to a store item already being populated that it doesn't think should be populated?

<civodul>i think it's fine

<davexunit>or what happens to the unionfs when both the base file system and the tmpfs on top have changed a file?

<civodul>that's what happens when we run 'make check -j4'

<davexunit>oh, and things just work?

<civodul>yes

<civodul>the only thing that can break it all is GC

<civodul>which is why tests/guix-gc.sh runs after all the other tests have completed

<davexunit>that's a reasonable caveat, I suppose.

<civodul>yeah

<davexunit>I can try bind-mounting /var/guix real quick

<davexunit>should be simple now

<davexunit>but ah the unionfs, need to figure out how to set that up.

<civodul>right

<davexunit>no way to encode that detail in a <file-system> object

<civodul>see mount-root-file-system for an example

<civodul>dunno!

<civodul>it's a FUSE file system, so normally you run the 'unionfs' command by hand

<civodul>but ISTR the 'mount' command would somehow figure out what to do

<civodul>(or the 'mount' syscall)

<davexunit>so I could tell mount that the fs type is unionfs?

<civodul>maybe

<davexunit>okay, I will look into it, then.

<davexunit>gotta go now.

<civodul>i can't find what made me think so

<civodul>ttyl!

IRC channel logs

2015-07-22.log