IRC channel logs

2019-05-29.log

back to list of logs

<sebboh>rekado_ or anyone, can you give me a link or something so I can read conversation about a bug that g_bor is working on, related to the openssh service not starting automatically at boot?
<rekado_>I don’t know if there’s a bug report about this.
<rekado_>g_bor[m] just mentioned something about this in this channel.
<sebboh>I didn't find something on guix-devel about it.
<rekado_>nothing specific yet.
<sebboh>ah
<ngz>rekado_: It seems to work. Thank you.
***Tirifto_ is now known as Tirifto
<abarbosa>node latest pull request = 55k
<abarbosa>jeee
<troydm>hey guys! I'm trying to install guixsd in virtualbox and as soon as I start vm with installation cd I see kmscon warning message and nothing happens, any suggestions?
<aerth>troydm: does ctrl+alt f2 show the help stuff?
<troydm>aerth: yup, I'm proceeding with manual installation on ctrl+alt F3 now, it seems that graphical installation on ctrl+alt F1 is not working for me
<troydm>aerth: I'm running latest VirtualBox 6.0.8 on a Linux Host
<troydm>aerth: also what suprised me is that ctrl+alt F2 help is viewed via emacs, which keybindings I almost entirely forgot since switching to vim some 8 years ago
<aerth>i had to manual install (baremetal amd radeon)
<aerth>how to make a proper environment for go-build-system, exported by (guix build-system go)? does anyone ave an example or maybe an -e oneliner
<aerth>this is confusing even second time around
<aerth>if only it were as simple as "guix environment hello"
<aerth>Tguix environment --ad-hoc go
***byzoni[m] is now known as cyberwolf[m]
***cyberwolf[m] is now known as byzoni[m]
<Sveta>with guix, can i create my own 'flavour' or 'blend' and share with a friend? someone did it before? is the process documented somewhere? wanna have some script to change the default set of installed applications and output a .iso
<Sveta>something similar to https://www.debian.org/blends/
<rekado>Sveta: yes, you can either share an operating-system configuration file, or you can rebuild the installation image.
<rekado>Sveta: the former is a supported use case, the other requires changes to Guix, so you need to do it from a git checkout.
<Sveta>if i share the configuration file, how will the users apply it? they will not be able to try it in a live cd, correct?
<rekado>Sveta: only if you generate an image from that configuration file.
<rekado>you can generate a VM or disk image with the “guix system” command.
<rekado>it won’t be an installer image, though.
<PirBoazo>Hi all
<Sveta>rekado, thanks, i guess the configuration file can be applied by users after they finish the install
<Sveta>rekado, quite laborious process is it? unless a sysadmin who is deploying the system on someone's computer
***reepca` is now known as reepca
<rekado>Sveta: what is your goal? To build a custom installer? Or to let people use a disk image you prepared?
<rekado>for a custom installer you need to modify how Guix builds its installer.
<Sveta>rekado: let people use a disk image i prepared
<rekado>but for generating a disk image you can simply tell Guix to build one from a configuration file.
<rekado>I would not call this “quite laborious”
<rekado>you can build the image and let others download it.
<rekado>they don’t have to even have the configuration file.
<Sveta>ok
<Sveta>is this documented somewhere or i just do 'guix system' and go from there?
<rekado>Sveta: it’s all documented in the manual
<Sveta>ok, thanks
<aerth>how do i find the package that contains the program X (in this case ldd)
<PotentialUser-73>ok
<PotentialUser-73>ok
<PotentialUser-73>je aime Camille !
<efraim>Sveta: also check the makefile in the repo for creating an iso image from a disk image
<aerth>go build system works wonderfully, cross compilation and all
<efraim>aerth: we don't have anything like 'apt-file' so I normally end up with 'find /gnu/store -max-depth 2 -type f -iname foo'
<efraim>But ldd can be found in gcc-toolchain
<aerth>efraim: ive been using /gnu/store/*foo*/bin/foo <tab>
<aerth>thanks :)
<aerth>how do i keep gcc-toolchain and go and make around, but only in an environment. without re-downloading the 128MB all the time
<efraim>Unless you run 'guix gc' it'll stick around in the store
<rekado>aerth: you can also pin that particular environment to any location with --root=/the/location
<aerth>hmm that may come in handy.. im not using it in a container but probably should be
<b0f0>emacs packages, do I install them in emacs or should instalation be done with guix install emcas-package ?
<civodul>Hello Guix!
<roptat>hi :)
<civodul>hey roptat
<civodul>the latest installer bug report is worrying: https://issues.guix.gnu.org/issue/35858
<roptat>civodul, I remember someone talked about integrating guix into jupyter or creating a similar tool with guix, do you remember anything about that?
<roptat>haha! I found it: https://gitlab.inria.fr/guix-hpc/guix-kernel/
<Gamayun>Hey guix!
<Gamayun>I've just transitioned my main computer to Guix System! -^.^-
<efraim>Congrats!
<Gamayun>Still transferring stuff back from backups and working out niggles, but no big issues so far... :-)
<pkill9>well done!
<Sveta>pardon my unprepared question again but at guix are apps spread out to /usr/lib/, /usr/share/, etc or is each app in its own directory?
<Sveta>at -> are
<rekado>Sveta: every package gets one (or sometimes more) separate directories under /gnu/store
<samplet>civodul: Just so you know, I’m preparing a patch for that URI localization bug. So far, it’s as ugly as you might expect. :p
<rekado>civodul: my emails to you can no longer be delivered. I commented on the program to build the on-line manuals; it fails to run for me.
<rekado>it aborts with a git error
<roptat>civodul, I've been playing a bit with guix-kernel, but it seems to be in a very early stage of development. Apart from the disappearance of guile@2.2.2 in recent guix versions (it crashes the kernel), I get an error with the python kernel loaded by guix
<roptat>is it still developped? should I send bug reports or merge requests?
<pkill9>shouldn't a lot of the phases which modify source code using substitute be patches?
<bavier>pkill9: depends on the nature of the modification
<bavier>some substitute values that are only known at build time
<pkill9>bavier: yea those make sense, although i would think it would make sense to maybe put them in a separate field, like "build-time-patches" or something
<mfg>hi there!
<pkill9>but i think a lot of them function as patches, but aren't treated as patches because they're scheme code rather than patchfiles, oh well
<pkill9>as in, they function as patches because they don't need to know anything at compile time
<bavier>pkill9: I think you could certainly submit patches to move such things into a source snippet.
<pkill9>i was just thinking about it because running `guix build -S package` will give you the patched source code, but if the patches are done in the build phases then it won't be patched
<pkill9>actually i'm not sure if it returns a patched source
<pkill9>and the source field does have snippets
<bavier>pkill9: it does
<bavier>or should
<bavier>'15
<bavier>oops, sorry
<bavier>defintely not a password
<pkill9>do the herd enable/disable commands persist on reboot?
<jonsger>hm guix.gnu.org doesn't redirect by default to https :(
<civodul>rekado: i did see your comment about doc/build.scm but didn't get around to addressing it yet, sorry!
<civodul>roptat: guix-kernel is very alpha, contributions welcome :-)
<civodul>i think i have a branch for that there
<ItsMarlin>hi guix
<civodul>so it's not actively developed, but definitely on my list of things to look at
*civodul goes afk
<ItsMarlin>i'm gonna work on some more ports later
<civodul>roptat: perhaps you're interested in guile-jupyter-kernel, which kinda works
<ItsMarlin>We gotta get a good solution for running binaries and appimages
<roptat>civodul, ok, thanks, I'll start by making bug reports and maybe fix some typos in the readme :p
<pkill9>ItsMarlin: i already have a solution i use, i made it into a service: https://gitlab.com/pkill-9/guix-services/blob/master/pkill9/services.scm#L302
<pkill9>you should be able to use it by adding that channel and adding "%fhs-support-service" to your system configuration
<pkill9>though it has room for improvements
<pkill9>but it works really well
<pkill9>I need to do a writeup of it
<mouldysammich>Can guix pack be used to generate an executable binary similar to appimage?
<ItsMarlin>awesome pkill
<abarbosa>pkill ftw
<roptat>mouldysammich, with a relocatable tarball, users only have to decompress it somewhere and run the binary
<ItsMarlin>pkill, what is that steam stuff on the scm file?
<pkill9>it was an early attempt at running steam, though naturally we don't want to condone running proprietary software
<mouldysammich>roptat: i see, thats pretty good
<ItsMarlin>oh
<ItsMarlin>it doesn't install steam tho, does it? heh
<pkill9>nah
<pkill9>g2g
<rekado>civodul: no problem! I just thought my email didn’t get through to you. I got a lot of mailer daemon messages telling me that my mails to you and to the mailing lists couldn’t be delivered.
<rekado>it’s very rustrating.
<rekado>there is no hurry in addressing this. I can also take a look at this later again.
<rekado>sneek_: botsnack?
<sneek_>:)
<rekado>sneek_: later tell pkill9 This FHS service looks interesting. Would you like to contribute it to Guix?
<sneek_>Okay.
<str1ngs>I create a FHS package some time ago. could be useful to someone. https://github.com/mrosset/filesystem
<str1ngs>it uses autotools
*vagrantc is baffled at the idea of a guix installation with FHS directories...
<kmicu>Rationale behind FHS is stated at https://nixos.org/nixpkgs/manual/#sec-fhs-environments 🤭
<vagrantc>so it's just another set of symlink trees back into the store to make it look like FHS for a container or something?
<rekado>yes
<vagrantc>clever
<ng0>str1ngs: have you considered the IF_AS etc macros? supposedly (I have personally not checked but had to start using them) they are more portable than simple if's etc in autoconfigure
<ng0>oops. nvm
<ng0>i've read the wrong file :D
<ng0>i thought I was in configure.ac, but it was the install file
<str1ngs>no, but this is good to know. thank you ng0
<ng0>you can read the related changes in gnunet and taler for some examples
<str1ngs>of do you mean AS_IF? I'm trying to find documentation for this
<ng0>yes
<str1ngs>btw, I hope to add gnunet support to nomad. nomad is a web browser I have been working on.
<ng0>cool. OT, but via looks interesting. do you have any documentation besides the in-source documentation via Go?
<str1ngs>no currently just in source. and via --help
<Fade>does the guixSD maintain a hardware compatibility list?
<ng0>ok.
<ng0>i think I'm really taking the hard road with plant. everyone else seems to have written code before documentation and not hte other way around. not that it's bad.
<str1ngs>ng0: it's very much WIP. it started from LFS and kinda just grew from there. but it has some interesting features and just grew from there. for example it builds packages in a rootless container.
<str1ngs>ng0: via actually predates Guix. but imho Guix superseeds via at this point.
<str1ngs>ng0: also the package declarations are machine readable/write. makes for some interesting automation
<ng0>Sound interesting, I'll give it a read :) json, interesting. I would have never considered json as a solution. I am somewhat drifting into the direction of either DSL definitions in the context of the subset of the generic PM people will have or one DLS in combination with transparent conversion between languages. I'm still looking into what's there and some of the topics.
<str1ngs>ng0: I kinda like json. the json is machine formatted so patches are very obvious. also you can substitute for yaml, toml, sexp even. also very safe since the meta data is not interpreted only the command sections are.
<str1ngs>ng0: example plan if you are intrested. https://github.com/mrosset/plans/blob/x86_64-via-linux-gnu-release/core/bash.json
<ng0>yes, I looked at that
<str1ngs>kk nice that someone has looked at it
<str1ngs>but at this point, Guix is superior. when I started via, the idea of functional input and outputs did not exist.
<ng0>i think there's no one goal which fits everyone.
<ng0>but of course it's nice for you when guix is starting to rid yourself of work
<str1ngs>this does have some good use cases. like for example I ported to power8/power9 in a day.
<str1ngs>yes, I am happy if Guix replaces via it's much less work for me.
<str1ngs>and I hope to maybe port some features over to Guix. like rootless cgroups
<Fade>i'm wondering what the sanctioned method is to get accelearated GPU support on AMD and nVidia hardware. I'm seeing a lot about how proprietary software is verboten on the official channels, but nothing about how to actually make any of this hardware work.
<ItsMarlin>usually using vesa graphics and such
<ng0>oof. i am getting first hand experience with how terrible npm is.
<ItsMarlin>some gpus CAN'T properly work without the firmware
<ng0>do you get this on guixsd too that some packages hardcode OS ranges?
<ng0>because I have to cheat my way around some on netbsd
<str1ngs>OS ranges?
<str1ngs>you mean say via autotools?
<ItsMarlin>you can make your own packages to get your hardware working. some people put those on repos, you might find some over the internet
<Fade>the npm ecosystem is a dumpster fire.
<ng0>os compatible: linux, bla, foo,
<str1ngs>for autotools packages you can sometimes update config.guess
<ng0>yeah npm isn't autotools but I think you know that :)
<str1ngs>oh, never mind lol
<ng0>for nodejs-sqlite3 i had to make a symlink from python3.7 to python in my $PATH. and our small university project pulls in like 80.000 packages now
<str1ngs>that's what you get when web developers decide to do systems programming lol
*str1ngs hides
<ng0>it's just interesting.
<Fade>:/
<str1ngs>npm packages also get hit by back doors
<janas>Idk if it's a problem with npm specifically or just how the culture around it developed
<str1ngs>I agree, I think its more the ecosystem
<rekado>Fade: if the hardware works with Linux libre it should also work on Guix.
<rekado>Fade: known-to-work hardware can be found on h-node, for example.
<ng0>str1ngs: i was ready to push an sqlite3 solution for the reactjs project, but then they told me they want mongodb because the prof could ask about that in the oral exam
<ng0>workload is roughly 300% more than the course stated. good job :)
<Fade>rekado: are you using guix as your daily driver?
<str1ngs>ng0: that's a pain. I would go for sqlite3 myself
<rekado>Fade: yes, on pretty much all my machines: laptops, desktops, servers.
<rekado>Fade: many of us here do.
<tune>anyone managed to get tmux-resurrect working on guix system?
<tune>I rebooted for the first time in a month and then remembered I can't restore a saved tmux session on this machine
<katco>how are folks mirroring substitutes for their local networks? i'm approaching the point to where i feel bad directing so much traffic to guix :|
<tune>hm actually I think tmux-resurrect is working for me now. maybe has to do with enabling more env var stuff
<bavier>katco: though I haven't done it yet, you can set up substitute servers on your local machines, and then point them all at each other
<katco>bavier: last time i considered doing that, i was looking at exposing 1 machine's store? all of my machines are the same arch, so i was looking at making one machine the store, and then all the other machines would request builds from there. are cross-linked substitution servers the preferred way? or is what i described weird?
<rekado>katco: you can use guix publish to share substitutes.
<rekado>the store of the machine running “guix publish” would be exported and can be used as a substitute server.
<katco>rekado: that might be what i was looking at doing. is that a sane way to share substitutes for a network?
<katco>rekado: and is there a way to request that store to perform builds from remote machines?
<vagrantc>it's more-or-less the same mechanism that guix uses to share substitutes anywhere
<vagrantc>the latter part not so much
<vagrantc>or i'd be happy to know otherwise
<vagrantc>i guess you could configure offloading to the remote machines
<vagrantc>and not allow local builds?
<vagrantc>thing that's always been weird to me about offloading though is both the remote and local machine need to trust each other...
<katco>in my case, they're all machine directly in my control, on a private network, so i'm good with that
<vagrantc>would be nice if you could only trust the substitute server
<vagrantc>and just requires builds ...
<vagrantc>sure, just you need to have all the machines trust the substitute server and the substitute server trust all the machines
<vagrantc>just more configuration to manage when adding new machines
<mfg>is there a portable shebang which works on guix _and_ other distros?
<mfg>for bash in this case
<rekado>mfg: there’s only /bin/sh
<mfg>hm k then i will have to work with that :D
<mfg>i see this is a symlink to bash?
<kmicu>mfg: I recommend ‘#!/usr/bin/env bash’. It works on GuixSD (with enabled service for that), NixOS and many traditional distros.
<rekado>but it’s not guaranteed to work on Guix systems.
<rekado>only when the /usr/bin/env is installed, which is a choice on Guix systems
<vagrantc>you need to watch out for some shell-specific issues when using /bin/sh ... not all shells behave the same when called as /bin/sh
<rekado> /bin/sh, on the other hand, is guaranteed to be available.
<kmicu>And to be anything. That’s a trade-off.
<rekado>you can use that /bin/sh thing to search for other stuff in the environent and pass execution
<mfg>as long as its POSIX compatible i'm good
<vagrantc>mfg: then you probably don't want to use bash as /bin/sh
*kmicu is a heavy dash user and /bin/sh pointing to bash is annoying as hell 😺
<katco>vagrantc: thanks for your thoughts re. substitutions
<g_bor[m]>hello guix!
<rekado>vagrantc: doesn’t bash behave differently when run as /bin/sh?
<g_bor[m]>what should create the shepherd socket?
<vagrantc>rekado: yes, but not differently enough in some cases :)
<rekado>heh
<rekado>g_bor[m]: shepherd itself, no?
<mfg>i haven't reached those cases yet i guess ;D
<vagrantc>rekado: there are POSIX grey areas where implementation is ambiguous
<vagrantc>mfg: run tools like checkbashisms on your code and that should catch most things
<g_bor[m]>it seems to me that the socket is created with a noticable delay. I can log in just fine, but can't run herd commands, and the socket is create later, and after that it works fine. Is this normal?
<mfg>vagrantc: is that available in guix?
<rekado>g_bor[m]: I don’t think so. Have you looked at the code yet?
<g_bor[m]>vagrantc: thanks for packaging guix for debian. I've just read the mail with status report.
<vagrantc>mfg: i don't see it ... in debian it's in devscripts, which is a pretty debian-specific package
<kmicu>vagrantc: or link /bin/sh to dash and start crying cuz everything is broken ;)
<vagrantc>g_bor[m]: we'll see if it gets anywhere :)
<vagrantc>kmicu: yes, then you have other issues
<g_bor[m]>rekado: not yet, I will do so later:)
<vagrantc>the problem is really that /bin/sh isn't exactly defined
<kmicu>Friendly reminder that Bash still has in its man page this gem ‘BUGS It's too big and too slow.’
<str1ngs>vagrantc: I hope it does get somewhere. because that would be quite useful.
<Marlin>hi guix
<bavier>hello Marlin
<mfg>vagrantc: okay i will look into it.
<Marlin>there is no warsow package for guix
<Marlin>i'm gonna cry
<Marlin>and port it ofc
<Marlin>oh, how can i port tarballs to guix?
<Marlin>i know how to do it to source code files that have make instructions
<Marlin>but how about tarballs with binaries?
<vagrantc>mfg: it will mostly work, it's a relatively small number of things to watch out for
<bavier>Marlin: more difficult, much easier to build (and preferred for upstream inclusion)
<vagrantc>mfg: avoid using "echo" :)
<bavier>Marlin: haven't seen that game before. looks fun
<Marlin>warsow recommends the tarball
<Marlin>but i'll just use the source code then
<bavier>many projects "recommend the binaries"
<mfg>vagrantc: printf instead?
<vagrantc>mfg: yeah
<mfg>alright
<vagrantc>mfg: simplest example is "echo -e" in dash vs. bash
<Marlin>although i have no idea where the source code i s heh
<vagrantc>mfg: bash interprets the -e as an argument, and dash outputs it
<mfg>vagrantc: but it is in both cases a shell built-in?
<bavier>Marlin: is it the "sdk" tarball at http://slice.sh/warsow/ ?
<vagrantc>mfg: yeah, that might be the difference between bash having it as a built-in and dash calling out to echo
<bavier>seems like they have a habit of moving artifacts around
<vagrantc>mfg: but just use printf. :)
<Marlin>yeah, there is the sdk tarball, but that includes more than the game
<mfg>vagrantc: okay i'm going to use printf then :)
<bavier>Marlin: this github might help: https://github.com/Warsow/warsow-root
*mfg goes offline
<dongcarl>Has anyone tried packaging `nsis` for Guix?
<b0f0>'guix import elpa -a melpa weechat' this command makes a package, is there a way to build this form file ?
<bavier>dongcarl: not that I've heard
<b0f0>ok never mind I found it
<dongcarl>:-/ Having trouble getting scons to pick up zlib... `scons` likes to be a hermit
<Sveta>rekado: ok, thanks
<pkill9>s
<sneek_>Welcome back pkill9, you have 1 message.
<sneek_>pkill9, rekado says: This FHS service looks interesting. Would you like to contribute it to Guix?
<pkill9>rekado: ah nice that you find it interesting, yes I would like to if there's interest :)
<Sveta>what's fhs?
<pkill9>filesystem hierarchy standard
<quiliro>Sveta: it is the way directories are aranged in Debian
<quiliro>and most distros
<Sveta>oh ok.. what's fhs service?
<quiliro>so is the definitions of where are programs, user files, etc
<quiliro>never heard that
<pkill9>it's a service I made that lets you run downloaded binaries and appimages
<quiliro>oh!
<pkill9>which are built in a way that assumes the distro has libraries and such as specified in the filesystem hierarchy standard
<quiliro>by the way...for activists: https://freeolabini.org
<b0f0>'propagated-inputs' and emacs-s blongs to it. Is this how a dependency is specified, meaning emacs-s is a dependency package for emacs-weechat package ?
<b0f0>ok how do I specify a dependency in pa package.scm ?
<dutchie>why am i getting errors like "/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)"? I have LANG set to en_GB.UTF-8
<roptat>dutchie, can you check the value of GUIX_LOCPATH?
<dutchie>$HOME/.guix-profile/lib/locale
<dutchie>I have glibc-locales installed
<roptat>is there a file fol en_GB.UTF-8 in that directory?
<roptat>for*
<dutchie>there is a subdirectory for it under $GUIX_LOCPATH/2.28
<roptat>ok, does /gnu/store/.../bash use glibc-2.28?
<roptat>(you should be able to check with just file)