<NiAsterisk>i am confused. okay. so I checked into a branch I had on an external disk with guix sources and it doesn't have problems building in guix environment. I know I sometimes can't access how to do things, temporarily, but this is bad :/ normaly it would go like: git clone $guix-src ; git checkout -b $branchto-workon ; do some changes ; and then the guix environment part, right?
<Jookia>I'm pretty proud of my router setup- fully encrypted running librecmc, with the modem bridged with the actual connection done with free software on the router
<Jookia>It'd be interesting to see if we could get Guix on a router
<pizzaiolo>Jookia: how's your guixSD install coming along?
<kristofer>mark_weaver: you nentioned that you symlink ~/.config/guix/latest a symlink to your local guix build.. does that happen automatically with a make install? and can you elaborate on what to do with root?
<mark_weaver>kristofer: I don't run "make install", and I recommend against it.
<mark_weaver>after you've built the local guix and make sure it works, just make ~USER/.config/guix/latest a symlink to the git checkout directory, and then 'guix', when run as USER, will use the copy in that source directory.
<rekado>mark_weaver: shotwell, guitarix, and gnucash were added by me. I'll check if a later version of webkit can be used.
<rekado>guitarix only added webkit as a dependency with the last release.
<rekado>sneek: later tell davexunit At FOSDEM I discussed with Manolis about our avr-gcc and he suggested we try building a second stage with the avr-libc. This should at least fix the problems with paths (finding things like crtm328p.o).
<mark_weaver>wingo: I don't feel strongly about it, but I would prefer that the pre-built .go files be packaged in a separate tarball. that would also solve the reproducibility problem for the main source tarball at least.
<suitsmeveryfine>pizzaiolo: you could also try to use the desktop config instead of bare-bones
<wingo>mark_weaver: ok, noted. i think i prefer them in the tarball because we want to give a good default experience, and we should make sure .go files are reproducible in any case. but we can iterate on this.
<wingo>mark_weaver: it's probably fine to use a deterministic syntax-session-id for prebuilt files, given that they will not be used at all once bootstrap is built. but maybe i misunderstand how session ids propagate.
<wingo>or we could use the version as the session id ;)
<mark_weaver>wingo: it has to be a different session id for each "guild compile" command
<Jookia>pizzaiolo: You could try doing an unencrypted install, but most likely you could get in contact with suitsmeveryfine and see how you can synchronize systems to rule out software error
<NiAsterisk>hi! which one of those would pass in a package definition? 1) (arguments `(#:make-flags '("-f Makefile.unx"))) 2) (arguments `(#:make-flags '("-f" "Makefile.unx"))) or 3) (arguments `(#:make-flags "-f Makefile.unx")) I am having trouble with (3) currently, which gives something like Odd number of arguments.
<taylan>NiAsterisk: "-f" "Makefile.unx" is the right way
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, rekado says: At FOSDEM I discussed with Manolis about our avr-gcc and he suggested we try building a second stage with the avr-libc. This should at least fix the problems with paths (finding things like crtm328p.o).
<efraim>second stage might be like the intermediate stage in bootstrapping
<NiAsterisk>:/ damn. doesn't "git clone https://domain.bla/bla.git" guix hash --recursive bla/ give the right hash? environment, what I put into the package definition AND another run afterwards with guix hash all differ ._.
<pizzaiolo>civodul: any ideas about mark_weaver's comment above? I'm having installation issues
<NiAsterisk>and in the environment running guix hash --recursive bla/ also produces something else.
<Dezponia>davexunit: I'm planning to build a server using that board to migrate my own stuff to. I run a few buildservers for GNU/Linux distros on my current hypervisor but would rather do so on the Libreboot-D16 with a FSF approved distro on the host (already run that on the current host but want more power and libereated firmware). Not sure if that setup is sufficent for your needs but cant hurt to offer :)
<davexunit>Dezponia: it would surely be sufficient as a worker in the build farm.
<Dezponia>davexunit: Then its still interesting at least. Planning to load it up with some pretty beefy specs so it should work fine :)
<suitsmeveryfine>pizzaiolo: you can find my working OS definition here: paste.lisp.org/+6KgK
<davexunit>we improved the way we compile the guile modules.
<davexunit>fhmgufs: if we didn't compile them, the first time you ran something like 'guix package -A foo' it would load every single package module and compile them.
<davexunit>any operation that wanted to scan the full package set would do this.
<fhmgufs>Ok, understood. I'm not so familiar with guile, yet.
<fhmgufs>And also not so familiar with how guix does things in detail.
<fhmgufs>To come back to my first question: I don't really know how to configure postfix or sth like that for 'git send-email' to use my mail provider.
<NiAsterisk>found that github has done an zip package of lispf4, I guess that's more appreciated? what else is needed to unzip this .zip other than the gnu packages unzip as module? I tried grep and found no .zip for sources
<jin>hi guixs, i am testing nautilus file manager and i've error when trying to connect via smb
<bavier>NiAsterisk: you're wanting to build a package from a zip archive?
<efraim>NiAsterisk: instead of master.zip, you can change the zip to .tar.gz
<NiAsterisk>it's not the issue anymore. now it's up to stuff failing to compile. but: can I? is it interchangeable?
<bavier>NiAsterisk: actually, in this case, a git checkout might be preferable, since we can specify a commit to checkout, rather than getting whatever is the current HEAD.
<bavier>but feel free to fix the rest of things before revisiting that
<NiAsterisk>it's not like this is ever getting worked on again.. or at least not very likely. it has been ported from the 80s version, and some stuff added and that's it. I had it using a git checkout before I discovered the zip
<bavier>by specifying a commit we can avoid the possibility of future breakage completely
<taylan>hoijui: below the title it says "As of version 0.9.0, the Guix System Distribution can be installed on an i686 or x86_64 machine. It uses the Linux-Libre kernel and the GNU dmd init system. Alternately, its package manager, GNU Guix, can be installed as an additional package manager on top of an installed Linux-based system."
<NiAsterisk>does gnu-build-system imply ./configure by default, as this package builds without a configure file on debian (it does not exist)
<wingo>mark_weaver: this machine has guix on nixos. it has GUIX_LOCPATH and LOCPATH set. it can't install locales any more though.
<mark_weaver>NiAsterisk: gnu-build-system does have a 'configure' phase that runs ./configure, but that phase can be removed or replaced. we tend to use gnu-build-system even for packages without a configure script.
<hoijui>taylan, yes exactly, that is how i found out, but that isa text that looks very unimportant by its formatting, while it is the most important text of hte page
<wingo>i'm not sure i have time to understand this again
<efraim>I'm loving the -M build option, even on my netbook
<taylan>hoijui: feel free to file a bug report by mailing firstname.lastname@example.org
<NiAsterisk>mark_weaver: I mean, there is an override for this in (arguments)? (related error in the build process: /gnu/store/l7px210li6zviymgvp3cps6n48x7fgpl-bash-4.3.42/bin/bash: ./configure: No such file or directory , there's no configure file
<mark_weaver>pizzaiolo: the kernel panic happens when the init process quits, and it can quit for many different reasons. in your case, it's quiting because /etc/static/localtime isn't there, or is a broken symlink.
<mark_weaver>and that's something we've not seen before. it's not about configs or kernel versions of locales.
<kristofer>git master has xf86-input-libinput (version "0.8.0") while the latest version is at 1.1.5.. am I using the wrong branch or something?
<mark_weaver>kristofer: we haven't updated our X11 packages in a while. lately, every time I update the X server, a bunch of drivers need to be patched to fix them to work with the newest server, and some other drivers are broken beyond my ability to repair them.
<mark_weaver>(and some other distros have simply dropped those unmaintained drivers)
<mark_weaver>suitsmeveryfine: my 'swap-devices' field pointed to a device that didn't exist, and recently there was a change that made that a fatal error leading to kernel panic, whereas before it was silently ignored.
<mark_weaver>in my case, it pointed to something in /dev/disk/... which had stopped working a while ago.
<mark_weaver>when running ssh like that on the client side, the client side shell will have already done shell expansions and quote interpretation. doing it again on the server side would probably be bad.
<paroneayea>hm, I see in my logs that it's implied that pulseaudio will be started itself...!
<mark_weaver>paroneayea: I don't know. I remember trying to figure out how that was supposed to work long ago, but never found out. I lost interest because my audio programs seem to just work anyway. maybe civodul knows.
<a_e>I would like to take out one of the inputs of a package only on arm. Does anyone remember a package where this is already done? I am getting lost in quotes and unquotes.
<suitsmeveryfine>but it can be mentioned in the guide that locales and stuff always can be changed later
<civodul>mark_weaver: BTW, what's the status of security-updates?
<suitsmeveryfine>petter: "If you're going to change locale you should check what is available and exactly how it is typed; close the editor or change virtual console (Ctrl-Alt-F#), and run the command "locale -a". This command doesn't work for me.
<petter>suitsmeveryfine: right, and as a wrote a few minutes ago i'll change this
<mark_weaver>petter, suitsmeveryfine, pizzaiolo: I just added the needed modules to the default set. after a "guix pull" you'll have them. but there's no harm in leaving them in your OS config for a while.
<suitsmeveryfine>yes of course, but it sounds a little bit as if though s/he was in control over the whole flock
<fhmgufs>What to do if a package wants to install its gir data into the gir directory in the store?
<mark_weaver>sneek: later tell fhmgufs: if a package wants to install its gir data into an existing store directory, you need to modify it to install the gir data in its own package output directory. see the grilo and libgee packages in gnome.scm for examples, but the fix might be somewhat different in your case.