<Formbi>mange: so making a /usr/bin and linking ld there could work?
<mange>Sorry, I used the wrong word. I meant the dynamic loader (which, for some reason, I always think of as a dynamic linker). It's usually something like /lib/ld-linux.so2, I think.
<mange>In GuixSD you'd have to link that to a particular ld-linux, which could disappear if/when you gc.
<Formbi>wouldn't the current version be in the profile lib directory?
<mange>I don't think so, because each binary produced by Guix will embed a reference to its particular ld-linux in the store. This is safe, because the GC can see that link and ensure it doesn't get collected.
<mange>When you have references into the store that the GC can't see, that's when you're in trouble.
<RetardedOnion>has someone used guix import and could help me import telegram from nix? i dont think i understand the syntax
<mange>I have used guix import a lot, but never to import from nix. Can you tell us more about your problem?
<atw>is it the invocation of guix import that's trroubling you?
<RetardedOnion>mange: i cloned the nix repo so its at ~/nixpkgs. my command therefore is guix import nix ~/nuxpkgs telegram-desktop. it says it cannot find nix-instantiate. i exported NIX_REMOTE=daemon before
<apteryx>hi! I'm trying to step some mcron job, and I can't seem to test those with 'mcron -sN my-job'. When I run mcron on the jobs compiled by guix system reconfigure, they work fine... I wonder the difference? Here's an example of the failures I'm seeing: http://paste.debian.net/1037217/
<atw>RetardedOnion: I'm cloning nixpkgs now and I'll try to reproduce. I have to go soon so it might be tomorrow
<RetardedOnion>atw: its 4am here. i need to go to sleep as well. if you can create a package tell me how and give me the package pasted into a pastebin please. i am always on because of quassel. thank you so much for your effort
<mange>apteryx: Does it work when you provide an absolute path to your file? The errors look like it's looking it up on its load path, but I don't know if mcron lets you add to its path.
<apteryx>mange: Thanks! This is it! I had to pass the full path!
<apteryx>I thought the shell would somehow do that for me.
<mange>The shell will often expand ~ into an absolute path, but that's about it.
<atw>apteryx: you may be interested in my g-expression based backup routine
<mange>Even then, you sometimes run into troubles with Guix doing things like --manifest=~/path/to/file, which won't work.
<reepca-laptop>Hm, I think I've managed to reach an all-time low in functioning networking... I'm getting ping times from 500ms to 10000ms between my computer and the wireless router it's connected to. I suspect it's a problem on my end, although I've only been able to test wired connections for comparison (sub-1ms ping times there)
<demotri>Are store items with "-check" part of deduplication?
<demotri>What I see: ls -l /gnu/store/...-foo-1.0.0/foo /gno/store/...-foo-1.0.0-check/foo, the "-check" version has link-count 1, the plain version has link count of 11 in my case. When I diff them, they are identical. What's this? If they are not part of deduplication (even after gc --optimize), the output of diffoscope is full of those link counts. Can't see the real problem.
<ngz>Hello. What version of libstdc++ Guix is using with gnu build system? Can I assume it is the same as gcc (5.5.0 at this time), or is it another version? How can I check? (if my question doesn't make any sense, please let me know).
<rekado>ngz: in (gnu packages gcc) we have a procedure (make-libstdc++ gcc)
<lfam>RetardedOnion: The nix importer is not really maintained anymore. I think we should either fix it or remove it
<RetardedOnion>when i create a directory somewhere in ~ and export PATH=$PATH:/home/whatever/directory i cannot execute the binary in there because the file is not found, it says /home/whatever/directory/binary not found
<brendyyn>my logitec gaming mouse still has its configuration saved in it from when it was on windows, so now i have mouse buttons that can type the chars ()bgm. I can basically type lisp with my mouse
<RetardedOnion>i actually wonder why it seems nobody on guixsd uses telegram
<rekado>RetardedOnion: you can’t expect a binary that was linked on a different system to work. Guix does not abide by the FHS, so “well known” paths don’t exist.
<RetardedOnion>i kinda expect binaries you download from the site to work because libaries should be statically linked.
<RetardedOnion>then again: if they were statically compiled guix wouldnt exist
<rekado>if its statically linked then you’d only need to patch the loader.
<RetardedOnion>thanks. i doubt its getting accepted in the repos because of the servers its connecting to. is there a bigger community/nonfree repo for guix?
<rekado>there’s no problem with servers that use proprietary software
<rekado>we accepted, for example, a client for Slack.
<lfam>+1, the free software movement as defined by the four freedoms doesn't have a concept of "free" or "non-free" services
<lfam>As long as the telegram client is free software, we should be able to offer a package of it
<rain2>RetardedOnion: If possible I would recommend against using telegram. it's been shown to be insecure in several ways and the authors have responded badly
<rain2>telegram client might be free but it is only a shell for their proprietary service, same as netflix or anything
<rekado>there are, of course, other considerations that a user can make before using software that ties them to a service, but these are not the same considerations that the free software movement is concerned with.
<lfam>Agreed, but it's not a concern for our distro
<rain2>what about the MAME emulator? it is entirely free software but there was debate about not including it because it can run nonfree roms
<lfam>I also agree with rain2's sentiment about Telegram's cryptographic implementation. My understanding is that it's never received a cryptanalytic review
<rekado>there was a long unproductive debate about it on various mailing lists that I’d rather not rehash here.
<brendyyn>but in the end do you accept such emulators?
<RetardedOnion>rain2: i know telegram is shit. mobile source gets released every few months, security is probably flawed and the servers are completely closed. still better than whatsapp and that is why i use it
<rekado>the fact that something can run nonfree software is not grounds for exclusion.
<RetardedOnion>a messenger is useless without people to message to. i "use" matrix but with noone
<brendyyn>rain2: i feel like there are essentially no good options and only a few sorta-ok options
<brendyyn>my riot has allthese ** Unable to decrypt: The sender's device has not sent us the keys for this message. **
<rain2>oh that is a problem, i have encountered that too
<brendyyn>because i log in on my desktop and phone, and have done on windows too
<RetardedOnion>i like the server based idea that telegram has. i want a server to handle everything, not my phone or whatever. i can host it myself if its needed, but a phone shouldnt be needed to write messages.
<pkill9>yeah that's annoying that you can't use your phone number from your desktop and manage messages etc
<pkill9>RetardedOnion: what software are you trying to run?
<brendyyn>my biggest issue is i dont want to cause trouble with my friends. once i asked someone to install signal so we didnt have to use facebook, explained various issues with fb and they got very angry at me
<rain2>because it forces you to use a phone number, the author works for facebook and recommends against GPG, and they did not want people to use the F-droid free appstore and they are against federating with people hosting their own server
<Formbi>RetardedOnion: maybe try symlinking …-glibc-version/lib/ld-linux.so.2 to /lib/ld-linux.so.2
<rain2>it's much less bad than telegram, and for example the cryptography in it seems very high quality - but that is my reasons to avoid it
<RetardedOnion>where do i specify to suspend and lock my screen at lid-close? is it elogind?
<RetardedOnion>Formbi: when i get around making a package it will work. icecat will do until then.
<RetardedOnion>isnt qt still broken? well telegram will have to wait a bit longer
<pkill9>RetardedOnion: you can define the options in the (services) declaration, see the manual
<RetardedOnion>hwo do you lock your screen when you are using just a wm? i dont really care what locker if its not i3locker since that never works with my password. and i really dont want to pkill i3lock to unlock my screen
<lfam>Something like this: `guix environment guix -- ./bootstrap && ./configure --localstatedir=/var && make`. Then you can use the Guix you've built like this: `./pre-inst-env guix package --install clustershell`
<mg>yeah. already read the building from git. but didn't get the point that i also would need to do this when i'm actually not working on guix itself but on the package codebase
<lfam>Right, Guix "itself" and the packages are integrated in the same codebase
<mg>shouldn't (inputs `(("openssh" ,openssh))) bring in stuff like the ssh client command?
<mg>runngin guix environment --pure --ad-hoc python-clustershell doesn't do so
<mg>however using guix environment --pure --ad-hoc python-clustershell openssh does
<lfam>'inputs' will be made available in clusterssh's build environment. They are intended for things like libraries which will be linked to by the package being built. 'propagated-inputs', on the other hand, would be installed alonside clusterssh, so they are useful for dependencies on command-line tools like the ssh client
<lfam>For the specific case of packages that want to use the `ssh` client rather than an SSH library, we usually don't add OpenSSH to propagated-inputs, because it's typical to have OpenSSH installed anyways, and we prefer to keep a loose coupling
<lfam>The user might even prefer to use some SSH client besides OpenSSH's
<lfam>And, there can be tricky interactions between things the user has explicitly installed and propagated-inputs. There may be filepath collisions when building the profile, which is a union of symlinks to /gnu/store. We sort of handle it on a case-by-case basis. For SSH, it's typically to let the user install a client manually if the other package is at all useful without SSH. For example, our rsync package does not automatically pull in an SSH client
<lfam>I don't have a strong opinion about whether or not the clusterssh package should propagated openssh. If it were me I would leave openssh out of the clustershell package definition, but I'm not using clustershell :)
<pkill9>if pyton simply used version-specific environment variable for library path, i.e. PYTHON36PATH, thena lot of problems would be fixed
<lfam>I do think it's better to use libraries like paramiko than try to use command-line programs as libraries, but again, I'm not using or writing clusterssh :)
<jabranham>Does guixsd have any notion of "channels" like nixos? I can't find anything like it in the manual.
<lfam>jabranham: Not yet. There is interest in it but we haven't implemented it so far
<pkill9>jabranham: no, but i think it's planned to be added
<rekado>jabranham: currently, you can extend the set of packages by setting the GUIX_PACKAGE_PATH environment variable to any directory containing Guix package modules.
<jabranham>So then the only way to get a binary of a package more recent than what's in 0.15 is to compile it yourself, is that right?
<pkill9>when you say 0.15, do you mean the installation image version or the latest git master?
<jabranham>pkill9: I'm just starting out, so I installed from the installation image then ran "guix pull" and "guix system reconfigure /etc/config.scm". I don't totally understand what guix pull does yet though so I'm unsure if I'm at the installation image version or the latest git master :-)
<pkill9>"# Arrange so that ~/.config/guix/current comes first."
<lfam>jabranham: What `guix pull` does by default is update the copy of Guix you are using to the latest commit of our Git repository. Effectively, it updates the Guix command and set of available packages
<pkill9>unless i did edit it, i don't think i did though
<roptat>I wonder what would happen if we got rid of guix in the system profile?
<pkill9>ACTION wonders if guix-git's package definition for guix could refer to itself
<pkill9>ACTION feels a little uneasy with the recursion
<jabranham>I'm confused about the difference between ~/.guix-profile and ~/.config/guix/current. Can someone explain why the guix binary seems to live under the latter but the other programs live under the former?
<roptat>you would need to know the hash for the commit you're going to make
<vagrantc>ACTION pretty much only ever uses "sudo -E" to run guix from the user's profile
<rekado>vagrantc: at the very bottom of the package graph lie bootstrap binaries
<lfam>vagrantc: The packages are based on a handful of bootstrap binaries, from which the entire package graph is built. Changing them would effectively mean forking Guix, since the entire graph of packages would change
<lfam>There is an ongoing effort to develop and introduce a different bootstrap technique that would not require these bootstrap binaries
<rekado>a statically linked tar to unpack the first tarballs, a Guile blob, a GCC blob… etc
<mbakke>wowza, bzip.org apparently expired and has been taken over..
<mbakke>vagrantc: Great talk! Grafts are really simple: they take an already built package as an input, and outputs a new package with all /gnu/store/<vulnerable-hash> strings replaced with the fixed version :-)
***OriansJ` is now known as OriansJ
<OriansJ>vagrantc: The Current Guix Bootstrap binaries are a fixpoint; So assuming we don't discover some massive Trusting Trust attack in the entire Free Software Ecosystem, changing of the root binary shouldn't change the fixpoint that Guix depends upon.
<jabranham>Anyone using EXWM and starting emacs from .xsession? I keep getting "error in process filter: [XELB] Connection failed: No protocol specified".
<rekado>mbakke: looks like it would be difficult to fix fontforge on core-updates.
<rekado>we could 1) try to disable Python support completely or 2) switch to Python 2, or 3) patch Python 3.7.
<rekado>option 3 is the most invasive, but it’s the most correct thing to do.
<amz31>jabranham: you can at least get some understanding of basic forms, primitives forms like lambda, define, let, quote, unquote, quasiquote. I think that list is good.. And what macros are useful for, because they change the way the code is interpreted. You don't need to be able to write macros tho
<jabranham>amz31: I'm OK with emacs lisp, so guile shouldn't be too different I think
<amz31>jabranham: ok then you can quickly jump in the guix boat
<jabranham>amz31: scheme is one of the main reasons I chose to experiment with guixsd rather than nixos :-)
<amz31>it opens an editor with the package definition in scheme
<amz31>except in the default install the definition is read only
<jabranham>hrm... "guix download <pkgname>" always results in "failed to parse URI".
<lfam>jabranham: `guix download` is for downloading arbitrary files, not Guix packages. You can think of it like a very simple wget
<lfam>The file is downloaded to /gnu/store and it's hash (in the format expected for Guix packages) is printed
<jabranham>lfam: oh, gotcha. The info page mentions that it also saves bandwidth by not needing to download it again, but how does it match up http:// some-random-place.tar.gz to a package declaration?
<lfam>It doesn't do anything related to packages. You give it an URL and it will try to download from it
<lfam>If you were doing a package update, you could use it to get the new source code hash for putting in the updated package definition. When testing the build of the updated package, you wouldn't need to download the new source code since it would already be in /gnu/store, and source code is looked up by its hash
<jabranham>"source code is looked up by its hash" was the part I was missing. Thanks, that makes sense
<lfam>I actually think it's better to download the source code some other way and then get the hash with `guix hash`, because having it already in /gnu/store means the URL is not tested, which can lead to broken package updates
<rekado>mbakke: using Python 2 for fontforge seems to work fine.
<rekado>Hey, if any of you have ideas about what ARM hardware to buy for a build farm extension, please write to firstname.lastname@example.org.
<rekado>we seem to never actually make a decision about this, and that’s sad.
<emacsomancer>I ran into a weird problem: /guix is allocated/using more than twice the number of available inodes on the root partition.