<davexunit>rekado: have you been able to make sense of ludo's avr-gcc suggestion? <fps>git is still a 108megs download, but installed it's like 23M <fps>ok, sent a bug report. let's see.. <efraim>I tried to work on opam earlier this week, but upgrading it to 1.2.2 involved packaging some ocaml packages, and I wasn't ready to sort out the intricacies of building ocaml packages <civodul>oh did you have a chance to look into Weechat? <efraim>just enough to check that running it in guix environment didn't work <civodul>efraim: why revert the wget upgrade? <efraim>civodul: it failed on the test phase on all the non-x86_64 hardware <efraim>although I have to wonder a bit, wayland also failed on everything and it just built fine on my machine <efraim>i didn't notice it either until I got the email <civodul>would be good to investigate Wayland then <efraim>I even made sure to run guix package -u before pushing like I forgot with libvpx <MatthewAllan93>hey :), during the installation is there anyway to get wireless working? <efraim>MatthewAllan93: `ifconfig -a` to find the wireless, `ip link ${wireless} up`(i think) to activate it, `dhcp ${wireless}` to actually have connectivity <efraim>command line networking is an interesting challenge <efraim>non-guix question: initramfs launches the OS's kernel and the actual operating system? <piyo>bootloader loads kernel and initramsfs into memory, tells the kernel to look at initramfs, then initramfs loads all the hardware drivers you need, then runs the actual operating system <HotLava>It seems that guix tries by default to download some tarballs from alpha.gnu.org if i build from source, how can I turn this off? <efraim>piyo: same kernel the whole time? <piyo>same but different. better. stronger. with more modules. <efraim>beacause I have one kernel that came with the arm board, and a different one on the sd card <piyo>efraim: i think its entirely possible to make the current kernel run another kernel <efraim>I really hope so, I've been trying to ditch the 3.0 kernel that came with the board for a long time <piyo>maybe the first kernel has to be loaded with its ramdisk so that you can read the sd card? <alezost>HotLava: I don't understand "if i build from source" part: do you mean you use "--no-substitutes" flag? <HotLava>no, i mean when building guix itself, as in the guix binaries <alezost>HotLava: building with ./configure and make? <alezost>HotLava: sorry, once again: do you run "./configure" and get that "downloading file ..." ? <efraim>those are the bootstrap binaries <alezost>HotLava: could you tell more, what shell commands you used <HotLava>alezost: yes, ultimately it's just "./configure && make" <alezost>sorry, I can't believe it; there is something else, cause those messages come from "guix", not from "./configure" <rekado>configure certainly does not download anything. <efraim>ACTION is in and out, sorry for the bad info <civodul>HotLava: 'make' downloads these tarballs the first time you invoke it <davexunit>you will see clear issues with the search paths <davexunit>actually, upon closer inspection at least some of the search paths look correct <davexunit>civodul: new avr-gcc issues, back to where i was a few months ago. avr-gcc insists that the libraries it finds are incompatible. :/ <davexunit>avr-ld: skipping incompatible /gnu/store/...-avr-libc-1.8.1/avr/lib/libm.a when searching for -lm <HotLava>civodul: can i download them first and give make a directory to look in? i want to build on a machine without access to the outside world <civodul>HotLava: sure, you can do that, but make sure you download the genuine binaries <civodul>and just store them where 'make' expects them <davexunit>civodul: it seems there are different subdirectories for the different avr types <davexunit>so I was able to add one to CROSS_LIBRARY_PATH that seemed to work <davexunit>and I can only find a single libgcc.a in the avr-gcc build <Steap_>configure.ac:68: error: possibly undefined macro: GUILE_MODULE_AVAILABLE <civodul>davexunit: normally libgcc.a would be found automatically thanks to the hacks in gcc.scm <davexunit>civodul: it finds the one libgcc.a that I see in the output directory, but it's skipped due to incompatibility <civodul>maybe it's built for a different AVR flavor than the one you're targeting? <davexunit>I'm not sure how, because the AVR libc includes all types of AVRs <davexunit>Steap_: set ACLOCAL_PATH. 'guix environment' does this automatically <civodul>Steap_: yeah, just use 'guix environment guix' and be done with it :-) <davexunit>manually installing deps and configuring env vars is a thing of the past with guix <Steap_>davexunit: yeah but should we add a dependency <Steap_>you'd have to edit the definition of the Guix pacakge, right ? :p <civodul>Steap_: the guix-devel package's dependencies include autoconf et al. <Steap_>civodul: yeah, but should we add a dependency in the git repo <Steap_>like, we recently added guile-json to the required dependencies <Steap_>but we haven't updated the definition of the guix package <civodul>but the guix package has everything anyway <Steap_>davexunit: so do you write package definitions of everything you hack on ? <davexunit>all of my personal projects have a 'guix.scm' file in the git repo for this purpose, yes. <davexunit>civodul: upon inspection of the gcc-avr package in debian, it's clear that our avr-gcc is messed up <davexunit>civodul: it's missing the many other versions of libgcc.a that should be there <davexunit>it's also messed up in that I need to add directories to the library search path that the debian build doesn't need <civodul>but this is common when you compare FHS vs. Guix <civodul>the problem is not that it needs to be added to the search path, but rather that it is not added to the search path by default <civodul>what are the other versions of libgcc.a? <davexunit>civodul: there should be versions in various subdirs like avr25/libgcc.a or avr31/libgcc.a <civodul>we need to find out how to configure GCC for that <davexunit>but it seems like the debian version of avr-gcc knows to search the subdirs <civodul>davexunit: (info "(gccinstall) Specific") mentions various AVR options, plus a --with-avrlibc configure flag <davexunit>civodul: it seems crazy to have to add each avr{n} directory to the search path, so I think something else is amiss. <davexunit>they both think it is a good idea to grovel your source code and magically guess what your dependencies are <Steap_>cyril@cyril-pc ~/guix [env]$ ./bootstrap <Steap_>./bootstrap: line 5: exec: autoreconf: not found <civodul>Steap_: with current master 'guix environment guix' gives what you want <civodul>if you're precisely at the 0.9.0 commit, then you get the error you had <civodul>to be sure, run "guix environment -e '(@ (gnu packages package-management) guix-devel)' <Steap_>I run 0.9.0 like every regular user <civodul>regular users to 'guix pull' or similar regularly, hence "regular" ;-) <Steap_>$ guix environment -e '(@ (gnu packages package-management) guix-devel)' <Steap_>guix environment: error: failed to evaluate expression '(@ (gnu packages package-management) guix-devel)': <Steap_>ERROR: In procedure module-lookup: Unbound variable: guix-devel <civodul>make it "guix environment -e '(@@ (gnu packages package-management) guix-devel)' <mark_weaver>Steap_: you need to change @ to @@ because it's not exported <MatthewAllan93>stupid question but when editing .scm file during installation and there is a root parition. after that it installs correctly but reboot its says waiting for root partition to appear <mark_weaver>MatthewAllan93: what filesystem type is the root partition? is it on LVM? <mark_weaver>can you paste the OS config that you used somewhere? <mark_weaver>(pastebin.com blocks all Tor users, so please don't use that one) <MatthewAllan93>i just used the desktop one but change the hostname, timezone, user, home directory <civodul>MatthewAllan93: did you create that partition with the label specified in the config? <civodul>that is, with: mkfs.ext4 -L root /dev/foo <mark_weaver>MatthewAllan93: if you forgot to set the label of the root partition to "root", you can also fix it later by running the following command as root: e2label /dev/foo root <mark_weaver>in both cases, the last line in the log is "load on machine XXX is XXX ..." <mark_weaver>MatthewAllan93: okay, the system might boot correctly now. <mark_weaver>I can't tell without seeing the config, but it's worth a try. <mark_weaver>(I'm assuming that you didn't do anything else since trying to boot into GuixSD that might have messed up the installation) <MatthewAllan93>i don't think so but when i install a web browser and i will send you my config :). if thats ok <rekado>davexunit: I have no problems with libgcc.a. I only see a message about incompatible libraries when I haven't added the right subdir to CROSS_LIBRARY_PATH. <rekado>e.g. adding the subdir for xmega instead of avr5. <rekado>civodul: the hint to use CROSS_LIBRARY_PATH fixed almost everything for me. <davexunit>I did the CROSS_LIBRARY_PATH thing that you did <davexunit>but I don't think we should need that in the first place <davexunit>you probably got lucky in that the lone libgcc.a that comes with our avr-gcc was compatible <rekado>maybe. My target is an atmega32. <rekado>(microscheme doesn't work so well for me, though. It's clear that it's targeting arduinos, so the port/pin mapping is all over the place.) <mark_weaver>MatthewAllan93: the third chapter in the guix manual is "Package Management", Package installation, upgrade, etc. ***Digitteknohippie is now known as Digit
<rekado>davexunit: microscheme does call avr-gcc with the -mmcu flag. <rekado>but I still need to set CROSS_LIBRARY_PATH. <davexunit>rekado: oh I thought this was a build time option <davexunit>mark_weaver: our avr-gcc build doesn't build libgcc.a for each supported AVR family <davexunit>it builds only a single one, and I haven't figured out how to fix it <rekado>does the debian package come with more variants of libgcc.a? <davexunit>you know all those avr{n} subdirs in avr-libc? <davexunit>their avr-gcc has all of those subdirs as well, and each has a libgcc.a in it <davexunit>we only have the equivalent of /usr/lib/gcc/avr/4.8.1/libgcc.a <davexunit>how do I see what configure and make flags debian uses? <davexunit>(ignorance of debian packages is showing here) <MatthewAllan93>when installing with guix package -i icecat, its says something about build failed: subsitite died unexpectedly <mark_weaver>davexunit: go to http://packages.debian.org/gcc-avr, and then select a specific package, and then in the right column of the package page, see the "Download Source Package" section. in the tarball, you'll see a 'debian' directory and within that a 'rules' file which is a makefile. <mark_weaver>my first guess is that our patching to help gcc find its libgcc_s.so needs to be adjusted somehow. <mark_weaver>davexunit: search for "Help libgcc_s.so be found" in gcc.scm <davexunit>mark_weaver: thanks. that looks like a promising lead. <davexunit>now, I'm not sure how to tweak it. rekado, does anything stand out to you? <mark_weaver>davexunit: oh, there's also the --disable-multilib flag that we pass to gcc's configure script. <mark_weaver>that's more likely to explain why the multiple libs didn't get built, although the patching stuff probably still needs to be adjusted to make it actually work. <mark_weaver>remember that if you change the 'gcc' package, it will rebuild the world, so you'd best start by copying the package definition and tweaking a copy. <mark_weaver>and then once we figure out the right fix, we can do it in core-updates. <mark_weaver>disable-multilib is usually the right thing for us, because we essentially have our own superior approach to multilib <rekado>we don't need to update the gcc package, though, do we? It would be enough to override the configure flags of the avr package. <mark_weaver>and we don't want the paths to end up with things like /lib32 <davexunit>then we'll see what damage the extra phases do <davexunit>I really want to build my firmwares again :) <mark_weaver>davexunit: so, it looks like the easiest way to remove the --disable-multilib option is to wrap the call to 'cross-gcc' in xgcc-avr with (package (inherit (cross-gcc ...)) ...) <mark_weaver>and then override the arguments, using substitute-keyword-arguments to wrap the flags with an expression that removes "--disable-multilib" from the flags <mark_weaver>see 'cross-gcc-arguments' for inspiration, since it removes the --enable-languages flags. ***ajgrf_ is now known as ajgrf
<mark_weaver>the code is trickier because what you have to work with is not the actual list of configure flags, but rather an expression that evaluates to the list of configure flags. <mark_weaver>civodul: regarding those stuck build jobs on hydra: I just killed the associated nix-realise processes on hydra and restarted them <mark_weaver>(I didn't want to delay the building out of the security-updates jobset any further) <davexunit>mark_weaver: thanks. I've been doing the (package (inherit (cross-gcc ...)) ...) thing in my current experiments, now to get rid of that flag. <MatthewAllan93>what should i do about this problem with ice-9, subsitute died unexpectedly when building or installing packages? <MatthewAllan93>well it says "error:in procedure scm-error:" and "error: invalid access-control list ()" <davexunit>that is a much different error than you told us before <davexunit>are you using GuixSD or Guix on another distro? <MatthewAllan93>yes i know just wasn't what error it is, no using guixsd only just installed it before :) <mark_weaver>MatthewAllan93: sounds like your /etc/guix/acl file got corrupted somehow <mark_weaver>guix archive --authorize < /run/current-system/profile/share/guix/hydra.gnu.org.pub <MatthewAllan93>mark_weaver: installing packages is working now for me :D, thanks for your help with everything. really appreciate it :) <civodul>mark_weaver: thanks for taking care of the stuck builds on hydra <fps>hmmm, in my system config i have user fps with /home/fps, but i once had /home/alice. that's not changed on reconfigure? <fps>so my user fps now lives in /home/alice :) <MatthewAllan93>ok, so is there any reason why i have to do that command from before that you said everytime i reboot <mark_weaver>fps: there's a comment in 'modify-user' in gnu/build/activation.scm that says ";; Don't use '--move-home', so ignore HOME." <fps>mark_weaver: i'd expect the new home dir to be created. but of course i also wondered about what should happen to the the old one <mark_weaver>sounds like doing the right thing here is tricky, and we punted. <fps>mark_weaver: and then i thought: shouldn't be the home directories be part of the generations? <fps>mark_weaver: i.e. if a home dir disappears and gets created with another name, it should still be part of the previous generation <fps>that would be very much in the spirit of being able to roll back system configurations <davexunit>fps: stateful things aren't part of generations <mark_weaver>fps: generations only reference immutable store items. it's not practical for a normal user home directory to be immutable. <mark_weaver>and I don't think you'd really want your home directory state to be rolled back along with everything else, would you? <fps>the location is immutable though :) <fps>i see your point though <mark_weaver>fps: if you want to work on a concrete proposal to improve things here, I would suggest trying to think through all the consequences, come up with a proposed patch, and post about it to the ML :) <mark_weaver>but honestly, changing the home directory of an existing user seems like a rather rare and strange thing to do, and there's a million more important things for us to work on :) <fps>mark_weaver: i do agree with that sentiment.. but it's an interesting problem nonetheless. <davexunit>I would expect that /etc/passwd would be changed to point to the directory specificed by the OS config <fps>it feels kinda itchy in this declarative way of setting up a system <davexunit>and the directory be created if it doesn't exsit <fps>i.e. it's state that sneaks in.. <davexunit>stateful things are managed by the service layer <davexunit>we have ideas for using services to manage SSH keys and such <fps>davexunit: actually about your last point; yes, that's what i would have expected.. creating the new declared home director if it doesn't exist and update the passwd file <fps>i agree wholeheartidly <alezost>MatthewAllan93: do you mean after every reboot your /etc/guix/acl file is empty? <fps>that's why i thought about making it part of the system generations.. <davexunit>that sounds like a sufficiently narrow problem to resolve <MatthewAllan93>alezost: no i mean after every reboot, its says looking for root partition <mark_weaver>davexunit: could be as simple as adding --home to the 'usermod' call in 'modify-user' in gnu/build/activation.scm <mark_weaver>(without the --move-home option, which may be a bad idea) <ajgrf>is there a way to switch the global generation without rebooting to grub? <alezost>MatthewAllan93: I thought you fixed your config for that, no? <fps>davexunit: i still have a documentation patch to finish first. for that i'll have to figure out how it's generated first :) <fps>davexunit: but i'd say it's a sufficiently wide ranging change that it's probably good to discuss it on the ML first (the passwd updates) <mark_weaver>I'm not sure if 'usermod' will create the new home directory if it doesn't exist. the man page is not clear on that point in the absense of --move-home <alezost>ajgrf: nope, as switching to a global generation means booting a kernel; you can't do it without reboot <MatthewAllan93>alezost: no, mark_weaver checked my config.scm file and he said it looks fine <ajgrf>alezost: how does it work when you run `guix system reconfigure`? <fps>now, a different question: why do i only get an X mode of 640x480 in qemu on another machine? :) trying to centralize my guixsd installs on a root server with vnc access.. <mark_weaver>fps, davexunit: actually, I guess that 'usermod' probably has no ability to create the home directory if it doesn't exist, at least if --move-home is not specified. <davexunit>fps: my technique is to fix the thing I want fixed, propose the patch, and let the ML debate with actual code. <fps>mark_weaver: i suppose there are other ways than usermod, like patching up the passwd.. is /etc/passwd also not part of the system generations? is it considered mutable? <mark_weaver>usermod can definitely change the /etc/passwd entry, but we currently rely on useradd to create the home directories from the skeleton, and I'm not sure that usermod can do that part. <alezost>ajgrf: when you run "guix system reconfigure", it builds a new system and links "/run/current-system" to it. So if you mean that new commands become available, it happens because "/run/current-system/profile/bin" is in your PATH <mark_weaver>fps: as for X, I would suggest looking in /var/log/Xorg.0.log for clues <alezost>MatthewAllan93: so the label of your guix partition is "root", right? <fps>found the documentation source, too. guix/doc/guix.texi, right? <ajgrf>alezost: right, i guess i'm just confused that you can switch to a newly created profile without rebooting, but you have to reboot to switch to a past one <mark_weaver>fps: gnu/services/xorg.scm contains the code that generates the xserver.conf, which includes a set of included X drivers. maybe you need to add one. <fps>mark_weaver: ok, will check it out. thanks for the pointer :) <alezost>ajgrf: I would recommend to install most programs in your user profile. You can switch to any user generation easily <MatthewAllan93>alezost: yes i have a bios parition because i created a gpt table, then root parition and then swap <alezost>MatthewAllan93: actually I don't know if GPT is supported out of the box, mark_weaver should know better <mark_weaver>MatthewAllan93: I'm confused, I thought we resolved this issue, no? <mark_weaver>did you ever successfully boot after changing your root partition label? <mark_weaver>actually, I confess I don't remember clearly whether anyone has used GPT successfully with GuixSD. <MatthewAllan93>mark_weaver: after going into the liveusb and doing that "e2label" or something like that for the root partition. i then restart and it boots up correctly but every time i reboot it does it again saying about finding the root parition. <mark_weaver>is that just a delay, or does it prevent the boot from proceeding? <mark_weaver>oh, well, I guess your message makes that clear enough. it's just a delay? <mark_weaver>if so, it's nothing to worry about. it just shows that our boot process currently uses polling to wait for devices to be ready, whereas there is surely a better way to do it that has yet to be implemented. <MatthewAllan93>oh ok, i think it prevents the boot from proceeding but i will reboot in a minute and see if it is just a delay <civodul>mark_weaver: i have a GPT and that's fine <mark_weaver>MatthewAllan93: okay. btw, while you were offline, civodul confirmed that he uses GPT with GuixSD and it works fine. <efraim>I think I'm at 0/8 for flashing this sd card. It might be time to pass it to an armhf VM with the debian installer and just install to it <efraim>ACTION goes to look up qemu commands <efraim>does our qemu support arm guests? <mark_weaver>MatthewAllan93: it's generated by the code in gnu/services/xorg.scm <mark_weaver>(it ends up as an immutable file in /gnu/store, since it may vary from one generation to another) <MatthewAllan93>ah ok, just because i want to remove ratpoison and xfce and install i3wm. i remember that slim.conf has to be edited <mark_weaver>MatthewAllan93: you shouldn't need to. the session options are based on what packages are installed in the OS configuration. <mark_weaver>based on looking for files in /run/current-system/profile/share/xsessions/ <mark_weaver>hopefully i3wm installs a *.desktop file there. I haven't checked that. <MatthewAllan93>ok thats makes sense, just check and it doesn't so. i am probably best creating an i3wm.desktop file then <mark_weaver>you can't just create it there, because all of those directories are immutable <mark_weaver>(if you override the protections and forcefully edit /gnu/store, that would violate assumptions made by Guix and it will likely bite you in very non-obvious ways later) <mark_weaver>the right solution is to fix the i3wm package to install a suitable *.desktop file <mark_weaver>a more expedient solution for now is to create a ~/.xsession script <mark_weaver>make sure it's executable with a proper shebang, and it should end by running the window manager. <mark_weaver>the existence of that file with override whatever window manager selection you make in slim. <mark_weaver>actually, I always use an .xsession script because I want it to do a few other things as well <sebboh>Hi, fellow guix. Question: is there a web-accessible package database for GSD? à la packages.debian.org? <sebboh>How would you pronounce that conversationally? "geekst"? "geeks-dee"? ***dmcp_ is now known as dmcp
<sebboh>I'm very new, so please pardon me. The hash for a given build takes into account the source, config, etc, yes? About the config.. is it hashed on the file level or after parsing? So, whitespace: does it change a hash? <mark_weaver>what do you mean by the "config"? the OS configuration? or something else? <Steap>sebboh: a trailing whitespace in the package definition, for instance ? <sebboh>Hm, I guess I do mean OS config. That's all I've provided... some /etc/config.scm in which I defined a user and specified some packages. Now I'm watching guix create packages locally with hashes in the filename. <Steap>but a whitespace in the name of a package changes the package's name, so yes :) <mark_weaver>no, whitespace and comments in there will not affect the result <sebboh>No, trailing whitespace in -- ok. Thanks. Oh, well a name is a string. That's different. ;) <mark_weaver>ditto for whitespace, formatting and comments in package descriptions. <mark_weaver>package definitions and OS descriptions are used to generate what are called "derivations", which are relatively low-level descriptions of how to build the package and what 'inputs' should be made available in the container where the build is performed. the derivation and the inputs all contribute to the hash. however, the derivation is unaffected by things like whitespace and comments in the original descriptions. <mark_weaver>and guix-daemon, which performs the builds, only sees the derivation. <sebboh>ah, right. So... did you guys take the "chose some specific date/time" strategy? <sebboh>or the "remove anything that tries to figure out what time it is" strategy? <mark_weaver>but everything in /gnu/store ends up with fixed timestamps in January 1970 <mark_weaver>and when creating tar files, we also set the timestamp to a fixed value, and ensure the files are in sorted order. <sebboh>ok, I have some memory of that from some presentation slides I skimmed through. <sebboh>I don't know if that's the cannonical source. Didn't check. <bavier>sebboh: no, that file doesn't exist in master anymore <sebboh>oh. :) Well I just google'd for a string that was likely to only occur in two places: the package list and the source of the package list generator. <roelj>Great, it's written in Guile <roelj>How is it done in master? :) <bavier>roelj: see website/www/packages.scm in the guix-artwork repository <sebboh>Hey, suppose I run out of filesystem space or tempfs space or something during the `guix system init ...` stage. I'm running the 0.9.0 usb installer in a VM. Can I just grow whatever resource ran out and then pick up where I left off? Do I need to provide some additional command line argument? <bavier>sebboh: the install should start up where it left off <lfam>Yeah, whatever got built in your /gnu/store will still be there <bavier>roelj: btw, did you read the previous discussion on the ML about build-status icons? <lfam>I'm trying to make a program wrapper but struggling to make it work. Where does the "prefix" in the wrapper for bioper-minimal come from? <roelj>bavier: At which date can I find the thread? <mark_weaver>roelj: it's generated by website/www/packages.scm in the guix-artwork git repository. git://git.savannah.gnu.org/guix/guix-artwork.git <roelj>I'm going to spend some time attempting to add the build status icon to the page, if that's OK with you guys.. <lfam>The build succeeds but the program is not properly wrapped. <lfam>There are two layers of wrapping: the python-build-system's PYTHONPATH wrapper, and the wrapper that I want to make. However, my wrapper is not applied properly. I get two layers of wrappers, but they both include PYTHONPATH and neither include PATH <mark_weaver>roelj: remember that there are multiple supported architectures, and often builds fail on some architectures and work on others. <mark_weaver>but I agree that it would be nice to see that information more easily. <lfam>That wrapper is largely cribbed from bioperl-minimal <bavier>lfam: what you describe does seem unusual <roelj>mark_weaver: I am aware of the four architectures. I have to draw up some UI for how this can be displayed nicely. Once I've got that I'll send a mail on the mailing list with the concrete plan. <bavier>have you tried adding your 'wrap-programs phase after the python-build-system's phase where it wraps programs (I don't know the name off-hand) <lfam>My wrapper happens add-after 'install. I'm not sure when the build-system applies its wrapper. <roelj>One more question, how can I generate output from the packages.scm file? <lfam>bavier: I'm not even sure if this is the right approach. I'm copying the approach taken by nixpkgs. The output executables need to be able to use the `dialog` executable. I am trying to put `dialog` on the path of each of the output executables. <bavier>lfam: try (add-after 'wrap 'wrap-programs ...) instead <bavier>the 'wrap phase is python-build-system's wrap phase <bavier>though if the wrap-program procedure isn't doing the right thing, it would be nice to fix it <sebboh>uh, while booted in the 0.9.0 usb installer.. I guess /gnu is in / and / is unionfs... And I guess that is some sort of tmpfs or ramfs? Can I just activate swap, or do I need to do something else to increase space available to /gnu? <lfam>bavier: Yes, that did it!!! <lfam>Does my wrapper look sane otherwise? <bavier>lfam: we like to add a "inputs" argument and use that rather than %build-inputs <bavier>lfam: reading the source in python-build-system.scm now, I understand why it doesn't work the other way around <lfam>bavier: re: %build-inputs, yes, that was some desperate and blind debugging ;) <lfam>I will have to read python-build-system <bavier>it's "wrap" procedure insists on only wrapping regular files <lfam>Oh, so it won't wrap the symlinks I tried to add-after 'install? <bavier>I'm not sure the situation could be improved either, since python-build-system can't have intimate knowledge of which programs to wrap <bavier>except to maybe to keep an eye out for programs that look like they've already been wrapped <lfam>I spent so much time reading the manual at the beginning, before I tried anything. Now I don't read it anymore. If I had I would have seen the section for python-build-system that would have saved me a lot of time. <karhunguixi>mark_weaver, regarding root encryption. With your help i was able to encrypt everything (root, home and boot) on my Libreboot system. At work (using 0.9.0) i have encrypted root and home, but not boot. (This system does not have Libreboot.) <karhunguixi>yeah, on my non-Libreboot system i updated grub.cfg as well <karhunguixi>i believe i don't add "insmod cryptodisk", only "insmod luks" and "cryptomount .." <ajgrf>are there any power-saving packages? (xfce-power-manager, laptop-mode-tools, tlp, etc.) <davexunit>civodul: there's no way to do downloads with url-fetch that use basic auth, is there? <civodul>you mean https downloads with x.509 server authentication? <civodul>that's not really supported currently, but not needed for Guix itself <davexunit>just curious if there was something automagic that I didn't know about ;) <davexunit>I'm just trying to clone a git repo that I keep private. <davexunit>cloning over https with basic auth should work for it. <civodul>bah, Gnus leaves out text that follows "--" in reply (normally a signature), but when there's text following an inline patch, it omits it <civodul>davexunit: oh but Git does its own thing anyway <fps>davexunit: problems with git and certs? <fps>there's an env var that tells git to ignore the missing certs <davexunit>this is specifically for cloning private git repos within a build container <fps>hm hm, ludo's comment on the git nar download vs installed size made me reconsider current distributed data store systems for distributing substitutions <fps>he mentioned content adressable storage in his remark and the referenced ML message. <fps>it made me lookup up CAS and the similarity to DDSs like morphis or ipfs directly sprang into mind. but there's an important difference in the requirements which would make a DDS for this purpose easier to implement than morphis or ipfs <fps>there's no need for confidentiality as it's all about distributing free software <fps>this rips away several layers of complexity afaict. the essence of kademlia's XOR metric routing could still stay inplace, but instead of routing all traffic through several hops through a cryptographic protocol to ensure confidentiality, the routing could just be a transparent lookup operation.. <fps>so in essence such a dCAS (distributed content adressable storage) node could just be a good ole HTTP server (or HTTPs for a little bit of confidentiality) supporting a select few operations and maintaining a small routing table.. <civodul>what i was suggesting was even simpler than a full p2p thing <civodul>but yeah, the ideal would be a p2p-ish network <fps>oh, you're around. my malfunctioning tab completion fooled me ;) <civodul>i've been profiling things and that's a very frustrating task :-/ <fps>the point while i'm pondering the problem a bit at all is that all the encrytption and hop routing tend to have a cost on systems like morphis and ipfs <fps>are you familiar with kademlia? <fps>well, in essence: every node generates an id that lives in the same adress space as the hashes of the content <fps>and the node stores documents that are close to its id <fps>that makes routing easy. <fps>the complexity really comes into it when doing onion routing, NAT traversal, etc.. <fps>for a network of content serving nodes that are accessible via HTTP all that would go away <civodul>possibly, though some may want anonymity <mark_weaver>in general, it would be nice for users to not have to reveal the set of software they use. <fps>i just wondered about distributing the load of serving binary substitutes with the least effort :) <fps>and the least amount of duplicate traffic and cpu resource usage <mark_weaver>on hydra.gnu.org itself, we have nginx running as a caching proxy in front of the real http server. <mark_weaver>I see no reason why similar nginx proxies couldn't be distributed around, all mirroring hydra. <fps>and at the same time introducing the CAS approach <fps>so a dCAS came into mind <civodul>mark_weaver: good point, that should work, indeed <civodul>in practice they'd probably have lots of cache misses <fps>another related question though: <fps>wouldn't a different archive format already fix the download size issue in case of git already? <fps>while maybe not fixing it for redundancy in two texlive installs.. <fps>[for the latter a CAS would indeed be the better option i suppose] <fps>how? while the archive format would ship hardlinks in the git archive, it couldn't cross correlate the two texlive archives <fps>or maybe i completely misunderstand an aspect or two :) <civodul>what i had in mind was an "archive format" that would merely contain hashes of the files that make it up, rather than file contents <civodul>and here comes remi`bd, who worked on GNUnet support this summer; right in time ;-) <fps>ah ok, so CAS in a nutshell :) ok, got it <mark_weaver>I like the idea, but I think that should only be done for files above a certain size threshold. <civodul>and probably with HTTP pipelining too <mark_weaver>otherwise, for packages which vast numbers of small files, the transaction costs would overwhelm the savings. <fps>oh, here's maybe one advantage of using a dCAS based on kademlia routing: no manual shipping of nginx proxy lists (mirrors) <fps>but i suppose if you want to go CAS, then using the dds of gnunet is a good choice, too, if it performs well enough. i just had some doubts because of the onion routing and cpu load.. <fps>btw: is the work they did on gnunet for guix in some public repo? <civodul>the parts that hook it up into Guix are in the mailing list archive currently <fps>another [random] thought about the small file sizes.. it could be possible to determine common subsets of files in different binary builds and reference those subsets instead of individual files <mark_weaver>the 'security-updates' jobset is fully built on x86_64 and i686 now. <civodul>mark_weaver: i'm fine with merging if you want <civodul>when it's fully built i'll rebase the tk-update branch <civodul>mark_weaver: re hydra evaluations, i haven't found any good optimizations (yet?) <civodul>OTOH the whole thing runs in 5mn here, which is too much, but still an order of magnitude faster than on hydra <civodul>so i don't know what's going on there <mark_weaver>civodul: okay, don't worry about it, we'll muddle through for now. <fps>ok, one last question for tonight: <fps>how much traffic do you get on your hydra per month? <civodul>mark_weaver: yeah but that's very frustrating <mark_weaver>civodul: if some of the work could be made into a derivation, it could be offloaded <civodul>mark_weaver: also, Hydra eventually switch to JSON instead of XML for the output of evaluations, and i think the reason was that the Perl XML thing was too slow <fps>i do have a few tens of GiB diskspace and some traffix and an nginx on a root server with gigabit ;) <civodul>fps: unfortunately we don't have any figures for hydra.gnu.org <mark_weaver>the biggest problem at the moment is the performance of what's behind nginx. <fps>and how much disk space do you currently have? <mark_weaver>but the biggest problem is likely the braindead RAID setup, by a previous generation of FSF sysadmins who will go unnamed. <mark_weaver>the details have been spelled out to me in the past, and I've forgotten most of them, but the basic problem is that there are RAID arrays where the underlying devices are not spread across multiple physical disks, but rather across multiple partitions on the same disk. <mark_weaver>so a single write turns into multiple writes to several parts of the same disk, far apart from each other. <fps>um, ok, that, if true, doesn't make too much sense :) <mark_weaver>yeah, it's pretty bad, and our I/O bandwidth is almost unbelievably low. <fps>yeah, it's long over bedtime for me, too..