<bms_>Oh... yeah, I'm pretty sure those names aren't constant. You should set a label when you use mkfs, like it does in the manual. Set the config file pointing to the hard drive's name as it is when you install.
<gazon>quiliro: no you're right, but it might still work if you change the config and system reconfigure --no-bootloader (or whatever)
<bms_>--no-bootloader would work, if you already have Grub installed and would like to write a manual menu entry.
<bms_>At least, that's how I've used it in the past.
<wsddn>Quick question: using guix packages with the -m for manifest option: why would in one generation guix uninstall and install a package whose version has not changed (but the hash has changed) with no substitutes?
<quiliro>if the software has not changed and the hash changed, that means the way it is compiled has changed....does that clarify a little, wsddn
<quiliro>the definition changes when the hash changes
<quiliro>the hash changes when the dependencies change
<wsddn>I ask because in the space of 40 minutes weechat and icecat reinstalled twice
<quiliro>so yes....the definition changes when i change the configuration of the package or its dependencies even if the package or its dependencies use the same versions as before...even more if those packages change versions
<quiliro>well i have never changed anything....so, it would be the developers
<fusion809>Hey does guix write its output to a log file? I ask because as I'm running it from the command-line without a GUI I can't scroll back on the output all that far and it would be helpful if I could view the full output. I know redirecting the output to a file (with COMMAND > output.log 2>&1) would manage this but I'd like to see the output in real-time so I can see in real-time what guix is doing and this method wouldn't allow for
<janneke>i don't think we have log files for `guix system'
<fusion809>Could I suggest that feature be added like at a bug tracker? I don't think it'd take a lot of work to do and would be of benefit to both users and developers as it means that if an error occurs it should be easier to give developers the full output log.
<fusion809>Yep I know that, but how to set scrollback using it.
<fusion809>Well ~/.bashrc is also a config file for bash. I usually use bashrc but bash_profile I'm willing to use too.
<fusion809>Confused as ya said, "you can scrollback as far as you config file determines....i think in bash it is .bash_profile" I assume that means you know how to set it up with .bash_profile. Not trying to insult ya just trying to understand what is going on here.
<fusion809>brb gonna switch to i3 on my host OS, KDE is freezing up on me and it's getting frustrating.
<quiliro>fusion809: i do not remember how i did it.....i think it is HISTFILE variable
<davidl>quiliro: apparently a lot more common than I thought.
<brendyn>I think at the moment we should take advantage of not having any backwards compatibility or LTS version to maintain. That way people like Ludovic can keep improving Guix unhindered until it's ready for prime time
<fusion809>quiliro: can I email email@example.com without subscribing to any mailing lists?
<fusion809>I created a partition table similar to that mentioned in "Preparing for installation". Except I had /dev/sda2 as a SWAP partition, likewise /dev/sda1 is the root partition. Never mentioned a partition specifically for GRUB.
<fusion809>Hey I'm gonna try creating a BIOS boot partition in case it makes a diff. The prob is how to do so with fdisk. cfdisk and gdisk can't be used for MBR so fdisk is my only option to my knowledge.
<fusion809>Doesn't seem to be present. Please don't tell me I'm gonna have to go through the slow process of running guix system init again. Please tell me I can label the partition without destroying the data on the partition
<catonano_>scrapy is a really cute framework. It' s too bad that it' s not packaged in Guix :-/
<wigust>So, i can boot into grub, but it want kernel to be in /store/... not in /gnu/store as i have. But it's not that important as i can change it while booting for now. There is an error: no suitable video mode found. Booting in blind mode.
<amz3>what's the purpose of the guix-patches mailling list? Otherwise said, if I have a patch I must send it to that mailling list?
<rekado>ng0____: not sure about what “the first version” refers to (can’t look it up right now), but I think the answer is a tentative “yes”: the idea is to make kbd look for other layouts in directories given with an environment variable.
<ng0____>the first version refered to neo2 not being an input-only-source but an extra package
<quiliro>ng0__: are you sure i am not using time that would be more valuable in other tasks?
<ng0__>those who help you do so because they want to, not because they are pressured into it
<quiliro>of course that if i learn, i can help....have to weigh benefits
<reepca`>I'm going to attempt to init onto my other hard drive that I got specifically for setting up GuixSD now, I've been putting it off for awhile. Will use the device label and see how it works for me.
<quiliro>sure...i know it is good will...but i do not want the project to loose time
<fusion809>Ah folks I've noticed something odd about GuixSD and I'm wondering if it's an oversight or deliberate. For some reason on my recently installed GuixSD system my PATH variable for the root account is shown in this screenshot http://i.imgur.com/rSzLDy5.png. What's relevant is not what's in it, it's what's not in it: /root/.guix-profile/sbin. Without that useradd, usermod and other important commands are not
<fusion809>available from the command-line. Most distros have these commands in the root PATH so I'm guessing this is an oversight, but I'm here to ask am I right or wrong in this belief?
<fusion809>If it's an oversight I'm happy to file another bug report, but if not I'd rather not irritate the devs by filing a false bug report.
<fusion809>I have not edited ~/.bash_profile, ~/.bashrc, /etc/profile or any other shell-relevant files. The only thing I've done it is set my root password and installed a few packages (vim, screen, git, wget and curl) with guix. So this seems like this is the default root $PATH.
<efraim>fusion809: go ahead and file the bug, it looks like it should be there
<fusion809>Thanks, I thought everyone was either confused what the problem was or not sure whether it was an oversight.
<ng0__>which commands? useradd and usermod are not really persistent on GuixSD
<efraim>root's profile's sbin was missing in either case
<lfam>fusion809: The value of PATH is generated based on which packages the user has installed. So, if you install something with an sbin directory, then your PATH will include that directory next time you open a login shell
<fusion809>lfam: not so far. That's not the problem it's that /root/.guix-profile/sbin contains several binaries that I, for one, think should be in the $PATH by default like groupadd, groupdel, cfdisk, fdisk, fsck, etc.
<lfam>fusion809: groupadd and groupdel won't work on GuixSD. The disk-related programs, on the other hand, are most likely found in /run/current-system/profile/sbin, which is in your $PATH
<lfam>You're free to install groupadd etc, but they won't do the right thing
<reepca`>fusion809: See section 6.2.2 of the manual, specifically "packages" - "The set of packages installed in the global profile, which is accessible at ‘/run/current-system/profile’"
<fusion809>I'll be .... I rebooted and now /root/.guix-profile/sbin is in the root $PATH. Might have been similar to what ya were talking about lfam. Seems odd though as I thought these commands came by default with GuixSD, they are found in most distros by default, but I suppose yas take barebones to a whole new level
<lfam>fusion809: We handle groups and group membership declaratively at the system configuration level.
<lfam>Also, you don't need to reboot to check changes to your login shell. `bash -l` will invoke a new login shell. It's much faster for experimenting
<reepca`>notice how (at least in the default configurations) packages includes %base-packages. My question is why /root/.guix-profile/sbin has stuff in it if the root user didn't install it there - is /root/.guix-profile initially a symlink to /run/current-system/profile?
<ng0__>woo, after 5 months I ca ndelete the neo2 branch :)
<quiliro>i have noticed the partition was not bootable
<lfam>reepca`: Not sure. If I uninstall all of root's packages that include an 'sbin/', then root's PATH no longer includes an entry for '/root/.guix-profile/sbin'
<reepca`>perhaps one of the few things fusion809 installed had a propagated-input that installed one of the mentioned binaries to /root/.guix-profile/sbin?
<bavier`>paroneayea: lots of exciting talk on HN right now :)
<reepca`>although if it had, that should have added it to the PATH anyway... my guess would be that a new shell wasn't started since the packages that put stuff in /root/.guix-profile/sbin were installed.
<quiliro>did not work...will try again with the boot activated...perhaps grub will then recognize it
<quiliro>or ....how can i grub-update or grub-install?
<ng0__>will show your partition table and information about it
<davidl>quiliro: idk, but if you just want it running you might be better off with MBR/DOS. If you use GPT you should possibly use separate /boot and set the grub_bios on flag with parted on the boot partition.
<lfam>Okay, then you just need to update root's guix package and restart the daemon. Make sure your systemd service file executes a symlink like '/var/guix/profiles/per-user/root/bin/guix-daemon' and *not* an absolute path to /gnu/store
<lfam>Our old service file had a bug that caused users to use old guix-daemons forever until they were garbage collected :/
<davidl>quiliro: I have had a very strange boot issue once which I solved after a very long time by "wipefs --all /dev/sda" and "head -c 3145728 /dev/urandom > /dev/sda; sync" and then repartitioning.
<reepca`>lfam: updating root's guix package here meaning guix pull, right? I've had a weird history with that - for the longest time, it wouldn't use guile2.2, and then I did "guix package -u guix" and now I think it does. Also, is savannah doing okay? It's been at 26KB/s for awhile here.
<lfam>reepca`: Savannah only serves the code of Guix itself. The rest of what we serve comes from another server, which is pretty slow, and we work around that by putting a mirror in front of it. If the file you requested is not in the mirror cache, then you could experience slow transfers.
<lfam>Soon this will improve. We have a new, more powerful, machine that should improve the speed and reliability of substitute distribution
<reepca`>Said slow speeds were happening during guix pull
<lfam>Where is Python 2.7.9 coming from? That's not a recent version.
<snape>davidl: I've read your script, and there's something I don't understand: why do you 'mkpart primary' on a GPT disk? There is the exact same thing in Guix, which is why I ask. I thought primary partition didn't exist with GPT.