<rekado>I just finished adding support for submitting issue comments on issues.guix.gnu.org. <mbakke>mfg: right, I don't know how to do that, though it's probably possible <mbakke>rekado: woah! and they will get sent to debbugs? <mbakke>it would be neat if modify-services could delete services by name <mbakke>NieDzejkob: good question, did not think that far <noobly>i think my problem may have something to do with network manager, how do i stop this process permanently on guix? <noobly>NieDzeejkob, that killed it, thanks so much <noobly>crossing my fingers that my problem was as simple as that <mbakke>oh my, what happened with cross-libc on 'master'? merge conflict galore! <mbakke>oh, commit 524a4e357cd71566841aaf405e8548fa3600b11b happened. <noobly>NieDzejkob: looks like that did it, i owe ya one <janneke>sneek: later tell civodul: see drafts, please edit+release if you like. <vagrantc>even the bots are treated nicely around here :) <ngz>I encounter a problem during the validate-runpath phase of a program. Build fails because a library cannot be found in RUNPATH. Yet, I added $out/lib to CMAKE_INSTALL_RPATH. Any idea about what could go wrong? <mbakke>ngz: is the missing library present in $out/lib? <noobly>i try to build a package but get 'no code for module (gnu packages rust-apps), how do I remedy this? rust-apps is not a package <ngz>mbakke: It is present in the failed build directory (I built it with -K), under "lib/". <ngz>noobly: Add #:use-modules (gnu packages rust-apps) at the top of the file, in `define-module'. <mbakke>ngz: try grepping for RPATH in the CMakeLists.txt's, perhaps the package ignores the configure flag <noobly>ngz, it is indeed there, my bad for not specifying. it still returns that error <noobly>it's with a long list of other use-modules, it just gets hung up on that one <mbakke>noobly: try deleting gnu/packages/rust-apps.go <mbakke>noobly: you building from a git checkout, right? <noobly>don't laugh but i only have gnu/store, not gnu/packages <mbakke>noobly: how are you building the package? <noobly>`guix package --install-from-file=firefox.scm` <mbakke>noobly: what is your 'guix --version'? <noobly>mbakke, 1.0.1. thanks for the help <mbakke>noobly: you'll need to 'guix pull' then, (gnu packages rust-apps) was added December last year <ngz>mbakke: hmm. The missing libraries appear in $out/lib/OGRE, not in "out/lib". There's "-DCMAKE_INSTALL_RPATH=" out "/lib/OGRE", but it seems to be ignored. <mbakke>ngz: you can separate multiple entries for CMAKE_INSTALL_RPATH with ";" - not sure if that helps if it ignores the argument though <ngz>As I see, it does set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${OGRE_LIB_DIRECTORY}"). This basically means "la, la, la, I don' hear you". <Parra>civodul: I've tried and it rebuilds, it always does that I don't know why <ngz>So, I probably need to do force the substitution right into the CMakeLists.txt file <mbakke>ngz: or delete the line from CMakeLists.txt <mbakke>ngz: you will be able to pass -DCMAKE_INSTALL_RPATH in #:configure-flags instead <ngz>hmmm ok. Let's try that. <ngz>mbakke: Build process at 90%, we're soon going to know if you're great... or not ;) <ngz>mbakke: OK. You're great. <mbakke>so I've merged master into core-updates, but a test in tests/packages.scm fails, not great :-/ <mbakke>will wait for civodul's opinion before pushing, probably should not be merging branches after midnight anyway :P <lfam>Good work mbakke, I'm trying it on my systems now <lfam>I think there are some spurious build failures on berlin, mbakke ***wxie1 is now known as wxie
<mbakke>lfam: there are thousands, most apparently due to timeouts on the sqlite db lock ***wxie1 is now known as wxie
<apteryx>rekado_: I'm a bit confused that the nfs client asks for statd to be running (on the client). <apteryx>it says: mount.nfs: rpc.statd is not running but is required for remote locking. Either use '-o nolock' to keep locks local, or start statd. <apteryx>There doesn't seem to be a way to start just statd? <pkill9>so the core-updates mailing list message about what's new says that it will mean guix runs natively on the Hurd. Does this mean we will be able to replace the kernel with the Hurd? <pkill9>or is it changes that make it technically possible, but implementation still needs to be worked out? <xelxebar>brendyyn: Unfortunately, no, I did not save the error message. I have the irc logs, so at the very least could share the single line I previously sent here. <apteryx>pkill9: you'll be able to run guix on the hurd natively. Lots of packages will need to be ported to make the ecosystem more useful. <apteryx>(but given that debian has more than 75% of its package collection building for Hurd, we'll get there) <pkill9>what kind of packages will need porting? <apteryx>everything that needs patches to build. Could be IceCat. Could be Emacs. Could be anything, really :-) <apteryx>rekado_: the quick and dirty thing to do would be to run the whole nfs-service on the client as well. Ideally we should be able te extract rpc.statd to stat that alone. I'll put a note on my todo. <brendyyn>xelxebar: we both had the same error though right? we might of just had two problems coincidently at the same time <xelxebar>It's possible. You did mention that you were getting the same error though... <xelxebar>Just a sec, I will do a pull now and see what happens <xelxebar>brendyyn: unfortunately(?), guix pull Just Worked this time <xelxebar>Wish I could help you more. Are you trying to figure out the root cause? <brendyyn>xelxebar: can you check `sudo dmesg'. Are there any suspicious looking errors in there? <xelxebar>grepping for the obvious strings doesn't turn up anything suspicious ***wxie1 is now known as wxie
<xelxebar>Only something about urandom ratelimiting and pcspkr driver already being registered <apteryx>rekado_: herd invalidate nscd is a good trick in the times we're in. Couldn't we make it more lenient by default, to flag a host as "invalid"? <raghavgururajan>apteryx Before hacking on tests for belle-sip/mediastreamer, shall we try to finish off the linphoneqt? :-) <GuixGuy>Greetings, I see that Linux-Libre-5.6.2 is in Guix-Master but it doesn't pulldown with guix pull? <brendyyn>GuixGuy: it has not yet been set to the default. in gnu/packages/linux.scm you can see the line (define-public linux-libre linux-libre-5.4) <vagrantc>GuixGuy: yeah, there are only a small number of linux-libre packages using 5.6.2 so far <brendyyn>i have set it manually and build and reconfigured with the 5.6.2 kernel already. you can either wait or you can set it in your operating system definition. i haven't tested it but you should be able do something like (kernel linux-libre-5.6) <rekado_>sneek: later tell apteryx We should add a separate statd service then. Hard to test this because server and client are the same in the system test. <vagrantc>brendyyn: i did just disable the borked linux-libre-5.6 packages that it was accidentally building <vagrantc>oh, i should update the patchset with that change <brendyyn>although there are other things like linux-libre-headers that need to be set too *vagrantc had kind of assumed setting the default wouldn't build all the variants <brendyyn>why is it that the kernel is 5.4, but the headers are 4.19.56? <vagrantc>the headers are generally backwards compatible but not necessarily forwards-compatible <vagrantc>so building against old headers is usually fine, but vice-vera could have issues <brendyyn>you mean forwards compatible but not backwards compatible? *headspin* <vagrantc>depends on which direction you're looking from :) <vagrantc>from the thing using the headers vs. the thing providing them <vagrantc>hopefull will get some more feedback about switching to 5.6.x soon <vagrantc>GuixGuy: as for applying patches, see the guix manual ...are you familiar with git? <brendyyn>GuixGuy: you would need to clone the git repo then download the patch from 40190 into the repo, use git to apply it, then build the git repo. then you can reconfiugre with ./pre-inst-env guix ... <GuixGuy>I see. I started using git about a week ago so I will check out the manual for further info <vagrantc>really relieved to find the RTC issue with rockchip systems (veyron-speedy/pinebook-pro) <brendyyn>ive been running on 5.6 and so far nothings gone wrong, and my webcam works now that was broken before 5.5 <vagrantc>brendyyn: what did you use for a kernel configuration? <brendyyn>i just applied the patch on the mailing list and changed nothing <noobly>so after running guix pull, I'm now getting a `guile: warning: failed to install locale'. any idea where to look next? <vagrantc>brendyyn: feel free to chime in about it on the bug, i guess :) <brendyyn>vagrantc: is it useful if I simply mention it's working for me? <raghavgururajan>sneek, later tell apteryx: For linphoneqt testing, please use new patch v7. <vagrantc>brendyyn: even better if you mentioned that it fixed your webcam :) <lfam>noobly: It will go away after you upgrade everything <noobly>lfam: sorry, but do you hav a command in mind? <lfam>Upgrade your installed packages, upgrade the guix-daemon, and upgrade and reconfigure if you are using Guix System <noobly>lfam: Yes I'm using guix system. I was wrongly under the impression guix pull upgraded everything - is there a command that just upgrades all my packages and daemons? <apteryx>rekado_: nevermind about statd being required on a client. There was a ridiculous amount of confusion going on, due to me moving a WiFi USB adapter to a different machine and my AP being configured to set the IP of that machine based on the MAC address of that adapter. Phew. Everything works perfect. Thanks a ton for the nfs-service-type! <sneek>Welcome back apteryx, you have 2 messages! <sneek>apteryx, rekado_ says: We should add a separate statd service then. Hard to test this because server and client are the same in the system test. <sneek>apteryx, raghavgururajan says: For linphoneqt testing, please use new patch v7. <lfam>noobly: To upgrade the packages your user has installed, use `guix upgrade`. To upgrade the system, including the daemon, do `guix pull && guix system reconfigure /etc/config.scm && reboot` as root <noobly>lfam, thanks! running the guix system reconfigure command now as root, hopefully hat upgrades and clears up the locale issue <lfam>Make sure you `guix pull` as root or run the reconfigure command with `sudo -E` <lfam>Otherwise it won't actually upgrade you <noobly>lfam, oh shoot. i ran guix pull with normal permissions originally, I'll rerun it now <noobly>on second thought i think i'll just do the sudo -E reconfiguration, thanks for the help *jsoo finally has startx without display manager <jsoo>i learned something about services. though i think i could still use some more knowledge. <jsoo>what does the compute field of a service-extension mean? <xelxebar>How can I figure out what object in the store /etc/config.scm comes from? <xelxebar>(simple-service 'config-file etc-service-type `(("config.scm" ,this-file))) <xelxebar>Or better yet, where should I look to figure out what this line in config.scm is doing? <jsoo> what do you mean xelxebar? <jsoo>does /etc/config.scm contain your system definition? <xelxebar>Yes. And it also contains that simple-service line. /etc starts out empty and gets populated somehow, I'm trying to figure out what copies the config to /etc/config.scm and where in the store the original object is. <xelxebar>Well, the "what" is sort of answered by that simple-service line. I'm just trying to find out where the original is <jsoo>have you tried guix system list-generations xelxebar ? <jsoo>that will tell you which configuration a generation was built from <jsoo>and that will indeed be in the store <xelxebar>Um.. perhaps that came out jumbled. The guixsd vm and iso images contain empty /etc directories by default; however, after booting /etc/config.scm exists, thanks to that simple-service line above. <xelxebar>jsoo: Nice. That looks exactly like what I want. Thanks <jsoo>i think there's a file in /run/current-system that also points to the current <xelxebar>Still getting a hang of the basic ropes here <jsoo>that's a cool idea to add the current config as a skeleton of sorts into a vm xelxebar. <jsoo>xelxebar: you can follow the link in /run/booted-system/configuration.scm and that should have your current configuration <xelxebar>jsoo: What about for a non-booted system? <xelxebar>Perhaps I could point guix to a mount point or something? <xelxebar>Yeah, I'm trying to hang together all the pieces to make a guixsd Google Compute instance. <jsoo>there is also /run/current-system/configuration.scm <jsoo>those will i think always be there <jsoo>gotcha. well i probably don't understand that bit of running guix well enough to say. hopefully the guix system commands can help you out enough. <xelxebar>No worries, thanks for the pointers so far <xelxebar>Okay, here's another one, are there moral equivalents to dpkg-query -L and dpkg-query -S, i.e. I'd like to find out what files (outputs?) a package provides as well as do a reverse search on these. <xelxebar>In particular, I am trying to figure out what packages lets one do 'herd start cow-store' <Veera>xelxebar: dpkg -L :: guix package --list-installed=pkgname; find /gnu/store/shown/path <xelxebar>Veera: Oh right, dpkg-query -S only looks in installed packages. I want to look for a package which provides something yet to be installed <Veera>xelxebar: I do not know of way for that. Using Guix for a month <Veera>xelxebar: you can git clone the guix.git repo from savannah. It has all the available current pkg definitions in it <efraim>I think you're thinking of apt-file <vagrantc>xelxebar: there's not really a way to search files, unless guix data service has implemented them <vagrantc>not seeing anything obvious exposed at data.guix.gnu.org <xelxebar>vagrantc: Hrm. So say you want the ip command and don't know that it comes from the iproute2 package, is there a standard recourse? <vagrantc>i have sometimes done ls /gnu/store/*/*bin/NAME with good luck <vagrantc>for system things, it's sometimes already installed in the system profiles but not exposed to the user ... or possibly a build dependency of something i built earlier <vagrantc>xelxebar: there was definitely talk of integrating it into the guix data service, but not sure if that worked out <vagrantc>i also sometimes look at what it's installed with in debian systems i have to narrow down the guessing, as things are *usually* similarly named <xelxebar>Okay, so the current state of affairs is that we need to use an a somewhat ad hoc collection of intelligent guessing and searching around <xelxebar>That data service link you shared, not sure what I'm looking at. Is this a summary of the substitute builds? <vagrantc>there are regular posts about it from cbaines on the guix-devel mailing list <str1ngs>it's not an easy problem to solve, definitely can only be don with guix infrastructure <xelxebar>Thanks for the clear and on point info, btw. <vagrantc>you basically have to build all the substitutes and then index them ... and each generation might result in different results <vagrantc>and not everything always finishes building, etc. <vagrantc>maybe the current substitutes aren't matching what you're running... <vagrantc>your version is N commits behind or ahead ... <str1ngs>maybe if there was an indexer that went thorugh the gzip lzip cache. <brendyyn>i think it doesnt need to be so technically correct. just scan and dump the data into some guix-packages-meta-data package and use that updated monthly or so for suggestions <vagrantc>though it seems something worth doing for each "release" ... and a lot of those files won't change <rekado_>we could run this on ci.guix.gnu.org <vagrantc>the difference is probably the sheer number of outputs <xelxebar>populated with the *paths* of the build outputs <xelxebar>Hrm, that repo has ~11k files in it, corresponding to that number of packages. <xelxebar>Is that an order of magnitude less than the amount of substitutes available? <xelxebar>The xlocate utility simply git greps through those files to find the path one wants <xelxebar>Not that this exact design is what guix wants, but it's an amazingly straightforward solution for the void case <vagrantc>because packages are rebuilt whenever it's dependencies change, that means a given upstream version of a piece of software may have an arbitrary number of builds <xelxebar>Meaning that there's no reasonable sense of a global linear order, i.e. no way of choosing a "newest" build and just indexing the output paths on that? <vagrantc>but it's not immediately obvious what the order is ... to get the linear order you would have to build each and every commit and track the differences, because there's no incrementing version <vagrantc>you almost have to know the answer to know what question to ask :) <xelxebar>Well, practically speaking we just want 'guix package --find-file=bin/foo' to return 'baz-9.9' or whatever will get installed with 'guix install baz' <vagrantc>a database that just periodically gets updated would probably be sufficient to ask "what packages have had bin/foo ever" <vagrantc>wouldn't have to be perfect, just good enough <xelxebar>Hrm, waving hands naively, my first idea would be to have the substitute builds have a post-build hook that feeds some (commit, pkg, ver, {paths}) tuple-thing to whatever database you want. <vagrantc>well, if you include the full paths, that embeds the package name and version ... though getting the commit out of it again might be an adventure <vagrantc>the full paths also include the file paths, obviously <str1ngs>aye package name is implied in the path <brendyyn>'guix build emacs' only takes 1.5 seconds for me after emacs is already build. so for 10,000 packages thats 4 hours to scan through everything. thats starting from scratch. only 10 minutes or so if say 500 packages have been updated and the rest is cached. <vagrantc>usually ... although there are some things in /gnu/store that aren't obviously tied to a specific package <rekado_>instead of scanning we can compute this information when generating the (cached) narinfo files. <vagrantc>for package in $(guix package -A ) ; do find -type f $(guix build package) ; done <rekado_>some other process could then index the narinfos. <rekado_>the only difficulty is that this is a centralized service. So far all of Guix works the same whether it’s run locally or on the build farm. <vagrantc>successfully built /gnu/store/zpg0xicxynsqpcx64vg3gky32fd58bbm-linux-libre-pinebook-pro-5.6.0.drv !!! *xelxebar high fives vagrantc <vagrantc>rekado_: could build a package updated periodically that's shipped in guix itself ... and it's only as outdated as the last time the package was updated <vagrantc>presuming this database is manageable in size <brendyyn>i thought that this could be not used as a dynamic service but treated as a package. we release some think like guix-package-data version 2020-04, and that is an input to some bash completion package or GUI package manager <brendyyn>update that once a month, not a big deal if its a bit wrong sometimes <vagrantc>rekado_: so the centralized service could produce the data set ... and if someone wanted to produce the dataset independently, presumably it woudl be possible <brendyyn>it can be defined with a guix inferior to remain stable for a time? <vagrantc>e.g. build all thepackages you want indexed ... <rekado_>it would be unfortunate to have a package that doesn’t correspond to the currently used version of Guix. <rekado_>“guix search”, for example, doesn’t ever return anything that isn’t available with the currently used version of Guix. <brendyyn>such a package would depend on every other package in the entirety of guix <brendyyn>and there are always failing packages, so it must compromise at some point. <rekado_>brendyyn: not if it just packages up data that was produced on ci.guix.gnu.org <vagrantc>it seems like there are two options ... you cache some potentially stale data, or you use a centralized networked service ... <rekado_>but that doesn’t look like a good solution <rekado_>I wouldn’t want to have to install package databases for different build farms. <rekado_>that would give much more emphasis to the particular build farm servers <rekado_>right now we can just swap out substitute servers and nobody would notice a difference <rekado_>so that guix sub-command should talk to the selected substitute servers and get info directly from there, for the current variant of Guix. <vagrantc>and if the current variant isn't available? you get nothing? <rekado_>we could then fall back to a previous version (and print a hint) ***rekado_ is now known as rekado
<xelxebar>Okay, I'm lost, what package provides the cow-store service? <xelxebar>Is it a custom service only on the installation iso? <vagrantc>rekado: it seems like it could be useful to generate a partial cache from local builds / downloaded packages ... <vagrantc>then at least, you wouldn't have to hit the substitute servers if you already had it in the store <rekado>this needs some thought, which is probably why it hasn’t “just” been implemented. <str1ngs> xelxebar it's only need with the install iso. so the computer does not run out of ram writing to the ramfs. I think it's ramfs <xelxebar>Well, I'm trying to do a manual installation, limited to a serial console. This means I cannot use the installation iso, so I am trying from a vm image. <xelxebar>The first step is apparently 'herd start cow-start <mount-point>'; however, from the vm image of guixsd herd complains that it cannot find the cow-store service. <str1ngs>xelxebar: how much space does the vm disk have? <str1ngs>provided its not using ramfs and is a large disk you don't need cow-store. <xelxebar>Okay. I thought it had something to do with pre-populating /mnt/gnu/store or something, but that's a misunderstanding? <str1ngs>cow stands for copy or write. so with the installer io instead of writing to / which is ram it writes to /mnt/gnu . so it does not eat all of your ram. <str1ngs>I vote for renaming cow-store to barn :P <xelxebar>Okay, for some reason I just figured the salient part there was "writing to /mnt/gnu/store" instead of "avoid using up all your ram" <rekado>xelxebar: I’ve installed Guix on machines with only serial console in the past. <str1ngs>xelxebar: it's nice to keep the VM image around will speed up if you need to init again or something. <rekado>xelxebar: perhaps we should change the installer to output to the console as well if that’s not the case yet. <xelxebar>I believe the installer doesn't. For whatever reason, the vm image does though. <xelxebar>Also, grub going into fancy graphics mode caused me significant grief <xelxebar>sorry to derail the "package from path search" discussion. seems like it was going somewhere nice <bricewge>rekado: There was a discussion about that on the ML some month ago but it stalled <bricewge>Should I try pushing it further then? By writing a patch maybe <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, janneke says: see drafts, please edit+release if you like. <janneke>hey civodul: writing the blog post made me realise that we actually acchieved quite a bit the past week, which is nice! <guix-ci>Problem: /etc/passwd has been changed on Zabbix server Problem started at 09:28:35 on 2020.04.06 *guix-vits Hi there (i'm "afk") <janneke>civodul: is the draft something you can work with? <civodul>janneke: i haven't checked yet, will do so soonish! <civodul>i have to deal with work email and all <guix-vits>janneke: do glitches are expected in qemu _without kvm_? <janneke>guix-vits: kvm should "only" give you a significant speed-up, afaik...why would you run without kvm? <rekado>I just reconfigured ci.guix.gnu.org; that’s probably why guix-ci complained. *rekado reconfigures again <civodul>rekado: i'd like to reconfigure soon with support for the i18n web site <efraim>does anyone know offhand how to change logging from user shepherd services so it displays a timestamp? <rekado>civodul: I’m just reconfiguring to get the latest mumi with support for extra spam <rekado>erm, I meant: with support for commenting on issues from the web interface <rekado>(let’s hope the spam mitigations work well enough) <bricewge>efraim: Logging isn't shepherd forte unfortunately... <rekado>hmm, mitigations work too well… It’s probably the host name check. <civodul>efraim: yeah like bricewge wrote, the shepherd doesn't do much in terms of logging <civodul>rekado: .186 is ENOSPC, could it be a problem with the mcron job? <efraim>I saw in (modules shepherd) it uses default-logfile-date-format as part of logging <efraim>it might be time to hack on shepherd finally. It doesn't have config file support yet and needs flags and it logs to .config/shepherd *guix-vits +1 to rename cow-store to barn <efraim>civodul: not when run as a user. Then it logs to $XDG_CONFIG_DIR/shepherd/shepherd.log <guix-ci>Resolved: /etc/passwd has been changed on Zabbix server Problem has been resolved at 10:28:35 on 2020.04.06 <rekado>civodul: I restarted .186, because it also had a wrong guix-daemon command line. <rekado>they have all been reconfigured via guix deploy recently, so mcron should be okay once restarted <civodul>it should be slightly faster and more verbose <rekado>(I saw lots of warnings about missing host keys. We should probably update the deploy script.) <civodul>ideally that warning would only be printed once <sulr70>Anyone know how to report bugs? Just send email to the mailinglist, right? <rekado>sulr70: yes, send email to bug-guix@gnu.org <sulr70>BTW, how to find the maintainer of a certain package? <rekado>there are no package maintainers. <rekado>the collection is collectively maintained *civodul reports an intriguing GCC cross-compilation failure <civodul>roptat: guix-cookbook is not on the TP right? how is it handled? <sulr70>rekado: Then how can I submit a new package? To the mailinglist? <alextee[m]>wnereiz: guix-patches@gnu.org using git send-email or format patch and send it manually <rekado>sulr70: please take a look at the Contributing section in the Guix manual. <rekado>hmm, mailutils gives me a very rough error on ci.guix.gnu.org. <NieDzejkob>I was referring to -*- guix-vits +1 to rename cow-store to barn <NieDzejkob>anyway, I just took a look at the CI status for core-updates and it looks like we're getting closer and closer :D <kmicu>I’m strongly opposed to the proposed patch ‘cuz cow‑store is called cowshed, barn is too general and confusing term‑it’s like referring to a monad as an endomorphism. <kmicu>(If you accept that patch I will be forced to migrate back to Nix ‘cuz we cannot compromise on improtant stuff.) <Parra>is there any example of copy-build-system? I can't even copy a single file with it, it says the folder is not found. <guix-vits>Parra: see games.scm, neverball (and many more around) *guix-vits "and aways check if `environment` has the same master volume level for the sound... it was LOUD" <Parra>guix-vits: they replace install phase directly... <Parra>but it's fine, I can use that <rekado>Parra: there are a lot of packages using the copy-build-system <Parra>in 1.0.1 master, I search for it and I can't find any use <rekado>that’s because it was added after 1.0.1 came out. <rekado>the master branch does have a bunch of examples. <rekado>for contributions to Guix please work on the master branch ***kensington_ is now known as kensington
*alextee[m] just realized we don't have LSP plugins <eric-guix>I'm trying to understand how to speedup my upgrade. Offload seems to solve the problem but my question is: Offload work in background building my config.scm package? Or it starts only when I launch "guix upgrade" or "guix install" ? <rekado>eric-guix: offloading only means that builds (when requested) happen on a remote server instead of the local machine asking for the builds. <rekado>eric-guix: are you downloading binary substitutes from ci.guix.gnu.org? <rekado>generally you don’t often need to build anything locally because ci.guix.gnu.org provides binaries. <eric-guix>rekado: I'm using the default server for the binary, the problem that I want solve is the heavy cpu work for my x200 laptop when i launch "guix pull" or "guix update". Exist something that relay on a server to do the job on any git pull change *kmicu is so happy that alextee[m] is packaging all those audio goodies. Thank you! <rekado>eric-guix: “guix update” should fetch binaries, so it shouldn’t be expensive. <rekado>for “guix pull” you can also get binaries if you’re okay with fetching a slightly older version <xelxebar>Goodness gracious. Setting up a fresh guix system from scratch is too easy. <xelxebar>I'm florred that it Just Worked on the first try <civodul>you didn't use the graphical installer? <pkill9>xelxebar: did you run it on a foreign distro or from the installation image? <xelxebar>pkill9: None of the above. Used the vm image. <xelxebar>Trying to get guix running on a google compute vm and for Reasons couldn't use the installation image. <Parra>rekado: I can't mate, I just want to unpack the zip into the output directory but it's not working <Parra>it only copies some files, not all of them <eric-guix>rekado: well, thanks! Now the last question. If I want the last version build from an other machine for my x200 there are some automatic background command? <alextee[m]>Parra: is the zip you're trying to unpack the source? <rekado>eric-guix: nothing will be built automatically unless you ask for it. <Parra>it only copies the .so files but not others with another extension <eric-guix>rekado: OK, and there is something to speedup "guix pull"? <guix-vits>Parra: please post the definition (paste.debian.net) <rekado>eric-guix: “guix pull” has one expensive operation, which is to compute the derivation. Only once that’s computed can it fetch pre-built components. <rekado>(using the channel file I posted above) <eric-guix>rekado: What I mean is can I use a server to do that for me "guix pull"? <Parra>and there is a lot of .dll files <civodul>i think we can maybe summarize the story of our sufferings :-) <guix-vits>Parra: '(("." "shared/" #:include-regexp ("\\.dll$" ))))) -- it's work at all (maybe "share" without d)? <civodul>janneke: i amend it a bit, let's discuss! <Parra>if I remove include-regex it copies one so file into the output/shared directory <Parra>if I leave the regex, it says folder not found, referring to the output folder *janneke is in a meeting right now <Parra>"failed to produce output path" <alextee[m]>using mirror://sourceforge/teliasopia/teliasopia/ <version> /DynamicMultiband- <version> .tar.gz <alextee[m]>(also, why does sourceforge suck so much and why does anyone use it?) <alextee[m]>oh you're supposed to put the username in "brought to you by" <rekado>this also worked for me: mirror://sourceforge/teliasopia/Dynamic_Multiband_GUI/DynamicMultiband-0.0.2.tar.gz <Parra>guix-vits: adding the .so regex works, but dll still not being copied <Parra>I don't know why it does this random behavior <Parra>are dll files excluded by default? <guix-vits>Parra: idk (i'll download and poke it, though) <civodul>janneke: i'm also building the image with from the latest & greatest wip-hurd-vm! :-) <Parra>guix-vits: what do you mean? <alextee[m]>oh it worked now, the previous link was giving a different hash each time <civodul>janneke: i realized ext2fs now uses xattrs to store passive translators settings, so in a future interation, we can store them directly when we build the image, in populate-root-file-system & co. <rekado>alextee[m]: maybe you got an HTML page <janneke>civodul: oh, very nice -- that's a good step towards removing bash from the bootstrap! <janneke>civodul: will that also work for /dev nodes? <guix-vits>Parra: you'll need to refine it (to place LICENSE.txt somewhere in /share/doc ): <guix-vits>(arguments '(#:install-plan '(("." "/shared")))) <guix-vits>it simply unpack all under /gnu/store/blah-package-name/shared <guix-vits>(though idk why do you need to distribute binaries in such a way.) <Parra>guix-vits: the license thing is a requeriment? <Parra>guix-vits: I've tried exactly that line and it does copy only one file, a .so file... <reepca>Parra: I've got an idea what the problem is. So the 'unpack' phase that is used in copy-build-system is reused from gnu-build-system, where it runs "tar xvf <source>". It assumes this will produce a single directory, the unpacked source directory, and so it chdir's into the first directory it sees. <reepca>but, having used wget to download the source myself and tried to unpack it, it exploded a bunch of directories and files into existence <Parra>there is a way I can handle that? should I rewrite the unpack phase? <reepca>a tarball can have "multiple files", but this is actually distinct from being a directory containing multiple files <reepca>it would make sense to do that, I think <Parra>any suggestions in how to modify it? <Parra>I mean, not the boilerplate of modifying a phase, but how exactly unpack it <Parra>maybe forcing to unpack it into a folder? how should the folder be named? <guix-vits>Parra: i used the line posted above and have a "/gnu/store/bzcm1gj54vlhil7fd4lbxpf6drlrkhwd-netcore-2.1.17", with all the files (under shared/). <reepca>make a "source" directory or something, chdir into it, tar xvf $source, and that should be all that is necessary <reepca>(where $source would be the variable bound with #:key source) <Parra>I will try again the guix-vits method, otherwise I will try yours reepca <reepca>on my system the first-subdirectory procedure returns the "host" directory, which contains only fxr/2.1.17/libhostfxr.so <Parra>I will refactor the unpack phase to move all files into source dir <Parra>netcore isn't bootstrappable right now, but if I can do a base package bootstrapped from cli seed binaries, eventually we will find how to build the seed client and bootstrap netcore completely <Parra>this I'm doing right now is an intermediate solution to package netcore, although it isn't fully reproductible <Parra>an option would be to build the seed cli with mono <guix-vits>Parra, reepca: ''In procedure stat: No such file or directory: "host"'' -- strange (`build`). <reepca>guix-vits: how'd ya get that message? <guix-vits>reepca: (arguments '(#:install-plan '(("host" "/host")))) <reepca>that would make sense, considering if the unpack phase is left as-is, then the current directory at the time of the copying doesn't have a "host" directory, as it *is* the "host" directory. <reepca>since the unpack phase happened to pick it as the first directory it saw to chdir into, because it expects the tarball to contain a single directory, not multiple files. It actually chose it as the first directory because it's the lowest one in more-or-less alphabetical order. <alextee[m]>is there a way to to do a regex on directories and copy them to a destination? <guix-vits>reepca: (invoke "pwd") in 'install: /tmp/guix-build-netcore-2.1.17.drv-0/host . hm.. <reepca>guix-vits: aye, that matches up with expectations. It should work to just do (modify-phases %standard-phases (replace 'unpack (lambda (#:key source #:allow-other-keys) (invoke "tar" "xvf" source)))) <reepca>hm, I guess another way to make it work would be to "undo" the chdir from 'unpack' by specifying '(#:install-plan '("../" "shared/" #:include-regexp ("\\.dll$"))) (note the "../") <guix-vits>reepca: i finally got it: in another tarballs, when i'm unpack them, i see a dir. thanks for the explanations <guix-vits>Parra: ^^ ''..."undo" the chdir from 'unpack'..'' -- works. <rekado>gah, mailutils errors are infuriating <reepca>it could be worse. It could just say "Segmentation Fault". <alextee[m]>what's the regex for something NOT ending in something? <reepca>I don't think there's a standard way to invert a regular expression, but you could use the optional PRED argument to find-files. <reepca>oh wait, the PRED argument is the regular expression thing. Well anyway, turns out it can also be a procedure! <alextee[m]>sounds complicated, i'll just copy the files manually :-) <eric-guix>rekado: I added the new channel that you suggest to me <civodul>rekado: oh that's bad, it worked pretty well for me (after i spent time setting debugging it) <alextee[m]>actually, this procedure is used for multiple packages so it would be nice to have a regex so i can just inherit, instead of copying the whole (arguments) thing <eric-guix>but now if I try to do "guix install icacat" it try to use default channel instead of the new one <civodul>janneke: i found why our /dev was all read-only, including /dev/null & co. <reepca>alextee[m]: (find-files "." (lambda (name stat) (not (string-suffix? ".so" name)))) should do the trick <Parra>guix-vits: can you explain what you mean with undo chdir from unpack? <rekado>civodul: it works fine on my machine, but on ci.guix.gnu.org I think it might be a problem with the firewall … again. <civodul>you must have a hot line to IT now? :-) <rekado>I’m lucky when they remember me. <rekado>it has to pass through the ticket system, so way more people are involved than I’d like <Parra>how I can debug this things? <Parra>I mean it's really simple the change, but without knowing anything about how guix is doing things makes it so hard <Parra>for example seeing what guix is doing when executing a build <Parra>I have no idea where is it located, what paths is it copying <Parra>I don't know where is "." or similar <Parra>they are simple things but it's really difficult to detect them <reepca>Parra: builds take place in what is essentially a scratch directory of the form "/tmp/guix-build-<package>.drv-0 <reepca>(and that itself is inside a container) <Parra>but I want a debugger to run it step by step and seeing what's happening in the folder at same time <Parra>so I can print the variables or pwd <rekado>sending from one of the build nodes works fine, though <reepca>Parra: for that I'd recommend write, display, and format <reepca>(all three are guile procedures documented in the reference manual) <Parra>reepca: how do you debug usually? <reepca>oh, and also, --keep-failed is nice <reepca>it copies the scratch directory out from the container and puts it in /tmp <Parra>when you say container you mean the jail guix does when building, right? <reepca>Parra: a combination of old-fashioned print-statement debugging, going through the same steps manually, --keep-failed, and reading exactly what the build system phases are doing <Parra>it's still complex, because that kind of debugging works in cmake for example, which is much more limited than lisp <Parra>but lisp is a complete fp language, we should have ways to intercept the function calls and inspect values <Parra>I think it would improve a lot the development, and the learning curve for people like me <reepca>part of the issue is that it's not really possible to interact with the build environment, by design (to increase reproducibility). <Parra>well, opening a port with gdbserver in debug mode is fine, only for developers <reepca>it'd be nice to have a build-environment-but-with-interaction-for-debugging-only, though. <Parra>I think exposing a port for connecting with a guile debugger <Parra>not sure if guile has debugger <Parra>I've never coded with it before <reepca>it can provide a REPL server over a socket <Parra>but it would be something at least <reepca>providing convenient integration would require tweaking the generated build scripts, which could increase the differences in behavior between the build environment and the debugging environment <Parra>I don't see how that could affect, because I don't know yet the whole architecture and Implementation of Guix <Parra>but I think debug can be rolled back later on, and that's it <Parra>I don't see how a debugger can modify the state, unless you manually modify the state <Parra>if you are only stepping and seeing the variables.. shouldn't affect the <Parra>the reproductibility at all* <Parra>it's like logging each step of the execution of the build,that shouldn't affect the build itself *raghavgururajan 's darling (x200t) is back <3 <mbakke>civodul: I did a merge of master into core-updates yesterday, but did not push it because one test is failing: "package-transitive-supported-systems, implicit inputs" from guix/packages.scm:397 <mbakke>can you have a look if I push the branch somewhere? <mbakke>the test returns '("i686" "x86_64") when it is supposed to return all supported architectures <mbakke>ehm I meant: actual-value: ("x86_64-linux" "i686-linux") <anadon>I started on updating Django yesterday. It looks like that will end up being a minor project and a rather large patch. Should I be breaking it up? I think in this case it should be kept on a monolith. <civodul>it may be because one of the new packages on the bootstrap path has a restrictive 'supported-systems' <mbakke>civodul: it passes on the current core-updates (I think -- haven't checked since the previous merge) <mbakke>so I'm confused as to why it failed now <mbakke>anadon: one patch per package update is preferrable <anadon>One patch per package, but multiple patches per PR? *mbakke double checks that the test passes on current core-updates <mbakke>ehh I meant core-updates..master in that command :) <mbakke>I need either more or less coffee, not sure which <mbakke>reverting it made no difference for the test though <NieDzejkob>what is it about that sha256 that you're finding unorthodox? :P <mbakke>NieDzejkob: the empty string on non-x86 <NieDzejkob>I assumed you meant "commit hash" for some reason <NieDzejkob>Also, I've seen you're doing a lot of work with build failures on core-updates. Is there a way I could help with that? I tried looking at the logs from some failing derivations but the /log/ URL returns an empty response <mbakke>NieDzejkob: there is an ancient bug somewhere that causes logs to be truncated when the build daemon is under a lot of pressure <mbakke>also, a huge amount of builds failed because of timeouts on the sqlite db lock <mbakke>so the CI pages are nigh unintelligible atm :/ <mbakke>I'd like to restart the whole evaluation somehow <mbakke>civodul: I can confirm that the test passes on current core-updates (commit a533c5a1835cbeafaf595c4474e2ce6adde7de8d) <mbakke>so there is a regression on master somewhere that only shows up after merging to core-updates <pkill9>does there exist a guix setup so lightweight, you could bundle the source code with it and build it all from scratch with no substitutes? <alextee[m]>just sent like 5ish patches for music if someone wants to review them <janneke>civodul: i like your edits a lot; more to the point and you add some enthousiasm <mbakke>somehow that breaks the unrelated test, on the core-updates branch only! *guix-vits just seen someone's "about me" on GitHub: ''Senior segfault engineer, PhD in printf debugging'' *mbakke should update their profile to senior bisect engineer, PhD in code spelunking <mbakke>civodul: hm, reverting that commit does not cause the test to pass however! and causes a new test failure, in "printer with location" <mbakke>derp, not "printer with location", but "transaction-upgrade-entry, zero upgrades, propagated inputs" <mbakke>civodul: to reproduce the issue, apply 190ddfe21e3d87719733d12fb9b5eb176125a49f and a187cc562890895ad41dfad00eb1d5c4a4b00936 on top of core-updates <mbakke>NieDzejkob: if you want to help with core-updates, here are some failures from my TODO list: 'ruby-sqlite3', 'ecl', and 'behave' *mbakke goes out in the sun for a bit <mbakke>NieDzejkob: some hints, SQLite has been updated, and ecl appars to fail because of the new LibFFI <mbakke>behave is in the Python ecosystem which has seen updates all over the place, including Python <civodul>janneke: i'll push a few things to wip-hurd-vm <civodul>initially i just wanted to have the pretty console up and running <str1ngs>janneke: regards to emacsy logging, I'll try to make it make it less noisy atleast. <str1ngs>janneke: there are not many logging procs. I think I can just add a emacsy-log? variable. so it can be turned on and off. should not effect much code this way. <janneke>str1ngs: okay, good. yes, i hope that most obnoxious "logging" is actually for debug purposes and should be removed at some point; only messages that are actually informational for a user must go to *Messages* i guess <str1ngs>janneke: right, though it is useful. just not all the time <lfam>Where are people applying the 1.1.0-pre translations? To core-updates? <str1ngs>janneke: I plan to do more work on *Messages* as well. nomad has a weird bug were *Messages* can not be seen when added to *Messages* scratch I've been able to finally handle okay though. <str1ngs>janneke: great, thanks for the feedback. <str1ngs>janneke: also side note, split window is a hard problem to solve haha. I'm using emacsy windows in nomad now. but widgets are PITA :) <janneke>str1ngs: sorry for not being more involved; thanks for picking this up <janneke>str1ngs: yes; this frustrated me for a while, thinking it "should" be easier to solve <str1ngs>janneke: no problem at all. I'm just cautious when making changes to emacsy. I'd rather have some code review. <str1ngs>janneke: my solution is to keep only support single window instance for now. I added frame support aka emacs windows which helps. <janneke>yes, we should really get this right; and that will take some effort <str1ngs>my thought was to create new GtkTextView's for each new window. this is manageable. for <web-buffer> which is a custom buffer with nomad. I thought of creating a web controller that works on each buffers window. seems like alot of work though. <lfam>efraim: I saw you pushed another commit since yesterday / last night <lfam>efraim: Anything changed I should know about? <rekado>issues.* doesn’t reliably update the database because there are two processes competing for locks. <rekado>guess I should use fibers instead. *lfam reboots on core-updates <lfam>Bytecode incompatibilty messages from the initrd <bricewge>I've send a request for help on the ML, I'm probably overlooking some basic Guix/Guile stuff. If someone has time it would be appreciated :) <efraim_>lfam: I have some more changes, I'll go ahead and push them now ***efraim_ is now known as efraim
*lfam works on GnuTLS CVE-2020-11501 <dongcarl>Hi all, where do y'all think procedures like PACKAGE-WITH-EXTRA-PATCHES should go? <dongcarl>But I think it probably belongs somewhere else <civodul>OTOH, until there's a more frequent need for it, it's ok to keep it local IMO <dongcarl>civodul: I'm finding that I need it for custom patches in my manifests, and would like to make it public <dongcarl>So that's why I wanted to find a good place for it to be exported <civodul>dongcarl: then sure, (guix packages) sounds like the right place to me! <civodul>janneke: i've pushed some of what i have here to wip-hurd-vm <civodul>we still get EACCESS messages and the console doesn't start <civodul>i have more changes locally but they only make things worse :-) <lfam>efraim: What have you done so far? I'm wondering where I could jump in after my current task <lfam>mbakke: How's core-updates? There's a GnuTLS bug fix on the way... <mbakke>lfam: core-updates is chugging along <lfam>mbakke: Unfortunately the bug fix is in GnuTLS 3.6.13, so we'll need to apply a graft for core-updates <lfam>Wow, there are really a lot of GnuTLS packages right now <mbakke>lfam: I assume 3.6.13 can be grafted in place? <mbakke>instead of extracting the security fix alone? <lfam>mbakke: The version number is a different length :( <lfam>We can do that on core-updates but not on master <mbakke>lfam: that's OK, just call it 3.6.A or something :) <mbakke>we'll need to adjust it on core-updates though <lfam>I don't know, I just feel like it should reflect the upstream version number <noobly>so I'm getting this eror: "guix package: error: cannot install non-package object: #<unspecified>", and I read that 'the problem is likely that the file doesn’t evaluate to a package object, but to #<unspecified>, so end it with ‘magic-enum’, which evaluates to a package object', but I don't know how to implement that advice, any tips? <lfam>noobly: Put the text 'magic-enum' at the end of the file you are working on <lfam>Assuming your package is called magic-enum <mbakke>civodul: there is some crazy side effect going on! <mbakke>lfam: the store item name is not all that interesting IMO <mbakke>OTOH a .A suffix signifies that it isn't a "normal" package :) <lfam>I guess it's better to have the upstream package than some kind of patched frankenstein <lfam>I sent my patch for review. If you make sure the use of package/inherit is correct I can revise my patch to use the upstream release <lfam>For packages like gnutls-3.6.A, are we using define? Or define-public with hidden-package? What's the standard now? <noobly>lfam: OH that makes sense, my package is not called magic-enum but thanks <mbakke>lfam: I've used define-public for a while, but think that using just "define" is better, because it ensures manifests etc get the same version as package inputs <mbakke>nagamalli: you can use the handy bot named sneek to leave a message for later <mbakke>sneek: later tell nagamalli that sneek is really good at remembering messages <mbakke>the bot needs to be fed to prevent it from getting bored and leave <guix-vits>sneek: later tell guix-vits "I'm so happy ot see you, you're the best" <sneek>Welcome back guix-vits, you have 1 message! <sneek>guix-vits, guix-vits says: "I'm so happy ot see you, you're the best" *guix-vits i know how to hide from sneek, MUHAHA ***nikita`_ is now known as nikita`
<mbakke>civodul: making the new test fail by changing a version number lets "package-transitive-supported-systems, implicit inputs" pass ... I am kind of hoping my computer is going nuts, as I really don't see a relation between the two tests. <mbakke>would be good if someone could try and reproduce the issue to confirm whether my computer has been ingesting illicit substances behind my back :P <mbakke>lfam: can you try to cherry-pick 190ddfe21e3d87719733d12fb9b5eb176125a49f and a187cc562890895ad41dfad00eb1d5c4a4b00936 on core-updates and run 'make check TESTS=tests/packags.scm'? <lfam>I sent a revised GnuTLS patch ***dftxbs3e_ is now known as dftxbs3e
<lfam>mbakke: The test 'package-transitive-supported-systems, implicit inputs' fails for me <lfam>Do you want more detailed log output? <lfam>Basically, the actual value is just Intel compatible systesms <mbakke>lfam: if you comment out the "transaction-upgrade-entry, grafts" test, does it then pass? <mbakke>lfam: out of curiosity, are you using Guile 2.2 or 3.0 for the test? check with './pre-inst-env guile --version' - I'm on 3.0.2 from 'core-updates'. <lfam>It passed when I commented that test out <lfam>I can rebuild the checkout based on itself, to upgrade <mbakke>lfam: no need, that's how I've been running it. somewhat reassuring that it occurs with Guile 2.2 and 3.0... *mbakke goes AFK for a while <vagrantc>wip-pinebook-pro updated with linux-libre 5.6 <janneke>vagrantc: very nice; i spend a tweet on how to continue <vagrantc>janneke: it's still tobias schram's git repository, but rebased against 5.6.0 ... which also seems to trivially rebase on top of 5.6.2 <vagrantc>the kernel git repository is a bit huge, though ... so hrm. <vagrantc>the patchset should apply to 5.6.x ... but it's a few hundred patches <vagrantc>would be interesting to distribute a patchset as a tarball or something rather than including directly into guix master <vagrantc>but adding a few hundred patches to master seems a bit ugly <janneke>ouch, i mean: great that it works... <lfam>vagrantc: We have examples of fetching patches at build-time from Git repos <vagrantc>yes, it's good to see video output and battery status ... working off of pure mainline works fine for a very fancy headless machine <vagrantc>lfam: like a git repository that contains patches? <lfam>I mean, the skies the limit <vagrantc>or extracting the patches out of a git repository? <lfam>A git repo can be accessed as patches <lfam>Check the qemu-patch procedure <lfam>Or how Bash patches are handled <lfam>I never actually use the QEMU patches procedure. I think it's relatively fragile and obscure so it's not worth it. But for hundreds of patches, no, they shouldn't be part of the Guix codebase <vagrantc>i see the qemu-patch procedure, but i don't see it used <lfam>Historically the QEMU repo was unstable <lfam>Generating patches from Git is not really something that should get a hash, IMO. The hashes are liable to change and the Git hash should be sufficient <lfam>But if you have to, you have to <vagrantc>yeah, for stability, i'm tempted to just create my own git repository <vagrantc>which maybe only contains the patches... <vagrantc>and then those patches can apply on top of linux-libre tarballs <vagrantc>but not quite wrapping my head around the examples attempting to do that sort of thing just yet <vagrantc>so for bash, it's basically just downloading individual patches into the store? <civodul>mbakke, lfam: can you open a bug for the failing test? <civodul>maybe it'll be fixed by them muahaha <bgardner>Good afternoon guix! I'm getting a new error on a box during 'guix system reconfigure' after a 'guix pull' - and nothing changed in the config.scm. The fail message is "builder for `/gnu/store/...-etc.drv' failed with exit code 1 - the actual error in the log is 'ERROR: In procedure symlink:\nIn procedure symlink: File exists' <bgardner>I do have two simple (extra-special-file ...) sections, and other guix boxes without these sections have no such error. <civodul>bgardner: did you see the message related to rottlog in "guix pull --news"? <bgardner>I did not - let me check that, one moment <bgardner>D'oh! That's my fault then, thank civodul *guix-vits -- "Is that cool, or aren't, that meson produces no error if it's "make check" was requested, but no tests were ever defined?" <bgardner>civodul: Thanks again Ludovic, that was totally it - I forgot I had added rottlog to all my servers last week. Reconfigure now runs successfully again. <nojr>what is the difference between $HOME/.guix-profile and /root/.guix-profile?? <pkill9>nojr: you don't need to export both <pkill9>they are guix profiles for separate users, the one int he root folder is for the root user <pkill9>but not for the whole system, just the root user <lfam>marmulak[m]: No, Guix doesn't have a stable branch <lfam>The only branch we support is the master branch <nojr>pkill9: I'm getting an error guile: warning: failed to install locale <nojr>Im getting an error again guile: warning: failed to install locale <nojr>I haven't seen that error since the day I installed guix (I'm on foreign distro) <nojr>I noticed it after reading over the manual and running sudo -i guix pull then systemctl restart guix-daemon.service <nojr>wario@wario:~$ echo $GUIX_LOCPATH <nojr>echo $GUIX_LOCPATH returns /home/comp/.guix-profile/lib/locale <joshuaBPMan>hey guix, I'm having trouble installing nightly via nix service type...Is it ok if I ask for help with that on this channel? <lfam>nojr: When you upgraded root's Guix with `guix pull`, you also upgraded the guix-daemon. It's possible that the guix-daemon and your user are using incompatible versions of locales now <lfam>Sure joshuaBPMan, although we might not be able to help much. We don't have a concept of "nightly" <lfam>Anyways feel free to ask about anything Guix-related <joshuaBPMan>lfam: well I feel bad about trying to install firefox-nightly... <lfam>Oh, I wasn't sure what you meant by nightly <joshuaBPMan>I'd prefer to use Icecat, but Icecat is basically un-useable for me. I can't get it to work reliably on mastadon or paypal. <lfam>You should try Epiphany or ungoogled-chromium. They are both modern browsers with regular security updates <lfam>Icecat gets security updates, too, actually <joshuaBPMan>lfam: I have similar issues with ungoogled-chromium. <lfam>I'm surprised to hear it doesn't work with Paypal although, tbh, I haven't tried <joshuaBPMan>I have to kill Icecat after about 5 minutes of useage on any "javascript heavy" sites. <lfam>Well, back to your original question <lfam>You want to use Nix on your Guix system? <joshuaBPMan>If I don't my computer locks up. Though I am hoping that my new earlyoom-service-type will help. <lfam>Also what kind of computer are you using? <joshuaBPMan>lfam: My actual goal is to use a decent web browser on Guix System. <jonsger>joshuaBPMan: did you disabled all AddOns in Icecat? <lfam>I see. That's a really old computer and it's going to struggle no matter what. I would make sure to use an SSD, though <joshuaBPMan>and that's weird. Disabling the add-ons in icecat did seem to help. A lot. <lfam>You might also try Epiphany. Like I said it's a modern browser engine but overall a much simpler package <pkill9>does anyone know how to use downloaded voices with festival text-to-speech? <efraim>Also apparently firefox now has an official flatpack <lfam>rekado might have advice about festival, pkill9 <rekado>I downloaded a bunch of voices (cmu_us_axb_cg, cmu_us_ksp_cg, cmu_us_slt_arctic_hts, etc), but the hts voices don’t seem to work <rekado>pkill9: but with this festivalrc you should be able to run “festival” and then input (SayText "hello there! How are you?") to get a very unenthusiastic greeting. <rekado>not sure what needs to be done to get the hts voices to work <rekado>(set! voice_default 'voice_cmu_us_rms_cg) gives you a much better sounding voice than the default kal_diphone <rekado>there’s a more elegant way to add languages to the load path and make them available, but I didn’t get around to writing it. <Blackbeard>rekado: I couldn't make the voices I downloaded to work either <Blackbeard>But I was using Guix on top of parabola, so maybe now on guix system I could <Blackbeard>Exactly that way, using the loadpath. I read the documentation and maybe that could work. <rekado>all the other languages in my festivalrc do work for me <joshuaBPMan>lfam: also, Firefox works just fine for me on my T400 machine when I run debian. <rekado>(would be nice if festival used Guile instead of SIOD) <Blackbeard>I did, but I don't remember now. But it is something I've been putting off for a while, I think I would try now <rekado>note that some components that are needed for some voices are proprietary (or at least have unclear licenses) *rekado plays with festival now instead of investigating why the mumi mailer doesn’t work right on ci.guix.gnu.org… <joshuaBPMan>epiphany is doing the same thing. It weirdly starts lagging and slowing down sway. <rekado>how much free memory do you have when this happens? <pkill9>rekado: ty, i managed to add a voice <joshuaBPMan>rekado: I only have a few tabs open. Less than 5. Icecat just got weirdly laggly on me a moment ago. I only had the official GNU/Hurd wiki open for a few minutes. <pkill9>rekado: i'd like eventually to be able to install them to a guix profile <pkill9>i don't know if festival looks in any environment variable specified paths though <guix-vits>joshuaBPMan: can you check it with a new test-user? <pkill9>and if the license is ok, package them in guix <joshuaBPMan>That's the startup error I got when I open icecat in a terminal. <joshuaBPMan>guix-vits: I probably can. I'm honestly not interested in trying that though. I'd have to reconfigure a lot of stuff to pull that off. If you can convince me that it would be worth the effort, then I might try it. <rekado>joshuaBPMan: do you see the same behaviour when using “icecat --safe-mode”? <rekado>pkill9: sounds good. We’d have to figure out how we want to write the site init file. Perhaps use an environment variable as a search path. <rekado>pkill9: my rc file is pretty crappy. I just learned that you can do (require 'voices) and then use a bunch of nicer procedures to load voices. <rekado>joshuaBPMan: I meant: do is still go laggy? <joshuaBPMan>rekado: well let me play around with pay pal really quickly, and we'll find out. *civodul restarts cuirass <joshuaBPMan>rekado: this is the only initial thing...but it seems to be a little laggy. <joshuaBPMan>And sure I'll send you money. What's your bank account # and routing #? :) *guix-vits / nick rekado_ <joshuaBPMan>rekado: Icecat does seem to be working a little better... <rekado>joshuaBPMan: what’s your free memory? (use “free -h”) <rekado>pkill9: we would only need to add a site file that splits FESTIVAL_VOICES_PATH (or similar) and adds each of them to voice-path before running (search-for-voices) again. <rekado>then we could install voices via Guix and set FESTIVAL_VOICES_PATH (or whatever) as a search path on the festival package. <joshuaBPMan>rekado: the used column says 869Mi "Free" says 1.5 Gib <rekado>is this when icecat becomes very laggy? <rekado>my guess is just that you simply run out of memory and then Linux tries to swap, moving memory contents to disk and from disk to memory. <joshuaBPMan>rekado: I don't think memory is the issue. I thought that too. I have 8GB. <joshuaBPMan>It should that I had a ton of memory available. Less than 1/3 of memory was being used. <leoprikler>perhaps something is eating your CPU? Like a compilation or stuff like that? *rekado tries to build hts_engine in festival <pkill9>ah that is a lot nicer rekado :) <pkill9>(the festivalrc you posted i mean) <leoprikler>if it's just icecat/chromium on their own, then it might perhaps be muh big javascript website, but that should affect webkit too <joey>Hello. I am thinking of installing Guix again, but for my Thinkpad X200, I wasn't able to get the volume buttons to work nor the touchscreen. Does anyone know if there are some specific drivers that are needed for these actions?