progfolio
commented
8 months ago Thanks for taking the time to fill out a ticket. Please share the full text of the init file you are using.
Closed 0x08088405 closed 8 months ago
progfolio
commented
8 months ago Thanks for taking the time to fill out a ticket. Please share the full text of the init file you are using.
0x08088405
commented
8 months ago Sure, I've stripped it of personalisations to make it less confusing, and tested that it still happens.
Additionally, these, if they may be useful:
progfolio
commented
8 months ago I'm unable to reproduce the issue given the test you provided on Emacs 29.1 or Emacs 30.
I've stripped it of personalisations to make it less confusing
The issue may be due to something in here, but it's hard to say without seeing any of it.
0x08088405
commented
8 months ago I think you misunderstand, when I said
I've stripped it of personalisations to make it less confusing, and tested that it still happens
I meant that I wiped my user-emacs-directory, put in that early-init-file and user-init-file that I also posted here, and still hit the same issue. I was trying to reduce it to not be related to something else, and I posted a version where I still encounter this problem. Just tried again to be sure with those exact contents and nothing else in my user-emacs-directory and I still get the exact same output.
progfolio
commented
8 months ago Understood. Unfortunately I'm still not able to reproduce on my end. I'll see if there's another test case I can provide to get more info.
progfolio
commented
8 months ago My hunch is that the heuristic for getting the date versioning for the packages is failing somehow. I've pushed a change to include the version being compared against in the error message. Would you mind testing from scratch again and sharing the failure messages from the elpaca-log buffer?
ryunix
commented
8 months ago How about adding (elpaca-wait) after (elpaca `(seq :build ,(+elpaca-seq-build-steps)))?
progfolio
commented
8 months ago How about adding
(elpaca-wait)after(elpaca `(seq :build ,(+elpaca-seq-build-steps)))?
That shouldn't effect the versions of the dependencies which are failing.
ryunix
commented
8 months ago That shouldn't effect the versions of the dependencies which are failing.
I'm sorry for the incorrect comment. :bow:
I'm reporting that I couldn't reproduce the issue in my environment either. I'm using Emacs 29.1 on Gentoo too. The versions matched, except for the build date.
0x08088405
commented
8 months ago Installed version nil is lower than YYYYMMDD, for both of them.
magit failed Failed dependencies: (git-commit) 25.622426
git-commit failed transient installed version nil lower than min required 20231204 25.628268
magit-section failed dash installed version nil lower than min required 20221013 25.990285Installed version nil is lower than YYYYMMDD, for both of them.
Thanks. That confirms my hunch.
We need to figure out why elpaca--date-version is not returning anything for those packages. A good first step would be to bypass the function altogether to see if the git command used is working. Let's use dash as our example.
Can you please:
$ELPACA-DIR/repos/dash/) in a terminal.git log -n 1 --format=%cd --date=format:%Y%m%d.%sWhat output do you get from that command?
0x08088405
commented
8 months ago Okay, that was a really good guess. I immediately knew why this was broken for me, and not you. Check this out:
gpg: Signature made Tue 23 Jan 2024 06:33:43 CST
gpg: using RSA key AB0DD41003567A55A0B3B70F205AB54A5D5D8CFF
gpg: Can't check signature: No public key
20240123.1706013217This is because of log.showSignature=true in my ~/.gitconfig. I temporarily removed that and the rest of magit compiles and loads and everything is happy. One could force that flag like git -c log.showSignature=false log ..., dunno if that's the best way, usually I see people use libgit2 (like magit does).
progfolio
commented
8 months ago Thanks for the details. That makes sense. I've pushed a branch with a potential fix so you won't have to workaround this. Would you mind executing the following test case on your machine and sharing the results?
| elpaca | 09a94ca HEAD -> fix/date-version, origin/fix/date-version |
| installer | 0.6 |
| emacs | GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-02-03 |
| git | git version 2.43.0 |
usually I see people use libgit2 (like magit does).
I'm trying to minimize elisp dependencies for this package, but I'll note that down to weigh out the tradeoffs. Thanks for the suggestion.
0x08088405
commented
8 months ago
(elpaca (` (seq :build (, (+elpaca-seq-build-steps)))))
I imagine this part of the test is meant to be (elpaca `(seq :build ,(+elpaca-seq-build-steps))) like in my above user-init-file, otherwise that elisp gets a classic "wrong argument type: symbolp" et cetera, so I edited that part of the expression. Here are the results, and I did check to put log.showSignature=true in my ~/.gitconfig beforehand;
| elpaca | 00ce5bb HEAD -> master, origin/master, origin/HEAD |
| installer | 0.6 |
| emacs | GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, cairo version 1.18.0) of 2024-02-08 |
| git | git version 2.43.0 |
progfolio
commented
8 months ago viri @.***> writes:
(elpaca (` (seq :build (, (+elpaca-seq-build-steps)))))
I imagine this part of the test is meant to be (elpaca `(seq :build , (+elpaca-seq-build-steps))) like in my above user-init-file, otherwise that elisp gets a classic "wrong argument type: symbolp" et cetera, so I edited that part of the expression.
Yes. That looks like it's an elisp pretty printer bug or limitation. Thanks for pointing that out. I'll look into it.
Here are the results, and I did check to put log.showSignature=true in my ~/.gitconfig beforehand; elpaca-log: "#unique" " seq finished ✓ 2.684 secs 13.568629 elpaca finished ✓ 2.995 secs 13.876013 compat finished ✓ 5.071 secs 17.447952 with-editor finished ✓ 6.044 secs 18.308732 transient finished ✓ 6.613 secs 19.018036 dash finished ✓ 6.975 secs 19.279611 git-commit finished ✓ 8.087 secs 20.342451 magit-section finished ✓ 8.613 secs 20.923314 magit finished ✓ 32.343 secs 43.224765 "
Test Env
Elpaca 09a94ca HEAD -> fix/date-version, origin/fix/date-version installer: 0.6 emacs-version: GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, cairo version 1.18.0) of 2024-02-08 git --version: git version 2.43.0
Looks like everything is working as expected. I've merged the change into the master branch. Thanks again for testing.
Confirmation
Elpaca Version
Operating System
Gentoo GNU/Linux amd64
Description
Garbage issue title, not sure what to call this, sorry. Trying out elpaca again with a blank
user-init-file. I try to installmagit, ran into theseqissue, did the pinned workaround. These errors remain:According to
elpaca-info, I havedash2.19.1 13f3fcd andtransient0.5.3 85ecbc6 installed. Now I admit I don't yet write elisp packages and don't know how the development versioning works, but those commits are ahead of the calendar dates it's indicating, so I'm not sure what the complaint actually is.