IRC channel logs


back to list of logs

<redacted>Have you tried using the importer (recursively to pull in dependencies)?
<peanuts>"Invoking guix import (GNU Guix Reference Manual)"
<ieure>JetpackJackson, There's a bunch of Go stuff packaged already, you can look at those for prior art. Specific reason for the failure is likely in the build log, but it can be hard to see.
<JetpackJackson>oh i didnt realize you could import go packages
<JetpackJackson>ill try that
<JetpackJackson>and look at examples
<JetpackJackson>thanks :3
<JetpackJackson>hmm guix import is failing with "reason: "" could not be fetched: HTTP error 404 ("Not Found")."
<JetpackJackson>oh its named differently in gopkgs
<JetpackJackson>thats annoying
<JetpackJackson>wait now its importing but its taking a while
<JetpackJackson>ok it doesnt want to import, it times out
<redacted>huh weird
<redacted>JetpackJackson, you won't be stuck with the name
<redacted>JetpackJackson: here's the output of `guix import go -r` for me:
<peanuts>"output of guix import go -r -"
<redacted>oh wait
<redacted>that's the wrong package, I think
<peanuts>"guix hydroxide -"
<redacted>JetpackJackson: the second pastebin link should be the right package
<redacted>I used the wrong repo name
<redacted>Didn't test whether it builds
<JetpackJackson>redacted: thanks! ill go test it
<JetpackJackson>hmm it cant find the emersion-go-smtp package
<JetpackJackson>i need to figure out why my guix import isnt working
<JetpackJackson>what command specifically did you run
<redacted>JetpackJackson `guix import go -r`
<JetpackJackson>thanks, ill try that and see if it works
<JetpackJackson>still lagging and timing out this is strange
<JetpackJackson>i can do guix install so i have internet
<JetpackJackson>Git error: remote rejected authentication: Failed getting response
<redacted>are you able to visit and in your browser?
<peanuts>"hydroxide module - - Go Packages"
<peanuts>"GitHub - emersion/hydroxide: A third-party, open-source ProtonMail CardDAV, IMAP and SMTP bridge"
<redacted>Next thing I'd try is checking the network traffic generated by the command with wireshark or tcpdump or something. I don't know how to do that off the top of my head.
<JetpackJackson>alright ill look into that
<redacted>might be a wild goose chase, though. I'm not sure what the right move is.
<JetpackJackson>yeah idk
<redacted>did you try updating your system?
<JetpackJackson>i cant find anything about the error online
<JetpackJackson>not yet
<JetpackJackson>was thinking about it tho
<JetpackJackson>im on a foreign distro tho so it should be fast
<redacted>I would definitely try updating before doing the networking stuff
<JetpackJackson>oh looks like someones working on hydroxide:
<peanuts>"[PATCH 0/3] add hydroxide package"
<JetpackJackson>how do i try out a patch from a package request?
<imadnyc_>Hey, so I'm a little confused on the entire `use-modules` thing
<imadnyc_>do I need to import each module that my packages are from each time (say for vim I need gnu packages vim) or can I just import everything all at once so I don't need to worry about it?
<imadnyc_>in Nix everything is accessible by the `pkgs` attribute so this is a ltitle offputting
<imadnyc_>also how do I discover which package goes where? I want to install `magic-wormhole`, and while for some package it tells me what I need to import, it's just telling me that I need a "use-modules form", but what module do I use?
<redacted>to find which module you need, use `guix search <package name>`. Look for the line that starts with "location:". The module name you need will be similar to the file path, so gnu/packages/magic-wormhole.scm will mean you need to import (gnu packages magic-wormhole)
<redacted>you can search for services with `guix system search` and home services with `guix home search`
<redacted>I'm not sure if importing all the modules is possible in Guile Scheme, since I've never tried.
<imadnyc_>thanks, but doesn't that only work because of how guix is structured? if say i had another channel that had a diff file name than the module name, is the only way to `guix edit <package name>` and look manually?
<imadnyc_>like `guix shell <package>` works and it seems to know where it is, how do i tell it to tell me?
<redacted>good point
<redacted>I've been looking over the source code of guix shell and I'm not sure.
<redacted>oh, found the solution I think
<peanuts>"Using the Configuration System (GNU Guix Reference Manual)"
<imadnyc_>wow, super confusing
<imadnyc_>especially since the default home.scm that's part of the latest install doesn't use the speicifcation but rather expects the package name (not as string)
<juli>you can get the module for a package the same way whether it's from Guix proper or a third-party channel
<juli>assuming you build your Guix with it (that is, it's one of the channels used when you `guix pull')
<juli>unlike Nix, Guile is a general-purpose programming language so it works more like a regular programming language than Nix
<juli>hence modules
<juli>as for converting package specifications to packages, there's `specification->package' for individual packages, and `specifications->packages' for lists thereof
<juli>if you want a specific output of a package without needing to use a specification (which is more ambiguous at the code level), you use a list like so: (list <package> "<output>")
<juli>the shorthand form of which is `(,<package> "<output>")
<juli>(you'd use this in, for example,`packages->manifest', or a package definition)
<juli>(strictly speaking the quasiquote form - the one starting with ` - is more about manipulating whether you're referring to the code as code or as data, but that's not something you necessarily need to know; it does explain some disparities between quasiquoting and using the list procedure, though)
<juli>` is an alias for quasiquote; , is an alias for unquote
<juli>and ' is quote
<ieure>Is there some command that'll show me the dependency path between two packages? I would like to understand why `guix build librewolf' is compiling a shit-ton of texlive packages.
<ieure>Okay, I see, it's because I had to update nss and flippin' everything depends on it.
<noobly>is there a guide for setting up a java development environment on guix?
<bigbookofbug>apologies if this is a basic question, but how would i figure out the license type when building a package if it doesnt appear explicitly stated?
<bigbookofbug>im packaging some chicken eggs, and it doesnt seem as if the license is stated in the license doc itself
<juli>do you mean that the license text does not state the name of the license?
<juli>and no other documentation gives the name of the license, either?
<juli>or something else?
<bigbookofbug>juli: yep ! the miscmacros egg, for example:
<bigbookofbug>the license seems like expat i think ? but licensing is a weakpoint of mine when packaging so i still struggle to sort them out unless its explicitly states
<juli>I don't know of any good tools except a web search tbh
<juli>there's this
<peanuts>"GitHub - licensee/licensee: A Ruby Gem to detect under what license a project is distributed."
<peanuts>"GitHub - spdx/spdx-license-matcher: A tool to match license text with SPDX license list using a an algorithm with finds close matches. It follows SPDX Matching guidelines to keep the substantial text as well as ignore the replaceable text for matching purposes."
<juli>guix could benefit from such a tool
<bigbookofbug>thank you ! and i agree
<bigbookofbug>like i cant speak for others of course, but something like a guix get-license as a CLI tool would be immensly helpful. een if it still needed to be manually checked by the packager, it at least would provide a point-of-reference
<juli>i may have nerdsniped myself
<juli>because i frequently run into this problem
<redacted>bigbookofbug, looks like that package has the BSD license. It's the miscmacros listed on this page, right?
<peanuts>"Eggs Unlimited (release branch 5)"
<bigbookofbug>redacted: thank you omg
<bigbookofbug>i didnt notice the license field there
<PuercoPop>How do I customize a package to f/e pass a new argument. In this case I want to pass the #:ruby and #:gem-arguments to the ruby-byebug from my guix channel.
<PuercoPop>Is the answer package variants?
<freakingpenguin>For example?
<peanuts>"byebug ?"
<PuercoPop>f/e I want to pass pristin to the gem invocation of the ruby-build-sistem to see what happens.
<PuercoPop>I'm trying to debug the problem someone encountered trying to use byebug at
<peanuts>"Building Ruby Gem Native Extensions in GUIX - Guix - System Crafters"
<juli>most kinds of package transformations are effectuated by making a variant, yet. there are lots of helpers to facilitate this process, though
<juli>substitute-keyword-arguments is probably helpful. it's not documented, but it's fined here:
<peanuts>"utils.scm\guix - guix.git - GNU Guix and GNU Guix System"
<PuercoPop>juli: Thanks! I was just about to mention that I had seen that online but I couldn't find it on the manual
<juli>let me find an example as well for ya
<juli>just need to gather the link
<peanuts>"onc-rpc.scm\packages\gnu - guix.git - GNU Guix and GNU Guix System"
<juli>(although you can probably also grep the guix source to find more examples)
<juli>hmm... someone should probably document that macro...
<juli>in fact, the entirety of (guix utils) probably deserves documentation
<juli>i can't tell you how often i bang my head against a problem for ages only to realize later there was a helper procedure floating around the codebase somewhere
<PuercoPop>can I use any non whitespace character as part of a symbol-name in guile? Emacs highlithing seems to suggest that I can't use prime(′) as part of the symbol name
<juli>idr the exact characters off the top of my head but ' ` , are off the table so i assume comparable characters are as well
<juli>I believe Guile's naming conventions match either r6rs or r5rs, though i suspect they are the same
<Guest16>Does anyone know how often GNOME gets updated? In the main repo GNOME is still on version 44.10. Which isn't "old" or anything, but I was using 45 since the monent it was available on Gentoo and I don't know how long I can tolerate using an older version.
<bigbookofbug>im having a bit of trouble getting an executable installed via the chicken-build-system. the program is an egg, but installs as a binary as well since its meant to be executed (its an i3bar written in scheme). the issue is that, when it attempts to install the bin after building, chicken-install runs into an error where it doesnt have the permissions necessary to install the binary
<bigbookofbug>i wonder if, since it is supposed to produce an executable binary, it needs to be installed via a different build system. but at the same time the repo states to cd into the repository and run "chicken-install" to install it, so i'm unsure of an alternative there
<bigbookofbug>if its of any help, the error i get is `install: cannot create regular file '/gnu/store/p4035pd4ly3qzip4gqm5dw971miq3100-chicken-5.3.0/bin/tarme': Permission denied`
<pabs3>bigbookofbug juli - the best tool for detecting copyright/license info is scancode, lots of tools mentioned here though:
<peanuts>"CopyrightReviewTools - Debian Wiki"
<peanuts>"GitHub - nexB/scancode-toolkit: :mag: ScanCode detects licenses, copyrights, dependencies by "scanning code" ... to discover and inventory open source and third-party packages used in your code. Sponsored by NLnet project, the Google Summer of Code, Azure credits, nexB and others generous sponsors!"
<ngz>Hello Guix
<attila_lendvai>the linux kernel was updated 30 hours ago, and i'm building it locally. something is probably stuck somewhere.
<ngz>attila_lendvai: I agree we're experiencing an overall slowness in CI an QA recently.
<ngz>For example, I find load percentages surprisingly low at <>
<attila_lendvai>well, stuck could be unstuck, but slowness is understandable and cannot easily be fixed. but it was time for me to learn about `guix pull --commit=[hash] --allow-downgrades` anyway
<peanuts>"Activity Build farm"
<attila_lendvai>hrm, then maybe there *is* something that can be unstuck
<sepeth>Hello friends, I am on a foreign distro (debian) and trying to replace it with Guix entirely like it is mentioned in this post (see Installing on the same drive), but glibc-cross-aarch64-linux-gnu-2.35 build fails with:
<peanuts>"debian Pastezone"
<sepeth>One thing I did different than the post above was to pass --target=aarch64-linux-gnu to the `guix system init` command, and without that I saw a grub related error and the file it was trying to look had i386 in the name. Hence, I added that.
<sepeth>Any idea to solve this?
<cbaines>on what systems ngz?
<ngz>cbaines: x86_64 and i686
<cbaines>the guix-packages-base builds can often lead to low loads because they get stuck and just take up RAM
<ngz>It's slightly better now (there are still 3 machines under 70% though), but at one point, only geidi was working, apparently.
<ngz>cbaines: Also, I don't know if you have noticed, but is kinda broken ATM.
<peanuts>"Statistics Guix Data Service"
<cbaines>that page has been broken for a while, it just needs removing
<cbaines>there's so many derivations now that counting them takes too long
<cbaines>in other news, I'm part way through rebasing core-updates, so I should be able to push this morning
<ngz>OK. Do you need any help?
<ngz>sepeth: No sorry =/
<cbaines>I'm looking at to see if there's more things worth including
<peanuts>"Patches Guix Quality Assurance"
<efraim>is it libfaketime that fails on core-updates on 32-bit architectures?
<cbaines>I've already added #68828 but if you have any thoughts on the changes there, that would be great
<peanuts>"[core-updates] gnu: libxft: Update to 2.3.8"
<cbaines>efraim, looks like it
<efraim>so off the top of my head its libfaketime for 32-bit architectures and libclc into mesa for aarch64 are some big problems I know of
<ngz>#71785 is uncontroversial, too, isn't it?
<peanuts>"[PATCH core-updates] build-system/meson: Add #:out-of-source? argument to build system."
<cbaines>ngz, I agree
<cbaines>efraim, I wonder if libfaketime is also affecting x86_64-linux builds, since I see it here maybe some x86_64-linux derivations use it somehow
<cbaines>(or the data service is getting confused)
<peanuts>"Blocking builds - Revision f14d43c Guix Data Service"
<efraim>uh, it might be actually. I have some not checked-in code around libfaketime on my core-updates branch
<ehmry>juli: I am in a #tvl channel and there has been light discussion on the protocol topic
<ehmry>this is the proposal I made a while ago, use the syndicated actor model
<efraim>cbaines: after you finish your rebasing I'll put my thoughts and code together for fixing mesa on aarch64 and send a patch
<ehmry>I did some work on absracting and proxy the worker protocol but moved onto working with a frontend protocol
<ngz>I think we should reconsider copyright lines at the top of the files. They introduce too many merge conflicts (e.g., 70496). Would it be possible to move them in a single COPYRIGHT file, where each module has its own hall of fame?
<ngz>err, listing copyright per author, not module, to prevent the same kind of issue in that file.
<ngz>Or force sorting copyright lines alphabetically in each module to reduce the conflicts.
<efraim>IMO there's too much potential for bikeshedding, between the FSF approved 15-line minimum, what counts as non-obvious, removing copyright if no code remains, all of it is fair game if we move the copyright to a separate file
<efraim>alphabetically (as I understand it) is less common than by date, but I suppose could reduce merge conflicts. At least after an initial conversion
<efraim>then again, one package per module also makes it a lot easier to reduce merge conflicts, but feel free to ignore that bikeshed
<efraim>ACTION once again feels like a repository of random knowledge
<ngz>Let's write packages in a padlet
<ngz>In any case, merge issues for such trivial topics are annoying.
<efraim>new plan! we improve 'guix import' to create ready-to-build packages and then we can remove "obvious" packages from guix because they can just be re-created by guix import at build time. it also decreases the size of the guix binary!
<efraim>ACTION hopes everyone knows to ignore that idea too
<civodul>efraim: i’ve long thought that we could use importers at run time, without writing down package definitions
<civodul>‘--with-latest’ is actually one step in that direction
<civodul>but we could do “guix install cran:whatever”, say
<efraim>I halfway think it might be the way out of the cargo mess
<civodul>except that the “cargo mess” is now touching the core of the system
<efraim>we package some specific crates which need special touches and rely on the importer for others
<efraim>indeed. but if we choose to rely on the author's Cargo.lock file then we have a list of crates and their versions which should work
<efraim>and which will return the same exact list of crates each time
<cbaines>efraim, do you know what the state of rust on x86_64-linux on core-updates is?
<efraim>cbaines: no idea, but I can test it locally or on berlin
<cbaines>I think the data service says rust@1.69.0 fails to build
<efraim>I assumed it was working
<peanuts>"Guix Data Service"
<efraim>my computer suggests berlin has a substitute for librsvg for x86_64 on core-updates
<cbaines>ah, and it does have a substitute for the thing I linked to, so I guess it doesn't fail all the time...
<cbaines>On core-updates, I've now pushed core-updates-new. This is core-updates, rebased on the lisp-team and other big changes that landed on master (subversion update, ...).
<cbaines>Plus a few new patches, and the changes on tex-team.
<cbaines>The bordeaux build farm is still catching up with the master branch, but maybe tomorrow we can delete core-updates, push core-updates-new to core-updates, then delete core-updates-new.
<futurile>morning all
<cbaines>I've just killed the stuck jobs on so it should process core-updates-new to at least see if that works
<cbaines>morning futurile o/
<ngz>cbaines: Thank you!
<civodul>cbaines: what’s new in ‘core-updates-new’? :-)
<civodul>the figures at are good
<peanuts>"Branch core-updates Guix Quality Assurance"
<cbaines>as I say, it's rebased on the big changes on master (lisp-team, subversion update, ...), includes two or three new patches, and includes all the tex-team changes
<cbaines>I think we needed to rebase due to the changes on master, so I think it makes sense to at least try changes that shouldn't be problomatic
<cbaines>if we do spot new problems, hopefully we can just remove those changes from the branch
<efraim>civodul: I think is missing some files
<civodul>cbaines: oh, excellent
<cbaines>civodul, I've been looking at too, although to me the numbers still look quite poor, and I was hoping things would build a little quicker
<civodul>maybe let’s call it ‘core-updates’?
<peanuts>"Branch core-updates Guix Quality Assurance"
<civodul>cbaines: yeah well, they’re good for x86_64; for aarch64, we’re virtually not getting much for aarch64 because most builders are stuck (waiting for support from the MDC)
<civodul>so it won’t get better, but bordeaux.guix has good figures there
<cbaines>I wanted to push it as core-updates-new in case there were fixes/changes other people wanted to make
<cbaines>to try and avoid multiple changes in quick succession
<efraim>I want civodul's fix for clang-15 on i686-linux
<cbaines>since it looks like the changes from master have almost finished being built, we can switch core-updates-new to core-updates tomorrow maybe
<civodul>sounds good
<civodul>the downside of rebasing is that it’s quite opaque: it’s hard to tell what has changed
<civodul>but i guess that’ll be better for the next ‘core-updates’, when we really keep it focused
<civodul>efraim: re missing files, i can upload whatever is need on your behalf, just lemme know :-)
<cbaines>yeah, I'm hoping that if we can move towards building branches out of patch series, then that can make things clearer
<cbaines>efraim, is that clang-15 fix a thing for core-updates?
<jpoiret>tracking changes to individual patch series is quite annoying too though, we don't have good tools for this
<efraim>yeah, it touches guix/elf or something
<jpoiret>sorry i'm weighing in even though i haven't done anything in a while but i've been thinking about the workflow for branches
<jpoiret>ideally we could rebuild branches from sets of patchseries, but when rebasing you have to send updated patches to the corresponding mail threads, and that could be quite time-consuming
<civodul>efraim: oh wait, the thing to avoid OOMs in gremlin?
<efraim>yes! that was it
<jpoiret>there's topgit that can potentially track patchsets and their evolution through time using git but it seems quite heavy to use
<civodul>it was really a hack, and i think we shouldn’t do a mass rebuild at this point
<civodul>so i’d just #:validate-runpath? (not (32bit-system?))
<civodul>(a bit of a shame, but sometimes we need to cut corners)
<efraim>I guess we can do that for llvm/clang. although it was really just i686-linux
<cbaines>do we know what the blockers for i686-linux on core-updates are? The data service says libfaketime and gd
<civodul>yes, i noticed gd
<civodul>it’s just one test failure IIRC
<civodul>maybe we should just XFAIL_TESTS that one and be done with it
<civodul>ACTION restarted cuirass
<civodul>according to cuirass.log, its heap suddenly grew and then it wasn’t making any progress fetching from Git
<civodul>looks like it was stuck somewhere in libgit2
<cbaines>savannah seems to be having problems at the moment
<Guest91>Hey guys, I'm trying to setup early kms but I can't figure out what I'm missing. I've added (initrd-modules (cons "nouveau" %base-initrd-modules)) under operating-system. But when I boot, modesetting and GDM are broken. Thoughts?
<ngz>Another idea for copyright lines: store them in a recutil database in the repo, and automatically add commit authors to that database through a server-site commit hook
<irfus>Regarding my previous messages, I think it's possible I ran into bug #71065
<peanuts>"Emacs packages that override built-in features ignored when compiled"
<kks>What's holding back the adb version?
<futurile>kks: someone updating it? (don't know this package personally)
<jpoiret>newer versions of adb require a new build system iirc, which is not packaged in guix
<ngz>cbaines: BTW, shall I delete the "tex-team" branch now you integrated it with "core-updates-new"?
<graywolf>Is there a way to configure guix deploy to not produce any ansi escape sequences?
<graywolf>Second question: Into where do the activation-service-type services log their output?
<cbaines>ngz, I'd keep it for now
<Guest10>pjotr, are you out there?
<redacted>removing `extra-special-file` from my config and reconfiguring doesn't appear to remove those special files from the filesystem
<redacted>that surprises me
<redacted>even after rebooting
<Guest10>why does main guix channel has to be updated so often?
<ieure>Guest10, Guix is a rolling release distro; that's how they work.
<Guest10>I would be OK with updates like every 24 hours, but now basically every 20 minutes there're some new commits there
<redacted>You don't have to pull every update! You can update as frequently or infrequently as you like.
<Guest10>yes, I know. I am just trying to get guix to work in a "funny" environment and testing with $guix pull
<vagrantc>you can pull to specific commits, too, if you want to reduce the churn
<SomniusX>> You don't have to pull every update! You can update as frequently or infrequently as you like.
<Guest10>is there a way to modify %default-guix-channel?
<eikcaz>I don't think you should modify that variable, you should just have your environment use a different value
<Guest10>also no functional-style modification ala (let ((x (copy %default-guix-channel)) (modify-commit x "blah")))?
<bigbookofbug>a quick question: im building a package for warpd, which has the ability to disable wayland or x support respectively. when packaging this, what are the guidelines. would it be advsable to create two seperate packages (a warpd-wayland and warpd-x, for example), or is there a way to control the output by specifying multiple outputs
<bigbookofbug>i ask because i only see specified outputs with things such as libs or docs, but haven't encountered an example regarding make flags
<sepeth>Hi there, when I run ./pre-inst-env guix system init ..., I get guix: system: command not found, hint: Did you mean `system'? Is this normal under pre-inst-env?
<eikcaz>bigbookofbug: the same repository produces two binaries? I would just put them in one output. The worry is that you would polute the user's PATH, but I don't think 1 binary -> 2 binaries for one package is worth the extra work to split outputs
<bigbookofbug>eikcaz: that makes since. i think its a single binary, but the make flag allows the removal of uneccesary build inputs. for example, on wayland you don't need to pull in x depends, and vice-versa for x
<bigbookofbug>its not a huge package so i might just be nitpicking it, but i'll build with both x and wayland enabled and see if that causes any conflicts (i dont think it should)
<sepeth>FWIW, I see some failed tests, such as tests/{builders,build-utils,challenge,containers,debug-link}.scm.
<sepeth>Oh, solved, I ran the ./pre-inst-env command in a new tab without guix shell.
<huguix>hi! I'm having some trouble getting some kernel module options to be loaded. I can do it via the `kernel-arguments` field of my operating system declaration, so my question is not really crucial, but I'd like to figure out how to do it "via modprobe" too
<huguix>I was under the impression this should work:
<peanuts>"gist:e88af751bd6a21948202e816a7edbbb1 ? GitHub"
<huguix>for reference, I'm trying to follow this solution to a problem I'm having with my (non free) wireless card driver
<peanuts>"rtw89_8852be network card ejects randomly ? Issue #240 ? lwfinger/rtw89 ? GitHub"
<huguix>if I set the options using kernel-arguments, the modprobe commands do list the options, so it's working fine
<huguix>but not if I try to do it by making the config files as in the gist I sent
<bigbookofbug>which guix package would package the "ft2build.h" header? i suspected freetype, but using it as an input, im still running into errors with the header not being found when trying to build warpd for x support
<huguix>bigbookofbug maybe try guix locate ?
<huguix>guix locate says it's indeed freetype
<eikcaz>Guest10: I think pepole usually use (cons (my-channel...) %default-guix-channel), but it sounds like you just want to freeze your guix, in which case, use the output of guix describe --format=channels
<eikcaz>as in, use the output of that guix invocation instead of %default-guix-channel
<PotentialUser49>is anyone here familiar with setting up an authenticated channel? I've made one and I can see that "guix git authenticate" properly authenticates my introductory commit but then fails to authenticate subsequent commits claiming they are "not signed by an authorized key". The key it outputs in the error message matches what I see when I run "git
<PotentialUser49>verify-commit HEAD".
<PotentialUser49>And just to be clear, there is only one commit after my introductory commit (so two commits total) so I know I'm looking at the right one
<attila_lendvai>ACTION dials civodul
<attila_lendvai>PotentialUser49, that's a bug that has wasted quite a lot of my time
<attila_lendvai>PotentialUser49, in short: the guix git authenticate only checks the *second* commit. if the first one is not properly signed, or with the wrong key, then it's accepted as authenticated regardless. if it takes some time for you to record the second commit, then you stand there baffled why the second one has problems.
<attila_lendvai>by first i mean the designated channel intro commit
<PotentialUser49>I'm quite confused now. I made a channels and manifest file and tried to use time-machine to set up a shell pulling from my channel and it succeeded.
<PotentialUser49>I would think it would fail if one of my commits wasn't signed correctly
<PotentialUser49>I've used "git verify-commit" on both of my commits and they're both signed with the same key
<PotentialUser49>which is the same key the error message says is an authorized key
<attila_lendvai>PotentialUser49, hrm. this could be a different, albeit similar issue.
<attila_lendvai>IOW, the channel intro commit is accepted as authenticated, regardless of keys and/or signatures.
<attila_lendvai>if you make an error with the setup, then it only fails once there are two commits in your channel. but i'm not sure this explains what you're seeing.
<PotentialUser49>I'm just confused as to how to determine if I've actually got this working. My repo is hosted on a private Gitlab instance and I can see in the web UI all of the commits are signed and like I said I can see they're signed when using "git verify-commit", and "guix time-machine -C channels.scm -- shell -m manifest.scm" works with custom packages
<PotentialUser49>defined in my channel. The only time I ever see a failure is if I clone the channel repo and try to run "guix git authenticate"
<PotentialUser49>and in my channels.scm I do the whole make-channel-introduction thing so I would think it would be needing to authenticate
<attila_lendvai>PotentialUser49, oh, so, do i read you right? guix pull works, even with two commits in your channel? and the only failure is running `guix git authenticate` in a local git checkout?
<PotentialUser49>guix pull -C channels.scm fails as well
<PotentialUser49>but when I use that same exact channels.scm file in guix time-machine -C channels.scm -- shell -m manifest.scm it succeeds
<attila_lendvai>PotentialUser49, did you force push this repo? there may be some local caches that interfere...
<PotentialUser49>so time-machine succeeds, but pull and authenticate both fail
<PotentialUser49>I don't think I did? Is there a way to check on that?
<PotentialUser49>For what it's worth, the machine I'm running this all on right now is not the same one I pushed the commits from
<attila_lendvai>i think they are in ~/.cache/guix/checkouts/ and ~/.cache/guix/authentication/
<attila_lendvai>PotentialUser49, you would remember, because you need to run `git push -f` to rewrite git history.
<PotentialUser49>~/.cache/guix/authentication/channels/ only has guix and guix-past
<PotentialUser49>ok I definitely did not do that
<attila_lendvai>PotentialUser49, and you have added your key to the `keyring` branch, right?
<PotentialUser49>Is there some specific formatting to ensure that guix finds the key file in the keyring branch? I just named it my_first_name-AAAAAAAA where "AAAAAAAA" is the first 8 characters of the fingerprint
<PotentialUser49>the only other thing I can think of is the fingerprint in my commits doesn't have spaces whereas in the .guix-authorizations file spaces separate every 4 characters, but I didn't think that mattered
<attila_lendvai>PotentialUser49, i doubt that it would matter, and also silently cause an issue... but if you find that to be the source of your problem, then that'd be a welcome bug report.
<PotentialUser49>I'd have to make a new repo to check, but I doubt it considering the formatting of keys in the official guix channel and commits matches mine
<PotentialUser49>It's just odd to me that guix pull fails but guix time-machine succeeds when my understanding is that they both authenticate
<attila_lendvai>sounds strange indeed
<PotentialUser49>At this point I think I'm just going to spin up a new machine with a clean install of guix and see if it fails in the same way. Like I've said, it's just weird that time-machine succeeds and pull fails on the same channels.scm