<nckx>cybersyn: So the package that fails to build is precisely that proprietary module, not the kernel itself (‘linux-module-builder’ is just a ‘build environment’ for modules). As you know we cannot provide support for the former here.
<sneek>vagrantc, apteryx says: I recently let mhw know about that decision, so they wouldn't be surprised when the change hits the patch tracker; they told me while they still disagree with it, it's a rather small thing in the bigger picture and they are ready to let it go.
<vagrantc>apteryx: yeah, that's the impression i got from mhw based on the various threads on the subject
<tissevert>while test building a package from the guix repos with ./pre-inst-env guix build, I get a lot of warnings about .scm files being newer than their .go counterparts (no kidding, I've just pulled to be sure I was up to date)
<tissevert>do you all have such warnings each time you test build a package ? if not what do you do to avoid it ?
<mekeor[m]>i have a server running guix system. suddenly, i can't run "su" or "sudo" successfully. although i can still login per ssh with a ssh-key. i'm pretty sure my password is correct. any idea whats happening?
<emacs-user57>Hi! I just reinstalled Guix and using EXWM. However, it's not using any of the emacs packages I downloaded before. I am using this on my .emacs (add-to-list 'load-path "/home/k/.guix-profile/share/emacs/site-lisp/")
<emacs-user57>I am using pdf-tools, nov.el, and modus-vivendi and none are working right now.
<iyzsong>mekeor[m]: maybe the /var/log/secure (or auth) file say something? i think it could be pam related
<mekeor[m]>iyzsong: i set (use-pam? #f) for ssh. is that relevant?
<iyzsong>mekeor[m]: that may be the reason why only ssh works
<davidl>civodul: I tried linking /lib/ld-linux-x86-64.so to ~/.guix-profile/lib/ld-linux-x86-64.so.2 and start the AppImage file again, but the same result: bash: ./drawio-x86_64-14.5.1.AppImage: No such file or directory
<mekeor[m]>iyzsong: removing that option solved the issue. thank you so much! :)))))
<civodul>emacs-user57: hi! you installed these packages with Guix but they're not found when you evaluate (require '...)?
<emacs-user57>civodul: yes I installed all of thse using Guix -- it worked properly until I updated my Guix a few days ago.
<sneek>roptat, apteryx says: I tried something like: info_TEXINFOS = [...] $(patsubst %,\%D\%/$(MANUAL_LANGUAGES).%.texi,guix) but that also failed
<civodul>roptat: ah good, i like it too! i was wondering what you thought
***alendvai__ is now known as attila_lendvai
<davidl>nckx: sure, I understand. I am stuck now because I need the libatk-bridge package which doesn't exist.
<davidl>nckx: this is where Im at now: sudo LD_LIBRARY_PATH=$(find ~/.guix-profile/lib -maxdepth 1 -type d | xargs | tr -s ' ' ':'):$(find ~/.guix-profile/lib -maxdepth 1 -type l | xargs | tr -s ' ' ':') ./drawio-x86_64-14.5.1.AppImage
<davidl>/tmp/.mount_drawioMaOcLR/drawio: error while loading shared libraries: libatk-bridge-2.0.so.0: cannot open shared object file: No such file or directory
<bone-baboon>I have a substitute server that has python and gnutls built on it. But when a client does `guix pull --substitute-urls=<my-substitute-server>:<port>` it starts building python and guntls. The substitute server was started with `--cache-bypass-threshold=<size-of-substitute-server-hard-drive>`. On a substitute server after building a package is there a command I can use to add that package to the substitute server's cache?
<civodul>bone-baboon: hi! the first step would be to check whether the Python/GnuTLS being built really are the same as those available on the server
<civodul>if you run with -v3, their store file name will be displayed
<civodul>then you can check whether it exists on the server
<civodul>next, you can check what 'guix publish' replies using wget
<liltechdude>Hello guys! How I can on the 'install' stage without Automake install info files?
<bone-baboon>civodul: In the output of `wget -O - http://example.org/<gnutls-hash>.narinfo` is StorePath: /gnu/store/<hash>-gnutls-3.6.15.drv. It also lists gzip, zstd and lzip. The store path in the substitute servers response matches what `guix pull --substitute-urls=<...> -v3` said was being built on the client computer.
<rekado>liltechdude: you don’t need automake to install info files.
<rekado>you need automake only to build the makefile
<civodul>bone-baboon: looks like <gnutls-hash> is the hash of the gnutls-3.6.15.drv, where it should be the hash of gnutls-3.6.15 (without ".drv")
<liltechdude>rekado: okay, I have 'texi' file, how I can (or where should read about this) install this files as info pages?
<rekado>liltechdude: I need a bit more context. Is this for Guix or for some other package? It depends on what machinery you have. If there’s a texi file there’s likely also a build system target to turn that into an info file.
<roptat>liltechdude, if you have a Makefile, you can usually call "make whatever.info" to turn whatever.texi into that info page, otherwise you can also manually call makeinfo
<bone-baboon>civodul: I also get a wget response from the substitute server with a store path matching the hash for /gnu/store/<hash>-gnutls-3.6.15 (which I found in the pull -v3 output) which has a different <hash> than the ...-gnutls-3.6.15.drv
<roptat>liltechdude, sorry, actually I'm not sure I gave you an answer to your question, I'd like to get more context. Is that guix's own git repo, one of your project, or a guix package you're trying to make? or something else?
<liltechdude>oh, I supposed that after installing all thing would automatically werks
<liltechdude>maybe in some recipe all thing like updating system variables already done?
<roptat>no, when you install a package, guix will update etc/profile according to what's in your profile: to have a variable definition, you need a package that defines that variable (like texinfo or info-reader), and a package that provides at least a file that creates that path
<roptat>so to set INFOPATH, you need info-reader to provide the definition, and your package to provide a manual so the definition is present in etc/profile
<roptat>then you need to reload. In your current terminal, you can temporarily set the variable with ". $HOME/.guix-profile/etc/profile"
<roptat>you can also inspect the file, or the output of "guix package --search-path"
<liltechdude>roptat: this is my mistake (I must include section in texi file that say to emacs how to display file in info dir page)
<bone-baboon>I am trying to run `make` it the Guix repository. I am getting a command not found error for po4a-transalate. There are no search results for `guix search po4a-transalate`. What package provides po4a-transalate?
<bone-baboon>%base-packages is defined in the Guix repository in gnu/system.scm. There are packages that are part of %base-packages and that have names that do not match what can be found with `guix search`. They are (%base-packages name, guix search name): (iproute, iproute2), (guile-3.0-latest, guile), (util-linux+udev, util-linux-with-udev). I am unable to build the %base-packages package names with `guix build` but I can build the
<bone-baboon> name counterpart. Could someone explain the rationale for this?
<lfam>It's the difference between Scheme variable name and package name
<lfam>The rationale is that we don't always want those names to be the same. For example, we have several packages named "linux-libre", the difference being their versions. The variable names are how they are distinguished at the code level
<roptat>(well two tabs to give you the list of possibilities, since there's also monerod)
<davidl>Anyone here who happens to know which package may contain libgcc_s.so.1? Or can make an informed guess among any of the following packages: libgcc\* gcc\* libstdc++\* libgfortran\* libgcj\* libgomp\* libtool cpp
<lfam>Well, we got linked to, if not mentioned by name
<lfam>We could even start our own ID system, like GNU-VULN-0000
<apteryx>nckx: I've investigated a bit the /etc/profile(.d),/etc/environment(.d),etc situation w.r.t. how the non-standard variables are made available when commands are sent non-interactively via SSH. It's a rather complicated situation. The way Guix System does it itself is rely on 1. build time optional feature of bash (-DNON_INTERACTIVE_LOGIN_SHELLS) to source ~/.bashrc when invoked from sshd 2. On a
<apteryx>fragment of .bashrc sourcing /etc/profile, which does the heavy lifting.
<apteryx>we can't rely on 1. on foreign distribution (chances are Bash is not built with that feature)
<apteryx>/etc/environment, if present, would probably be used, but then its not a script and cannot handle sourcing other files such as $HOME/.guix-profile/etc/profile
<apteryx>a way that should work on foreign distributions right now with a guix-install.sh install guix is to have the environment correctly is to force the command through a 'login' shell, like so: 'ssh remote sh -l -c "guix describe"'; that should take care of sourcing the /etc/profile.d/guix.sh script
<bavier[m]>oh hey, just a friendly report that I just used the 1.3.0 rc installer image to reinstall and boot up my system. Seems to be working alright so far. :)
<lfam>Any idea about that `guix pull` permission denied error?
<davidl>iskarian: ok thanks, though how do I install it? gcc-toolchain appears to depend on it, but Im not able to simply run guix package -i gcc:lib as it switches to gcc-toolchain automatically..
<bavier[m]>a small annoyance in the installer, though: I chose the "manual install" method, if I switch to tty2 to read some docs, then switch back to tty1, I have to re-select the "manual install" option to get back to the terminal I was in.
<davidl>lfam: It is just an ugly hack. I do this: sudo LD_LIBRARY_PATH=$(find ~/.guix-profile/lib -maxdepth 1 -type d | xargs | tr -s ' ' ':'):$(find ~/.guix-profile/lib -maxdepth 1 -type l | xargs | tr -s ' ' ':') ./drawio-x86_64-14.5.1.AppImage and I get this;
<davidl>/tmp/.mount_drawio0ZyWKF/drawio: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
<lfam>"Alternatively, the --expression option may be used to specify a Scheme expression that evaluates to a package; this is useful when disambiguating among several same-named packages or package variants is needed. "
<lfam> '(@@ (gnu packages gcc) gcc)' is a package; the lib output of the GCC package is not a package
<davidl>lfam: ok. So basically, do you know if there is any way at all to install the lib output of gcc in a convenient way, or do I need to write a package module and redefine the package with (define-public ... ?
<lfam>I would just install the GCC package, but I still don't think it's the right thing to do here
<lfam>Like I said, we hid that package because it doesn't work on its own
<lfam>Additionally, the error message "error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory"
<davidl>lfam: I did, but still find ~/.guix-profile -iname '*libgcc*' does not give me the file I was looking for: libgcc_s.so.1
<lfam>I don't know how to make binaries compiled for other operating systems work on Guix
<lfam>There are some hacks to make it work, but I don't know them
<lfam>They are expecting many things to be in certain places, but Guix does not provide them
<davidl>essentially, AppImages are supposed to work on their own, but shared object files are hardcoded to /lib and /lib64 which I have symlinked to ~/.guix-profile/lib, though I still need the shared object files installed in ~/.guix-profile/lib
<lfam>I vaguely remember somebody using the extra-special-file service to provide the Guix linker / loader in the expected location, and binaries compiled for other operating systems worked (or almost worked)
<lfam>Right, AppImages and all the other "app bundles" are not actually self-contained
<lfam>They still expect a standard old-school Linux environment
<iskarian>honestly probably easier to run them in a lxc running a more standard environment
<davidl>lfam: what are the thoughts on supporting a package or a service that sets up symlinks in the right places that make these bundles work? For example, if AppImages generally require fuse and symlinks from /lib and /lib64, an AppImage service could provide the installation of fuse and special-files-service (or whatever that thing was called).
<lfam>It's not what I was looking for but it's related
<davidl>now the question is still where libgcc_s.so.1 exists.
<davidl>General question to guix maintainers: patch review order policy? My patch submissions are generally pretty small, but when I do work on a patch and submit it, I have no idea about when or if it will actually be reviewed. So far, the majority of patches I have sent have been reviewed, but when it takes a while like 2 weeks or more, I am concerned that my efforts have been wasted and I don't think Im the only one. If there was a policy and you could just
<davidl>say something like "currently there is 2 weeks backlog but we are working on it", it would feel like the risk of me wasting my time is much smaller.
<lfam>Maybe it's the wrong approach but it's what happens
<davidl>lfam: ok. I had a package I worked on which required probably 20+ packages to 2 different package modules, but then to submit I would need to split the commits up in separate packages carefully, but so I never did because I was worried it would never get reviewed anyway.
<lfam>Somebody who seems to have worked on related packages before
<davidl>lfam: thanks. So maybe for now, the best thing is to ask someone before working on a patch-set, whether they're up for reviewing it once it's ready. I don't think it's a great solution. I guess the project just needs more full-time maintainers who can review patches. In a way it's a good sign of interest in the project though, that there are more patches sent than can be committed :-)
<lfam>To clarify: maintainers are not the same thing as committers
<lfam>There are only 5 maintainers and they aren't directly responsible for code review
<lfam>I agree we need more people reviewing but it's not easy to make volunteers do this task
<lfam>There are several dozen committers, however. And code review can even be done by non-committers, and I do value that kind of code review as a committer
<apteryx>nckx: re /etc/environment, perhaps the statu quo is not that bad after all; we *could* migrate the content of /etc/profile.d/guix.sh to /etc/environment.d/guix at least on systemd machines, with the exception of sourcing $HOME/.guix-profile/etc/profile, which seems like a deal breaker to me (it will work for some applications and then not for others, because some environment variable will be missing)
<lfam>Code review is pretty hard work, requiring strong level of focus on technical matters, a sense of "what's cooking" in related code, and emotional resilience
<lfam>davidl: Something you can do to improve your chances with code review are to say whether or not the packages build or not, pass lint or not, work for your use case or not, etc
<lfam>It's surprisingly common to apply patches for review and see that these tasks have apparently not been performed. And that's demotivating
<chikamungus>Hi lovelies! I understand xorgs settings are meant to be set by gdm or whatever login manager but in my autogenerated config.scm from my install, the xorg-configuration keyboard-layout is set in xfce-desktop-service-type in the services section. Why is that? I want to get my head round what is going on before I add some needed extra xorg config stuff
<iskarian>efraim, in your gccgo > go patch from a few years ago, you suggest that go wants to be built with the gcc from the gccgo build... do you recall where you found that info (or, by trial & error)?
<iskarian>I've never seen it in e.g. xfce-desktop-service-type, though I have seen it in alternate dms like slim-service-type
<iskarian>My understanding is that you either put a (xorg-configuration (xorg-configuration (keyboard-layout ...)) in the DM service, or you add a separate service (set-xorg-configuration (xorg-configuration (keyboard-layout ...)) which will communicate that to whatever DM exists
<nckx>davidl: git send-email tip: you can write whatever you want under the first ‘---’ and git will not include it in the commit message. Saves reviewers some work compared to having to remove ‘Hi! etc.’ manually from an otherwise perfect commit message, which of course you will write.
<chikamungus>thanks iskarian, that's useful. My worry is if it's put in xfce-desktop-service, it won't be set in other desktops and it seems a strange thing for the graphical installer to do
<chikamungus>as it is, it's a us keyboard layout which is probably what xorg would default to anyway
<nckx>Does xfce-desktop-service-type provide a display manager?
<nckx>chikamungus: Can you share the auto-generated configuration? I'm curious.
<chikamungus>You know what, I'm reading the scheme all wrong and I'm being daft
<nckx>OIC, you thought ‘guix container exec’ created containers.
<davexunit>back in 2015 I figured I might improve this tool some day... oopsies
<nckx>Try something like ‘guix system container /my/system.scm’ and run the resulting script. Then look up the PID of that script using you favourite process manager. Then use ‘guix container exec <PID> <COMMAND>’.