<paroneayea>how do I tell which package is keeping around another package? <paroneayea>lfam: I'm wondering what's keeping an old package in /gnu/store/ <lfam>Like, you want to get rid of it because you think it's blocking you from installing the right versoin? <paroneayea>my real frustration is that ctypes can't import a module that's clearly in my $LIBRARY_PATH <lfam>If so, then it's definitely not doing that ;) <davexunit>paroneayea: if you have the store item path you can use 'guix gc --referrers', I think <lfam>I can never keep -R, --references, and --referrers straight <lfam>Perhaps I could flesh out the explanations in the manual <paroneayea>I wonder how I get that environment variable to propagate in guixsd... <lfam>To propagate into a build chroot? You'll have to set it in the package definition IIUC <paroneayea>guixsd seems to know what environment variables I need and I'm not really sure how it does that <lfam>Check out ~/.guix-profile/etc/profile <davexunit>paroneayea: setting LD_LIBRARY_PATH is not a great idea <paroneayea>davexunit: but the ctypes library loading doesn't work without it :< <paroneayea>libX11 = ctypes.CDLL("libX11.so") # Import XFree <davexunit>you should substitute "libX11.so" with "/gnu/store/../lib/libx11.so" <davexunit>we do this for guile libraries that use the ffi <davexunit>(when the configure script doesn't auto-detect the full path or provide a flag to do so manually) <davexunit>this is one of these times where the autotools really shine <lfam>Working with Guix has given me a different perspective on autotools. <davexunit>where things like python/other dynamic language libraries never even think about these sorts of things. <paroneayea>I still wish autotools weren't written in m4 expanded shell, but yeah <lfam>So many people complain about autotools, but they really don't know how good it is. <paroneayea>I do understand a lot of the rationale behind many things now <davexunit>the problem with guile autotools is that it would rely on guile to be on the system building it. <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. <davexunit>paroneayea: I think it would be OK, but I think many would see this differently. <davexunit>autotools would become less portable as a result <paroneayea>the gnu standards doc says as long as the interface is preserved, it's ok <paroneayea>davexunit: it would work anywhere that has guile, right? <davexunit>yeah, would be interesting to bring up on gnu-prog-discuss or something and see the flamewar. <paroneayea>the development of guiletools wouldn't have to kill autotools <lfam>Well, they are both GNU projects. <paroneayea>davexunit: the first rule of gnu-prog-discuss is we don't talk about gnu-prog-discuss ;) <davexunit>but now, consider the circular dependency that would be created <lfam>Perhaps if you appeal to that, it will cool the flames a few degrees. <paroneayea>the second rule of gnu-prog-discuss is to "mark all as read" whenever the thread exceeds 20 posts <calher>XFCE looks like junk. I'm going to use ratpoison. <lfam>paroneayea: That's a good rule of thumb in general <davexunit>calher: you should apply the adwaita theme or something. <paroneayea>but first thing's first, I need my password manager to work again :P <paroneayea>. o O (this has turned into a much bigger task than I expected) <paroneayea>he seems to kind to like to do his own thing at his own pace <lfam>Will Guix be well represented at LibrePlanet? <CompanionCube>it's less ugly than XFCE and doesn't require you to have mousephobia <lfam>I live on the East coast and it would be nice to meet some of you! <davexunit>lfam: paroneayea and I will be giving a talk about it. <davexunit>and mark_weaver will be in attendance, too, I think. <Jookia>ACTION suffers from acute mousephobia :( <paroneayea>I'm already feeling how much presence can have an impact post-FOSDEM <CompanionCube>ACTION is currently compiling Enlightenment in the background <CompanionCube>paroneayea, I will say that the default theme can be divisive as to liking or hating it :p <CompanionCube>one of the releases also has the rare distinction of being on the same development timescale as Duke Nukem Forever <pizzaiolo>anyone tried using numix icons? I'm having a few problems with theming <calher>davexunit: What about an aoeu build system? <calher>CompanionCube: The ugliness is due to the inconsistency between GTK2, GTK3, window manager, and god-knows-what-else. <CompanionCube>but I have to admit it looks nice when you have a matching GTK theme <CompanionCube>the icons are Haiku-inspired and they add a splash of colour to the grey scheme <Jookia>you can pry my gradient blue clearlooks theme out of my cold dead hands <Jookia>does it have clearlooks? everything after clearlooks is downhill <CompanionCube>to give you an idea of E's theming: I have seen a theme that made the window borders into fancy christmassy pixelart <calher>CompanionCube: I made an interesting new prompt: PS1="\\u@\\h $(date +%H | sed 's/^0//')h$(date +%M | sed 's/0.//') ->" <Jookia>Lisp is the first language in eons that's given me consistent parenthesis errors <Jookia>I'm not on a system that I can set up an editor yet :( <lfam>Not even something like vim? <lfam>There is a paredit vim plugin <calher>Crap, I have to reboot to use i3. <calher>because the display manager doesn't see it if i just install it as my user <davexunit>if you set up an .xsession file then you could use it <calher>ACTION cat "exec i3-wm" >~/.xsession <mark_weaver>calher: it needs to have a shebang as the first line, and needs to have the executable flag set (using chmod +x) <calher>mark_weaver: shebangs dont seem to work on guixsd <calher>or the shebang has to be very strange <lfam>On GuixSD, couldn't you use #!/run/current-system/bin/sh ? <mark_weaver>calher: umm, it needs to be an absolute path to a program, like on any other system <davexunit>GuixSD has /bin/sh as it is required by POSIX <davexunit>but that's it, no /bin/bash, /usr/bin/bsh, /usr/bin/env <mark_weaver>calher: for bash, use #!/run/current-system/profile/bin/bash <mark_weaver>that's a slippery slope to losing the advantages of guix <Jookia>it'd make sense to have a fake env in a guix environment once you've specified your dependencies <lfam>sneek should have an auto-spiel it spills whenever somebody mentions "/usr/bin/env" <davexunit>/usr/bin/env shebangs have the illusion of portability <mark_weaver>I'd rather have a way to easily convert a script into a guix package, with the usual shebang rewriting that our build system does. <Jookia>/usr/bin/env python # which python version? <davexunit>because most people haven't used a system that doesn't conform to the outdated FHS <davexunit>mark_weaver: yes, I think that's the way to go. <Jookia>I'm not too sure about that, it means packaging complex projects for development (Libreboot) wouldn't be fun <davexunit>a build system *should not* make assumptions like this <davexunit>Autoconf, for example, provides mechanisms to lookup the absolute paths of binaries at configure time. <mark_weaver>Jookia: Libreboot's build system is basically designed to work on a small number of FHS systems. <CompanionCube>also, maybe it'd be a good idea to a good solution for building packages directly from VCS repositories <lfam>CompanionCube: We already have that <mark_weaver>if it used autoconf, then we'd be able to package it relatively easily. <Jookia>It's moving to autotools but also is pulling in non-autotools stuff <Jookia>Since it's multiple pieces of software <davexunit>check out scripts/guix.in in the guix git repo <Jookia>I'm pretty disappointed with the idea I'd have to rebuild my scripts every time I update my system <davexunit>it uses autoconf to replace @GUILE@ with the absolute path to the guile binary at configure time <mark_weaver>but iirc, Libreboot would like to switch to using autoconf, as part of its goal to become a GNU project. <davexunit>once libreboot uses autoconf there will no longer be an issue. <Jookia>Maybe I'm the odd one out since I don't package things when I develop things <davexunit>you don't need to package things in order to avoid baked-in assumptions about the host system. <Jookia>Well I don't know what I'd do if I wanted to run scripts without autoconf <davexunit>I think there's room for a tool that could attempt to do shebang replacement on the fly <Jookia>binfmt_misc is a kernel thing that allows you to parse and edit shebangs <Jookia>and decide what to load them with <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>I should also point out that if GuixSD had /usr/bin/env, then inevitably we'd end up with lots of Guix packages that inadvertently used it, without anyone noticing. <Jookia>It certainly is a build system problem, but it's also a user experience problem <mark_weaver>and then things that work today might break because you change your profile or your PATH or whatever <Jookia>mark_weaver: Isn't this what environments are for <mark_weaver>I'm pointing out real problems with having /usr/bin/env <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>Every time I edited it it'd need to be converted to a package so I can run it <mark_weaver>so if you don't want that, just put #!/run/current-system/profile/bin/whatever <Jookia>This doesn't work with other people's code if they're wrongly using /usr/bin despite Guix's ability to avoid its problems <davexunit>I'm afraid those scripts just aren't portable. <mark_weaver>if it's someone else's script, then it's probably not something you're going to be editing a lot, so you can just import it as a package as I described. <mark_weaver>if it's your script, you can put that kind of shebang on top <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 <paroneayea>davexunit: /gnu/store/yxn3djg3ga577s0m5r96canpvm4sa352-python2-pygtk-2.24.0/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py <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 <paroneayea>/home/cwebber/.guix-profile/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py <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>because use of /usr/bin/env is quite widespread, and we need to notice that it's being used by making attempts to use it break. <Jookia>If there's a way to get a dangerous /usr/bin/env in a container that's all I want- I don't plan on packaging anything, I've just been bit pretty hard by this kind of stuff on NixOS <Jookia>On another topic, --no-grub considered harmful? <calher>CompanionCube: exec enlightenment does not work <paroneayea>~/.guix-profile/lib/python2.7/site-packages/gtk-2.0/ <paroneayea>and the gtk and gio and etc modules are nested *inside* of there. <paroneayea>it looks like the gtk subdirectory is added to the pythonpath <paroneayea>now granted, pygtk is considered a pretty outdated way of doing things anyway, gobject introspection seems preferred anyhow, but <calher>I gotta get DejaVu on here. FreeMono sucks. <davexunit>okay, well perhaps we need to add a special native search path for this package then <davexunit>wooo some of the guile/guix talks are up *with sound* now <paroneayea>Assword database error: Decryption error: Decryption failed <paroneayea>yeah I can't decrypt *any* of my gpg encrypted files <calher>I can't view images in Terminology. <paroneayea>gpg: decrypt_message failed: Unknown system error <calher>Jookia: Terminology is made to view images. <mark_weaver>I seem to recall that they dropped support for some old formats recently <paroneayea>is gpg trying to tell me it's time for a new key? ;P <davexunit>paroneayea: do you use gpg 2 or 1.4 on debian? <paroneayea>davexunit: I have no idea, I guess I need to check now! <calher>Hm... no IceCat icon in the Enlightenment panel when I add it. <mark_weaver>calher: that's true, IceCat doesn't install a .desktop file <CompanionCube>Enlightenment calls the ones you make 'personal application launchers' <paroneayea>An error occurred during a connection to gnupg.org. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap) <paroneayea>SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt <paroneayea>GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt <paroneayea>I keep going levels deeper and deeper on this yak <paroneayea>davexunit: I did that and it's still complaining <paroneayea>so, I confirmed it works fine with gnupg-1 anwyay <davexunit>I configured gpg2 to explicitly use a particular pinentry <paroneayea>so I guess gpg dropped whatever cipher I'm using, or something <paroneayea>okay, it looks like I need to figure out how pinentry works, and that's probably the root of it <paroneayea>I'm going to do that, but I'm taking a break first <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. <calher>yeah, CompanionCube, tyls don't work in Screen and tycat doesn't do video as advertised. <mark_weaver>and actually, Firefox ESR 38 (and IceCat 38) bundles an older version of NSS. but we don't use that bundled version, we use the newest release of NSS. <paroneayea>anyway, I think I'm close to having assword working, which means I'm close to being able to actually use guixsd as my main distro....... <mark_weaver>paroneayea: okay, sleep well, and thanks for your perserverance! <mark_weaver>I'm considering packaging the older NSS and building IceCat against it.. <mark_weaver>although I guess that gnupg should update the software on their website as well <Jookia>would it be appropriate to allow ssh access for git downloads <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 git@example.tld/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>so, iiuc, the only way that could work is if we distributed the private key with Guix and somehow convinced upstream git repos to honor that not-very-private key. <Jookia>this is a hard situation since you can get git to funnel git:// through http proxies but it'd require a rebuild <mark_weaver>Jookia: users can use substitutes from hydra.gnu.org to fetch those sources. <Jookia>mark_weaver: so i can fetch a git checkout over hydra? <mark_weaver>use "guix build -S <package>" for any package whose source comes from git, and you'll see <Jookia>I'm trying not to rely too much on Hydra <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. <Jookia>i shall have to think more about this :) <mark_weaver>I guess I don't know a solution that meets your requirements. <mark_weaver>we want to move to gnunet for distribution of binary substitutes. <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>Oh I understand- thinking it through it great. :) <mark_weaver>if the upstream git repo doesn't provide access in a way that's friendly to tor, then you need someone else to host a mirror that is friendly to tor. <mark_weaver>and hydra does that, but I guess you don't want it to be hydra, or maybe you don't want it to be any single site. <mark_weaver>I think maybe the gnunet distributed hash table is what you're looking for? <Jookia>I'm fine with it being a single site, ideally upstream. Maybe <mark_weaver>then you need to convince upstream sites to add tor-friendly access options. <Jookia>To put it in context there's a grand total of six packages that rely on git:// links that don't support Tor <Jookia>So it might be easy enough to just ask them <mark_weaver>btw, are you sure that the 'git' protocol can't be used through tor? <Jookia>It can but it'd require editing the fetch-git builder <Jookia>Git needs a proxy program passed to its configuration <Jookia>I think netcat + a derivation for the proxy program + passing that to Git would be all that's needed <Jookia>I also have had to patch the subversion fetcher to get HTTP SVN links to work, though I think svn:// is broken over Tor <mark_weaver>Jookia: could this be done via kernel netfilter rules? <Jookia>You can actually wrap programs using 'torsocks' but the problem is that they don't know they're being proxied and might do weird things that compromise anonymity <mark_weaver>fixed-output derivations, like the ones used to download package sources over http, ftp, git, svn, etc, have network access. obviously, they couldn't work without it. <Jookia>Yeah, but let's say you're on my system that blocks all output unless it's LAN, Tor or OpenVPN <Jookia>the correct way to get things to use Tor for the most part is specifying proxy settings (it's not too bad)- one thing I often run in to is programs that leak DNS requests <Jookia>So while you *could* proxy things using nettables or torsocks it can lead to weird behaviour- like, proxying ssh will still tell github your unix username <mark_weaver>well, I'm certainly open to the idea of adding proxy functionality to our git-fetch and svn-fetch methods <Jookia>Would it require rebuilding the world if I did that? <Jookia>I see! I'll work on getting HTTP proxy support in to svn and git then <mark_weaver>the hashes of the outputs of those derivations are embedded in the Guix source code. <mark_weaver>Jookia: here's the thing though: we need to minimize the number of new packages that are added to the set of dependencies for git-fetch <mark_weaver>because all of the packages in that set cannot use git-fetch. <Jookia>0 new dependencies for svn-fetch, netcat would probably be the dependency for git-fetch <Jookia>It looks like it has 0 dependencies actually <mark_weaver>btw, the way I became aware of this problem was once when I tried to switch a core package to use git-fetch instead of url-fetch. <mark_weaver>and then I found that it led it a circular dependency <mark_weaver>git-fetch requires git, which requires glibc, which requires git-fetch <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? <Jookia>Since it requires netcat I suppose not <mark_weaver>Jookia: actually, that's an interesting point. if we used guile, then we might not even need netcat at all. <mark_weaver>we download http and ftp with pure guile code, after all. <Jookia>From what I understand you may not even need an external script- but to think more, the proxy command is "nc -x $http_proxy_host:$http_proxy_port www.example.com 80" <mark_weaver>Jookia: help me understand this. this is to access git:// URLs? <mark_weaver>sorry, I need to go afk for a while... will be back in a while... <calher>tor browser bundle does not start <chewieQC>Hi, is there an iso of GuixSD? I can't make the usb (?) download on the official website work in virtualbox <calher>chewieQC: virtualbox is nonfree. use QEMU. <Jookia>chewieQC: i think you need to convert the iso to a HDD image for virtualbox <chewieQC>jookia: I tried: dd if=guixsd-usb-install-0.9.0.x86_64-linux of=guix.iso <Jookia>chewieQC: I think you need to use vboximageconvert <Jookia>chewieQC: you want the iso to turn in to a vdi disk image <paroneayea>it was fine once I logged out and logged in again <calher>Jookia: Why are you supporting non-free software? <paroneayea>Jookia: you weren't talking about mediagoblin's community were you <Jookia>paroneayea: oh, no- just today i managed to register on goblinrefuge and upload a bad freestyle rap song <chewieQC>calher: I wasn't actually aware VB was non-free <Jookia>I might need to bug report those Tor captchas <chewieQC>Wikipedia says it's mostly licenced under gplv2 <Jookia>chewieQC: it's a gray area, all the source code is licensed under GPLv2 but it requires a nonfree compiler for BIOS, and there's no option to remove the BIOS setting <Jookia>chewieQC: I did manage to get a version running with only EFI so it was actually free but eventually got bored and didn't finish patching it <calher>Jookia: I wouldn't be able to build it on any of my machines. <Jookia>calher: If you patched it you could <mark_weaver>Jookia, chewieQC: to be clear, our installer is *not* an ISO. <chewieQC>mark_weaver: But isn't an ISO a disk image, technically..? <_`_>yeah but not all disk images are ISOs <chewieQC>Or do you mean the downloadable image is not an installer like a more traditional distribution's iso? <_`_>an image of your superblock is a disk image. <chewieQC>For the curious, the command that worked for me to convert to a VirtualBox-compatible image is: VBoxManage convertdd guixsd-usb-install-0.9.0.x86_64-linux guixsd.vdi --format VDI <chewieQC>calher: Do you know if gnome boxes has the same problem as VB? <_`_>gnome boxes just uses qemu+kvm as a hypervisor doesn't it? <pecg>Hello. What would be required in order to write a service for php-fpm <pecg>So besides writing a dmd service for php, what else will be required to have php 7.0 under guixsd? <mark_weaver>it's not my area of expertise, and no one else seems to be answering <paroneayea>and yay! let's see if I can last a whole week using guixsd only! <pecg>mark_weaver: Fine, I will subscribed to the mailing list and ask the question. <pecg>I'm just wondering if that question had been asked before, and if someone is already working on it <mark_weaver>I don't think it's been asked recently, and I'm not aware of anyone else working on it <pecg>Well maybe I can contribute in that matter <mark_weaver>although there has certainly been thought on how best to support web applications <pecg>Not that I'm a wizard in scheme <mark_weaver>I haven't been paying close attention to those discussions, though. <pecg>I ask because that's maybe the only thing that is not implemented yet, and I need (I write programs in php) <mark_weaver>no need to be a scheme wizard. most guix contributors don't know very much scheme, and came in knowing almost none. <pecg>Well, that certainly is encouraging <pecg>Among other things, I just realized that GNU dmd is now named GNU Shepherd <mark_weaver>pecg: we have an nginx service, but no apache service yet, fwiw. <pecg>mark_weaver: That's great because I use nginx <mark_weaver>I'm not sure how much real-world use it has gotten yet. <pecg>I can't remember the last time I used apache <pecg>mark_weaver: Do you know details about the boot process of POSIX system, like GNU or BSD <mark_weaver>well, GNU, anyway. it's been a while since I looked closely at BSD <pecg>I'm reading some criticism to systemd and some people say it's one of weak points is that it uses PID 1 <pecg>Which seems to me something senseless <pecg>Jookia: Same thing I thought <Jookia>mark_weaver: i think they argue that systemd has too much surface area for crashing PID 1 <pecg>if PID 1 crashes, all the system does. <mark_weaver>is this just a theoretical argument, or is it a problem in practice? <mark_weaver>yes, it doesn't matter what program it is. if PID 1 exits, the kernel panics. <pecg>ACTION smiles when someone clarifies linux as a kernel, which is the only thing it is <mark_weaver>PID 1 has a special role: it becomes the parent of orphaned processes. <mark_weaver>yeah, it's too bad that I feel the need to clarify, but there's widespread confusion about it. <pecg>mark_weaver: That I knew, but isn't there a way to avoid kernel panic when PID 1 crashes? <pecg>mark_weaver: 2016 and still is <pecg>mark_weaver: Don't worry I know quite enough about operating systems (not that I know a lot) to know the difference <pecg>ACTION used to have a banner in his laptop saying: Linux is just a kernel, that gave him lots of endless debates with 'experts' <mark_weaver>if PID 1 exits, how would another process take its place? <mark_weaver>and if there's no PID 1, what becomes the parent of orphaned processes? <pecg>mark_weaver: I was thinking about that exactly <pecg>mark_weaver: I wonder how minix does that, since it is announced as fault tolerant <pecg>Maybe it does nothing about that problem <mark_weaver>I guess the thinking is that since the system's reliability depends on Linux (the kernel) being reliable, it should be no harder to write a PID 1 program that's reliable. <mark_weaver>one thing that could be done is to move some of the complex jobs to subprocesses <mark_weaver>PID 1 might have some other special privileges too, I don't remember off-hand. <pecg>mark_weaver: And that's one of the strongest technical features of the GNU Hurd project <pecg>it distributes complexity <pecg>Exactly. If networking fails, it doesn't crash the kernel. So simple kernel management, simple init makes a more reliable system <pecg>mark_weaver: Ever since I knew about the existence of people working on such an advance piece of software I've been in love with the sole idea <pecg>I know Tannenbaum's Minix succesfully implemented microkernels, but the Hurd seems to have higher goals <pecg>believe it or not the Hurd means a lot to me, is the main reason I'm towards learning operating system programming <pecg>kernel programming, to be more specific <mark_weaver>are you aware of our work on porting GNU Guix to the Hurd? <pecg>mark_weaver: No, not at all, mainly because I lack of the knowledge for low level programming <Jookia>Microkernels forever! I'd like to see a POSIX userspace on L4 someday <pecg>Jookia: I feel the same way <pecg>I'm thinking even writing a new microkernel, just to see how it is implemented <pecg>mark_weaver: Are you Magnolis? <pecg>mark_weaver: I think I know from some other channel <pecg>mark_weaver: Yes, I think it is from there <pecg>I'm very excited about Guix <mark_weaver>I've been using Libreboot laptops exclusively for a couple of years now, and I'm about to transition my server to a Libreboot machine as well. <pecg>I will buy the ASUS C201 as soon as the libreboot port is ready <pecg>I have to divide my time in too many activities. <pecg>I whish I could help in hardware too, but I cannot take the time to do so <mark_weaver>that's an interesting device, the C201. I've been on the fence about whether to put much effort into it, given the GPU and wireless that require non-free code to use. <pecg>mark_weaver: Those are the usual problems in today <mark_weaver>and also the very limited storage is a problem for my purposes, and for use for Guix development. <mark_weaver>In the ARM world, I'm more interested in the Novena, although it's too bad that one can no longer easily build complete laptops using it. <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. <_`_>TALOS/openpower's making it a reality hopefully. <mark_weaver>_`_: TALOS looks awesome, but unfortunately the high price that tpearson is asking is far beyond my means. <_`_>I'm saving up for it now <_`_>worth having a system with modern hw that I can probably really trust. <Jookia>ACTION grumbles about not being able to verify hardware <mark_weaver>it's not that I don't think it's worth it. it's just that I've optimized my life for maximum freedom and free time, and so I literally don't have the money. <pecg>mark_weaver: The Novena is amazing, but expensive, although I wonder why is not easy build a complete laptop any longer <mark_weaver>pecg: the battery boards are no longer being produced. <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. <pecg>I clicked on that, but thought it was a scam or something <mark_weaver>tpearson is the guy who ported coreboot and libreboot to several ASUS boards. <pecg>I think raptorengineering is not tor friendly <pecg>page loading seems endless <_`_>I think it's running on an underpowered vps <pecg>mark_weaver: What mailing list would be more suitable to write about the question of php 7.0 and GNU Shepherd <pecg>ACTION the guix (package manager) logo really got me <pecg>See you in some hours, have to sleep right now <calher>The manual still says "deco status dmd". <Jookia>calher: Ooh, sounds like a patch you could do <mark_weaver>I discovered the source of the problem with IceCat connecting to gnupg.org <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>disabling several protocols to defend against the Logjam attack, except that we fixed those problems long ago in openssl and nss. <mark_weaver>mordocai: stumpwm will need to be patched to look for sbcl.core in the right place <mark_weaver>well, or maybe there's an environment variable, dunno. <mark_weaver>mordocai: are you making a Guix package for stumpwm, or compiling it manually? <Jookia>calher: Find the 'deco status dmd' thing then edit it <mordocai>mark_weaver: I'd like to make a guix package but for now I just want it manual <mark_weaver>why don't you search the stumpwm sources for occurrences of sbcl.core and see what it's doing <mark_weaver>mordocai: if you compile something manually on Debian, the build system of that package will probably try to use stuff from Debian, like libraries, sbcl, etc. <mark_weaver>in general, you need to ensure that when building software, either everything is used from Debian, or everything is used from Guix. mixing is bad. <mordocai>mark_weaver: Not finding sbcl.core in the source btw. It finds sbcl in guix (i see it in the makefile) but the sbcl.core thing might be something else. <mordocai>So far everything that I know of related is installed through guix <mordocai>Doesn't mean I didn't miss something though <mark_weaver>it might actually be easier to write a Guix package for it <mark_weaver>because then its build system won't be able to see Debian, and won't be confused by it <Jookia>Are there any examples of Guix building shell script derivations? <mark_weaver>I see that alezost is/was also a stumpwm user. he might also have some clues <mordocai>mark_weaver: Ah, this is a sbcl problem not a stump problem <mordocai>When I run sbcl by itself I get the same error <mark_weaver>there are mentions of SBCL_PREFIX and SBCL_HOME environment variables. maybe they need to be set? <mordocai>mark_weaver: Yep, found that info independently. setting SBCL_HOME seems to make sbcl run. That should probably be one of those things printed after you install sbcl. <mark_weaver>of course, it's not good that sbcl doesn't work "out of the box". we should ask taylan about it <mordocai>That's good anyway, I want to update the sbcl package to 1.3.1 too <mordocai>Going to learn how to do that after I get basic stuff working <mark_weaver>mordocai: it would be good to email bug-guix@gnu.org about the sbcl problem <iyzsong>there is no 'cc', set the environment 'CC=gcc' work in most case. <Jookia>How does guile handle $1, $2, $3, etc? <mark_weaver>Jookia: (command-line) returns the list of arguments passed to a script <Jookia>ACTION is trying to write some of his first guile <mark_weaver>Jookia: see 'make-ld-wrapper' in gnu/packages/base.scm and gnu/packages/ld-wrapper.in for an example of how to make a package that imports a guile script in the guix source tree. <Jookia>i'm currently using gexp->script maybe <Jookia>It'll need a lot of help though since I haven't done this before and have no idea how to articulate what I'm trying to do <mark_weaver>although if the code is big it might be a bit cumbersome <mordocai>I wish there was something like debian's build-essential... oh well. What the hell is 'as' and where do i get it? <mordocai>Well found what it is, not found a guix package to provide it yet though <Jookia>I'm getting this warning "possibly unbound variable `ungexp'" which sounds like a big deal <Jookia>i'll write a post to the mailing list about it <mark_weaver>mordocai: install 'gcc-toolchain' instead of 'gcc', 'binutils' and 'glibc'. <mark_weaver>gcc-toolchain includes an important wrapper for the linker called 'ld-wrapper' <mark_weaver>and ensures that you have the entire toolchain from guix <mordocai>mark_weaver: So I have both gcc and gcc-toolchain installed. <mark_weaver>oh, I see. there's no 'main' defined in terminal_glue.c, is there? <mordocai>Yeah, I guess not. I started trying to figure out the error because common lisp is having trouble compiling it however it does. <mordocai>Not sure where the error output goes there, guess I should find it <mark_weaver>when you run "gcc foo.c", it tries to make a standalone executable, which needs to have a 'main'. <mark_weaver>if you want to just compile it to a .o file, pass the -c option to gcc <mordocai>Yeah, as far as your first statement I realized that after you pointed it out <mark_weaver>I would remove the 'gcc' package, btw. gcc is already included in gcc-toolchain <Jookia>It might be a better effort to ask people to enable HTTPS Git repos <mark_weaver>Jookia: I might be able to help with this, but right now I'm busy with other things. <Jookia>mark_weaver: Thanks- I'll take another shot in a bit <mordocai>At least i'm learning a lot having to do all this... sigh. Where is the stupid compiler error ASDF? *grumble* <Jookia>mordocai: haha, learning is 'fun' <mark_weaver>this is the kind of stuff we have to deal with all the time in guix <mordocai>Yeah, i'm asking #lisp if there's a standard way people handle this kind of think but so far I think the answer is no <mordocai>heh, the sad thing is it turns out if they'd just set it to the string gcc then the path would've been used <Jookia>mark_weaver: big problem: importing the module containing netcat/socat to git-fetch means all modules in that file can't use git-fetch <calher>Jookia: It's fixed in the VCS version. I guess my manual is out of date. <calher>Jookia: Not sure how to change it. <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>you may want to make ~/.config/guix/latest a symlink to the git checkout, so you can use normal 'guix' instead of 'pre-inst-env guix' when testing. <mordocai>Would guix environment guix not including libbz2 count as an error? <iyzsong>yes, but I have it under 'guix environment guix' (in C_INCLUDE_PATH, etc.). <mordocai>I have to guix package -i bzip2 before it worked for me <iyzsong>that shouldn't happend, can you check GUIX_ENVIRONMENT and C_INCLUDE_PATH to be sure? <iyzsong>after run 'guix environment guix', the new shell have 'GUIX_ENVIRONMENT' set to 't'. <mordocai>Ah, I bet I know the problem there. I have C_INCLUDE_PATH set in my bashrc. <iyzsong>yeah, bashrc is not the right place for that kind of environment variables. <iyzsong>~/.bash_profile, but if they are for guix, you can use 'source ~/.guix-profile/etc/profile'. <mark_weaver>mordocai: never set environment variables in .bashrc, because that will break "guix environment". only set them in .bash_profile <mordocai>I've had trouble with things not sourcing bash_profile before, hence why I typically don't use it. <mordocai>That was a long time ago though so my memory could be fuzzy, taking your advice and i'll see if I run into any problems <mark_weaver>it's true that when logging into X sessions, one typically has to arrange for .bash_profile to be loaded via .xsession or similar <mark_weaver>but that's needed anyway, in order for programs launched from the desktop environment to have the environment settings. <iyzsong>yes, some login manager won't use it, in that case I set my terminal emulator to use login shell. <mark_weaver>iiuc, on GuixSD we arrange to load .bash_profile from the display manager <mordocai>Haven't tried it inside guix environment guix, but outside it does <iyzsong>also, you can try `guix environment --pure guix', which give a environment total unreleated to the host distro. <mordocai>iyzsong: guix environment --pure guix didn't help, same error as pasted above. emacs seems to run fine. <mark_weaver>mordocai: you should probably re-run ./bootstrap and ./configure --localstatedir=/var within that pure environment. <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. <iyzsong>unless you modify the arguments of a given package (eg: name, inputs, phases, etc.), it won't be rebuild. <mordocai>Yeah, it seems weird to me that there isn't a flag to force a rebuild <iyzsong>ideally, rebuild a package without any arguments changed won't change the package at all. <mordocai>But my local machine already has a substitute copy <iyzsong>it even might be bit-identical.. I don't know the '--check' option help or not. <iyzsong>ACTION don't know if '--check' will force a rebuild. <calher>(replace-string "don't" "doesn't") <mordocai>So far I haven't been able to get the pre-existing sbcl to build so I can see if it is an issue with my setup <calher>Oh, is someone trying to port StumpWM? Good-good-good. <mordocai>calher: Well, I have stumpwm running locally. I haven't tried to make a package yet <calher>I don't use any particular WM. I use whatever is most available. <xd1le>mordocai: is stumpwm a "manual" tiling wm? if you know what that means. <xd1le>searching the internet does not seem to answer this <mordocai>xd1le: Yep, similar to emacs is the short description <calher>i3, MATE and Plasma 5 seemed nice. <mordocai>So how can I get guix to build the sbcl 1.2.8 package that I already have a substitute downloaded for? This is slighly aggravating so far <iyzsong>mordocai: yeah, I guess 'guix build sbcl --check' should do what you want. <calher>I don't think I want to use StumpWM; it uses Common Lisp instead of Guile. <iyzsong>so our sbcl's patch-unix-tool-paths phase failed to look some utf16 files.. seem tough. <mordocai>iyzsong: Ah, i was doing guix build --check sbcl and it was complaining about --check <iyzsong>mordocai: no such option? you can use the git version by '../guix/pre-inst-env guix ...' <mordocai>iyzsong: I get "unsupported build mode" when I try it your way <iyzsong>mordocai: the daemon is old, you can stop the current, and run the git guix-daemon. <xd1le>calher: yeah, i wonder if there's a tiling wm that uses guile <iyzsong>indeed guile-wm can be a good tiling wm, but I haven't learn the skill to hack it :o <mordocai>Alright it looks like sbcl is building now, i'm going to go to bed and check it in the morning. G'night and thanks for all the help everyone! <xd1le>iyzsong: oh thank you! didn't know about that <iyzsong>jamesaxl: what's is 'pcks'? I think there is no guix deb package. <jamesaxl>iyzsong: what kind of pkgs does guixSD have? <iyzsong>yes, scheme files for source, and simple archive (nar) for binaries. <iyzsong>well, when using systemd in the past, I have to do it :( <Jookia>jamesaxl: i don't know what that means <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 <jamesaxl>alezost: understood, does Guix can be installed in Vbox? <alezost>jamesaxl: virtual box? Why not, someone did it AFAIK <jamesaxl>alezost: I should try it then :) I am fan of Gnu system, i used before parabola :) <Steap|DevConfCZ>yeah well, improvising a lightning talk about Guix seems a bit too hard for me right now ***raulet_ is now known as raulet
<Steap|DevConfCZ>but this is quite fast, I don't have time to rehearse + I'm not used to talk to people :D <fps>is that video cut off? <fps>after a couple minutes? <fps>oh, it's a lightning talk :) <fps>just had it run in the background <Jookia>night #guix , remember that you can buffer overflow a human by asking them "what's 1+1+1+1+1+1+1+1" ***I is now known as Guest8842
<pizzaiolo>I'm trying to change my locale to pt_BR, but when I do guix system reconfigure it complains that the system locale lacks a definition <boegel>fps: yeah, it was a 5-minute lightning talk, and I was quite strict on the timing <boegel>fps: rekado did a great job though <pizzaiolo>I should like to add a pt_BR locale in the future <alezost>pizzaiolo: I think we can just add it to that list. Would you like to send a patch for that? <pizzaiolo>alezost: but isn't a prior translation necessary? <alezost>pizzaiolo: for sending a patch? no :-) <iyzsong>pizzaiolo: I guess custom the 'locale-definitions' field with '(list (locale-definition (name "pt_BR") ...' should do it. <pizzaiolo>iyzsong: it is by sending an email to the mailing list? <iyzsong>for 1 commit, I used to do: git format-patch -1 && git send-email 0001-*.patch <pizzaiolo>but it's not the official language of any country <alezost>pizzaiolo: I have no idea, Ludovic may know (as he is an esperanto man) but he's not here right now. <alezost>pizzaiolo: but you can try both (or maybe "eo_US") and see if any works :-) <alezost>ACTION doesn't see any "eo…" file in /gnu/store/…-glibc-2.22/share/i18n/locales/ <pizzaiolo>alezost: can I just use <smth>? will the patch merger notice it as a variable? <alezost>pizzaiolo: I think for now you can just raise a question on guix-devel list about adding new locales to %default-locale-definitions. And there you can ask about esperanto locale <alezost>pizzaiolo: no problem, I think pt_BR should definitely be in the default list, not sure about eo <pizzaiolo>alezost: other distros support eo locale, I should check how they handle it <janneke>pizzaiolo: nice graph...warnings for what? <mark_weaver>no need to add it to %default-locale-definitions, just add a 'locale-definitions' field to your OS config that includes it <mark_weaver>better yet, we should simply arrange to automatically add it to the system's locale definitions <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. <mark_weaver>based on looking in /run/current-system/profile/share/locale and ~/.guix-profile/share/locale <janneke>i'm wondering if we could have a /usr/bin/env <janneke>atm, guix rewrites /usr/bin/env <..> and that is fragile when the script is a symlink <janneke>... rewrites #! /usr/bin/env in scripts in the source tree, before building <mark_weaver>I guess we need to add documentation about it, because I'm tired of arguing it every other day :) <janneke>ACTION is reading the manual while trying to build some first packages <mark_weaver>I have to go afk now, no time to explain again. but I'll write up an answer later. <NiAsterisk>Hi! I already opened an bug for this, but is anyone else having issues with the latest master from guix pull? <NiAsterisk>also didn't fetch emails since yesterday, so no idea if it's an duplicate, sorry <NiAsterisk>okay, seems to load now. is reporting bugs in case of such errors too early? in my view trying 5 times and getting broken results was okay to report. <janneke>now /me is confused, it seems that patch-shebangs already skips symlinks <petter>i'm trying to reboot but it's not going so well. I've tried "/run/booted-system/profile/sbin/reboot", but i get error: "/var/run/shepherd/socket: No such file or directory" <NiAsterisk>the mailinglists have some high amount of emails in 18-24 hours... 180 new emails <janneke>petter: i've seen that too, possibly after entering a new enviroment <NiAsterisk>sadly the windows laptop at friends home did not want my rockbox player, so I couldn't print tor and some other logos I wanted to try. maybe next time I can make some more <janneke>pizzaiolo seems to be outside of the snippet you posted <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. <pizzaiolo>janneke: should I reboot after reconfiguring? so that the new locale will come into effect <drtan>Hi! Is Guix a rolling distribution? <drtan>Guix SD to be more accurate. :) <NiAsterisk>but not in the sense of archlinux for example, where I remember 8 years ago stuff breaking the system when you upgraded. <mark_weaver>it's a rolling distro in the sense of archlinux, but if something breaks you can always roll-back. <mark_weaver>updates are not done in place, but rather by adding new directories and switching a symlink, so it's always safe, even if you pull the plug in the middle of an upgrade. <mark_weaver>all the generations of the system are in the GRUB menu. GRUB itself is the only thing we have to be careful with, because there's only one of those. <drtan>What needs to be done with Guix so it becomes production ready? Apart from testing? <mark_weaver>but even if GRUB became broken, you could still boot the system using GRUB from an external USB stick, e.g. from our USB installer. <mark_weaver>drtan: well, there's a lot to do. it would be easier to answer that question if I knew what you were going to use it for. <mark_weaver>on the server side, there are still many missing services. <mark_weaver>we don't yet support hibernation, LVM, btrfs. none of these are difficult, they just need to be done. <NiAsterisk>I could imagine a grphical (as in similar to debian or others), more accessible installer in the future for clients. <mark_weaver>updating services requires a reboot last I checked. our init system is lacking many features. <xd1le>mark_weaver: didn't dmd exist before guix? <xd1le>or did you guys create dmd too? <mark_weaver>yes. when I saw "our own init system", it's because it was basically orphaned and we took over maintenance of it and breathed new life into it. <xd1le>sorry, should say shepherd, if dtan is searching for it rn.. <mark_weaver>drtan: right, dmd was recently renamed to shepherd. that's our init system <mark_weaver>several of which didn't have CVEs assigned at the time, but I saw the commits in the upstream repo and thought they looked security-relevant, so I cherry-picked them :) <mark_weaver>he worked on it a long time before anyone else got involved <pizzaiolo>there's little history on it on the guix website <pizzaiolo>maybe that's why the wikipedia entry is so short <mark_weaver>and last I checked he has still made over half the commits <mark_weaver>he's made 4644 commits total, and I come in second place at 976 <mark_weaver>I have no idea how he gets so much work done on Guix along with two kids and a job. he's amazing :) <mark_weaver>it's the only future I want to live in, that's for sure :) <mark_weaver>and it still doesn't give you any assurance that your binaries haven't been compromised. <mark_weaver>any of us can get hacked, especially those of us who run modern web browsers. <drtan>There will be real breakthrough if we found the way web services to be verified against the code. <drtan>You have AGPL service yet you don't know if the server is running the code it claims pit provide you source under AGPL. <mark_weaver>I don't see any way, even in principle, to gain confidence what code is running on a server that is remote to you and out of your control. <mark_weaver>I think the solution is to architect things in such a way so that you don't need to trust servers that are out of your control. <mark_weaver>similarly to how the use of encryption and anonymity services like tor or gnunet allow us to use a network that's hostile to us. <drtan>Do you think it might be possible to do all our computing by ourselves? <drtan>The problem of server appears when you want to delegate some of your computing. <NiAsterisk>the ultimate solution is death to the servers, at least most of them. in my opinion, in what I learned through the last years. <mark_weaver>drtan: good question. some things are hard to decentralize. web search is an example of that. <drtan>NiAsterisk: When I see people choosing "cloud" is almost always out of lazyness. <mark_weaver>I would say that delivering email, where the participants are not always connected to the network, is another example, but it seems that Pond is a good solution to that. <pizzaiolo>mark_weaver: yacy already decentralizes web search <NiAsterisk>distributed (or real distributed) services work when it covers large areas and no lobbyism goes against it. <NiAsterisk>ACTION now got lispf4 to run, but needs to dive into documentation to see what's needed to make it accept (EXIT) not only on random. <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 <pizzaiolo>civodul: what's the esperanto locale? "eo" or "eo_EO"? <civodul>pizzaiolo: i think it's still not in upstream libc, but some people call it "eo_XX" <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>janneke: never use the binary tarball to upgrade an existing installation. <janneke>so how do i include local patches/commits that i want to test into that "guix pull" mechanism? <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 <M-yrns>mark_weaver: So do you 'make install' after every git pull? <mark_weaver>M-yrns: no, I've never run "make install" for any package in GuixSD <mark_weaver>when 'guix' is run, it looks in $HOME/.config/guix/latest and uses the copy of guix there <mark_weaver>so even though I'm running an old 'guix' command, it doesn't matter because the first thing it does is look for that symlink which points to the newest version of my git checkout. <mark_weaver>so I just "git pull" and "make" and then future "guix" commands will use the updated version. <NiAsterisk>is "lispf4-0.0-1-174d876" an okay form of $name-'no-version-upstream-exists'-$guixversion-'take 7 from the commit hash' for an git checkout? <NiAsterisk>I read the thread about this, but it was rather long <mark_weaver>NiAsterisk: there's a section in our manual about this now too. <mark_weaver>GNU Distribution > Packaging Guidelines > Version Numbers <mark_weaver>but it doesn't say what to do for packages that have never made a release. <mark_weaver>using 0.0 in place of the release version seems reasonable to me, though. <efraim>from the mailing list I thought we were assuming 0.0.0 was better for an unreleased version 0 <mark_weaver>efraim: sure, that's probably best to be on the safe side :) <NiAsterisk>I doubt lispf4 port from fortran in 1980s to C in the 2000s will ever see a release number. <fhmgufs>Could someone give me an example where to versions of a package exist, one with gtk+-3 and one with gtk+-2, please? <fhmgufs>Ah, I'm silly, I used this as a input myself. Thanks! <janneke>could it be that (uri "file:///home/janneke/foo-0.1.tar.gz") is broken in git master? <janneke>just did the `latest' symlink trick and now have a hard time getting my package to build...still learning anything <mark_weaver>bah, I set the priority of the new icecat jobs to 30 in master, and yet the queue-runner allocated *every* slot to security-updates jobs with priority 10. <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 :-* <efraim>could the priorities be like linux nice or MX records? lower is actually a higher priority <mark_weaver>at this point I've successfully used high priorities within a single jobset and they work as I expect. <mark_weaver>but scheduling between jobsets appears to be a mess. <mark_weaver>for now, I lowered the scheduling shares of security-updates down to 50, and will see how things evolve as the existing builds finish. <mark_weaver>and maybe later I'll look at digging in the queue-runner code and fixing it. <fhmgufs>iyzsong: Good idea, updated the patch. <pizzaiolo>what's the assembler's name? I tried guix package -i as but it didn't work <fhmgufs>... is the package. But it should be there. <mark_weaver>andschwa: install 'gcc-toolchain'. it has everything you need. <petter>hm, my computer just rebooted on its own <civodul>janneke, mark_weaver: file:// URIs are supposedly supported by url-fetch; see (guix download) <civodul>pizzaiolo: gnome-shell is available, it seems that not much is missing <CompanionCube>does anyone know if installing GuixSD to a btrfs partition / subvolume is working? <civodul>CompanionCube: it's not supported yet, there have been discussions/reports on the mailing list <lfam>mark_weaver: Thanks for mentioning the tiff update earlier. I was getting ready to dig in and figure out if your update addressed all those CVEs. <Jookia>A little off topic but did something happen to twitter <Steap|Brno>Jookia: how would people from this channel know? <lfam>Besides being a sad example of how we give our social lives to a proprietary system created by a private company? ;) <Jookia>I don't know, I assume a lot of us are on GNU Social or Identica which is where a ton of new users just blasted in <calher>Asks a channel of freetards about Twitter ... gets no response <calher>I don't have another word for "adherent of free software ideology". <Jookia>'free software people' is what I usually go by, not offensive words <Jookia>I do and I'd suppose a lot of other people would given the similarity to 'retard' <calher>The kids at Woodstock called themselves by whatever names society gave them. The term served its function and they didn't care if it was traditionally considered offensive. <calher>Jookia: There's nothing wrong with being a retard. <Jookia>I feel like if you have to explain to someone why you shouldn't be offended by these words you've already lost this argument <calher>Jookia: I call myself a freetard. My fellow freetard, Zerock, also calls himself a freetard. <_`_>You're pretty deconstructive, huh. <NiAsterisk>because you decide it's not offensive does not mean it does apply to every one or a majority. <Jookia>The fundamental problem is you shouldn't really have to justify using a word <calher>Oh wait, I remember another word: Stallmanite. <lfam>It's clear there is some disagreement on this subject. How about we keep the discussion on topic? There are other channels for general discussion. <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 <lfam>Do you know what string that is? <lfam>The one with the null byte? <mordocai>I looked for a boot-9.scm and didn't find one <lfam>I imagine it's part of Guile <lfam>If the only difference is your patch, I would look at the hash string in an editor that shows "hidden" characters <lfam>And the version string as well <lfam>You may have somehow introduced a null character into the hash string <mordocai>How would I show hidden chars with emacs? <lfam>I don't know ;) In vim you can do :set list <mordocai>Soo... my system uses utf8 and I notice the error mentioned utf16. Are these files supposed to be utf16? The error is in utils.scm with-atomic-file-replacement apparently. <lfam>I think we should stick to utf8. <mordocai>Well I definitely should be writing utf8. <lfam>If we can't figure it out here, then I'd say it's worth an email :) <lfam>Especially since it's blocking your contribution <mordocai>Yeah, so what is the standard practice in emails on guix-devel? Would I provide a link to my paste or put the text directly in the email? <mordocai>Obviously both will "work" just unsure what is standard practice <lfam>I'm not sure there is a standard. If the output is very long, perhaps a utf8 text attachment? <lfam>The problem with using a paste site is that eventually the email would become worthless as the external site garbage collected old pastes <lfam>Also, the paste site may mangle the encoding, which seems to be important here <jjmarin>Hi !. My computer has a intel Centrino Wireless-N 2230 (rev c4) wifi component, but guixsd doesn't detect. Any idea how to proceed ? <mordocai>Well hydra is being pretty hammered right now it appears. Having to build things myself :) <jjmarin>I've spend more than five hours for building icecat <jjmarin>guix package -i icecat didn't work and suggested to use --fallback option <mordocai>I believe that, I know from previous experience with gentoo that chromium/firefox(or dirivatives) are some of the longest to build things. <jjmarin>it seems fallback option compiles everything for that package <jjmarin>about my question, I've realised that iwconfig shows my wireless <lfam>jjmarin: It's possible that linux-libre doesn't include drivers for your wireless card if the drivers are non-free <mark_weaver>jjmarin: I recently updated the icecat package, and hydra is *almost* done building it. if you wait 30 minutes or so, hydra will probably have the substitute by then. <lfam>I mean, it's definite that linux-libre will not include non-free drivers. It's possible that your card requires them ;) <mark_weaver>jjmarin: as for your wireless, I guess that's one that requires a nonfree blob uploaded to it in order to work. GuixSD is a fully free distribution, so it doesn't include those blobs. <jjmarin>mark_weaver: thanks, I'm new to guix/guixsd and everything seems strange :-) <mark_weaver>the best way forward would be to acquire a wireless device that doesn't require a nonfree blob. <jjmarin>what happens with all the things that guix has downloaded for compiling icecat ? <lfam>They will be in /gnu/store. If they are not referenced by anything, they will eventually be garbage collected <jjmarin>I thought that intel wireless cards driver were free :/ <mark_weaver>lfam: jjmarin: they will only be garbage collected if you run "guix gc" <mark_weaver>jjmarin: no, the intel wiresless cards generally require nonfree blobs, I'm afraid. <lfam>My mistake, I thought that garbage collector did run periodically <mordocai>Yeah, I was quite sad that my laptop requires a non-free blob for the wireless. Is is the only non-free blob required (besides microcode/BIOS) AFAIK <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. <mark_weaver>on my thinkpads, the cards have been replaced with atheros cards, but I could only do that because I also replaced the BIOS with Libreboot. <jjmarin>that's disgusting. I want to change the wifi card for whatever I want :/ <mark_weaver>coreboot would be another option, but coreboot doesn't seem to support your laptop either. <mark_weaver>there's one other option: I've heard of people using hacked versions of the thinkpad BIOS to remove the anti-feature of refusing to use unapproved wireless cards. <jjmarin>NiAsterisk: thanks for the recomendation <NiAsterisk>could I use (copy-recursively) for just copying the entire "Documentation" dir to lets say share/doc/lispf4/ ? <lfam>NiAsterisk: I believe that's another option <lfam>There are some examples in the package tree <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. <mark_weaver>it's just a matter of working through the remaining issues. <lfam>It would be good to release 0.9.1 with working GNOME, as civodul suggested. <lfam>I think it would make the system a lot more accessible to new users <rekado>wow, so much activity on IRC and the mailing list. I don't think I'll ever be able to catch up. 
