IRC channel logs
2023-04-11.log
back to list of logs
<Guest79>Hey folks, how do I view the source for the guix repo's packages? <Guest79>I'm looking for an example of unpacking a .deb file so I can create my own package from a .deb file. <vagrantc>depending on what part of the source you are looking for <vagrantc>e.g. "guix build --source PACKAGE" will give you the source code that guix build process builds "guix edit PACKAGE" will show you what guix's build process looks like <Guest79>vagrantc: neat, thanks. I think those are what I need. Then I need to find a package that builds from a .deb and inspect it <vagrantc>that is an unlikely way to build a package, i am not sure there are any examples in guix proper <Guest79>vagrantc: Yeah, sadly I'm trying to install some unholy proprietary software (Signal's desktop client, for work). They only give a .deb file for linux AFAIK. I'm going off of gentoo's ebuild for it. <Guest79>Speaking of gentoo, I know the guix proper channel doesn't include any nonfree software, but is there something similar to Portage's ACCEPT_LICENSE or package.license? This would be in the case I enable some other non-gnu channel, but only want to accept some types of licenses. <vagrantc>that is up to the channel you are trusting <vagrantc>you would have to trust them to report the licesnses correctly anyway... <poselyqualityles>Hi, should the names of p11-kit-next and gnutls-next be p11-kit-next and gnutls-next, or, alternatively, how to specify installing p11-kit and gnutls instead of p11-kit-next and gnutls-next? (e.g. guix install p11-kit appears to install the version associated with p11-kit-next) <the_tubular>What's the command to view reverse dependency of a package ? <poselyqualityles>the_tubular: guix graph -t referrers <package> shows the ones from the store, not sure if that helps <jackhill>poselyqualityles: at the command line you coule use the gnutls@version (it matches partial version numbers so gnutls@3.7 would install the current -next, but gnutls@3.7.2 (that obviously is easier for things where -next is more differnt than the current version, like e.g. ffmeg)). Althernatively, you could use a manifest an use the scheme package objects directly rather than specification->manifest <jackhill>poselyqualityles: for gnutls in particular, I'd, in general, expect folks doing explicit operations to actually want the -next version (like if they were using the cli tools or setting up a local dev environment). Of course there many cases that don't fall into "in general" :). No idea about p11-kit <Guest79>I'm trying to write a package whose source is an archive. It sounds reasonable to extract the archive and then use the copy-build-system to do the installation. How do I tell the package to do the extraction? <Guest79>I mean I know the required command, but I don't know where to put it. <jackhill>are the signing keys of particular store items preseved after they are imported? I'm having a program (ungooged-chromium) crashing with illegal instruction, and I'm wondering if it was build for a different CPU than I'm currently running. Extra complication, the version I'm running is probably grafted. <poselyqualityles>jackhill: thanks! likely will switch to referencing the scheme objects (mostly what i'm encountering is conflicts with propagated inputs of other packages which mostly reference the non -next versions) <poselyqualityles>Guest79: the unpack phase already includes ((string-suffix? ".zip" source) (invoke "unzip" source)) ((tarball? source) (invoke "tar" "xvf" source)), so depending on the type of archive, you may not need to modify anything <MysteriousSilver>i hope this question makes sense: i see many gnu packages are translated in my language, how to i use those languages instead of english in my guix? <Guest79>poselyqualityles: gotcha, so how can I modify the unpack phase? <Guest79>Okay I found the documentation on build phases. I've got to do something with modify-phases in the `#:phases' argument. <Guest79>I'm in a guile repl and I'm trying to inspect the %standard-phases variable. All I've done is ,use (guix build-system copy) and then %standard-phases but it's unbound. What should a noob like me do? <poselyqualityles>Guest79: (guix build gnu-build-system) is where %standard-phases is defined <poselyqualityles>A pattern like this (replace 'unpack (lambda* (#:key source #:allow-other-keys) (invoke "<archiver>" "<extract-argument>" source))) should work for modify-phases <Guest79>poselyqualityles: Amazing, thank you so much. Native inputs are the build-time dependencies then? <poselyqualityles>Guest79: One other thing, the default unpack also does chdir into the first subdirectory after unpack, so if you replace unpack you may want to replicate that for convenience <Guest79>Amazing, you've helped me a lot poselyqualityles. <vagrantc>sounds like it is not using /gnu/store from the new device you are installing to <vagrantc>e.g. it's just using the store mounted on tmpfs, which is ram-limited <apteryx>jackhill: interesting question; I don't know but finding where the signatures are stored would probably answer the question (perhaps the NAR format can do that?) <apteryx>or no, that's probably silly; I think the NAR format was created for reproducibility. Stuffing arbitrary keys in them would defeat that. <vagrantc>i am weak on the details ... but i think the .narinfo contains the signature <apteryx>I guess .nar is as simple as it can be, without signature support <apteryx>but I'll keep writing about *guests* now :-) <jackhill>that sounds about right. I should probably peek at the sqlite database. It may not get recorded though. In this case, I think I might know which machine produced it, so I may just as well check the hashes to see where this store came from. <jackhill>I suspect that runnnig ungoogled-chromium on AMD, built on Intel, is the source of my problem. <jackhill>I bet not that many folks are checking ungoogled-chromium for reproducability (I celebrate when I can get it to build once!) <vagrantc>optimizing the build for the build cpu ... not good practice and an issue for reproducible builds, obviously :) <vagrantc>yeah, it didn't end up in my tests from some months ago <vagrantc>wow, i haven't done any of that since august or so <jackhill>vagrantc, apteryx: hmmm, actually it seems the store items substittues from berlin adn bordeaux match, so maybe it's not that. <jackhill>of course the problem might be in a dependency, not ungoogled-chromium itself. I don't terrible want to run all of that under a debugger :sigh: <apteryx>jackhill: what kind of problem are you seeing? <apteryx>I've got some ~2008 Quad Core CPU so I should probably be able to trigger the problem if the substitutes use fancy modern instructions. <jackhill>apteryx: I can reproduce it with ungoogled-chromium-wayland from Guix c1262edba9118af6507dc47ce6ad61ffdec02384 and the security settings page of gandi.net. It crashes with "Illigal instruction" and dmesg shows "traps: chromium[23747] trap invalid opcode ip:55bf1461697c sp:7ffc734dae00 error:0 in chromium[55bf13887000+b300000]" <jackhill>seems to be the same instruction pointer each time <jackhill>oh, interesting, the non-wayland varient doesn't crash on that page. Well, at least I can get the thing I was trying to do done. <jackhill>ok, also just tried ungoogled-chromium-wayland from core-updates (freshly substituted) and that doesn't trigger a problem either. <jackhill>I've checked `guix gc --verify=contents` and all is good there. <jackhill>when I was checking if the substitutes matched, I was doign `guix hash -rx .` in the rood of their store directory by the way. <Guest79>Likely a dumb question but here goes: I have some files I'd normally install to /opt and /usr (on a typical GNU/Linux distro). How do I instruct my package to install such files appropriately for guix? <lfam>Guest79: On Guix, there's not a system of package categories like usr and opt. Everything gets installed to the same place and then you run the program in the normal way. Specifically, how do you install your packages on other distros? With a Makefile? <Guest79>lfam: Yeah the package manager might make use of a patched makefile or whatever, depends on the project. With Gentoo, say, ebuilds install stuff in /usr and /opt where appropriate. <Guest79>So let's say a makefile wants to put stuff in /opt, where do I tell it to go instead? This is in the context of writing a package <lfam>Hm, I would have the package install it to "$PREFIX/share", although you could also choose "$PREFIX/opt". <lfam>You don't see opt/ used in Guix often, because unprivileged package management is possible, so it's not necessary to create a place like opt/ that can be used without privileges <lfam>But, that's largely a matter of convention <lfam>If you can be more specific about the type of files, I can tell you how they are typically handled in Guix pakages <Guest79>What I *think* I understand so far is that the gnu-build-system invokes its configure phase with a variable called `outputs`that determines the prefix. I want to access that but with the copy-build-system <Guest79>looks like I've got some .so files, locale .pak files and the application's main executable under /opt and the icons, desktop files, docs, etc. under /usr/share <lfam>Alright. I don't have specific knowledge about copy-build-system. Hopefully someone else can help there <lfam>But, you're right about the special prefix, which is $PREFIX in the build environment <lfam>When you build a package, all of the built output goes into /gnu/store/$weird-looking-hash-PACKAGE-VERSION <lfam>And within that you'd find things such as 'opt/', 'share/', 'bin/' and so on. I'm moving the slash because the directories /opt, /usr, and /bin do not exist in Guix-world <Guest79>Nice, then I understand it much better now <lfam>When you then *install* the package for yourself, that directory in /gnu/store is symlinked into your "profile" (aka collection of packages), and then your $PATH and other variables are set appropriately <lfam>The end result is something like this: <lfam>$ /home/leo/.guix-profile/bin/git <lfam> /gnu/store/8js4byvk3w5lzqf3ffv3pdk386gpalgg-git-2.39.2/bin/git <lfam>The git program is a symlink from my profile to its ultimate source, that weird directory in the store <lfam>The .so files would usually go into 'lib/'. Everything goes where you'd expect, but then prefixed into the package's special store directory <lfam>Within this paradigm, there's rarely a need for 'opt'. But there's no reason you couldn't choose to use opt <lfam>You might see things like 'share/misc' <Guest79>Ah, gotcha! So if I used some weird non-convention and build a patched git at /gnu/store/085732049soatuehaseo-git-9999/notbin/git, how would the end-user's PATH know about this `notbin/` directory? <Guest79>or is this where we need some convention <lfam>Basically, when you do `guix install git`, it ends up on your $PATH automagically <lfam>Oh, I missed the detailed point of your question <lfam>It would not end up on PATH <lfam>It would be found at ~/.guix-profile/notbin/git, but that's kind of annoying to type <Guest79>Gotcha, so we should put it in $PREFIX/bin <Guest79>Well if I'm not bothering you I'll ask another question. How would you handle a package that is normally distributed as a bundle? <lfam>I'm happy to help! What do you mean by a bundle? <Guest79>(sorry, by bundle I mean with the dependencies included) -- Should we attempt to unbundle the software and declare external deps or is there a way to install the bundle such that the software you want uses whatever is bundled? <lfam>The Guix convention is to unbundle. Of course, there's a difference between unbundling 5 dependencies or unbundling 1000 dependencies. Personally, I would first try to make a working package with the bundled dependencies, and then decide how to proceed. If you submit the package for contribution to Guix, you will probably be asked about the bundled dependencies <Guest79>Okay, that's what I'd expect. And very good to know, thanks lfam :) <mvnx>I've given up trying to get River (a Wayland compositor) running on Guix, at least within a QEMU VM (not sure if that's the problem). Anyone have a working config with bspwm on Guix? <TristanCottam[m]>Is it possible to set the owner of a special file from SPECIAL-FILES-SERVICE-TYPE? If not, are there any alternatives? <jpoiret>Guest79: also, you might want to talk with upstream about adding the possibility of using unbundled dependencies <jpoiret>that might be the option with the least friction <jonsger>on core-update we have GNOME 43.x or? <apteryx>nothing special about GNOME on core-updates, so no <apteryx>ACTION managed to update python-cryptography to 40.0.1 <retropikzel>Hmm, when I make guix shell(container,network,pure,emulate-fhs) with ghc@9.2.5 and run ghc --version inside of it it gives me version 8.10.7 :/ <retropikzel>Anyone happen to know which package holds tab autocomplete for make? <mirai>what's the difference between program-file and scheme-file <mvnx>I believe `program-file` is for binaries (maybe the Scheme-compiled .go files?), and `scheme-file` for, well, Scheme files. <mvnx>I don't actually know though, just my understanding when I read the docs. <RavenJoad>I am running a perl program in a sub-shell and I get "perl: warning: Setting locale failed." All of my locale environment variables are set to "en_US.utf8". After running "locale" in the subshell, I get "locale: Cannot set LC_ALL to default locale: No such file or directory" as one of the outputs. <RavenJoad>I do not know what is happening, as most other programs seem to work fine. Am I missing a locale somewhere? <apteryx>do you gave the glibc-locales package installed? <RavenJoad>Probably not. I do not have it listed anywhere in my system or home configurations. <RavenJoad>So unless it is provided by a service that I am not aware of, then I do not have it installed. <apteryx>mirai: applied your nginx changes, thanks! <zacchae[m]>guix weather nss identifies 1/2 substitutes in ci.guix.gnu.org, and 2/2 in bordeaux.guix.gnu.org, yet home reconfigure still tries to build nss <zacchae[m]>Substitutes download fine for other packages. Why is guix trying to build nss? <mirai>apteryx: the php one or the logging one? <zacchae[m]>unmatched-paren: /gnu/store/f4m421...40f-nss-3.88.drv <mirai>in any case, thanks for reviewing it! <unmatched-paren>zacchae[m]: that's the derivation, not the output path, but i think that'll do as well <zacchae[m]>unmatched-paren: sure: /gnu/store/f4m42191f8dl0yhddw576vx7mhii040f-nss-3.88.drv <zacchae[m]>I left it building over night on my puny arm device (Librem 5) and it was still building in the morning <zacchae[m]>Since bordeaux comes up with guix weather, that means it is enabled right? <unmatched-paren>the channels that guix weather uses are hardcoded :P (don't ask, i have no idea...) <zacchae[m]>Ah, that is probably it then. the 1/2 in guix weather for ci is probably the drv. <zacchae[m]>After authorizing bordeaux and restarting guix-daemon, it still wants to build nss... <lfam>"hint: On Guix System, add all `authorized-keys' to the `guix-service-type' service of your `operating-system' instead." <lfam>Is there a way to restore the symlinked /etc/guix/acl and take the advice of the hint? <lfam>I just authorized a signing key from another machine <teddd>Is it possible to unquote a string variable in a gexp so that is become ungexpd to a string an not a reference to a derivation ? <unmatched-paren>#~/#$ are essentially the same as `/, except when a lowerable object is ungexped it gets, well, lowered (there are other, more minor differences, such as supporting WITH-IMPORTED-MODULES and WITH-EXTENSIONS etc) <teddd>yes but (define str "emacs") #~(do-stuff-with #$str) gives me #<gexp-input "emacs":out> when I really just want to use the string "emacs" <teddd>not sure. I'm trying to write a gexp for a shepherd-service <teddd>unmatched-paren: ok will read <unmatched-paren>teddd: hmm, DO-STUFF-WITH is receiving a <gexp-input>? that's impossible <jpoiret>teddd: can you paste.debian.net the relevant snippet of code? <unmatched-paren>(also, would there be anyone willing to review that blog post here? :)) <teddd>These blog post series are really helping a lot btw :) <unmatched-paren>teddd: by the way, if you add (shepherd support) to the service's modules you can use the variable %USER-LOG-DIR <teddd>Ah nice thks. I copy-pasted this from somewhere and never really understood it. <teddd>ah good to know ! Not surprising in a way yes <bjc>where is the ‘(shepherd support)’ module? <unmatched-paren>i wrote that before i knew about (shepherd support), though, i'd better change it :) <unmatched-paren>shepherd's scheme modules are available to shepherd services along with guix's <unmatched-paren>presumably the gexps are wrapped with (with-extensions (list shepherd) ...) <jpoiret>teddd: where does the error occur? log? <unmatched-paren>teddd: also, i've found out that that emacs service has a bug where if you don't create ~/.config/emacs/custom.el yourself it'll fail to load emacs <teddd>yes: log -> #<gexp-input "emacs":out> <teddd>unmatched-paren: hard... Happend to me last year. Also discovered a lot of non-reproducible things through this. <unmatched-paren>teddd: fortunately i had moved virtually everything to guix home, which i'd put online :) <teddd>unmatched-paren: yes that was the moment when I switched to guix-home so it can't happen again <teddd>unmatched-paren: haha I knew it <unmatched-paren>and i'd highly recommend using an existing emacs service (there's one in the rde channel, as well as the guixrus one); opposites attract, which leads me to think that emacs and shepherd repel each other :P <teddd>but didn't you mean it is kind of expected ? <teddd>Yes might be the shortest path to solve this <unmatched-paren>teddd: that's only if you are for some reason trying to access the fields of the <gexp> record <unmatched-paren>and if you are doing that, i'm afraid your code might be beyond a simple exorcism <teddd>I think I need to read this blog post before I can realize what is happening ^^ <unmatched-paren>teddd: what happened with my home dir is that i was trying to switch from aerc (terminal program) to mu4e (emacs package) for mail reading <teddd>The first and part of the second. I should start there to up my esoteric level <teddd>unmatched-paren: sounds legit <ellysone[m]>any rust expert here? I'm trying to build scryer prolog, but it can't compile gmp-mpfr for whatever reasons https://paste.debian.net/1277032/ , when I source the environment-variables file in /tmp/guix-build-scryer.. and launch a cargo build manually it works <teddd>unmatched-paren: that's epic <unmatched-paren>the final insult was that i didn't have permissions to delete the ``go'' directory, meaning it literally preserved the *least* useful part of my $HOME :P <teddd>That's probably also a curse <jpoiret>i'm sorry I haven't been reading that much <jpoiret>teddd: when does the error happen, on reconfigure or on boot? <podiki[m]>unmatched-paren: that was a recent change in mu I think (pretty sure it expanded ~ before), sorry that happened to you <unmatched-paren>podiki[m]: haha, it was mainly my own idiocy in not quoting the ~ in the rm command :) <podiki[m]>I nearly did the same, had to double check the completion <teddd>jpoiret: I can reconfigure but the service doesn't launch. So it was pretty confusing. <teddd>unmatched-paren: well I actually have no idea where the log landed but definetly not under ~/.var/log/emacs <teddd>unmatched-paren: yes that's what i meant <teddd>You mean 'herd start emacs' should output something ? I think I tried it but no output <mirai>apteryx: don't forget to restart the CI/substitute servers <teddd>unmatched-paren: I just realized the author of the blog posts ( is you <unmatched-paren>teddd: sometimes it outputs something when something goes badly wrong <teddd>at leat parenthses are matched when in you last msg <teddd>(shepherd-service-start (emacs-shepherd-service '(emacs) '("--fg-daemon") #t #f)) <teddd>outputs: #<gexp (make-forkexec-constructor [...] #:log-file (string-append (or (getenv "XDG_LOG_HOME") (format #f "~a/.local/var/log" (getenv "HOME"))) "/" #<gexp-input "emacs":out> ".log")) [...]> <teddd>So is it possible still to put a not hard coded string in a gexp ? <teddd>but how to stop the recursive ungexping of the string ? <teddd>Isn't the string ungexped to this emacs gexp-input ? <teddd>Ah ok. So it really becomes the string I want to have and the error lies somewhere else. <unmatched-paren>again: you're likely better using one of the existing emacs services <unmatched-paren>if you want to practice writing services, there are much easier choices than emacs :) <teddd>unmatched-paren: Yes will eventually do. I will probably still tinker a bit on it just for fun :) <jpoiret>teddd: what is the usual value of names? <teddd>jpoiret: well guix describe says I should guix pull... <teddd>jpoiret: meaning last pull was more than a month ago <jpoiret>arf, I was about to ask the guile version as well <unmatched-paren>i strongly suspect it's just something with the service itself, maybe a flag that hasn't been passed or something <jpoiret>damn you're telling me I had to refresh my gexp internals for naught? <jpoiret>even though I always end up forgetting stuf <jpoiret>I was thinking that maybe symbol->string returns something that doesn't behave well (ie. sometimes doesn't give you string? == #t) <jpoiret>since that string seems to be special (you shouldn't string-set! it apparently, so I'm thinking it comes from the actual representation of the symbol in memory) <teddd>I just reconfigured my home with this snippet again. Shepherd isn't ever starting. I can't find the logs in ~/.local/var/log/shepherd <unmatched-paren>teddd: by the way, once you've read the posts, would you mind giving some feedback on them? <unmatched-paren>i haven't really got all that much feedback from people who haven't previously understood the concepts at play (the reviewers mainly seemed to be people who would already understand) <unmatched-paren>teddd: thanks! have you done monads before? that's one thing i'm especially keen to hear about: does it do a good job explaining monads to someone who has never used them before? <unmatched-paren>jpoiret: fortunately guile isn't elisp :) (the E, of course, stands for eldritch) <teddd>unmatched-paren: No, the most I understand is derivations more or less. The concept of monad ins't really clear to me yet. I'm looking forward to understanding it. <teddd>unmatched-paren: probably not this evening though, but during this week. <teddd>unmatched-paren: what is that? <sneek>Welcome back teddd, you have 1 message! <sneek>teddd, unmatched-paren says: hi <teddd>why did ddg tell me about this when asked him ? <teddd>well maybe I saty 5 min now that new commands are being revealed <jpoiret>I thought this would work, I've seen it used :/ <sneek>unmatched-paren was last seen in #guix 4 seconds ago, saying: huh. <teddd>jpoiret: oh no don't reveal the secrets of magic tricks <teddd>does that avoid it to be public ? <sneek>Commands is numerous; try /msg sneek help <sneek>Someone once said Commands is numerous; try /msg sneek help <teddd>Alright now I'm happy, see you ! Have fun with the sneekbot <zacchae[m]>Must 'guix archive --authorize' be run as root, or is sudo acceptable? Seems like a dumb questions, but can't figure out why my install won't download some substitutes <unmatched-paren>zacchae[m]: wait, is there a difference between sudo and running as root? <zacchae[m]>There are some differences, e.g. uses /home/<user>/.config/guix/current/bin/guix instead of /root/.../guix. Don't think there should be other differences, but I'm running out of ideas <zacchae[m]>(which is why running guix as root requires extra 'guix pull' invocation vs sudo) <zacchae[m]>Currently won't let me su root. Have only run guix as user (or with sudo for guix archive --authorize) <zacchae[m]>unmatched-paren: No problem, the fact that guix weather output can't be totally trusted was a big help <ryan77627_>Hey, I may have a bad question, I am new to Guix. I am trying to set up my system atm and installed "swaylock-effects" as part of the system configuration, which shows up properly if I run `guix package --profile=/run/current-system/profile --list-installed | grep swaylock-effects`. But, none of the effects are actually showing when I run the command, it seems I have regular swaylock installed based on <ryan77627_>the `--version` output. Any reason this could be occuring? I can send example config lines if need be <ryan77627_>I checked and my user profile has no version of swaylock or swaylock effects installed <ryan77627_>Oh.... I found the discrepency I believe. It seems I errantly copied a line from a Github repo for a setuid problem without reading what it actually does, I believe swaylock gets defined in there... I'm going to reconfigure my system and try once more <ryan77627_>I do have a question regarding making a system configuration. What resource should I reference if I want to have everything included in %base-packages, minus 1 or more certain packages. Specifically, i want to replace `sudo` with `doas` and I am unsure of a clean way to do that at the moment <nom[m]1>is there any home service to run gnu stow? <nom[m]1>ML? sorry for ignorance, I'm new to guix <ellysone[m]>to ease the transition between stow and a full guix workflow <Guest1936>is it possible with guix home to move files to the home user? Like for example I use pass which has a dir in ~. <nom[m]1>ellysone: that's good, i'm a bit conflicted with how the home handles the symlinks, since there are certain config files I still need write permissions for <jpoiret>ryan77627_: you should be able to just use list manipulation functions for this <jpoiret>ie you can use (delete sudo %base-packages) <zacchae[m]>ryan77627_: make sure you are running a sway DE (they default to x11) <zacchae[m]>Guest1936: In my opinion, passwords are the one thing that should be manually handled, but yes, you can make arbitrary shell scripts with mcron <ryan77627_>jpoiret: Thanks, I will look into them, is there references to these functions in the Guix manual or is there somewhere else I should look? <jpoiret>the guile manual should be the place to look into <Guest1936>zacchae[m] hmm I don't understand what you mean. Why should I create a mcron job to move a dir to the home folder? basically I just need a xdg-config-service but for the home directory <apteryx>I think pyproject-build-system doesn't work with mesonpy <apteryx>on core-updates, trying to build python-scipy with pyproject-build-system <zacchae[m]>Guest1936: xdg-config-service adds a file to the store and symlinks it into .config. I don't think you want your passwords added to the gnu store (even if they are encrypted). You want your password store to be mutable (writable) as well. You should just clone your ~/.password-store from wherever you have access from. If you really must automate it, then I think an mcron would do the job <negligiblebeans>script is trying to fetch some data from the internet, but it does not have permission. However I am not sure how to continue <lfam>negligiblebeans: Your analysis of the bug is correct. Within the container used to build packages, there is no network access. That means that all of the package's dependencies must be provided before the build starts, either by packaging them as well and including them as inputs to your package, or by bundling them together (which is common for Go software) <jpoiret>negligiblebeans: how are you trying to package this? ie what build system are you using? <jpoiret>whoops, didn't see your paste 🙃 my bad <negligiblebeans>jpoiret My main attempt was using the gnu build system, to mirror the installation instructions. However I did give the go build system a quick try too (whose lines are commented out in the paste) <jpoiret>I think you're better off with the go build system <jpoiret>the Makefile doesn't seem to be doing much (apart from maybe the manpages <jpoiret>since guix is so different from a usual distro, the build systems in Guix do a lot of non-standard stuff, especially for languages with their own dependency management <unmatched-paren>negligiblebeans: if the makefile installs the manpages, you can add a phase after 'build to run make install-man or whatever while still using go-build-system <unmatched-paren>nom[m]1: the files you need write permissions for should not be managed by guix home anyway <jpoiret>they have their own manpage generator ☠️ <jpoiret>might not be the easiest first project <jpoiret>you could maybe try using the go-build-system but replacing the build phase by a make invocation <jpoiret>you're straying off the beaten path there though, might not be a good first packaging experience <jpoiret>if you do end up not generating the manpages, please mention it somewhere <jpoiret>(i personally hate go packaging, I've stopped using some programs and services because of it) <lfam>Go is pretty easy if you do it the Go way. They basically reimplemented Guix at the language level. But there's a mismatch between our expectations and theirs <lfam>If you can just build one of their Git repos with all the dependencies bundled, it's simple and reliable <lfam>Guix also has a recursive importer for Go packages, which should work when the Go developers don't stray from their own conventions <jpoiret>what i hated most was having to package 100s of dependencies, some with different commits as the ones which were already in guix <negligiblebeans>Currently, naively using the go build system produces this: https://paste.debian.net/1277052/ . It looks like I might need to specify where the main file is or something. I've tried setting the "#:import path" to "./cmd/gh", which seems to match with what the go build script does, but I still get the same issue <lfam>jpoiret: Yes, I would say "don't do that" <lfam>Just use the bundled dependencies or use the importer <unmatched-paren>the only time you need to make a new package is if they've released a /v2 or the like <lfam>negligiblebeans: Usually, the import path is equivalent to the domain name location of the package <jpoiret>right, most of it worked pretty nicely but you still had the odd couple of dependencies <lfam>Something like 'github.com/cli' <jpoiret>i remember packaging the qt bindings which was a pain <unmatched-paren>so if you have github.com/foo/bar you'd make that go-github-com-foo-bar-v1, and github.com/foo/bar/v2 would be go-github-com-foo-bar-v2 <jpoiret>also some pre-go modules dependencies aren't imported properly i think <lfam>negligiblebeans: The import path is the canonical name of the Go package, according to the Go tools. It's how Go programs refer to each other <negligiblebeans>This is ultimately the build command that I want to the go-build-system to generate. i.e. it passes the path "./cmd/gh" <lfam>If I understand correctly, you should ignore that <lfam>If you were to build this package not using Guix, what command would you use? <negligiblebeans>but admittadely I've never used Go before, so I'm not familiar with its build commands <lfam>It looks like they've decided to make it a bit complicated, but I'm sure it's possible to package for Guix <lfam>I would first try to build it outside of Guix <lfam>That will definitely help <lfam>So, if I wanted to package this, I'd first start by using our package importer: `guix import go --recursive github.com/cli/cli` <lfam>After that, you'll need to make some revisions here and there, but you'll have avoided days of tedious work <ngz>Speaking of the Go importer, it always raises an error when trying to import recursively github.com/rclone/rclone. <lfam>"Someone" should fix it ;) <lfam>I have to go. Good luck everyone!