IRC channel logs


back to list of logs

<rain1>janneke: 2) remove anonymous unions and structs from 8cc
<rain1>I think I could do this, maybe
<rain1>we will have to see what comes out of thread thouh
<janneke>rain1: :-) yes, let's see
<rain1>there is only 1 anonymous union in 8cc?
<janneke>rain1: i didn't really look
<janneke>beyond the first anonymous struct in anonymous union, that is
<rain1> well here is a patch to name that anonymous union, if there are others or other reasons mes cant compile it i can refactor it more
<rain1>Missing dependencies [i686-unknown-linux-gnu-gcc], run
<rain1>hm is there a workaround for this? or do ihave to install a cross compiler
<janneke>rain1: yes, there is a workaround
<janneke>...but doesn't `guix environment mes' work for you?
<rain1>ah i did not try inside guix, i only have a guix virtual machine just now
<janneke>the hard depedency on i686-unknown-linux-gnu-gcc has been dropped on my wip-hex2 branch
<janneke>but configure and make have not been updated
<janneke>i will have a look tomorrow
<janneke>ACTION -> zZzzz
<OriansJ`>jeez, I almost forgot how many weird edge causes x86 encoding has
<rain1>good evening OriansJ :)
<OriansJ`>rain1: evening rain1
<OriansJ`>janneke: I might have to modify hex2 to get a couple edge cases of x86 to fit into M0. (x86 has requirements on Immediate sizes that can cause serious encoding problems)
<OriansJ`>rain1: do you think it is too aggressive of an idea simply forbid labels that start with a digit and use the !@% symbols to indicate the size of the immediate?
<rain1>I actually prefer it that way!
<OriansJ`>rain1: interesting
<OriansJ`>rain1: but comes the question of if we want to bother with the signed/unsigned variable sized immediate values or simply forbid them for now
<rain1>i think in x86 they can all be signed
<OriansJ`>rain1: nope, about 70+ instructions are unsigned only
<OriansJ`>rain1: mind you, this only contains about 1% of x86 instruction encodings
<OriansJ`>and I have absolutely no intention of making it 5% complete
<OriansJ`>as there is rarely a need for more than 170 of those lines in a program
<OriansJ`>heck the hex assembler example, I am preparing is only requires about 22 of those definitions
<OriansJ`>looks like I'll have to extend M0 to also be able to deal with big and little endianness of immediate values
<OriansJ`>OriansJ -> Zzzz
<catonano>janneke: I was just checking if someone had left sneek something for me ;-)
<efraim>like I do?
<sneek>efraim, you have 1 message.
<sneek>efraim, ng0 says: One thing I haven't figured out in E21/Enlightenment is that one Webbrowser extension behaves very weird thinking the binary path is /usr/bin, while all other WMs/DMs are okay.
<efraim>sneek: thanks
<catonano>see ? :-)
<janneke>catonano: i was just saying `hi' in a funny way back
<janneke>so, morning Guix!
<catonano>morning !
<efraim>under GuixSD what's the absolute path to reboot?
<rekado>efraim: reboot is a message to shepherd
<efraim>rekado: right, but i'm patching enlightenment's configure script to say 'REBOOT="/usr/bin/systemctl reboot"'
<rekado>for me reboot is “/gnu/store/…-shepherd-0.3.2/sbin/reboot” and it’s linked to “/run/current-system/profile/sbin/reboot”
<efraim>is there a suspend or hibernate command?
<rekado>I only see halt, reboot, and shutdown.
<rekado>the suspend and hibernate commands come from the power management packages I think
<buenouanq>isn't reboot an alias of something like $ shutdown -r now
<rekado>“shutdown” is a link to “halt”
<rekado>the shepherd does things differently
<rekado>“halt” itself is just a short Guile script
<rekado>it runs the “main” of (shepherd scripts halt)
<civodul>Hello Guix!
<efraim>git signing on my firefly is killing me, I got pinentry-tty working so I can --detached-sign things but I can't sign commits on that machine
<civodul>maybe bad interaction between gpg-agent from Guix and gpg from the foreign distro, or vice versa?
<efraim>i think at this point i have all from the foreign distro, haven't tried logging out and back in since I got partial functionality
<efraim>worst case is I'll switch the odroid to core-updates and pass the patches there to sign and upload and keep my laptop on master
<civodul>rekado: i think we should do an e-"coding sprint" to work on the performance issues that you have
<civodul>at the very least to clearly identify the source of the problems
<rekado>sounds good
<civodul>then we can have PoCs for each solution
<civodul>just to make sure we're on the right track
<rekado>I need to first set up my machine so that I can make changes to guix without affecting everybody else’s installation
<civodul>yeah that's preferable :-)
<rekado>GUIX_DAEMON_SOCKET=guix:// is really useful
<rekado>I think I’m ready
<rekado>that was easier than I thought
<civodul>rekado: i just posted a patch to test my RPC performance hypothesis
<jsierles>any way to get some more info on what the guix-daemon is doing? i'm stuck with it trying to fetch substitutes.
<jsierles>`updating list of substitutes from ''.. 0.0% - this stays at 0
***nmp is now known as nparody
<jsierles>tracing the process it appears to be writing to the same files over and over in the store.
<civodul>jsierles: could you capture that and send it to bug-guix?
<civodul>please make sure to include as much info as possible
<jsierles>yep sure thing.
<nparody>hi, i am following instructions in Binary-Installation.html
<civodul>jsierles: for instance, whether the store items mentioned in the /var/guix/substitute/cache/xyz at fault actually exists
<civodul>things like that
<civodul>also the complete content of the /var/guix/substitute/cache/xyz file it touches if any
<nparody>when i 'guix pull' it just keeps on printing 'substitute: updating list of substitutes from ''... 100.0%' for hours
<civodul>nparody: literally hours?
<nparody>yes, literally
<civodul>can you try "guix pull --no-grafts"?
<nparody>yesterday at least 4-5 hours before i killed it. today i tried 'guix package -i emacs' and the same thing has been happening for 2 hours now
<civodul>nparody: like jsierles, could you strace the 'guix substitute' process?
<nparody>ok, i'll try that
<jsierles>civodul: the files seem to exist. do you know a way meanwhile to work around it? just now i can't build anything which is not already in the store
<rekado>civodul: I’m going to test the patch shortly. Thanks!
<jsierles>civodul: which process should be traced - substitute --query or substitute --substitute?
<civodul>it's the one that prints "updating the list of substitutes"
<civodul>well, actually both could do that
<civodul>so let's trace both :-)
<jsierles>could there be an issue with the substitute server?
<rekado>civodul: the timings of “guix build hello” and “guix build -n hello” are extremely variable.
<rekado>sometimes it only takes 5 seconds, other times it takes 41 seconds.
<rekado>it’s hard to test the impact of a patch this way :-
<civodul>is it over the network or on localhost?
<rekado>I use a remote GUIX_DAEMON_SOCKET to talk to the server that has /gnu mounted over NFS
<civodul>and if you run this on the server that runs guix-daemon, with guix://localhost ?
<rekado>I can try this but need to get a separate Guix first
<rekado>I’ll copy my directory over in a moment
<civodul>i guess i can try this too
<civodul>this is very sensitive to network latency
<civodul>with ssh://localhost it takes 2 minutes, terrible
<rekado>copying my guix directory right now. I have to leave for a couple of minutes; will test this as soon as I’m back in the office
<divansantana_>busy with guixsd install, says "substitute: updating list of substitutes...100%" and keeps doing that forever.
<divansantana_>that's when doing `guix system init /mnt/etc/config.scm /mnt` or `guix pull`
<divansantana_>hopefully this is a familiar problem for someone?
<civodul>divansantana_: a couple of people just reported the same issue
<civodul>it seems that something is wrong
<jsierles>i'm sending the traces now
<divansantana_>civodul: I'm happy yo here this. Thought it was just me or my luck.
<jsierles>is it a big chore setting up a substitute server?
<civodul>not really, see 'guix publish'
<jsierles>i see, so it's just for sharing our store. maybe then what i want right now is to bypass fetching substitutes and just build?
<civodul>right, so you could do --no-substitutes if you don't mind building
<jsierles>dont have a choice at the moment :)
<jsierles>a way to just fetch a substitute and cache it in the store without using guix?
<civodul>that wouldn't be convenient
<efraim>the only thing really worth caching ahead of time would be the source tarballs, you can always build offline later
<jsierles>hmm, now things seem to be working again
<janneke>sneek: later tell rain1: on my Mes wip-hex2 branch, CC32 is now optional.
<janneke>sneek: botsnack!
<janneke>sneek: later tell OriansJ`: on my wip-hex2 branch i have a handcoded exit42 example in hex2, that can be inspected with objdump and debugged with gdb. handcoded bits because i needed substraction.
<sneek>Will do.
<janneke>sneek: thanks!
<rekado>so, I’m trying to use socat to export the daemon socket over TCP, so that I can use GUIX_DAEMON_SOCKET=guix://localhost:12345
<rekado>I’m a bit confused about the fact that I cannot seem to connect to it.
<rekado>remote systems can connect though :)
<Petter>Wild guess, maybe you need to use instead.
<rekado>tried that too
<rekado>also tried the outside IP
<civodul>rekado: we'd have to look at what socat does exactly
<civodul>BTW, i'm also working on supporting --listen=localhost:2342
<rekado>civodul: what do you think about supporting multiple daemons to run on different nodes?
<rekado>e.g. in a redundant / round-robin setup?
<rekado>that came up today and I think that there’s an assumption in the daemon that there can only be one.
<civodul>rekado: yeah, there can only be one, more or less
<civodul>at least the database is shared, and there's a limit on the number of concurrent accesses
<civodul>but note that "make check -j" actually runs several daemons in parallel
<civodul>BTW running tests in parallel causes difficulties for GC
<civodul>because each guix-daemon instance is unaware of the temporary GC roots of the other instances
<civodul> arranges to run tests/ last for that reason
<quiliro>this is the third day i get "not enough space left" message when installing guixsd on macbook air (has EFI)
<quiliro>tryed with and without EFI partition
<quiliro>tryed with 2 GB partition and with 110 GB partition
<civodul>hello quiliro
<quiliro>i don't think it is because it is an solid state disk, is it?
<quiliro>hello civodul
<civodul>normally if you have enough space on the target device, that shouldn't happen
<civodul>did you run "herd start cow-store /mnt"?
<quiliro>civodul: yes
<civodul>then it probably means the file system on /mnt is full
<quiliro>let me confirm
<quiliro>df says it is not
<civodul>i mean that it was full at the time you got the message
<quiliro> /mnt has 110GB available
<quiliro>and only 3GB used
<quiliro>let me check, maybe i was using another disk
<quiliro>there were 3 disks whern installing: usb installer, embedded disk and usb data with light-desktop.scm
<quiliro>i now removed usb data
<civodul>yeah make sure you're mounting the right disk on /mnt
<quiliro>lsblk says /mnt is in sda1, mount says /mnt is in sda1 and /tmp is on sda1 twice
<quiliro>lightweight-desktop.scm says bootdevice is sda
<rekado>civodul: I’m afraid I cannot see any difference between a version of guix after applying your patch to guix/store.scm and the unpatched version.
<rekado>but that’s not because of the patch
<rekado>it’s just way too variable here
<rekado>building bwa I get anything between 6 seconds and 42 seconds
<rekado>best time yet is 5.7s for the patched variant
<quiliro> / is filling up... it is 68% now
<quiliro>perhaps it is that?
<quiliro>civodul: ^
<civodul>quiliro: if you run "herd start cow-store /mnt", then the image's root file system should not be filling up
<efraim>i built python and python2 from core-updates on aarch64, now building toward gtk gtk2 cmake guix qemu-minimal
<quiliro>civodul: perhaps i did not type it correctly and it failed, i do not remember checking if it worked correctly...thank you
<quiliro>the passwd command is not installed on the usb installer, thus it makes it impossible to lgin from another machine to install remotely
<efraim>Guix still doesn't have anything like apt-file yet
<civodul>it's waiting for someone to write it :-)
<efraim>If I add '#:system x86_64'(or whatever) to a package definition, does that just change the --target?
<civodul>#:system corresponds to --system, not --target
<civodul>setting it overrides --system
<civodul>that's rarely what you want
<civodul>i think the only case where we do that is Wine
<efraim>so the result is it uses i686 make and i686 gcc and everything?
<quiliro> i have installed with wireless without password... i followed these steps
<quiliro>loadkeys dvorak-es
<quiliro>ifconfig -a
<quiliro>ifconfig wlan0 up
<quiliro>iwconfig wlan0 essid putnik
<quiliro>dhclient wlan0 -v
<quiliro>ping -c3
<quiliro>cfdisk /dev/sda
<quiliro>mkfs.ext4 -L my-root /dev/sda1
<quiliro>mount LABEL=my-root /mnt
<quiliro>mkswap -L swap /dev/sda2
<quiliro>swapon -L swap
<quiliro>then i edited lightweight-desktop.scm
<quiliro>herd start cow-store /mnt
<quiliro>guix system init /mnt/etc/lightweight-desktop.scm /mnt --fallback
<rain1>I got errors about wchar_t when I 'make' mes
<sneek>rain1, you have 1 message.
<sneek>rain1, janneke says: on my Mes wip-hex2 branch, CC32 is now optional.
<mekeor>hello guix!
<janneke>rain1: ugh...gcc configurations and build whoes, someone should create an reproducible build environment!
<quiliro>hello mekeor
<civodul>rekado: did you try to build Bazel & TensorFlow?
<civodul>i remember this was discussed at some point
<civodul>and Bazel had a zillion bundled deps
<rekado>yeah, I once tried building Bazel
<rekado>in order to build TensorFlow
<rekado>but I gave up when I saw that packaging Bazel wouldn’t be easy
<rekado>at the repro builds summit the Bazel folks admitted that at that time building Bazel required Bazel.
<rekado>apparently work was under way to make it build with just a shell.
<rekado>civodul: has someone requested TensorFlow? Or do you think we should give it a try for the Guix HPC work?
<civodul>rekado: there's a team at work that needs it
<civodul>currently the approach is to build by hand and to make "modules"
<janneke>rain1: what kind of system/compiler are you running? Mes has been tested with `guix environment guix.scm' which installs gcc-5.4.0
<rekado>civodul: oh.
<rekado>ACTION looks up Bazel
<janneke>rain1: sorry that things -- even compiling C -- can be such a nightmare
<rain1>arch linux
<janneke>can you try gcc-5.4? what version gives you this problem, so that i can look at it?
<rekado>civodul: heh, says: Bazel does not require Bazel to build itself but can be bootstrapped with a shell script (
<rekado>I have a feeling that Bazel doesn’t quite deserve to be listed there when it really just bundles dependencies.
<rekado>“To bootstrap your first bazel binary, please download a dist archive…”
<rekado>which contains generated files
<civodul>maybe we should ping them
<civodul>and remind them of the discussion we had
<civodul>if we threaten them with a line in the "best bootstrapping practices" hall of shame, that might work :-)
<rekado>it might be possible to generate these files without using their pre-built stuff.
<rekado>I’ll give it a try
<rekado>ugh, this means we have to package a lot of the stuff in the third_party directory
<rekado>we have a few of them already
<rekado>but many of the remaining things seem pretty complicated :-(
<rekado>as a first step we could unbundle as many of the third_party jars as we have already packaged and see if the bootstrap script will work.
<civodul>rekado: yeah let's see how complicated it is
<efraim>its not pretty, but I finally figured out if I pipe mail in Hebew from mutt to fribidi and then to less I can read it right to left rather than backward
<civodul>rekado: guix-daemon --listen for TCP:
<rain1>ive got gcc 7.1.1
<janneke>rain1: ah, okay. let me check if i can reproduce your bug report.
<rain1>i installed gcc5 and tried building again, same problem
<janneke>ugh! i broke something adding headers for 8cc and all. great!
<janneke>you can go back a couple of commits, say to bee152ec doc: Release update.
<janneke>i'm flabbergasted why i didn't notice this before, oh well, thanks!
<rain1>did you get my patch for 8cc?
<rain1>the reason im setting up mes is to try te help building 8cc with it!
<janneke>rain1: no? i don't think so!
<rain1>ah i removed the anonymous union
<rain1>let me paste it
<janneke>OK, great!
<janneke>i have been adding C headers (mostly as stubs) to get past 8cc and guile's eval.c #include's , so that's where i goofed up something
<rain1>unfortunately going back to an older commit gives me the i686-unknown-linux-gnu-gcc problem again
<janneke>rain1: do a fresh fetch and hard reset?
<janneke>i fixed configure on master and rebased wip-hex2
<janneke>rain1: you need: f7823d6c build: Make CC32 optional in configure too.
<rain1>sorry, i am still not able to build it!
<Tekk_>Hey, I just installed guix overtop of dragora through the binary installer last night. I think that guix is in an infinite loop with guix pull
<Tekk_>It grabs the .tar.gz, it extracts it, but then it goes on substitution for hydra
<Tekk_>and then prints the substitution at 100%
<Tekk_>and again, and again, and again
<Tekk_>It *is* on a netbook so maybe it's a cpu bound problem, but I let it sit for a few hours and it was still trying to guix pull
<bavier>Tekk_: the repeated "fetching substitutes from ..." is a know issue
<bavier>it's not a loop, just needs to get a lot of information
<bavier>and isn't properly squashed into a single progress bar at this point
<janneke>rain1: ugh! i haven't found the problem yet, although if i do:
<janneke>rm mlibc/include/stddef.h
<janneke>it works for me
***jonsger1 is now known as jonsger
<efraim>CVEs against glibc, exim, libffi, the kernel, and sudo i believe
<davexunit>efraim: is x86_64 not affected?
<davexunit>all the exploits are on i386
<efraim>I assumed it is all the architectures
***jonsger1 is now known as jonsger
<efraim>debian's security email didn't say i386 only
<waynedpj>ahoy all, trying to install 0.13 on a i686 and after the "guix system init" call lots of compiling is happening. is that because the i686 binaries substitutes are not yet available for the packages ? or is there some way to avoid this and speed up the install?
<lfam>waynedpj: We should have the binary substitutes available. It's possible there was a network connection issue at the time you ran the command. I recommend cancelling it and trying again.
<lfam>Well, we should have substitutes available for the 0.13.0 release. If you ran `guix pull` then we won't have built some things yet.
<waynedpj>lfam: thanks. if i hit control+C to stop the "guix system init" call, will i have to start over or will it leave things in a bad state?
<lfam>You can also add --fallback to the `guix system init` command in another TTY to get a full list of what will be done
<lfam>It's safe to cancel and restart the command
<waynedpj>lfam: i did not do a pull but perhaps the init did?
<lfam>No, it won't do it by itself
<waynedpj>OK, then i will try to restart it and see what happens. thanks again, GuixSD looks very interesting, excited to try it out
<lfam>ACTION Can't work on the stack clash updates right now, but maybe later today
<waynedpj>lfam: PS: is there a way i can check if a pull was done? because if i did it unintentionally i will restart the entire installation to avoid compiling everything
<lfam>waynedpj: I think you'd remember doing it, because it takes quite a long time
<lfam>At least 15 minutes on recent x86_64 hardware
<efraim>cve-2017-1000366 hits all of our linux glibc packages, not sure about hurd's
<lfam>efraim: This is perhaps the first time I've wished we were on the distros list
<efraim>i'm working on the glibc one first
<waynedpj>lfam: only thing i remember seeing is "substitute: updating list of substitutes from ''", is that a pull? BTW i am on i686
<waynedpj>lfam: just ran "guix system --dry-run init" and while many packages were for downloading, about the same number are for building
<efraim>it looks to me like some of the glibc packages can share their patchsets and shorten their definitions
***robmyers_ is now known as robmyers
<efraim>i'm not sure about libffi
<efraim>we aren't SElinux enabled, right?
<boskovits>I am having a hard time to get a working system from the images on the downloads page
<boskovits>Currently i am tring the vm image, but guix pull is not working
<boskovits>Tries to download linux-libre 4.4.47, and fails.
<boskovits>efraim: It seems, that by default selinux is no enabled
<efraim>'366 is glibc, '370 is the kernel, '369 is exim, '376 is libffi but needs selinux
<efraim>'371 is also the kernel
<efraim>'365 ditto
<efraim>'367 and '368 is sudo and already patched
<efraim>finally almost done building guile@2.2.2 on aarch64 on core-updates
<bavier>hello boskovits
<boskovits>I would like to know, if anyone else is experiencing problems with linux-libre 4.4.47 failing to download.
<quiliro>cy dao xññb ocq dhgpo cboyanncbi ncidy,ñcidyzeñotyhl
<quiliro>it has been 6 hours since start of lightweight-desktop started
<efraim>here's my glibc patch for CVE-2017-1000366 having a hard time getting it to actually build glibc
<efraim>Sneek_ later tell lfam I could use some help finishing the glibc patch huuttps://
<efraim>sneek_: botsnack
<civodul>ouch, /me looks up the CVE
<rekado>efraim: we have selinux, but we don’t build any of the core packages with it.
<civodul> is interesting
<lfam>efraim: How's it going?
<sneek>lfam, you have 1 message.
<sneek>lfam, efraim says: I could use some help finishing the glibc patch huuttps://
<quiliro>is it necesary to guix pull before using guix system init?
<mekeor>quiliro: no, AFAIK, it's not "neccessary"
<mekeor>quiliro: "guix pull" just pulls the latest version of guix.
<quiliro>mekeor: thank you
<quiliro>why is it taking so much time to install GuixSD?
<mekeor>sneek: later tell civodul some time ago, i submitted a patch for ghc-x11 which upgrades it to version 1.8. at you said that you have applied this patch but i can't see neither in the source nor in the git-logs. if you apply that patch (for ghc-x11), afterwards this patch ( for upgrading xmonad from
<mekeor>0.12 to 0.13 should work.
<mekeor>sneek: later tell civodul ... 0.12 to 0.13 should work.
<sneek>Will do.
<mekeor>ugh, i should probably write an e-mail for this... i will do so soon.
<mekeor>quiliro: i guess it has to compile many things
<quiliro>6 hours and i suspended and started again
<civodul>lfam: i *think* GuixSD is immune to the LD_LIBRARY_PATH one, FWIW
<sneek>Welcome back civodul, you have 2 messages.
<sneek>civodul, mekeor says: some time ago, i submitted a patch for ghc-x11 which upgrades it to version 1.8. at you said that you have applied this patch but i can't see neither in the source nor in the git-logs. if you apply that patch (for ghc-x11), afterwards this patch ( for upgrading xmonad from
<sneek>civodul, mekeor says: ... 0.12 to 0.13 should work.
<civodul>lfam: because of the way is_trusted_path works in glibc
<rekado>mekeor: I remember trying the xmonad upgrade, but I could not build it.
<quiliro>is there a guix tutorial? (not manual)
<rekado>quiliro: the manual is the tutorial
<rekado>mekeor: our haskell packages are a little outdated, so they really should be updated to the latest version of the haskell platform.
<rekado>quiliro: is there something you miss from the manual?
<civodul>mekeor: looking at i think i canceled the ghc-x11 upgrade when i noticed the xmonad upgrade didn't work
<civodul>mekeor: we need your input on this :-)
<mekeor>civodul: you first have to apply ghc-x11.patch, then xmonad.patch. that will work.
<mekeor>civodul: yes, i want to work on packaging haskell packages from latest haskell-platform; including ghc@8...
<civodul>mekeor: i did apply both in this order, to no avail; could you double-check?
<quiliro>rekado: i find the part of installing GuixSD very is step by step and helps understand by doing. I don't see something similar on the rest
<quiliro>i am not saying the manual is fact it is very good
<quiliro>not perfect but very good
<mekeor>civodul: what does "to no avail" mean?
<quiliro>i suggested adding how to connect to unencrypted wireless
<quiliro>but besides that, i like it a lot
<civodul>mekeor: it didn't work:
<quiliro>my major problem is installation time
<quiliro>not documentation
<civodul>mekeor: that was more than a month ago, so i forgot the details
<quiliro>so i am still trying to make a hydra mirror...but i see that will be of no use because not all packages have subtitutes
<quiliro>perhaps a repository of sources is possible?
<rekado>quiliro: in section “6.1.4 Preparing for Installation” there’s an example for how to connect to *encrypted* wireless networks; for unencrypted networks you would have to check “man wpa_supplicant”.
<quiliro>i have not received answer for my reports on the mailing list (help)
<quiliro>wpa_supplicant is of no use on wireless without password
<mekeor>civodul: the error message in the mail you wrote doesn't make sense to me. it states "At least the following dependencies are missing: directory >=1.2.3" but i did add package "ghc-directory" to the dependencies of xmonad.
<civodul>mekeor: i won't argue about the error message :-)
<civodul>i just applied the patches, built, and that's it
<quiliro>what would be very nice would be a .scm file for working with emacs in order to contribute to Guix
<civodul>mekeor: if you have patches rebased on current master that work, i'll happily apply them
<quiliro>or a tutorial to become a contributor
<rain1>is there a guide to set up hydra?
<rekado>quiliro: oh, you’re right about wpa_supplicant. My bad!
<rekado>rain1: I don’t think so. But we have an example configuration for Cuirass (in guix-maintenance.git)
<quiliro>not a suggestion or manual about contributing but a tutorial
<quiliro>cuirass for nginx mirror?
<janneke>ACTION -> zZzzz
<rekado>quiliro: the manual has a dedicated section on how to contribute (section 7).
<rekado>quiliro: no, cuirass would be used to build a set of packages continuously from git.
<quiliro>rekado: but a tutorial would be better for contributing
<quiliro>rekado: so cuirass is what i need then, is there a manual of how to set up a source server for guixsd repo?
<quiliro>there is a broken link in
<quiliro>"See Getting Started in"
<quiliro>404 - Page Not Found
<mekeor>quiliro: why not fix the link in the git-repository and then send a patch to the mailing-list? ;)
<mekeor>quiliro: what would be the difference of a "tutorial" in contrast to the "how to contribute" section of the manual?