<roelj>Can I increase the default qemu memory size? (it defaults to -m 256..) <OriansJ>roelj: Yes. there are many ways to do that. such as simply adding a bash alias to pass qemu the option of -m xxxxM <roelj>OriansJ: Well, Guix sets it explicitly. <roelj>OriansJ: I edited the source code, but I would like to have a command-line switch.. I guess I could try to add it myself <OriansJ>roelj: It does have a command line switch and if a virtual machine is set up with libvirt, it can be configured through the virt-manager GUI. <roelj>OriansJ: What is the command-line switch? <OriansJ>roelj: -m ###M sets qemu to use ###MB of ram instead of the default. It however does not change the qemu defaults. <roelj>OriansJ: Oh. I guess I haven't expressed myself too clearly. I meant an option in Guix, so that 'guix system vm ...' can be told to create a VM with more than 256M of memory available. <roelj>OriansJ: Sorry for the mix-up. <OriansJ>roelj: No worries, sometimes we all use the wrong words. <roelj>OriansJ: Thanks for your help! <OriansJ>roelj: I thought the arguments given to the guix system vm script are passed to QEMU <roelj>OriansJ: Yes, that is true. Now, I liked it when it would be possible to set a size that will then be adopted in the script automatically ***Emacsite is now known as calher
***calher is now known as Emacsite
<koosha>I ran "bootstrap" and "config" without error finally but I got some through "make" . The vm's speed is very low and if I start the make process again it will take hours to finish . <koosha>I've got this from running make on Debian/hurd : <koosha>"make[2]: *** No rule to make target 'gnu/packages/bootstrap/i586-gnu/bash' , needed by 'all-am'. Stop." <civodul>koosha: 'master' lacks some of the bits to support GNU/Hurd <civodul>you should use the 'wip-hurd' branch instead <rekado>what do you think about making new releases whenever core-updates is merged? <koosha>Oh , I have errors in bootstrap ... <koosha>"configure.ac:21: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged. " <koosha>"configure.ac:21: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead," <civodul>maybe you're using Autoconf 2.69ish from Debian? <civodul>i heard some distros ship an unreleased version of Autoconf <koosha>I have autoconf 2.69-8 on Debian/hurd <civodul>yeah we don't get this warning with the vanilla 2.69 <civodul>but anyway, don't worry about it :-) <koosha>And what's your comment about the errors that I've got from 'make' ? <civodul>yeah, maybe phant0mas can provide additional feedback later <koosha>Okay , so I should wait , thank you anyway . <koosha>phant0mas: Do you have time to help me ? <Digit>mmm. guix on hurd. that's some enticing words there. ... i kinda wanna drop everything n go try that out. ... but barely got started with the last thing to have that effect on me. one geeking at a time. ... soon tho. hopefully. <civodul>rekado: sorry i hadn't seen your question, but yeah, i think we should make a release once core-updates is merged <phant0mas>koosha: when you are online ping me, so I can guide you step by step <phant0mas>and in case you cannot find me here feel free to mail me at manolis837@gmail.com <koosha>well it seems my hardware doesn't support hardware virtualization . <koosha>phant0mas: I got some errors in running make <koosha>like this one : "make[2]: *** No rule to make target 'gnu/packages/bootstrap/i586-gnu/bash' , needed by 'all-am'. Stop." <phant0mas>koosha: you need the bootstrap binaries placed in gnu/packages/bootstrap/i586-gnu <koosha>"'dot' is missing on your system . " <koosha>phant0mas: Why is it downloading "guile.2.0.11" through running make ? <phant0mas>koosha: are you sure it's downloading? I think it should just untar the one from the bootstrap binaries <phant0mas>the bootstrap process in guix uses the bootstrap guile to download and prepare the rest of the bootstrap binaries so it can start bootstrapping the system <phant0mas>or in other words create the bootstrap-toolchain <phant0mas>aah it seems it download the bootstrap-binaries for other architectures <rekado>having /gnu on NFS is unbearable <rekado>I always think I've gotten used to it by now but then it just takes 10 minutes longer than usual <jlicht>How can I easily get the sha256 of a git-based origin? Is this outside the scope of guix download? <davexunit>the hash of a git repo is simply the hash of the directory <davexunit>sans the .git directory which is inherently nondeterministic <jlicht>davexunit: that explains so much. I was thinking on how having a hash of a git repo would make sense XD <davexunit>jlicht: if you looked at the source for git-fetch, you'll see that after cloning the repo, the .git directory is deleted. <jlicht>I guess the source is usually the most up-to-date documentation ;-) <davexunit>it would be nice for 'guix download' to handle git repos, svn repos, etc. but no one has made it do that yet <rekado>I'm thinking about hacking in a post-store-change hook. <rekado>I'm thinking about moving the store to a local disk. <rekado>whenever a store item is created I'd like to copy it over to a mirror on the slow fileserver <civodul>would it work to server substitutes from the fast machine to the slow one? <rekado>I previously tried to use inotify but it didn't work. <rekado>substitutes aren't the biggest problem. <rekado>what takes much too long is creating new profile generations <rekado>especially when a profile contains many files. <rekado>when I add a package (that's already in the store) to my profile it takes a very long time for the union build to succeed. <rekado>just now a user added "r" and "r-genomation" to a profile already containing "python-matplotlib" and other Python things and it took about 8 minutes. <rekado>no building or substituting involved <rekado>I wonder if it would work if I mounted the store via Samba. <rekado>not sure if it supports all the fs features the store needs. <rekado>our weird ZFS appliance allows us to export the share via NFS or Samba. <civodul>rekado: so users have direct access to the Guix commands? <rekado>I made a wrapper that connects to the daemon remotely <rekado>in this case I was looking over the user's shoulder and saw that it took about 8 minutes for the new profile generation to be created. <rekado>I'll just try to switch to CIFS. I hear that read performance with CIFS might be about 10 times faster than with ZFS via NFS. <civodul>since /gnu/store is append-only, perhaps caching can be made very aggressive <civodul>but i guess you've already tried to tweak everything <rekado>yeah, I made extensive tests with NFS caching and different mount options, but all I managed to do was shave off a couple of seconds. <civodul>how do you connect client commands to the remote daemon? <rekado>socat runs on the management node and accepts connections to the daemon. <rekado>the wrapper starts socat where the user currently is, connects to the remote socat instance, and sets GUIX_DAEMON_SOCKET. <rekado>I'm experiencing the same performance problems without all that, though. <rekado>when I'm on the management node and run guix locally it's just as slow. <rekado>everything points at the union build to take the most time. <rekado>On Thursday I'm going to give a Guix workshop and I'm considering to set up a local toy Guix installation instead of using this very slow central installation. <civodul>yeah, i was just wondering how you had achieved that part <koosha>phant0mas: It finished and I think had no error . <civodul>rekado: i wonder if your particular NFS setup is particularly slow, or if NFS is bound to be that slow no matter what <rekado>I'll eventually prepare a patch for the manual, showing the wrapper and everything. <civodul>rekado: on the client-side we could implement something that connects directly over TCP <civodul>would be easier than having to write a wrapper etc. <rekado>ZFS is a little slow already, NFS is slow too, and it could be that the NFS settings on the appliance are very conservative, too. <rekado>civodul: sounds like a good idea. <civodul>rekado: anyway it's great that you're giving a Guix workshop at work! <civodul>largely my fault i guess, but such is life <rekado>I already have a couple of converts :) <jlicht>is anyone doing anything with node on guix right now? I seem to have problems trying to run `npm` with the latest packaged version (6.0.0) <jlicht>and rolling back to 5.10.0 does not have this problem <koosha>phant0mas: guix installed successfully . I'm going to setup the daemon . <civodul>jlicht: davexunit may be the right person :-) <davexunit>jlicht: would be good to know what the exact issues are. I haven't used npm much since doing that upgrade <rekado>another possible problem with the shared storage might be gzip compression. (Compression ratio is 2, but I don't think it's worth it if this turns out to be the reason why reads are so slow.) <thomassgn>Curios,I've recently started using nixos, purely on a gut feeling it would be more... mature. But I'm kind of looking for guix to be "safe" enough to make the change for it. Anyone with experience running guix that can speak to its stability as a day to day OS? <rekado>thomassgn: I'm running GuixSD on multiple machines. <rekado>the primary issue with GuixSD is that it doesn't have as many packages as other popular GNU distributions. <rekado>stability is definitely not an issue for me. <rekado>if anything it's more stable as I cannot really break things anymore. <rekado>(my workstation in the office is running Fedora and I break things often enough to find it annoying) <thomassgn>nice, yes, that was my thought too. This way of managing a system is so much better/easier <rekado>there are a couple of rough edges still. <rekado>e.g. IBus doesn't really work well (at all?). <rekado>one is a Thinkpad X200s, the other a T60. <rekado>obviously, the Thinkpads with Lenovo BIOS don't have WiFi. <thomassgn>let's write a change for guix when I next have time for it then :) <rekado>I'm going to try to replace the BIOS on the X200s with Libreboot soon, so that I can use an Atheros WLAN card. <thomassgn>Do you know, is there tools for managing remote machines? (like nixoPs if you're familiar with it) <davexunit>I brainstorm from time to time and have done a few experiements with local virtual machines <phant0mas>koosha: when you have everything ready, go back to the ftp server and get menelaus-key.pub <phant0mas>and run guix archive --authorize < menelaus-key.pub <thomassgn>hahaha,that qwould be awesome. It might be terrible, but so far it beats my old method of manual ssh management :P <phant0mas>so you can fetch substitutes from my hurd machine <civodul>phant0mas: oh you're serving substitutes, cool! <davexunit>thomassgn: I read the nixops code from time to time. there's not tooo much to it. <davexunit>a good portion of it is making sense of the nix->xml transformation that they have to do <davexunit>I intend to avoid the whole "state file" thing that nixops has. <civodul>davexunit: it'd be nice to get funding or something for these things to happen <thomassgn>huh, they send XML between the machines or something then? I've never looked at how or what it does, just tried it and it worked more or less as expected <davexunit>thomassgn: they translate the nix expressions into an AST in XML form <koosha>phant0mas: Okay , but about daemon setup , for build enviroment setup , guix-deamon is needed , is it installed ? <davexunit>this is just a local thing. they do that to figure out what is being deployed and such <davexunit>civodul: yeah. I have been too short on time to make a serious dent in this. <davexunit>and I'm in the midst of a big move and house purchase so I'm not exactly going to have more free time anytime soon <phant0mas>koosha: is should be at /usr/local/bin/guix-daemon <davexunit>so for now I just think and think and think about what I'd like to do <thomassgn>ah, I see. Thanks a lot for the input all of you <davexunit>thomassgn: you're welcome. it's a feature we're definitely going to have at some point. so if it's a dealbreaker for you now, check back every once and awhile. <rekado>...the case where one package is added to an existing profile. <rekado>instead of going through the list of *all* files whose union path would collide we could just compare the paths of the latest generation with the colliding paths of the new package. <rekado>IIRC new generations are created from scratch, ignoring the work we've done for previous profile generations. <davexunit>I'm not sure if that optimization could be done such that the resulting profile would be exactly the same as if it were created from scratch <rekado>hmm, I guess it would become order-dependent in case of conflicts. <rekado>right now we always pick the first of conflicting files. <davexunit>maybe there are other optimizations that could help here <koosha>phant0mas: Yes it is installed and I'm following it . <rekado>I guess it would still work if we made the order explicit (if it isn't already so). <rekado>I wonder: doesn't deduplication in the store already figure out conflicts for us? <rekado>if we could mark files as duplicates at the time they are added to the store we wouldn't have to figure this out each time on profile creation. <rekado>last time I checked I saw that we are actually reading files to see if they are identical. <rekado>IIRC mark_weaver optimised unioning. <civodul>rekado: as davexunit suggests, it wouldn't work well <rekado>there isn't anything obviously bad about the way it's implemented <koosha>phant0mas: It doesn't finish . 'guix-daemon --build-users-group=guixbuild' . I just copied the text in the manual into a file with the name guixbuild and the the command . <rekado>the files in /gnu/store/.links are named after the hashes of the store paths of individual files, no? <civodul>you could use that to do nasty optimizations, maybe ;-) <civodul>ACTION makes 'guix lint -c cve' Fast Again <rekado>I'm wondering if we could replace "file=?" in guix/build/union.scm by making a lookup in /gnu/store/.links <civodul>rekado: no, because (1) we cannot access it from the build env, (2) it would be state-dependent, and (3) deduplication is optional <civodul>it would be stateful, that is, a function of the current store's state <civodul>that's how it start, and then we end up with dpkg all over again! <davexunit>imperative shortcuts, like a pile of fresh baked cookies on the counter, you just can't resist. <rekado>well, this collection of links just tells us that two files are in fact the same. <rekado>without having to read them again. <rekado>I see this as a cache of previous work <civodul>rekado: in file=?, i'm pretty sure that if we check for (= (stat:ino st1) (stat:ino st2)), it'll be magically faster <civodul>because deduplicated things have the same inode number <civodul>so if you're using deduplication, this test is necessarily true for identical files <rekado>will a change to this file cause rebuilding the world? I'm curious and would like to try this. <civodul>i'm committing it anyway, because it cannot harm <civodul>it's just like (define (equal? a b) (or (eq? a b) ...)) <rekado>will stat:ino trigger another stat call? Or is this cached by Guile? <davexunit>it just accesses information of the result of stat <davexunit>so no additioanl stat call, it's just a selector <civodul>but actually that only helps for the case where files are identical <civodul>so maybe you won't see a difference :-/ <davexunit>can inode numbers clash across different file systems? <civodul>yes, but by definition, there's only one file system involved here <davexunit>profile creation slowness bit me when I accidentally installed texlive-texmf into my profile <davexunit>and then I tried demoing 'guix package -i' at a talk... <civodul>rule #1: only show things that work well ;-) <davexunit>'guix package -i' works wondefully, if I didn't forget about that earlier goof <davexunit>I wasn't expecting an issue, so rather than rolling back a generation I just moved on <davexunit>I should do the same for ruby. that would greatly simplify guixifying existing projects. <koosha>phant0mas: Well the mistake was from my side . <koosha>phant0mas: It's not going to end : "guix-daemon --build-users-group=guixbuild" <davexunit>koosha: it's a daemon process, so it's going to keep running. that's its job. <koosha>davexunit: I didn't read your message , sorry :) <koosha>But I can't work with shell . So I should run it in background ? <lfam>I think it's a great opportunity to learn more :) <koosha>davexunit: I'm not master but not noob too :) <koosha>phant0mas: So now I should go to ftp , right ? <phant0mas>and run guix archive --authorize < menelaus-key.pub <davexunit>koosha: if you use a distro that uses systemd, then you can install a service file for the guix daemon and manage it that way <davexunit>which is nicer than leaving a terminal open with guix-daemon running in it <koosha>davexunit: Intresting , thank you for advice :) <lfam>Just FYI, our Git repo includes a systemd service file at etc/guix-daemon.service <lfam>phant0mas: Are you running a mirror or are you running a Hydra server? <phant0mas>lfam: davexunit I am using guix publish on debian/hurd :-) <phant0mas>and btw that debian/hurd machine is not a vm <lfam>What hardware are you using? <phant0mas>it's and old pentium4 processor with 1gb ram <lfam>I have a processor from that era, although the machine has less than 1gb RAM. Maybe if I get more free time... <phant0mas>you could even get guix running on it with the help of my substitutes <koosha>phant0mas: I use to run it like this "command &" , isn't good ? <phant0mas>koosha: run screen `command` and then press ctrl a +d <koosha>phant0mas: So what is the next step ? maybe get familier with hurd and guix with manuals and reporting bugs ? <koosha>Because I dont know enough about guix and hurd . <phant0mas>koosha: well if you want to get familiar guix, I suggest using it first on linux <koosha>phant0mas: Yes , I have guixsd installed . <phant0mas>well you could try building packages you use on linux, on the hurd <jmd>Where's the function which generates the html list of packages? <jin_>phant0mas, koosha i followed your steps provided! <jmd>ahh. So not in the main source. <davexunit>which is then converted to the HTML text for the final product <random-nick>if all packages are listed it takes a long time to load :/ <lfam>Yeah, it's really heavy. Sounds like a good project for somebody to take on :) <davexunit>there's only so much you can do when the page is static <davexunit>I think just generating pages would be enough for now <davexunit>you wouldn't be able to search of course, but for that we would need a dynamic web application anyway. <lfam>For me, the most important use case is being able to give somebody a hyperlink to the package information. <lfam>I guess search is useful before you've got a working Guix installation <davexunit>random-nick: search just isn't going to happen without a dynamic web application backing it <random-nick>well, the current package list is easy to search :-) <random-nick>but it might start freezing/crashing browsers when it grows in the future <roelj>I believe some of the sluggishness comes from invalid HTML. <roelj>Which I have on my long to-do list.. So I would be very happy if someone beats me to it. <davexunit>it's not like we are missing closing tags or whatever <koosha>Debian's hurd version is very old , It's 0.6 . Isn't it ? <roelj>Sorry.. The HTML that comes out of the lisp code is simply not valid.. <davexunit>but a couple minor things that make it not valid HTML <davexunit>I have my own sxml->html procedure that should take care of these things <davexunit>so it's just some weird idiosyncracies with HTML having totally crazy rules <roelj>I don't find an <a> tag without any text to click on being invalid a crazy rule. <roelj>In the context of a markup language, I find that pretty sane. <roelj>Not sure how much it will speed up after it's valid HTML as well, because it's still a lot of data. <roelj>At least it should help a bit <phant0mas>koosha: you can run apt-get update && apt-get upgrade <koosha>What version do you need to I have ? <kraji>hello all! i used guix build to build a costumized package. how do I replace the package in base with the one I builted? I'm getting "collision messages" all the time <bavier>I have a project that was released under gpl2+; later they decided to re-release under LGPL, but didn't change any of the source headers, which still read gpl2+. So, would I just need to list both licenses? <lfam>kraji: If you mean what I think you mean by "collision messages", those collisions are in your profile (user's installed packages). So, uninstall the old package and keep the new one. <lfam>bavier: I'm not an expert, but I'd guess that unless LGPL and GPL2+ are compatible, then the state of the licensing is too ambiguous. <kraji>the think is that it is a system package and I don't see the other one listed <lfam>kraji: A system package on GuixSD? <lfam>kraji: If so, how did you make the customized package. In the Guix source tree (using ./pre-inst-env) or in a separate tree (using GUIX_PACKAGE_PATH)? <kraji>i just downloaded the tar file <lfam>Ah, I don't know whether or not you can use --with-source with `guix system reconfigure`. You could try it. <bavier>but yes, I might contact the author to point out the situation <lfam>kraji: The way I handle custom packages on GuixSD is to put them in a separate tree (where they inherit from the Guix-provided package), and then reconfigure with GUIX_PACKAGE_PATH pointing to my tree. <roelj>Could any tell me how the GuixSD USB image is booted? How does the BIOS find the kernel image to start? <roelj>I suppose when doing 'guix system disk-image gnu/system/install.scm', at some point it must partition the disk image, right? Where is that code? <roelj>Found it in gnu/build/vm.scm <GNUtoo-irssi>hi, on x86_64 under parabola I did: guix pull; guix system vm ./my_config.scm <GNUtoo-irssi>Note that I'm still struggling to get it use binaries packages. <GNUtoo-irssi>should I reinstall guix or something like that to have a fresh start? <civodul>and currently it's all green, except on ARM <roelj>civodul: I had to disable the tests for QEMU on a local build myself two days ago. <civodul>oh, it could be that there are non-deterministic errors or something <GNUtoo-irssi>I'll try again after moving TMPDIR to the disk instead of tmpfs <kraji>my store occupies 20gb. is this normal? <bavier>it seems to me the implementation is a bit convoluted though <davexunit>"Of course I'm looking at this from the perspective of deploying micro-services and immutable infrastructure." holy buzzwords batman <bavier>civodul: LANL has quite a few interesting tools <suitsmeveryfine># modprobe thinkpad_acpi fan_control=1 ; because by default, it loads with ...=0 <wingo>nuclear weapons and multi-processing in bash <wingo>it's making multi-processing in bash look good ;) <suitsmeveryfine>I understand, of course, that it's better to load `thinkpad_acpi fan_control=1` immediately. <davexunit>suitsmeveryfine: read the source or use the REPL <suitsmeveryfine>Can I just open my system configuration in Emacs and find it from there? <davexunit>suitsmeveryfine: to do that you need a REPL open so that you can evaluate that code <davexunit>suitsmeveryfine: how about just using 'grep'? <davexunit>the old fashioned way of finding where something is defined <suitsmeveryfine>If I've grep'ed correctly thinkpad_acpi doesn't exist in any of the defined guix services but it's still loaded at boot. Why is this so? <kristofer>I'm really not positive how to do that with your system configuration <suitsmeveryfine>hmm, is it safe to modify GRUB this way? Will I still be able to load previous configurations? <kristofer>it'd be something like thinkpad-acpi.fan-control=1 added to the linux line <suitsmeveryfine>Hmm, it appears that I need to create custom GRUB menu entries and type in all the details manually if I want a different option like "thinkpad-acpi.fan-control=1" <suitsmeveryfine>kristofer: do you think it will work to define the initial RAM disk instead? <emyles>I deleted (with rm) some files from the store, not sure why, and broke my guix <emyles>how can I fix it, or where can I start again from? <emyles>sudo guix gc --verify gives ".drv still has valid referrers!", <emyles>"disappeared, removing from database" <emyles>and also, build failed: invalidating path `/gnu/store/longhash-uwsgi-2.0.12.drv' <emyles>-uwsgi-2.0.12.drv' in database: FOREIGN KEY constraint failed <kristofer>suitsmeveryfine, no I don't think so. You should pass the module arguments on the linux line of your grub.cfg <suitsmeveryfine>OK, thanks. I'll try to figure out how I can do this. It seems that it would involve adding an addional GRUB menu entry