***aeva is now known as test
***test is now known as aeva
<aeva>I'm having trouble booting the live install usb... I downloaded the 0.9 x86_84 xz file, verified the signature (would be great if the docs included info on how to get the public key - that is not obvious information), extracted it, dd'd to a usb stick, and attempted to boot to it. In libreboot's grub prompt, I hit "search for grub configuration outside of CBFS", and then selected "Load Config from (usb0,1). <aeva>and hitting OK, shows a guixsd grub, and hitting enter blanks the screen, hangs for about an error, and then shows the same error, and hitting enter loops back to the guixsd grub prompt etc <aeva>trying again a 3rd time is more like the first error, but the guixsd grub prompt is a generic blue prompt instead of a nice graphical one <aeva>I... have no idea what is going on here :| <lfam>aeva: I have no idea what's going there either. I know some people are using GuixSD on Libreboot so it should be possible. I would send a bug report to bug-guix@gnu.org. <lfam>Is it expected that the x86_64 installer would want a 32-bit grub? <fps>is it libre-boot or lib-reboot? :) <francis7>grub's usb support is buggy, not all drives work <aeva>I did get it working >_< <aeva>reflashed the drive, still didn't work, put it into a usb port and got a working console <aeva>sorry, I tried to post it earlier, though my connection is super flaky <francis7>mark_weaver, do you know what aeva's problem might be? <francis7>aeva, mark_weaver's a guix hacker, and uses an x200 <aeva>I mean, its working now :| so like, usb spiders or something I guess <francis7>libreboot's documentation for guix is rather limited <mark_weaver>aeva, francis7: as I (vaguely) recall, when trying to boot a USB stick from Libreboot, I found that sometimes GRUB was unable to see the USB stick. it seemed to be sensitive to which USB port I used, when I plugged in the stick, which stick I used, and/or some amount of luck. I don't remember the details, but I remember it being somewhat flaky. <mark_weaver>once I got GuixSD installed, I never had to boot from USB again, so it's been a long time since I tried it. <aeva>I got the install got the install to finish, but upon reboot it does "failed to resolve partition 'root'" :/ and having trouble getting it to boot back into the usb >_> <aeva>debating tearing the drive out and putting it into an enclosure and plugging it into another machine <aeva>vs pulling the dock out and trying to make a live CD <mark_weaver>it sounds like you specified the root partition device incorrectly. <aeva>once I can figure out how to get at the drive :) <aeva>I can copy what I think I wrote :)? <mark_weaver>aeva: do you remember what the 'device' and 'title' fields were in the 'file-system' specification for the root partition? <aeva>I referenced this config http://pamrel.lu/fd88a/ main difference between her drive setup and mine is I just threw it all into one partition <aeva>I think I left the device and title sections alone (root for device) <mark_weaver>aeva: did you set the partition label on the root partition to be "root" ? <aeva>I don't think I touched the partition label <mark_weaver>so, the easiest fix would be to run "e2label /dev/XXX root" <aeva>once I can boot back into the usb drive o.o <aeva>ima try an enclosure and a different machine brb <lfam>That part of the manual is confusing. I made the same mistake <aeva>yeah - I kind of want to make a script that generates a system config <lfam>I'm writing a patch for the manual <aeva>ok, so grub fails to load operating system, stating /vmlinuz not found. loading from grub config.... holy shit it works :D!!!!!!!! <mark_weaver>aeva: you should make a symlink from /boot/grub/libreboot_grub.cfg to grub.cfg <mark_weaver>then, the default item in the Libreboot grub.cfg will load GuixSD's grub.cfg automatically <lfam>I think that point 2 of section 7.1.3 should be edited to remind the user that the label set my mkfs must match the (device) name in (file-systems). Thinking about how to phrase it... <aeva>so a few misc questions - where would be the best place to the keyboard layout (can this be done in the system config?) and how to set the swapiness to 0 :/? <aeva>(symlink fixed the boot problem) <lfam>Too bad there's no such thing as `mkfs.ext4 --label`. It would make it easier to write documenation <lfam>mark_weaver: Yes, but the long-options let the example command-line describe itself to some extent <lfam>I'm reading about the interaction between device and title in the file-systems configuration. I now see the value of letting the installation instructions remain vague. <mark_weaver>we don't have an out-of-the-box way to set the swapiness <mark_weaver>I guess we should have a generic way to set sysctl parameters, but last I knew we didn't have one. <aeva>that would be really handy :) <aeva>is there a way to set capslock as a ctrl key from the system config? <lfam>I want to clarify the installation instructions but I don't want to make them too specific while glossing over the interaction between 'device' and 'title'. But I think that most users who need the step-by-step instructions will start by copying an example configuration. And once they are ready to use GuixSD with more complicated partition layouts, they will be more familiar with the options available. <mark_weaver>aeva: in my OS config, I created a hacky 'anti-caps-lock-service' to do that job for the text consoles. <aeva>I'm a fan of having "beginner" and "advanced" tutorials <mark_weaver>that's just the top of my config. some of the module imports may not be necessary for yours. <mark_weaver>probably there's a nicer way to do an anti-caps-lock-service, which is why I never submitted this upstream, but I haven't gotten around to researching it. <mark_weaver>as for arranging it in X, I run "setxkbmap -layout us -option ctrl:nocaps" from ~/.xsession <mark_weaver>if that file exists, it must be executable with a proper shebang at the top, and the last thing it does must be to run your window manager (or session manager) in the foreground. <aeva>X is probably good enough :) <mark_weaver>if that file exists, it overrides whatever window manager you selected from the slim display manager. <mark_weaver>(although it looks like we'll have gnome-shell in the repo in the next couple of days) <lfam>mark_weaver: How can I double check the store path of the grub used to boot? <lfam>I think I just rebooted with that grub patch applied but I want to be sure <mark_weaver>lfam: look for the store paths in /boot/grub/grub.cfg <mark_weaver>in particular, the line that starts with "search --file --set /gnu/store/..." <aeva>weird. sudo emacs /etc/config.scm - wont let me edit, says its read only <aeva>where does the system config usually live? <mark_weaver>but some files within /etc are actually (via symlinks) files in /gnu/store, and it's important that you don't edit those. in fact, it's mounted read-only on GuixSD to prevent accidental edits. <aeva>oh. how should it be updated? <mark_weaver>aeva: the system config is not managed by Guix at all. it's up to you to keep track of it, preferably in a VCS. <lfam>aeva: Did you copy that file from the example configuration on the USB installer? <lfam>I did, and I hit the exact same problem. We are making all the same mistakes :p <aeva>yeah - though I didn't think I needed to save it anywhere <lfam>You can keep the configuration anywhere really. But I guess that if you copy it from the installer, you have to chmod 644. <aeva>copied it over, edited it based on other examples <aeva>so if I want to install new things via it instead of the guix package command, what would be the expected workflow? <aeva>I assumed it would be "edit file, run a command" <lfam>Yes, and the command is `guix system reconfigure config.scm` <davexunit>I find it better to manage user profiles separately <lfam>And then you have to reboot for it to take effect <lfam>That's a good point. Early days for us :) <davexunit>lfam: adding a new package to the global packages list and reconfiguring will make those packages available immediately <davexunit>it's system services that require the reboot currently <lfam>I was thinking about this difference between GuixSD and NixOS earlier. On NixOS, the service changes take effect immediately, and the need for a reboot on GuixSD is annoying. But on the other hand, you never know what state there may be in services that NixOS doesn't think needs to be restarted. For example, if services foo and bar interact, and you edit foo.nix and then reconfigure, who knows what might happen with bar? <davexunit>lfam: this isn't a deliberate decision, it's a known limitation <lfam>I know, but it's not the worst limitation <davexunit>NixOS uses systemd so they just get this feature <lfam>It's a limitation that makes things very safe, rather than less safe <davexunit>the goal would be to safely do the service upgrades <paroneayea>mark_weaver: I did the same thing re: putting /etc/config.scm that aeva did <paroneayea>I think the system install docs encourage that.... <mark_weaver>bah, I want to make a reservation at a local restaurant in the Boston area, and they only accept reservations via an online service called "opentable.com". <mark_weaver>in order to use this service, you must (1) use their non-free javascript code, (2) agree to a rather lengthy legal agreement which among other things prohibits you from going to court to assert or defend your rights, prohibits you from taking part in class action lawsuits, and prohibits you from "creating any derivative product" of opentable.com. <lfam>Do you need a reservation? Maybe you should just give the restaurant's host or hostess $20 (or whatever amount is appropriate). Or just be courteous and hope for the best. <mark_weaver>but, as usual, services can get away with this BS because almost no one reads the agreements, they just click the button that says "I've read and understood the agreement" without even looking. <lfam>Of course, you can't use the world wide web if you don't <lfam>At least, not the part that everybody else seems to use <davexunit>they make it purposely difficult to understand the conditions you are agreeing to. <davexunit>so less steadfast people will just agree and move on <lfam>Indeed. You subjugate yourself when you click the mouse button <lfam>I don't like mixing the web and restaurants. Seems profane to the art somehow. Reservations should be made on the phone or in-person a few days before. <mark_weaver>and the number of people who actually read the agreements is so small that we're utterly insignificant, so the norm is to make the agreements totally egregious. <paroneayea>mark_weaver: and the courts recently held up a rule that ToS documents can block the right to class action lawsuits... <paroneayea>(wasn't that even at the supreme court, if I heard right?) <paroneayea>could have been a federal court but not the supreme court <mark_weaver>paroneayea: yeah, I vaguely remember hearing that as well recently. bah <mark_weaver>I don't remember if it was the supreme court of a federal court. <aeva>lfam: I think it is a little confusing? Or at least, reading a diff is a little confusing. I think a comment in the example scm files would also be handy <lfam>mark_weaver: How would you reconfigure with a patched grub? I did `./pre-inst-env guix system reconfigure config.scm && reboot`. Is that the right approach? <lfam>aeva: Yeah, the texinfo is a little rough on the eyes. Do you want to suggest a change on the ML? I'll take a look at patching the examples. <aeva>lfam: I think part of the problem is that the order of operations here is a little weird <aeva>eg 1) partition your device, so that it matches your config <aeva>2) learn how to write the config <lfam>aeva: The web interface to the ML mangles some of the texinfo because it thinks there are email addresses in there. <mark_weaver>lfam: yes, that's right, assuming that you integrated the patch into the 'grub' package in that git checkout <aeva>lfam: that explains a lot >_> <aeva>mark_weaver: re your question earlier, I am Aeva Palecek :) <aeva>(sorry, didn't see you ask earlier >_<) <lfam>aeva: Writing documentation is tricky :P My order of operations was to start following the step-by-step instructions, referring to other parts of the manual as I needed them. I'm writing this patch for people doing their first installation because I figure that experienced users will know how to configure their file-systems in GuixSD. But if we can make something better, we should. <lfam>And my rule-of-thumb is that for every person that complains, 10 people hit the same problem and don't say anything. So for 2 people to hit the problem in the same day, there must be a lot of us! <lfam>That's when you know the instructions are leading people astray <lfam>aeva: What was your order of operations? <aeva>I scanned the document, saw that there was a system config thing (I was looking for it because I heard about it from a friend who got me interested in trying guixsd), went and found some friends to share their configs, and then went through the steps in the document without looking at the configs in detail until a step called for it <aeva>so, first was download the image and sig file <aeva>second was waste half an hour trying to figure out how to verify the download, since I had to install someone's public key (that would be really good to include in the doc) <aeva>third was spend about an hour getting the usb thing to boot <aeva>fourth was quickly partitioning with cf - just deleted everything on the computer, made a partition for everything, and a partition for swap, set the first to be bootable, wrote changes and formatted <aeva>then mounted under mnt, called the "cow store" thing, mkdir'd /mnt/etc, copied over the config.... <paroneayea>ACTION puts the cows back in the store, sorry about that <aeva>nano config.scm (refrenced friend's configs)... <aeva>and then looped between trying to call system init and figuring out what the modules thing is <aeva>(having guix installed on my fedora laptop was essential to getting past that phase) <aeva>also figuring out how to setup wifi was in there somewhere <lfam>Sounds pretty similar. I guess we should link to a gpg reference. I also had to play the USB flash drive / USB bus lottery <aeva>so yeah, I got tripped up on the labels thing. also I think a cd iso would be nice too? I would have used that instead of the usb :/ <lfam>Oh, you have an optical drive? ;) <aeva>an md5 checksum would have been easier than the gpg thing <aeva>I have a dock I can sit my laptop into that has one, and also an external driver <lfam>I don't think we use gpg so we can authenticate the source. <lfam>mark_weaver: Okay, on the GuixSD system I cloned the Guix source tree, applied the patch, reconfigured with ./pre-inst-env, and rebooted. The confusing thing is that all my generations seem to refer to the new grub. Of course, I didn't record the name of the old grub. Maybe I did something stupid when I was tired last night like initialize with the patch but I don't think so. Thoughts? <lfam>aeva: Have you read about OpenBSD's `signify` program? It's basically just the features of gpg that are used for code signing, without anything else. An interesting middle ground. <aeva>so `guix system reconfigure config.scm` seems to be recompiling everything when I thought it would install like three new programs and a few dependencies :/ - is there something I need to do to get it to just pull down the missing binaries? <aeva>(and if so, if I killed this and did that thing instead, would that screw anything up?) <aeva>like, its rebuilding the kernel right now I think o.o <lfam>aeva: It pulls whatever it needs. <aeva>surely it had a kernel already? <lfam>It's strange that it would be compiling. Surely there are substitutes? Did you `guix pull` to update to the latest package definitions yet? <lfam>I guess it's possible that the substitutes of the initial 0.9.0 release have already been garbage collected on hydra <lfam>I would cancel the reconfigure and guix pull <aeva>should I just let it finish then? <lfam>`guix pull` is like `apt-get update` <aeva>side thought: if someone makes whatever the guix equivalent to a non-free repository, they should call it squix <aeva>so after the pull is done, then the reconfigure thing should work right? <lfam>Well, assuming that was the problem ;) It would have worked anyways, but recompiling the whole system would have taken some time. <lfam>Have you tried out `guix graph` yet? It will give you a scary insight into why so many things need to get rebuilt after some seemingly trivial change. <aeva>or rather, I saw paroneayea do it in a really awesome presentation that made me want to convert :) <lfam>Cool that you have friends who can share their configs with you! <lfam>I need to find this community in my city <aeva>well, one of them is in sweden, one is a stat over from me, and one is davexunit and I forget where he lives <aeva>I don't know of anyone else in Chicago who is using guix <aeva>ACTION waves at paroneayea <aeva>we should get redhat to host that lol <paroneayea>aeva: speaking of college day gnu/linux activities ;) <paroneayea>lfam: it's doing pretty well when I've been there <paroneayea>Meg Ford and Jim Campbell organize it, and they are both awesome <aeva>yeah :) this is a lot of the same kind of fun (sans pizza). once upon a time I was a highschooler and I visited chris at college and he helped me install gentoo on my computer :) <lfam>From one source-based distro to another <aeva>I had described GuixSD the other day as being like Gentoo but for adults :) <lfam>Guix / Nix's source->binary transparency is a huge advance I think. <paroneayea>and then I go to conferences and people are like <paroneayea>and I'm like "Hi person...!" *internal panic as I try to scan my crappy facial recognition db* <lfam>Haha. It's like a Seinfeld episode <lfam>Everyone should wear a pixel qi badge with their avatar <paroneayea>ACTION switches his avatar to x11r5's and sees if anyone notices <lfam>x11r5 is my favorite. You have big shoes to fill <mark_weaver>lfam: grub is not a per-generation thing. grub is loaded before you even get to choose which generation to boot into. <mark_weaver>incidentally, that's why it's important to make sure we don't break grub. <mark_weaver>anything else, even libc, is no problem if we break it. <lfam>Given the steps I've taken, do you think I should send the patch to the ML? <mark_weaver>lfam: what kind of system did you test the new grub on? <lfam>i686, Dell Inspiron 700m laptop. It's a Pentium M CPU with (ostensibly) 512 megabytes of RAM. <mark_weaver>okay, sounds good, thanks! please send your patch to the ML <lfam>Brutally slow to `make` the Guix source tree :) <mark_weaver>yes, but fortunately one does not have to make it from clean very often. <mark_weaver>"git pull" and "make" it fairly quick most of the time. <lfam>Yes, nor do I have to use this computer very often ;) Unfortunately, this GuixSD system will be used for testing until I get a new home server next month <aeva>lfram doing the system reconfigure thing - I just noticed its pulling down stuff I already have again (window maker, same version as is running) :/ <lfam>aeva: Did you change anything else? <lfam>BTW I was just reading the config on pamrel.lu. Good to know that ncurses is where `clear` comes from! <aeva>I added some packages to the system config, but did that before the pull <lfam>I bet that one of those changes affected a dependency of windowmaker. <lfam>Or, `guix pull` updated some dependency of windowmaker, or windowmaker itself <aeva>added rhythmbox, which is probably the most extreme <aeva>other than that I think it was just xset and whatever I need for wpa <lfam>I looked at the dependency graph of windowmaker. I'm sure that at least one of those changed between now and the 0.9.0 release (2015-11-04). So when you updated your package definitions with `guix pull`, the next reconfigure would want to get all the new packages. <aeva>so, the running version of windowmaker is the same as the one being pulled down ...? <aeva>or has the package just been updated despite being effectively the same version? <aeva>(I noticed a bunch of stuff was broken >_>) <lfam>So, even if windowmaker itself didn't get updated, if one its dependencies did, you get a new windowmaker package. All packages are named for the hash of their dependencies, so a single change in the graph creates a new package. But duplicates are deduplicated in the store with hard links <lfam>That's probably what happened. <aeva>can't set the desktop background is the one I recall off hand <aeva>a number of things if you tried to do them it would throw up a error that didn't say anything useful <mark_weaver>aeva: there's another issue that might have bitten you: if you run "guix pull" as your normal user, that only affects "guix" commands run by that user. when you run "guix system reconfigure" as root, that will not use the new packages unless you also ran "guix pull" as root. <aeva>I think I did sudo for both, but not sure <lfam>But if you do then run `guix pull` as root, any duplicate work from your user's `guix pull` is re-used. <mark_weaver>there's a hack to make this a bit nicer: "guix pull" makes ~/.config/guix/latest a symlink to the latest version of guix as compiled by "guix pull" <mark_weaver>so, if you always want root to use the same version of guix as your normal user, you can make ~root/.config/guix/latest a symlink to ~aeva/.config/guix/latest <mark_weaver>actually, what I do is this: I make both ~root/.config/guix/latest and ~mhw/.config/guix/latest symlinks pointing to my git checkout of 'guix', so all of my guix commands always use the version from my git repo. <mark_weaver>among other things, this allows me to keep arbitrary local modifications to guix by using my own private branch which I periodically rebase onto upstream master <lfam>mark_weaver: I read on the ML that you do everything from your git checkout. I wondered, do you also update the guix-daemon that way? <mark_weaver>and updating is vastly faster than "guix pull", since "make" only rebuilds the files that changed since my last update. <aeva>so I guess if I did that it would behave more like other distros where everything packages is just done via root? <mark_weaver>aeva: I don't know what you mean by "everything packages is just done as root" <aeva>I'm not sure I do either :) <mark_weaver>I mostly install packages in my user profile, so I run those commands as my normal user. <mark_weaver>and when I make modifications to guix, I do that as my normal user as well. <aeva>like, generally in debian or fedora, it is the thing to do with managing packages to be root to do it <mark_weaver>the only thing I need to run as root is "guix system reconfigure" <aeva>this is so different than what I am used to :) <mark_weaver>lfam: on a GuixSD, the 'guix-daemon' used is the one from the "guix" package, and that only gets updated when our 'guix' package gets updated. so, my daemon is generally quite a bit older than my 'guix' command. <mark_weaver>aeva: however, it should be noted that when you ask guix to build something, your 'guix' command (running as your normal user) asks 'guix-daemon' to perform the build. 'guix-daemon' is the only thing that's allowed to modify the store. when it performs builds, the builds themselves run within an isolated container and are run as an unprivileged user. <lfam>mark_weaver: I don't understand — can you rephrase that? <mark_weaver>unprivileged users can specify arbitrary package descriptions and ask guix-daemon to build them. if multiple users ask for the same package description to be built, it will only be built once. <lfam>I meant your message about guix-daemon and living in the git checkout <mark_weaver>lfam: it's a bit confusing, but 'guix' includes a package description for 'guix' itself. <lfam>Wow, I didn't expect it to be in gnu/packages. <mark_weaver>so, although the 'guix' command that I run (as a client to guix-daemon) is usually very close to the latest commit on our 'master' branch, the 'guix' package within 'guix' is at an older commit: 5c36edc <mark_weaver>the 'guix-daemon' that is used by GuixSD is that older version. <lfam>Ah, thank you for explaining that. <mark_weaver>so, my 'guix-daemon' only gets updated when we update the version of our 'guix' package within 'guix'. <mark_weaver>but that rarely matters, because the package descriptions come from the client, not from the daemon. <mark_weaver>any user can connect to 'guix-daemon' and send it a package description to build, and it will build it. <mark_weaver>(within an isolated container as an unprivileged user) <mark_weaver>and 'guix-daemon' provides the mechanism to allow multiple users who ask for the same package to avoid building it more than once, without allowing users to interfere with each other or compromise the security of the other users. <mark_weaver>so, every user on a Guix system has the freedom to use their own customized packages. they are not tied to the set of packages chosen by the sysadmin. <jlicht>Is there any place where progress of the fsf-suported donation drive is being reported? <mark_weaver>jlicht: unfortunately not. even we don't have access to such a thing. we need to ask them periodically. <jlicht>mark_weaver: any non-up-to-date updates in already? <jlicht>not that much of a problem, I can wait till the end of the drive as well. <jlicht>Hope you guys can get some powerful machines for the build farm because of it <lfam>jlicht: I can at least tell you for sure the current amount is greater than $your_donation ;) <lfam>So at least that's a number for you ;) <mark_weaver>our build farm, and especially our build farm master machine, is woefully inadequate <lfam>mark_weaver: I tried fps's x86_64 substitute server yesterday. It's very fast. A faster infrastructure will really improve the day-to-day experience of using Guix. <lfam>The list of substitutes arrived in < 1 second <lfam>Right now Guix gives the user ample time to reflect on things <jlicht>looking forward to that. First time I used guix, I thought I'd done something wrong because of the time it took to install the first few packages <aeva>I have mgrl running in icecat <aeva>but, it is cool to see that working tonight :D <fps>i'm still not 100% clear on how to use the substitutes from my own server though <fps>and it all still got pulled from hydra <efraim>move your server to the top of /etc/guix/acl? <fps>efraim: oh, i wasn't even aware that file existed <efraim>although I don't think that should make a difference <fps>also i'm not sure i got all packagaes that are needed for system init. i'd love to find out how to make sure <fps>would be nice if i could contribute bandwidth for at lease x86_64 users until the new hydra appears <mark_weaver>I just want to point out that by using a substitute server, you're putting a lot of trust in that substitute server. <mark_weaver>a breach in that server can trivially lead to root compromise on your machine. <fps>ok, even if everone else is scared to death about my evil motives coupled with my disastrous incompetence <fps>then at least _i'd_ like to be able to use my own substitute server ;) <fps>also there's still guix challenge,no? so i can compare the hashes with hydra's, no? <mark_weaver>fwiw, I'm not alleging evil motives nor disastrous incompetence. <fps>having two servers is better than one only (hydra). a single source of substitutes is even less trustworthy <fps>mark_weaver: yeah, i forgot to put a humor marker :) here we go: ;) <iyzsong>ok, .../pre-inst-env guix system build .../gnu/system/examples/desktop.tmpl get the same error for me. <cby>I am trying to build guix from the git source <cby>on a Debian box running guix as an extra package manager <cby>I was hoping to get all dependencies in my user profile from guix <cby>but I can't seem to be able to use Guile, I keep running on this error on ./bootstrap: configure.ac:68: error: possibly undefined macro: GUILE_MODULE_AVAILABLE <cby>if I get guile and guile-dev from debian, it works fine <efraim>i'm on debian also, i'm checking `guix environment guix` now to check if it works on debian's kernel <iyzsong>cby: it seem that the guile.m4 can't be found. to use guile.m4 from ~/.guix-profile, ACLOCAL_PATH need to contain ~/.guix-profile/share/aclocal <efraim>ok, on debian's stock kernel `guix environment guix` will give you an environment with all the tools you'll need for building guix <efraim>s/will/should/, I think I have a mix of files from debian and guix for building guix <iyzsong>instead of build upon ~/.guix-profile, IMO 'guix environment guix' is easy and work better. <cby>iyzsong: all rigt, that was my next question <cby>efraim: thank you, I'll try that now <cby>iyzsong, efraim: that works great ! thanks for the advice <fps>hmm, i have a little cmake based c++ project i just tried to get to build, without packaging it <fps>i installed cmake, gcc and make.. <fps>oh, maybe i need gcc-toolchain? <fps>about these environment variables: <fps>how about collecting them in a shellscript per profile? that one can source if needed? <fps>ok 14kib/s. gnaah. let's get fps.io:9999 working ;) <fps>fps.io:9999 has this in store: <fps> /gnu/store/m930028h6y385mvzyxqbnly3hlaa4f8k-boost-1.58.0/ <fps>why doesn't it fetch it from fps.io? <iyzsong>fps: we does have 'etc/profile' for the variables per profile <fps>iyzsong: oh ok.. maybe guix package might output a pointer to this :) or maybe i missed it? <iyzsong>yeah, no document about it now, maybe we should mention it in the "Application Setup" section of manual.. <fps>ooh, there we go. sudo guix archive --authorize <fps>then paste in the pub key and ctrl0d <fps>then we have subsitutes that max out my downstream :) <fps>too bad it's not possible per user it seems. had to sudo it since it wants to write /etc/guix/acl <fps>iyzsong: or maybe also output a line in the guix package output a la "updated [...]/etc/profile" <iyzsong>fps: yes, we can display a message when build the file, but I don't know how to detect the search-paths update or not. <roelj>Somehow I have very poor network connectivity with the 'guix' command. Downloading the master.tar.gz takes a day, while downloading with a web browser (IceCat) takes a couple of seconds. (This is all on the same machine, with GuixSD) <fps>roelj: weird.. it's downloaded from savannah, right? maybe it treats different clients differently? <iyzsong>so many strange things happened on GuixSD :o <roelj>fps: Possibly.. I'm trying to figure out why.. If I can find anything, I will report. <rekado>ACTION sent an email to gtk-devel-list@gnome.org to discuss my patches for GTK2_PATH and GTK3_PATH. <mark_weaver>unfortunately, I don't have time to look into it right now <efraim>mark_weaver: boo, i'll take a look at it <efraim>ok, that passed on my machine, both with 5GB of /tmp and with 6GB of /tmp <efraim>that test specifically tests for the cve, but it was commented out before the gtk-pixbuf security update <efraim>I enabled it, but I'll go ahead and re-disable it with an updated message <efraim>after I test that it still builds, should I rebase it on master? <swedebugia>Regarding xfce4 does anybody know how to make the shutdown-buttons i the menu work? (They are greyed out) <efraim>I have an old P4 machine that I'm thinking of setting up with i686 guix for secondary development, having seen how much space some builds take I'm thinking of splitting the original IDE drive 10G /tmp 10G swap and my 2.5" spinning rust drive my / drive <efraim>swedebugia: there are people who know, unfortunately I'm not one of them <anonymiss_>you need a specific group, forgot which one.. one sec <mark_weaver>efraim: I'm a little nervous about disabling that test. <mark_weaver>it would be good to understand what's going on, if at all possible. <mark_weaver>anyway, security-updates is now based on the 'ruby-update' branch. <mark_weaver>I guess I'll cancel all jobs on the security-updates branch for now. it would be better to let the ruby-update branch finish building and get merged first anyway.l <ringst>swedebugia: I know that it has something to do with systemd, and Guix's lack of it <davexunit>rekado did some investigation here awhile ago <davexunit>I think he even came up with a patch to make it work <ringst>I know it happens to Xfce on Debian when you remove systemd <davexunit>I have elogind running and it still doesn't work. it could be a setuid binary thing or something <efraim>mark_weaver: it works fine on all the other architectures, and when I was playing with building it before I got some weird errors with tests being skipped due to lack of ram or other reasons, and then it's group failing because not all of them were run <mark_weaver>efraim: well, I suppose if you just want to disable the test for now, that's okay. <mark_weaver>apparently the test is not very robust -- a very common problem in test suites :-( <rekado>xfce buttons should have been fixed with 25a21c7. <mark_weaver>rekado: has anyone else reported it working for them? <swedebugia>rekado: thanks for the info. I did a git pull on the machine 2 weeks ago. Can I do something else to make it work? <rekado>I think it also requires reconfiguration. <rekado>it was 25a21c7 together with eac26c3 that fixed it for me. <rekado>(well, it still doesn't do what it should, but the buttons are no longer inactive for me.) <mark_weaver>rekado: I'm running 3faf214 and it doesn't work for me. I just tried "suspend" from the xfce logout menu. <mark_weaver>(I don't want to try shutting down or rebooting right now, but I've tried them in the past) <bavier`>what would be the best way to add udev rules and scripts to an os configuration? <bavier`>typically, they would be put in /etc/udev/rules.d/.. and /etc/udev/scripts, but are those directories safe during reconfiguration? <swedebugia>does anyone have an estimate of how many are testing and using/improving guixsd? 10? 30? <davexunit>24 contributors in the past month, 56 in the past year <davexunit>now, the number of people just using guixsd that don't make code changes upstream... no idea1 <rekado>mark_weaver: nothing happening is expected. But the buttons/fields are no longer disabled, are they not? <rekado>bavier: I added a udev rule by modifying udev-service-type. <takside>does anybody know if someone's adding/added support for guix system to install grub with EFI support? <mark_weaver>rekado: oh, the buttons are expected to not do anything? so why did we put effort into making them not appear disabled? :) <mark_weaver>if they don't work, it would seem better for them to be clearly disabled. <civodul>davexunit: so it actually works? ;-) <civodul>ACTION considers stealthily switching his partner's laptop to GuixSD <davexunit>I need the advanced gnome tweak tool to make it a bit more comfortable <fhmgufs>Short question: should the packages of small libraries include the optional e.g. gtk-doc documentation? <mark_weaver>but it would be good to fix it and then use it much more. we have many packages that could use gtk-doc but don't yet have it as an input. <rekado>mark_weaver: well, they were supposed to work. But for some reason all they do is log you out. <rekado>I was going to work on this but haven't found time to do so (as each time I'd lose my session when clicking on these buttons). <stack>hello, I'm researching a way to encapsulate configuration for some daemons alongside the package dependencies to ship different vms, something like docker does, but using what guix or guixsd provides, is there something I can look at or should I use puppet or similar to ship services configuration in containers/vms? <davexunit>stack: you want too look into guixsd's service API <vmb>Can GuixSD use a proxy server for /gnu/store downloads? <fps>vmb: it's a http service, so i think it could <vmb>I don't have transparent proxying so have to configure proxy to use port 3128 - where? <vmb>I have setup my first Guix install in the DMZ for now but would like to find the config item for allowing use of a proxy <fps>vmb, oh, i misunderstood then.. i thought you would reverse proxy hydra.gnu.org <fps>vmb: dunno about using a normal proxy <fps>there's a bug report about it <fps>maybe it has more info <fps>vmb: can you do this: stop the guix-daemon, with something like deco stop guix-daemon <fps>and then run it manually exporting the http_proxy env var.. http_proxy=.... sudo guix-daemon --build-users-group=guixbuild <vmb>OK will try that, thanks. <fps>not sure about the details [service name for dmd and whether the sudo command will honour the env var. might need to sudo su -l and then guix-daemon ....] <fps>and whether it actually works. check the bug report for details. i just came home from work <lfam>fps: Have you considered building i686 substitutes on fps.io? It should be possible on x86_64. <fps>lfam: nope. i also just pulled quite a few subs from hydra to make sure i got as much as possible <fps>lfam: i could try to gc everything that's not 0.9.0 which would give me some diskspace to mirror another architecture.. <fps>and 0.9.0 x86_64 is about 45G <lfam>I wonder what the "demand" percentages are for each architecture. <lfam>Like, how many people want which one <lfam>I'm sure x86_64 is the big one <fps>yep.. dominant architecture.. <lfam>I actually think it's worth keeping 0.9.0 if people are using your server. It helps new users, and they have the most "fragile" expectations. The rest of us are accustomed to waiting ;) Of course, that means they'd have to know about it and choose to authorize it. <fps>lfam: well, at least until the next release.. <fps>i wondered about gc'ing everything that's _not_ 0.9.0 :) <fps>it shouldn't be too hard to find out all derivation output paths for all packages in 0.9.0 and then try and gc everything else <lfam>Or, we could make it so that if Guix detects that a system's first profile is being created, it would print a reminder to run `guix pull`. I feel like we get A LOT of people wondering why they are downloading / building everything, and it's always because they didn't `guix pull` <lfam>Or, a user's first profile. That may be more effective <fps>did hydra gc so many 0.9 packages already? <lfam>I don't know, but your server is faster <fps>yeah, noone's using it :) <lfam>I guess the part of the code that makes the symlink from /var/guix/profiles to ~/.guix-profile <fps>and you still get packages from it even after some guix pulls? <fps>must be stuff that's the same as 0.9 <lfam>Hmm, I'm not paying much attention since I set it up. I haven't needed to install much, really. The list of substitutes arrives quickly and that is nice :) <lfam>Sometimes it takes several minutes to get that list <fps>that box is totally overloaded <lfam>Did anyone else try to apply bavier's unison-doc patch? It doesn't apply to the master branch for me. <civodul>weird that some entries seem to come and go <lfam>How does Guix's list of CVE's get updated? I noticed that `guix lint` didn't complain about the grub CVE. <civodul>see the top of (guix cve) on how it works <civodul>here that's because it's called differently: "grub2" instead of "grub" <fps>civodul: btw: about challenging servers: is it true that you need to have a local build available? wouldn't it make some sense to directly compare output signatures for two servers? <civodul>fps: it does make sense; you need to have at least two things to compare <fps>oops, no, not signatures, but hashes of the outputs <fps>civodul: oh i must have been confused then. i tried to challenge for a package not installed locally with hydra and fps.io urls <fps>but it told me "no local build" or something.. will read more <fps>i went the for n in `guix package -A | cut -f1`; do guix challenge ....; done route :) <fps>oh, and here's another thing just popping up. i used both urls in a guix package -i command. got a 404 from fps.io, then it didn't even try hydra <civodul>fps: could you investigate that case? <lfam>Either Guix doesn't use the info in the list of substitutes correctly or fps.io is giving a bad list <civodul>it could happen if a server provides a narinfo for an item, but then returns 404 for the corresponding nar <fps>package is gtk+-3.18.2 <fps>civodul: hmmm.. lemme check the path.. <fps>there's a .drv in the store, but not hte package itself <fps>yep, for that package i have a guile-builder. a drv for the tarball, one for the package and a lock <fps>but not the package itself <fps>i still get 750k/sec from fps.io.. it's maybe slow on your end, civ? <fps>someone investigated already. interesting that the same package failed to build here <fps>oh well, deterministic failure :) <fps>btw: note that i still tunnel the http port to my other vm. i might get a pubic ip soonish for that vm though <lfam>I'm getting 1.5 MiB/s from fps.io <fps>oops, misread the bug report. it's valid for the other person, but the decoding phase is probably missing anyways <fps>lfam: good :) it's a 100mbit connection i think ;) <lfam>My max is 30 megabits. I'm pretty happy to get half that from around the world <fps>lfam: i'm currenty downloading. does it work in parallel through the ssh tunnel? <fps>lfam: can you do me the favor and try another download right now? <fps>i wonder if ssh tunnels can handle multiple connections wel <civodul>mark_weaver: what's the status of security-updates on Hydra? <civodul>seems we still have many failures there <lfam>I wonder if there a problem parsing '+' <civodul>lfam: yes, it's the bug i was referring to above <civodul>problem with URL encoding in 'guix publish' <mark_weaver>civodul: the gdk-pixbuf update fails consistently on armhf <mark_weaver>and for now, I cancelled all the builds on security-updates so that hydra would focus on ruby-update for now, which is also a security update, but with many fewer rebuilds. <fps>lfam: you might have to get the offending package from hydra.. <lfam>I don't actually need it, it was just a test. The code needs some love to fall-back to the other servers listed in --substitute-urls <fps>lfam: yeah. care to file a ticket? i'm half dead from work right now :) <mark_weaver>civodul: so, it sounds like the problem is not armhf specific, but can happen on any architecture if there's not sufficient resources. <fps>lfam: eh, i can do it, too :) <mark_weaver>it seems that a test is skipped because of lack of resources, and then that triggers an error later. <lfam>Are you saying you'll do it? I'm due to meet a friend <fps>np, thanks for testing.. <fps>mark_weaver: if you want me to update to a particular revision and build some substitutes, let me know ;) <fps>is that a problem in guix-daemon or guix package i wonder (not trying more substitute servers if one failed with 404) <civodul>mark_weaver: gdk-pixbuf already skips on test for memory usage issues; IIUC there's now another with that problem, right? <mark_weaver>civodul: regarding openldap, I see that there's a newer version (2.4.43), but updating it will entail around 2800 rebuilds :-( <mark_weaver>it failed three times in a row, actually, with the same error <mark_weaver>SKIP: cve-2015-4491 1 /pixbuf/cve-2015-4491/original # SKIP Not enough memory to load bitmap image <mark_weaver>PASS: cve-2015-4491 2 /pixbuf/cve-2015-4491/scale-overflow <mark_weaver>ERROR: cve-2015-4491 - too few tests run (expected 4, got 2) <mark_weaver>ERROR: cve-2015-4491 - exited with status 137 (terminated by signal 9?) <fps>drats, i just had a question in mind. oh well, it'll come back to me <vmb>fps: I read the bug report for using a proxy for download but I was unable to get it working in my environment. <vmb>I had the host hooked up in the DMZ and it was buzzing away downloading via http until it cam to ftp for openssl the stopped due to firewall rules. <fps>vmb: mark_weaver and civodul might be of much more help than me :) maybe you're lucky and they have a minute :) seem to be busy though <stack>davexunit: ok thanks for the pointer <vmb>I am pretty much stuck be able to experiment with Guix here until proxy download is working. <mark_weaver>but if you use substitutes from hydra.gnu.org, then I guess you shouldn't need ftp. <fps>an ftp download shoud only happen for a failed substitute, no? <vmb>Yes, I was using the --no-substitutes . I'm new, I haven't got a clue yet! <fps>vmb: oh, try without that :) <fps>i think that was specific to the bug report. did you get the guix-daemon to run with http_proxy exported? <vmb>I did, went had dinner came back later with a screen full of mesages saying use --no-substitutes. Will try using substitutes again. <vmb>:) Downloading from hydra! <vmb>I found Guix purely by accident. I was just about to get more involved in Devuan and started to look again at Debian kFreeBSD and GNU/Hurd <fps>vmb: how do you like it so far? <vmb>I have watched lots of past video presentations already and I am really itching to get packaging. Bye bye dpkg. <fps>vmb: you'll probably find a proxy a little limiting then, for some sources might only be available via ftp.. <swedebugia>wow mpv yields a hefty list of both downloads and derivs to build. This is going to take half of the night :D <vmb>I can put a new VLAN on the firewall with rules that won't affect everything else. <swedebugia>and i'm running guix-daemon over tor and an VPN tunnel to the other side of the world :p <vmb>Just not able to do that at the moment <mark_weaver>civodul: actually, I see now that efraim updated the branch again to disable the failing test, as I had done previously. <mark_weaver>so, after ruby-update is merged (should be in a few hours), I'll rebase security-updates on master and start hydra working on it. ***TML__ is now known as TML-
<swedebugia>now it finished downloading substitutes. the builds was ...profile and the like and took only some seconds 
