GNU bug report logs - #59064
29.0.50; build problem git worktree linked to main worktree (repo)

Previous Next

Full log

View this message in rfc822 format

From: Gregor Zattler <telegraph <at> gmx.net>
To: Matt Armstrong <matt <at> rfc20.org>, 59064 <at> debbugs.gnu.org
Subject: bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)
Date: Sun, 06 Nov 2022 12:30:15 +0100

Hi Matt, emacs developers,
* Matt Armstrong <matt <at> rfc20.org> [2022-11-05; 17:04 -07]:
> Gregor Zattler <telegraph <at> gmx.net> writes:
>> Dear Emacs developers,
>>
>> building Emacs from sources in a detached linked worktree[1]
>> linked to a main worktree[1] fails, because necessary
>> -by.el, -wy.el files are not generated as described in
>> admin/grammars/Makefile for targets `bovine` and `wisent`.
>> Instead while these files are generated error messages "Args
>> out of range: "master", 0, 7" are shown and the respective
>> files are not generated.
>
> These sorts of lisp level "Args out of range" errors during the build
> are typical of a need to run "make bootstrap" to rebuild much more than
> is usually rebuilt.  With respect to lisp compilation the build system
> takes a few short cuts for expediency sake, and sometimes requires this
> extra help.
>
> See the INSTALL.REPO file in the root of the git tree for more
> information about this.
>
> At the extreme, you can tell git to delete all files not under version
> control with this command:
>
>     git clean -dfx
>
> This is what I do when I want to get the tree into the same state it
> would be if I deleted it entirely and re-cloned it.
>
>
>> But I found out that building instead from sources in a
>> linked worktree linked to a bare repository[1] works as
>> expected.
>
> This may have been because re-cloning the worktree was akin to the git
> clean command above?
>
> (however, what you say next raises doubts...)

All experiments were done in freshly cloned main worktrees,
freshly added linked worktrees from freshly cloned main
worktrees and the like.

>> In order to rule out any misconfiguration on my side, I installed
>> Emacs build dependencies on a minimal installation of Debian/bullseye,
>> cloned the emacs git repo with a freshly created and otherwise
>> unconfigured user.  To trigger the build process this user then issued
>> only "make V=1 -j 1" to get the most default build process.  All tests
>> were made with freshly cloned repos respectively freshly generated git
>> worktrees created from those pristine git repos.
>>
>> The difference between a linked worktree and its main
>> worktree is in the .git directory only, as this diff shows:
>> $ diff -aNurx.git/* emacs2 emacs2-worktree
>> File emacs2/.git is a directory while file emacs2-worktree/.git is a regular file
>
> Well that is a pretty compelling argument.
>
> I have just created a fresh worktree from a non-bare git repo using:
>
>     git worktree add ../b59064 scratch/matta/master
>
> The "scratch/matta/master" tree is close to the current "master" branch.
>
> Then in the ../b59064 repository, "cat .git" produces:
>
>     gitdir: /home/matt/git/e/emacs/.git/worktrees/b59064
>
> In this directory a clean build works fine, so I have not yet reproduced
> the problem.

I now see, I should have showed my command line, I do
*detached* linked worktrees:

git worktree add -d ../emacs2-worktree

This is, because I do not develop, I just want different
builds in order for the possibility to use an older build,
if something goes wrong with a new one.

In a detached linked worktree the build fails as described.

In a not-detached linked worktree produced like so:

git worktree add -f ../emacs2-master master

the build process does *not* fail.

*So this bug report is about detached linked worktrees only.*

(Now it's even more likely this does not bother emacs devs).

>> While investigating, I learned that the build process embeds
>> the repository revision into the Emacs binary.  This is the
>> case if Emacs is build in a linked worktree linked to a bare
>> repository, as the template from emacs-report-bug shows.
>
> In my case, the built Emacs successfully above figures out the
> repository revision.  For example, this is copied out of the buffer
> created by M-x report-emacs-bug:
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.34, cairo version 1.16.0) of 2022-11-05 built on naz
> Repository revision: ce917027c69f77b8dd6eb2052b018593f36a393f
> Repository branch: scratch/matta/master
> System Description: Debian GNU/Linux bookworm/sid
>
> Configured using:
>  'configure 'CFLAGS=-Og -g3' 'CXXFLAGS=-Og -g3' --enable-checking=yes
>  --enable-check-lisp-object-type --with-pgtk'
>
>
>> If you have further specific questions, I'm happy to help as
>> far as my very limited knowledge allows.
>
> You reproduced this on a fresh Debian/bullseye system, presumably run in
> a VM?

No, this is a Microserver used for backup purposes.

> I am on Debian Testing, updated about a week ago.  So that
> is one difference.
>
> I think the next thing to do is to figure out if either:
>
> a) This can reproduce this on a Debian/testing or Debian/sid system.  Is
> it easy for you to spin up a VM to do this?  If so, it would be useful
> to know if this is related to the Debian version, as you are likely to
> use steps similar to what you've already done.

I used to use VirtualBox, but since this is not part of
Debian stable, I will use this opportunity to learn how to
use KVM.  This will take some time, I will report back.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.