IRC channel logs


back to list of logs

<spiderbit>ok added it to authorized-keys instead on the guix machine but still the same error message
<spiderbit>does somehow guix offload nead specifically a rsa key?
<lilyp>IIRC it's a gcrypt key, but there might be more than one accepted algo
<oriansj>well the guix server doing the build uses it's private key to sign its builds and the client machine adds the guix server's public key via: guix archive --authorize <
<oriansj>and then add to the guix-daemon command: --substitute-urls="" on the client machines
<oriansj>To allow your computer to serve packages to other users, simply: guix publish This will spawn an HTTP server which allows anyone with network access to obtain substitutes from it.
<oriansj>The signing key pair must be generated before guix publish is launched, using guix archive --generate-key
<lucypoo>Hey there, I use the rosenthal channel for hyprland, hyprland uses different versions of software like wlroots than that which is packaged in guix. In general are people ok with accepting some ( package/inherit)-s surrounding a commited package to allow building?
<lucypoo>As I imagine there will never be a point at which all software lines up
<lucypoo>I guess that may instead warrant a new definition adjacent to the inherited package, not next to the one it is made to comply with
<lilyp>package/inherit across channels – or even across modules within guix – is typically not that great of an idea
<lilyp>within the same module it's typically safe
<lilyp>also, if you're doing your own channel, you set the rules: typically, depending on a given range of guix commits (implicitly) works out just fine
<lilyp>just be aware that things might break from time to time and be ready to update
<spiderbit>oriansj: had to add private-key field in machines.scm
<spiderbit>then it started... yet after a while it failed
<spiderbit>"build ... failed" even guix pull fails
<spiderbit>sadly without a error
<lucypoo>thanks lilyp
<podiki>lucypoo: regarding hyprland, discussion on guix-devel about packaging:
<peanuts>"Packaging Hyprland"
<spiderbit>oriansj maybe it works now but most of the time my remote 8 core cpu only a few cores are at 10-20% maybe maximum seldom 45% 1-2 cores
<spiderbit>have speed at 5.
<spiderbit>do I have to change something at paralell builds but that should not help for 1 package
<spiderbit>well was to optimistic crashed again
<oriansj>well the only detail you need to tweak for parallel builds is the number of build users you create
<spiderbit>but if I only want to build the package icecat as example that takes forever changing parallel builds doesn't change anything right
<spiderbit>well I restarted it with -v5
<oriansj>well individual packages only have so much parallelism in their builds
<spiderbit>I think the build-machine has some authentification problems still even I can login as root into user / root without pw
<oriansj>well did you populate the password in your configuration using (password "yourhashgoes here") and generate that value using: mkpasswd --method=sha-512
<spiderbit>on the target machine or the build-machine
<spiderbit>the build machine is archlinux
<spiderbit>so only guix
<spiderbit>guix offload error: unauthorized public key...
<oriansj>you may wish to look at this:
<peanuts>"~oriansj/System_setup (main): files/guix-config.scm - sourcehut git"
<spiderbit>it says ed25519 which would be good
<spiderbit>I set up "user" -> XY and then this user should have access to the guix machine right and it has that
<spiderbit>for the user root and the user XY on this machine
<spiderbit>in both directions
<oriansj>you need to set a password on a server (and your clients) and you'll want to tweak your sshd configuration by adding (permit-root-login 'prohibit-password) to your (openssh-configuration section
<spiderbit>prohibit? I can login without password
<spiderbit>isn't that enough
<oriansj>spiderbit: you don't want people to be able to login into your server as root by guessing no password.
<oriansj>no people on the server be able to su to root by just hitting enter
<spiderbit>"no?" why "no"
<spiderbit>you mean I must set password to ""
<spiderbit>no that of course doesn't work
<oriansj>spiderbit: there is nothing I said that you must do
<oriansj>but general good practices suggest setting a strong password for the root user account and forbidding remote logins to it
<spiderbit>yes I am mostly behind a firewall, sure premit root login direct or something makes sense if you are in public networks but that is a different question
<lucypoo>podiki: thanks just dropped a web mail
<spiderbit>can I somehow define "private-key" on a system that has only guix as a program
<spiderbit>so different distribution
<spiderbit>ok it's the "signing-key" from my main machine
<spiderbit>muss ncohmal frisch generieren
<spiderbit>ups sorry for my german slip :D
<spiderbit>have to generate the key again
<spiderbit>do I have to use user "root" when my normal user I use for the machines needs a password for sudo
<spiderbit>I just did the authorize command with sudo again on the other machine now the build peaks moch more often over 40 50% even reached 100% of one core for a second... it looks different now maybe that fixed it somehow
<Gooberpatrol66>How do you get useful backtraces in guix? The top level error is always "In unkown file" and there is no line number
<spiderbit>ohh I think I found another Problem that is related strongly or causal
<spiderbit>I started from both machines being called the same name for some reason and tried to rename one but aparently the renamed one still refers to localhost if I ping the other machine
<spiderbit>just rebootet
<spiderbit>ohh the hosts file is the prob
<spiderbit>now the next strange behavior the build doesn't crash but it creates nearly 0 load on the build machine for 10 minutes or so...
<spiderbit>it send total I think since reboot in gnome-systemmonitor of 340kb and uploda 700kb
<spiderbit>sometimes I see guix offload process with 0.3% cpu
<spiderbit>most of the time not even that
<chsasank>hey folks, I want to contribute guix packages for SYCL compiler for Intel GPUs. However I am new to guix - is there a way to get started with building etc?
<chsasank>thankfully most of these packages are opensource
<lilyp>well, "open source" can mean anything from actually free software to non-free software where they kindly give you the source code
<lilyp>regarding sycl, you'd first have to find an actual implementation (I assume you already did that)
<lilyp>then, you define a package as outlined in section 8.2 of the manual (Defining Packages)
<lilyp>for sycl, it's likely that you'll have to use cmake-build-system among other things
<lilyp>then you check whether the package builds, debug, rinse and repeat
<lilyp>you might further want to check whether the upstream source contains unwanted stuff such as precompiled sources or binaries
<lilyp>and see how to generate them from actual sources
<hako>podiki: Don't know why but I didn't receive your mail, I just found it in the mailing list. Did you get any message from the mail server?
<ekaitz>hi! how do I pull only from one channel?
<vivien>ekaitz, if I had to do that, I would create a channels file where every channel is pinned to a specific commit except the one you want to update.
<vivien>I would try to do that at least, I don’t know if it works
<ekaitz>oh that's a good one
<ekaitz>thanks vivien looks like it's working
<graywolf>Hi. How should commit message look like when I am updating 3 packages in one commit?
<lilyp>graywolf: Not at all. You should update one package per commit.
<lilyp>If there is a hint anywhere stating otherwise, you can take the first package and say "Adjust accordingly" on the others.
<graywolf>I see. So I need to (each number is commit) 1. rename the variable foo to foo-previous, create new foo (the updated version), modify (inherit) to point to foo-previous. 2. update guile2.2-foo to point to foo again 3. update guile2.0-foo to point to foo again 4. remove the foo-previous variable
<graywolf>Is there a commonly used name suffix for the `foo-previous'?
<graywolf>lilyp: I am not sure if you saw my response above...
<lilyp>Did not, sorry
<lilyp>had to reboot
<graywolf>I see. So I need to (each number is commit) 1. rename the variable foo to foo-previous, create new foo (the updated version), modify (inherit) to point to foo-previous. 2. update guile2.2-foo to point to foo again 3. update guile2.0-foo to point to foo again 4. remove the foo-previous variable
<graywolf>Is there a commonly used name suffix for the `foo-previous'?
<graywolf>^ re-posting
<lilyp>Not sure what exactly your use-case is here, sorry.
<graywolf>I want to update guile-irregex, but guile2.2-irregex and guile2.0-irregex inherit from it. So the naive way I would be updating 3 packages in one commit.
<graywolf>According to above that is a no-no, so I am thinking how to structrute the commits
<lilyp>Uhm, no, inheritance is one of the exceptions where you are allowed to change multiple packages at once.
<lilyp>But this is just superficially "multiple packages" anyway. Just write the commit log as though it was only guile-irregex
<graywolf>Ah I see, thanks for the guidance :)
<lilyp>relogging shortly, need to debug ibus
<graywolf>How many components of "path" shall I repeat in changelog-style commit message? Shall I repeat the full path, or just the differing components? Illustrated here:
<Guest36>can i configure wlan through the system settings, so it is setup automatically after reinstalling a system, or do i always need to use networkmanager?
<Guest36>basically, want to setup wlan in my system config
<lilyp>avoid unnecessary detail
<janneke>graywolf: git keeps history for a reason, and you're allowed to look at it
<nckx>sneek: later ask reedm And does manually modprobing bcachefs work? I've never used the service you mentioned, but have the module automatically added to my initrd because it's my rootfs.
<sneek>Will do.
<nckx>janneke: Would you mind a PM that has nothing to do with Guix?
<nckx>Guest36: AFAIK there's no way [yet] to specify SSIDs/PSKs/etc. through Guix.
<nckx>This could be added by someone motivated.
<janneke>nckx: sure
<apteryx>what's the typical entry point for build-side code? some builder script?
<apteryx>lilyp: perhaps the xvnc service with xdmcp? #t (assuming you use Xorg) would help your testing
<Guest36>nckx: Ah good to know
<apteryx>instead of logging out from your real session, you'd simply logging a new localhost-served VNC one.
<apteryx>I've used that trick to test desktop upgrades before, it was handy.
<reedm>nckx: running "modprobe bcachefs"
<sneek>reedm, you have 1 message!
<sneek>reedm, nckx says: And does manually modprobing bcachefs work? I've never used the service you mentioned, but have the module automatically added to my initrd because it's my rootfs.
<reedm>nckx: yields "modprobe: FATAL: Module bcachefs not found in directory /run/booted-system/kernel/lib/modules/6.7.5"
<reedm>nckx: in /proc/config.gz, I have a line "# CONFIG_BCACHEFS_FS is not set". Is this likely the root cause?
<podiki>hako: it said server certificate not trusted and still retrying
<hako>podiki: Can you DM to me the detailed message? I'll check it out tomorrow
<podiki>hako: sure, not a problem. I'll do it once I'm at my other computer, probably need to use a paste service (will put a password on it) and send it
<nckx>reedm: Yes, it is. Which kernel is this?
<nckx>I grepped Guix's .config and it was [m] but I don't remember which one I grepped.
<nckx>I'll try to remember not to sneek you any more messages. :)
<lilyp>apteryx what testing exactly?
<reedm>nckx: given the rules of the chatroom, I'll simply say I use the most common non-guix-default linux 6.7 kernel. Is there an easy way to add that config setting back in via the operating-system declaration?
<reedm>Sorry, didn't mean to invoke any details there. By non-guix-default, I meant to indicate that it wasn't the default guix, not trying to reference any particular channel
<spiderbit>so somehow guix offload just makes both machines go into idle mode for me, but that is not really high on my priority list and the package I wanted to offload build is now as substitute there
<spiderbit>But I still try to get my keyboard working correctly over eudev hwdb file, I switched this machine on gnome-team branch so theoretically the necesary patches should be there to load hwdb files
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<spiderbit>can somebody tell me what I have to configure to get there my hwdb file used/loaded
<spiderbit>so /etc/udev/hwdb.bin is read only so I have to build it somehow into the config
<podiki>perhaps ask lilyp vivien as the authors. unclear from a first look if it will just work from any packages included in the system profile which have those files, or if something else is needed (and should be documented)
<podiki>oh, seems it should find hardware files if packages in the same profile have files in their lib/udev/hwdb.d directory
<podiki>e.g.. packages which have /gnu/store/...<package>.../lib/udev/hwdb.d populated and are in the same profile as the eudev package. likely the system configuration I would say
<vivien>spiderbit, you need to extend the udev-service-type with the value that is the result of calling file->udev-hardware if you have a file-like object, or udev-hardware if the file content is a string
<spiderbit>so is there a smaller derivation or what not possible or do I need my own version of the package?
<spiderbit>well I originally thought I wait till the next guix release with that changes, but I did not see that guix only get's new releases every 2 years or so :)
<vivien>Similarly to what is done for udev-rules (see the manual), you can use the udev-hardware-service (search for "udev-rules-service" in the manual and replace every instance of "rule" with "hardware" :))
<vivien>It will soon(tm) be on master
<spiderbit>I don't even know where this is defined
<lilyp>on master, currently nowhere
<podiki>Guix is rolling, the releases are just of the installer really
<spiderbit>podiki good to know!
<spiderbit>vivien so you say this udev-hardware-service is already defined I just have to set the right values to it?
<spiderbit>this would make sense and is what I expected
<spiderbit>it's just not documented then I guess
<lilyp>on gnome-team in the same location as udev-service-type and file->udev-rule
<lilyp>IIRC, it ought to be documented over at gnome-team
<spiderbit>"over" means what :) is there a manual version for this, well if I just have to pretend it's a rule and change the rules -> hardware in the doku, it should be doable without specific manual :D
<lilyp>it means you have to check out the source and compile the documentation locally
<spiderbit>can't I just look up the doku of rules and apply it as you seem to have said before?
<nckx>reedm: I can't help you with a custom kernel package (unless it's so custom you wrote it yourself :) but there's
<peanuts>"Customizing the Kernel (GNU Guix Cookbook)"
<nckx>But you should also inquire why they disabled it.
<nckx>It's likely just a bug.
<spiderbit>(udev-hardware-service 'my-keyboard %example-udev-hwdb)
<spiderbit>so something like that?
<vivien>Is there an automatic linter for news entry?
<reedm>nckx: Thanks! that was exactly what I was looking for
<lilyp>yes, we have a make-target that runs as pre-push hook
<podiki>there's build-aux/check-channel-news.scm if you want to use it directly
<podiki>though i think that just checks it works not sure if it lints as well
<lilyp>For actual content you can't do better than manual review
<aldum>is there a groupchat/project/wiki/etc for devops related usecases and discussion, like NixOps for Nix?
<tokenringwraith>is there any way to set the default toolchain to rebuild an entire profile with it ? like stdenv in nix
<spiderbit>lilyp it accepted the config and run through a reconfigure do I have to resatart the computer to make it active or does it just silently not work :D
<civodul>aldum: there’s no devops-specific communication channel, but you should definitely bring it up on or
<civodul>also if you have ideas on how to incrementally improve ‘guix deploy’, that’s something many people would like
<spiderbit>well reboot did not work or to be more precise it did not load my hwdb file
<spiderbit>   (udev-hardware-service 'my-keyboard %laptop-kb-udev-hwdb)
<aldum>I definitely don't have things to add yet, I was wondering where to start
<aldum>saw some discussion here about containers for example
<spiderbit>ohh I see a problem
<spiderbit>didn't change the name of the output file from the rules example
<ieure>Does anyone have a suggestion for conditionally starting a Shepherd service? I have one which launches jellyfin-mpv-shim, but I want it to only start if there's a config file on disk.
<ieure>If you configure jellyfin-mpv-shim, it runs in the background; if you don't, it launches a GUI to do that. I'd like the shepherd service to only launch it when there is a config file.
<ieure>I stuck a conditional in the (start ), but shepherd thinks it's running even though it's not.
<ieure>(The configuration IMO isn't reasonable to do declaratively, as it contains an auth token for a remote server, which can only be obtained by communicating with that server.)
<civodul>ieure: you could have its ‘start’ method return #f if the file doesn’t exist
<spiderbit>lilip well it put my hwdb file in a folder with the other hwdb files so I tihnk I used the right stuff, but it did not take effect
<spiderbit>it's in /gnu/store/22b....-udev-hwdb.d/
<spiderbit>the content of the file seems right
<lilyp>I don't have magic access to your file system, sorry ._.
<spiderbit>You may obtain device identification info by running evemu-describe(1) as the root user. This command is provided by the evemu package.
<spiderbit>that's from archlinux wiki I can only think it must need a different device id
<peanuts>"emacs-ergo-thinkpad-kb-layout/90-X220-keyboard.hwdb at master ? spiderbit/emacs-ergo-thinkpad-kb-layout ? GitHub"
<spiderbit>that's the file
<lilyp>to be completely honest, I haven't yet had to debug any hwdb-related stuff, so I'm as clueless as you, sadly
<spiderbit>theoretically this shold match all "at" keyboards
<spiderbit>if that catches it I would be good because otherwise I would only use usbkeyboards as alterantive
<lilyp>I think udev logs to /var/log/messages, maybe you can check there for suspicious lines
<lilyp>you might also try udevadm hwdb --test
<spiderbit>--test expects a value MODALIAS
<spiderbit>no idea what that is supposed to be
<spiderbit>if I use -u -o test.db
<spiderbit>it accepts it
<spiderbit>so no syntax error I guess
<vivien>spiderbit, with your initial system configuration, do guix build -f <your config> instead of guix system reconfigure, and do that for your system configuration with the new hwdb file. You should be able to compare the 2 results, and particularly /etc/udev/hwdb.bin
<vivien>The hwdb.bin file should change (it should be bigger) by adding the hwdb file in your system configuration
<spiderbit>that seems a lot of work to just check if the rebuilding works
<spiderbit>I would still assume it's more likely the wrong device id
<spiderbit>I did this many years ago
<spiderbit>probably they changed that
<spiderbit>I just have to change it to point to a local file
<spiderbit>to test it
<spiderbit>well the md5sum of /etc/udev/hddb.bin changed it's still 4kb big
<spiderbit>or is that only a dummy version
<vivien>On my GNOME system it’s more like 9.8 MB
<vivien>But it’s probably a symlink, so maybe the tool you use to compute the size does not manage symlinks
<vivien>I do wc -c /etc/udev/hwdb.bin
<spiderbit>it says 9,8mio I guess bytes
<vivien>That’s more likely yes
<spiderbit>I use a relative high number
<spiderbit>is that priotising the lower
<vivien>You should have UDEV_HWDB_PATH set
<spiderbit>so if there would be another file have the same evdev id... maybe it steels it from me
<vivien>It will tell you where udevadm found the hwdb files to create the index
<vivien>(Well, the system part of the value of this variable at least)
<spiderbit>yes it's set
<spiderbit>in this directory
<spiderbit>there is my file missing
<vivien>Do you mean, you found your file, or your file is missing?
<spiderbit>in this directory there it is missing
<vivien>Well, it means that your system configuration did not add it
<spiderbit>(udev-hardware-service 'my-keyboard %laptop-kb-udev-hwdb)
<spiderbit>so that is not enough
<vivien>What is %laptop-kb-udev-hwdb?
<spiderbit>I defined it
<spiderbit>like in the readme...
<spiderbit>(define %laptop-kb-udev-hwdb
<spiderbit>  (file->udev-hardware
<spiderbit>   "90-X220-keyboard.hwdb"
<spiderbit>   (local-file "<path-to-file>")))
<vivien>There it is
<vivien>It works if I do (plain-file "test" "# test udev hardware file")
<vivien>I see my file
<vivien>So maybe the problem is somewhere else
<spiderbit>the file is in /gnu/store/vq...-udev-hwdb.d/
<vivien>Oh right it’s not installed under /profile
<spiderbit>yes it points directly
<spiderbit>to the package
<spiderbit>the files in profile
<spiderbit>not this separate store thing :D
<vivien>Since your file is not installed as part of a package, then it does not appear in the profile
<spiderbit>the mixed together store thing exist
<spiderbit>what's it called a build?
<vivien>I don’t understand, sorry
<spiderbit>well I just say there is path in gnu/store
<vivien>Your hwdb file does not appear in the profile because it’s not part of a package, but it is indexed by the hwdb.bin index
<spiderbit>where all the hwdb files are
<spiderbit>ahh so you think it's not ignored
<vivien>I think so
<vivien>I think it’s not ignored
<vivien>It’s just not installed
<vivien>It’s just not installed separately
<vivien>It should be included in the hwdb.bin file
<vivien>But not installed as a stand-alone .hwdb file
<spiderbit>it's interesting in the keyboard.hwdb there are other thingkpads with their device ids listed
<vivien>Maybe you should a lower file name than 90-X220-keyboard.hwdb then
<vivien>Maybe you should choose a lower file name than 90-X220-keyboard.hwdb then
<spiderbit>doubt it that would be a regression I guess the point is besides that i use keyboard:dmi:... it's now evdev:atkbd:dmi
<spiderbit>it looks otherwise the same as my ids
<vivien>I can’t help you much, I have very little experience with udev
<spiderbit>yes thanks... I think I did not reboot since last change... maybe it loads it, well couldn't I load it with "trigger"
<vivien>I just know how to compile a list of hwdb files into a hwdb.bin file using udevadm
<apteryx>lilyp: it was in response to you mentioning you were re-login to test some dbus tIng
<spiderbit>I mean I can rename it I guess
<spiderbit>maybe eudev is not compatible with the older implementation
<spiderbit>ohh wait
<spiderbit>reboot did it
<spiderbit>thank you very much!
<vivien>Thank you for testing!
<spiderbit>so the device id was the problem
<spiderbit>ok with the slightly altered device string keyboard -> evdev:atkbd it also works so just this "keyboard" but yes I am offline for now cia.
<ieure>civodul, Returning #f kind of works (it doesn't start), but herd reports it as "failing" without giving any reason why. Is there some way to communicate *why* it isn't starting? I tried returning #:not-configured from start instead of #f, and that shows up in the running status, but shepherd thinks it's running in that case.
<mccd>Heya, is anyone in the american side of the world also having very slow download and build speeds? Even with substitutes
<lilyp>The servers are located mainly in Europe, so you might have issues getting across the pond.
<cow_2001>what does "some outputs of `/gnu/store/....drv` are not valid, so checking is not possible" mean?
<nutcase>Hi Guix. I'd like to see wl-mirror in Guix. I couldn't find it, therefore I tried to create a package definition on my own. This is the result, which I have questions on:
<peanuts>"wl-mirror-for-guix/wl-mirror.scm at main ? nuthub/wl-mirror-for-guix ? GitHub"
<nutcase>Is this something, that's generally interesting for others @Guix? If yes, I have further questions on polishing the package definition (see TODOs) and on the contribution process.
<nutcase>How should I deal with source code that doesn't mention any version numbers or license (see wlr-protocols, which is a requirement of wl-mirror)?
<lilyp>We typically do some variant of 0-REVISION-COMMIT
<apteryx>should gnu/packages/ be part of the core team?
<apteryx>or perhaps rather of the core-packages team
<civodul>apteryx: core-packages, yes, that’d make sense to me
<civodul>ieure: unfortunately no, there’s no way to communicate why it’s failing to start
<ieure>civodul, Bummer.
<ieure>civodul, Do you think it'd make sense to create a jellyfin-mpv-shim-configuration-shepherd-service, which starts or doesn't start based on the presence of the config, and which jellyfin-mpv-shim-shepard-service requires?
<apteryx>jpoiret: hi! how must diruption can we cause on core-updates at this point in time?
<apteryx>how much*
<apteryx>(in terms of say, world rebuilds)
<jpoiret>hey! is this wrt. the pkgconf patchset?
<civodul>ieure: i’m not sufficiently familiar with the use case, but maybe yes
<apteryx>yes, or another change I've made to ld-wrapper (will send to review first)
<jpoiret>in terms of world rebuild, there's a low level change we'll need to make for guile to have a libxcrypt dependency
<jpoiret>still trying to think of how to properly do it, esp. since libxcrypt doesn't have any tarball releases except for github's, and git has a dependency on python which itself has a dependency on libxcrypt now
<jpoiret>so all in all we can afford one world rebuild but it has to not be too impactful down the line
<ieure>civodul, The usecase is: I want this thing to launch if it's configured; and not launch at all if it's not configured. The reason is that if it starts when it's not configured, it pops up a huge GUI window, and that'd be an annoying experience if you add the service and log in. I'd rather manually open it, configure it, and then have it Just Work from then on.
<nutcase>lilyp: thank, I added (version (git-version "0.0" revision commit)), although I'm not sure, how "revision" is usually determined and set it to 0 now. (see
<peanuts>"wl-mirror-for-guix/wl-mirror.scm at main ? nuthub/wl-mirror-for-guix ? GitHub"
<ieure>civodul, But, if I just fail the start when it isn't configured, it won't be obvious that you have to launch manually in order to get the expected behavior; so communicating that it needs that manual action somehow is key to making that work.
<podiki>nutcase: revision will start at 0 (well sometimes I see it start at 1, but anyway) and will bump it up for a new commit or change basically (since the version number doesn't change)
<ieure>I guess I can stick that in the infodocs, but I'd rather have the service communicate the situation, since that's likely to be what users see.
<nutcase>podiki: thanks, I think that in my case something like "wlr-protocols-0.0-0.4264185" would be fine then?
<podiki>yeah, I think it will looks something like that. not the prettiest but that's how it goes
<nutcase>is there a best practice how to deal with source code that does not ship a separate COPYING or LICENSE file? However, the assets in the repo (XML files) contain a license text that looks like MIT license to me. But I am not 100% sure.
<peanuts>"unstable/wlr-input-inhibitor-unstable-v1.xml ? master ? wlroots / wlr-protocols ? GitLab"
<tokenringwraith>which version of guile should i be using ?
<tokenringwraith>3.0.9 is the only one that technically doesnt fail or crash when i use it within emacs
<tokenringwraith>because it hangs forever in probably an infinite loop
<tokenringwraith>ive added ~/.guix-profile/share/guile/site/3.0 and ~/.config/guix/current/share/guile/site/3.0/ to the load path and installed all the addons that the handbook doesnt say are necessary but are
<apteryx>civodul: it's bug#69395
<peanuts>"GUILE_SYSTEM_PATH and GUILE_SYSTEM_COMPILED_PATH are not documented"
<apteryx>err, not this one
<cow_2001>what licenses would you call "We intend this report to belong to the entire Scheme community, and so we grant permission to copy it in whole or in part without fee. In particular, we encourage implementers of Scheme to use this report as a starting point for manuals and other documentation, modifying it as necessary."? specifically the ones in (guix licenses)
<cow_2001>(that's the copying paragraph of
<cow_2001>currently working on the r7rs-small-texinfo package definition
<apteryx>perhaps (license license:non-copyleft) ? since it's a custom license
<apteryx>cow_2001: that's cool, thanks for undertaking this
<apteryx>note that we have r5rs and r6rs build targets in Guile itself
<cow_2001>this one doesn't need guile
<apteryx>I thought about adding r7rs there, and have a guile:doc output install these Texinfo manuals there
<cow_2001>wait, build targets?
<apteryx>ACTION checks
<apteryx>there's at least referenced somewhere, so I thought it must be possible to build it
<apteryx>see doc/r5rs
<cow_2001>it's part of guile, which is a bit unfortunate, because it's useful for any Scheme
<apteryx>true, but given it's a GNU Texinfo adaptation and was used as the reference for Guile, it kind of makes sense to have it there as well
<apteryx>our current packaging of Guile doesn't expose this though, which we should change
<cow_2001>i'd split it into its own separate package, and maybe add it as an input?
<apteryx>maybe that could do it
<apteryx>if you really want to have it as a standalone package too
<apteryx>I think otherwise it would be reasonable to have it in guile:doc output, and expand the guile package descrition to mention its doc output ships these useful resources
<dodoyada>I use guixsd on a librem 14 and have an issue where my computer will charge from 0-1% but stops charging until I unplug and plug it back in, then it continues. Is this more likely an issue with my guix system config or with the laptop itself?
<apteryx>sounds like a hardware problem
<apteryx>if you want to confirm, you could try another live system and see if the issue resolves or persists
<dodoyada>cool, will try it
<apteryx>cow_2001: just saw your package for it here:
<apteryx>since it comes from its own project source, then it makes sense to be a standalone package
<cow_2001>apteryx: i've added license notices to all source files!
<peanuts>"kakafarm/guix-kakafarm-channel: Kaka Farm's GNU Guix channel. -"
<cow_2001>just now
<cow_2001>i wish there was some Guix training
<cow_2001>there are so many parts that need to come together in dealing with Guix
<cow_2001>apteryx: the file is now in kakafarm/packages/texinfo-documents.scm
<cow_2001>people are using gpg to sign their channels, but i never get around to actually generating a keypair