<lfam>When I get packages that use Makefiles without autotools, it's always a huge PITA. And so I go to the different distros and see every distro hacking their own shitty version of ./configure because upstream didn't want to do it right... sigh
<davexunit>whereas the autotools now only rely on POSIX things.
<mark_weaver>Jookia: here's the thing: one of Guix's goals is that a program that works today will continue to work tomorrow, because the set of software it uses is also fixed.
<mark_weaver>i.e. a python script is rigged to use a particular python version and build.
<mark_weaver>and when you update your system, you get another python script that is now rigged to talk to the new python version.
<mark_weaver>now, if your script stops working because of some change in python, that doesn't break the old version of your script.
<Jookia>I understand that- I just feel that it's kind of a sad thing that even when I do specify the dependencies using a guix environment I still need to patch tons of shebangs and somehow get git to ignore them
<mark_weaver>now tell me the problem with having a single command that automatically converts your script into a package that is then automatically put into your profile, and updated when you do "guix package -u", etc.
<Jookia>mark_weaver: Hundreds of versions whenever I change a file
<Jookia>I don't see the harm in having a environment feature that creates /usr/bin when you've specified the dependencies - this would allow me to use other's code with obscure build systems while having a fixed amount of dependencies
<davexunit>paroneayea: is there a gtk.py file in the pygtk package?
<Jookia>Unless that's not what environments are meant for?
<mark_weaver>Jookia: I already explained that if we had /usr/bin/env, then we'd end up with a lot of stuff that inadvertently uses it.
<Jookia>mark_weaver: Why can't we have it as an explicit flag for environments?
<mark_weaver>and also, since that's a system-wide path, only root can decide what it does, or what environment it will have.
<davexunit>Jookia: it *might* be harmless in the case of 'guix environment --container', as an optional thing, but I'm not sure.
<paroneayea>davexunit: I don't know... "apt-get install python-pygtk" or whatever it was always brought me both the pygtk and the gtk modules...
<davexunit>paroneayea: could you search the store directory?
<mark_weaver>environments are good for typing things on a command line
<Jookia>Shebangs can be rewritten at runtime using binfmt_misc - what I'm saying is I'm aware of the issues, /usr/bin/env is fundamentally broken, but it's a lot easier to set up a development environment with my dependencies specified and a flag saying 'very-bad-env' for development rather than spending a day patching code across multiple repositories
<mark_weaver>but when you want programs to work reliably both today and in the future, having these programs find everything they need in an environment that changes a lot over time is a serious problem.
<Jookia>This is true, but guix environment files are easier to write in a few minutes than a day of patching
<davexunit>Jookia: in guix containers, you could 'ln -s path/to/coreutils/bin/env /usr/bin/env'
<mark_weaver>Jookia: here's what would happen: people who opt into this /usr/bin/env thing would start contributing packages that they tested in their environment, but they wouldn't work for other people who either disabled /usr/bin/env or had a different set of packages in their environment.
<Jookia>davexunit: Interesting- I'll have to try that
<mark_weaver>paroneayea: I have the same problem connecting to gnupg.org with IceCat. it works with Epiphany.
<paroneayea>mark_weaver: ah, I didn't know epiphany was an option!
<mark_weaver>I don't think it's a cert issue, I think it's because Mozilla's NSS (network security services) library has aggressively disabled some crypto algorithms that are considered not very security.
<mark_weaver>Jookia: I think what we really need to do is start making signed commits
<Jookia>mark_weaver: That'd be cool- but I mean stuff like fetch-git for Guix packages, instead of using git:// URLs it'd be nice if it supported ssh since while a lot of servers don't support http://example.tld/blah.git they support email@example.com/blah.git
<Jookia>mark_weaver: i actually have a list of the repos that don't support git over http, not sure whate exactly to do for their case
<mark_weaver>Jookia: fetch-git can't support ssh URLs because ssh'ing to any server requires that you have a private key that's authorized to ssh into that server.
<mark_weaver>if it's because of the performance problems, those should be addressed in the next few weeks.
<Jookia>oh no, it's more of weird philosophy about sustainability- if hydra exploded could i rebuild my system through tor?
<mark_weaver>if it's because you're worried about Hydra being compromised and serving malicious substitutes, then maybe the answer is to provide an option to use Hydra only for "fixed-output derivations".
<calher>CompanionCube: now i remember why i dont use enlightenment -- it crashes all the time
<Jookia>mark_weaver: ie if i wanted to use a system from 1 year ago, would hydra still hold the git checkout
<mark_weaver>those are derivations where the cryptographic hash of the result is stored is known ahead of time and stored in the Guix source code. that's the case for all 'origin' derivations, for example.
<mark_weaver>hydra's storage is about to go up by a factor of about 5, so its substitutes will persist for longer.
<mark_weaver>it's a good point that hydra won't keep substitutes forever, but on the other hand, we've often found that upstream tarball distribution sites have gone away or moved, or deleted their old versions, so that's no silver bullet either.
<mark_weaver>but if you want a decentralized, resilient, long-term storage of all source code, then you need to convince a lot of people to contribute to the maintenance of such a system.
<Jookia>my goal is more 'building by myself with tor' and i don't know how i feel about have hydra in the mix
<Jookia>I have a question: git-proxy requires a program/binary/script to run. Should this be written in Bash or Guile? If in either, is there a way to point to a file in the Guix repo for it to use rather than a derivation?
<mark_weaver>pecg: but putting all that aside, there's a snag with supporting GuixSD on the C201. Getting GRUB to run on it will be non-trivial work, I think.
<mark_weaver>currently, GuixSD assumes GRUB. at the very least, we need a way to make a boot menu with many choices, to allow booting into older generations of the system.
<mark_weaver>this is very important for GuixSD, so that you can update things like glibc and the kernel fearlessly, and still be able to boot into an older generation if the latest one is broken.
<_`_>Think arm will be a lost cause in open hw for a while. Only openpower/openrisc look promising.
<Jookia>open hardware is going to take a while to get
<mark_weaver>GRUB has been ported to u-boot, so it should in theory work on the Novena, which uses u-boot. Jookia tells me that it doesn't work, but for now I'm going to guess that it was either a mistake in his configuration or else a bug that might not be too hard to fix.
<Jookia>i'm not going to take super duper expensive freedom stuff seriously
<mark_weaver>of course, we have the board designs, so in theory I could get a PCB made and buy all the chips and go to a local hacker space to solder all the surface mount stuff on, but that is *totally* not my skill set.
<pecg>mark_weaver: I will be lost in that section too
<mark_weaver>don't get me wrong, I think that hardware like TALOS is very important. I think it's worth those who can afford it to make compromises to buy it.
<mordocai>Hey everyone! So i'm on my desktop now and I made a rather minimal debian install and am trying to setup as much as possible on top of that with guix.(talking on erc on guix emacs) One error I ran into though is when compiling stumpwm with sbcl(sbcl installed through guix) it is looking for /usr/lib64/sbcl/sbcl.core instead of $HOME/.guix-profile/lib/sbcl/sbcl.core. Any ideas on how to fix?
<mordocai>I'm guessing there is some environment variable to set, but idk.
<mark_weaver>Jookia: do something similar to what is done in the (git-package) procedure in guix/git-download.scm
<mark_weaver>and add the corresponding keyword argument to the 'git-fetch' procedure in the same file, analogous to the (git (git-package)) there
<mark_weaver>so make a (netcat-package) procedure, and add (netcat (netcat-package)) to the argument list here, and add #:netcat-command (string-append #+netcat "/bin/netcat") to the call to 'git-fetch' in there.
<mark_weaver>and then, in the 'git-fetch' in guix/build/git.scm, add another keyword argument (netcat-command "netcat")
<mordocai>Alright so I want to edit gnu/packages/lisp.scm, update the sbcl version, test it and submit a patch. What's the best way to go about this? Do I just edit .config/guix/latest/gnu/packages/lisp.scm directly or ... ?
<iyzsong>mordocai: clone the guix git repository, and see 'Contributing' section in the manual.
<iyzsong>if it still broken, show 'make -n emacs/guix-autoloads.el' :o
<mordocai>Nah, sorry. Forgot to report back but running mark_weaver 's commands worked. Building sbcl 1.3.1 failed and i'm now trying to get 1.2.8 to build to check it (instead of using substitute) but since I've already downloaded the substitute it won't build it.
<jamesaxl>Jookia: init is the parent of all processes on the system, it is executed by the kernel and is responsible for starting all other processes;it is the parent of all processes whose natural parents have died and it is responsible for reaping those when they die.Processes managed by init are known as jobs, and can be further split into two types; services are supervised and respawned if they should terminate unexpectedly, and tasks are
<mark_weaver>having said all this, we should probably add pt_BR to %default-locale-definitions anyway.
<mark_weaver>pizzaiolo: that's a good question, I don't know. I know that we have Esperanto translations for the messages in Guix, but I'm not sure off hand what the name of the Esperanto locale should be. civodul would know.
<NiAsterisk>so if I will be there for next years fosdem, I could make some. this is an very vague statement as much can happen in one year, especially if we could resettle to iceland when situation here becomes more difficult, etc.
<NiAsterisk>directory "bin" of lispf4 now contains lispf4 and SYSATOMS. should I create directory bin/lispf4 to solve potential future colision with something which might require a file named SYSATOMS?
<NiAsterisk>and is this even doable? fwi remember /bin had either symlink or binaries, but not directories.
<civodul>NiAsterisk: in general bin/ should contain only executables, and no sub-directories
<NiAsterisk>civodul: yes. so if colision happen, it will be solved at that time / or it is up to persons deciding what they want. if I can figure out that SYSATOMS can be in a different place, I will write an patch or make it happen in a different way.
<civodul>yes, collisions should either not happen or be something left to the user
<janneke>the manual #Binary-Installation shows how i can upgrade my binary installation: make guix-binary.x86_64-linux.tar.xz, surely that's not how you all do it, via the tarball? When i attempt ./configure --localstatedir=/var --with-store-dir=/gnu/store, it wants to install stuff in /usr/local; that's probably also not what you all do?
<mark_weaver>from just a few minutes, and basically a go-ahead from a core maintainer to submit patches for the "eo" locale to glibc
<mark_weaver>janneke: if you're going to contribute (yay :) then better to build guix from git checkout, and never use guix pull :)
<mark_weaver>and then you can either run guix directly from the git checkout by prefixing commands with "./pre-inst-env guix ..." or else make ~/.config/guix/latest a symlink to the git checkout after its built, in which case it will be used automatically for users with that symlink.
<mark_weaver>in my case, I made both ~mhw/.config/guix/latest and ~root/.config/guix/latest symlinks to my git checkout
<mark_weaver>janneke: if you started a "guix pull", you can just Ctrl-C it
<janneke>mark_weaver: ah yes, that's what i was looking for
<mark_weaver>janneke: see the "Building from Git" section of the Guix manual, but I'll also add that it's important to pass --localstatedir=/var to configure
<mark_weaver>(to match the localstatedir of your initial binary install)
<mark_weaver>we should probably be more clear about that in the manual
<mark_weaver>janneke: and more generally see the "Contribution" chapter
<mark_weaver>ah, it seems that the priorities are only used to sort jobs within each jobset, not between jobsets.
<mark_weaver>but the master and security-updates jobsets each have 100 scheduling shares, so you'd think that would lead them each being allocated about half the slots. but instead *every* slot has been allocated to security-updates, starving master completely :-*
<mordocai>I want to send a mail to guix-devel, i have a large amount of output from a command that isn't working for me. Should I just include that in the mail or to people prefer pastebins for email too now?
<mordocai>Alright, i'm in `guix environment guix` on my debian + guix box so I made this patch to lisp.scm http://lpaste.net/151811. I then ran make and did ./pre-inst-env guix build sbcl. I got this output: http://lpaste.net/151810. To verify, I stashed my lisp.scm changes and was able to build sbcl 1.2.8(current guix master sbcl). Quite frankly I have no idea what the error means and could use help figuring it out.
<mordocai>Well I guess technically I know what it means, just not what is causing it
<mordocai>ACTION is using debian testing + guix pretty much solely because he has a few non-free stuff he still "needs"
<mark_weaver>jjmarin: so, the wireless card is physically replacable with an atheros card, but there's a problem: the BIOS in thinkpad machines generally refuse to use any card that isn't in their short list of approved cards.
<NiAsterisk>grep the source luke! is something I learned to do more.. but I'm still taking notes to maybe get beginnerns not go through some basic mistakes/questions I made which wasted time so far :)
<jjmarin>Does anybody know if gnome 3 is ready to be used in guixsd ? I see many packages, but I read that it is not ready yet ? (I every try to execute gnome-shell)
<lfam>NiAsterisk: It would be nice have a "My first package" guide
<lfam>Something more hands on than what's in the manual now.
<mark_weaver>jjmarin: I did run gnome-shell successfully once, but there were some problems, notably that none of the configuration settings could be changed. in my case, that was a show-stopper, because I couldn't make caps-lock into a control. I'm *useless* on a keyboard unless caps-lock is control.