IRC channel logs
back to list of logs
<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
***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>silicius[m]: Why not? Just ask someone using Wayland to test :) As for KMS: maybe switch to a Linux VT and try --winsys=kms? <jpoiret>for wayland, you could test using a simple wayland compositor like sway with a minimal config but it might be a bit too much trouble <jpoiret>one more reason to properly package it <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 <nckx>If you wrote it in a separate (guix build -f) file, please paste the entiry file. People sometimes omit the use-module section leading to tedious re-work. <nckx>Weeks I longed to be back behind a proper keyboard and now I do things like this. <silicius[m]>The module needs to be changed to something that will work for you, but otherwise it should be fully working <silicius[m]>I'm considering putting the package into gnu/packages/vulkan.scm, seems like the best place for it <nckx>I just appended ‘vkmark’ to the end of the file and used ‘guix build -f’. :) It's building. <nckx>Yes, it's a toss-up between vulkan.scm and benchmark.scm. <nckx>I generally prefer putting packages in modules that describe what they do (benchmark), not how (vulkan), but here both make sense. <nckx>Whatever you prefer, or leads to the least new module imports. <silicius[m]>I didn't know about benchmark, it might be a better place for it. thank you <jpoiret>what's the stance on patented software in Guix? <nckx>Still building; otherwise busy laptop. <nckx>jpoiret: Maintainer hat off: I don't think we care? <jpoiret>i was reading LWN and learned about the openh264 shenanigans just now, and realized that we're packaging open264 ourselwes <nckx>Right, that. I really don't think we care. <jpoiret>but ianal and don't really understand who would be at risk with such behavior: the users themselves? <nckx>But, while that sounds like ‘well we should protect users then’, the accepted argument is ‘we can't effectively do so, whilst we would harm many others in real ways, so don't try’. <nckx>I'm sure the FSF has written that more clearly, let me look 😉 <nckx>It's true that Guix could choose to be more strict, but I would argue against doing so. <nckx>All such discussions get mired in WANAL, see the recent ML tedium. <nckx>silicius[m]: Scary pony achieved. Wayland works! <nckx>silicius[m]: As for 3/3: Error: Failed to find specified window system 'kms' *nckx tries forcing -Dkms=true <nckx>The KMS back-end is very new. <nckx>jpoiret: So I'm clear: are you implying that's not ‘enough’ for us to justify our (possibly informal) policy? <silicius[m]>that's the same for me. I think the arch package mentions something about it being broken <jpoiret>oh no, i was just wondering if there was any actual stance on the issue <jpoiret>the FSF saying "it's impossible to actually track, so we don't care" is reassurance for me, since i completely agree with that <silicius[m]>ncks: Should I just remove dependencies for the kms backend, as it seems broken rn? <jpoiret>this just in: the seatd/greetd patches have been committed <nckx>2017, ‘just disable it’, sigh. <nckx>jpoiret: We're pretty explicit in following the FSDG, although it's true that ‘non-rule’ isn't really part of the FSDG in a strict sense because it's not-there. <jpoiret>what's the recommended way of inserting a package in a file? in the first place where it would belong alphabetically? <jpoiret>i feel like this is the hardest part of writing a new package definition <nckx>I'm going to not-be my usual hem-hawing IMHO-self and just say yes. <lilyp>Either there or in case you see total chaos you might also try putting it near a related package <jpoiret>heh, thanks for the new word (hem-hawing) <jpoiret>lilyp: well it's total chaos currently (wm.scm) but it's never too late to start <lilyp>perhaps we should teach guix style to sort files, might be fun <nckx>jpoiret: Exactly. I do the first-alphabetical thing amidst chaos too. <nckx>A widdle beacon of order, two packages, in order. <nckx>Maybe if they grow to like each other they will make a third. <nckx>But seriously who is supposed to provide vulkan_intel.h — it's supposedly mesa, but also obviously not!? <efraim>llvm configure flags are driving me crazy <nckx>(A specific random development feature branch of mesa that is.) <efraim>llvm@9 needs some extra flags for riscv64, my previous fix didn't quite get everything <nckx>lilyp: There are people who actually like ‘git blame’, and would not like that. <lilyp>Well, you can recursively blame, so... <nckx>Just put that in a comment and be done with it. <nckx>silicius[m]: Have you tried to build from vkmark master by any chance? <nikola_>What is the reason Firefox isn't in the official channel <silicius[m]>nckx: Is the package not building from master? I used the latest commit <silicius[m]>That's the latest stable version, the program's window also features this date <jpoiret>nikola_: the firefox branding itself belongs to mozilla and they don't want other distros to compile and distribute binaries themselves <nckx>So this has been broken since then and not fixed on master. Let's not bother [unless you want to fix it and write a patch]. <nckx>You versioned correctly, it's just disappointing. <nikola_>jpoiret: what about something like librewolf then <jpoiret>although i think i saw something about Debian and Mozilla coming to terms with their decade-old feud <silicius[m]>I don't anything about programming for vulkan, just wanted to test my graphics card <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. <jpoiret>(and with more personpower than icecat) <nckx>silicius[m]: Also, newline before (revision …) in the let. Those always go on their own line. <silicius[m]>sure, I'll submit it today once I'm sure it's 100% ok <nikola_>Though i don't think i can be the one to package it since I'm very new to guix <sneek>apteryx, you have 1 message! <sneek>apteryx, civodul says: hey! tests/services/telephony.scm refers to procedures in jami-service.scm that have been removed, IIUC <jpoiret>hmm, does `guix hash -rx .` not work for git repos? <silicius[m]>nckx: guix style put flatenned that line automatically, but I'll change it <nckx>Well, I don't like it. So there 😛 <apteryx>rekado_: you should be able to logon to 129 using the user 'rekado' and your usual sysadmin public key <nckx>silicius[m]: Thanks for pointing that out. <apteryx>rekado_: and from there you can use 'sudo' to gain root <civodul>nckx: thou shall not contradict the almighty 'guix style'! <bjc>i've had to fix up ‘guix style’ for some things. is that actually verboten? <efraim>I tried packaging arcticfox but I wasn't able to get it to build <civodul>bjc: no actually it does have some rough edges <jpoiret>apteryx: i forgot to `git checkout <tag>` 🙃 <nckx>bjc: valiant last bastion of human taste against the tyranny of the machine. <bjc>in the words of the great del the funkee homosapien: never let a computer tell me shit <jpoiret>cage was surprisingly easy to package <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 is probably just me. <jpoiret>how do you find out where store references are in a store path? <lilyp>bjc: Human + Emacs still results in cleaner style than the Guix tool. <jpoiret>hmmm, should we drop debug-gui from libinput? it pulls in gtk <bjc>lilyp: no disagreement from me; i was just wondering if the project required its use <jpoiret>i'm staring at the "minimal" wayland compositor cage having a 1GB closure <bjc>surely that's just for the build phase, and not the outputs? <jpoiret>🤡 debug-gui is actually a UI you can launch through libinput's CLI <lilyp>jpoiret: if you can separate it into a libinput-minimal <lilyp>graphical debugging of input handling sounds mildly useful <jpoiret>wlroots also retains references to Xwayland, but i don't think it should <silicius[m]>how can I force a rebuild of a package? guix build does not seem to have an option for that <jpoiret>although if guix doesn't want to rebuild a package, it's because the recipe hasn't changed
***stikonas_ is now known as stikonas
<jpoiret>lilyp: looks like we already have such a libinput-minimal <reyman>I'm trying to configure eduroam wifi <reyman>my command line wpa_supplicant -c cat_installer.conf -i wlo1 -B return an error : p2p-dev-wlo1:failed to initilaize drive interface <reyman>with nl80211 Could not set interface p2p-dev-wlo1 UP <apteryx>perhaps that interface requires proprietary firmware <nckx>jpoiret: Could it be a separate output somehow (say if libinput just uses $PATH to find it)? <reyman>actually it's possible to connect to 4G without problem using the same interface <nckx>The same interface providing 4G and wifi? <reyman>I have this : Rekeying PTK for STA 94:b4:0f:bc:a8:70 but driver can't safely do that. <jpoiret>nckx: it's ok actually, since we already have libinput-minimal for that use case <jpoiret>just that many packages use the full libinput <reyman>using my 4G with phone as wifi @nckx <nckx>There is little point in shipping the full libinput if nothing is built against it IMO. ‘But you could build your own code with a debugger’ is meh. <reyman>[25462.032062] debugfs: Directory 'netdev:p2p-dev-wlo1' with parent 'phy0' already present! <reyman>ok, so running sudo dhclient -v wlo1 that work, but this is not displayed in gnome <rekado_>apteryx civodul, node 129 now has access to the SAN. <apteryx>great! were you able to connect to it using your sysadmin key? <silicius[m]>I think I got the patch ready to send, but since it's my first package should I add my name somewhere like copyright or something? <jpoiret>silicius[m]: usually at the top of the file, you'll see a bunch of other copyright lines, just add your own <unmatched-paren>silicius[m]: you need to add your name (or pseudonym ;) and email to the header in each file you've modified <jpoiret>let's say I mass rename libinput -> libinput-minimal for 4 packages in the same file, should that be 1 or 4 commits? <nckx>It is taking its sweet perambulations to arrive. <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 <nckx>hugonobrega[m]: It's fine. <nckx>Adding pandoc as a native-input is totally fine. <nckx>silicius[m]: Arrived & approved, thanks! <nckx>Ah, I meant as not-spam. <apteryx>nckx: hi! the node 129 is up on a Btrfs RAID 10 5 disks array, can reboot without issues at will <nckx>Oh that's wonderful. So using btrfs is tenable. <nckx>That's something of a relief. <apteryx>yes; migrating /etc is potentially login breaking due to PAM and other possibly stale things kept there <apteryx>and EFI probably improved because the boot drives were > 2TiB and BIOS can't cope with that <apteryx>I'm also relieved that the PERC seems to behave transparently as we'd expect, whatever their operation mode (RAID vs HBA) <nckx>let vs. setenv wut even why. <nckx>I would not recommend running ‘guix style’ and committing the results. <nckx>apteryx: Was there a reason for choosing BIOS initially? <nckx>I'll rephrase: is there still a drawback/trade-off you made switching to UEFI now? <unmatched-paren>nckx: could you have a look at the v2 patchset i just sent to #55999, if you're still interested in fixing Dub? <hugonobrega[m]>unmatched-paren: I don't have much to add, so pardon the ping if it's against house rules, but I was the original bug reporter so just wanted to say thanks for looking into this stuff <unmatched-paren>happy to help where i can. "where i can" isn't often due to my general inexperience :P <unmatched-paren>hugonobrega[m]: all it took was updating Dub, really. we were 16 non-patch versions behind... <hugonobrega[m]>nice, this whole thing came from me trying to package some things to teach myself guix+guile too <hugonobrega[m]>yeah I figured as much, I managed to work some of that out locally but not all the way <hugonobrega[m]>as you can see from my question on this channel a couple of hours ago I'm still somewhat in the "asking silly questions" phase, but knowing me that phase doesn't actually ever end <jpoiret>hugonobrega[m]: we're all the silly person of someone else *unmatched-paren "Hello, is this Custom Signposts Co? I'd like to order a digital signpost saying 'Stupid Questions Welcome'."
***mark__ is now known as mjw
*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>I am thinking I need to make use of `#:test-target` somehow. Other gems in /guix/gnu/packages/ruby.scm seem to specify a string for some reason. <lilyp>I don't know how this works for ruby, but #:test-target is supposed to be the second argument for make, e.g. ("make" "check") or ("make" "test"), and so on <tangonov>That is helpful to know. If there's no makefile, then we will get nowhere <tangonov>It starts out reading like it's trying to do something with the check command, which is only a little confusing. I'm not sure how abstracted gems are for guix: https://pastebin.com/WipxAxfm <hugonobrega[m]>tangonov: my guess is you need to change into the appropriate directory before the check phase <tangonov>hugonobrega[m]: Thanks for that. There's a pretty good example of where to get test pre-requisites in `ruby-listen` as well. It involves pulling the repo source. <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. <nckx>So you've added the package to your local guix git repository, then ran ‘./pre-inst-env guix build [said list of packages]’, and everything builds? <nckx>If so, sounds good to go. <tangonov>I did not! That's the next step, I suppose. <nckx>Assuming you've tested the package itself by running it, of course, but how (or if) that's done depends on its nature. <nckx>tangonov: ‘guix refresh -l’ won't throw errors. <nckx>It just prints that info. <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? <patched[m]>Allright. If I want to submit a package depending on that version, should I submit a version with a package variant in the meantime? <nckx>patched[m]: Is this a security update? <nckx>my current one is extremely rude. *nckx was being an idiot yesterday, yelling at self always helps 👍 <justkdng>I'm trying to build a package but I'm getting this error when compiling <patched[m]>nckx @nckx:libera.chat: not a security update, just an update that allows it to listen to pulseaudio monitor channels <maximed>justkdng: Is this when building a package (with Guix?) <unmatched-paren>i think this error is because guix does not alias gcc to cc by default <maximed>justkdng: What package fails to build? <justkdng>so just mostl copied the definition and changed versions <nckx>patched[m]: Then yes, I'd create a variant, with a comment explaining why it exists, and use it in as many packages as you need/want to that don't hit the limit together. <nckx>For bonus points send a second patch that ‘undoes’ the variant and updates the main package normally, that can be pushed to staging when master's merged. <maximed>justkdng: Maybe run "grep -rF 'cc'" in the unpackad sourec code? <maximed>to determine where the cc comes from <nckx>patched[m]: Nobody does that but it would save the committer time. <patched[m]>nckx @nckx:libera.chat: good idea, I'll remember that <unmatched-paren>no idea what $(filter default) means: $(if $(filter default,$(origin CC)),$(CROSS_COMPILE)$(COMPILER),$(CC)) <maximed>Looking at that file, it looks like 'CC_FOR_BUILD needs to be overwritten. <maximed>i.e., point CC to #$(cc-for-target), and set CC_FOR_BUILD to gcc. <justkdng>is there a way to view the commit that updated efivar to 37? <nckx>Commit message discipline for the win. <maximed>justkdng: you can do "git log --grep efivar" in a checkout of Guix <maximed>Needs some degree of manual interpretation though. <gnucode>hey guix! I am going to try to push my WIP smtpd-records today... <maximed>Hmm I thought that the data service was supposes to implement that kind of searching? <nckx>git log --format=oneline --grep 'gnu: efivar: Update' should really do it unless somebody screwed up. <justkdng>hmmm, when doing a guix pull I checkout the guix repo right? <maximed>justkdng: A checkout of the guix repo is made, somewhere behind the scenes <maximed>TBC: modifying that repo has no effect, and it's technically an implementation detail <justkdng>I figured if I already have it downloaded somewhere <justkdng>it would be faster to check the git logs from there <maximed>I recommend making a new repository, and adding the checkout made by Guix as a remote <maximed>(that way, you avoid interfering with Guix' copy) <maximed>Found it: it's a subdirectory of ~/.cache/guix/checkouts/ <civodul>maximed: hello! did you have further comments regarding home-openssh-service-type? <justkdng>but probably the compiler is now messing with some stuff (? <justkdng>cc1: all warnings being treated as errors <nckx>The relevant error is *somewhere* above that. <nckx>Basically, a warning was emitted by the same people passing -Werror to the compiler. <nckx>You need to fix that warning for them or remove the -Werror somehow. <justkdng>yeah, I'm looking for the addition of Werror <nckx>This package is unbelievable. <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. <nckx>tangonov: It's impossible to say ‘no’, but it's not in the top-N of expected errors either. <justkdng>hmmm, damn you red hat, and your shaenanigans <nckx>unmatched-paren: …Windows? <justkdng>Error: invalid attempt to declare external version name as default in symbol `efi_set_variable@@LIBEFIVAR_0.24' <nckx>That's scary and won't pop up Notepad by default. <nckx>unmatched-paren: Which it is? <nckx>unmatched-paren: Are you advocating… they make it something else? Are you mad? <nckx>Stop giving them ideas right this minute, young person. <unmatched-paren>thy file extensions and GUI art sacred and I am but a sinner for condemning them! <nckx>‘Dear users; sadly, the IANA has rejected our binary/cmake MIME type proposal.’ <nckx>‘This leaves us with no choice but to use .xml instead.’ <justkdng>It seems that error is related to lto, is lto enabled by default in guix? <unmatched-paren>nckx: "Since a binary format is obviously 3000X more efficient, we will be designing a bxml format for build files." <nckx>$(call enabled,ENABLE_LEAK_CHECKER,$(call enabled,ENABLE_LEAK_CHECKER_LTO,-flto,), <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"? :-) <civodul>this CMake thing is an endless source of... <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 <unmatched-paren>justkdng: I used to like Cargo before I started contributing to Guix :) believe me, certain software packages seem nice and simple for users, but are hell for distros <nckx>unmatched-paren: I encountered that once, but it was $random_project bundling a cmake.exe in their source tarball. <nckx>It was a bootstrappable build. <justkdng>how can I use that git commit as the source? <justkdng>unmatched-paren: could be a guix issue ;P <unmatched-paren>nckx: have you ever encountered a project embedding a binary _directly in the source tarball_, though? :P <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? <unmatched-paren>--why is it so easy to demolish anything i say with a really obvious counterpoint-- <nckx>tangonov: Is there a reason/suspicion why you're fixated on permissions? They don't seem relevant. <nckx>Are you getting a ‘permission denied’ anywhere else? <justkdng>ohh, ty nckx, I was checking the cookbook though ;) <justkdng>appreciate it though if I could get some feedback on my solution <morganw>Does anyone know if there is a variable that can be used within the Guix Home configuration to get the path to the home directory? <morganw>unmatched-paren: I wasn't sure the environment where the build runs is stable, but I'll give it a try. Thanks. <maximed_>justkdng: Guix doesn't do install staging (was that the terminology), so setting DESTDIR is pointless. <maximed_>Also, the DESTDIR is incorrect, if anything, it should be / <nckx>morganw: The answer is something like that regardless, e.g., using (getpwnam "user"), it won't be a Guix-specific thing. Use the power of Guile. <maximed_>it was 'prefix' (lowercase), in this particular case IIRC <nckx>justkdng: Missing ) after the hash. <nckx>maximed_: It's prefix & they said DESTDIR was necessary regardless, which was plausible given the general quality of the Makefile. <maximed_>civodul: TBC didn't look at the documentation <nckx>I didn't verify it either. I'd rather it works before we start changing ‘details’ (your point is correct, of course, but first steps first). <civodul>maximed_: ok, noted; i guess we can adjust the doc later on if needed <nckx>maximed_: I think this is day 2 of justkdng packaging pesign, but it might be more. <nckx>It's not a friendly learning package. <nckx>You're closing up to (origin, but not (source, no? <gnucode>nckx: So I just submitted my opensmtpd-records to guix-patches. <gnucode>It probably needs a fair amount of work.