<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. <ngz>rekado_: It seems to work. Thank you. ***Tirifto_ is now known as Tirifto
<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 <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. <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>is this documented somewhere or i just do 'guix system' and go from there? <rekado>Sveta: it’s all documented in the manual <aerth>how do i find the package that contains the program X (in this case ldd) <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>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 ? <roptat>civodul, I remember someone talked about integrating guix into jupyter or creating a similar tool with guix, do you remember anything about that? <Gamayun>I've just transitioned my main computer to Guix System! -^.^- <Gamayun>Still transferring stuff back from backups and working out niggles, but no big issues so far... :-) <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? <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. <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 <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 <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 <civodul>so it's not actively developed, but definitely on my list of things to look at <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>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 <mouldysammich>Can guix pack be used to generate an executable binary similar to appimage? <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 <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>there is no hurry in addressing this. I can also take a look at this later again. <rekado>sneek_: later tell pkill9 This FHS service looks interesting. Would you like to contribute it to Guix? *vagrantc is baffled at the idea of a guix installation with FHS directories... <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? <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>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 <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>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. <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. <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 <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 :) <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 <ng0>it's just interesting. <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. <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>i guess you could configure offloading to the remote machines <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>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 <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 <rekado>vagrantc: doesn’t bash behave differently when run as /bin/sh? <vagrantc>rekado: yes, but not differently enough in some cases :) <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>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. <mfg>vagrantc: okay i will look into it. <Marlin>there is no warsow package for guix <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) <bavier>Marlin: haven't seen that game before. looks fun <Marlin>but i'll just use the source code then <bavier>many projects "recommend the binaries" <mfg>vagrantc: printf instead? <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? <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 <Marlin>yeah, there is the sdk tarball, but that includes more than the game <mfg>vagrantc: okay i'm going to use printf then :) <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 ? <b0f0>ok never mind I found it <dongcarl>:-/ Having trouble getting scons to pick up zlib... `scons` likes to be a hermit <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 :) <quiliro>Sveta: it is the way directories are aranged in Debian <quiliro>so is the definitions of where are programs, user files, etc <pkill9>it's a service I made that lets you run downloaded binaries and appimages <pkill9>which are built in a way that assumes the distro has libraries and such as specified in the filesystem hierarchy standard <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? <roptat>is there a file fol en_GB.UTF-8 in that directory? <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)