<fps>civodul: just one more question and then i shut up :) the mapping from recpie to file name happens where? <civodul>in (guix packages) and (guix derivations) <sebboh>Looks like the initial install from the USB image didn't populate the store as I would have expected. I'm downloading and building things that I downloaded and built yesterday. **I think.** I don't actually know the steps that guix goes through to install a package, or reconfigure an OS. <xd1le>sebboh: it might be different versions? <sebboh>Ghost script latest release 2014. <sebboh>for example. That one caught my eye, that's what made me realize this. <fps>sebboh: did you do a guix pull in between? <sebboh>Actually, let me finish reading this doc before I ask that. ;) <mark_weaver>get the latest version of guix from git master, and all the package updates therein. <sebboh>and the usb install didn't do that? <mark_weaver>but also, "guix pull" only updates guix for the user that runs that command. <mark_weaver>so, when you run "guix system reconfigure" as root, that won't be affected by the "guix pull" you ran as your normal user. <fps>unless it's "root"? :) <mark_weaver>fps: no, if you run it as root, then it only affects 'guix' commands run as root <sebboh>Is aws making a fleet of guix machines yet, or nix machines? :) <mark_weaver>sebboh: good question. well, when you run a 'guix' command, it consults $HOME/.config/guix/latest <mark_weaver>and when you run "guix pull" it sets the $HOME/.config/guix/latest symlink to point to the latest version of guix from git. <mark_weaver>well, I'm not sure off hand what happens if you run "guix pull" with $HOME that doesn't match getuid. I don't use 'sudo' or 'su' myself. <fps>mark_weaver: are you sure? if i never did guix pull as user, but did so as root. in this case i don't have a .config/guix as user <fps>and ls -l `which guix` points to the same for both user and root.. <civodul>mark_weaver: sudo sets HOME appropriately; but i wondered if we sould use getpwuid preferably? <mark_weaver>anyway, this is a common error, that people end up installing old software because they didn't run "guix pull" as the account that they're using to run 'guix' commands. <mark_weaver>fps: yes, I'm sure that 'guix pull' run as root only affects 'guix' commands where $HOME is ~root <mark_weaver>fwiw, one workaround for this awkwardness on single-user machines is to make ~root/.config/guix/latest a symlink pointing to ~USER/.config/guix/latest <sebboh>I use sudo exclusively (or, I will if I can ever complete this reconfigure) and I never even look in /root. Occasionally when it is time to migrate a machine, I look in there, and I find tons of little application-generated files, all of which clearly somehow got that $HOME instead of /home/hobbes. Now, there is some command line option for sudo that affects this.. and I might occasionally invoke sudo incorrectly. But whatever, if I <sebboh>see anything weird I'll report it. <mark_weaver>in my case, I always run guix from a git checkout, and both ~root/.config/guix/latest and ~mhw/.config/guix/latest are pointing to my built git checkout of guix. <sebboh>mark_weaver: sometimes i contemplate symlinking /root to /home/hobbes... Any known problems with that? <mark_weaver>civodul: probably we should find a way for "sudo guix ..." to end up using the ~/.config/guix/latest from the user that runs 'sudo'. <sebboh>mark_weaver: are you sure that is the correct goal? What if two users use sudo? <sebboh>... my latest message is unrelated to my previous message. ;) <fps>soo, if i run sudo guix pull and it actually recompiles guix and all the package definitions <fps>shouldn't the guix binary point to a different one for root than for the user? <sebboh>hm, xwindows related libs are being downloaded. <sebboh>I saw some dvi tools in the base packages.. probably for docs. Maybe consider skipping those for the default base system. <sebboh>ath9k-htc firmware??? I'm in virtual box.. <fps>you get it anyways :) <fps>sebboh: i suppose you could just not use %base-packages in your packages field <sebboh>no matter. I'm about to install X anyway. I'm just being hauty. <fps>oh allright. it's the hash of the build inputs.. interesting. <sebboh>wait, "the following environment variable definitions may be needed" and it shows some path in /root/.guix-profile... Is there any such thing as a systemwide package? <sebboh>/run/current-system/profile/s?bin is on my path. <sebboh>I think the balance between this thing being a unix and having it be centered around a functional package manager has broke--that is, it has tipped to both side simultaneously. <sebboh>Don't worry, I'm here to help. 1. all requests for resources (source, bins, package lists, whatever) go through localhost:1234 which caches. That will solve a lot of re-download-cause-wrong-user issues. <sebboh>2. any build/work/expensive operation gets *uploaded* to localhost:1234, too. For the same reason. <sebboh>3. Some facility can show an operator what packages are installed and at what scope-level each is installed. (This may exist, pardon me.) <fps>sebboh: there is such a thing: the list of packages in the operating-system call in your config <fps>or maybe i misunderstood your question <fps>also: are you talking to yourself? <sebboh>I just installed a few packages, but they didn't make it to my config. Which brings me to 4. an operator can ask the running system to emit a config, and it will somehow magically know the difference between a default value and values the user has tainted, whether it happened from config.scm or later from guix package ... et al. <sebboh>fps, I'm praying? I don't even know who the devs are. <sebboh>I can't remember what the other thing is. Have a great weekend~! <fps>oh, ok. you were enumerating wishes :) <sebboh>crap, I meant /I just/s, / and / ... I think? <fps>about 1. unless you explicitly GC stuff that was downloaded won;t be downloaded again <fps>if you have a package in the operating-system and a user guix package -i's the exact same package he _should_ just get a symlink to the same place in the store <fps>about 2. unless you explicitly GC, the result of a derivation will not get removed, so if another user requests the same derivation they should again just get a symlink in their profile to the same place in the store <fps>about 3. i wonder if the result of the operating-system call is serialized explicitly somewhere among the system generations in /var/guix <Steap>$ ./pre-inst-env guix-daemon --build-users-group=guix-builder <Steap>error: creating directory `/usr': Permission denied <fps> /var/guix/profiles/system/profile/manifest <fps>that includes only the operating-system though afaict.. but i suppose users might have something similar <fps>but it's scheme baby <fps>also /var/guix/profiles/system/parameters <fps>not precisely what you want, but maybe ckose <fps>Steap: how did you configure guix? <fps>i mean did you use arguments to ./configure? <Steap>and I work on Guix using "guix environment guix-devel" <Steap>I ended up doing # mkdir /usr <fps>yeah, but pre-inst-env is a thing from a local git clone of guix.. and it gets generated when you build that clone <fps>other guix things work fine? <fps>like guix build or guix package? <Steap>$ ./pre-inst-env guix-daemon --build-users-group=guix-builder <fps>i mean using pre-inst-env <Steap>$ ./pre-inst-env guix build python-keystone <Steap>guix build: error: build failed: opening lock file `/gnu/store/r3sdgmlmswhjmhcqjb9vrk5khh78jijk-tar.lock': Read-only file system <Steap>"guix package -i" raises the same error about the RO file system <fps>this is the first time i heard that pre-inst-env can be used to run the daemon, but i'm noob.. <fps>but usually it runs as its own user <Steap>well, I was doing it on Debian <fps>so yes, if you run it as a different user it will have problems :) <Steap>nah, same when using my "cyril" account <Steap>and not using "./pre-inst-env" <fps>but /gnu/store belongs to root <Steap>I did not run the daemon as root <fps>if you don't want to run the daemon as root you can start it with a different store dir :) <fps>or at least i thought so <Steap>I think we kind of have to run it as root <Steap>to ensure reproducibility or somethign :p <fps>just make the process's uid part of the build inputs.. then the difference would be made explicit :) <fps>or maybe i miss another issue with that.. intersting subject all in all :) <fps>anyways. nn and happy hacking :) <piyo>So, this is not in the manual but, on my foreign distro guix, do i need to do a guix package -u guix as root and as a normal user if I want to keep up? <Digit>i'm still new, but i think it's guix pull. i think that keeps package list updated, and guix updated. (someone will correct me if i got that wrong). <piyo>I was thinking it was package -u guix then pull, because the latter is for the guix package only? <Digit>oh yes, to actually update everything in your profile. :) sry, "keep up" was ambiguous to me. ^_^ <Digit>actually, i'm still not sure. ^_^ <piyo>well let's just keep hammering hydra.gnu.org just in case.... :-] ***Digit is now known as XXXDigitXXX
***XXXDigitXXX is now known as Digit
<rekado>Steap: one reason the daemon runs as root is that it needs to be able to spawn build processes that run as unprivileged build users. <alezost>rekado: about your C-c C-c shell problem: look at "C-h C-c C-c"; is it still bound to `comint-interrupt-subjob'? <rekado>yes, still bound to comint-interrupt-subjob. (I used C-h k C-c C-c) <alezost>ouch, my guess was that it's not. So I don't know why it doesn't work :-) <civodul`>bavier: i think we need a full-blown graph module <civodul`>ideally based on (guix scripts graph) + (guix scripts refresh) ***yang_ is now known as yang
<Steap>So, I managed to crash my GuixSD installation last night by running "./pre-inst-env guix build package" <Steap>I figured it was because of network issues (been having some disconnections recently) <Steap>(even outside of a guix environment :p) <Steap>and I get a Guile REPL when booting <rekado>XFCE4 needs policykit / consolekit. The "Suspend", "Shutdown", "Restart", "Switch user" fields in the panel are only active when it can get a positive answer on DBus to questions like "CanRestart". <rekado>you can run "dbus-monitor --session" and then add "Action Buttons" to the panel to see these dbus requests and their answers. <rekado>the destination is org.xfce.SessionManager, so if we wanted to fix this we would have to change the session manager code. <civodul>Steap: sorry, i don't understand what failed <civodul>coreutils and dmd (provides halt & reboot) are installed by default <civodul>rekado: you mean "policykit", not "polkit"? <Steap>civodul: tl;dr: not a single command available for some reason <Steap>booting into a guile REPL instead of a normal system <civodul>how did you get into that situation? <Steap>./pre-inst-env guix build python-keystone <Steap>do you know how I can redirect the console output of KVM ? There seems to be an interesting backtrace <civodul>Steap: running that cannot "remove" all these commands <civodul>there must have been something else no? <civodul>you can pass "console=ttyS0" on the kernel command line, and run QEMU with "-serial stdio" <Steap>civodul: well I can't exactly tell you since I do not have access to my GuixSD machine <rekado>Polkit is used for the shutdown fallback. <rekado>there are some hardcoded paths to shutdown executables in xfce4-session/xfsm-shutdown-fallback.c <civodul>rekado: ok but normally we have that in place, don't we? <civodul>or maybe xfce needs to add a polkit rule for itself? <civodul>Steap: looks like 'usermod' and 'dmd' have been removed <civodul>the interesting thing would be to know how this happened <Steap>well, it's a bit late for me to log everything :) <Steap>do we know how well GuixSD behaves with restricted resources ? <Steap>like limited amount of RAM/disk space <civodul>it doesn't remove files at random, even with limited resources :-) <civodul>i can think of 3 ways this can happen: (1) remount /gnu/store read-write and explicitly remove the things, and (2) overwrite /var/guix/db/db.sqlite and run 'guix gc', or (3) install Guix with a different localstatedir and run 'guix gc' with that Guix <Steap>I always forget how it works and end up removing everything :D <rekado>xfce shutdown and reboot via menu work now :) <rekado>is it okay for a file to contain a hardcoded path to an executable in /run/setuid-programs? <civodul>rekado: yes, but OTOH it should be able to find it in PATH <civodul>elogind has the file names of 'halt' and 'reboot' hardcoded, FWIW <civodul>so that pressing the power button works <mark_weaver>guix build package doesn't remove anything from /gnu/store, it only adds things. <Steap>mark_weaver: how do I do that from a Guile REPL ? <mark_weaver>so, can you just run the e2fsck from outside the VM? <Steap>oh, I can do that on a qcow2 file ? <mark_weaver>(it's possible to run things from that emergency Guile REPL, but it's kind of a pain) <mark_weaver>does this qcow2 image contain just a single filesystem, or does it contain a partition map with multiple partitions? <mark_weaver>(my question may show my ignorance of VMs; I confess I almost never use them myself) <mark_weaver>if this happened to me on my bare metal system, I would boot from the USB installer <Steap>it has an ext4 partition + a swap partition <mark_weaver>it may be that someone with more experience with VMs should be helping you here. what does one normally do when the root partition of a VM is corrupted? how does one do the equivalent of booting a rescue system that has access to that corrupted partition? <mark_weaver>Steap: did you try booting into an earlier generation of the system? is there a GRUB menu that you have access to while booting this VM? <mark_weaver>it would be nice if our initrd emergency REPL were easier to use, and that's something we can work on, but honestly it hasn't been high on our priority list because I don't think this kind of problem has ever happened any of us before. we've always been able to boot into an earlier generation of the system. <Steap>mark_weaver: yeah, I get the same failures <mark_weaver>that should have the least overlap with the current generation <mark_weaver>well, since you're the VM guy, I ask again: what does one normally do when the root partition of a VM is corrupted? how does one do the equivalent of booting a rescue system that has access to that corrupted partition? <mark_weaver>because I, as a bare-metal guy, know exactly what I would do in this case: I would simply boot the USB installer. <Steap>we're in the era of "trashable VMs" <Steap>that's how great software engineering is :D <efraim>can you mount the VM in another VM? <Steap>but then that's gonna take me longer than just reinstalling the whole thing <efraim>i ran `guix build nano -s i686-linux nano` and i got back 2x /gnu/store/pl69dz5dr4jvqlyjzii20npcc7kqcbj5-nano-2.4.3 <efraim>that's going to need some investigating <mark_weaver>Steap: well, my conclusion from this is the same as if you had said "I ran 'tar xf icecat-xxx.tar.xz' and now my whole system is fubared". your filesystem got corrupted somehow. it's the only explanation of why simply adding new files to the filesystem would cause long-existing files to suddenly disappear. <efraim>/gnu/store/pl69dz5dr4jvqlyjzii20npcc7kqcbj5-nano-2.4.3 is the i686-linux version <mark_weaver>efraim: that command has 'nano' mentioned twice on the command line <mark_weaver>it's like running 'guix build -s i686-linux nano nano', no/ <mark_weaver>or did you expect it to return the x86_64-linux version followed by the i686-linux version? <efraim>i could try switching it around, but I expect I'll get 2x 64-bit nano ***mark_otaris is now known as {mark}\\[otaris]
<mark_weaver>e.g. "guix build foo --keep-failed" applies the --keep-failed to the 'foo' build, which would not be the case if it worked the way you seem to want. <efraim>I normally add -K at the end, not after build <mark_weaver>right, and if each package build only applied the options seen up to that point, then that wouldn't work. <efraim>I'm trying to remember if `apt-get install -t experimental apt foo bar` will install foo and bar from experimental too <efraim>I guess trying to make some flags per-package and some per-guix-invocation would lead to more confusion in the long term <civodul>it could be due to a transient network issue, or the sender being broken <efraim>wondering if it would be faster than downloading it <cehteh>considering that you have to download the source <civodul>how should we handle the libarchive rebuild? <efraim>yeah but I can probably nearly max out my connection to upstream, hydra normally hits ~150 KB/s <efraim>is it possible to expose /dev/tty for tests? <efraim>and ladspa.org has been down since around august 1st <rekado>efraim: we have two patches to fix ladspa.org. <rekado>well, not fix it, but to update the URL of our package. <rekado>hmm, I spoke too soon. The shutdown and restart buttons are no longer disabled, but they don't actually do what their labels say. XFCE ends but it immediately respawns and the user ends up at the slim login screen. <rekado>how can I view the logs on vt1? Are they stored somewhere? <davexunit>is it possible to set the default value of a field in define-record-type to the value of another field?