IRC channel logs

2018-08-09.log

back to list of logs

<rekado>I haven’t seen any announcements or plans for 3.7.1
<database>rekado: ?
<database> https://paste.debian.net/1037148/
<RetardedOnion>why cant i run binaries?
<mange>What sort of binaries are you trying to run?
<RetardedOnion>mange: got my problem sorted out. java was getting rendered "wrong" and i tried the oracle version. problem was just bspwm.
<RetardedOnion>do you know about libvirt and how to add something to /etc/libvirt/qemu.conf and how to use ovmf with it?
<mange>I don't, sorry.
<RetardedOnion>since i cant get my graphics card to run on guix easily i doubt i will be switching to it on my desktop. shucks.
<Formbi>now that you mention it…
<Formbi>I couldn't use normal Firefox
<RetardedOnion>icecat is basically firefox esr. but you can try to make a package for it.
<Formbi>I mean the version from the site
<RetardedOnion>we need some kind of shithole like the aur for nonfree packages
<Formbi>there's a tarball with the browser and libraries
<Formbi>and the system was saying «no such file» when I did ./firefox
<mange>Formbi: That still won't work on GuixSD, because it won't be able to find the linker it wants.
<RetardedOnion>can you share what gpus you are using with guix if its not intel?
<mange>There's a thread on help-guix about running non-guix software: https://lists.gnu.org/archive/html/help-guix/2018-08/msg00037.html, but it's not really an officially supported workflow.
<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.
<Formbi> https://lists.gnu.org/archive/html/help-guix/2018-08/msg00054.html that's probably the solution
<mange>That actually has the same problem, but it should work until you call gc.
<Formbi>hm, yes
<nckx>Just point to profile symlinks instead of using store file names directly. GC-proof.
<nckx>'s how I use Tor Browser on Guix.
<nckx>Which is basically FF.
<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
<RetardedOnion>"in execvp of nix-instantiate: no such file or directory"
<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.
<apteryx>atw: sure do :)
<apteryx>mange: this is because ~ is expanded only when it appears at the beginning of the argument. Got hurt by that when playing with GNU getopt in a Bash script ;)
<mange>Yeah, I understand why it is, it's just annoying. I try not to rely on the shell's expansion behaviour. Even moreso now that I use both eshell and bash, which expand things differently.
<atw>apteryx: https://paste.debian.net/1037218/
<atw>you can replace borg with any backup program
<atw>RetardedOnion: I can reproduce, not sure if we're both doing something wrong or if this is a bug. I will investigate more, hopefully tomorrow
<apteryx>atw: very nice! I like the steps showing how to test it :). I was also looking at Borg to replace my dump rsync dump.
<apteryx>dumb*
<atw>I wrote those for myself because I kept forgetting. Ludo helped me out https://lists.gnu.org/archive/html/help-guix/2018-01/msg00042.html
<atw>gtg!
<mange>RetardedOnion: Do you have nix installed? It looks like nix-instantiate comes from nix (which is probably necessary to read the nix expressions).
<database>rekado: still here ?
<apteryx>doesn't mcron spit errors somewhere? /var/log/messages or such?
<brendyyn>Might be going to china soon so ill have to learn how to evade the machine learning behemoth of censorship that is the ungreat firewall
<ison111>Has anyone else been experiencing lock ups when building some Qt packages? I've tried about 5 times now and it always does a hard lock up while compiling, not even sysrq keys work.
<ison111>Is there any chance that could just be a hardware issue? Maybe a sign of overheating? My PC is pretty old now.
<mange>I haven't with Qt, but I used to have that problem when building ledger. From memory it worked fine if I added #:parallel-build? #f to the arguments.
<ison111>mange: Alright, I might try that later then, thanks.
<mange>It didn't have the same problem on hydra back then, so I think my problem with ledger was something to do with my machine. I never tried to track it down any further than that.
<brendyyn>were you running out of memory?
<mange>Very possibly.
<database>any command in terminal return segmentation fault
<brendyyn>maybe add swap space and see what happens
<database>brendyyn: can you help me out ?
<brendyyn>maybe. I'm not sure how you got into this state
<database>brendyyn: me or mange ?
<brendyyn>you
<database>ohh
<database>so, you don't know how to come out from this state
<brendyyn>no i mean i have no idea what you did that made it happen
<brendyyn>more information would be useful
<database>ohh
<database>to be honset i don't know too
<database>brendyyn: and here is one more thing Xfce is working fine but boune again shell is not it's keep giving segmentation fault
<brendyyn>env -i bash --norc
<brendyyn>can you run that?
<brendyyn>wait it wont work
<brendyyn>maybe there is something wrong in your .bash_profile or .bashrc
<database>okay
<database>i have backup of my .bash_profile let me replace it
<brendyyn>for changes to .bash_profile to take effect you have to log out and back in again
<database>okay
<database>let me try it
<database>brendyyn: no changes in .bash_profile
<brendyyn>do internal bash commands work like `time'?
<database>yes
<database>only coreutils commands are not running
<brendyyn>not all commands?
<brendyyn>what have you tried?
<database>nothing
<database>but i am thing of reinstalling it
<brendyyn>do guix commands work?
<database>nope
<brendyyn>hmm i dont really know what's going on
<database>neither do i
<database>leave it can you help me with assembly language
<database>here in guixsd ld cannot find -lc
<database>brendyyn: solved now it's working
<brendyyn>how?
<database>"guix package -r bash" using xfce terminal
<brendyyn>very strange
<brendyyn>Return a package that runs takes source files from the SOURCE directory
<brendyyn>^ runs looks like i typo there. could someone with git access find that like and fix it up please?
<brendyyn>that line
<database>brendyyn: i don't understand what you are trying to say
<brendyyn>I just stumbled across a typo in guix
<database>ohh
<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.
<roptat>hi guix!
<demotri>Hi roptat.
<roptat>demotri: I have this issue too
<roptat>didn't know what the link count was though, I just ignored it
<demotri>roptat: I just figured it out now.
<demotri>ls -l /gnu/store/zlxarsbwwkasy69cyv34jvzi7bgmajxz-shishi-1.0.2-check/share/man/man3/shishi_asreq.3.gz /gnu/store/zlxarsbwwkasy69cyv34jvzi7bgmajxz-shishi-1.0.2/share/man/man3/shishi_asreq.3.gz
<demotri>-r--r--r-- 1 root root 624 Jan 1 1970 /gnu/store/zlxarsbwwkasy69cyv34jvzi7bgmajxz-shishi-1.0.2-check/share/man/man3/shishi_asreq.3.gz
<demotri>-r--r--r-- 11 root root 624 Jan 1 1970 /gnu/store/zlxarsbwwkasy69cyv34jvzi7bgmajxz-shishi-1.0.2/share/man/man3/shishi_asreq.3.gz
<demotri>Here the "1" and "11" before the user/group is the links.
<demotri>That's the number of hard links to the inode of the file.
<demotri>You can figure out the inode with ls -i file.
<demotri>Then you can find all files pointing to that inode: find /gnu/store -inum 46161304
<roptat>fun :)
<demotri>Yes :-)
<roptat>were you the person who reported one of our java packages was not reproducible because of the use of <tstamp>?
<roptat>I can't remember what package and if it was fixed
<demotri>roptat: Yes.
<demotri>roptat: I thought you reviewed and commited it. Wait ...
<demotri>49a8684d9f20656aaa9094c02164cbf2f67b290b
<roptat>ok, I forgot ^^'
<roptat>did you work on a patch for ant, or can I work on it?
<demotri>No. I did not. If you would like to do it, that would be great!
<demotri>It would be cool to bring that upstream. I don't know how much the ant team is open for that.
<roptat>no idea, but I'll try
<demotri>Back to the link-problem: Is that a bug in Guix?
<roptat>as long as you don't change the default behavior, people are quite open to this kind of change I think
<roptat>I don't see a reason why -check directories couldn't be de-duplicated, but maybe there is one?
<roptat>your best bet is to send a mail to help-guix I think
<demotri>Yeah, will do that.
<rekado>brendyyn: in the 7+ years that I lived in China I used an SSH tunnel to avoid web censorship.
<brendyyn>How long ago was that?
<rekado>I left in 2014.
<brendyyn>and where abouts in China were you?
<rekado>Shanghai
<rekado>there were lots of problems with VPNs but never a single problem with SSH.
<brendyyn>Interesting. this post foudn ssh tunneling had issues http://blog.zorinaq.com/my-experience-with-the-great-firewall-of-china/
<rekado>I used privoxy and only routed known blocked sites through the tunnel.
<rekado>my servers were in Iceland and France.
<brendyyn>interesting
<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)
<ngz>Yes, I saw that.
<rekado>ngz: it produces a libstdc++ package based on the given gcc package.
<ngz>I couldn't find it called in "gnu-build-system.scm"
<ngz>Anyway, if you guarantee that gnu-build-system is also using 5.5.0 for libstdc++, then I trust you.
<rekado>in guix/build-system/gnu.scm you can see “standard-packages”
<rekado>it looks up %final-inputs in (gnu packages commencement)
<rekado>that refers to gcc-final
<rekado>that’s also where libstdc++ is defined
<rekado> and that is made with (make-libstdc++ gcc)
<ngz>OK.
<rekado>and that gcc is defined in (gnu packages gcc)
<rekado>(define-public gcc gcc-5)
<brendyyn>did you just maintain your own small list of sites to route?
<ngz>Thank you rekado
<rekado>brendyyn: it wasn’t small but yes that’s pretty much what I did.
<brendyyn>id also need to route my phone and programs like signal
<rekado>I didn’t use a phone then (and still don’t).
<mbakke>Oh no, the 'staging' evaluation on Hydra seems to have gotten "stuck": https://hydra.gnu.org/jobset/gnu/staging
<brendyyn>so hard to not have a phone :/
<rekado>brendyyn: I guess it’s hard to stop using one, when it has already become a part of your workflow. I started by not taking it with me on most days.
<rekado>I’d miss calls, but none of them were important anyway.
<rekado>I’d take a book instead to have something to read on my commute.
<rekado>eventually I realized that I really had no use for a phone.
<rekado>I do reactivate the phone sometimes when I’m traveling, because it can be useful in travel emergencies (no money, no internet, missed flight, etc).
<brendyyn>I've been getting my friends to switch to signal, but its annoying that it requires a phone and phone number for authentication and contacts
<brendyyn>so i've caused myself another problem, but atleast we're not on facebook
<brendyyn>also i work casually so i could be called to work on the spot :/
<ng0>there's signal desktop
<ng0>but you have to pair it with the phone first
<brendyyn>yes i use that but its still requires the phone
<brendyyn>and it cant add contacts i dont think
<brendyyn>it just has an option to sync contacts from the phone
<brendyyn>at first i was recommending riot but its interface is poor
<brendyyn>and enabling encrypting can cause problems
<ng0>I did never recommend signal to my friends, yet some of them started using it after a couple of years.
<brendyyn>It's suprisingly easy to get it working
<brendyyn>i've been wondering if its possible to run android apps on the computer emulated somehow. there are some solutions apparently but they dont work so well it seems
<efraim>shishlik?
<rekado>hmm ghc-cairo (new package I’m working on) fails to load Gtk2HsSetup, but running the runhaskell command manually in a container works fine.
<rekado>I do get the notice that “Setup.hs: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal.”
<rekado>I wonder if we should change the haskell-build-system to use --package-db instead of setting GHC_PACKAGE_PATH.
<rekado>hmm, but we already do that.
<rekado>ah, now I see
<rekado>in the configure phase GHC_PACKAGE_PATH is unset to keep Cabal from complaining.
<minji>/close
<RetardedOnion>mange: thanks for the heads up. i didnt have nix installed. it is now eating 100% of one core. so its doing something.
<mange>No worries! I tried my own suggestion earlier today and it sat for a while before eventually failing. Hopefully you'll have more luck!
<lfam>Has anyone noticed a recent slowdown in the creation of disk images? For me, the 'registering closures' step takes about 90 minutes for a very basic system
<RetardedOnion>mange: yeah no. it failed.
<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
<rekado>is the file executable?
<RetardedOnion>rekado: i chmod 777d it just to be sure. not working
<rekado>can you execute it when the full path is used?
<RetardedOnion>rekado: no
<rekado>is it a binary or a script?
<rekado>if it’s a script, is the interpreter path correct?
<RetardedOnion>rekado: looks very binary too me
<brendyyn>wow
<rekado>if it’s a binary, did you compile it yourself or take it from another system?
<RetardedOnion>i took it from another system
<rekado>if it is from another system it probably uses the wrong loader
<rekado>you can try to patch the loader with patchelf.
<rekado>but I’d urge you to compile and link it yourself.
<RetardedOnion>oh god its a pain. yeah i will just create the package.
<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.
<rekado>that’s easily done with patchelf.
<rekado>the alternative is to provide the loader (part of glibc) at the expected location.
<RetardedOnion>i want the package anyways. not the most easiest way, but i will try to build it myself
<rekado>another thing for core-updates: let all build phases in the haskell-build-system return #t.
<rekado>good luck!
<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.
<rekado>it = the MAME emulator.
<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.
<rain2>why don't you try matrix/riot.im
<rekado>GNU+Linux can run nonfree software.
<brendyyn>whatsapp uses signal from what i understand
<rain2>you can also use OTR2 with XMPP via pidgin
<brendyyn>or atleast signal comes from whatsapp
<rain2>there are a lot of good options
<lfam>Yes, whatsapp uses the same messaging protocol as signal. They hired the signal team to implement it for them
<rain2>I really recommend strongly against whatsapp, signal and telegram
<brendyyn>i was using riot then i switched to signal because it was kinda yucky to use
<brendyyn>maybe i should try going back to it
<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
<RetardedOnion>pkill9: telegram
<RetardedOnion>i need telegram to run. basically everything i do is there.
<jabranham>Installing guixsd for the first time today in a VM, wish me luck! :-)
<brendyyn>good luck
<jabranham>Tried last night but misunderstood the bios_grub flag I needed to set with GPT/BIOS so screwed up the whole install.
<Formbi>rain2: why against signal?
<RetardedOnion>Formbi: https://sandervenema.ch/2016/11/why-i-wont-recommend-signal-anymore/
<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
<rain2> https://drewdevault.com/2018/08/08/Signal.html
<pkill9>options for elogind*
<RetardedOnion>pkill9: can i just say "xlock && suspend"?
<rekado>FWIW when I close the lid of my laptop it suspends automatically; I did not need to set this up.
<rekado>(I’m using EXWM, so no fancy desktop environment)
<RetardedOnion>suspend works fine. lock with xlock doesnt
<pkill9>oh i misread your question
<pkill9>xfce by default locks your environment on suspend
<RetardedOnion>(screen-locker-service xlockmore "xlock") is specified, it still doesnt lock. using bspwm
<pkill9>s/environment/screen
<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
<mg>hej! i'd like to package following python project https://github.com/cea-hpc/clustershell
<pkill9>i guess it's a bug if the screen-locker-service isn't working
<mg>so far i managed to get an environment runnig with following definition https://pastebin.com/YMMFbeAU
<mg>however, it doesn't seem to actually build clustershell itself, rather than make just the dependencies available
<mg>how can i proceed to build clustershell itself and make it available as a package?
<mg>if i build the package it gets stored in e.g. /gnu/store/b9mn2bi524fcjqpkclzkmqqmkzhc2j7j-python-clustershell-1.8
<mg>but afterwards i can't create an environment with e.g. guix environment --pure --ad-hoc python-clustershell
<mg>it just comes back with guix environment: error: python-clustershell: unknown package
<lfam>mg: Where is the package? In a Git checkout of the Guix source code, or a separate directory?
<mg>lfam: separate dir
<lfam>Okay, you are using GUIX_PACKAGE_PATH?
<lfam>I recommend using either GUIX_PACKAGE_PATH (if planning to keep the package out of GNU Guix) or putting it in a Git checkout of the Guix source tree (if planning to add it to GNU Guix)
<mg>ok i did add the workdir to the package path but no difference
<mg>yes i'd very much like to add it to gnu guix. how would i use the git repo approach then?
<lfam>The basic workflow is to clone our Git repo, build Guix from it, and then you will be able to use Guix "from the Git repo", which makes it easy to test changes
<lfam>The documentation starts here and goes into the next section: https://www.gnu.org/software/guix/manual/en/html_node/Building-from-Git.html
<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>kk. get it.
<mg>none the less. i'm still doing something wrong when using the package path.
<mg> GUIX_PACKAGE_PATH=$PWD guix environment --pure --ad-hoc python-clustershell
<mg>guix environment: warning: failed to load '(python-clustershell)':
<mg>no code for module (python-clustershell)
<mg>guix environment: error: python-clustershell: unknown package
<mg>stat python-clustershell.scm
<mg> File: python-clustershell.scm
<mg> Size: 774 Blocks: 8 IO Block: 4096 regular file
<lfam>The file you linked to doesn't include a module definition. You'd want start with something like this: (define-module (my-packages clustershell) #:use-module (guix packages) ...)
<lfam>Then, the file would be located at $GUIX_PACKAGE_PATH/my-packages/clustershell.scm
<lfam>The module path is up to you. I just picked that one as an example
<lfam>Here is a concrete example: https://github.com/lfam/pkgs
<mg>working now.
<mg>lfam: big thx!
<lfam>Great :)
<mg>one more thing though :D
<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
<mg>ah
<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
<mg>understood
<mg>i thought of the propagation the other way round
<mg>like it is propated via the python-build-system
<mg>other than the "native" input ones
<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
<mg>hm
<lfam>For Python stuff, run-time dependencies typically must be propagated since we don't have another way to refer to the inputs after the package is built
<lfam>Run-time library dependencies, that is. If they are commands, they are typically found in PATH
<mg>reading https://github.com/cea-hpc/clustershell/issues/253 i think in the clustershell case it would be better to depend on openssh explicitly.
<mg>what do you think?
<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 :)
<lfam>Or, clustershell
<lfam>Your package reminds me that we need to address CVE-2017-18342 in pyyaml
<mg>always glad to help :D
<nckx>lfam: Herp. Thanks for fixing the kurly typo.
<lfam>nckx: Thanks for noticing the new home-page and updating it :)
<rekado>I’m trying to upgrade my Cuirass server at work, but Cuirass crashes upon start
<rekado>“Uncaught exception in fiber ##f”
<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 :-)
<nckx>jabranham: The latter.
<rekado>note that after “guix pull” you should add ~/.config/guix/current/bin to the beginning of PATH.
<rekado>otherwise you are not using the latest version when you run the “guix” command.
<rekado>“guix pull” installs the latest version of Guix into “~/.config/guix/current”
<jabranham>rekado: thanks. For the current session only or do I need to manually add that in ~/.profile or whatever?
<pkill9>i think you just need to logout and log back in
<rekado>jabranham: I’d add it in ~/.profile
<pkill9>then you'll have it added to your $PATH
<rekado>pkill9: I don’t think that’s true…?
<pkill9>it's in my /etc/profile (which i haven't edited)
<lfam>It doesn't happen automatically on GuixSD?
<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
<lfam>Yes, it happens automatically on GuixSD
<pkill9>another thing i do is make my /root readable by my user, and just symlink my root's ~/.config/guix to my user's ~/.config/guix
<rekado>sorry, I didn’t see that this is about GuixSD.
<rekado>ACTION hides
<lfam>pkill9: That works but... yikes :)
<lfam>I guess that readable is not so bad. It's actually a default in some cases. Writeable would be the really risky thing
<pkill9>yeah it's not writable
<pkill9>i'm not sure why /run/current-system/bin/guix isn't updated to latest version of guix whn `guix system reconfigure` is run
<pkill9>when*
<roptat>that's because it is a package described in ~/.config/guix/current
<roptat>unless the package definition is updated, you don't get a newer one
<pkill9>ah i see
<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 waves
<lfam>pkill9: It's not possible
<roptat>jabranham: ~/.guix-profile is your profile, where everything you need is installed. ~/.config/guix/current is another profile made especially for guix
<vagrantc>a number of folks expressed interest in guix after my talk at debconf18 ... so hopefully building a debian+guix community :)
<roptat>you can manage ~/.config/guix/current like a profile with "guix package -p ~/.config/guix/current ..."
<roptat>but really you shouldn't install anything in it
<jabranham>roptat: Thanks. Why is guix special though? Couldn't it live under ~/.guix-profile?
<roptat>the issue with guix is that it cannot be described in the same way as other packages
<jabranham>roptat: ah, OK I guess that makes sense then
<rekado>vagrantc: oh, lovely!
<roptat>because a specific version of guix can only refer to older versions
<vagrantc>also had talks with a few people about actually packaging for debian; doesn't sound as infeasible as i used to think
<vagrantc>e.g. debian policy maintainer suggested an exception for /gnu/store
<rekado>that sounds great!
<lfam>Wow, that was the major sticking point in the past
<vagrantc>so i think it's pretty much down to packaging the dependencies
<lfam>Well, that and the binary bootstraps
<vagrantc>oh, that.
<lfam>Er, bootstrap binaries. But, they can be built again :)
<vagrantc>notably, the ./bootstrap scripts seem to just run autotools and such ... or is that a different bootstrap?
<pkill9>to remove guix form the system profile, you'll need to manually create root's (or a user's, but root probably better) ~/.config/guix profile
<pkill9>from*
<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..
<lfam>Oops!
<pkill9>oof
<mbakke>I noticed by trying to build the world without substitutes! I wonder if we can use the content-addressed mirror even with --no-substitutes.
<vagrantc>what i've never wrapped my head around is ... are the bootstrap binaries needed to build from source ... or will, say, "guix pull" pull them in on it's initial run
<lfam>mbakke: I'd argue it should be allowed within --no-substitutes, if it is not already
<lfam>vagrantc: They are needed in all cases
<vagrantc>ah, that seems like a pretty big blocker, then
<pkill9>are the original upstream URLs kept in a list somewhere for package definitions that use mirror:// as a source?
<pkill9>well not neccessarily a list, but a generla record
<lfam>pkill9: The "mirrors" are defined in guix/download.scm
<pkill9>general*
<vagrantc>so then Mes is attempting to dramatically reduce the bootstrap binaries?
<demotri>jabranham: It is to decouple the package definition (~/.config/guix) from the installed packages (~/.guix-profile). You can manipulate them independent with the new guix pull. See this blog post: https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/
<lfam>vagrantc: Yes, that's the effort I mentioned
<vagrantc>ACTION gave a quick stab at packaging Mes for debian a few weeks ago too :)
<jabranham>demotri: very cool, thanks.
<vagrantc>mostly interested in trying to get a cross-distro tcc built reproducibly :)
<vagrantc>and then bootstrapping gcc from that
<pkill9>interesting
<rekado>it might be possible to reach a fix point with user-supplied bootstrap binaries.
<rekado>but I think this is non-trivial.
<vagrantc>it didn't go quite as well as i had envisioned, but there's video of it: https://meetings-archive.debian.net/Public/debian-meetings/2018/DebConf18/2018-08-03/my-crush-on-gnu-guix.webm
<rekado>maybe we’ll need a way to cut the bootstrap graph at an arbitrary point and glue it onto a provided set of bootstrap binaries.
<vagrantc>didn't get notice it was accepted until pretty late and didn't prepare as well...
<vagrantc>rekado: but even doing the rebootstrapping once would at least give a new checkpoint, so to speak
<lfam>It should at least be possible to recompile the bootstrap binaries reproducibly, in principle
<rekado>that’s already possible
<lfam>But at what point does Debian just decide to replace dpkg with Guix? ;)
<rekado>vagrantc: I like your opening remarks on the name.
<rekado>vagrantc: I have to do this a lot, too..
<rekado>.
<vagrantc>and of course, throughout the talk i switched back and forth on pronunciation :)
<janneke>vagrantc: i missed your talk, as i was travelling -- thanks!
<demotri>vagrantc: I saw the video yesterday, very nice.
<demotri>vagrantc: My favorite part was when you told that you upgraded uboot first in Guix and then later on Debian :-)
<vagrantc>i have a few "demos" prepared with "script" but didn't have the commands to reply them coming to mind on stage :)
<vagrantc>demotri: yeah ... i wanted to go into more detail about various aspects like that, considering the audience. if i had another few days to prepare, i would've expanded on that
<vagrantc>ACTION should start writing entries in one of those online journal thingies again to flesh that out
<vagrantc>anyways, catch y'all another time
<vagrantc>ACTION waves
<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.
<rekado>option 2 is probably the easiest.
<rekado>would you like to try one of these options?
<amz31>o/
<rekado>meanwhile (in order to test the GNOME upgrade) I’d pick option 2 locally.
<mbakke>rekado: Option #2 seems like a reasonable workaround if feasible.
<rekado>do you mean we should not patch Python 3.7 *at all* on core-updates? Wait for 3.7.1 instead?
<amz31>is it possible to have access to the version field of a package inside one of its phase?
<efraim>amz31: it's often used as ,version but it depends on the quoting and unquoting
<amz31>efraim: tx, it will do
<amz31>my guix pkg config doesn't find anything
<amz31>even if there is something in ~/.guix-profile/lib/pkgconfig/
<amz31>but this works: PKG_CONFIG_PATH=$HOME/.guix-profile/lib/pkgconfig/ pkg-config --variable=libdir libargon2
<amz31>/gnu/store/cx5j6h8yy134b7w8j21rxhq9b46g8x0w-argon2-20171227/lib/
<amz31>with a fixed argon2 package
<amz31>I mean I am working on arong2 package, but would like to make sure it's done right
<amz31>ok got it it's an environment variable issue, seems like the above PKG_CONFIG_PATH must be exported by bash profile
<mbakke>rekado: I think we have to fix Python 3.7 eventually, but still hoping 3.7.1 is released in time.
<mbakke>I haven't gotten any further with glibc 2.28 yet :/
<amz31>and my project runs again https://screenshots.firefox.com/MDbwtBy4Tj1iVXrQ/localhost
<mbakke>amz31: You could install pkg-config to your profile to get PKG_CONFIG_PATH configured automatically.
<mbakke>Another alternative I use fairly often is `guix environment -C --ad-hoc pkg-config [other stuffs] -- pkg-config --foo bar`.
<jabranham>hrm... is there any reason that downloading a substitute from hydra.gnu.org would be very slow (< 30KiB/sec)?
<pkill9>jabranham: that build server often has slow download speeds, berlin is usually faster though
<mbakke>jabranham: You should be using "https://mirror.hydra.gnu.org" rather than hydra.gnu.org directly.
<jabranham>mbakke: yes, I am just forgot to type the first part :-)
<jabranham>pkill9: didn't know about berlin.guixsd.org. I'll check it out
<jabranham>thanks
<amz31>mbakke: correct!
<amz31>ok the patch for argon2 is online @ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32349
<jabranham>so after installing "r" and "r-quantmod", starting R doesn't let me load quantmod. Am I missing something obvious?
<mbakke>Woah, new version of C librsvg is out.
<jabranham>ah, nevermind. Logging out and back in fixed it
<mbakke>jabranham: Did you get any notifications about environment variables? You may have to log out and in again to make R find plugins.
<mbakke>Oh.
<jabranham>mbakke: yeah, that's what I tried and it worked. Thanks :-)
<roptat>mh... guix pull on my arm board is taking forever
<roptat>it's already been 3 hours
<roptat>that's weird that it has to build anything, because I chose a commit that hydra had built...
<mbakke>rekado: I have tested the polkit update and it seems fine to me. Will be pushing shortly!
<mbakke>roptat: The way `guix publish` (and by extension Hydra) works is, when caching is enabled, the very first request to a store item will return 404, and then Guix will "bake" the archive.
<mbakke>It could be that you were the first requesting that substitute.
<mbakke>If you cancel and try again you may have better luck....or not! :P
<roptat>mbakke: ok, I'll try that
<jabranham>what's the best course of action to take if I notice a package in the guix git repo is out of date?
<mbakke>jabranham: The best course of action is to send a patch updating it! :-)
<jabranham>mbakke: I guess that's time to read (info "(guix) Contributing")
<jabranham>(that means it's time)*
<mbakke>jabranham: Yay! Feel free to ask here if anything is unclear :-)
<amz31>mbakke: the contributin section doesn't say to learn guile, does it?
<mbakke>amz31: I've been an active contributor for about two years and I still can't say I know Guile! :-)
<mbakke>ACTION goes afk for a bit
<amz31>jabranham: well i recommend you learn scheme, even if it's not the manual, even if you can create package without knowing scheme... it much less neat experience if you don't know scheme
<amz31>mbakke: meh... you are just joking right?
<mbakke>amz31: Only partially ;)
<amz31>of course you don't need to be able to hack on guile vm to contribute to guix
<amz31>ACTION looking at mbakke commits
<amz31>like, simple packages require only copy / pasting hello package
<amz31>and search and replace stuff
<amz31>jabranham: learning guile doesn't mean you must do cover to cover read of the guile manual https://www.gnu.org/software/guile/manual/html_node/
<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>jabranham: me too
<amz31>jabranham: elisp is a LISP-1?
<amz31>i don't know emacs lisp myself
<roptat>mbakke: no luck :(
<jabranham>I don't remember what LISP-1/2 means. Something about namespaces?
<jabranham>amz31: ^^^ that was directed at you
<amz31>jabranham: LISP 1 == single namespace for functions and other stuff / LISP 2 means function are not in the same namespace than other stuff
<amz31> https://en.wikipedia.org/wiki/Emacs_Lisp#Language_features
<ngz>elisp is lisp 2.
<jabranham>amz31: sounds like elisp is a lisp-2 then
<amz31>jabranham: basically, you don't need to do something special to call a function that is stored in a variable
<amz31>in scheme
<amz31>and guile
<jabranham>amz31: ah, good to know.
<jabranham>so in scheme/guile (my-variable-whose-value-is-a-function 1 2 3) will call whatever function that variable is bound to?
<amz31>yes
<amz31>jabranham: here is an error that happens very often when i code guile:
<amz31>scheme@(guile-user)> (1 2 3)
<amz31>ERROR: Wrong type to apply: 1
<amz31>it says 1 the number one is not a procedure
<amz31>well, not very often... but it's difficult error to decypher anyway
<jabranham>right, cause 1 isn't a function
<jabranham>seen something similar many times in elisp-land
<amz31>what package do you want to update? sometime it's just matter of chaing the version field string
<amz31>jabranham: do you know the following command: guix edit hello
<jabranham>amz31: not yet but I only installed guix this morning :-)
<amz31>try it ;D
<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 guix-devel@gnu.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.
<emacsomancer>which is why I can't install anything
<emacsomancer>(and probably why `guix gc` isn't working properly)