IRC channel logs


back to list of logs

<emacsoma1>what is the best way to set/export SBCL_HOME in Guix? (Trying to get stumpwm running properly here again.)
<the_tubular>Is there any "honeypot" stuff packaged for guix ?
<jgart[m]>xelxebar: TIL
<jackhill>the_tubular: probably not exactly a honeypot, but I know that we have endlessh. Unfortunately, I'm not that familiar with honeypot stuff to know what to check for
<abrenon>hi guix
<abrenon>I don't understand why all the examples to build guix from the repo call ./configure with the --localstatedir parameter, set to /var, when calling --help on it seems to show that it defaults to that
<abrenon>does it do something ? can I screw my local build if I fail to provide it ?
<abrenon>also, is a non-default value frequent enough for hackers around here that it wouldn't be safer to make ./configure default to that if that's not already the case ?
*abrenon is building all of guix for the third time in less than 24h
<civodul>Hello Guix!
<tex_milan>hello Guixers! How can I install rust version 2021 (or rust-nightly)?
<sneek>tex_milan, you have 1 message!
<sneek>tex_milan, nckx says: I'll have to dig through my backups && pray. Fired that client...
<rekado>abrenon: it does not default to /var. And yes, if you use a different value you will not be able to access the local guix installation’s database. This will cause Guix to consider everything in /gnu/store to be trash.
<rekado>configure does not default to /var because it follows GNU conventions
<abrenon>thank you for that rich answer !
<abrenon>do you mean that setting a default would be contrary to GNU conventions, or that the default should be different to follow them ?
<abrenon>also, what is the meaning of "[PREFIX/var]" in the help message ?
<abrenon>can't use my locally-compiled version to even display the new package I've added, it takes a huge amount of time complaining about all the .go files which would have an incompatible bytecode version
<abrenon>I 'make clean-go'ed twice since yesterday, and in addition re-./bootstrap and ./configure this morning
<abrenon>I shouldn't have stopped practicing for so long, now everything feels weird and not-quite-right
<abrenon>ok there's clearly something wrong with my install
<abrenon>I've done everything once again, in a pure environment
<abrenon>and I still get a flood of In procedure load-thunk-from-memory: incompatible bytecode version
<abrenon>what do I need to load colors.go to simply call ./pre-inst-env guix describe ??
<abrenon>ok, works from a totally fresh git clone
<abrenon>there's more to clean in a dir than the .go files ?
<civodul>abrenon: hi! "make clean-go" should have solved the "incompatible bytecode version" issues i guess
<civodul>but yes, there's also a bit of C++ compiled code and other things that "make clean" removes
<abrenon>yeah, that was it… ^^
<abrenon>sorry for spamming the chan
<abrenon>I finally got it to work, the build finished just a couple minutes ago
<civodul>alright, good to hear :-)
<abrenon>yeah, now I can finally try and finish packaging that software where I left several months ago ^^'
<abrenon>thanks again for the help everyone !
<abrenon>see you later
***wielaard is now known as mjw
<bovid-19>Hi guix!
***bjc`` is now known as bjc
<bovid-19>What's the correct syntax to specify the version of a package's input? I tried llvm@13 and llvm@13.0.1 (the version of llvm 13 that guix search finds), but I get an `unbound variable' error.
<singpolyma>bovid-19: you want the name of the variable in that context
<singpolyma>So there's no standard syntax, just whatever the version you want it called when it is defined
<bovid-19>singpolyma: Thank you for the quick reply. Unfortunately, I do not understand. Do happen to know where I could find an example that uses a specific package version as an input?
<singpolyma>bovid-19: every input does that
<singpolyma>You need to find the package version you want to use. I think guix show package@ver on the cli will tell you what file to look in
<singpolyma>Assuming the version you want is in guix of course
<bovid-19>Either I still don't get it or it might be a bug or some other problem. I want to package clasp 1.0.0, which needs LLVM 13. Is there something wrong with `(native-inputs (list llvm@13.0.1 ))' if I want to achieve that? LLVM v13.0.1 is available in guix and I have `#:use-module (gnu packages llvm)' in the `(define-module (gnu packages lisp))' form at the top of `lisp.scm'.
<singpolyma>bovid-19: it's probably just (list llvm)
<singpolyma>But you'd have to read the code to be sure
<singpolyma>If there were a 13 specific one it would likely be (list llvm-13) but again, would have to read the code to confirm
<singpolyma>The guix show output should say what file to look in. Or you can use guix edit to open it
<bovid-19>Right, it's `llvm-13'. Thank you!
<GNUtoo>hi, are we supposed to be able to run ./ && ./configure && make in guix or is that not supported?
<GNUtoo>More specifically is there some way to make pkg-config work out of the box?
<rekado>GNUtoo: why wouldn’t it work?
<GNUtoo>In my case it doesn't find openssl
<GNUtoo>I don't know if it's related to what I'm building or Guix
<GNUtoo>Parabola: $ pkg-config --libs openssl => -lssl -lcrypto
<GNUtoo>Guix: $ pkg-config --libs openssl => Package openssl was not found in the pkg-config search path.
<GNUtoo>guix package -I | grep "^openssl" => openssl 3.0.2 [...]
<GNUtoo>and I've also openssl in my system.scm
<GNUtoo>so something needs to set PKG_CONFIG_PATH
<GNUtoo>or maybe I need to install things
<GNUtoo>or maybe it's unsupported
<olnw>you could try find / -wholename "/gnu/store/*openssl.pc"
<GNUtoo>yes, but how do I make it work out of the box?
<rekado>GNUtoo: the pkg-config package has a PKG_CONFIG_PATH search path specification.
<rekado>perhaps you’re overriding it?
<rekado>GNUtoo: this works, and I know that because we’re relying on this search path specification to use pkg-config in thousands of Guix packages.
<GNUtoo>aha if I install pkg-config with guix package -i pkg-config it works
<GNUtoo>but if I install it in my system.scm it doesn't
<GNUtoo>Thanks a lot for the information
<GNUtoo>I still wonder if there is a way to make the one in the system.scm work, but at least I've a workaround that works now
<GNUtoo>Maybe it's something related to my strange configuration though
<bovid-19>I tried to send a patch for adding `btop' via mail, but the mail was rejected. Another patch from the same email address and server had been delivered before. Anyway, if someone else wants to add it:
<wdkrnls>Dear guix, I was hoping to try using guile-xosd to make a Hello World example for myself to consider it as a tool for desktop notification. However, I couldn't figure out how to get Guile to see the module after I installed it with Guix. Can someone suggest what the arcane ritual is to tell guile where to look for modules installed via Guix?
<civodul>wdkrnls: hi! if you install both Guile and guile-xosd in the same profile, it should set (or suggest setting) the GUILE_LOAD_PATH environment variable
<wdkrnls>civodul: hi! Should I expect that to not be available by default then?
<wdkrnls>I was hoping it was going to be as simple as ,use(xosd)
<alethkit>What's the easiest way to temporarily use Node 16? The latest version seems to be Node 14.
<wdkrnls>The GUILE_LOAD_PATH environment variable is set to /run/current-system/profile/share/guile/site/3.0 for me.
<wdkrnls>I'm wondering if that is just the wrong load path.
<wdkrnls>Okay, yes if I start guile with that environment variable explicitly set to the one in my current profile, then it works.
<wdkrnls>I'm just a bit confused why it doesn't read that one in the first place.
<wdkrnls>It seems like it reads the system load path instead of the local profile load path by default.
***pkill9_ is now known as pkill9
<civodul>wdkrnls: as long as Guile and guile-xosd are in the same profile it's fine
<civodul>for instance, this works: guix shell guile{,-xosd} -- guile -c '(use-modules (xosd))'
<wdkrnls>That does work for me too. I guess there is no point for me to have guile installed in my default profile.
<morganw>Is it a problem that I'm seeing a "recovering journal" message on every boot for the encrypted block device which has the root partition? Is the file system not unmounted before shutdown?
<zacchae[m]>I'm getting "no such file or directory" for a binary that definitely exists. I see online people suggest inspecting it with "readelf", but I can't seem to find that package in guix (elfutils package does not supply readelf).
<zacchae[m]>Anyone know how to get readelf, or have another idea for debugging "no such file or directory" on an existing binary?
<bjc>binutls has readelf, i believe
<bjc>binutils, that is
<zacchae[m]>Thanks. I see, the binary for itk-snap (medical image viewing software) is trying to run via /lib64/
<civodul>zacchae[m]: note that there's an itk-snap package
<civodul>unfortunately it seems to be broken right now
<civodul>maybe you can take a look?
<zacchae[m]>My deadline is tonight, but I could spend an hour or so
<civodul>ah, got it
<mjw>the elfutils binary is called eu-readelf (so as to not clash with the binutils readelf binary)
<zacchae[m]>What does guix use to dynamically link C libraries? guix searching "dynamic link", "'linux\.so'", "'ld\.so'" isn't getting me anywhere
<zacchae[m]>Ah. Thanks
<zacchae[m]>Looking into why itk-snap isn't building correctly: It seems compiling one of the .cxx files throws: "error: ‘sys_siglist’ was not declared in this scope". Not sure which include sys_siglist should be comming from, and my cpp-foo is pretty weak.
<zacchae[m]>I'll try just moving up the commit for the itk-snap repo. My guess is the current pinned itk-snap is expecting an old library version which got updated, so hopefully itk-snap updated as well
***mark_ is now known as mjw
<podiki[m]>anyone get an error "couldn't find a proper ls command" in emacs trying to do something like opening a file with sudo (using tramp, but just locallly)
<podiki[m]>hrm, might be an emacs v28 or native-comp thing :-/ as the older 27.2 works
<bjc>you may have to `(add-to-list 'tramp-remote-path 'tramp-own-remote-path)'
<bjc>that allows tramp to pull in the path from the remote shell, which is more important for guix than normal
<bjc>i think you needed to do that in 27, too, so i might be wrong
<bjc>regardless, in 28/29 i don't have an issue with a remote guix install in tramp (it's how i do just about everthing)
<podiki[m]>I'm not even going remote, just sudo for local file, but let me try,thanks
<podiki[m]>bjc: you're my hero that works
<podiki[m]>so is that something we should do for guix's emacs package in v28?
<podiki[m]>oh I see it is in the emacs package as a source snippet for tramp
<bjc>"remote shell", in this context, means whatever mechanism tramp is using to proxy commands. for the most part (if not completely), tramp doesn't care if the actual host is local or not, it treats everything the same
<podiki[m]>odd that it doesn't work in the emacs 28 package I'm using from flatwhatson, though it inherited...
<podiki[m]>oh I see, the source is (of course) different, so the snippet isn't inherited
<podiki[m]>has anyone started on updating guix's emacs to 28.1? the flatwhatson version (that I use) also has an updated/tweaked? libgccjit which I think is either needed or helpful for the native-comp speedups
<bjc>you can use the emacs-next package for 28
<bjc>the base emacs package hasn't been updated yet
<podiki[m]>do you know what the deal is with libgccjit and native-comp? the flatwhatson version (and others I use in other distros) needed a current libgccjit, but I haven't followed any developments as that made it to the main emacs branch
<zacchae[m]>itk-snap package seems to already use the latest version, so I'm out of ideas
<podiki[m]>finally looking at the emacs 28.1 release notes, and native compilation is included via a compile flag and does need libgccjit, so I think we'd need to update that in guix as well
<the_tubular>bjc do you know if emacs-next will be upgraded to 29 when emacs hits 28 ?
<lilyp>podiki[m], the_tubular, and whoever else is interested, I submitted a patch for emacs 28.1
<lilyp>if someone wants to add a bump for emacs-next, it's bug #54829
<bjc>lilyp: is there a way to extract those patches from the bug database for local testing automatically?
<bjc>it seems awfully stone knives and bear skins to have to download the attachments and apply them by hand
<lilyp> (I try without dash if with dash doesn't work)
<bjc>what's the R a substitute for?
*robin is attempting to use guix time-machine to fix guile-emacs (build currently broken...or rather hangs indefinitely for reasons unknown)
<bjc>oh, for like version? so is the latest set of patches you put up?
<robin>is 'guix time-machine -c8 -C ~/guixchan.scm --commit=daeb61f7a92a178b0ac4a5c11b62b962293517e5 -- build -c8 guile-emacs' the proper way to invoke it?
<robin>(where guixchan.scm contains just the guix channel)
<robin>as i get guix build errors running that
<robin>or should i be using guix inferiors or something else?
<lilyp>bjc: R is reroll-count, leave it empty to get the first
<bjc>lilyp: hmm. i'm not sure what "reroll-count" means. i assume this is debbugs lingo that i should read up on
<lilyp>robin: I think you ought to add the commit to guixchan.scm
<lilyp>bjc: it's git lingo, reroll count means how often you've revised the patch
<bjc>ah, i've never heard that before
<bjc>been using git for over a decade now, too ;)
<lilyp>it's the v2, v3, v4, ... you see after [PATCH before ]
<bjc>yeah, i'd guessed it was that. i'd just never seen it codified in terminology
<lilyp>well, you don't read manuals then :P
<bjc>i do not!
<bjc>well, not often enough, i suppose
<bjc>tbh, i don't think, aside from the rebase manpage, i've read the git manuas since i first started using it
<robin>lilyp, aha, hadn't thought of that :) then does it matter if i specify the same commit on the command line or not?
<lilyp>I don't think those two mix well at all; the command line argument might invalidate stuff from your guixchan
<lilyp>IIRC, specifying stuff on the command line means you're only walking back in history of guix itself and ignoring all other channels
<lilyp>this can be bad if you're using some other channel that is developed roughly in tandem with guix and stuff in the middle changes
<robin>first attempt failed in guix pull (i think) with "Unbound variable: current-processor-count", does more work with a later commit
<robin>trying a later commit does appear to work, ty lilyp :)
***dgcampea-2 is now known as dgcampea
<robin>incidentally, i'm looking at mono (current version is a bit old) and it appears to be yet another unbootstrappable compiler
<robin>iirc their initial releases were for compilation with the ms .net toolchain (might be misremembering)
<the_tubular>lilyp, mind sharing a link of your patch, can't seem to find it
<robin>dunno if dotgnu ever went anywhere, so bootstrappable compilers for c#/f#/(ugh) vb might need something like ocamlboot for some version of mono (it was a much simpler language when released, dunno how many fancy new c# features they use in the compiler)
<robin>...and mono is pretty niche but c# seems to be the preferred language for use with godot, the game engine (though guile support wouldn't be terribly difficult to add, i think ;))
<drakonis>you need CLI for this
<drakonis>and that one's a big big boy
<drakonis>actually, i dont even know
<drakonis>the ecosystem is complicated by the existence of .net framework, mono, .net and .net core
<robin>drakonis, yeah, it's quite hard to untangle. you're probably right about CLI now that i think about it
<drakonis>it is the shared component among all of them iirc
<drakonis>dotgnu seems to have stopped development back in 2007
<drakonis>it implements a class library though
<drakonis>its probably not useful for bootstrapping C#
<drakonis> ah nevermind, it does implement the CLI
<drakonis>i find that it is in the same space as the attempt to implement the jvm
<drakonis>gnu classpath and the gcj
<drakonis>its extremely non trivial, sadly.
<robin>"An advantage of our implementation of System.Windows.Forms is that we don't try to wrap up third party widget sets like Gtk, Qt, Wine, etc. Instead, we provide a basic drawing layer and then render the controls ourselves. The approach is similar to Java Swing, in that all controls are implemented in pure C#." ah yes, java swing, everyone's favorite widget toolkit
<drakonis>who even does this
<Kalq[m]>what's a good way of getting the list of packages that have a specific package as a dependency?
<dlowe>I've often wondered if gui rendering should be split off into its own server process
<lilyp>java swing is the best solution if you have to want to run your app on potato pcs using the ms os
<lilyp>in terms of UX it's beat by writing your GUI in Emacs, but Emacs might not be allowed inside your corporate IT infrastructure
<singpolyma>"render the controls ourselves" is always where I stop reading. Not worth my time
<lilyp>rendering controls yourself is very fun though, you have N CPUs and N*2 hyperthreads to hog