IRC channel logs


back to list of logs

<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..
<civodul>Hey Guix!
<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>unfortunately no
<efraim>just enough to check that running it in guix environment didn't work
<civodul>i'll see if i can do something
<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
<civodul>oh i see now
<civodul>i hand't seen before
<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
<MatthewAllan93>thanks efraim :)
<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 if i build from source, how can I turn this off?
<efraim>piyo: same kernel the whole time?
<piyo>efraim: same kernel
<piyo>same but different. better. stronger. with more modules.
<piyo>efraim: this explanation is good
<efraim>beacause I have one kernel that came with the arm board, and a different one on the sd card
<efraim>i'll check that out too
<piyo>efraim: i think its entirely possible to make the current kernel run another kernel
<piyo>baton touch
<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?
<efraim>I hope so
<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
<HotLava>it's outputting these messages
<alezost>HotLava: building with ./configure and make?
<HotLava>downloading file `gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz' from `'...
<HotLava>from git, to be precise
<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
<civodul>this is one of the "bootstrap binaries", see
<davexunit>rekado: run 'avr-gcc -print-search-dirs'
<davexunit>you will see clear issues with the search paths
<davexunit>at least I think so, anyway
<davexunit>actually, upon closer inspection at least some of the search paths look correct
<civodul>iyzsong, davexunit, mark_weaver: could you comment on (requires JS for decryption), which i'd like to post to Savannah?
<davexunit>civodul: sure thing
<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
<civodul>davexunit: uh
<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>now it can't find a compatible libgcc
<davexunit>and I can only find a single libgcc.a in the avr-gcc build
<davexunit>civodul: that post looks *great* to me
<davexunit>really really good
<Steap_> error: possibly undefined macro: GUILE_MODULE_AVAILABLE
<Steap_>what am I missing here?
<civodul>davexunit: thanks
<davexunit>Steap_: guile's autoconf macros
<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?
<Steap_>davexunit: how do I get those?
<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 :-)
<Steap_>doyou really do that ?
<davexunit>that's how I hack on guix
<Steap_>oh I see
<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
<davexunit>I don't understand.
<davexunit>that is a mistake
<Steap_>but we haven't updated the definition of the guix package
<davexunit>guile-json should be optional
<davexunit>bug needs to be fixed.
<civodul>it's fixed already
<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>sometimes I just make ad-hoc environments
<davexunit>for other things
<davexunit>like right now while I play with avr-gcc
<davexunit>civodul: upon inspection of the gcc-avr package in debian, it's clear that our avr-gcc is messed up
<civodul>davexunit: how is it 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>oh, ok
<civodul>we need to find out how to configure GCC for that
<Steap_>cyril@cyril-pc ~/guix [env]$
<davexunit>but it seems like the debian version of avr-gcc knows to search the subdirs
<Steap_>we've got "[env]"
<Steap_>My life is complete now.
<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>civodul: I'll look into those.
<davexunit>here is today's terrible new software:
<civodul>it's super hype!
<davexunit>it's seems almost exactly like
<davexunit>they both think it is a good idea to grovel your source code and magically guess what your dependencies are
<davexunit>civodul: looks bad
<Steap_>cyril@cyril-pc ~/guix [env]$ ./bootstrap
<Steap_>+ exec autoreconf -vfi
<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 don't get it
<Steap_>I run 0.9.0 like every regular user
<civodul>regular users to 'guix pull' or similar regularly, hence "regular" ;-)
<civodul>but yeah, i agree this is confusing
<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?
<MatthewAllan93>mark_weaver: no it is ext4
<mark_weaver>can you paste the OS config that you used somewhere?
<mark_weaver>( 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
<MatthewAllan93>because i can't paste it
<civodul>MatthewAllan93: did you create that partition with the label specified in the config?
<civodul>that is, with: mkfs.ext4 -L root /dev/foo
<civodul>the examples at assume that the root partition has label "root", as noted there
<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>civodul: FYI, two build slots on hydra that have been stuck for more than a day doing nothing at all:
<mark_weaver>any idea what happened there?
<mark_weaver>in both cases, the last line in the log is "load on machine XXX is XXX ..."
<MatthewAllan93>fixed, thanks :). just run the e2label command that you said :)
<mark_weaver>MatthewAllan93: okay, the system might boot correctly now.
<mark_weaver>without any further action
<MatthewAllan93>is there anything else that should be done aswell?
<mark_weaver>assuming that was the only problem, no.
<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
<MatthewAllan93>thanks :)
<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.
<davexunit>rekado: hmm
<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>based on debian's build
<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.)
<MatthewAllan93>where is the documentation on how to install packages sorry
<MatthewAllan93>thanks rekado :)
<mark_weaver>MatthewAllan93: the third chapter in the guix manual is "Package Management", Package installation, upgrade, etc.
***Digitteknohippie is now known as Digit
<davexunit>"The default for this option is avr2."
<davexunit>we need to add in all of the things
<davexunit>though I'm not sure how
<MatthewAllan93>thanks mark_weaver also :)
<mark_weaver>davexunit: what are you trying to do exactly?
<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>nvm then
<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>the instructions found on the avr-libc website don't mention anything special in the instructions for compiling avr-gcc
<davexunit>rekado: yes
<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
<mark_weaver>I see that Debian has a bunch of them:
<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
<davexunit>transient network error. try again.
<davexunit>our substitute server is often overloaded
<mark_weaver>davexunit: go to, 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>but I already looked, and found nothing notable
<davexunit>mark_weaver: thanks!
<MatthewAllan93>ok thanks davexunit :)
<mark_weaver>my first guess is that our patching to help gcc find its needs to be adjusted somehow.
<mark_weaver>davexunit: search for "Help be found" in gcc.scm
<mark_weaver>that simple patching approach assumes non-multilib
<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 might actually be the main problem here.
<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.
<davexunit>looks like we're deep in the mud here
<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.
<davexunit>I'll give it a try tonight
<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
<mark_weaver>rekado: right
<davexunit>rekado: that would be a start, yes.
<MatthewAllan93>i get the same error while trying to build icecat :/
<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?
<davexunit>or build the entire distro from source
<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 :)
<MatthewAllan93>*wasn't sure
<mark_weaver>MatthewAllan93: sounds like your /etc/guix/acl file got corrupted somehow
<mark_weaver>did you edit it manually?
<MatthewAllan93>no i haven't
<mark_weaver>can you paste the contents of that file?
<mark_weaver>e.g. to
<MatthewAllan93>there's nothing in the file
<mark_weaver>MatthewAllan93: please run these commands as root:
<mark_weaver>rm /etc/guix/acl
<mark_weaver>guix archive --authorize < /run/current-system/profile/share/guix/
<mark_weaver>that should restore it to what it should be
<mark_weaver>not sure what happened there...
<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 :)
<mark_weaver>fps: what did you expect to happen?
<MatthewAllan93>mark_weaver: this is the config.scm file that i used before
<mark_weaver>MatthewAllan93: looks okay to me
<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
<davexunit>home dirs are not immutable
<davexunit>and thus not managed by guix
<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.e. the path..
<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
<mark_weaver>sounds reasonable
<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
<davexunit>I think that would be a good improvement
<davexunit>it should *not* delete any existing state.
<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)
<davexunit>fps: ^ if you'd like to try to fix this :)
<davexunit>--move-home sounds scary
<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
<fps>(and dir creation)
<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
<fps>mark_weaver: ok..
<mark_weaver>fps: as for X, I would suggest looking in /var/log/Xorg.0.log for clues
<fps>mark_weaver: ok.
<mark_weaver>we may be missing an X driver
<alezost>MatthewAllan93: so the label of your guix partition is "root", right?
<fps>found the documentation source, too. guix/doc/guix.texi, right?
<mark_weaver>fps: yes
<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
<MatthewAllan93>alezost: ah ok, i don't mind reinstall if need be
<mark_weaver>I believe that GPT is supported
<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>(maybe I made an incorrect assumption)
<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>civodul: thanks
<MatthewAllan93>mark_weaver: its alright now :), don't know why it is
<MatthewAllan93>i am really glad though that there are no problems now :)
<mark_weaver>okay, sounds good, I guess? :)
<MatthewAllan93>yes it is :)
<mark_weaver>MatthewAllan93: okay. btw, while you were offline, civodul confirmed that he uses GPT with GuixSD and it works fine.
<MatthewAllan93>mark_weaver: oh thats good :), thanks for letting me know
<davexunit>we need a Minetest equivalent of this:
<efraim>for a server I assume
<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
<MatthewAllan93>where is the config file for slim?
<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.
<MatthewAllan93>ah ok, thanks mark_weaver :)
<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)
<MatthewAllan93>oh yes forgot about that sorry
<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>(in the foreground, preferably using 'exec')
<mark_weaver>the existence of that file with override whatever window manager selection you make in slim.
<MatthewAllan93>ok thanks :)
<mark_weaver>actually, I always use an .xsession script because I want it to do a few other things as well
<mark_weaver>you're welcome!
<sebboh>Hi, fellow guix. Question: is there a web-accessible package database for GSD? à la
<mark_weaver>sebboh: it's rudimentary, but:
<mark_weaver>btw, we call it GuixSD, not GSD
<sebboh>ok, thanks and thanks.
<sebboh>How would you pronounce that conversationally? "geekst"? "geeks-dee"?
<davexunit>geeks ess dee
<sebboh>:( I left that one out.
***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.
<sebboh>Steap, yes.
<Steap>sebboh: no
<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>because only the post-parsed data is relevant.
<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?
<davexunit>there are many determinism issues
<davexunit>timestamps are a common one
<mark_weaver>we haven't yet addressed them all
<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.
<roelj>I would like to add the build status to the package list at: I wonder how the current page is generated. Could anyone point me in the right direction?
<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: No.
<bavier>roelj: starting at
<roelj>bavier: At which date can I find the thread?
<roelj>Oh thanks
<mark_weaver>roelj: it's generated by website/www/packages.scm in the guix-artwork git repository. git://
<roelj>mark_weaver: Thanks.
<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..
<bavier>roelj: I think that'd be cool
<lfam>This is the WIP broken wrapper that I have:
<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.
<efraim>microsoft opensourced visual studio code apparently MIT license
<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
<lfam>ACTION trying 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!!!
<bavier>lfam: good
<lfam>Does my wrapper look sane otherwise?
<bavier>lfam: we like to add a "inputs" argument and use that rather than %build-inputs
<bavier>but otherwise looks good
<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
<bavier>and it wraps all of them
<bavier>*in the bin directory that is
<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.
<efraim>or guix/build-system/python.scm
<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>"proof": (only one partition mounted)
<civodul>karhunguixi: would be neat if you could help address !
<civodul>sounds like little is missing
<karhunguixi>i'll take a look
<civodul>great :-)
<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>yeah, figured.
<davexunit>just curious if there was something automagic that I didn't know about ;)
<civodul>no such thing! :-)
<civodul>it Wouldn't Be Hard™ though
<civodul>provided CA certificates are around
<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
<davexunit>I thought it used basic auth...
<davexunit>ooh, it may just work
<davexunit>ACTION tries
<fps>davexunit: problems with git and certs?
<fps>there's an env var that tells git to ignore the missing certs
<davexunit>fps: no
<davexunit>this is specifically for cloning private git repos within a build container
<davexunit>I've figured it out
<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?
<civodul>not in detail
<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
<civodul>yes i know this high-level view
<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 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.
<mark_weaver>civodul: any reason why not?
<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
<civodul>well, depends on popularity i guess
<fps>another related question though:
<fps>wouldn't a different archive format already fix the download size issue in case of git already?
<civodul>it would
<fps>while maybe not fixing it for redundancy in two texlive installs..
<civodul>these are the same problem in fact
<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.
<mark_weaver>yeah, definitely +1 to pipelining :)
<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>it's incomplete though
<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.
<mark_weaver>time to merge I guess...
<mark_weaver>(although armhf and mips are far behind)
<civodul>mark_weaver: i'm fine with merging if you want
<mark_weaver>okay, will do.
<civodul>cool, thanks!
<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.
<mark_weaver>thanks for trying
<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 ;)
<fps>oops *traffic
<civodul>fps: unfortunately we don't have any figures for
<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>not enough. less than 800GB
<mark_weaver>and only 4GB of RAM
<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.
<mark_weaver>anyway, I have to go afk for a while. ttyl
<fps>yeah, it's long over bedtime for me, too..