From: Kyle Meyer <kyle@kyleam.com> To: No Wayman <iarchivedmywholelife@gmail.com> Cc: wtd@pobox.com, marcowahlsoft@gmail.com, emacs-orgmode@gnu.org, eibhear.geo@gmail.com Subject: Re: Switching to new Git repositories Date: Thu, 23 Sep 2021 18:24:19 -0400 [thread overview] Message-ID: <87a6k33p7w.fsf@kyleam.com> (raw) In-Reply-To: <87y27nt29u.fsf@gmail.com> On 09/23/21 17:17:48 -0400, No Wayman wrote: >> Sounds like a weird issue. I don't think this 9.5-dev tag is >> something from the Org repo. > > There is a bug in mk/targets.mk introduced by 61336f80dc. Quoting that commit message for context: mk/targets.mk: Add version fallback for tag-less repos * mk/targets.mk (ORGVERSION, GITVERSION): Get version from lisp/org.el header if it can't be retrieved from git-describe. As of elpa.git's ee03829f90 (Finalize the new master branch, 2020-12-14), org-release and org-git-version are empty strings in https://elpa.gnu.org/packages/org-*.tar files. This is because the new setup executes `make autoloads info' in an elpa.git worktree with an Org branch checked out, but elpa.git of course doesn't have Org's release tags. Maintaining the org.el version header has been a point of contention in the past [1], but the header has been there for a while now. Use it to avoid the above elpa.git issue. In the case of the master branch, the org-release value generated in a tag-less repo will have a different version than the one from a regular repo because org.el's version header has a "-dev" suffix, but that's still better than an empty version. [...] > As others have pointed out, the new repository does not have tags. > As a fallback, org.el's version is read in it's header. > However, it looks like Kyle forgot to trim that string so we get > ORGVERSION set to "9.5-dev" instead of "9.5". I of course can't say for sure, but based on my commit message (in particular the last paragraph), it sounds like I was aware of the discrepancy but didn't realize it'd cause the downstream "Invalid version syntax" issue mentioned by Bill in <alpine.DEB.2.22.394.2109231400490.7770@shell3.miskatonic.org>. > This causes `org-version' to return an incorrect version string. > > The attached patch addresses the issue in the makefile. Thanks. > Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos > > * mk/targets.mk (ORGVERSION, GITVERSION): properly generate ORGVERSION. I think it'd be better to say something more specific about the change rather than say "properly" and assume the reader knows what the writer has in mind. > Fix bug introduced 61336f80 which caused ORGVERSION to be generated as > "Major.Minor-dev" instead of "Major.Minor" in tag-less repos. Please say what the bug is. Can you give a sparse outline of the call chain for the error mentioned in Bill's message? > - ORGVERSION := $(shell $(BATCH) --eval "(require 'lisp-mnt)" \ > - --visit lisp/org.el --eval '(princ (lm-header "version"))') > - GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD) > + ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \ > + --visit lisp/org.el --eval '(princ (lm-header "version"))')) > + GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)) It looks like you've unintentionally added a ')' to the end of the GITVERSION line. Another approach would be to update org.el's version to contain something that still signals "-dev" but won't trigger the "Invalid version syntax" (which, based on grepping the Emacs repo, is signaled by version-to-list). But given that in the current setup a clone with tags wouldn't use the header version, stripping -dev for consistency sounds like the way to go.
next prev parent reply other threads:[~2021-09-23 22:25 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-20 4:37 Bastien 2021-09-20 9:08 ` Marco Wahl 2021-09-20 9:16 ` Timothy [not found] ` <87ilyvtwma.fsf@gnu.org> 2021-09-20 10:30 ` Marco Wahl 2021-09-25 13:50 ` Bastien 2021-09-20 9:27 ` Bastien 2021-09-20 10:14 ` Eric S Fraga 2021-09-20 10:20 ` Bastien 2021-09-20 10:38 ` Eric S Fraga 2021-09-23 10:07 ` Éibhear 2021-09-23 15:17 ` Nick Dokos 2021-09-23 17:40 ` Colin Baxter 2021-09-23 18:54 ` Marco Wahl 2021-09-23 18:06 ` William Denton 2021-09-23 18:23 ` Éibhear 2021-09-23 19:05 ` Colin Baxter 2021-09-23 19:07 ` Marco Wahl 2021-09-23 21:17 ` No Wayman 2021-09-23 22:24 ` Kyle Meyer [this message] 2021-09-23 23:13 ` No Wayman 2021-09-24 1:48 ` Kyle Meyer 2021-09-24 3:21 ` William Denton 2021-09-24 7:50 ` Eric S Fraga 2021-09-25 14:57 ` Bastien
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87a6k33p7w.fsf@kyleam.com \ --to=kyle@kyleam.com \ --cc=eibhear.geo@gmail.com \ --cc=emacs-orgmode@gnu.org \ --cc=iarchivedmywholelife@gmail.com \ --cc=marcowahlsoft@gmail.com \ --cc=wtd@pobox.com \ --subject='Re: Switching to new Git repositories' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).