<fosskers>Hi again. I seem to be in some sort of chicken-and-egg scenario. I can't use `guix home` until I've updated `guix`, but I can't actually use the new guix (that includes `home`) until I've updated my environment, but since I'm not a bash user I can't update the environment until I've setup a Guix Home... you see my problem.
***Xenguy_ is now known as Xenguy
<fosskers>What's the difference between what appears in /var/guix/profiles/per-user/ME/current-guix/ and /home/ME/.config/guix/current ?
<oriansj>well there is the minimal configuration approach if you want to grow into a setup
<the_tubular>I haven't followed everything, but why do you critically need fish ?
<oriansj>the_tubular: some people just like it better, they don't need a reason for doing so
<oriansj>and there is only a few environmental variables they would need to add to their setup script to make it work well with guix
<the_tubular>I understand that oriansj, but it's like picking seat color before picking a car IMO
<the_tubular>Also, I could understand for some other binaries that are critically required (web servers, db, etc etc)
<the_tubular>A shell doesn't fit that use case, I was just curious
<oriansj>the_tubular: I'd rather sit comfortably in a slow car than sit uncomfortably in a fast car that drives like a dream. Sometimes the seat matters more than the car to the person behind the wheel
<the_tubular>Color doesn't make it comfortable, but I get your point :P
<oriansj>if the shell they want to use is important to them, then it is important
<oriansj>the_tubular: one doesn't learn emacs, they just finds the bits in the mud they like playing with.
<jackhill>fosskers: I haven't done this myself, but one thing I've seen suggested would be to keep bash or whatever as your "official" shell for doing all the Guix-y stuff, but configure your terminal to start up fish for you automatically
<jackhill>fosskers: probaly look to see (to the extent possible with how well the search works) if it's mentioned on https://issues.guix.gnu.org and if you see nothing there, explain the problem in an email to firstname.lastname@example.org
<sneek>rgherdt, unmatched-paren says: Hi, whereiseveryone_ and me were discussing ideas for a Scheme LSP server, and we were pointed to your email to guile-user: https://email@example.com/msg13699.html the idea whereiseveryone_ had was to extract Geiser's Guile code and use that as the backend of the LSP server. What do you think? Would that work?
<rgherdt>one thing that is more tricky is that I'm trying to mimic the way geiser/slime work. Namely that you can start a REPL and load files into it. Based on that, I can get LSP info regaridng what the user loaded
<rekado_>civodul: or if you have access on node 129, please shut it down
<rekado_>civodul apteryx or if someone could init my password on that node — that would be helpful too.
<rekado_>my colleague is in the data centre now and I need access to test the SAN connection.
<rekado_>I’m trying to fix some reproducibility problems in R packages after seeing vagrantc’s email
<rekado_>it pains me to see r-minimal back on the list. It’s a single character difference and I have *no* idea where it comes from!
<rekado_>working on r-affycompatible now, which I think is merely a sorting problem. It builds classes from XML, and I think that the xpath results are in non-deterministic order.
***mark is now known as mjw
<silicius[m]>I packaged vkmark recently but could only test it on x11 while it also lists wayland and kms as its possible backends. I wouldn't want to send a patch with 2/3 of its functionality broken..
<nckx>Sending patches of a limited and well-defined brokenness level is fine, just mention exactly how.
<silicius[m]>I'm in the process of putting the declaration in guix and testing it there according to the manual, but if someone is willing to test it on wayland I can post what I have rn on paste.debian.net
<efraim>llvm@12 and llvm-julia@11 worked, I'll have to see if llvm-10 needs anything special :/
<nckx>No problem. See my comment about a comment about it above, and go ahead and submit your package. But please move home-page, synopsis, description, and license to the end of the package, in that order.
<nckx>I'm willing to cede the (for me) hard-to-remember-and-bordering-on-arbitrary 5-input single line thingy but I think I draw the line at (let ((some superlongthing) (o hai)) …) — maybe it's just me, but I always feel a tiny bit of relief that I ‘caught’ the second one when I see it.
<nckx>apteryx: Good evening! How went the btrfs (mis)adventures, if any?
<hugonobrega[m]>hello folks. I have a quick question about package etiquette, so to speak: I'd like to package something whose man page requires pandoc for building. would including a prebuilt man page be frowned upon if I then tried to contribute the package to guix?
<hugonobrega[m]>because, uh, including pandoc as a dependency just for the man page makes me shudder a bit
*unmatched-paren "What?! It comes with DRM?! I'll take my money somewhere else!"
<tangonov>I am not a ruby dev, but I need ruby tools to do a job. The package I am preparing for guix has a testing option, which is failing, because the gem seems to be missing a path to some file. Presumably because it doesn't exist. The path of least resistance is to turn tests off. Let's pretend for 5 minutes that I'd actually like to see tests run. Can anyone give me some pointers?
<hugonobrega[m]><tangonov> "I am not a ruby dev, but I..." <- disclaimer: I don't know much. but is the stuff that's missing packaged already in guix? if so, I'd try adding the package(s) in your package definition as native-inputs
<maximed>Does someone know how to resolve ‘File ... is read-only; trying to patch anyway’?
<maximed>(when adding a patch to an origin using git-fetch)
<maximed>For some git-fetch origins, this works, but not for others.
<tangonov>hugonobrega[m]: I was able to package the dependencies, how to do that was pretty clear :D
<tangonov>However, the testing that's part of the target gem in particular is calling for some sub-directory for itself. I have no idea if gems even deploy with these directories/files.
<tangonov>If I need a newer package version of a dependency, what's the etiquette? Can I bump the existing package, or define a new one? I assume a new package is in order.
<tangonov>hugonobrega[m]: Yeah! I'm realizing that getting into the abstraction that is the guix package API is fairly straight forward.
<nckx>tangonov: If the update doesn't break any dependents, and it doesn't rebuild more than 300 packages, you can just replace it. ‘guix refresh -l PACKAGE’ tells you both that number, and which packages need to be rebuilt to test.
<nckx>Of course existing broken dependents can be ignored if they still fail to build. If they suddenly start building with the update, all the better.
<tangonov>Ok, so the refresh lists 7 other packages that may be rebuilt.
<unmatched-paren>tangonov: after that, you'll want to `./pre-inst-env guix lint PKG` and fix any issues it may raise :) i would recommend `guix style`, but I've just learned that its styling is often... dubious.
<tangonov>Whatever makes it simple for someone to accept the patch
<nckx>I wouldn't recommend guix style now, since its suggestions are often as not worse than what a newishbie would come up with just by emulating other packages.
<nckx>If you don't know what to ignore, it's not a win (yet).
<nckx>Now ‘guix lint’ — there's a good boy. Be sure to run that if you haven't yet.
<patched[m]><nckx> "tangonov: If the update doesn'..." <- I am in a similar situation but for sdl2, which has 527 dependents. How would one best go about that then?
<tangonov>So `ruby-listen` is presumably hashed from a git checkout. Normally we get our hashes from a base32 representation of a sha256 checksum of a file. If the method is `(git-fetch)` I wonder where what we're checksumming
<unmatched-paren>tangonov: it's basically the equivalent of running `guix hash -rx .` in the git repo checkout
<unmatched-paren>-r means recursive (hash whole directory), -x means exclude vcs-related paths like .git/
<tangonov>This is good to know, in the event I want to be able to verify a checkout myself, without just going "oh, that's red!" and copy/paste it
<maximed>(on git-fetch + read-only issue): for now I'll apply the patch & make a git repo with the patch applied
<nckx>patched[m]: Locally nothing, but when you submit the patch (1) mention that it goes on the staging branch, as mentioned in the manual (grep for 300 or something), and (2) just don't expect to see your changes on master soon.
<nckx>Neither are big deals if you're aware of them. (1) is optional but polite, and avoids misunderstandings.
<nckx>The distinction is more important for committers than for patch senders.
<nckx>…so when you push to ‘master’, git doesn't send the name of the local branch anywhere, rite?
<tangonov>If a ruby package like "listen" is trying to move a bunch of files around at test time, and tests are failing with EBADF - Bad file descriptior - might this have something to do with the immutability of the /gnu/store?
<nckx>I think you do, but I won't spoil your vibe.
<unmatched-paren>"Hopefully IANA will be decieved by our claims that it's supposed to be a generic binary version of XML."
<nckx>There's EBML, but that would still be a standard, so I see your point.
<civodul>maximed: alright i'll go ahead then, thanks!
<unmatched-paren>"Dear users: we have decided that designing a binary format is too hard. Therefore, we will from now on be storing build recipes in Microsoft SQL Server databases."
*nckx waited minutes for a simple grep to complete, was sure their file system was hosed, probably took the kernel with it, not this again, turned out they had a file named ‘-’ in the cwd. I love Unix Fridays.
<civodul>unmatched-paren: you write you'll understand ".txt", but what about "Lists"? :-)
<nckx>(The original topic wasn't even CMake, but a Red Hat Enterprise Software Enterprise that uses GNU make, but in the most something way imaginable.)
<unmatched-paren>"Dear users: for your convenience we will be bundling precompiled MS-SQL binaries for Windows, Linux, and Mac directly in the CMake source code. This ensures build files can be readable out of the box."
<justkdng>ok, seems they fixed it in a commit after the release of 37
<maximed_>unmatched-paren: Look for ‘blobs’ in the Linux kernel
<unmatched-paren>justkdng: you can use whatever build tool you like :) it's all just a matter of preference. guix users tend to be a little cynical about complex build systems, from what i can see, though
<tangonov>nckx: It's trying to make moves in the /tmp/ directory. The folder "guix-build-ruby-listen-xxx" is not in my /tmp folder. If I dig deep into the store may I find it and check the file permissions?