<apteryx>jpoiret: yes, the *Warnings* :-) seems related to emacs comp or something <apteryx>uh, error: X.509 certificate of 'disarchive.ngyro.com' could not be verified <kitty4>I'm going around cleaning my guix configurations, I remember seeing a nice list of lots of example configurations at one point ;; although I am struggling to find it, where could it be? <kitty4>or just like, any good example systems <kitty4>particularly trying to figure out how to more properly manage packages because my current setup is ugly af, but also just in general seeing what I can learn! :> ***rgherdt_ is now known as rgherdt
<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>flypaper-ultimat: I haven't noticed that <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) <abrenon>oh, your $GUIX_ENVIRONMENT/share/info is non-empty and has this weird dir loop ? <abrenon>then I'm afraid it is a your-side problem, sorry <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. <flypaper-ultimat>so as a temporary solution, is there a way to force removal of something in the store? <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)). <abrenon>I have no idea personally but I suppose looking at guix/gc.scm would be a way to answer it <abrenon>so you still have a garbage-collection issue, but the link is not at fault ? <cbaines>flypaper-ultimat, I don't think self referential store items are a problem. <cbaines>If it can't be reached from a GC root, it should be a candidate for removal <cbaines>as for the referrers, I believe there's information in the guix-daemon database, but this can also be computed by looking through the store <flypaper-ultimat>cbaines: thanks for mentionioning GC root , that pointed me in the right direction. <flypaper-ultimat>i found that /var/guix/gcroots/auto/ contained symlinks to ~/.cache/guix/profiles/ <flypaper-ultimat>and those would be created when you would "guix shell" or make a new profile with "guix package". <flypaper-ultimat>so removing the symlinks in ~/.cache/guix/profiles/ would allow "guix gc" to no longer consider these throw-away profiles to be alive, and thus be elligible for garbage calloction. <flypaper-ultimat>funny thing was, i did a search through the info pages for guix for "cache" before contacting you, and couldnt find anything then. <flypaper-ultimat>though a closer reading of "guix shell" `--root' info clarifies some bits <Luk6655>is it possible to list files installed by guix package? <Luk6655>efraim: doesn't this just list installed packages? <rekado_>Luk6655: find $(guix build the-package) <rekado_>“guix build foo” returns the location in the store, e.g. /gnu/store/…-foo <Luk6655>rekado_: great, yes it works, thanks :-) <rekado_>what you cannot do, unfortunately, is ask Guix what package might contain a certain file <Luk6655>I was hoping bluez might contain hciconfig (for bluetooth), but no, it doesn't <Luk6655>it has some other files that look like they may serve the same purpose though <Luk6655>flypaper-ultimat: great, thanks, bookmarked :-) <faust45>and got: guix system: error: symlink: Permission denied: "/var/guix/profiles/system-147-link.new" <cbaines>faust45, are you reconfiguring as root (using sudo or otherwise)? <rekado_>faust45: only root can reconfigure the system <faust45>one more question, got this guix no target home profile for home shepherd <faust45>(service home-redshift-service-type) <Luk6655>it seems I need libffi 3.2 while the current one in guix is 3.3. Is there a better way to find the previous version than searching the git log of guix repo? <Luk6655>cbaines: wow, this page will be so useful to me, thanks <cbaines>so the latest revision with libffi@3.2 is c81457a5883ea43950eb2ecdcbb58a5b144bcd11 (from 2020) <Luk6655>yes, I seem to remember there was some switch to tell guix package to use a specific commit, if not, I can extract it and install from file <Luk6655>ideally it would be great if I could specify this version in inputs of another package, but I doubt that is possible <flypaper-ultimat>Luk6655: though i'm uncertain if that works in the libffi since it just dowloads a tarball? <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 libffi@3.2 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>inferior specifies the channels and consequently commit, but not the module location <Luk6655>is it not necessary? Will the inferior search the entire namespace(perhaps there is a different term for it, but I hope it is understood what I mean by it)? <jpoiret>Luk6655: yes, it will search the entire package list <jpoiret>the same as specification->package used for example in the CLI <Luk6655>cool, I'm just trying it in repl, it is taking a while as it needs to do its whole thing from scratch <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? <Luk6655>this was while running guix pull, after updating the package to include the inferior <Luk6655>with a package pulled from the inferior in its inputs <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>You can do "./pre-inst-env guix build ..." to use the local (modified) git checkout of Guix, likewise you can do "./pre-inst-env guix system reconfigure ..." <antipode>Luks6655: --disable-authentication is insecure. <antipode>--disable-authentication disables authentication of _all_ the channels, including the Guix channel. <Luk6655>but I have a local fork... of course here I'm trying to use the inferior which bypasses my local fork so you have a point... <Kabouik>When using reconfigure with `./pre-inst-env guix system reconfigure `/.config/guix/config.scm`, should I use sudo as usual when reconfiguring too? <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? <Luk6655>I initially thought this non-self-quoting has something to do with it, but the exact same code worked in repl <antipode>I think I might know the issue -- all builds (except for fixed-output builds, but that's not the case here) do _not_ have network access. <Luk6655>here the only difference is that we have a number of use-module statements in front <antipode>(and neither access to /arbitrary/file/system/file-name) <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. <Luk6655>perhaps it clashes with one of modules I import? <Luk6655>I think I'll try removing bits to see what happens <antipode>Luks6655: going by the various packages there, your goal appears to be to package something non-free. <Luk6655>I'm not trying to promote it, right? <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 <Kabouik>Just to disambiguate the two intertwined conversations, my package change in cyrus-sasl has nothing to do with non-free things <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 <ulfvonbelow>for what it's worth, I'm able to use some custom out-of-repo packages with a ./pre-inst-env invocation by setting GUIX_PACKAGE_PATH <ulfvonbelow>though I probably should just make a channel out of them, to ease deploying to other systems <ulfvonbelow>I recall a long time ago having issues with GUIX_PACKAGE_PATH and -L not doing exactly the same thing <maximed>Luks6655: AFAICT level-zero does not use guile-json. <maximed>Do you have a (free) package that needs a package from an inferior? <Luk6655>maximed: no, it doesn't, I don't need guile-json, it is just a copied comment from the example in the manual <jpoiret>it seems that it's just the inferior system that's broken, i'm not sure there's an free/nonfree distinction <Kabouik>Could you share the full command please ulfvonbelow? ***maximed is now known as antipode
<antipode>jpoiret: I think I found the problem, will send a bug report <antipode>inferior-with-channels is eager (not lazy), so it cannot be used in a channel on the top-level, as builds (including channel builds) are isolated from the network <jpoiret>you mean, it builds while compiling? <antipode>I meant during the build of the channel itself, not the packages inside the channel. <antipode>("guix pull" makes a derivation for each channel, to turn the .scm->.go IIUC) <jpoiret>yeah, but that shouldn't trigger a build, right? <antipode>The build of the channel is a build -- as I wrote previously, "guix pull" makes a derivation for each channel. <jpoiret>or maybe the compiler is trying to compute the top-level constants <jpoiret>I know, but I don't see how the relevant .scm file being compiled into a .go would trigger the inferior building process <antipode>In Guile, if you compile a module '(foo)' which uses the module '(bar)', Guile will load (bar) because it might have macros. <jpoiret>arf, i just remembered that files are loaded in order to be compiled <jpoiret>yeah, and guix goes further iirc and loads every file first <Luk6655>jpoiret: thank you, I was just looking at the bug <Luk6655>I'll try it now, I might need to disappear though <ulfvonbelow>Kabouik: GUIX_PACKAGE_PATH=$HOME/Programming/my-packages sudo -E ./pre-inst-env guix system reconfigure /etc/config.scm <Kabouik>Thanks ulfvonbelow. Unfortunately that still fails with my config.scm: no code for module (nongnu packages linux) <jpoiret>antipode: i wonder if we couldn't just add an with-inferior-build-system that would delegate lowering to a derivation to an inferior <jpoiret>and pass it around with write-derivation/read-derivation on a pipe <antipode>I suppose we could, don't know about the pipe, I'm not that familiar with inferiors. <Kabouik>To be clear, $HOME/Programming/my-packages is the location of your edited version of the Guix repo, or is it the folder where you have your extra channels? <jpoiret>that way, you could just do (define that-package (package (name "xx") (version ...) (build-system inferior-build-system) (arguments (list #:channel channel-obj)))) <ulfvonbelow>that's where I've got some extra package definitions I haven't bothered making a channel for, but it should be functionally equivalent to a channel for purposes of GUIX_PACKAGE_PATH <ulfvonbelow>also, you can always switch 'guix system reconfigure' out for 'guix repl' and do some interactive poking around <jpoiret>how are you using (inferior) Luk6655? <jpoiret>depending on where it appears it could lead to the same issue <Luk6655>I'm about to replace the whole file with just few lines to try again <Luk6655>yes, I did just to show what I'm referring to, I'll try your paste exatly with nothing else in the file <jpoiret>the last line is not code but a suggestion <Luk6655>well, I can't really use your code exactly, because it has (use-modules <Luk6655>while module definitions need #:use-modules <jpoiret>yes, just put that into the #:use-module <jpoiret>maybe call it inferior-for-pkg instead of inferior <ulfvonbelow>Kabouik: of particular interest in 'guix repl' would be the value of %load-path and %load-compiled-path <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 <jpoiret>on my computer, this code doesn't do anything, it's loaded and that's it <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>alternatively, you could just modify your channels.scm to point to your local checkout, then 'guix pull' <Luk6655>jpoiret: it was a copy/paste problem, the code is supposed to be put in an scm file in a channel <Luk6655>then when you run guix pull with that channel you get the error <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) <apteryx>ulfvonbelow: that seems to be per warning though <jpoiret>I've never seen those, are you using up-to-date packages? <apteryx>both system and user profiles are from yesterday <jpoiret>well, maybe that should be reported upstream to cmake then <apteryx>I guess perhaps native-comp-async-report-warnings-errors; it seems to default to #t <jpoiret>oh, is there native-comp on master now? <jpoiret>i'm still using a native-comp-less emacs <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>Something I would find useful, is a combination of "git pull" or "git rebase" and "guix git-authenticate" <antipode>To avoid the TOCTTOU of "make authenticate" <civodul>i don't see where there's a TOCTTOU race? <civodul>i mean, if you run the command s sequentially youself, it should be fine, no? <maximed>civodul: Currently, it's like verifying the authenticity of a gnupg tarball, by extracting the gnupg tarball, compiling it, and running the freshly compiled gnupg tarball. ***maximed is now known as antipode
<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. <two[m]>hi, is there a channel for shepherd? <apteryx>oh, evince not opening PDFs anymore post update? or is it jus me <efraim>apteryx: new commit about 2 hours ago to build evince with a newer poppler, worth trying out <boji3>So peeps do you have any ideas about that efibootmgr problem, been at it for days *unmatched-paren 's ethernet cable has once again decided it doesn't want to work :( <rekado_>I forgot everything I knew about “guix archive”… <rekado_>I tried this: guix archive --export --recursive $(readlink -f env) > cache-env <rekado_>and then I tried to look at the contents with “guix archive -t < cache-env” <rekado_>but I get this error: guix archive: error: corrupt input while restoring archive from #<input: file 0> <rekado_>is there something obviously wrong in how I use it? <apteryx>where are the SSL_CERT_DIR/SSL_CERT_FILE of openssl documented? <apteryx>rekado_: yes, because the guix archive command operate on a single archive <apteryx>I don't think that's very convenient; we could extend it to understand the format it produces with export (which is just a list of archives) <apteryx>weird, openssl manpages only mention SSL_CERT_DIR in its util openssl-rehash. SSL_CERT_FILE is not mentioned at all. <rekado_>it shows this example: guix archive --export -r $(readlink -f ~/.guix-profile) | ssh the-machine guix archive --import <rekado_>aside from SSH I don’t see how this differs from what I do <ulfvonbelow>could be that --list only works with a single nar, while both --export and --import can work with a sequence of appended nars <apteryx>uh, the very ill-named SSL_CTX_set_default_verify_paths manpage has it (SSL_CERT_DIR and SSL_CERT_FILE explanations) <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? <two[m]>admins: above seems to be a cryptocurrency scam <tom-1>two: did you understand what you wrote? <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 