IRC channel logs


back to list of logs

<paroneayea>how do I tell which package is keeping around another package?
<lfam>What do you mean?
<lfam>paroneayea ^
<paroneayea>lfam: I'm wondering what's keeping an old package in /gnu/store/
<paroneayea>I guess that doesn't matter
<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 found out what it was
<paroneayea>so, this is strange
<paroneayea>export LD_LIBRARY_PATH=$LIBRARY_PATH
<paroneayea>fixes it
<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
<davexunit>for anything beyond a quick hack
<paroneayea>davexunit: but the ctypes library loading doesn't work without it :<
<paroneayea>libxdo = ctypes.CDLL("")
<paroneayea>libX11 = ctypes.CDLL("") # Import XFree
<paroneayea>these lines don't work
<davexunit>paroneayea: the library needs patching then
<davexunit>you should substitute "" with "/gnu/store/../lib/"
<paroneayea>davexunit: ah
<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.
<davexunit>lfam: same.
<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 autotools needs a new interface.
<lfam>Guile autotools? ;)
<davexunit>most of the hate comes from the interface
<paroneayea>the interface seems fine, it's the plumbing...
<paroneayea>./configure && make is fine
<davexunit>sorry, the programming interface.
<paroneayea>trying to debug a config script though
<paroneayea>okay, that!
<davexunit>the user interface is great
<paroneayea>lfam: yeah guile autotools, I'd love it
<paroneayea>I'll never have time for it though
<davexunit>the problem with guile autotools is that it would rely on guile to be on the system building it.
<CompanionCube>I'd imagine any autotools problems
<paroneayea>meh :)
<CompanionCube>are that it's a giant blob of M4 and Bash
<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.
<paroneayea>I think guile being required is fine.
<paroneayea>make now has a guile option now right?
<paroneayea>if make can be compiled with guile
<paroneayea>autotools being built on guile seems fine
<paroneayea>embrace the future like a shining star
<davexunit>paroneayea: I think it would be OK, but I think many would see this differently.
<paroneayea>yeah I know I'd get pushback on this one
<paroneayea>davexunit: though!
<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.
<davexunit>paroneayea: yes
<paroneayea>the development of guiletools wouldn't have to kill autotools
<paroneayea>autotools can stick around as legacy :)
<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.
<davexunit>guile uses the autotools
<lfam>Ah, true
<davexunit>guile would depend on itself
<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.
<davexunit>but ratpoison is fun.
<paroneayea>I really want to port stumpwm to guix
<paroneayea>but first thing's first, I need my password manager to work again :P
<davexunit>we need an asdf build system
<davexunit>for common lisp
<paroneayea>. o O (this has turned into a much bigger task than I expected)
<davexunit>and then a quicklisp importer
<paroneayea>davexunit: yeah that would be nice
<davexunit>and then I can package dto's games
<paroneayea>yeah! :D
<davexunit>(ulterior motive)
<paroneayea>dto is so cool
<davexunit>he lives not far from me.
<davexunit>never met him irl though
<paroneayea>he seems to kind to like to do his own thing at his own pace
<CompanionCube>calher, what about Enlightenment
<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 :(
<lfam>Perhaps I will attend!
<paroneayea>lfam: libreplanet is a blast!
<paroneayea>and it'll be nice to have more guix presence
<paroneayea>I'm already feeling how much presence can have an impact post-FOSDEM
<CompanionCube>ACTION is currently compiling Enlightenment in the background
<paroneayea>oh man I should try enlightenment again
<CompanionCube>but not for guix
<CompanionCube>and technically it's EFL that's currently compiling
<davexunit>paroneayea: yeah?
<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
<paroneayea>CompanionCube: :D
<CompanionCube>let me find a recent screenshot
<pizzaiolo>anyone tried using numix icons? I'm having a few problems with theming
<CompanionCube>panel not shown
<CompanionCube>paroneayea, ^ opinion?
<calher>davexunit: What about an aoeu build system?
<davexunit>ACTION plays rimshot
<calher>CompanionCube: The ugliness is due to the inconsistency between GTK2, GTK3, window manager, and god-knows-what-else.
<calher>oh yeah, and icons
<CompanionCube>calher, icons aren't default
<CompanionCube>I should maybe say that
<CompanionCube>but I have to admit it looks nice when you have a matching GTK theme
<CompanionCube>ACTION does
<calher>It's hard to match this stuff.
<Jookia>GTK is my favourite toolkit
<CompanionCube>the icons are Haiku-inspired and they add a splash of colour to the grey scheme
<Jookia>clearlooks for life
<CompanionCube>but the default io
<CompanionCube>*icons are also OK
<Jookia>you can pry my gradient blue clearlooks theme out of my cold dead hands
<CompanionCube>what colour is clearlooks again?
<Jookia>white and blue
<calher>i enlightenment openbox i3-wm
<calher>clearlooks is glossy
<paroneayea>CompanionCube: will look in a sec
<Jookia>gloss is still in
<calher>Jookia: Flat is phat.
<calher>maybe i should just use exwm
<Jookia>i use i3
<CompanionCube>E is also extremely themeable
<Jookia>does it have clearlooks? everything after clearlooks is downhill
<paroneayea>CompanionCube: wait what
<paroneayea>what game is that???
<paroneayea>in your screenshot
<CompanionCube>it's a game
<paroneayea>that sounds like a delightful nightmare
<CompanionCube>written entirely in gawk
<CompanionCube>to give you an idea of E's theming: I have seen a theme that made the window borders into fancy christmassy pixelart
<CompanionCube>another blurred parts of the UI
<CompanionCube>(well, the background anyway)
<calher>CompanionCube: I made an interesting new prompt: PS1="\\u@\\h $(date +%H | sed 's/^0//')h$(date +%M | sed 's/0.//') ->"
<CompanionCube>ACTION uses zsh + oh-my-zsh and powerlevel9k
<Jookia>My prompt: [%n@%M %c]%#
<Jookia>Lisp is the first language in eons that's given me consistent parenthesis errors
<davexunit>Jookia: fix your editor.
<Jookia>davexunit: To do what?
<davexunit>to edit lisp
<davexunit>we all use this
<davexunit>or a similar thing if not using emacs
<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
<Jookia>vim, but on a live CD
<Jookia>that i often reboot
<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
<calher>Hm... exec i3 did not work
<mark_weaver>calher: it needs to have a shebang as the first line, and needs to have the executable flag set (using chmod +x)
<mark_weaver>i.e. it needs to be an executable script
<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 ?
<Jookia>calher: #!/bin/sh works fine
<lfam>Or alike
<calher>I'm used to /bin/bash
<mark_weaver>calher: umm, it needs to be an absolute path to a program, like on any other system
<mark_weaver>but yeah, we don't use the FHS
<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
<CompanionCube>it'd make sense to have env
<davexunit>it actually would not.
<davexunit>this comes up from time to time.
<calher>Could I just do #!bash
<mark_weaver>that's a slippery slope to losing the advantages of guix
<davexunit>calher: no.
<mark_weaver>calher: no
<Jookia>it'd make sense to have a fake env in a guix environment once you've specified your dependencies
<davexunit>maybe, yeah.
<davexunit>but I think such scripts are hacks.
<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.
<calher>Hm... #!/bin/sh\\nbash -e "i3"
<lfam>A shell-build-system
<davexunit>this would be on the fly
<Jookia>I'm not too sure about that, it means packaging complex projects for development (Libreboot) wouldn't be fun
<mark_weaver>guix package --install-script myscript
<Jookia>Or LibreCMC
<davexunit>Jookia: no.
<Jookia>... No?
<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
<CompanionCube>arch has -git and similar packages
<Jookia>It shouldn't but it does
<lfam>CompanionCube: We already have that
<mark_weaver>if it used autoconf, then we'd be able to package it relatively easily.
<davexunit>does libreboot use the autotools?
<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/ 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>it's basically a set of shell scripts
<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.
<davexunit>this is autoconf's bread and butter.
<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
<davexunit>thinking out loud here:
<davexunit>guix sh
<Jookia>That'd be good
<davexunit>I don't know what that is
<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
<davexunit>that is a build system problem.
<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
<calher>Jesus, xterm is glaring white.
<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
<mark_weaver>I don't understand what you mean
<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
<paroneayea>ACTION puzzled
<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.
<paroneayea>>>> import pygtk
<paroneayea>>>> import gtk
<paroneayea>Traceback (most recent call last):
<paroneayea> File "<stdin>", line 1, in <module>
<mark_weaver>if it's your script, you can put that kind of shebang on top
<paroneayea>ImportError: No module named gtk
<paroneayea>that's strnage, right?
<paroneayea>not just me
<paroneayea>I have python2-pygtk installed
<paroneayea>why would pygtk import, but not gtk?
<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 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>I'd like to think very carefully.
<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/
<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>also exists
<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
<Jookia>mark_weaver: This is true
<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.
<mark_weaver>or else Guix cannot achieve its goals
<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
<mark_weaver>sure, doing it a container is fine
<mark_weaver>*in a container
<Jookia>On another topic, --no-grub considered harmful?
<calher>CompanionCube: exec enlightenment does not work
<CompanionCube>wrong executable
<CompanionCube>you want enlightenment_start
<mark_weaver>I have to go afk for a while...
<Jookia>Have fun
<calher>Maybe I'll use Enlightenment.
<paroneayea>davexunit: I think I figured it out
<CompanionCube>calher, if you do
<CompanionCube>then I recommend giving the tiling module/add-on a go
<paroneayea>this isn't actually on the path
<paroneayea>and the gtk and gio and etc modules are nested *inside* of there.
<paroneayea>on other systems like debian
<paroneayea>it looks like the gtk subdirectory is added to the pythonpath
<paroneayea>er, gtk-2.0
<paroneayea>now granted, pygtk is considered a pretty outdated way of doing things anyway, gobject introspection seems preferred anyhow, but
<paroneayea>there it is
<calher>I gotta get DejaVu on here. FreeMono sucks.
<davexunit>paroneayea: ah!
<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
<Jookia>ooh, link?
<davexunit>some seem to still be messed up
<CompanionCube>calher, if you plan to use Enlightenment
<CompanionCube>I suggest you also try Terminology
<calher>but i use screen
<CompanionCube>ACTION is not aware of any broken-ness in that area
<paroneayea>davexunit: it looks like we might be able to fix it this way...
<paroneayea>I'll try
<CompanionCube>(also yes, that font sucks terribly)
<paroneayea>after spending all day on it
<paroneayea>Assword database error: Decryption error: Decryption failed
<paroneayea>hm :\\
<paroneayea>yeah I can't decrypt *any* of my gpg encrypted files
<davexunit>hmmm I wonder what's missing
<davexunit>maybe a strace session can help
<calher>I can't view images in Terminology.
<Jookia>its a terminal
<paroneayea>bash-4.3$ gpg2 --decrypt text.txt
<paroneayea>gpg: no valid OpenPGP data found.
<paroneayea>gpg: decrypt_message failed: Unknown system error
<paroneayea>okay yeah, whaaat
<davexunit>paroneayea: not using your gpg database?
<davexunit>gpg2 --list-keys
<calher>Jookia: Terminology is made to view images.
<paroneayea>it lists my pubring.gpg....
<calher>in ls
<mark_weaver>paroneayea: maybe try gnupg-1.4
<mark_weaver>I seem to recall that they dropped support for some old formats recently
<mark_weaver>gnupg-2.0 might also work
<mark_weaver>calher: install 'font-dejavu'
<mark_weaver>as for Terminology, I have no idea
<davexunit>ah yes, could be a gpg version mismatch
<paroneayea>is gpg trying to tell me it's time for a new key? ;P
<calher>calher: I got it now.
<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!
<CompanionCube>calher, hm
<Jookia>there's gpg 2.1, 2.0 and 1.4
<CompanionCube>I believe you needsomething like evas generic loaders
<CompanionCube>also try 'tyls'
<mark_weaver>paroneayea: see the bit about "three flavors" at
<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>calher, you can create your own though
<calher>IDK how to.
<CompanionCube>Enlightenment calls the ones you make 'personal application launchers'
<CompanionCube>look in the menus :)
<paroneayea>An error occurred during a connection to Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
<paroneayea>so, somehow that seems funny
<davexunit>paroneayea: missing certs?
<davexunit>env | grep SSL
<paroneayea>I have certs for other sites ;p
<paroneayea>that work with
<paroneayea>gpg: problem with the agent: No pinentry
<davexunit>paroneayea: can you talk to
<paroneayea>I keep going levels deeper and deeper on this yak
<davexunit>paroneayea: guix package -i pinentry
<paroneayea>davexunit: I did that and it's still complaining
<paroneayea>that's for gpg-2.0
<paroneayea>er gnupg
<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>time for a new key?
<paroneayea>mine was a 2048 key
<paroneayea>I guess I should upgrade anyway
<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
<paroneayea>I'm sooooo clooooooooooooose
<mark_weaver>paroneayea: I have the same problem connecting to 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.......
<paroneayea>soooooo close
<paroneayea>but I'm exhausted and taking a break for now
<paroneayea>thanks for your help, everyone!
<mark_weaver>paroneayea: okay, sleep well, and thanks for your perserverance!
<mark_weaver>perseverance even :)
<mark_weaver>I'm considering packaging the older NSS and building IceCat against it..
<mark_weaver>and seeing if that's less annoying strict
<mark_weaver>although I guess that gnupg should update the software on their website as well
<mark_weaver>*annoyingly strict
<Jookia>would it be appropriate to allow ssh access for git downloads
<CompanionCube>calher, iirc they use extended control sequences
<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
<Jookia>you okay
<calher>irssi wont resize with terminal
<mark_weaver>Jookia: users can use substitutes from to fetch those sources.
<mark_weaver>and that's over http
<Jookia>mark_weaver: so i can fetch a git checkout over hydra?
<mark_weaver>assuming that hydra has built that derivation
<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
<CompanionCube>it's stable for me
<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>Jookia: well, I don't know.
<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>that would solve some of the problems, at least.
<Jookia>It's not urgent
<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>philosphical questions
<mark_weaver>Jookia: fwiw, I respect what you're trying to do.
<mark_weaver>I'd like to enable this
<mark_weaver>I'm just trying to think it through with you.
<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?
<mark_weaver>and indeed, that's the plan.
<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
<mark_weaver>what change would be needed?
<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>Yes but you wouldn't want to
<mark_weaver>why not?
<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
<Jookia>aka protocol leaks
<mark_weaver>okay, but they can already do that
<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
<mark_weaver>okay, understood
<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?
<mark_weaver>because they are used in fixed-output derivations
<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>and ditto for svn-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
<mark_weaver>that's probably fine.
<mark_weaver>I guess that netcat has very few dependencies
<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.
<Jookia>outside implicit
<mark_weaver>and then I found that it led it a circular dependency
<mark_weaver>suppose I decide to fetch glibc with git-fetch
<mark_weaver>git-fetch requires git, which requires glibc, which requires git-fetch
<mark_weaver>circular dependency
<mark_weaver>no way to make that work
<Jookia>I see
<mark_weaver>but if it's just netcat, I think that's fine.
<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>what functionality of netcat will be used?
<Jookia>I'll quickly search, one moment
<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 80"
<Jookia>It uses HTTP CONNECT
<mark_weaver>Jookia: help me understand this. this is to access git:// URLs?
<Jookia> is actually better and explains why it's not working
<mark_weaver>sorry, I need to go afk for a while... will be back in a while...
<Jookia>No problem
<calher>tor browser bundle does not start
<calher>tor doesnt work with any apps
<chewieQC>Hi, is there an iso of GuixSD? I can't make the usb (?) download on the official website work in virtualbox
<calher>chewieQC: there is no iso
<calher>chewieQC: virtualbox is nonfree. use QEMU.
<chewieQC>I'm downloading it
<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
<paroneayea>yes.... YES!
<paroneayea>assword is properly packaged! :D :D :D
<Jookia>chewieQC: I think you need to use vboximageconvert
<Jookia>paroneayea: nice job!
<Jookia>chewieQC: you want the iso to turn in to a vdi disk image
<paroneayea>turns out whatever gtk issue it was
<paroneayea>it was fine once I logged out and logged in again
<paroneayea>"have you tried turning your login off and on?"
<calher>Jookia: Why are you supporting non-free software?
<Jookia>calher: goblins told me to
<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
<paroneayea>Jookia: :)
<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.
<mark_weaver>it's a disk image with GRUB on it
<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>That makes sense
<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?
<chewieQC>That would be perfect
<chewieQC>It has qemu has a requirement (
<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?
<paroneayea>patches sent to the list.... YES!
<paroneayea>ACTION does a dance
<Jookia>what kind of dance
<paroneayea> EVERYBODY
<paroneayea> _o/ \\o| DANCE! |o/ )o)
<paroneayea> |_ ) \\ (
<paroneayea> | |\\ /\\ / \\
<paroneayea>that kind
<mark_weaver>ACTION loves paroneayea's ascii art :)
<mark_weaver>pecg: can you ask the question on the mailing list?
<mark_weaver>it's not my area of expertise, and no one else seems to be answering
<paroneayea>assword stuff sent to the mailing list
<paroneayea>I said
<paroneayea>I'm tired.
<paroneayea>time to log off!
<paroneayea>later #guix friends!
<mark_weaver>good night!
<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>but I'm not sure about php specifically
<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>cool :)
<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
<mark_weaver>yeah, nginx seems far superior
<pecg>And lightweight also
<pecg>mark_weaver: Do you know details about the boot process of POSIX system, like GNU or BSD
<pecg>What's with the PID 1?
<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
<Jookia>all init systems use PID 1
<pecg>Jookia: Same thing I thought
<mark_weaver>what's the argument for why that's a weak point?
<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>Linux (the kernel) will panic if PID 1 exits.
<pecg>in GNU Shepherd too?
<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
<mark_weaver>well, that's an interesting question.
<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>and keep PID 1 very simple
<mark_weaver>and maybe we should do that with Shepherd
<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
<mark_weaver>what is?
<mark_weaver>moving the complex jobs to subprocesses?
<pecg>it distributes complexity
<mark_weaver>yeah. I'm very fond of the Hurd design.
<mark_weaver>I should really start using it more.
<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>I'm not there yet
<pecg>Jookia: I feel the same way
<pecg>I'm thinking even writing a new microkernel, just to see how it is implemented
<pecg>Very few people do so
<pecg>mark_weaver: Are you Magnolis?
<pecg>(maybe not)
<pecg>This is amazing
<mark_weaver>my nick is my name
<pecg>mark_weaver: I think I know from some other channel
<mark_weaver>maybe #libreboot?
<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>(I have a bare Novena board)
<Jookia>I have a bare board too :D
<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.
<mark_weaver>but there's no u-boot for the C201
<_`_>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.
<mark_weaver>I don't know if they will be brought back.
<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.
<mark_weaver>I hope that many people *do* buy it.
<pecg>what is TALOS?
<pecg>I clicked on that, but thought it was a scam or something
<mark_weaver>not at all
<mark_weaver>tpearson is the guy who ported coreboot and libreboot to several ASUS boards.
<mark_weaver>he's eminently qualified to do this
<pecg>I think raptorengineering is not tor friendly
<pecg>page loading seems endless
<mark_weaver>it's being slow for me too
<_`_>I think it's running on an underpowered vps
<pecg>_`_: Gotta wait then
<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>mark_weaver: Thanks
<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
<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>it's here, an IceCat specific change to the configuration:
<mark_weaver>disabling several protocols to defend against the Logjam attack, except that we fixed those problems long ago in openssl and nss.
<calher>Jookia: I looked for the change in the VCS repo. All I found was <>.
<mark_weaver>mordocai: stumpwm will need to be patched to look for sbcl.core in the right place
<mordocai>mark_weaver: Ugh really?
<mark_weaver>well, or maybe there's an environment variable, dunno.
<mark_weaver>taylan would be a good person to ask about this.
<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
<mordocai>Just need it to work!
<calher>Jookia: Got it.
<mark_weaver>why don't you search the stumpwm sources for occurrences of sbcl.core and see what it's doing
<mordocai>Yep, that's what i'm about to do
<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
<mordocai>Possibly. Idk how to do that though.
<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>mordocai: maybe some clues here:
<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
<mark_weaver>taylan is the one who made our sbcl package
<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: sounds good
<mark_weaver>mordocai: it would be good to email about the sbcl problem
<mordocai>mark_weaver: sent that email
<mordocai>What package provides bin/cc?
<mordocai>I need it for some lispy stuff
<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>ah, ok
<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/ 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
<mark_weaver>sure, that sounds like a reasonable approach too.
<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>oh i see
<mordocai>Found it! 'as' is in gcc-toolchain
<mordocai>Or one of its deps
<Jookia>ok i give up
<Jookia>i'll write a post to the mailing list about it
<mordocai>Okay new weirder error. Trying to compile I get
<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>this is totally standard, btw. not specific to guix
<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'
<mordocai>Programmers sometimes
<xd1le>haha brilliant
<mordocai>So that was my problem
<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>kind of thing*
<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.
<mordocai>iyzsong: Alright, thanks
<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.
<iyzsong>happy hacking :3
<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.
<mordocai>Well I need like 8 of them for guix
<mordocai>What is the right place?
<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
<mark_weaver>IMO, this is good practice on any system.
<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.
<mordocai>Alright. So is what I get after running guix environment guix. which bash shows /home/mordocai/.guix-profile/bin/bash
<mark_weaver>iiuc, on GuixSD we arrange to load .bash_profile from the display manager
<mark_weaver>I have to sleep now. happy hacking!
<mordocai>mark_weaver: night!
<mordocai>iyzsong: any insight on my error above?
<iyzsong>does emacs works?
<mordocai>Haven't tried it inside guix environment guix, but outside it does
<mordocai>(installed through guix)
<iyzsong>also, you can try `guix environment --pure guix', which give a environment total unreleated to the host distro.
<mordocai>That might help, i'll try that shortly
<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.
<mark_weaver>(the localstatedir setting is important)
<mark_weaver>okay, really going to sleep now :)
<mordocai>hehe thanks, i'll try that stuff
<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>ok :-)
<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>Right, but I want to verify that
<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")
<iyzsong>thanks :3
<mordocai>Well either way with my sbcl 1.3.1 build attempt I get
<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.
<xd1le>calher: do you use stumpwm?
<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
<xd1le>mordocai: thanks
<iyzsong>mordocai: yeah, I guess 'guix build sbcl --check' should do what you want.
<iyzsong>but it won't change anything :)
<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
<mordocai>I'm using git version
<mordocai>but apparently old, just did a git pull
<mordocai>one sec
<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
<jamesaxl>do you have debian pcks ?
<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
<xd1le>mordocai: night!
<iyzsong>jamesaxl: what's is 'pcks'? I think there is no guix deb package.
<jamesaxl>iyzsong: what kind of pkgs does guixSD have?
<xd1le>jamesaxl: it's own
<jamesaxl>xd1le: that's great
<iyzsong>yes, scheme files for source, and simple archive (nar) for binaries.
<calher>how do i power off the machine
<iyzsong>halt? or press the button..
<calher>button is no good
<iyzsong>well, when using systemd in the past, I have to do it :(
<jamesaxl>calher: i think init 0 can help you
<calher>what is init 0
<Jookia>type 'halt'
<jamesaxl>Jookia: are you against init 0
<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
<alezost>jamesaxl: on GuixSD there is no "init" command. We use Shepherd <> as our init system. And the proper way to shutdown here is "halt"
<Steap|DevConfCZ>how hard would it be to put together a lightning talk about Guix ?
<Steap|DevConfCZ>like, in a few hours :D
<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>rekado: how do you explain Guix in 5 minutes
<Steap|DevConfCZ>I've just taken a look at your slides, it seems a bit fast
<alezost>jamesaxl: fps wrote something about it: <>
<jamesaxl>alezost: thank you very much
<alezost>glad to help :-)
<jamesaxl>i have never seen RS in gnu channel
<Steap|DevConfCZ>yeah well, improvising a lightning talk about Guix seems a bit too hard for me right now
<Steap|DevConfCZ>Devconf will have to wait till next year to hear about it!
***raulet_ is now known as raulet
<boegel>Steap|DevConfCZ: talk to rekado
<boegel>Steap|DevConfCZ: and see
<Steap|DevConfCZ>boegel: yeah, I watched this video in between conferences
<Steap|DevConfCZ>but this is quite fast, I don't have time to rehearse + I'm not used to talk to people :D
<Steap|DevConfCZ>I'm pretty sure I'd crash the talk if I were to do it today :/
<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
<pizzaiolo>anyone might know why?
<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
<alezost>pizzaiolo: yes, because there is no "pt_BR" in %default-locale-definitions: see the bottom of <>
<pizzaiolo>thanks alezost
<pizzaiolo>I should like to add a pt_BR locale in the future
<pizzaiolo>any links you can point me to?
<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 :-)
<pizzaiolo>ok, let me check how to do it
<iyzsong>pizzaiolo: I guess custom the 'locale-definitions' field with '(list (locale-definition (name "pt_BR") ...' should do it.
<pizzaiolo>iyzsong: I mean how to send a patch
<iyzsong>ok :-)
<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>I want to add a locale for esperanto
<pizzaiolo>but it's not the official language of any country
<pizzaiolo>should it be "eo" or "eo_EO"?
<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>pizzaiolo: as iyzsong suggests, you can do it like this: <>
<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
<boegel>hmm, Pjotr is not around here? the guy from ?
<pizzaiolo>we need some warning like these :P
<janneke>pizzaiolo: nice graph...warnings for what?
<pizzaiolo>guixSD in general? :P
<mark_weaver>pizzaiolo, alezost: here's the answer to the pt_BR locale problem:
<pizzaiolo>I'm using pt_PT meanwhile
<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>we should improve the error message
<mark_weaver>better yet, we should simply arrange to automatically add it to the system's locale definitions
<mark_weaver>I do recommend using the .utf8 one though
<pizzaiolo>mark_weaver: am using
<pizzaiolo>mark_weaver: how about esperanto?
<pizzaiolo>should it be eo or eo_EO?
<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>my knowledge in this area is weak
<pizzaiolo>I'm not sure if the program expects a _XX
<mark_weaver>pizzaiolo: my guess is that it's just "eo"
<mark_weaver>based on looking in /run/current-system/profile/share/locale and ~/.guix-profile/share/locale
<boegel>pizzaiolo: haha
<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>this should be a FAQ
<pizzaiolo>mark_weaver: is there an FAQ btw?
<mark_weaver>I guess we need to add documentation about it, because I'm tired of arguing it every other day :)
<janneke>sorry! ;-)
<mark_weaver>janneke: no worries :)
<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.
<janneke>thank you
<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"
<petter>Any tips?
<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
<pizzaiolo>iyzsong: I tried alezost's past and now I can't reconfigure
<pizzaiolo>it says end of file in string constant
<pizzaiolo>in the error message
<NiAsterisk>GuixSD logo is good enough for button making: (bad quality of camera, looks better)
<pizzaiolo>ooh nice NiAsterisk
<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
<pizzaiolo>janneke: this is my config.scm:
<janneke>try emacs and enable scheme-mode
<pizzaiolo>janneke: anything wrong in that bit?
<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.
<janneke>it should read: (name "eo.utf8"))
<pizzaiolo>nicely spotted janneke
<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. :)
<mark_weaver>and greetings!
<mark_weaver>pizzaiolo: yes to you too :)
<NiAsterisk>but not in the sense of archlinux for example, where I remember 8 years ago stuff breaking the system when you upgraded.
<NiAsterisk>you can always rollback with this rolling :)
<pizzaiolo>mark_weaver: woo, thanks
<mark_weaver>it's a rolling distro in the sense of archlinux, but if something breaks you can always roll-back.
<drtan>I see. That's amazing. :)
<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>experiment with a new glibc fearlessly :)
<mark_weaver>or a new initrd, whatever
<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.
<NiAsterisk>drtan: depends on what you need I would say?
<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>reboot/shutdown from the GUI doesn't work.
<mark_weaver>updating services requires a reboot last I checked. our init system is lacking many features.
<drtan>Do you use systemd?
<mark_weaver>we have our own init system based on GNU Guile.
<drtan>That's refreshing.
<mark_weaver>our initramfs uses guile also
<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.
<mark_weaver>*when I said
<xd1le>ah yes, true
<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>I love when I read about a tiff update in Debian <>, I investigate, and discover that I fixed all those problems in Guix over two weeks ago :)
<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 :)
<pizzaiolo>mark_weaver: I'm working on
<pizzaiolo>to add guixSD
<pizzaiolo>was ludo the iniciator of the distro?
<mark_weaver>pizzaiolo: yes
<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
<mark_weaver>and last I chek
<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>actually, he's now down to 43% of the total commits
<mark_weaver>25% of commits over the last year
<pizzaiolo>well, the more contributors, the merrier
<mark_weaver>he's made 4644 commits total, and I come in second place at 976
<mark_weaver>so, a rather big gap there :)
<pizzaiolo>one-man army
<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 :)
<pizzaiolo>2015 was a great year for guixSD
<pizzaiolo>according to that graph
<pizzaiolo>I wonder the cause
<mark_weaver>each year is better than the last :)
<mark_weaver>the future for Guix looks bright to me :)
<pizzaiolo>I think it's the future
<pizzaiolo>reproducible builds
<mark_weaver>it's the only future I want to live in, that's for sure :)
<mark_weaver>it's the only way to gain trust in binaries
<pizzaiolo>the gentoo way is a bit much for me
<pizzaiolo>don't want to compile everything
<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.
<mark_weaver>which is almost everything
<mark_weaver>*almost everyone
<drtan>There will be real breakthrough if we found the way web services to be verified against the code.
<mark_weaver>drtan: what do you mean?
<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 that's an impossible problem.
<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.
<NiAsterisk>the "cloud" killed off real secure servers.
<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
<pizzaiolo>although it's not very good
<pizzaiolo>it works anyway
<pizzaiolo>it's P2P
<NiAsterisk>distributed (or real distributed) services work when it covers large areas and no lobbyism goes against it.
<NiAsterisk>which is a hard way till you are there
<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>I can push the patch soon :)
<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
<civodul>ACTION updates guile-next
<janneke>ACTION rejoices
<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
<NiAsterisk>making vegan muffins now :)
<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"
<civodul>now, you can set LANGUAGE=eo
<pizzaiolo>that's what I did
<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.
<mark_weaver>just "guix pull"
<janneke>ah, great
<pizzaiolo>cool, civodul
<janneke>so how do i include local patches/commits that i want to test into that "guix pull" mechanism?
<pizzaiolo>civodul: so apparently it's a WONTFIX ):
<efraim>`guix refresh -l grep` says 12, but I'm not convinced
<mark_weaver>pizzaiolo: I read the same thing and it doesn't seem like a WONTFIX to me: the ticket civodul linked to refers to this one:
<mark_weaver>see the last comment in particular
<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
<janneke>yes, amazing amount of info there!
<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>or will be an "." better as the last separator?
<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
<NiAsterisk>ah cool, I'll check it
<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.
<mark_weaver>as long as the first release will be at least 0.1
<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 :)
<mark_weaver>in case the first release is 0.0.1
<NiAsterisk>I doubt lispf4 port from fortran in 1980s to C in the 2000s will ever see a release number.
<NiAsterisk>okay, I'll add an zero
<NiAsterisk>to my notes I mean
<fhmgufs>Could someone give me an example where to versions of a package exist, one with gtk+-3 and one with gtk+-2, please?
<mark_weaver>fhmgufs: webkitgtk-4.9
<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?
<mark_weaver>could be, dunno. I haven't tried that in a while.
<mark_weaver>it's not really officially supported
<mark_weaver>civodul: any help for this? ^^
<janneke>just did the `latest' symlink trick and now have a hard time getting my package to build...still learning anything
<janneke>using a local webserver works ...
<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>ACTION still learning how to use hydra effectively
<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>efraim: good thought, but no :)
<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.
<mark_weaver>anyway, I have to go afk. ttyl!
<fhmgufs>iyzsong: Good idea, updated the patch.
<pizzaiolo>I'm trying to compile libsoundfile, and I run into this gcc error
<pizzaiolo>anyone has a clue?
<janneke>gcc cannot find its assembler, as
<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.
<mark_weaver>including ld-wrapper which is important for guix
<mark_weaver>ACTION goes afk again
<pizzaiolo>I think that was meant for me, right?
<petter>hm, my computer just rebooted on its own
<fhmgufs>pizzaiolo: I think so, too.
<pizzaiolo>petter: it needed a little break from you
<petter>pizzaiolo: :P
<petter>wonder if 'reboot' works now..
<petter>it does :)
<civodul>janneke, mark_weaver: file:// URIs are supposedly supported by url-fetch; see (guix download)
<pizzaiolo>anyone working on a gnome port?
<civodul>pizzaiolo: gnome-shell is available, it seems that not much is missing
<civodul>iyzsong took care of that
<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
<Steap|Brno>"ton of new users"
<Jookia>... freetards?
<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
<calher>I don't find it offensive.
<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>Watch Woodstock (1970).
<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.
<calher>What's 'deconstructive' mean?
<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.
<janneke>Jookia: @JooKia has been suspended
<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>or do*
<lfam>Try using a paste site
<lfam>We can look at it now
<lfam>on IRC
<mordocai>Sure, one sec.
<pizzaiolo>iyzsong: what's missing from gnome?
<mordocai>Alright, i'm in `guix environment guix` on my debian + guix box so I made this patch to lisp.scm I then ran make and did ./pre-inst-env guix build sbcl. I got this output: 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
<mordocai>Ah okay. So I need to go up higher.
<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
<mordocai>I did copy/paste the hash string.
<mordocai>I typed the version string
<mordocai>I'll focus on the hash string for now
<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>Well i'll look it up
<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
<mordocai>Right. Attachments it is.
<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
<mark_weaver>atheros cards are the way to go
<mark_weaver>some of them, at least
<mark_weaver>jjmarin: what kind of machine do you have?
<jjmarin>thinkpad x131e
<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>It is*
<mark_weaver>jjmarin: looks like your best bet is to get an external USB wireless adapter, I'm afraid. here are some:
<lfam> <-- May also be helpful
<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>and all of the approved cards require blobs, iiuc
<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>yeah, it's infuriating
<mark_weaver>coreboot would be another option, but coreboot doesn't seem to support your laptop either.
<NiAsterisk>i can recomment the TL-WN722N for external wifi
<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>but we're close
<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.