<sneek>apteryx, raghavgururajan says: Thanks for pushing the patch. Btw, I tested it on master and the application worked fine. I did not get Mesa related errors. I tested by `./pre-inst-env guix environment --ad-hoc linphoneqt --pure` and `linphoneqt &`.
<apteryx>raghavgururajan: I'll try to see if we can install that default ring sound file.
<apteryx>hm, well the file is not included in the package source files.
<raghavgururajan>apteryx Cool! Btw, I still think it is better to change just package name of liblinphone to linphone. Because, 1) Upstream have not renamed the released source directories yet, as qt-version is still in heavy developement. 2) The working linphone client in master is currently liblinphone, and user has to execute by using `linphone &`. So just changing package name (not variable name) to linphone is g
<leoprikler>next question: what do I do if that doesn't spawn?
<leoprikler>It appears ssh-service-type runs, but I can't switch VTs and there's no login prompt on VT1
<craftyguy>I just started reading about guix, and I'm wondering where I can find out more info on how packages are updated in the distro. several blogs list 'no need for package maintainers' as a perk for guix, but a number of packages on guix.gnu.org/packages are out of date compared to upstream. who updates them if there are "no package maintainers"?
<brendyyn>craftyguy: anyone can at any time. they packages supported grows as the community as a whole grows
<craftyguy>1.17 was from March 2019, 1.20 is out now. how does one update that package for all guix users?
<craftyguy>(I don't actually have guix installed.. yet. I'm just a long time arch linux user trying to learn more about how this distro works because it's shiny and new :D)
<brendyyn>for wayland im unsure. you see updating wayland would update over 1000 other packages
<brendyyn>basically you would download the guix git repo, make a patch, test it and email to email@example.com
<craftyguy>yeah, that's why I picked it. it's >1yr out of date, and lots of things depend on it
<craftyguy>I see, does a human review/accept the patch in that mailing list?
<brendyyn>yes there are 40+ volunteers with commit access i think
<craftyguy>oh ok, so there are maintainers of the package repo, but not necessarily 'official' maintainers for individual packages. or something
<craftyguy>brendyyn: thanks. back to more reading I go :)
<brendyyn>yes. civodul believed it may create barriers to contribution if there were such "official" maintainers. there are people that care closely about certain packages and may be effectly maintainers of it
<brendyyn>for core packages like gcc and bash etc updating them is done in a separate branch like core-updates.
<craftyguy>That's actually quite similar to the way Alpine Linux is run. There are package maintainers that 'keep the ball rolling', but they also accept patches from anyone that wants to update something, provided it passes review and build test
<brendyyn>wayland im unsure about. you could ask on guix-devel
<rekado>you can provide a patch for the core-updates branch
<PotentialUser-60>My system reconfig failed with this error: /gnu/store/gwgjamz3svc2q72piyx1fhbyz2yp85pj-grub-efi-2.04/sbin/grub-install: errore: /gnu/store/gwgjamz3svc2q72piyx1fhbyz2yp85pj-grub-efi-2.04/lib/grub/i386-pc/modinfo.sh non esiste: specificare --target o --directory.
<PotentialUser-60>The error was launched by this: grub-install --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi/
<thvk-ivgf>PotentialUser-60: please paste.debian.net your sys. config.scm
<xelxebar>lfam: In a previous discussion, you mentioned that there is an existing issue on the tracker related to the delay between package downloads. For the life of me, I can't seem to find it. Would you happen to have a link?
<mbakke>PotentialUser-60: that error means that you are using 'grub-efi-bootloader', but your system has booted in "BIOS mode"
<lafrenierejm>Anyone available for TeXLive help? I'm testing a recipe I wrote for https://www.ctan.org/pkg/moderncv, but I get the error "File `ifluatex.sty' not found" when attempting to compile a sample tex file with pdflatex. How would I go about finding out which CTAN package profides `ifluatex`?
<g_bor[m]>civodul: I have a feeling for a while... it goes like this: the packages part of guix could be reduced by a huge amount in the following way:
***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
*raghavgururajan thinks about creating ready-to-use VM images (generated from configs based on civodul 's idea), where it can be run on VPS, SBC etc. This establishes decentralized communication channels very fast.
<g_bor[m]>Have the output of a recursive importer as a fixed output derivation.
<g_bor[m]>Have also a diffset as a fixed output derivation.
<g_bor[m]>And use the resulting set of package definitions as a channel
<civodul>g_bor[m]: heh, it's tempting, but the work we do "manually" also includes curation work, QA, license checks, etc.
<civodul>but "someone" could do that for Node/JS, for instance
<civodul>or just do the on-the-fly import we've discussed before
<civodul>also, importers don't work for cross-language packages: Jitsi (Java+JS), Mattermost (Go+JS), etc.
<divansantana>what to do for binaries that are looking for /bin/bash (guessing). like this -bash: ./vagrant: No such file or directory
*divansantana hoping to get vagrant working this way on #guix.
<g_bor[m]>civodul: yes, I was not proposing this as a replacement, but instead as an automation mechanism. It could do a lot of the more laborous but boring stuff, and we could do all what we have been doing in the diffset.
<civodul>divansantana: if you're working on a package for Vagrant, the patch-shebang phase should take care of it
<thvk-ivgf>divansantana: aren't there 'bash:' telling that it can't find ./vagrant?
<civodul>g_bor[m]: i guess Someone could give it a try and see how well it works
<divansantana>civodul:unfortunately not working on a package. Just trying to get a quick win to get it to work on guix.
<ngz>Hello. I have a (mostly) working Guix installation on top of Debian, but it seems that late installation scripts do more advanced configuration than they used to. In order to test new installation script, is it possible to run it on top of an installed Guix?
<bricewge>I have around 25% packet loss on my part
<vincelevi>hello lle-bout, I am also on free, and also experiencing slowness in dl'ing guix substitutes, so I'm trying mtr, and it also shows significant loss on one of free's routers along the path...
<lle-bout>I have Xavier Niel's phone number just in case.. maybe that could help
<vincelevi>65% loss on : p11-crs16-1-be1109.intf.routers.proxad.net
<lle-bout>alextee[m]: that's a website, not ungoogled-chromium
<lle-bout>you can always install Ublock Origin or something to block those annoyances I guess, but yeah it's not default yet on GNU Guix. I'm certain you can submit a patch to install Ublock Origin by default it would be great.
<alextee[m]>o.o so jitsi wants me to install google calendar? weird
<sarg>I've noticed that in my guix on top of debian setup, qutebrowser doesn't use pulseaudio to output sound. When I start the browser - I see Cannot open shared library libasound_module_conf_pulse.so (/gnu/store/nyylgcnzmbw8wrn4sna2crl0g7zxxh33-alsa-lib-1.2.2/lib/alsa-lib/libasound_module_conf_pulse.so: libasound_module_conf_pulse.so: cannot open shared object file: No such file or directory)
<bavier`>I've had a good experience with brasero in the past, but some things are broken in the guix package
<lfam>It turns out that it's possible to read an audio CD and get files that sound good but they don't actually reflect what's on the disc. It's a tricky early-digital implementation with plenty of room for error while reading
<apteryx>lfam: I don't get it. Digital files are either successfully read or not at all. It's not like there's some analog to digital conversion or vice versa going on. Or perhaps you are discussing the merits of various audio compression technologies/settings, and that some rippers have better defaults in that regard?
<lfam>I don't see the error when starting qutebrowser either
<lfam>apteryx: No. It's more complicated than that.
<lfam>With CDs, it's obviously possible to fail to read the data due to scratches. But there is a lot of error correction built in to work around this. And it can actually misread but still pass the primitive checksumming in use
<lfam>Remember... audio CDs were designed in the 1970s
<sarg>lfam: could you please check that qutebrowser's stream is visible in pavucontrol?
<reepca>technically that can happen with any checksum, it's just lower-probability with modern ones
<lfam>At the moment I can think of any solid citations apteryx, but they do exist
<lfam>Audio CDs are a really interesting example of cutting-edge digital technology at the very beginning
<reepca>(where "modern" here means "more bits of redundancy")
<lfam>You're right sarg, it's not showing up there
<apteryx>lfam: Ah, so it's about the performance of the error correction (recreating missing parts). So your argument is specific to the case where the input data (the CD) is damaged to start with, if I'm following.
<lfam>Yes, basically. But sometimes the CDs were burned poorly
<sarg>guixsd installs /etc/asound.conf where paths to pulse plugins are specified. I've tried to install alsa-plugins:pulseaudio and create this file manually. Now I get another error and still no sound output :()
<lfam>There is at least one commercially sold CD that crashes CD players!
<lfam>Not on purpose, it was supposed to contain music
<cbaines>davidl, I'd be careful with the bundler package in Guix though, if you downloading things from Rubygems anyway, you might be better off gem install'ing bundler. That avoids issues with Ruby versions.
<cbaines>davidl, I usually use the direnv "layout ruby" to keep rubygems things contained
<cbaines>that works nicely with use guix --ad-hoc ruby
<davidl>cbaines: Im not very familiar with direnv unfortunately. The main thing Im trying to do is to serve the docs folder as a jekyll website (from some nbdev template), so I need to cd docs ; bundle install ; jekyll serve - but Im failing the dependencies in the Gemfile. For now I think Ill try without direnv. I have: export GEM_HOME=/home/myuser/gems which let me use bundler succesfully, and now it seems
<davidl>to work after I removed the guix version of these packages.
<ecbrown>rekado: i submitted a new patch to bug#40696
<emys>hi, how can I find out the recipe used for a package? Let's say I want to have a look at how `python-isort` or `python-numpy` have been packaged
<emsyr>efraim: about the enlightenment apps menu problem I wrote about a few days ago. I looked it up today, followed your instruction, deleted ~/.cache/efreetd and did the trick. Now I can lunch apps from enlightenment's menu.
<roptat>didn't work: ice-9/eval.scm:293:34: In procedure string-append: Wrong type (expecting string): #f
<ngz>I get this : "gnome-session-binary: GLib-GIO-ERROR: No GSettings schemas are installed on the system" when launching Gnome (after GDM prompt) on a foreign distro, and cannot log in. It disappears if I unset GI_TYPELIB_PATH. Does that ring a bell?
<ngz>I can log in if I unset both GI_TYPELIB_PATH and XDG_DATA_DIRS, more precisely.
<carapace>I'm using the GNU Guix 1.1.0 QEMU Image from the https://guix.gnu.org/download/ page. I can download the installation ISO, mount it, and look in there, of course but is there a config.scm in the qemu vm image?
<carapace>In the manual under 8.16 Running Guix in a Virtual Machine it says "You can also reconfigure the system based on its initial configuration file available as /etc/config.scm" but I'm using the pre-built Guix VM image and that file doesn't seem to be there.
<civodul>carapace: yes, it's a bug that we've now fixed on master
<roptat>do you need non free software for it to be useful at all, or can it be used on a completely free system?
<roptat>civodul, re-running make with strace now, it will take some time...
***atw` is now known as atw
<ngz>Still trying (sorry) : does the error shown there https://paste.debian.net/1141418/ which prevents Gnome from starting, ring a bell somehow? This happens on Debian stable and is fixed by setting both GI_TYPELIB_PATH and XDG_DATA_DIRS to an empty value in ".profile".
<rekado>ngz: these variables can tell an application to load incompatible binaries
<rekado>it’s a real problem, not only for Guix software on foreign distros but also for foreign distro software when Guix sets these variables.
<rekado>generally, I think that we need to isolate Guix more by never setting any variables (other than PATH) that haven’t been prefixed with GUIX_
<rekado>this would require patches to a lot of applications, though
<lfam>pinoaffe: What do you mean by "interacting with proprietary software"? Do you mean online services?
<ngz>rekado: But when I unset XDG_DATA_DIRS, my foreign Gnome does not have access to Guix installed applications. I don't know what I'm losing by unsetting GI_TYPELIB_PATH, tho.
<rekado>we’ve got a similar problem with PYTHONPATH which cannot be shared between Guix applicaitons and software provided by the foreign distro
<g_bor[m]>rekado : i agree with the isolation you proposed.
<rekado>if only we could do some more magic with environment variables and make the lookup non-global
<ngz>Oh. So everyone's Gnome is crashing on foreign distros? oO;
<g_bor[m]>this would also mean that the foreign distro Gnome would not see guix stuff by design. And also that the guix gnome would not see the foreign disto gnome by design. They would live in complete isolation...