IRC channel logs


back to list of logs

<cbaines>abhicherath[m], git am is the command to apply patches in mbox form
<sneek>Welcome back cbaines, you have 1 message!
<sneek>cbaines, antipode says: I've written a few comments on the fibers streaming patch.
<cbaines>there's also a branch here which contains those patches
<jab>abhicherath[m]: I have been using debbugs via emacs to apply patches.
<jab>though I have only applied one patch total :)
<jab>debbugs lets you use I think it is o M to save the patch to a location, then switch to magit to apply the patch.
<shcv[m]>how do you recommend I build a single package from a module I'm editing?
<abhicherath[m]>Im a little unsure of what to do still, so i have a guix vm and i see that the guix binary is in /gnu/store symlinked to /.config/guix/current/bin
<shcv[m]>I have (define-public python-agentspeak ...) in module (masr packages python-xyz); I tried guix build -e but apparently don't know the right expression to use
<abhicherath[m]>How do i apply patches with a running system like this?
<abhicherath[m]>Sorry, bit new to the whole functional package management thing
<shcv[m]>nvm, `guix build -K python-agentspeak -L .` worked
<vagrantc>abhicherath[m]: you probably want to buidl from git ... let me see if i can find the section in the manual about that...
<vagrantc>abhicherath[m]: and the following sections ...
<abhicherath[m]>I see i see and then after ive built it i run guix system-reconfigure?
<vagrantc>./pre-inst-env guix ...
<vagrantc>once you have that set up, you can apply the patch, and run whatever guix commands as "./pre-inst-env guix"
<philip>When should a package be named `texlive-latex-foo` vs. `texlive-foo`?
<shcv[m]>ok, next problem: importing the python package from pypi means downloading the source using a pypi-uri, which I think means it already has the 'extra' test files stripped out - should I just drop the check phase, or work on getting the full source from github?
<abhicherath[m]>Thank you!!
<kaelyn>Hi #guix, for "guix home", how would I add a symlink to a file in a package to my home directory? Specifically, I've create a simple package for passff-host (the native messaging host component for the passff browser extension), and I want to create a symlink from the "passff.json" in the package to "~/.mozilla/native-messaging-hosts/passff.json".
<kaelyn>From running "guix home search .", I think the home-files service type may be the answer, but I'm uncertain how to use it and the manual doesn't describe it.
<Cairn>I'm very new; could someone walk me through how to modify a package definition to to remove a certain file?
<Cairn>Or is there another mechanism to delete a file from a package that doesn't involve modifying its definition?
***califax_ is now known as califax
<singpolyma>Cairn: you will need to create a package that inherits and then adds a phase to remove the file (or else replace the phase that adds it, or whatever)
<Cairn>Ah ok
<Cairn>I'll go check out that section of the manual then. Thanks singpolyma
<Cairn>Having trouble with `guix system reconfigure` cause the `eigen` package fails. How should I proceed?
<Cairn>Hold on, trying to to garbage collect, cause it might be unneeded
<atka>sneek: botsnack
<cnx>how to use specification->package with alt output, e.g. git:send-email?
<cnx>oops sry wrong window
<PurpleSym>podiki: That patch does not apply for me and I don’t see any switch called `ROC_ENABLE_PRE_VEGA`.
<sneek>Welcome back PurpleSym, you have 1 message!
<sneek>PurpleSym, podiki[m] says: for rocm just came across the Arch patches, like maybe there is something in there to enable support for the hardware you have on newer versions? (just saw an update today too)
<PurpleSym>As far as I see rocr-runtime and rocm-comgr still mention gfx803-based GPU’s, but that could be just leftovers from the past.
<unmatched-paren_>hello, guix
<sneek>atka: Greetings!
<cnx>hi, how to use specification->package with alt output, e.g. git:send-email?
***iyzsong-alt is now known as iyzsong
<unmatched-paren_>cnx: just "git:send-email", i'd think
***taiju is now known as Guest8810
***taiju` is now known as taiju
***unwired0 is now known as unwired
<taiju>cnx: this is my manifest.
<nckx>cnx: specification->package+output, but you have to treat the result with circumspection because it actually returns two values. Something like (packages (map (compose list specification->package+output) (list "foo:bar" "fiz:buz" …))) should work though.
<nckx>And of course it accepts specs without :output parts as well, so you can just apply it to everything.
<nckx>Morning, Guix.
<cnx>thanks, i looked into the module and found specifications->packages which does exactly that
<nckx>Is that new? I've never heard of it.
<nckx>(It is.) Great, now I don't have to suggest map compose to people like a madman.
<vivien>Dear guix, how do I get a cross-build package as a file-like? There is something called package->cross-derivation in (guix packages), but I’m not sure how to use it.
***Guest8810 is now known as taiju
<vivien>It seems like package->cross-derivation returns a derivation, how do I convert it to a file-like?
***taiju is now known as Guest3605
***taiju` is now known as taiju
<antipode>vivien: Don't use it, use with-parameters instead:
<antipode>something like (with-parameters ((%current-target-system "aarch64-linux-gnu")) the-package)
<antipode>Should also works for non-package file-likes that support cross-compilation
<antipode>Maybe nevermind, you still have to somehow build it.
<antipode>Maybe: ,build (with-parameters ...)
<antipode>(in the REPL)
<antipode>AFAICT there is no _procedure_ for actually building things in the manual.
<vivien>antipode, it seems to work!
<dirtcastle>i just installed guix in arch linux using the installer script. failed to connect to /var/guix/daemon-socket/socket : no such file or directory. I looked up online for answer and tried them out. nothing worked
<vivien>dirtcastle, is the guix-daemon (systemd) service running?
<vivien>I mean guix-daemon must be activated
<dirtcastle>vivien. it doesn't exist
<dirtcastle>I tried to enable, start, restart. looks like the file just doesn't exist
<dirtcastle>should I run the script again?
<vivien>I don’t know to be honest
<attila_lendvai>when i use rottlog through the rottlog-configuration in guix, then it rotates the files into /var/log, even if it's somewhere deeper in a subdirectory. any insights on how to rotate into the same dir?
<nckx>attila_lendvai: I don't, but I find that behaviour so strange that I'd file a bug (with Guix, first) to make sure it's even intentional.
<nckx>Even if somebody actually wants that it's an odd default.
<attila_lendvai>nckx, done:
<nckx>Oh, thanks!
<nckx>dirtcastle: Is the daemon successfully running?
<nckx>Well, success modulo the fact that it's unusable…
<mrvdb>I submitted a patch yesterday, anything else I need to do to get it applied, other than waiting? ( )
<declan>Hey guys. How to use gcc@9 with gnu-build-system?
<nckx>Adding it as a native-input generally suffices.
<nckx>mrvdb: Only the wait remains.
<nckx>For bonus points from readers/your future self, add a comment explaining why it's needed.
<mrvdb>nckx: allrighty
***wielaard is now known as mjw
<unmatched-paren_>does anyone have a working emacs configuration where, when you make a commit in magit, a prompt for the gpg password appears and the commit is signed? I've tried various combinations of epa-pinentry-mode, epg-pinentry-mode, allow-loopback-pinentry, allow-emacs-pinentry, etc, to no avail.
***califax_ is now known as califax
<muradm>unmatched-paren_: i didn't configure emacs to do signing of commits, i don't know event if it is possible
<muradm>instead git config --local
<muradm>git config --local user.siginingkey=<....>
<muradm>then git does the job and obeys os/desktop config for prompting pin entry
<muradm>for magit it becomes transparent
<muradm>also git config --local commit.gpgsign=true
<unmatched-paren_>muradm: It's certainly possible to get it to sign commits and prompt for the GPG password (with EPG), but it seems like the method for doing so has changed a lot
<unmatched-paren_>^ this doesn't work anymore
<unmatched-paren_>(as the comments show)
<muradm>last time i made emacs asking for pinentry is with guix package --list-available=pinentry-emacs
<unmatched-paren_>that package is apparently obsolete
<muradm>it was working fine, but i switched to system level pinentry
<muradm>unmatched-paren_: yes, as far as i remember there is no warm support for pinentry from emacs at all
<unmatched-paren_>muradm: there seems to be in the builtin epa package
<unmatched-paren_>> A particularly useful mode is `loopback', which redirects all
<unmatched-paren_>> Pinentry queries to the caller, so Emacs can query passphrase
<unmatched-paren_>> through the minibuffer, instead of external Pinentry program.
<muradm>is "system" level pinentry not suitable for you? if so why?
<unmatched-paren_>I'm using sway with xwayland disabled, so pinentry-gtk2 doesn't work
<unmatched-paren_>and i don't really like it anyway
<muradm>closest to native wayland should be pinentry-bemenu if you really have to go without Xwayland
<muradm>but gnome3/qt should work as well..
<unmatched-paren_>Oh, I didn't realize there was a pinentry-bemenu
<unmatched-paren_>And pinentry-gnome3 too...
<nckx>Imma jot that down in case I ever become sufficiently hard-core to live without Xwayland.
<nckx>I would not have marked something named ‘pinentry-bemenu’ as being ‘the Wayland pinentry’.
<nckx>The description falls (and is) extremely short.
<unmatched-paren_>I just realized that I didn't use any X applications and turned it off -.o.-
<unmatched-paren_>Except for pinentry-gtk-2, which I replaced with pinentry-ncurses shortly after.
<unmatched-paren_>But obviously that doesn't work with GUI emacs.
<nckx>Off-topic, but: is there a less ‘clever’/more ‘sane’ way of determining Xwaylandness than running xeyes?
<nckx>…which works fine, but I feel like I'm missing the obvious correct way.
<nckx>unmatched-paren_: But HexChat :-/
<nckx>Fine I'll run it in a VM.
<nckx>I think that's my only single X holdout.
<unmatched-paren_>Why not $EMACS_IRC_CLIENT?
<unmatched-paren_>erc or rcirc or ...
<nckx>I tried both and one or both took minutes to connect, and the other one had another fatal (to me) flaw that I can't remember.
*nckx has a lot of buffers.
<muradm>nckx: echo $DISPLAY?
<nckx>Not sure I follow. Isn't that set for everyone?
<nckx>It's set in foot.
<muradm>for offtopic question on Xwaylandness )
<nckx>(Foot does not support X.)
<nckx>I mean that *all* processes inherit DISPLAY.
<nckx>E.g., Firefox has DISPLAY set, but Firefox is not running in X mode.
<nckx>Because multi-touch support in X mode, last I checked, and to put it delicately, sucked.
<muradm>nckx: ah, that way.. may be trying to get xprop
<nckx>That certainly sounds more ‘correct’! I'll install it and see, thanks.
<muradm>nckx: another way, if you are definetely under sway, swaymsg -t get_tree | jq '<magic-selector>'
<muradm>this way you may not need programs to install
<nckx>I might not be clever enough to write <magic-selector>. My opinion of JSON/jq is unprintable.
<nckx>But this looks promising. Thank you!
<nckx><this way you may not need programs to install> Exposed as somebody who thinks having jq installed is normal, I see :o)
<nckx>Oh this is perfect.
<nckx>Thank you very much.
<muradm>:D imho jq is coreutils candidate :D
<nckx>guix uninstall coreutils
<muradm>jq btw would be better to install than xeyes or xprops considering the dependency graph
<nckx>JSON is just XML 2.0 changed for no other reason than fashion, fine, it is what it is; but jq's query syntax just feels very unintuitive to me.
<nckx>I tend to reach for grep first unless I really can't make it work.
<unmatched-paren_>tbf JSON is way simpler than XML
<muradm>nckx: have fun :D welcome :)
<unmatched-paren_>pinentry-gnome3 seems to be complaining about <something gcr something>
<unmatched-paren_>i'll try pinentry-bemenu
<nckx>unmatched-paren_: I'm just salty that JSON exists rather than superior sexps being the standard interchange.
<nckx>There is a parallel universe where they are, and JS is a Lisp as originally intended, and I'm pissed off that I'm stuck in this one.
<unmatched-paren_>i do not see how js bears even a passing resemblance to lisp but okay :)
<nckx>I'm trying to build an interdimensional portal but the hardware all uses weird proprietary vendor Web UIs written in JS so I'll never make it out.
<nckx>unmatched-paren_: It doesn't?
<unmatched-paren_>You said 'as originally intended'.
<nckx>How you get ‘resembles’ from that I do not know.
<unmatched-paren_>Well, if it was originally intended as a Lisp, surely it'd be slightly like a Lisp.
<nckx>I don't follow. The idea was nixed quite early on.
<nckx>Java was hip, therefore it was decreed that it would be called JavaAnything and superficially resemble Java, et voila, sucky universe achieved.
<unmatched-paren_>Gah, pinentry-bemenu doesn't work either.
*nckx silently scritches out note.
<unmatched-paren_>Back to attempting to get EPG's pinentry working, I guess.
<nckx>(Not a suggestion) Did you try -gnome3?
<unmatched-paren_>> pinentry-gnome3 seems to be complaining about <something gcr something>
<unmatched-paren_>> i'll try pinentry-bemenu
<muradm>nckx: :D
<nckx>This fine.
<mrvdb>a local guix repo git clone can work as (the default) channel? would make working with WIP package changes easy. Adding the channels.scm changes is easy, but that doesn't seem to work unless I'm missing something.
<nckx>muradm: No, appreciated :) I admit I'd already written a grep equivalent but this will be more robust.
<nckx>mrvdb: Yes.
<nckx>What goes wrong?
<nckx>(A common caveat is: don't forget to commit.)
<mrvdb>testcase: use exiv2 package patched as I mentioned before
<unmatched-paren_>Ah, interesting: looks like the gpg-agent loopback support is now enabled by default. So I don't actually need to touch the gpg config to get this to work.
<unmatched-paren_> --no-allow-loopback-pinentry disallow caller to override the pinentry
<mrvdb>guix install takes the unpatched package (from default guix channel I presume)
<nckx>mrvdb: So no error at any point prior, just not the expected package?
<unmatched-paren_>(gpg-agent.conf is just a list of gpg-agent long options)
<mrvdb>nckx: correct
<mrvdb>(channel (name 'local-guix)
<mrvdb> (url "/home/mrb/dat/src/guix/.git"))
<nckx>mrvdb: First, take a look at ‘guix describe’, to see if the expected (local) URL was actually used.
<mrvdb>that's in channels.scm
<nckx>For example, here it says repository URL: file:///home/nckx/guix
<unmatched-paren_>mrvdb: I'm trying to implement a feature that would allow you to apply git patches on top of channels when you pull (though I'm stuck at implementing a necessary new feature in guile-git). Hopefully once I'm done this kind of thing will be a lot easier :)
*nckx AFK but not too long.
<mrvdb>url is there in describe, without the file:// prefix
<mrvdb>trying with the prefix now
<unmatched-paren_> but this doesn't work... hmm.
<mrvdb>unmatched-paren: the way channels easy, it just doesnt do what I expect.
<mrvdb>*the channels way of doing it*
<mrvdb>how does guix know which channel to use when it has the same packages?
<unmatched-paren_>could you show the whole channels.scm?
<unmatched-paren_>because file:// should work
<unmatched-paren_>you'll want to remove %default-channels
<unmatched-paren_>change it to (list ...)
<unmatched-paren_>also, i think you need to remove the trailing /.git
<mrvdb>why is that?
<unmatched-paren_>at the end of each path
<unmatched-paren_>mrvdb: because that contains the old guix channel. (When you're done with your local version you can replace it with %default-guix-channel.)
<mrvdb>yeah, that's the idea, no? have both. or is that not supported? than my question is moot
<unmatched-paren_>you should only have one, i thin
<unmatched-paren_>because the local one contains the entire default channel + your modifications.
<mrvdb>true, bit academic in this example indeed.
<nckx>I think calling it 'guix rather than 'local-guix would throw an error (untested).
<mrvdb>it does
<nckx>Now they are simply two unrelated channels as far as Guix is concerned, and in reality… they are.
<nckx>Guix will always use the 'guix channel to provide Guix, so there's no ambiguity, but it means you have to provide exactly one 'guix channel, and here you were doing so by accident.
<nckx>I don't know if this is documented & don't have time to check, but maybe it should be, if very briefly.
<mrvdb>but intended, i expected either to specify the channel on install or some logic to autoselect a leaf commit or something
<nckx>I see.
<nckx>I don't think the limited ‘guix install’ classic PM emulation layer lets you specify channels.
<mrvdb>so, override 'guix' as channel is really the only option if i understand correctly
<mrvdb>that is, if I want to work directly with the git repo
<nckx>Order might matter in that case, I don't honestly know. E.g. (append %default-channels (list my custom stuff)). Icky, but it would be more sane than magically preferring 'guix at all times. Try it & see.
<nckx>I've never had overlapping channels but it's a valid use case.
<mrvdb>allright, enough permuations too keep me busy for a bit. thanks
<mrvdb>permutations even
*nckx is now thinking ‘but wait, what about having two channels that both provide (guix …) namespaces, isn't the Scheme interface even worse than the CLI?’ and doesn't know that, either.
<nckx>Thank you for valiantly exploring edge cases and reporting back o7
<silicius[m]>anyone knows when wil (roughly) core updates be integrated into master?
<apteryx>it's really inefficient to have to download the debug outputs for grafting...
<trevdev>Hey Guix! If someone had multiple source repositories to build a thing, could they be declared in the (source) form, or is it better to just clone it in the build step?
<apteryx>trevdev: typically what is done is that each component is packaged separately, and unbundled from the final software integrating them
<trevdev>I had a feeling that might be the case. Simply trying to clone additional sources during build is throwing a 128 exit status. I'm guessing for some reason git can't just go out to the Internet and grab something
<apteryx>there's no internet connectivity in the build container, by design
***panosalevro is now known as panos
<podiki[m]>but you can do a recursive git clone in source (though as said, we try to unbundle, but I've seen where you have modified versions needed, or not something that can be built separately)
<trevdev>What I need is technically a dependency, so I guess...a package it is
<mitchell`>I am trying to build a arm-none-eabi gcc compiler but it keeps failing trying to load "libisl" even though isl is listed as a native dependency. Is there something I'm missing?
<unmatched-paren_>if it's a library it should be a normal dependency
<mitchell`>It looks to be a library only used at build time though. The other gcc packages i modeled this one after have it as a native dependency (gcc-arm-none-eabi-7-2018-q2-update)
<mitchell`>`cross-gcc` also returns it as a native-dependency
<trevdev>podiki[m]: In my situation I have a recursive dependency in my source code that is not a submodule, so I'm kinda boned if I can't just clone it in one build package.
<trevdev>Aside from maybe imposing my opinion of how the repository should be set up to the upstream author, which is not something I feel like doing or waiting for
<podiki[m]>not sure what you mean exactly, but I usually opt for getting something building and working first, and then sorting out details of packaging
<acrow>Has anyone installed guix on a debian freedombox?
<trevdev>podiki[m]: In package A: We need to clone package B. In package B - we need package A to build package B. Neither are submodules of the other
<trevdev>This is a trivial problem if I can simply git clone during build
<trevdev>Is it possible to create a package that is just the source code required to build another package?
<vagrantc>acrow: i can't imagine there would be anything that would conflict
<vagrantc>acrow: freedombox is just a selection of installed debian packages
<podiki[m]>yes, there is package-source to use the source from a package, or you can have packages that are just source (no build) as well
<podiki[m]>trevdev: sounds like you have a (slight) circular dependency to break in terms of packaging, but there are examples of that (grep for "circular" in the guix packages, I think)
<podiki[m]>but yes, you can do what you need, in some way :)
<acrow>vagrantc: So, freedombox is really just debian?
<jackhill>are multiple URLs allowed in a source record?
<trevdev>I may have jump to a conclusion over whether or not this is a real problem here.
<trevdev>But Iwill remember that circular thing for later
<podiki[m]>trevdev: good luck! there are examples for sure of such things already in the packages, don't have one off the top of my head but you'll find some
<nckx>jackhill: Yes, but it means that these are different URLs for the exact same file.
<nckx>(The name of the record is origin, not source — if you mean whether the source field takes a list: no.)
<vagrantc>acrow: far as i know
<jackhill>nckx: yeah, I guess I did, thanks
<jackhill>Have I seen an origin record enbeded directly in an imput?
<nckx>Nope, you'll need to add additional origins as inputs then, jackhill.
<nckx>jackhill: I don't know :) But you could have!
<jackhill>my skills for searching for things that span multiple-lines in scheme is lacking. I bet the toolking to do so exists in some form though
<nckx>I guess they are technically native-inputs, although I don't want to think about the kind of weird use cases that could make that relevant.
<podiki[m]>I believe I've seen an input that had origin embedded, but can't find it either :(
<jackhill>aha! The libigl package is an example of it
<jackhill>trevdev: ☝ libigl may be an interesting example to look at
<nckx>They aren't that rare. It used to be easier, when you could grep for ",(origin" (which still turns up a shit-tonne of results), but the new style makes it less greppable.
<jackhill>looks like libigl is still using the old style, although what I ended up searching for was "test-data" because I figured test-data would be a good use case for this … scheme
<nckx>I think the most common use case I've personally addressed is man pages being shipped separately (for example, Debian writes man pages for upstreams which lack them — a very nice service to the community).
<jackhill>indeed, yay Debian
<podiki[m]>question: new language should get new module? i have patches for the haxe language, which is built on top of ocaml but is its own thing
<podiki[m]>besides some ocaml packages needed to build, would just be the compiler/package manager, and two vms, so not a lot of packages for a new module, but makes sense to separate?
<mrvdb>nckx: order of channels makes no difference at all, guix always is preferred, local urls file:// or not both work, .git at end of url makes no difference. So, only override is useful with local git guix repo.
<nckx>podiki[m]: Probably does, yes. Circular dependencies seem very unlikely?
<shcv[m]>is there a way to `guix pull` only a specific channel? or maybe just a better way to use `guix shell` with a local channel I've made for development, and have to update regularly?
<podiki[m]>nckx: right. I'm not sure how many more packages would go in (gnu packages haxe), maybe there will be some related tools or something. but yeah, should be one way ocaml deps for haxe
<vivien>shcv[m], you would use guix time-machine -C channels.scm -- shell …, and in channels.scm you would specify the exact commits for each channel
<vivien>See the Channels section of the manual :
<nckx>podiki[m]: The <new-cool-lang>{,-xyz,-…}.scm pattern is just one. There's nothing wrong with putting ‘toolchain’ stuff in haxe.scm and everything else written in it in <relevant-field>.scm — which I actually prefer.
<nckx>But it's an implementation detail and the main factor should be (future) packaging convenience, so do whatever makes the saner graph.
<podiki[m]>nckx: right, I think for what I have now it is just (general) ocaml packages that were needed and then a few claarly haxe tools. I'm not sure if the future holds a "haxe-build-system" to take over for the haxe package manager, since I find it works without modification on Guix so far
<podiki[m]>especially neat since it compiles to other languages and seems to work on Guix, even js
<podiki[m]>as well as their vm target, which I was surprised it didn't need fiddling
<nckx>What does vm mean in Haxe?
<jackhill>yes, thanks podiki[m] for working on Haxe, looks very neat
<podiki[m]>welcome! I was just looking for some game libraries and found heaps (built in haxe), so of course I got more interested in guix packaging than making a game :)
***samplet` is now known as samplet
<podiki[m]>nckx: "vm" seems to mean generating code that is run with the "haxe vm" rather than directly js or python. in practice I saw it used for sdl/opengl (or I suppose directx, which I couldn't test)
<nckx>IC, thanks.
<podiki[m]>the packaging was surprisingly straightforward
<podiki[m]>leaving a good first impression of the language to me, nice tooling that works easily on guix is a big + to me
<nckx>Assuming it doesn't ‘just work’ because it bundles the world, that's very nice indeed.
<podiki[m]>I looked at the js output for the "hello world" and it is readable regular code too, though very long for a simple thing
<podiki[m]>I can't say I know what is behind the scenes of the haxe package manager, but everything I tried with it did work, it'll download the haxe libraries you ask, compile to js, python, etc.; and then run
<podiki[m]>the fact that a graphical sdl/opengl program will just compile and run on guix without anything extra...I'll have to see what it does exactly but a nice test for portability for sure
<PotentialUser-21>Hello. I have a problem with guix pull. Somehow my signing key is only valid for the initial channel-introduction. If I change something and push the channel the next guix pull gives me an error about not signed by authorized key. But the commit is signed
<PotentialUser-21>If I change the channel introduction commit to the last one in my channel.scm it works until the next change. Strange
<podiki[m]>I'll have to see if haxe is bundling somewhere, but other than putting the compiler and package manager together (maybe could separate?), I don't see anything obvious
<nckx>I didn't mean to imply it was. Just that it's an unfortunately popular approach to ‘just works!’ nowadays.
<nckx>I say nowadays, I have no idea if it's increasing or not.
<nckx>Shipping 1.2 GiB ‘executables’ has become less impossible, though.
<podiki[m]>I'm totally with you, which is why I'm surprised and suspicious
<podiki[m]>the instructions on one of their VMs even says: you should install dependencies with your package manager (except Windows)....sanity for packagers??? vas is das
<podiki[m]>and actually lists the dependencies
<nckx>*celestial music plays*
<unmatched-paren_>"one of" their VMs? why multiple VMs?
<podiki[m]>they moved to a new one it seems, but old one still works
<trevdev>It looks like my trivial build is unable to find my linux headers. I've included the linux-libre-headers as a native-input. I'm sure there's more that needs to be done, but I can't wrap my head around what that is
<trevdev> 38 | #include <linux/limits.h>
<trevdev> | ^~~~~~~~~~~~~~~~
<podiki[m]>they even list the cmake options in an easy way to understand in the is too nice to me, i'm used to digging through cmake files
<nckx>I recommend not using the trivial-build-system if that's what you're doing, trevdev. It is more pain than it's worth for any but the most trivial (or I-need-total-and-absolute-control-over-everything) builds.
<nckx>If you're not using the t-b-s: odd, that file should be found in the default build environment.
<trevdev>I agree, the trivial-build-system feels like a lot. The package I'm trying to build is already pretty hacky by design. It sorta fits into the gnu-build-system, but definitely does not, and it uses a bunch of shell scripts and git cloning to piece things together.
<trevdev>I'm trying to learn how the guix build/gexp stuff works, I feel like this is the way to go despite it not being "trivial"
<nckx>I'd still recommend starting from the g-b-s and removing/adding phases to it, to be honest.
<nckx>But sure, legit reason.
<nckx>It seems like C_INCLUDE_PATH isn't being set in the environment; if you pass --keep-failed to the build you can inspect the environment-variables file in the printed directory.
*nckx → foodz.
<antipode>trevdev: With some rare exceptions, sounds like a non-native input to me
<jackhill>trevdev: out of curiousity, what package are you working on anyway?
<PotentialUser-21>Uuh. Sorry about the noise. I forgot the .guix-authorizations file while copying data from one channel to another.
<trevdev>The current hacked-around package does not manage to include any of the other binaries that make a complete nim-toolkit
<trevdev>And the build process is this combination of shell scripts and .nim files that are intertwined just-so
<trevdev>Hard to follow what's supposed to happen where, or when
<antipode>trevdev: Normally, the linux headers are propagated by the glibc package.
<antipode>Additionally, trivial-build-system does not have any implicit inputs (looking at guix/build-system/trivial.scm).
<antipode>Is your package finding glibc?
<trevdev>I imagine it should be...
<antipode>To be clear, I meant that IIUC, the trivial-build-system does _not_ automatically give you a glibc.
<trevdev>IIUC: International Islamic University Chittagong?
<antipode>trevdev: I recommend, pastebin is full of cookies and 'consent' forms and in all likelyhood trackers.
<antipode>IIUC: if I understand correctly
<trevdev>antipode: Thanks, bookmarked
<antipode>(also: IIRC: If I recall correctly)
<trevdev[m]>I'm guessing that's not a part of the gcc-toolchain then
<antipode>IIRC and IIUC, gcc-toolchain has some code for always finding glibc, but I don't know if that covers the linux headers too
<iiioxoiii>Hi guys!
<cdo256>quick question: fresh install is freezing on initrd. nothing in /log. Where could I look?
<iiioxoiii>One question. Do you know if is possible install Oracle Virtual Box in Guix?
<unmatched-paren_>iiioxoiii: Virtual Box uses a boot firmware with freeness problems
<unmatched-paren_>the firmware itself is free, but it requires a nonfree compiler
<unmatched-paren_>use QEMU instead :)
<unmatched-paren_>with GNOME Boxes if you want a friendly UI
<iiioxoiii>thanks a lot!!!
<mrvdb>nckx: Correction: did some more testing, order *does* matter. channels are evaluated in order, so last channel with same "key" has the package. (first test was looking at the wrong branch). So, ideal actually. Start with %default-channels in list and append whatever mess I'm willing to add to it for myself.
***Dynom_ is now known as Guest7627
<ft> → 502 bad gateway, for a while now. Known issue?
<unmatched-paren_>ft: yeah
<acrow>vagrantc: copyrighter has been tweaked in a couple ways but I'm still pondering larger changes.
<florhizome[m]>cdo256 logging is under /var/log/Messages and on tty12
<ft>unmatched-paren_: Thanks. I suppose this is not something I should hold my breath for?
<nckx>There's no logging in the initrd though.
<nckx>ft: It's ill-advised.
<unmatched-paren_>i think there are currently some issues with the servers
*ft nods
***mark_ is now known as mjw
<nckx>There's nothing wrong with them, there's just a cable that needs to be run, but for that we need to wait.
<nckx>That should make the set-up a bit less fragile.
<nckx>That's not true: there *is* something wrong with them but it would be easy to fix *if* we had the magical management cable.
<nckx>That's the real issue.
***unmatched-paren is now known as Guest569
***unmatched-paren_ is now known as unmatched-paren
<shcv[m]>is emacs with native-comp part of guix yet?
<abhicherath[m]>Hello, I'm still a bit confused regarding how to apply a patch to a running instance of guix vm
<abhicherath[m]>so what I did was clone the guix patches git repo, checked out the go-1.18 patch, then followed the install from git instructions
<abhicherath[m]>ie. guix environment guix, ./bootstrap, ./configure, make
<abhicherath[m]>then sudo make install
<abhicherath[m]>now I expected guix install go to give me go-1.18, but it doesn't
<dominicm>It looks like guix shell doesn't set $CMAKE_PREFIX_PATH; do you just have to append $GUIX_ENVIRONMENT to the prefix path manually, or is there a way to do it automatically like it does with $PATH?
<abhicherath[m]>what am I missing?
<unmatched-paren>abhicherath[m]: i think you should use your local checkout as a channel, not by `make install`ing it
<unmatched-paren>(channel (name 'guix) (branch "master") (url "file://...")) i think
<abhicherath[m]>that makes sense
<abhicherath[m]>so making a new package doesn't require building guix from source every time
<shcv[m]>I set commits in my channels.scm to avoid updating them, but `guix time-machine` still says "updating <channel>"... Is it ignoring the commit in my channels.scm? or does it "update" first and then use the specified commit? Or does "updating" just involve checking the channel and it stops when it notices the commit ID matches what I already have downloaded?
*nckx sorry.
<unmatched-paren>shcv[m]: if it doesn't say 'X new commits' then it isn't updating
<unmatched-paren>abhicherath[m]: though guix pull needs you to commit your changes for it to pick up on them
<nckx>dominicm: You sure? It's set here:
<nckx>Make sure your shell initialisation files don't clobber it.
<dominicm>nckx: Ohhh I see, I was just doing 'guix shell <my-library>', but it sets the path based on the location of cmake itself, so I need to do 'guix shell cmake <my-library>'
<nckx>shcv[m]: You're not the first. If only we could have a bot run ‘sl’, but I fear it'd get kicked for spam (and be truly rightly hated).
<nckx>dominicm: Ah, yep!
<nckx>Variables are pulled in by consumers.
<nckx>I assume you need cmake to build the library, but it should be pulled into the environment and not ‘inherited’ from your user/system profile, because environment variables (search-paths, in Guix parlance) are only applied within a profile, not across layered ones.
<dominicm>nckx: That makes more sense; thanks!
<shcv[m]>nckx: hmm. I can't find that bot when I search for it. What does it do?
<nckx>It's not a bot. (1) guix shell sl -- sl (2) enjoy the show (3) do not profit in any way.
<shcv[m]>I see
*nckx sorry, again.
<jab>I just came accross this:
<jab>that would be pretty cool to package via guix
<antipode>unmatched-paren_: Do you known what compiler was that?
<antipode>I remember something about the compiler being non-free, but at the same time there was some communication with the copyright holder on relicensing it.
<antipode>Was it this one: ?
<nckx>antipode: OpenWatcom.
<nckx>There was discussion but it stalled.
<nckx>antipode: That's the one.
<nckx>I'm very glad to see replies trickling in.
<nckx> sigh.
<nckx>You found the one company that is actually making real progress, if slowly, towards what you want so why not pester them to make them regret it.
<yewscion>Hello all, I'm having an interesting issue on my Librem 14 running GNU Guix. If I walk out of the range of an AP I am connected to, the Qualcomm Atheros QCNFA222 card will eventually stop working entirely. In fact, I've just discovered it will *also* not accept an ethernet connection. How does one restart the networking service, and does anyone have an idea why this might be happening?
<antipode>yewscion: What do you mean with 'stop working entirely'?
<antipode>I mean, it's not surprising that if you go out of range, you don't get the wifi (WiFi?).
<antipode>E.g., can you still create WiFi hotspots and scan the local environment for networks?
<yewscion>antipode: I mean, it is basically as though the card is not present in the system. It will not reconnect, will not scan, nmcli hangs for a *long* (>30s) time before showing no interfaces and a usage message.
<antipode>As some generic advice, "sudo dmesg" might have useful information (e.g. I used it to notice a certificate problem when connecting to a network).
<antipode>Possible the network manager also have logs, though I wouldn't know where.
<yewscion>sudo dmesg also hangs, apparently, and will not respond to ^C.
<mitchell`>that is an interesting symptom
<antipode>Maybe open /var/log/messages instead.
<antipode>A copy of dmesg things (and other things) is put there.
<antipode>Or was it /var/log/debug or /var/log/secure, or all of them, ...?
<abhicherath[m]>ok, now im even more confused. I added as a channel with my branch of interest (series-12228)'
<abhicherath[m]>and ran guix pull
<nckx>yewscion: Can you cat /dev/kmsg ?
<nckx>(This is privileged.)
<abhicherath[m]>and that errors out saying its not a descendent
<yewscion>antipode: nckx: Trying Your suggestions, excuse the lag while I wait for responses.
<Maya[m]1>i have been digging around pam and I must say, guix solves it kind of weird, and there’s a lot missing
<unmatched-paren>abhicherath[m]: that means the commit that repo is based on is older than the commit you currently have pulled
<nckx>No problem yewscion. My second suggestion, if not, would be to reboot, run dmesg --follow and actually walk out of range again if possible.
<abhicherath[m]>so i tried just copying the golang.scm file and running guix package --install-from-file and that errors out with cannot install from non-package object
<yewscion>No sudo command will work, trying su - instead.
<abhicherath[m]>unmatched-paren: I figured, but I'm not sure what to do about that exactly
<nckx>abhicherath[m]: guix anything -f expect the file to return a package, so it must end in (say) a variable name.
<unmatched-paren>abhicherath[m]: either rebase the patches on a newer guix and use that, or provide --allow-downgrades to guix pull
<nckx>yewscion: This all sounds like the driver took down your kernel.
<nckx>Or at least that execution is hanging there.
<abhicherath[m]>nckx: i see
<nckx>Add the (variable) of the package you want to build as the last line and it should work.
<nckx>*(variable) name 😒
<nckx>Do not actually write any ().
<yewscion>nckx: Interesting. I'd like to confirm that, and take steps to avoid it from happening again. I have a 30 minute commute 2x/day, and have needed to reboot each time to work around this.
<yewscion>Working on exporting dmesg to a paste, will add link when finished sneakernetting between laptops.
<nckx>I've been there (with an iwlwifi card, so not even libre, so was a double relief to finally replace it).
<nckx>It didn't take down my kernel but did require a reboot to reconnect.
<abhicherath[m]>that works for now, but would it be possible for me to specify that only certain packages be acquired from a channel?
<yewscion>If this is the case, I will order a new card today, for sure.
<nckx>Well, I would expect Purism to have extensively tested this card with ‘Linux’ and not needlessly ship firmware.
<nckx>So unless you got a bad card, I wonder what's really going on.
<nckx>Did you (previously or now) try other distros on this machine in the same situation?
<nckx>Ideally linux-libre ones.
<yewscion>I did not. It came preinstalled with PureOS, but I wiped it the day I got it for GNU/Guix.
<abhicherath[m]>I see so I can maintain my own channel repo
<abhicherath[m]>ok I will do that, that actually comes in handy for a couple other things too
<abhicherath[m]>thank you so much for your help unmatched-paren nckx
<unmatched-paren>abhicherath[m]: you can use a local file
<unmatched-paren>so you don't need to upload it
<nckx>abhicherath[m] :) That's why we're here.
<yewscion> Here is the output from dmesg with the system in the Bad State.
*nckx is expecting a backtrace; let's click.
<nckx>Oh boy.
<nckx>So yeah, execution is hung in kernel space starting at line 863, so stuff will start to hang (hence no starting sudo, dmesg, …) and eventually your system won't meaningfully respond.
<nckx>This is broadly very similar to what I had, but I'm surprised. That was a crappy Intel card requiring iffy firmware (the errors would start there), yours is an ath9k that should be as stable/well-supported as it gets on Linux, barring short-lived regressions.
<nckx>On the chance that the ‘hwrng’ lines aren't a red herring, and you're willing to put some (human & CPU) time into building a custom kernel, you *could* try setting CONFIG_ATH9K_HWRNG=n and hoping the problem just goes away.
<nckx>No ROI guarantees :)
<nckx>There is a conspicious lot of talk about hwrng in that log, though, so it seems plausible.
<yewscion>nckx: It's more of a lead than I had before, I'll give it a shot.
<yewscion>Is there a guide to doing a custom kernel on Guix somewhere? As I recall from Slackware, usually there is a stateful menu and then a long build process involved, but I'm unfamiliar with how to do so on GNU/Guix.
<abhicherath[m]><unmatched-paren> "so you don't need to upload it" <- hm, so one more question. is it better to have a patched guix repo or to have my own channel with packages for certain things? how long does it take for patches to be merged generally? Cause I don't really want to have to deal with the hassle of rebasing if I don't have to...
<unmatched-paren>abhicherath[m]: Probably your own channel
<nckx>yewscion: I'll wait and hope someone else answers that; I don't use Guix's linux packages at all and am not up-to-date on the best way to configure it. But roughly: no, no menu would be involved, you'd write a bit of code including '("CONFIG_ATH9K_HWRNG=n") somewhere and use it as the value of your operating-system's (kernel …) field.
<yewscion>Ah, okay. Thanks!
<nckx>If nobody responds I'll try to help you through it, but I'll be learning something I don't use alongside you and it will be very inefficient. :)
<mitchell`>yewscion: You should take a look at the kernels defined in gnu/packages/linux.scm. The `stateful` menu but of the linux configuration results in a .config file which is used to actually build the thing. You can skip the menu if you have a .config already
<mitchell`>you can use the menu to create the config and then put it in a repository somewhere guix can find it
<nckx>yewscion: I found this:
<yewscion>mitchell`: Ah, okay, that makes sense. Thanks!
<yewscion>nckx: Ooh, awesome, I'll read up on it.
<nckx>mitchell` isn't wrong, but ideally we'd just tell Guix ‘use the default kernel, plus this one line’. That's what the (define %default-extra-linux-options …) snippet does.
<nckx>If you create your own entire .config file, you still have to pass it to the linux-libre package, and it won't save you much work I fear.
<nckx>And possibly more risky.
<mitchell`>this is true
<yewscion>Copy that, will try to add just that option first. Would rather keep as much in scheme as is possible.
<nckx>By the way, my example above would be ("CONFIG_ATH9K_HWRNG" #
<nckx>* ("CONFIG_ATH9K_HWRNG" . #f)
<nckx>Mmm, Schemey.
<shcv[m]>any reason the guix home zsh services don't support aliases like the other shell configuration services?
*nckx hmms.
<mitchell`>shcv[m]: lazy implementors?
<nckx>yewscion, mitchell`: I'm going to backtrack a bit because I just read that cookbook article and… unless you disagree, I find it very confusing unless you already know more than the article explains. There is a way to do just what we want, but IMO that cookbook article just ain't it. And it would take me too long to write a debugged version that does. So yes, let's follow mitchell`s method (partially; no pretty menus I'm afraid) and use a complete .config file
<nckx>, if you agree?
<mitchell`>nckx: yewscion: you can also pass these parameters as make arguments
<mitchell`>i think*
<yewscion>nckx: It seems like overkill a bit, but I think I've just about gotten it. That said, I'd like to know how to do it the other way too, in case of a future use-case where I need to fall back to a .config.
<nckx>mitchell`: But does (make-)linux-libre use #:make-flags? That's my problem here: what's simple in Linux terms doesn't seem to jive with Guix's make-linux-libre approach.
<mitchell`>you can inherit the package that makes and add the make flags that way
<mitchell`>Granted I have not tested this
<nckx>But are they used?
<podiki[m]>only caught the end of this kernel customization discussion, but if anyone wants an example you can see mine: (please ignore the following section, shield your free eyes)
<nckx>In general: absolutely. In linux-libre land… mines.
<podiki[m]>I had to piece together from that cookbook and other discussions, but this was the simplest I ended up with
<nckx>yewscion: Oh, OK, if you're close to a working kernel I'll shut up. I just found too many potential confusions (e.g., you have to ‘know’ that stuff like %file-systems is purely made up — which a new user won't. I have no idea what you are :)
<nckx>podiki[m]: Oh this is so much better, thank you.
<nckx>Now this I can unreservedly recommend for glorious cargo-culting.
<podiki[m]>in the comments I link the source, one is on that non-free channel, sorry (as is my config kernel)
<yewscion>podiki[m]: Thank You for sharing, this will help immensely.
<antipode>Maya[m]1: Did you have any weirdness or missing stuf in particular in mind?
<podiki[m]>we have the tools to make this easy, just seems like between an older blog entry and the cookbook it never solidified on an easy way
<antipode>'guix solves it kind of weird' and 'there's a lot missing' is not enough to work with for an answer.
<podiki[m]>that is documented
<antipode>(TBC, I don't really know PAM myself)
<nckx>Sorry if my disappointment in the cookbook came out a bit too strongly-worded above. It's not bad and clearly took effort, it's just not what I'd expect from a cookbook article. I want to be able to throw those at anyone without having to write 5 disclaimers after it.
<Maya[m]1>antipode: yes, I tried to get fprintd working but there are missing many pam.d files and guix uses non-standard structure to all of this, instead of a tree it just puts everything flat into files, no includes
<Maya[m]1>and there’s no way to preserve order between entries which are significant in pam sadly
<mitchell`>I actually have funding from my lab to explore using guix to make compliance with random government decree's easier to validate on embedded hardware. I will probably end up writting something that can be donated to the cookbook
<podiki[m]>nckx: agreed, I also found it confusing. it is like most of what you need but doesn't show the simplest example, but does give you the tools mostly
<yewscion>Good documentation is an always-evolving finish-line we can never reach, but one which we must strive for endlessly.
<nckx>I'm always pleasantly surprised to hear that someone convinced Serious Institution (humour me) to spend real money to investigate this silly Guix thing.
<nckx>podiki[m]: Right!
<yewscion>At least GNU/Guix has an amazing community to supplement its awesome docs.
<podiki[m]>I think the cookbook should prioritize an example of "here's how you add/change a config option" since that is mostly what someone wants I would guess. then if you want to redo the configuration, use a full custom one, etc. here is how you build up the kernel package
<nckx>I also understand that the cookbook article was written with ‘this unexported non-API can completely change under me at any minute’ in the back of the author's head.
<nckx>That's not motivating to eke out the perfect text for the ages.
<yewscion>nckx: podiki[m]: mitchell`: It is building now, on my secondary machine. Upon success I'll update my channel and reboot the other comp, then I'll move to the newly built kernel there.
<yewscion>Thank You all for Your assistance!
<podiki[m]>hope it gets you all sorted!
<nckx>I want to ask ‘move how’ but I'll save it for later. May all your builds succeed, comrade.
*nckx AFK.
<vagrantc>acrow: great, let me know if you want me to take a look at it
<shcv[m]>it looks like the python-pytest package hasn't been updated in a while - it's on 6.2.5, latest is 7.1.2
<shcv[m]>and I kinda want a 7.0 feature that adds support for a pythonpath config in the pytest.ini
<trevdev[m]> If you have a custom channel, and you want to test an update to a package, how would you go about doing that? I have the local repository, would be nice if I didn't have to commit/revert or even guix pull
<shcv[m]>trevdev: I was trying to figure that out earlier today
<shcv[m]>the recommendation I was given (though am not fully satisfied with yet) is to have a channels.scm pinning most of your channels, and then use `guix time-machine -- shell ...`
<shcv[m]>oh wait, that's if you want to use the installed package
<trevdev[m]>My setup is extra mucky as I use guix home for the majority of my packages haha.
<shcv[m]>if you just want to test the package definition, use `guix build -K -L . package-name
<shcv[m]>(-K for keeping the build directory if something goes wrong)
<shcv[m]>it would be nice if it was slightly easier to submit package definitions, since actually defining packages themselves is so easy
<trevdev[m]>That worked well
<trevdev[m]>So I did `guix build -K -L package-name`, then from that same directory did `guix shell package-name -L .`
<podiki[m]>if you don't need other things in your channel, you can also use -f filename.scm for most things like build or shell
<podiki[m]>(when you don't need the -L loadpath)
<podiki[m]>or rather if you already have what you need from guix pull
<nckx>shcv[m]: If you submit an update to python-pytest it will be (gladly!) accepted but note that it will land on the core-updates branch, not hit master immediately, and may or may not make it into the next c-u → master merge.
<shcv[m]>sure, but the process for submitting updates is intimidating, so I haven't done it
<nckx>You could also add a separate python-pytest-7 package that wouldn't have this problem, since few packages would have it as input at the start.
<shcv[m]>would be nice to have a simple web form you could paste package definitions either anonymously, or with a "check here to relinquish copyright" option
<shcv[m]>otherwise I have to figure out the mailing list, patch formatting, and possibly copyright assignment before I submit anything
<nckx>Relinquishing copyright is hard and probably impossible. Certainly not something we could do. But that's not a requirement, it could just have an author field.
<nckx>There is no copyright assignment.
<shcv[m]>an interesting legal question: if the source is published anonymously, who holds the copyrights? especially in jurisdictions that don't really recognize public domain
<nckx>It's not a workflow I'd recommend, but you could: git format-patch -1 (or any number off the tip), attach patch(es) to mail, send to guix-patches@.
<nckx>shcv[m]: Oh, sure, lots of interesting questions and answers :) I just meant that Guix as a project should probably not do any ‘interesting’ things in that particular area…
<nckx>Let's keep that confined to code.
<nckx>I'm not wild about the pseudonymous copyright headers we already have but there's no way to enforce real legal names anyway, without asking Mr. Mickey D. Mouse for a scan of their ID.
<shcv[m]>so which do you think is better? python-pytest-7 or updating python-pytest itself?
<nckx>That just depends on whether you want it to be immediately available on master.
<nckx>If a separate -7 is added, we'll still need a separate c-u patch to actually update the main package and remove -7 again.
<nckx>That's a bit more work, but worth it if 7 offers real features folks want to use today™.
<shcv[m]>what's the best way to have local versions of packages for while I'm waiting for master to catch up?
<nckx>If you mean local versions to ‘guix install’, the strictly easiest route would be to ‘guix install -f ~/junk/my-python-pytest.scm’.
<nckx>Not implying your code is junk, just that it's a random file that lives entirely outside of Guix/channels/the like.
<nckx>If you want to write Guix packages that use it, probably a channel.
<nckx>Bit of start-up overhead though.
<nckx>(Setting up GPG keys, etc.)
<shcv[m]>are there complications from using a local clone of guix as a channel, since it would have lots of duplicate declarations?
<nckx>Hah, let me pluck the backlog.
<nckx>26 Jul 18:57:06<mrvdb> nckx: Correction: did some more testing, order *does* matter. channels are evaluated in order, so last channel with same "key" has the package. (first test was looking at the wrong branch). So, ideal actually. Start with %default-channels in list and append whatever mess I'm willing to add to it for myself.
<nckx>Complications: nothing preventing it from working, but I'm not sure if you'd be inundated with duplicate package name warnings or not.
<shcv[m]>huh, ok; worth a try then
<nckx>And you'd still have to do the GPG stuff.
<nckx>I don't really see any advantage to starting from a full Guix copy, but hey, freedom.
<nckx>Good luck :)
*nckx away again.
<shcv[m]>I've already set up one channel though, so I think I can just copy the authorization stuff
<shcv[m]>well, the advantage would be that I can use the package I'm working on and planning to eventually share as a patch
<shcv[m]>instead of duplicating it to a personal channel
<maximaximal>Hi! I'm currently trying to install Guix with the Systemcrafters image that already includes Non-Libre Linux (sadly, Linux Libre doesn't work on that new machine). I'm trying full disk encryption (the option in the installer) with BTRFS with enabled zstd compression (custom option) as root. During install I encounter one of these errors though:
<maximaximal>Either the "is somewhat slow" and the installer aborts after a failed download, or the installer just stops at some point and freezes. I didn't get any useful logs yet, the files are all empty. But the partitions are created correctly and one can browse some of the created files.
<maximaximal>Do you know where I could look to maybe get native GuixSD on the machine working?
<shcv[m]>nckx: what's the 'primary' fingerprint comment for in the guix authorizations?
<shcv[m]>maximaximal: you could try an image-based install, where you create a system image that has guix on it using a working guix (e.g., binary installed on another distro), clone it to the target device, and then extend the partitions afterward if necessary
<shcv[m]>not sure if that would work for your encrypted file system though
<shcv[m]>you could also try the shell installation process and see if it gives you more useful logs
<apteryx>maximaximal: perhaps the network card is flaky on that system when using free software? try an ethernet cable, if you aren't already
<maximaximal>shcv[m]: Yes, that sounds like a good approach - especially initializing from a different machine. I'm currently on my 10th try with the direct install and now trying to just select fewer software so that the chance to not have a network drop is lower
<maximaximal>apteryx: Currently on wifi, but using non-libre Linux. Had the same issue with servers being somewhat slow quite often already with guix, also on different machines - figured the CI service was a bit under the weather right now
<shcv[m]>an intermediate method would be to do `guix system init --no-bootloader` from a working system, and then manually boot later. I haven't quite figured out the best way to do that though
<shcv[m]>the 'chroot into an existing installation' instructions don't work, because a lot of stuff doesn't exist until the first boot has happened
<shcv[m]>I guess you could install it with the bootloader, but it will probably mess up the efi configs on the system you init it from
<maximaximal>It seems your presence fixed the connection - now the reduced install size completed successfully! I forgot to change the kernel though and now the GPU driver is missing, but I hope I can repeat this success.
<shcv[m]>I do think it would be nice if the "build a complete guix system from an existing system" workflow were slightly improved though
<shcv[m]>instead of trying to mess with a live usb installer
<maximaximal>My ISP just seems to dislike free software if I'm the only one experiencing these slow moments
<maximaximal>Yes that would be nice. Basically just dd-ing to a new drive
<shcv[m]>the `guix system image` tools are *almost* close enough, but it doesn't support all of the options yet (pretty sure encryption and btrfs aren't supported)
<shcv[m]>would also be nice to be able to build it in place on the new drive, instead of building a small image in the store, transferring it with dd, and extending it
<shcv[m]>the image option is nice if you want to mass-produce drives with the same image I guess
<shcv[m]>but having the "bootloader but not messing with my efi configs" in `guix system init` would probably be the right way to do it
<shcv[m]>would also be nice if there was a version of `init` that would partition the device, instead of doing that manually as a prereq
<shcv[m]>kinda like the way `image` does it
<maximaximal>Oh, so you mean similar to installing it on other distros but as a whole system, just with pre-formatted drives?
<maximaximal>Pulling these steps apart would make the install experience smoother and more flexible I think, yes
<nckx>This is conceptually similar to what 'guix deploy' does, i.e. introduce a machine concept above operating-systems. It's still a WIP though, and defines 'machine' as 'a previously installed Guix System listening over SSH'. But still.
<shcv[m]>yeah, deploy could be a good place to put it too; maybe better than guix system init because the `system` commands implicitly assume a local system I think
<nckx>And it might actually make sense not to use the same record type & UI for 'virgin machines' and 'existing machines to reconfigure', I dunno.
<shcv[m]>though it also fits with init, since that's making a new system on a specified device (usually from the installer, but still)
<nckx>It's tempting to lump them together but really, now deploy has to deal with 'you changed the size of /var' and... resize partitions? And that's just the simplest transformation I can imagine.
<shcv[m]>and guix system image does make new images
<nckx>You probably said it already, but the Stuff already exists, it just needs to settle.
<nckx>This is worth getting right.
<podiki[m]>"distributed under the terms of the GNU Library General
<podiki[m]>Public License, with the special exception on linking described below. (This is the OCaml library licence.)"
<podiki[m]>^? lgpl2.1 like other ocaml libraries?
<podiki[m]>from ocaml.scm I see lots of "with ocaml linking exception" and lgpl2.1, but I'm guessing here
<podiki[m]>I guess more lgpl2.0 (when it was called "library" rather than "lesser")
<nckx>Whoah, opam doesn't mandate a licence field? (Is this xml-light?)
<nckx>podiki[m]: ☝
<podiki[m]>this is xml-light, good catch
<nckx>Oh good, then the answer's easy 😉
<podiki[m]>i've found one where the metadata in the opam and then the one in the actual files was different too
<podiki[m]>ah nice, typical ocaml it seems then lgpl2.1+ with linking excpetion
<podiki[m]>(readme was not up to date, forgot to check the source)
<podiki[m]>as you might guess, doing that polishing on the haxe patches
<podiki[m]>i also slightly de-bundled the package manger from compiler, at least in terms of source (but compiler and package manager still built together in one package)
<orneb>Hi! Icecat is not showing characters and some icons after first installation. Can this be due to some env variables not configured properly? Beside adding export XDG_RUNTIME_DIR=“/tmp/swaywm” to my .bashrc I didn't do anything in particular.