IRC channel logs


back to list of logs

<vmlinuz88>anybody have any ideas?
<paroneayea>hey, does anyone have a nice simple system definition for launching with "guix system vm" that I can snarf?
<paroneayea>I'd love to give that a test.
<davexunit>paroneayea: build-aux/hydra/demo-os.scm
<davexunit>$(guix system vm build-aux/hydra/demo-os.scm)
<davexunit>in bash, that will build and launch the VM
<paroneayea>nice thx davexunit
<paroneayea>davexunit: what's with the $()
<davexunit>paroneayea: bash will evaluate the output of the command within
<davexunit>guix system vm returns a store item path that is an executable script
<davexunit>so that is substituted for the $(...) expression
<paroneayea>thx davexunit
<Tsyesika>well it said the command was successful but it won't boot
<Tsyesika>i don't believe it installed grub
<Tsyesika>i guess guixSD is not to be for tonight
<Tsyesika>is there a guix command which will just install grub
<Tsyesika>i don't just mean pull down the package and such but actually run the grub install on the HDD
<Tsyesika>maybe i can chroot in and run the grub install commands manually
<davexunit>Tsyesika: I don't know off the top of my head, but you'll find the code that does it in gnu/ somewhere in the source tree
<Tsyesika>okay thanks
<Tsyesika>i wanna get this working but at the same time i need a working laptop soon as i'm travelling
<paroneayea>eek, make /dev/kvm 666?
<paroneayea>is that safe?
<davexunit>paroneayea: it's alright as a hack
<davexunit>of course, you don't have to do this hack on guixsd
<paroneayea>booting guixsd from qemu now...
<paroneayea>woohoo, hey it's working :)
<davexunit>Tsyesika: the one time I installed GNU/Linux on a mac I had bootloader issues
<davexunit>so maybe there's some special hack that we're not doing
<paroneayea>davexunit: Tsyesika said she had it working with trisquel tho...
<davexunit>yeah I know
<davexunit>not sure what trisquel does different
<Tsyesika>davexunit: all other distros seem to manage okay and i've installed gentoo and the likes
<davexunit>so does the bootloader not install at all or what?
<Tsyesika>i don't believe it is installed at all but the command didn't report any problems
<Tsyesika>when chrooting into the system what do i need to setup to get at the software
<Tsyesika>i am guessing there is some script which sets up all the paths for me
<davexunit>there's probably something you could run, but I don't know it.
<davexunit>i did a simple chroot the other day
<paroneayea>hm, how to shutdown this thing :)
<davexunit>sudo halt
<davexunit>Tsyesika: I created a directory like /my-chroot and bind mounted /gnu/store to /my-chroot/gnu/store
<davexunit>and then bind mounted the OS build to /my-chroot/system
<davexunit>then I ran 'chroot /my-chroot /gnu/store/blahblah-bash-x.x.x/bin/bash'
<davexunit>oh but wait, you've already installed the system
<davexunit>so you can ignore pretty much everything I've said
<Tsyesika>the grub package isn't even installed i don't think, there is nothing under /gnu/store/*grub*
<davexunit>a 'chroot /your/install/dir /path/to/bin/bash' should do the trick
<Tsyesika>no dirctory exists
<davexunit>'find /gnu/store -name "*grub*"' ?
<Tsyesika>davexunit: well that does get me into a bash session but i have to type out the full paths i was wondering if there was an easier way but looks like grub isn't installed and i can't install it once i've chrooted in as i need the guix daemon
<davexunit>is that roughly what you did
<davexunit>Tsyesika: you might be able to do 'export PATH=/run/current-system/profile/bin' or something
<davexunit>I don't know if that's available until after booting, though.
<Tsyesika>shouldn't the installer have installed the grub package at least even if it didn't manage to install grub onto my hdd
<davexunit>Tsyesika: can you paste your OS config?
<Tsyesika>yeah sure
<Tsyesika>lemmi install curl again
<davexunit>at the very least I can run 'guix system build' and see what happens
<Tsyesika>*it's very little modification over the sample config
<Tsyesika>these are a lot of deps for curl
<davexunit>some questions with likely obvious answers: is /dev/sda really the device for the disk you want the bootloader installed to?
<davexunit>did you actually label the partitions root and home?
<Tsyesika>i did label them with the -L flag on mkfs.ext4 as the docs suggest
<Tsyesika>and /dev/sda is the path of the disk so, i guess so?
<davexunit>and there's only one disk, right?
<Tsyesika>yep one disk
<Tsyesika>one thing to note is it's gpt as macs are a bit funky about this
<Tsyesika>it does have a bios boot partition or whatever
<davexunit>GPT is probably the culprit
<davexunit>we might not support that yet
<davexunit>all my systems use an msdos partition table
*Tsyesika nods
<Tsyesika>well grub supports gpt and erm i would expect there to be a grub package pulled down?
<Tsyesika>surely it'd fail?
<davexunit>when I do 'guix system init' I see that it fetches grub
<davexunit>now, this is on the *host*
<davexunit>not the installation target
<Tsyesika>oh right i see
<Tsyesika>yeah grub is on the host image
<davexunit>lol I'm glad I stopped this init
<davexunit>I forgot that it was going to install grub
<davexunit>that would have been a disaster
<Tsyesika>well i manually ran the grub install, it reported it installed and the mac still thinks there is nothing to boot so
<Tsyesika>i guess it's something else
<Tsyesika>hm arch wiki claims i should be using an efi partition
<pecg>I just came here to say how beautiful the new for the GuixSD is.
<pecg>Really like it.
<davexunit>pecg: I assume you mean "new logo"? yes, it's really nice.
<pecg>Looks very modern and stylish, but also with a minimal design, only 'bad' thing is that it reminds of Longhorn (code name for Vista); but that could be something happenning just to me.
<pecg>davexunit: Yes, I forgot to write logo.
<pecg>The logo for the Guix Package Manager should be kept as it is, I also like it
<pecg>I'm even thinking about printing and sticker and put it in my laptop's lid, would be nice.
<Tsyesika>davexunit: thanks for your help, i'm going to see what if i can do this without setting up efi but i'm heading to bed now it's 2am for me
<Tsyesika>night everyone
<davexunit>Tsyesika: good night! sorry about the troubles!
<davexunit>pecg: yeah, we plan on keeping both logos.
<davexunit>I would like to order a small batch of stickers, myself.
<pecg>davexunit: from me?
<pecg>davexunit: In what part of the world do you live?
<davexunit>no, from a sticker printing site
<davexunit>to distribute
<pecg>davexunit: Yes, that's what I thought
<civodul>Hello Guix!
<civodul>hey, wenderen
*civodul just realized the nickname/realname mapping :-)
<civodul>rekado-: $GCJ/lib/jvm/jre/lib/amd64/ is a dangling symlink, presumably because we don't build that part, and that leads to this error:
<civodul>rekado-: we could #:validate-runpath? #f, but it's even better if we can fix it for good
<civodul>rekado-: WDYT?
<civodul>taylanub: do you think you could look into the RUNPATH issue of wxwidgets?
<civodul>i saw your name in that file :-)
<civodul>basically just needs LDFLAGS=-Wl,-rpath=$libdir
<civodul>same problem for webkitgtk (which uses cmake)
<wenderen>i should probably switch to something more memorable, wenderen has literally no connection to my real name
*ajnirp wishes rohan weren't such a common name
<rekado_>rekado-: re GCJ: Oh, I think we can just remove this link in a separate build phase. It doesn't seem to be needed (at least for the things we use GCJ for).
<rekado_>erm, civodul --^
<civodul>ajnirp: whatever name pleases you, but don't change too often ;-)
<ajnirp>sure, sure :)
<civodul>rekado_: do you want to give it a try (core-updates), or should i do it?
*civodul has a preference for the former :-)
<rekado_>civodul: yeah, I can do it in core-updates. I'll send a patch to the ML.
<rekado_>I just read that Ubuntu 15.10 will come with "Snappy Personal".
<rekado_>yet another package management technique based on bundling everything.
<davexunit>I'm unenthused by snappy
<davexunit>I don't know why the answer to packaging problems has become effectively static linking everything
<rekado_>because Apple?
<davexunit>snappy says it has transactional package management... but it just takes disk images.
<davexunit>sometimes I have a hard time coming up with concrete issues that I have with things like snappy, docker, etc. that is easy to understand and follow
<davexunit>I really want to do better at that so I can write a blog post or give a talk about the future of package management
<rekado_>(I feel like I'm too young to already be grumpy about all this appification.)
<davexunit>and why I think guix has it right.
<civodul>i would argue that these things are heavyweight, coarse-grain, and make upgrades difficult
<davexunit>rekado_: I'm 24 and I'm very grumpy about it all.
<civodul>i'm older and i'm grumpy!
<davexunit>what makes me grumpy is that no one seems to see the issues we see.
<rekado_>"disk space is cheap" they say.
<davexunit>yesterday on HN I got in a discussion about "unifying" package managers, and I proposed Guix as a solution.
<civodul>you probably saw that already:
<davexunit>but then I was told that Guix is just "yet another package manager" (cue XKCD comic on standards)
<davexunit>and that the *real* solution was a tool that "unified" the many distinct package managers people were already using!
<davexunit>then I called it a "package manager manager" and people disagreed
<civodul>in a way, things like Puppet are package manager managers
<davexunit>yeah, that's true
<rekado_>heh, yesterday I "fixed" (i.e. wiped clean and reinstalled) a colleague's Ubuntu machine where he had installed software with both apt and yum.
<civodul>because they add a layer above the actual package managers
<davexunit>also, Guix isn't a solution because it doesn't work on Windows.
<rekado_>is Windows still a thing?
<davexunit>it's getting a package manager!
<davexunit>but it's just another binary based package manager
<davexunit>no, by Microsoft themselves
<rekado_>an "app store"?
<davexunit>all Powershell'd up
<davexunit>no, a CLI interface and everything
<taylanub>civodul: is runpath validation globally disabled on master or so? the wxWidgets build seems to skip it for me.
<davexunit>civodul: and yes, I saw that "sad state of sysadmin" article. the comments on r/programming are so depressing
<civodul>taylanub: there was a bug whereby build systems other than gnu-build-system would skip it (fixed in core-updates)
<davexunit>the top comment is "Compiling from source just means you've created the untrustworthy binary locally."
<taylanub>civodul: should I patch wxWidgets in core-updates, or enable the runpath validation somehow?
<civodul>taylanub: rather in core-updates
<davexunit>so, I couldn't sleep last night, and I wrote some code that abstracts over Linux namespaces:
<taylanub>civodul: BTW could you look at ? summary: we have mesa patches; should they be applied to core-updates, or wait until core-updates is merged?..
<davexunit>this module allows you to easily fork the process with new namespaces, or create new namespaces in the current process.
<davexunit>(with-clone '(uts) (sethostname "foobar")) ;; hostname stays the same for all other processes!
<rekado_>gah, the comments on the article about Ubuntu's Snappy Apps thingie are even worse than the reddit comments.
<davexunit>rekado_: link?
<rekado_>it's in German
<davexunit>nvm lol
<rekado_>for the record:
<taylanub>has anyone else noticed Guix sometimes not listing all the packages it will download?
<taylanub>first it said: (121 packages listed under downloads) now grepping for "substituter-succeeded" in the output gives: (146 packages)
<taylanub>not the first time I'm noticing it ether (I kind of ignored it previously because other things were occupying my mind)
<civodul>taylanub: re Mesa, either way is fine: merge now in core-updates, or wait until core-updates is merged
<civodul>i'd like it to be merged real soon
<civodul>there are still build failures, so people need to look at it
<civodul>davexunit: with-clone looks neat!
<civodul>taylanub: see
<civodul>somehow i never got around to fixing that
<civodul>that code needs love
<taylanub>ah ok, well it's not a critical bug, good to know it's known
<davexunit>civodul: thanks! probably has some issues but I'll find out in due time. currently struggling with the lack of netlink support in Guile's sockets.
<iyzsong>Can 'guix package -i' support install 'drv' or store output paths? Or How can I use the one-click install 'nixpkg' file from hydra?
<civodul>davexunit: yes netlink support would be nice; also keep an eye on libstore/ for things that would be useful ;-)
<civodul>iyzsong: yes, it can be passed a store item or a .drv
<civodul>i forgot how the one-click thing works, i think one has to "guix archive --import" the thing first, right?
<rekado_>so, it's "one-click and some more typing(TM)"?
<iyzsong>civodul: it doesn't work now right? when using nix, I can look at hydra, select any package, and do 'nix-env -i /nix/store/xxx' without caring my nixpkgs status.
<iyzsong>if the package is in binary-caches, then I can install it, even no way to build it...
<civodul>oh you mean it also substitutes it?
<iyzsong>yes, I think that's why it's named one-click install ;-)
<civodul>i can no longer find the one-click thing on Hydra
<civodul>do you have a link?
<iyzsong>nixos or our one?
<iyzsong>and our:
<taylanub>is there a waf equivalent of #:make-flags (list (string-append "LDFLAGS=..." ...))?
<civodul>iyzsong: i see; we don't have that, not sure how useful that is
<civodul>iyzsong: however, we could certainly have "guix build /gnu/store/...-foo" automatically substitute foo if it's not already valid
<civodul>same for 'guix package -i'
<civodul>taylanub: dunno; rekado_?
<taylanub>ah, setenv LDFLAGS before configure seems to do
<iyzsong>civodul: sure
<iyzsong>taylanub: In 'core-updates', for jack2, it seems to me that I have to patch wscript to add LINKFLAGS.
<iyzsong>well, I didn't try LDFLAGS
<taylanub>iyzsong: try something like: it's probably a little cleaner than patching a file
<bavier>civodul: out of curiosity I wrote a package definition for Spack (
<rekado_>taylanub: maybe this could be added to the waf build system standard phases?
<taylanub>rekado_: if we can be sure that $out/lib is the right place ...
<taylanub>I just pushed three commits doing it, maybe should had waited :\\
<civodul>bavier: so what do you conclude? :-)
<taylanub>if we can be sure that $out/lib is the right place, then this could probably be automated for more than just waf, no?
<bavier>civodul: it has some nice features
<bavier>civodul: but I actually had some questions about how our nix package works
<bavier>do we expect that an admin has created the nix store and started the daemon before a user uses nix?
<bavier>the issue I ended up at with spack is staging directories and such
<bavier>the docs do say that the primary user is one who runs spack from their home directory and stores build results there too
<bavier>davexunit: thx, so I suppose we could assume the same for any other package managers that our package manager manages ;)
<davexunit>to bring up a larger point: this is a problem that the Debian folks see with Nix/Guix
<davexunit>that we don't set this stuff up.
<davexunit>I don't know if/how that can be reconciled.
<civodul>davexunit: the problem for Debian folks is that the store is not FHS-compliant, no?
<bavier>could the build daemon handle stuff like that?
<davexunit>civodul: among many other things
<civodul>the daemon actually creates the store by itself now
<bavier>civodul: could it create other stores?
<davexunit>civodul: see:
<davexunit>by Stefano Zacchiroli
<davexunit>a name many of you will recognize
<davexunit>worth a read to see the issues raised.
<davexunit>crazy that this email is from 2008!
<civodul>but it doesn't mention the daemon not setting up /nix/store though?
<civodul>i think there was an ITP for Nix long ago
<phant0mas>changes in commencement cause a lot of rebuilds? it's building for an hour now...
<civodul>bavier: what do you mean by "other stores"?
<civodul>phant0mas: probably yes
<davexunit>civodul: the key bit in the email is "maintainer scripts are not turned in functional (and revertible) expressions, so the only way to "undo" them is living without them, or restore whole parts of the filesystem (with the disk consumption problems other observed)"
<bavier>civodul: e.g., if a user requests Guix to install the nix package, could the build daemon create /nix/store as part of the installation?
<davexunit>think upgrading the sqlite database for an application or something
<civodul>davexunit: but what are "maintainer scripts"?
<civodul>ah yes
<phant0mas> I am away from my workstation and my laptop takes ages...
<davexunit>we can't reasonably do anything about that because we lose transactional rollbacks
<davexunit>thus the issue of what do with state is pushed elsewhere.
<civodul>bavier: as part of the installation no; rather the first time it is spawned
<bavier>civodul: I suppose for nix you'd still need root to start the nix daemon
<davexunit>civodul: libstore/ is surprisingly readable and well commented. :)
<iyzsong>well, I think we already do the 'maintainer scripts' partly when build the profile (build info-dir, etc.), so instead of "undo" them, we "redo" them every time?
<davexunit>iyzsong: a database throws a monkey wrench into that though. you can't reasonably just rebuild it from scratch.
<davexunit>it's inherently stateful.
<iyzsong>sure :-(
<civodul>davexunit: yup :-)
<civodul>there was a master thesis on that topic, with a tool called "SNix"
<civodul>didn't work out, though
<taylanub>what packages are there which need an update to some sqlite database upon updating them?
<davexunit>iyzsong: guix does a great job of separating the stateful from the stateless, but something has to handle that db upgrade.
<davexunit>taylanub: that was just a contrived example, but consider a web application with a PostgreSQL database.
<paroneayea>iyzsong: there's a true problem here indeed with database migrations
<paroneayea>if you have sql, you *need* to keep upgrading your schema as the software evolves
<davexunit>when the software is updated, who does the migration?
<paroneayea>that means rearranging tables and all teh data is updated
<taylanub>I see
<davexunit>I don't think guix should do it.
<paroneayea>so upgrading mediagoblin in guix will mean updating the database arrangement
<paroneayea>so, one thing that could be done
<davexunit>because it's out of scope of updating the software itself.
<paroneayea>is a tool could be written to recognize that a new schema was being written out
<iyzsong>oops, that's painful for me to think
<paroneayea>and backup and archive the database right before that upgrade
<paroneayea>that way if the upgrade goes badly, you can roll back to the prior data
<paroneayea>of course, it might be lossy if new data appears.
<paroneayea>but it's still a safer solution for users.
<davexunit>I'm skeptical that an automated tool could possibly do a good job with this.
<paroneayea>maybe not, I'm not sure
<paroneayea>I'm just trying to think of some ideas :)
<davexunit>sure :)
<paroneayea>I'm not sure what zack's security concern is though that's an interesting one
<paroneayea>things in the /gnu/store shouldn't really be exposed to the world in a way that's dangerous
<davexunit>paroneayea: a user keeps a broken openssl in their profile, thus it cannot be gc'd
<davexunit>one possible scenario
<paroneayea>davexunit: that's true, but the openssl will only be for that user's stuff right?
<paroneayea>and it's not like outside network applications can go starting up whatever they want from /gnu/store
<davexunit>it's one of those things you have to accept if you're giving unprivileged users some autonomy.
<paroneayea>I mean, users on all the new imperative container solutions can also keep 60 docker containers without of date ssl, and updating *those* will be a lot harder!
<davexunit>well, any process can read /gnu/store
<davexunit>but I don't see how that would be a security issue
<paroneayea>davexunit: but hopefully applications are written in a way that they don't *let* any process just read /gnu/store
<paroneayea>I mean, if apache lets you execute just any binary on your system
<paroneayea>you're gonna have a bad time there, too
<davexunit>apache shouldn't let you outside of the docroot, etc.
<paroneayea>also the complaint that guix will pretty much never get the same number of packages, well
<paroneayea>guix has a *lot* of packages already now!
<paroneayea>from 2008 -> present
<davexunit>how many do they have now?
<davexunit>I agree they have a lot
<paroneayea>ubuntu has about 45k packages
<paroneayea>nix has 13k
<davexunit>if you package it, they will come.
<civodul>paroneayea: zack's point about security is also a good argument: it is trivial to find all copies of a security-flawed package on a Nix/Guix system :-)
<civodul>the sysadmin can trivially find profiles that needs an upgrade, *and* can identify processes that need to be restarted
<civodul>the latter is hardly possible on an imperative system
<davexunit>great point.
<paroneayea>civodul: I'm in another channel with zack, I'm asking him for clarification
<paroneayea>I'll raise that point
<taylanub>that Debian ML thread is weird. atmosphere reminds me of the emacs-devel ML :P (hostility...)
<davexunit>paroneayea: keep in mind the age of this email, I wonder what his thoughts are now.
<paroneayea>civodul: mind of I copy-pasta that point?
<paroneayea>davexunit: yes I'm tryign to extract that ;)
<paroneayea>oh, this is a publicly logged channel
<paroneayea>so it's probably fine to copy-pasta ;)
<paroneayea>the other channel is a backchannel of sorts ;)
<paroneayea><zack> I don't have time to counter argue right now
<paroneayea><zack> but the point is not whether it is _possible_ to do that
<paroneayea><zack> but whether the system does that by default
<paroneayea><zack> the gap among the two options is huge in terms of practical security impact
<paroneayea>oh well :)
<paroneayea>oh, maybe it wasn't okay to copy-pasta from the private channel though ;)
<rekado_>I actually agree with zack on this one. But since it *is* possible we can actually write these tools for sysadmins.
<paroneayea>it would be nice to have something that can scan the tree and see what profiles have out of date security
<paroneayea>that could give sysadmins the ability to force users to upgrade, or else they'll do it for them
<davexunit>I find it mostly fruitless to debate with Debian folks about this stuff.
<davexunit>they have 20 years of history and are set in their ways.
<paroneayea>davexunit: there's a wide spectrum there of people and their willingness to explore things
<davexunit>sure, I guess I just haven't seen much willingness.
<paroneayea>for example, zack may have a strong opinion here, but he's pretty open to discussion on things, and joeyh is a "(gu|n)ix sympathizer" ;)
<paroneayea>but for many, sure
<paroneayea>but I think that open dialogue about these things can be good.
<civodul>didn't joeyh leave Debian?
<davexunit>yeah, but it's still his OS of choice.
<paroneayea>he did, for process reasons
<paroneayea>it's hard to say "debian people"; it's a pretty broad group.
<davexunit>yeah, you're right.
<civodul>zack was at the 2011 GHM and he was obviously very friendly and open to discussion
<civodul>that was very constructive
*paroneayea is a huge zack fan!
<civodul>even on some of the otherwise heated topics
<davexunit>zach is very nice. I talked with him a bit at the FSF office the monday after libreplanet.
<paroneayea>I think he's one of the most thoughtful people I know in free software.
<civodul>personally i'm glad to have feedback from people from "standard" distros because i've spent too much time in Nix land :-)
*paroneayea reads zack's papers :)
<davexunit>but overall I seem to run into more resistance from people that promote Debian.
<civodul>i guess there may be tribal reactions from time to time
<taylanub>civodul: BTW do you want to look at the Qt patch? (and I suppose I should push it to core-updates?)
<taylanub>also yay for Guix helping reproduce bugs:
<taylanub>hmm, there's some new patches there; maybe my hacky patch is obsoleted now.
<taylanub>civodul: I guess you can postpone looking at the patch :) I'll try out these new ones; should have results by around midnight given Qt's build time on my machine.
<paroneayea>it's a good point anyway, both that the outdated security stuff is a concern, though I think an addressable one
<paroneayea>though addressable in theory and addressed in reality are different things :)
<rekado_>civodul: I submitted a patch for GCJ to the ML. Includes a fix for the "gcc", "g++", etc conflicts with other gcc packages.
<civodul>taylanub: i'll wait; nice that they actually used it to reproduce the problem!
<civodul>rekado_: ok, will look at it
<rekado_>I wonder about the validity of the security concern. Even on Debian I can build software from sources. This may be vulnerable software. What exactly is the point here? You cannot prevent Guix users from running vulnerable software?
<rekado_>Or is it about the way a rollback can take you back to an incarnation of the same version that uses a vulnerable library that has since been patched? (Is this not addressed with grafts?)
<civodul>rekado_: right, sysadmins can prevent users from building stuff from source and such
<rekado_>One thing I find interesting about snappy is that access can be declared as well:
<rekado_>this should make it possible to generate AppArmour profiles from package metadata.
<rekado_>I would like that for Guix as well, actually.
<cehteh>mhm .. guixsd still feels like a lottery, 2 days ago it installed, but network didnt work in the kvm, today the installation breaks
<rekado_>not my experience. I'm using it on a ThinkPad as an audio recording workstation. Reliable.
<davexunit>cehteh: an important detail, is this the exact same version of guix that's doing this?
<davexunit>I'm curious to know what could be causing intermittent failures
<cehteh>no i did a guix pull inbetween
<cehteh>and now its broken :D
*paroneayea just now reads civodul's response to the "replacing bower" thread
<paroneayea>it's an interesting idea!
<davexunit>cehteh: using a git checkout and running git bisect to find the commit that breaks things would be helpful, but I understand that's asking a lot.
<cehteh>the problem is that i am way to nwe to understand guix
<cehteh>i know git well .. but i have no idea yet how to get a grip on guix when its broken
*davexunit nods
<cehteh>system init copies a lot stuff to /mnt now ... and then:
<cehteh>i/o error: /gnu/store/j4vq1xndh98xs15ai1xhnnl7mylv371j-guix-0.8.1.fc34dee: Datei oder Verzeichnis nicht gefunden
<cehteh>error: getting attributes of path `/mnt//gnu/store/j4vq1xndh98xs15ai1xhnnl7mylv371j-guix-0.8.1.fc34dee': No such file or directory
<cehteh>guix system: error: failed to register '/gnu/store/j4vq1xndh98xs15ai1xhnnl7mylv371j-guix-0.8.1.fc34dee' under '/mnt'
<cehteh>(i deleted /mnt completely, except the system-configuration.scm)
<cehteh>there is a /gnu/store/j4vq1xndh98xs15ai1xhnnl7mylv371j-guix-0.8.1.fc34dee.lock
<cehteh>whats that?
<cehteh>(deleted that, did guix gc .. start over)
<cehteh>.. same error again
<paroneayea>davexunit: did you look at ludo's reply to the bower thing?
<paroneayea>it makes me itch even more to understand gexps ;)
<davexunit>paroneayea: yes, I did. I have to think about it some more.
<davexunit>it would be pretty straight forward to supply a script that builds the asset bundle
<davexunit>in a directory structure compatible with bower
<davexunit>I'm glad ludo brought it up, because I didn't even think of it, but it's obvious, really.
<davexunit>I'm getting excited thinking about it more
<cehteh>so .. deleted everything, reinstall, try again
<davexunit>paroneayea: (package (inputs `(("node" ,node) ("assets" ,(web-assets jquery bootstrap)))) ...)
<davexunit>still more to think through, though....
<paroneayea>davexunit: yeah
<paroneayea>man, g-exps seem to be the shit
<paroneayea>I keep fearing I won't understand them because I don't know monads, but they seem to hide the need to understand monads :)
<paroneayea>oh, I guess not all g-exps use monads.
<davexunit>yeah, they're not directly tied to monads
<davexunit>they allow you to transform package objects (or derivations, or origins, I think) into their respective file names.
<davexunit>which is super convenient
<davexunit>pretty cool to be able to 'unquote' a package
<davexunit>and that gexp can then be built with all the necessary dependencies
<cehteh>oops installing again compiles stuff now .. anyway i am off, bbl
<cehteh>compiles glibc ... oh my :)
<davexunit>looks like this is missin the 'modules' argument in the arguments list
<cehteh>mhm .. still compiling, is hydra out for lunch?
<paroneayea>davexunit: I was just trying that myself
<paroneayea>scheme@(guile-user)> ,run-in-store (gexp->script "list-files"
<paroneayea> #~(execl (string-append #$coreutils "/bin/ls")
<paroneayea> "ls"))
<paroneayea>$14 = #<derivation /gnu/store/67wm9w2xbh9ajsiynzzpxnv53f98fvf4-list-files.drv => /gnu/store/gmv6ffb4l1lp7jzpbr64q2qvbsgnbk46-list-files 668d730>
<paroneayea>however whatever that /gnu/store/gmv6ffb4l1lp7jzpbr64q2qvbsgnbk46-list-files is, it does not seem to have stuck around...
<paroneayea>I can't find it
<davexunit>paroneayea: you didn't built it
<paroneayea>oh, hm
<paroneayea>how do I?
<davexunit>run (built-derivations (list $14)) inside the store monad
<cehteh>i wonder how long it takes installing guixsd from source :D
<davexunit>a long time
<cehteh>no idea why the shit is still compiling here, but i am too lazy to break it
<cehteh>it started with downloading some stuff, could it be that i fetched (git head) things that hydra didnt build yet?
<davexunit>that's a possibility, but we don't typically merge things into master until we've built everything in a separate branch
<cehteh>mhm strange then
<cehteh>break, restart, now it starts at least with downloading stuff
<cehteh>.. so far about determinism .. 2nd tried finished without building anything
<cehteh>but still no network :/
<cehteh>hi civodul :)
<cehteh>i've send the mail about "GuixSD in kvm" .. have it installed now, but network does not work
<cehteh>seeing the network card in lspci and same kvm with debian8 works, but under guixsd dhclient times out
<cehteh>(in earlier tries with the usb-install image, networking worked, but that failed for other reasons)
<paroneayea>every day I'm more sold on Guix :)
<paroneayea>coming to understand how to use g-exps
<paroneayea>one more step in that direction
<paroneayea>I'm really excited to have "guix environment" be the #1 recommended way to hack mediagoblin, and virtualenv + bower be the fallback option
<davexunit>paroneayea: we need to work on a node-build-system
<paroneayea>davexunit: yes
<davexunit>mediagoblin uses node a bit, right?
<davexunit>just bower or more?
<paroneayea>davexunit: not for mediagoblin itself, just for those packages
<paroneayea>so for debian package, there's no node dependency
<paroneayea>since they symlink in all the debian packages itself
<paroneayea>but yeah, effectively for most users, there is
<paroneayea>davexunit: we also ought to get packaged.
<davexunit>I didn't know if there was some javascript minification pass
<davexunit>paroneayea: that would be a good goal project
<paroneayea>btw, speaking of pump
<paroneayea>via mlinksva's pump post:
<davexunit>oh neat
<davexunit>this person is writing some good stuff
<civodul>paroneayea: nice post indeed
<civodul>confirms what we could be afraid of regarding Snappy
<paroneayea>civodul: be afraid of?
<civodul>paroneayea: (probably a frenchism, sorry) i mean the scary stuff like bundle everything, share nothing, etc.
<paroneayea>civodul: aha :)
<paroneayea>civodul: interesting to see container solutions and functional solutions having some overlap in design though
<paroneayea>I mean, you know where I'm at on opinions on this stuff ;)
<civodul>yup :-)
<paroneayea>one thing that it would be good to have more of built in to be easy in guix though
<paroneayea>sandbox'y isolation, but built in proper guix'y fashion
<paroneayea>eg, I still don't want to run wordpress outside a sandbox :)
<paroneayea>that's one thing some of these container'y things have going for them, that I think is snarfable :)
<paroneayea>(snarfable in concept, not code, I mean)
<davexunit>paroneayea: boy there sure are a lot of dependencies for
<paroneayea>davexunit: yupppppp
<davexunit>dependency hell for sure
<davexunit>such is life with node, I guess
<davexunit>and ruby, for that matter
<paroneayea>unrelated; thought I had earlier:
<davexunit>I want to have rails packaged...
<davexunit>not gonna happen anytime soon without lots of help
<paroneayea>I wonder how hard it would be to do isolated packages *as* inherited packages
<paroneayea>I guess, at least they could be derivations with gexp->script
<davexunit>what do you mean by isolated?
<paroneayea>davexunit: er
<paroneayea>isolated containers
<paroneayea>for security stuff
<paroneayea>going back to thinking about wanting to run some things (eg, wordpress) in an isolated environment
<paroneayea>it seems to me that guix has most of the stuff there to make it not that hard to build it based on the packages themselves as inputs
<davexunit>perhaps a wrapper script could be written
<davexunit>that does the clone() call and sets up the container
<davexunit>I mostly get how kernel namespaces work now
<davexunit>I don't yet understand uid/gid mapping, though.
<paroneayea>civodul: I guess a question for you, does anything like g-exps exist in nix?
<paroneayea>because it's a pretty awesome feature in guix.
<paroneayea>now that I know what's going on :)
<davexunit>you probably understand gexps better than I do at this point
<paroneayea>davexunit: have you seen
<paroneayea>you probably have
<davexunit>paroneayea: yeah, been very slowly working through that
<davexunit>cgroups are useful, but not strictly necessary for a container.
<davexunit>only if you want to limit resources
<davexunit>I'm bummed out on my container project because Guile cannot create AF_NETLINK sockets with its built-in socket library.
<davexunit>and I need them for virtual network interface
<paroneayea>ah :( why not?
<paroneayea>just a missing guile feature?
<davexunit>yeah, seems so.
<davexunit>I'm not experienced with sockets so I don't feel too confident to go mucking in guile core.
<paroneayea>fair enuf