<cehteh>anyone of you had success with gsd-usb-install-0.8.1.x86_64-linux in a kvm? <cehteh>i am more or less following the manual, tried some variations (guix pull; guix system init ..) <cehteh>somehow the installation doesnt configure the initrd/kernel/grub or whatever correctly <cehteh>oh .. in short: the /gnu/store is completely empty after i ran system init and rebooted <cehteh>i now retry without the cow-store started <davexunit>did you verify that /gnu/store was populated before rebooting? <cehteh>but i couldnt figure out what all the unionfs mounts where all about <davexunit>then I don't understand how it could be empty, if it's not empty. <cehteh>maybe that shadowed the real store somehow <cehteh>when i dont start the cow-store then things will be copied over still? <davexunit>but the reason it's useful is because otherwise everything guix downloaded while installing would be installed to the ramdisk <davexunit>with the cow-store, the store will live on disk <cehteh>well i gave the vm 4GB .. should be ok <cehteh>could it be that the grub installed cant handle ext4? <davexunit>you may be the first to be installing to a VM like this <cehteh>the files are there, but from grub commandline i cant ls and dirs except the root dir <cehteh>what do you mean by os-config? the one i used to install my system? *davexunit takes guile-minikanren for a spin <davexunit>paroneayea: I will probably apply this patch tonight with a couple of really minor stylistic tweaks. <cehteh>i've pretty much used the template, only changed the hostname, the username and the filesystem label <cehteh>doh .. cant copy paste from the vm :D <cehteh>should configure the serial cosole <paroneayea>davexunit: I'm using The Reasoned Schemer as motivation for going through some really boring admin tasks <paroneayea>davexunit: oh yeah, also Aeva dropped by my apartment today, I showed her both Guix and a live demo of the live coding Sly features <davexunit>cehteh: I think it would be a good idea to write to guix-devel@gnu.org with a copy of this config and a report about what is going wrong. <cehteh>how do i chroot into the installed system ... on another system i would just chroot /mnt ... but that doesnt work with guix <davexunit>paroneayea: I'm glad you still have a working Sly setup! :) <paroneayea>I showed off the guix environment stuff inside of sly too <davexunit>reports about this sort of things not working would be good for our mantainer to see. <davexunit>he's afk for a few days, but he'll read the mailing list when he gets back. <cehteh>different bash on the usb than on the installed medium, but figured it out now <cehteh>eh no doesnt work :D .. profile lost <cehteh>i did chroot /mnt /gnu/store/...-bash*/bin/bash .. but then everything else is out :) <cehteh>bash works but nothing else in /bin or PATH then <cehteh>everything installed but /root is empty <davexunit>I haven't done this from a chroot, but if you are root and $HOME is /root <davexunit>you should be able to something like 'guix package -i guile' <cehteh>can i change the $HOME for that? <cehteh>because the rescue environment is not the same as the installed environment <cehteh>i am just doing a guix pull and hoping the rescue env is up to date then <davexunit>if guix works in your chroot, you can create a user profile that will allow you to get a list of env vars to set. <cehteh>because the rescue (usb image) bash is another bash than it is installed on the target <cehteh>chroot wants to execute $SHELL .. but that has the full hashed path <davexunit>so could you set $SHELL to something that would be correct in the chroot? <davexunit>cehteh: could you find a version of bash in /mnt/gnus/store and set $SHELL to that? <cehteh>but there is no profile inside the chroot <cehteh>setting $SHELL and chrooting works <cehteh>mmh have to add everything to $PATH manually then <davexunit>you should be able to create a profile form within the chroot with 'guix package' <davexunit>'guix package -i guile' will create a user profile for root and install guile, for example <davexunit>'guix package --search-paths' will spit out a list of environment variables that you should set to use the stuff in your profile <davexunit>and you can eval 'export PATH=/root/.guix-profile/bin' <cehteh>first i have to add guix to path . <davexunit>I have no idea if you'll be able to talk to the daemon from that chroot <cehteh>even if .. that daemon doesnt know that i am in a chroot <cehteh>lemme see if i can start a daemon in the chroot <davexunit>paroneayea: I ended up altering your build script more than I originally planned, but I am going to push the patch now. <davexunit>paroneayea: is that comment by the 'license' field still relevant? <davexunit>your latest patch doesn't install the license anywhere <davexunit>I'm pretty stoked to have minikanren conveniently available now <davexunit>I use an explicit #t because 'copy-file' doesn't return a value <davexunit>and though the build phase will pass without this, it's best practice to explicitly return a truthy value <davexunit>perhaps we should enforce this by testing build phases for *unspecified* <davexunit>one other style thing to note is that I used 'for-each' instead of 'map' when looping over scm-files <davexunit>because we're not transforming the list, but applying a procedure for its side effects. <davexunit>and I transformed '(if (not ...))' into '(unless ...)' <paroneayea>good call. I always forget about (unless) and (when) <davexunit>now, I need to a similar thing for Industria <davexunit>and maybe from there we can extract an r6rs-build-system or something *paroneayea posts exuberantly <cehteh>.. looks like bug in either the gsd kernel or kvm <davexunit>cehteh: thanks for sticking with this for so long <cehteh>when i change the virtual disk from sata to virtio or ide then it boots <cehteh>well i am quite interested in this project and would invest some time and resources <davexunit>cehteh: don't hesitate to post to the guix-devel list when you get stuck. you'll wait longer for a response, but more people are going to read it than just hear on the irc channel <cehteh>i wonder that no one else has this problems, isnt it natural that one tries a new distro in a VM? <paroneayea>davexunit: do you think I did an okay job for a first try on the package though? <davexunit>but it wasn't dependency hell, so that was nice. ***Digit_ is now known as Digit
***Digit is now known as Guest69625
***Guest69625 is now known as Digit_
***Digit_ is now known as digitteknohippie
***digitteknohippie is now known as Guest33255
*paroneayea points gun at foot <paroneayea>so how does one deal with a package that needs to bootstrap itself? ***Digit_ is now known as Digit
<cehteh>gcc needs some (sufficient) C compiler and does a 3 stage bootstrap *paroneayea just sent a doozy of an email to the list :) <cehteh>packaging mercury will be fun :) <cehteh>well for me the first thing is get guixsd running at all *paroneayea wonders if it's kosher to snarf descriptions straight from Debian... *paroneayea wonders that propagated-inputs means *paroneayea also wonders why his attempt at packaging extremetuxracer is failing, hm <iyzsong>paroneayea: the packages listed in 'propagated-inputs' will be propagated by the package when it was used as a input or installed to profile. <davexunit>rekado_: looks fine to me. maybe remove the leading/trailing whitespace around '=', though. <rekado_>(I'll remove the spaces around '=' before pushing. <davexunit>rekado_: thanks for looking at the sfml patch. I pushed that. <rekado_>I've been planning to package M.A.R.S. which depends on sfml. <rekado_>it's a silly game with pretty graphics <davexunit>rekado_: looks like it will be simple to package this game. we have all the dependencies <rekado_>yup. I like how this is becoming true for more and more packages. <davexunit>yes, things are starting to become convenient <davexunit>I keep finding packages that I am not expecting to find <davexunit>paroneayea: using bower for the first time. it's pretty mediocre!\\ <paroneayea>davexunit: a mediocre solution for a less than mediocre state of affairs <davexunit>it seems that most projects that have bower.json files store build artifacts in their git repo <paroneayea>davexunit: "its' better than 'git add extlib/jquery/'" <davexunit>I don't know why, but I was expecting something more sophisticated <paroneayea>the community members were right who argued for it <paroneayea>because I was coming up with a solution which was basically another mini package manager <davexunit>bundling complicates license compliance and stuff <paroneayea>I think I might crosspost my email to guix-devel to the userops list <davexunit>so here's what I'm thinking: if we try out the $WEB_ASSET_PATH, it would be easy to make it compatible with bower. <davexunit>export WEB_ASSET_PATH=/path/to/bower_components <davexunit>on Debiabn: export WEB_ASSET_PATH=/usr/share/web-assets <paroneayea>going down this path, I also see an easy way to unify virtualenv + bower / guix environment / guix package / deb/rpm/etc <paroneayea>which is really good, given this state of affairs :) <davexunit>supporting 'guix environment' would just be adding another helper file to the root of the source tree <davexunit>in addition to bower.json, you'd have package.scm <davexunit>(assuming we package all the JS and CSS and such <paroneayea>well, the web world is not so different as in terms of the popular vs long tail of linked assets <paroneayea>it's really not much different from normal applications, except that there has to be some linking inside the package to simplify things, plus we *make* it harder <paroneayea>but it's really not that much different than the kind of linking we've been dealign with forever in software <paroneayea>us web devs have just been thinking we've been too special to pay attention to the rest of the packaging world, I'm afraid :) <davexunit>which is why I think unifying package management is so important <davexunit>someone will come along and say "what about windows?", though. and for that... keep using gem, pip, npm, bower, etc. ;) <davexunit>all these things get deployed on GNU/Linux anyway, so if guix or similar is the tool used in production, we win. <paroneayea>davexunit: and OSX people can continue to use virtualenv + bower and get jealous of all the cool kids who are running guix environment <paroneayea>then they say "well I could just run it in Parallels if I really wanted to" <davexunit>or someone could port guix to darwin/xnu/whatever <paroneayea>haha, installation of nix on that page has a curl | sh <davexunit>I tried to install Nix on my girlfriend's work laptop with is a macbook <davexunit>nix is way different than guix and I couldn't figure out how to make it work. <davexunit>I followed the instructions but something wasn't working <davexunit>I tried installing GNU hello and it started compiling gcc... <davexunit>even though I thought I told it to use nixpkgs and their hydra instance <davexunit>paroneayea: I think iyzsong suggestion is better. <davexunit>I forgot that pkg-config should take care to setup the right include path for SDL <davexunit>rekado_: I tried to see if I could package m.a.r.s. reeeaaally quickly, but guix fails to download the source due to a tls issue. :( <bavier>davexunit: you might be able to use a git checkout for the time being <davexunit>bavier: yeah, I just don't really have time to do this now that it's taking extra work. maybe later. <davexunit>at least I think it does that. or perhaps it's just copied to /tmp after a failure when -K is used. <bavier>no, the builds are resident in /tmp the whole time <cehteh>mhm on some server i have /tmp mounted as noexec .. guess that would be a problem with guix <davexunit>paroneayea: could you use 'modify-phases' instead of 'alist-cons-after'? <davexunit>and name the phase 'patch-makefile? the 'shebangs' part is inaccurate because it's not patching a shebang. <davexunit>paroneayea: thanks. it's just a style thing. <davexunit>we introduced that syntax to make things read a bit better, and I think it's worth using consistently on new packages. <davexunit>paroneayea: hahahahaah how have I never seen that? <davexunit>paroneayea: building for myself, then I will push. thanks! <paroneayea>having tuxracer on your computer is kind of distracting. <paroneayea>especially when you haven't played it in almost a decade. <paroneayea>admittedly this is which is why mediagoblin is so hard to package: I didn't know how to make things easy to package until... well, now <paroneayea>packaging stuff is a low barrier to entry... if you know scheme. And if you screw up, roll back! ***gnusosa_ is now known as gnusosa
<davexunit>you don't even have to really know Scheme to do basic packaging. We have several packagers that didn't really know scheme when they started. <davexunit>it helps a lot, but it's encouraging to see several examples of people being able to learn the basics from the docs and reading other package recipes. <paroneayea>davexunit: yeah I think I could have done the tuxracer one without scheme knowledge <paroneayea>not true of the miniKanren one but, as said, that was more tricky than most <davexunit>paroneayea: yeah, that one requires scheme knowledge. <davexunit>not having a build system certainly raises the barrier <angelic_sedition>how exactly is the store shared with the host when running "guix system vm"? do you have to include the packages in the config file to be able to use them? <davexunit>angelic_sedition: the store is mounted read-only in the VM <davexunit>so yeah, you have to include everything in the config <davexunit>angelic_sedition: using a user profile means that you can install packages without having to reconfigure the system. *alezost uses his user profile for everything except iproute <davexunit>you also won't be able to enjoy the wonderful emacs mode that alezost wrote ;) <angelic_sedition>what happens if you run guix-daemon without --build-users-group and install everything as root, is that still a user profile? <davexunit>if you run 'guix package', it gets installed to a user profile, yeah. <davexunit>angelic_sedition: you can use 'guix system vm-image' instead <davexunit>a read-only mounted store makes VM generation quicker. <davexunit>of course, we could use more advanced vm deployment features. <davexunit>I want to control remote VMs/containers with guix. <paroneayea>davexunit: I'm still not really sure how nixops works, and how that would translate into guixops, and how much we'd really want to carry over or not <davexunit>paroneayea: a good portion of nixops is parsing Nix expressions into XML nodes, so we can do without that part. ;) <paroneayea>gexps are kind of this magical, mystical thing to me right now <davexunit>we don't have to parse shit because it's all scheme, baby. <davexunit>I should write down my discoveries from reading the nixops code. <davexunit>basically, it revolves around objects called 'deployments' <davexunit>a deployment is a collection of machines with a unique id <davexunit>and there's a state directory that nixops writes things to, the IP that each machine ended up with and stuff. <davexunit>yeah I should just brain dump on the mailing list and we can discuss strategies <davexunit>I have some basic data types already defined in my wip-ops branch <davexunit>which contains an <operating-system> and a <platform>, another new data type. <paroneayea>davexunit: can <operating-system> be anything other than guixsd? <davexunit><platform> objects provide the abstraction layer for the various infrastructure that systems can be deployed on. <davexunit>paroneayea: no, it's a guix <operating-system> object. <davexunit>I haven't used them enough to appreciate them fully. <davexunit>roniz: guix is a package manager that also provides a GNU/Linux distribution. <davexunit>roniz: is there anything in particular that is confusing? <bavier>roniz: have you browsed the manual at all? www.gnu.org/s/guix/manual <davexunit>something we could explain better on our home page, perhaps? <ijp>good news for guix with gsoc, I see three accepted projects <davexunit>didn't get any takers for my container project. :( <bavier>off-topic -> in terms of the FSDG, is Guix is responsible for filtering packages that are installable via other package managers we support? <davexunit>bavier: I guess it depends. we shouldn't ship a package manager that recommends non-free software out-of-the-box.