<drakonis>buuuut it should be back on the table after i'm done with my project
<GNUtoo>kaelyn: I've also been playing a bit with x86_64-w64-mingw32 (mainly to test how far it could go) and we probably need to patch bzip2 to enable to build more things with it: if I try to compile other things than xz or hello world, it would try to compile bzip2 and fail. There is a patch in msys2 to convert it to autotools but I've not managed to apply it in Guix (when running make to build guix, guix would
<GNUtoo>complain about max heap and similar thing (that comes from libgc) and make would fail at the end or never complete)
<GNUtoo>(It would be really neat to be able project for multiple platforms to get more contributions in Guix, and it'd probably help build-testing software that are super strict with portability, like Wireshark for instance, or things like unetbooting that works on multiple OS)
<antipode>pkill9: I have been working a little on extending gnunet-scheme to support DHT and CADET (to eventually support FS and maybe GNS), which I expect to be a good basis for P2P substitutes.
<antipode>P2P substitutes in the general case sounds a bit too ambitious to me, so I intend go for P2P downloading of (source) tarballs first (like https://issues.guix.gnu.org/44199, but in (guix download) and with http / https / ... fallbacks)
*GNUtoo would also be interested in something slightly different: reuse Tails perm configuration file (and modify it a bit) to block non-tor traffic: this way the substitute would be gotten through Tor. Though I need to actually package perm first
<antipode>(NSE and DHT support are decent now, CADET is what I'm currently working on)
<warren>Hi. I'm wondering if someone experienced at Guix might be interested in contract work involving using Guix as a build system for particular FOSS cross-distro portable binaries. There's already some similar examples to work from. We know Guix is good but we're overloaded so hoping to find help on this. Please DM if you're interested.
<warren>It is probably off-topic to discuss in channel here, and it's rude to DM people, so please DM me if you would like to chat.
<GNUtoo>ok, it was not to apply, it was more to understand real life usage of Guix
<GNUtoo>For instance it's being used to build bitcoin binaries
<GNUtoo>And as I understand in the UK there is also some state services that use guix for their infrastructure (to host web services for instance)
<warren>yes, the clean bootstrap and reproducibility of guix is very attractive when you want similar assurances for portable binary distributions for anything
<warren>(Here I'm describing history, not the specific use case we want to hire for now) Prior to Guix, Bitcoin used "Gitian" which used debootstrap to make a particular Ubuntu buildroot. Those binaries were reproducible but without any chain of clean bootstrap so you couldn't know how safe it was.
<GNUtoo>I think the tor-browser had similar issues in the past
<GNUtoo>So it's really interesting to fix things like that
<GNUtoo>I've looked a bit at the way bitcoin uses guix and it seems to use the bare minimum of Guix: it creates a standalone container which has a basic toolchain, and then it somehow builds things on top of that
<warren>as of Bitcoin Core 22+ they dropped these compat wrappers because they switched to Guix. They picked the particular version of glibc/gcc/etc so they don't need the symbol stripping hacks anymore.
<GNUtoo>wow, I though Guix was just something on the side
<GNUtoo>So I guess the idea now is to add support for platforms not yet supported by Guix like OSX and so on
<ulfvonbelow>our tests that use Xvfb seem not to be waiting for the server to be ready before running the tests. This causes some nondeterministic test failures depending on how long it takes X to start up.
<warren>Guix was adapted in a specific, narrow way to build it not only safely but also to result in static binaries to maximize portability across many distro targets.
<oriansj>GNUtoo: guix thanks to its bootstrapping work is the gold standard for trusted builds in the crypto world
<iyzsong>GNUtoo: what works needed for Replicant and Guix if I want to run 'guix package -i element' on x86 or aarch64 powered postmarketOS (or guix system)? does it sounds reasonable :)
<oriansj>well yeah, being forced to use OSX sounds miserable.
<GNUtoo>iyzsong: one day it would be nice to not depend on distributions like Trisquel and prebuilt binaries to build Replicant, so doing something like it's done for bitcoin/bitcoin-core would be desirable I think
<warren>fortunately nobody considers OSX to be a serious server deployment target, it's only popular with developers
<drakonis>because apple finds new ways to screw up developers
<GNUtoo>iyzsong: for now people have either to run Trisquel, Debian or use that in a chroot or LXC through libvirt
<GNUtoo>iyzsong: the setup with Guix would be easier: install guix, run a script, and you'd be able to build it directly
<warren>I'm interested in hiring for contract work: 1) Adapt Bitcoin's Guix build approach to similarly build portable binaries of specific other FOSS projects that we make. 2) Generalize that to be an easy to use build system for ANY FOSS project. 3) Build Guix-based docker and flatpak containers so binary distributions of such are similarly safe for more than just one binary, similar to Alpine levels of container minimalism. Maybe this already exists?
<GNUtoo>for OSX what about toolchains like zig that can also build C code for mach.o ?
<GNUtoo>It might need to be bootstrapped though...
<warren>#2 might not be easy enough to be general purpose, maybe it's a simple consultantcy task, people WILL be willing to pay for guix adaptations like this.
<warren>GNUtoo: I would assume so? you run homebrew on OSX itself, it isn't cross-compiling
*GNUtoo has followed that a bit to understand how porting a free software OS to a new platform without cooperation from the vendor worked, and it seem that behind asahilinux there was cooperation between the people working on compilers for OSX and asahilinux
<GNUtoo>So things like making binaries that work on OSX was required to make all that possible
<GNUtoo>though the best way to find out is probably to do the work of adding support for that in Guix...
<GNUtoo>This way you're sure that it doesn't contain nonfree software...
<GNUtoo>(or maybe it was for their bootloaders, but anyway they had to deal with things like that)
<raghavgururajan>GNUtoo: Thanks so much for the info at #replicant. I'll look into them.
<iyzsong>GNUtoo: well, it sounds more difficult for guix on OSX OS than OSX apps on linux packaged by guix. there are some free apps on other platforms (eg: android) that i have interest to run on my guix system, that's what i asked for...
<ulfvonbelow>another thing to check would be log files, though they usually don't grow terribly fast
<apteryx>has anyone gotten gdm to listen on port 177 for XDMCP?
<ulfvonbelow>by nature deleting system generations requires root (and even if it didn't, the entries for old systems have to be removed from the bootloader, which requires root anyway), so it's a separate command from 'guix gc'.
<apteryx>oh nevermind, it works, my 'ss' command was wrong (missing 'u' for UDP).
<apteryx>now my test proceeds a bit further, stops at: gdm: Gdm: GdmDisplay: Session never registered, failing
<apteryx>(I'm testing connecting via vncviewer (tigervnc) via the XDMCP server of GDM)
<yuu[m]>hasn't guix packages an emacs built with native compilation NATIVE_FULL_AOT?
<ulfvonbelow>this is really puzzling. Apparently libxtrans has pretty much always refused to make a sticky-bit /tmp/.X11-unix directory when non-root, and xorg has always used it more or less as it does now. But only recently has our xorg-server-for-testing begun exhibiting this behavior.
<nckx>Yeah, you'd add the package variable name to your package list. I use the -pgtk variant myself.
<nckx>You'd modify the package the way you modify any other guix package: using (package (inherit emacs-pgtk-native-comp) (your changes) (go here)) in code, or with package transformation options (see manual) if you use the CLI (which I don't, so can't help with).
<nckx>Well, I could, but it would just be manual reading storytime.
<ulfvonbelow>note that package transformation options are also available in scheme
<nckx>Package transformation options (including CLI) won't work here, because the emacs source is not a Git reference.
<kaelyn>sneek: later tell GNUtoo thank you for taking a look at the patches! I've actually not done much with mingw & I updated it as part of an attempt to get newer versions of dxvk building (I'd hit an error that was fixed in 9.0.0)
<apteryx>hm. I tried migrating from slim to gdm, and it seems to hang on boot. has anyone experienced something like that? before the GUI comes up; I can't even change virtual terminal.
<apteryx>perhaps it crashes due to my aging video card? I see: "elogind: New session c1 of user gdm.", "gdm: Gdm: GdmDisplay: Session never registered, failing", "gdm-session-worker: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed", "elogind: Removed session c1." and "gdm: Gdm: Child process -451 was already dead.".
<apteryx>perhaps my ~/.xsession gets in the way? seems to work in a VM
<ulfvonbelow>apparently I was wrong, and for at least half a year now none of the xorg-server-for-tests instances spun up in package builds have created /tmp/.X11-unix directories. I guess there's some alternative transport they use?
<Kabouik_>I heard once that there would be packaging hacks to skip the hash verification, if I want to build a package that fetches the latest HEAD commits from git every time I call guix install package
<ulfvonbelow>the channel introduction itself is optional; without the ability to verify the initial commit, there's no point to specifying an initial commit, since 'guix pull' will use the latest one anyway. In other words, to not use authentication, simply omit the entire (introduction (make-channel-introduction ...)) part.
<rekado_>just got a message from IT: “The cause of the network disruption has been found and the problem has been fixed.”
<Kabouik_>I see, but I was confused by the manual page saying "the first commit where the authorization invariant holds, and the fingerprint of the OpenPGP key used to sign that commit (it’s not strictly necessary but provides an additional check)"; I thought the brackets only applied to the second part of the sentence.
<ulfvonbelow>hm, actually, what I said might not be quite accurate. Conceptually a commit id does fully specify the contents of the initial commit, whether signed or not, so it makes sense to include it even without a signature. Subsequent commits, however, would have to be signed. Note though that git commit hashes use sha-1, which is considered somewhat weak nowadays. I suppose if one wanted to try specifying only the commit identifier, my best
<horizoninnovatio><ulfvonbelow> "by nature deleting system..." <- Thank you, I'll have a look.
<pkill9>I've bloated my config to too much complexity D:
<rekado_>does anyone know how to import golang.org/x/image/tiff with the go importer?
<Kabouik_>I don't understand why I am getting this git fetch error with my package, the url seems right: https://p.teknik.io/Raw/nEIND (the first part of the paste is the package.scm, the second is the error log when trying to install it)
<nckx>Oh, berlin. It was very low. Like 3-4 or so.
<nckx>I don't know what you consider interesting. It showed that connections would immediately spawn a Shepherd SSH service, which would then twiddle its thumbs for ~30s (but sometimes less, so it's not a hard time-out as I originally thought), then lets you in.
<nckx>So that would point to something like PAM (or a network dependency) timing out, I guess?
<ulfvonbelow>Kabouik_: builds are run in an isolated container. The only exception is that fixed-output derivations can be built with network access, since their output is fixed. This requires that a hash of the output is specified. Since you didn't specify an output hash, the source origin doesn't result in a fixed-output derivation, and it doesn't get network access.
<ulfvonbelow>Kabouik_: you can either use a git-checkout object instead of an origin object as the source - in which case you may want to look at ~/.config/guix/current/share/guile/site/3.0/guix/git.scm around line 694 to see how that's defined - or simply use options->transformations from (guix transformations) in conjunction with the with-commit or with-branch options, which will in turn use a git-checkout object internally.
<nckx>Kabouik_: <replacing the hash with zeros … might … give it network access in that case> Yes, but useless network access, as whatever you download will not match the bogus hash and abort. You can't think your way out of the isolation. There is no hidden networking switch inside a build container.
<Kabouik_>So does that mean that there is no way to build a package with latest sources all the time (meaning the hash can't be known in advance and has to be skipped), or does that imply that the only way might be using guix transformations in conjunciton with --with-branch=PACKAGE=BRANCH (which I'm currently trying to do, but this is not trivial for me)
<ulfvonbelow>there is a way - the aforementioned git-checkout objects - but it's not documented well in the manual, whereas ((options->transformation '((with-branch . "my-package=master"))) my-package) is
<nckx>Kabouik_: git-checkout will do just that, but it doesn't do it by ‘enabling network access in the build container’. Since that was a possible (not unreasonable but wrong) interpretation, I wanted to point it out. Think of it as checking out the source for you in ‘user mode’ (not in the daemon), ‘writing’ a source form with the latest hash, and passing that to the isolated daemon build environment.
<ulfvonbelow>although you'll probably also want with-git-url in addition to with-branch, since the original package isn't using a git reference
<ulfvonbelow>probably more straightforward to just use git-checkout
<nckx>I'll admit I'm kind of biased against transformations & towards anything that produces a more regular-looking Guix package, like git-checkout.
<nckx>I think the former use the latter under the hood though.
<Kabouik_>So git-checkout it is; now I have to understand how to use it and what to delete from my current .scm file. I'm about to create a monstrosity.
<ulfvonbelow>Kabouik_: a <git-checkout> can have as fields 'url', 'commit', 'recursive?', and 'branch?'. It's like a <git-reference> in that regard, except that a <git-reference> can't specify a branch.
<Kabouik_>So I think the package is now correctly formatted according to your advice (many thanks, and sorry for being this slow, I'm trying ot read docs at the same time to better understand), but I need to use a use-modules for git-checkout. I already have a use-module (guix git-download) but apparently that is not enough for git-checkout. So my question is, how do I know which module to load when I call something new in my code? I
<Kabouik_>checked git.scm L694 but can't see a reference to the module function. Or is it use-module (guix git)?
<ulfvonbelow>note that I don't think you need to guix pull to get an updated version of that particular package, due to the way it's defined.
<Kabouik_>This git-checkout will be very useful for me, since I am interested in some third-party software that's only on git repos I trust and not having to manually download them and check the hash will be more convenient for me when updating
<zamfofex>vivien: I remember you once wanted to use Emscripten for something. I suggested just using ‘clang --target=wasm32’, but you say you wanted to be able to use e.g. ‘readline’. Here’s another suggestion: Have you considered using ‘zig cc --target=wasm32-wasi’? Zig is packaged in Guix, and it features a powerful C cross compiler based on Clang. If you want to use the compiled code in a browser, you can use ‘@wasmer/wasi’
<nckx>unmatched-paren: Mails will be word-wrapped to 72 characters. Anything exceeding that will be parsed as a new (and invalid) ‘(verb)NNN (args)NNN’ line. You should get a mail from Debbugs on both success and failure.
<apteryx>hmm. switching slim-service-type to gdm-service-type in my config really does lead to hang at boot
<unmatched-paren>Specifically, I'm using a slightly outdated version of aerc from guixrus while I wait for the non-outdated patch I just sent to be reviewed, which thanks to Go isn't going to happen anytime soon :)
<mrvdb>Is there a way to get notifications from certain issues?
<Kabouik_>How do I get more information on each Scheme functions/record/field, namely to see which fields a function can take? I'm trying to add a (patches (search-patch "xxx.patch")) to (source (git-checkout …)) but that complains about "extraneous field initializer".
<Kabouik_>Specifically, I think that's my main issue with Scheme/CommonLisp so far: I am used to R where I can do ?command to know how a command is used and which arguments it can take, or same with bash
<Kabouik_>I'm missing that kind of manual for lisp
<Kabouik_>The package I want to use is nnn file manager, which is receiving multiple commits a day; I just want my custom package to update it to the latest all the time instead of doing that manually and applying my patch every time
<unmatched-paren>The German version, specifically, seems to want to reference nonexistant nodes.
<unmatched-paren>Anyone else getting this @ref texinfo error on the latest commit when `make`ing?
<Kabouik_>On other distros, I just used to git pull regularly, apply my patch manually, and compile and install. But with guix, making my own package seems to be better than compiling manually from the cloned repository, so I wanted my package to do the pulling and patching all by itself
<Kabouik_>Also, on other distros, I usually just ended up not upgrading nnn at all because I was too lazy to apply my patch and custom make options every time, so here again a package.scm doing the work for me was better
<Kabouik_>Well, I named my package "nnn-git", so if it always pulls the latest commit and does the same operation on it, it does what I want, and in that way is not redundant with the nnn.scm from the guix channel (which is fixed to a specific version and hash)
<unmatched-paren>These 'inputs' include actual inputs, native-inputs, and propagated-inputs, along with the version of Guix, the arguments, the phases, the source, and the machine
<unmatched-paren>A package that might create a different output without changing the inputs is broken.
<Kabouik_>To produce the same results from a set of inputs, I would indeed favour nnn.scm and not nnn-git.scm. But there are some packages whereby I'd like to keep close to remote git and not be using fixed versions if they don't have ties with the things I would want to keep reproducible (like R analyses for instance)
<Kabouik_>I see, but then I was told that packaging third-party software not in official channels is the best way to use third-party software. I understand that one of the advantages of guix is to make everything reproducible, but I'd like to be able to adjust the mix between reproducibility and flexibility when a third-party software I like is being updated, without having to repackage with a new hash
<unmatched-paren>I don't really see why you'd want to stay on HEAD at all times; if a change you like is made, sure, change the package to incorporate that change. But surely you don't need to automatically pull in every little change made to the software, especially when doing so goes against the grain of the package manager you're trying to use?
<unmatched-paren>I'm using aerc, and I'm perfectly happy with a pretty outdated version, even though they're getting lots of commit activity
<Kabouik_>I don't know, nnn and nmail for instance are among the tools I use every day and they get bug fixes or new features regularly, but those are not necessarily immediately bundled into git releases. Yet, I'd be happy to enjoyr or even test those new features when they arrive.
<Kabouik_>For instance at some point I wrote a few plugins for nnn (not in common lisp, as you may expct :p), I needed my local nnn binary to be up to date all the time for that
<podiki[m]>Kabouik_: you can just use the package transformations to always build from latest git commit
<Kabouik_>civodul: thanks for the reference page. It does say that (origin ) needs a hash known in advance. And git-checkout doesn't appear to allow patches. So I guess transformations might in the end by the best way for my specific case here (with --with-branch=package=branch and --with-patch=package=file), but those are CLI so I need to translate them in Scheme for my .scm filew
<Kabouik_>podiki[m] yes, that's what I was starting to think too
<Kabouik_>Also it says "Package transformation options are preserved across upgrades: guix upgrade attempts to apply transformation options initially used when creating the profile to the upgraded packages.", so maybe it's fine if I just don't create a custom package.scm with the transformation, and instead just install `nnn` from the Guix channel with those transformations in CLI, as apparently both the latest-commit transformation and
<Kabouik_>the patch transformation should be conserved in guix upgrades.
<Kabouik_>Actually guix package --export-manifest just shows installed packages, not their scm file, and email@example.com doesn't get installed with --with-branch=nnn=master because "guix install: error: the source of firstname.lastname@example.org is not a Git reference". --with-patch=nnn=$HOME/path/to/my.patch works though, and that's already good news.
<civodul>Guest95: hi! do you mean that the bug came back?
<Guest95>civodul: i mean that there has been fixed a problem like this but with different package glibmm-2.64
<Guest95>civodul: and I suppose that cairomm-1.14 needs the same
<kaelyn>civodul: I haven't been certain how to test the version upgrade more thoroughly as I wasn't sure what packages work with it (and if I try to set a mingw target e.g. through "guix build --target=x86_64-w64-mingw32" I always get an error related to tar being available bootstrapping. I also noticed in your output it is referencing a mingw 8.0.0 path
<civodul>Guest95: ah, i see; would you like to submit a patch?
<civodul>kaelyn: i tried "guix build gzip --target=x86_64-w64-mingw32" and similar commands
<kaelyn>I've had some success using the toolchain with package variants that use `(cross-gcc "x86_64-w64-mingw32")`
<Guest95>civodul: I'm sorry I'm a novice, so I just wanted to make someone notice this and solve it if possible
<kaelyn>I also see the same error with the gzip build without the mingw update
<two[m]>added glibc-locales to the container, fixed!
<kaelyn>(I'm trying it with my update now to see if the error is the same or not, now that I have a build target that sort of builds)
<civodul>kaelyn: right, so i guess this is something we'll have to address afterwards, or it's going to be much less useful :-)
<apteryx>I don't get it; on some machine I have both berlin and bordeaux keys in /etc/guix/acl, 'guix weather linphone-desktop' says ci.guix.gnu.org has it, yet 'guix shell linphone-desktop' fetches the substitutes, but 'guix upgrade' attempts to build it
<kaelyn>I think I may have bitten off more than I can chew... I wanted to update dxvk to a newer version, but newer versions need to be compiled with mingw. I got it almost building (with the mingw upgrade), with dxvk failing during configure because it can't find the vulkan library. I'm tryng to figure out how to build vulkan-loader with mingw, and that is so far the hardest part to even get to build
<Kabouik_>I don't think there are transformations for changing compile options, are there? Just realized that my transformed procedure works but there was a non-default compile option in my original package project. -.-
<drakonis>civodul: i'd like to participate more often
<civodul>drakonis: that'd be much welcome; you're also welcome to ask if you're unsure how to proceed, perhaps that can help improve the whole process
<drakonis>i had been busy with things and drifted away a bit
<podiki[m]>which hash do you mean? there is the source hash (if you inherit and don't change it will be the same as origianl source)
<antipode>The hash you put in the sha256 of the origin is only over the source code.
<podiki[m]>and there is the /gnu/store/<hash>-pkgname-version hash, which changes on any changes to the package definition itself as well
<antipode>Any build tools or configuration flags or phases are irrelevant for what you put in the sha256 field.
<antipode>kabouik: The hash is only over the unpatched source code.
<kabouik>I think in my case it would be the source hash, but since I want to apply a patch to it, inheriting it from the base package wouldn't help anyway (and is not easily feasible because I need (origin) to apply a patch anyway)
<antipode>kabouik: WDYM with not easily feasibleN?
<antipode>There's a nice procedure package-with-extra-patches
<antipode>How would inheritance be hindered by patches?
<kabouik>I tried earlier to just install the package already in Guix channel with the transformations I wanted. To summarise, I want three custom changes: use latest git commit, apply a patch to the source, and compile with an extra option. I came to realize that using the latest commit goes against the Guix reproducibility philosophy, so I started leaning towards dropping that from my wishlist, and just writing a custom.scm that would
<kabouik>contain the patch and the compile options. But then, I don't really want to edit it regularly to change the hash and versions, I'd prefer inheriting all that from the Guix-channel package.
<kabouik>And if I ever want to get the latest commit, I guess I can always install with --with-branch=package=master anyway
<kabouik>I will look into the package-with-extra-patches you mentioned, didn't know about it
<podiki[m]>well a source hash has to be updated only if the source is updated...you could just use a particular version rather than inheriting, or just accept that there is always some package maintenance
<podiki[m]>also, for nnn I count 3 version related commits in the last year
<kabouik>But to make a variant that is just a patched package from Guix channel, having to manually maintain the variant for the hash and version seems just error prone, since I would have to keep an eye on the base patch all the time for no added value
<kabouik>Yes, that was the point of the "latest-commit" on my initial wishlist, the package is not getting updated often; but nnn itself is changing on a daily basis
<kabouik>But I understood that building packages from latest commits beats the point of guix reproducibility, so I got it that it's better to stick to fixed versions (and occasionally use CLI transformations if I need bleeding edge commits)
<podiki[m]>sounds like you want a variant package that inherits from nnn, changes the build option (that needs a package definition), but adding a patch and using latest commit can be done with package transformations at install
<podiki[m]>then everytime you install it pulls the latest commit
<podiki[m]>(I have a manifest where I use transformations to always use latest commit on some branch for some packages)
<kabouik>I was able to install nnn (guix channel) with CLI transformations (latest commit + patch), but not quite able to transform that into Guile (the errors I got were probably easy to fix, but I didn't find how yet and seeing an example would help).
<kabouik>Can I see those packages? Though if I remember correctly my issue was to transform the --with-patch=nnn=my.patch into its Guile equivalent
<podiki[m]>what do you want in the end? if you just want to have the package installed as you want it, sounds like you are mostly there (you could us a manifest to have the transformations functions explicitly)
<podiki[m]>the cookbook link I sent should be helpful, sounds like what you want (for reproducing packages on another machine)
<unmatched-paren>davidl: when you want to paste a code block longer than 3 lines, could you please use paste.debian.net, 0x0.st, paste.sr.ht, or something similar?
<kabouik>I know how to export the output to a file.scm but my misunderstanding there is I was expecting that the manifest to look like a package-specific scm files, with transformation in it.
<podiki[m]>no, it is a list of packages generally, though can have Guile code that modifies them; this is used by e.g. guix package to install packages
<podiki[m]>it does not export the full package definition, those live in Guix itself and are not needed for a manifest (Guix looks up the package name to know what it means)
<kabouik>Actually, reproducing packages on different machines is part of what I want, but it doesn't exactly cover all the needs. What I wanted is a custom package with my patches, that I could decide to install or not on different machines. A manifest is a bit more all (packages) or nothing.
<kabouik>nnn is not all that important in the end, it's just the package I chose to experiment and learn (slowly, as you can see).
<podiki[m]>you could even use some code that selectively adds or not package there probably
<podiki[m]>I use several manifests for organizational purposes, for instance
<kabouik>My goal in the end really is to learn packaging third-party software from git, with or without custom changes (patches, latest commit or fixed versions with hash, compile options), and nnn was interesting because it is already packaged for Guix channel so it gave me an example, and also opened new possibilities (inheriting, hopefully to avoid duplicating maintenance too).
<shcv[m]>I'm contemplating packaging doom-emacs for guix so I can get all of my home setup into guix home; which approach do you think is best?
<shcv[m]>1. Just install the doom utilities, and then leave everything else (.doom.d, .emacs.d, all of the straight.el packages) in mutable userspace
<shcv[m]>2. Pass in the config files, and build the whole .emacs.d as an immutable blob by invoking `doom install` and `doom sync` during the build phase (rebuilding from scratch every time)
<shcv[m]>3. Go all in and make configuration records for the doom configs, and try to somehow redirect straight to use separately installed packages managed by guix
<apteryx>shcv[m]: can't doom-emacs use the Guix-provided Emacs packages instead of reinventing the wheel?
<kabouik>My USB-C charger has a 65W port and a couple slower USBA ports. When traveling I usually take only that too, and will plug the phone to the slow ports when I have time, to the fast one when battery charging is more important than preserving it from the extra wear.
<antipode>Because to me it kind of seems a weird thing to do.
<antipode>kabouik: Do you have sources for fast chargers (laptop chargers?) causing extra wear?
<gnucode>woo hoo! I just sent in a bug report that shows that auto login to tyy doesn't work for all ttys.
<kabouik>Well, at work I use a laptop and don't bring a phone charger, so if my phone needs juice during the day, I just unplug the laptop (use its battery) to recharge the phone a bit, without dealing with multiple chargers.
<kabouik>antipode I just take that from a friend who is into repairing electronic devices, I could ask him sources
<antipode>OTOH avoiding separate chargers was the main reason of the EU for pushing for a single charger standard ...
<kabouik>I believe the charge rate is not the actual issue for battery wear, but the heat it causes is
<kabouik>My phone goes above 45°C when fast charging from a low battery level
<warren>Yesterday in chat (see logs) I wrote we're looking for help from someone who can adapt Guix to build other FOSS into portable Linux binaries. https://twitter.com/rocky_linux/status/1554844007356051457 We're also interested in someone with skills and interest to work on this grander goal: Use guix to bootstrap and demonstrate a reproducible core of packages for Fedora or Rocky Linux. Those distros would need a lot more more work to adopt it later but
<warren>merely demonstrating that it is possible to make the core reproducible would inspire them to take it seriously in the long-term.
<vagrantc>warren: might also be worth mentioning on #reproducible-builds on irc.oftc.net or email@example.com
<warren>ugh it's effort to setup IRC bouncer for a second IRC network
<kabouik>So… I ended up inflating my nnn patch, which no alters not only `nnn.c` and `nnn.h`, but also the Makefile so that my custom compile options become default after the patch is applied. This means I can get all I want with `guix install nnn --with-patch=nnn=$HOME/.config/guix-private-channel/my.patch` (and even latest git if I add --with-git-url=nnn=https://github.com/jarun/nnn.git). It's not exactly what I wanted in the first
<kabouik>place, but I have to change my plans because (1) I'm not learning Guile/Guix as well as I hoped I would, (2) my plans where not very guixy apparently so it's best altering them than skewing the philosophy I'm trying to blend into.
<kabouik>Seeing that I do have a private channel working, there's still a little frustration that I can't use it directly to get the nnn I want from a new machine (and cherry pick what I want on a per-package basis, so not with manifests), but I can download the patch from the git repo and install manually with the above guix install command and transformations.