all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Gregor Zattler <telegraph@gmx.net>
To: Matt Armstrong <matt@rfc20.org>, 59064@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	[thread overview]
Message-ID: <87y1so1fso.fsf@no.workgroup> (raw)
In-Reply-To: <87k0492e0i.fsf@no.workgroup>

Hi Matt, emacs developers,
* Matt Armstrong <matt@rfc20.org> [2022-11-05; 17:04 -07]:
> Gregor Zattler <telegraph@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
--
 -... --- .-. . -.. ..--.. ...-.-





  parent reply	other threads:[~2022-11-06 11:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-05 23:11 bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo) Gregor Zattler
2022-11-06  0:04 ` Matt Armstrong
2022-11-06 11:30 ` Gregor Zattler [this message]
2022-11-06 14:59   ` Gregor Zattler
2022-11-06 18:17     ` Matt Armstrong
2022-11-06 18:38       ` Philip Kaludercic
2022-11-06 19:05         ` Eli Zaretskii
2022-11-07  8:52           ` Philip Kaludercic
2022-11-07 17:24             ` Matt Armstrong
2022-11-06 21:35       ` Gregor Zattler
2022-11-07 17:19         ` Matt Armstrong

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y1so1fso.fsf@no.workgroup \
    --to=telegraph@gmx.net \
    --cc=59064@debbugs.gnu.org \
    --cc=matt@rfc20.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.