<flypaper-ultimat>hey all! Recently whenever i create a non-empty profile through either "guix shell <some-packages>" or "guix package -i <some-packages> -p /path/to/somewhere" the /share/info directory will contain a symlink to "dir" that is a link to itself, thus the profile its own referrer for "guix gc --referrers /path/to/profile", and thus always being marked as "alive", and so it cannot be gc'd. Anyone else have this problem? (i'm on guix system,
<abrenon>the share/info/dir in my /run/current-system points to somewhere in the store as I suppose it should
<abrenon>I've just spawned a shell with a new package (awesome, for the sake of the test), share/info is empty so I suppose being non-empty is not a sufficient condition on the profile to trigger the issue if there is one
<flypaper-ultimat>ah ok, if i do a "guix shell awesome" and then invoke guix gc --referrers $GUIX_ENVIRONMENT it does refer to itself.
<abrenon>what do you mean ? what is "it" in your last sentence ? which path should I check to see if I reproduce the issue here ? I've tried $GUIX_ENVIRONMENT/share/info (empty) and /run/current-system/profile/share/info (but which is the same as from outside the container, and I think that's expected)
<flypaper-ultimat>maybe related is that beefore I had a problem a package from an previous "guix-shell" environment would be in my new guix shells, doing a guix shell --rebuild-cache seemded to clear that up, but now this is here.
<abrenon>I suppose mounting from outside and being able to simply toy with the directory will do it, but at what cost (I suppose guix-daemon won't like it after the reboot when it sees things were altered)
<flypaper-ultimat>sorry i'm wrong. theres no "info" loopy linkk, i was misreading the symlink, its not a self-link. nowhere is a symlink to itself, (if i run "find -type l $GUIX_ENVIRONMENT -ls" they are all pointing to where i expect them)).
<Luk6655>flypaper-ultimat: thanks, I'm writing a new package definition and it needs libffi 3.2, possibly the easiest would be to extract libffi 3.2 from that commit and define it as libffi with version 3.2, then use firstname.lastname@example.org in inputs. Or isn there a better way?
<flypaper-ultimat>Luk6655: I like to use a private channel in such case with that libbfi, but i don't know if that is best practice, inferiors like cbaines said might be a more encouraged solution?
<Luk6655>yes, I'm doing that in another channel. Probably an inferior is better, I would need to read up on it again to be able to implement it.
<Luk6655>reading about it now, it seems inferior feature was created precisely to resolve this problem
<Luk6655>I't doesn't seem that difficult, I'll give it a try
<Luk6655>yes, however, trying to use it in a package input I got an "interesting" error message: "(exception %exception (non-self-quoting 140736920090368 "#<&store-connection-error file: \"/var/guix/daemon-socket/socket\" errno: 2>"))" any ideas?
<mbakke>roptat: do you think it's feasible to change the default JDK of ant-build-system to openjdk17?
<Kabouik>I'm trying to edit the cyrus-sasl package to add a --enable-login option in the configure phase. Once I have rebuilt it with ./pre-inst-env (if it works), how can I tell my Guix system to use that package instead of the one from upstream Guix?
<Luk6655>hmm, just adding "define inferior" causes this error to pop up on guix pull... They do warn in the manual inferior is an experimental feature, so I guess this is some bug as I think I'm doing pretty much what the example shows.
<Luk6655>If anyone recognises this: #<&store-connection-error file: \"/var/guix/daemon-socket/socket\" please let me know
<Luk6655>the file does exist btw, it is owned by root, but rw by everyone
<antipode>Luks6655: Usually, when an error message like that is printed, it is only part of the error message, with an associated backtrace
<antipode>Did this (exception %exception ...) come with a backtrace?
<Luk6655>no, it didn't, let me paste the output and the log file in a sec
<antipode>Also, do you have a minimal reproducer, that other people can use to test things.
<antipode>Kabouik: With "guix system reconfigure".
<antipode>Kabouik: Yes (otherwise it will just fail because of lacking permissions), I don't know if the 'sudo' goes before or after the ./pre-inst-env though, and I don't know if special flags like -E are required or not.
<Luk6655>If I comment out the (define inferior ...... ) bit the error disappears
<antipode>The first paste has a line 'View build log at '/var/log/guix/drvs/7z/z07zlyc4jzi6s9cnvg05sjrxsc6ns4-guix-hpc-non-free.drv.gz', what does it contain?
<Kabouik>I'm getting errors with all combinations of sudo/sudo -E, before or after ./pre-inst-env. I think it might be due to my config.scm importing (nongnu packages linux), which is not in my cloned guix repository. Somehow the command does not use my channels.scm when using ./pre-inst-env?
<antipode>Kabouik: IIUC, yes, ./pre-inst-env only uses the _local_ Guix, not whatever you have in ~/.config/guix/current
<antipode>Try -L to make additional things available.
<antipode>No, but you're asking me to help you with packaging non-free things.
***Dynom_ is now known as Guest1758
<Kabouik>-L does not seem to help antipode, I'm asking in the channel that shall not be named as well, since it's related.
<antipode>You don't have to hide if you are using non-free software, but I won't help you with it either.
<antipode>Kabouik: There are people using free channels too, -L works equally with free channels.
<Luk6655>antipode: that's fine, everyone has right to their convictions etc
<antipode>Kabouik: (and there doesn't appear to be a goal to increase non-free things)
<antipode>Kabouik: -L is not a flag, you need to add a directory
<Kabouik>Oh I know, that is not what I meant. But my config does use the Linux kernel for hardware reasons. I just thought that users of that kernel may have faced the same issue with ./pre-inst-env, but so do those with custom channels used in their config.scm too of course
<Luk6655>I wonder if I even get the same error, with no package defined. At the end of the day, I can simply copy the package I'm interested in without using the inferior, but I'm interested in finding out if this is a bug, or some issue with my system
<Kabouik>That is what I am getting ulfvonbelow: https://0x0.st/oOSn.png I feel there must be a solution I am missing, because I can't change my kernel to test the custom version of my cyrus-sasl package defintion
<ulfvonbelow>re: guix repl, keep the setting of GUIX_PACKAGE_PATH and the sudo -E and all that, just swap 'guix system ...' with 'guix repl'. That way you'll see it exactly how guix sees it when reconfiguring
<jpoiret>Luk6655: are you sure? You're missing a closing parenthesis
<ulfvonbelow>also, I think I see the problem - I think you're trying to use the guix profile built by 'guix pull' that's symlinked from ~/.config/guix/current (although you're telling it to use ~/.config/guix), but the issue is that, first, that's not a channel directory, that's a complete profile - the top-level directory looks like ("bin" "share" "lib" "etc") and so on. To access just the guile source, you'd want
<ulfvonbelow>~/.config/guix/current/share/guile/site/3.0. But second, that's going to contain the code from /all/ of the channels, including, presumably, the upstream guix. GUIX_PACKAGE_PATH is *prepended* onto the guile search path IIRC, so you'd just be using the same code as the guix installed by 'guix pull' does.
<ulfvonbelow>basically, you want to use GUIX_PACKAGE_PATH to point it specifically to the *other* channels, not to a combination of the other channel you want to use and an older version of itself
<ulfvonbelow>so you'd need a local checkout of the various channels you use
<ulfvonbelow>which, most likely, you already have, somewhere in ~/.cache/guix/checkouts
<ulfvonbelow>alternatively, if you have a checkout somewhere else, you can point it there.
<ulfvonbelow>regarding GUIX_PACKAGE_PATH not getting picked up in 'guix repl', that's an oversight on my part - the code that modifies the search path is in (gnu packages) (and is run at module-load time!), and I guess 'guix repl' doesn't automatically load that.
<Kabouik>Thanks a lot ulfvonbelow. `GUIX_PACKAGE_PATH=/home/mat/.cache/guix/checkouts/l74zueb3lgylhgxnuzx3d5fzraztxvzu2s4466wlqqvmz7hdct3a sudo -E /home/mat/Projects/guix/./pre-inst-env guix system reconfigure ~/.config/guix/config.scm` seems to work (it's busy currently). It's a bit convoluted though, I hope I'll find that in my command history every time I need it!
<ulfvonbelow>it would be nice to have tooling that allows a combination of 'guix pull' management and manual management, so you can, for example, use code from a local checkout without also needing to manually obtain/find local checkouts for all the other channels you use
<Kabouik>I think I don't really know what the concept of local checkout means for Guix. Do they get updated when I guix pull?
<ulfvonbelow>my understanding is that the repositories in ~/.cache/guix/pull which are in your configured channels get updated when you pull, yes
<Luk6655>unfortunately I don't know how to make inferior-with-channels lazy (I'm not even sure what it means in guile/GUIX), when I have some extra time later I might do some research on it
<Kabouik>Yes I think this is complicated (probably because it's not simple to implement otherwise) for a task that I would assume is quite common: editing an upstream package and testing it locally. So far I only did that with binary files running on their own, so I could just use their real path and execute them to test them, but here with cyrus-sasl I faced a new difficulty
<ulfvonbelow>a way to avoid the issue would be to do system-related testing of guix packages in a vm, where one would assume other channels are not necessary for them to be tested. Of course that'd introduce its own complexities.
<apteryx>why does a *Warnings* buffer keep popping up in latest Emacs on Guix, e.g.: "Warning (comp): cmake-mode.el:434:8: Warning: docstring wider than 80 characters Disable showing Disable logging" -> thanks, but I don't care :-) How can I keep it out of my way?
<ulfvonbelow>apteryx: I would guess that pressing the "disable showing" button listed would do the trick
<jpoiret>sneek, later tell Luk6655: the code i gave you should do exactly that (deferring the calculation of inferior-with-channels)
<jpoiret>seems that by default the emacs build system doesn't build .elc files though :(
<apteryx>the docstring of the native-comp-async-report-warnings-errors variable suggest setting it to 'silent should behaves better: no pesky *Warnings* buffer pop-up, but warnings logged in *Messages*
*apteryx slaps (setq native-comp-async-report-warnings-errors 'silent) in their ~/.emacs file
<ulfvonbelow>which compression algorithm do ya think would work best for a tarball containing a large build tree?
<ulfvonbelow>lots of source files, lots of build system files, lots of object files
<jackhill>it might be neat if `guix git authenticate` would remember the introduction, to make it more convienient to re-authenticate a repository after pulling
<Kabouik>The reconfigure is still ongoing ulfvonbelow, I sure hope cyrus-sasl will work expected after that!
<Kabouik>This is by far my longest reconfigure so far, I wonder if extra stuff is being built compared to when I just run sudo guix system reconfigure file.scm
<ulfvonbelow>hmm, is your local checkout (the one you're running ./pre-inst-env from) much diverged from the pulled one?
<civodul>jackhill: hi! yes, it could keep it in ~/.cache or something along these lines
<Kabouik>No, I don't think it is (I would know if I did something special with it, I guess).
<ulfvonbelow>I'm just used to waiting forever for stuff to build ever since I modified mesa locally
<Kabouik>I actually didn't change anything in nonguix, just in my cloned version of guix
<jackhill>civodul: cool! glad to hear that it's a reasonable idea
<civodul>jackhill: it definitely is! the tool is inconvenient to use currently
<civodul>i hadn't thought of caching the intro, but that would be a simple way to improve the situation
<antipode>(1) You run "git pull" (2) an attacker has intercepted the network connection and modified Makefile.am's authenticate target to always 'succeed'. Additionally, the attacker inserts some malicious code somewhere (e.g. some code in Makefile.am to upload your GnuPG keys to evil.com). To add some stealth, the modified Makefile.am automatically reverts the malicious commit. (3) You run "make authenticate" as recommended by the manual, and now the attacker has y
<antipode>* and now the attacker has your private keys.
<antipode>* running the freshly compiled gnupg tarball -> running the freshly compiled gnupg, even though it might have been malicious
<ulfvonbelow>that's why you "guix git authenticate" instead of "./pre-inst-env guix git authenticate", right?
<ulfvonbelow>or am I misunderstanding what "guix git authenticate" does?
<boji3>Hey I am having problems with fresh install on my pc, been at it for days now. Its completely fresh install with no edits to config and doing it through graphical installer with encrypted partitions. During gnu/store install /efibootmgr option requires and argument -- "d" which is listed as --disk disk and lower part of error is failed to register the boot entry operation not permitted, pls help :)
<antipode>ulfvonbelow: yes, but to be clear I was referring to "make authenticate"
<antipode>Even then, currently "git pull + guix git authenticate" (and "make authenticate") is inconvenient for anyone that isn't a committer, because their key will be rejected.
<antipode>So currently you have to switch to the upstream branch first, do the authentication (copying the COMMIT and SIGNER from the manual), switch back, and rebase (or maybe merge, though myself I rebase)
<ulfvonbelow>yeah, it would be nice to be able to specify to authenticate a certain branch, like origin/master
<Reza>Hello. When I was trying to install guix I got a long error:
<Reza>That says the installer has encountered an unexpected error. And asked me to send it to a special email.
<ulfvonbelow>looks like the info page on "invoking guix archive" does indeed specify a difference between the "single-item" and "multiple-item" archives. Apparently the single-item archives come basically exclusively from substitute servers.
<tom-1>Hello . Please tell me how to install bisq on guix? Maybe someone has tried it?
<apteryx>as long as it's free software, you could try packaging it, if you wish
<tom-1>apteryx: thanks a lot for your reply. Please tell me how to do it yourself? I would be grateful for help!
<apteryx>bisq appears to be written in java; you could have a look at other packages in (gnu packages java) to get started, along the Guix reference manual and perhaps other introduction material (blog posts, etc).
<tom-1>and I have another question, can I trust this application from an ethical point of view?
<two[m]>"before you can start trading, you'll need [$200] for a security deposit"
<apteryx>tom-1: i'm afraid that's a too broad question for me to answer, especially not knowing the software
<tom-1>apteryx: in any case, thanks for the answers, maybe someone from the community installed. From decentralized ethical systems, there is not much choice.
<Kabouik>That guix system reconfigure just to check a little change in cyrus-sasl is giving me a headache, still not finished and crashing my system because webkitgtk is eating my 16GB of RAM pretty fast. I should just have made a separate package and have added it to a channel to test it.
<apteryx>uh. segfault of qemu 7.1 when trying to run 'screendump /tmp/dump.png -f png'
<mbakke>Kabouik: depending on what you are trying to do, you can also "inline" the package definition in your system configuration
<mbakke>and use package-input-rewriting or similar