<lfam>I wonder if there is anything I can do tonight to help with the staging branch. The only significant blocker I can see is the mesa build failure on i686-linux, which has been reported upstream, and I don't have any ideas about what's wrong: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091
<lfam>The rust failure is surprising to me, cbaines. Is that on x86_64?
<lfam>Wouldn't we have noticed the failure of all packages depending on rust?
<lfam>Oh, I see that the canonical rust is rust-1.45
<jgart[m]>Hi guix! `local-file` is a record that is then shadowed by the macro `local-file` (using define-syntax). Is my thinking correct on that? I'm reading the code in gexp.scm
<justinmoon>lfam: thanks. i did get some good answers over there!
<jgart[m]><jgart[m] "Hi guix! `local-file` is a recor"> to answer my question above and for anyone else that might benefit understanding this: the macro local-file in the gexp module is the public interface for creating <local-file> record objects. Thanks #scheme
<nij>Any idea on why guix was chosen to be written in Scheme, not CL?
<raghavgururajan>> leoprikler: raghavgururajan: the issue is this->_sprites being empty
<apteryx>nij: IIRC RMS didn't think CL as elegant, so it must have played a role.
<apteryx>Guile was brought to GNU (it already existed before) to compete with TCL (Tool Command Language), which was increasingly popular at the time, used to script and extend software (it's still common with electronic design automation tools bfor example).
<mroh>And also it was/is much easier to extend C code/libraries in/with guile than with TCL and RMS really didn't like TCL that much...
<apteryx>Also, Tcl was controlled by Sun Microsystems at the time and there were concerns about the license (e.g., it could become proprietary).
<_tecosaur>Oh, another thing with another dependency: reset-gzip-timestamps complains "In procedure open-fdes: Permission denied" from reading http://logs.guix.gnu.org/guix/2019-12-19.log it seems the fix is to modify #:phases to change the file perms, with a linked (expired) paste from roptat. I'm not sure how I'd go about this, so if anyone might be able
<_tecosaur>raghavgururajan: so guix now runs the nextcloud desktop client? What about the server?
<lfam>_tecosaur: The only thing I see that is amiss is that the URL of your new package is still fetching from github. But, I don't believe that should matter, since the #:import-path is what creates that filesystem structure
<Bitt>hello! is it normal for the shell to respond with no such file or directory, when trying to run downloaded executables in guix? for example I downloaded the latest blender build from their website and wanted to run it with ./blender, but then even though it exists, bash said it doesn't
<rekado_>Bitt: yes, it’s normal, because those executables refer to a global executable (the loader), which is not available at the expected location.
<rekado_>for those cases you can create a link /lib64/ld-linux-x86-64.so.2 to /lib/ld-linux-x86-64.so.2 from the glibc package.
<rekado_>some applications may contain a reference to a different loader location, so you’d have to use something other than /lib64/ld-linux-x86-64.so.2 to satisfy theim
<apteryx>there's another driver for the shell script test files
<apteryx>In particular, I'm trying to understand what the --test-name is supposed to be: the file name of the test, or its actual srfi-64 test name? It's seems the former, although I find it confusing.
<apteryx>and I can't seem to find the right invocation to call such test driver directly, e.g.: guile -e main -s build-aux/test-driver.scm --test-name=tests/packages.scm --log-file=log --trs-file=trs tests/packages.scm
<apteryx>yes, that works. I want to understand how to call directly to the undelying test driver as I'm trying to augment it with a --select and --exclude options that'd allow selecting individual test cases, as running 'make check TESTS=tests/packages.scm' takes too much time when I'm interested in a single test case result.
<apteryx>I guess the answer lies in autotools; if I know how it calls any test driver I'll have my answer.
<apteryx>the SCM custom test driverseems to be registered with the SCM_LOG_DRIVER variable in Makefile.am; it's nothing special outside of setting the environment with test-env before calling the script.
<apfel>hi, git.savannah.gnu.org seems to be down, is anything know whats going on? i tried to find some status webpage or something which tells me when it will be up again, but i did not find anything.
<lfam>It's likely at the location mentioned in that earlier discussion, though
<lfam>It's a well-known location, which is why binaries can be distributed like that. It can be expected to work on most old-school GNU / Linux systems
<mzbm>it says "access("/etc/ld.so.preload", R_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
<mzbm>hmm seems to not find a lot of stuff... ill try the suggestion in the chat log
<nij>What's the actual packaging workflow like? I understand how to package =hello= and =suckless-terminal=, by directly editing the scheme file. But I imagine this isn't how people really do it.
<nij>In practice, do you first enter a guix environment? And then start editing the scheme file that defines the package? And then you try to build based on that file? What happen if it fails? Do you have to restart a new environment? What happen if it succeeds? Do you have to manually input all the dependencies of the env? Or there's a quick way to dump the information?
<cbaines>nij, I normally don't bother with trying to build the software outside of building the package, unless I'm really stuck with trying to get the package to build
<cbaines>nij, Guix package definitions define the environment within which the package is built, so using guix environment to build software can only make sense if you're building the software without using a package
<pineapples>civodul, lfam: Thanks! I'm unknowledgable as far as compression algorithms and the difficulties of deploying them in production are concerned, but I guess the thread on guix-devel contains all the information I need to know. Now I can only presume the inability to drop lzip or gzip must have something to do with CPU architectures
<lfam>It has to do with existing Guix deployments not yet supporting zstd. It's a chicken and egg situation
<pineapples>lfam: Ah, I see. civodul's pronounced reply read like there's a far more critical reason due to which the support for them cannot be dropped, although you made it clear it's about not all g
<pineapples>I wrongly assumed that every instance of Guix and Guix System must be already running the newest version of guix-daemon if it performs any updates at all, but this is, of course, plain wrong now that I'm thinking about it
<n1to>Hi. I recently began using Guix and am now trying myself at packaging. I managed to create a working package definition for 'libnitrokey'. Right now as I am testing it though, it seems that the udev rules, which are provided by the package (in ~/.guix-profile/lib/udev/rules.d), don't take effect. Thus I can't access the device as a normal user. As root it just works fine. Is this just a configuration error on my part or do I need to consider this
<n1to>pinoaffe: ah, I see. So guix finds these rules itself just from the package definition?
<n1to>as long as I specify it in the udev-service-type, I mean.
<pinoaffe>n1to: I don't know for sure, but I think that as long as the package puts the udev rules in the right directory, adding the package in the udev-service-type should ensure that they're added to the system
<pinoaffe>if it's putting them in the wrong directory, you might need to modify the package definition a bit