From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregor Zattler Newsgroups: gmane.emacs.bugs Subject: bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo) Date: Sun, 06 Nov 2022 12:30:15 +0100 Message-ID: <87y1so1fso.fsf@no.workgroup> References: <87k0492e0i.fsf@no.workgroup> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25723"; mail-complaints-to="usenet@ciao.gmane.io" To: Matt Armstrong , 59064@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 06 12:31:43 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ordsM-0006UF-FD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Nov 2022 12:31:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ordrm-0001fl-5p; Sun, 06 Nov 2022 06:31:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ordrj-0001fO-6q for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 06:31:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ordri-0006YP-JE for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 06:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ordri-0007Kt-F9 for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 06:31:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87k0492e0i.fsf@no.workgroup> Resent-From: Gregor Zattler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2022 11:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59064 X-GNU-PR-Package: emacs Original-Received: via spool by 59064-submit@debbugs.gnu.org id=B59064.166773423528164 (code B ref 59064); Sun, 06 Nov 2022 11:31:02 +0000 Original-Received: (at 59064) by debbugs.gnu.org; 6 Nov 2022 11:30:35 +0000 Original-Received: from localhost ([127.0.0.1]:58836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ordrH-0007KC-6f for submit@debbugs.gnu.org; Sun, 06 Nov 2022 06:30:35 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:47863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ordrC-0007Jt-2x for 59064@debbugs.gnu.org; Sun, 06 Nov 2022 06:30:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1667734221; bh=uS5goWmQaziP3ysXDXBKdE9nqeUQMzP4kYGvUWFHX6A=; h=X-UI-Sender-Class:From:To:Subject:Date; b=g6yfj6e2370glBAYX+Qov+F/0egrtqxPb7FC3Pct8MVi4HWI+fyvP/KUcPCnCE/84 avO6u7YzUD11hpVZ7sZAtvbYeVDjs2th5dQPr2dwxGuKszctxkiWHlp9lgzQYcV8rr VuK/gvV4Xj/bh/swbCetn9Ga5d69WjYFFD3nm7VQGFsFCNjYYY1pXe5p/50UUlWWnU w+3lDTv8NtPN8ufyUWBRXpSQqmgSQUN7gZG6C1ETahY9xNmmyzRaJdJprnt8D5nfgm yKDhTIoRH/h3L87zaadYtYhIe1VrPd6TMCxMRj0iXoedg+QECDiUR3GQ3D/djXyGQo Vt6EZtYU/HA2Q== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from localhost ([95.90.239.135]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvK4f-1p8tgq1mT3-00rJEw; Sun, 06 Nov 2022 12:30:21 +0100 X-Provags-ID: V03:K1:a5POdJ73liZbIitjotKAYsT/XQTc8nc9lzxg+W6jFkuT+jIxAxY /6egJGwrJucuCAtrK8JGdG4nqqcWdp7NquoNlmXg2pwrTA7BCtoOHQybbbo5ubdLCEnXwZ7 7ArLlUwEk2vl9voz/gON2qFpZ1+j3IcZ9DCKGkIgdrLpyWNJfyGEFe/gShKiROXt7x6YL2n y3JSY6543R0dvtq50D/HA== UI-OutboundReport: notjunk:1;M01:P0:rDUwgD7bqSs=;0xrm9gb9J4wOoQjV+TJ3sm71qoJ hqGu0U+OjfqhnczO7yLu4Nvut6jTUeV+NuR4IyKVDw54zzRzo92ovaerizzWKVr0tBipbULvP dVn1+pHC7FloO91CZLkoFr9/YPn/e/dpH0Dxu10+aAquOtIVo3xxzjnHBzbEpFJ9dH8KqWq7X StL05GtQdAsVpf0VcmQcgwYvhKRoDvR1H/qsyYMC+t63EHgKWES4cBsLDzjepfvKK8wR3ZPfu t55i1NfzzI5Po933CeyVtqJ1beiXWhaPBfUR4g9PcqBVh/CeCb4jneBT9KsVsPuw2i3t1MmHe ByO2VXdgQeH2NDQwX2r02PpxdjW3AJFs/viTO9gEJXr+J4nfF/il8eG4rc+st0chtEefXaPyc dTVseU5MD+BH2+Ti4Nn8Ac/Vd22SuZEr1jWglyNrl999SxYkaSFPPNXOhHKSq8MxKmeH6JPwi R97Z4u5GzPdvdotj7gIKy0+iN3mPzRo90Pz3AImZZd+SNFvoXTy3j8melvEsHMew+YUxjjqB2 FA2OBwn3it4OCwSFOoEKYz/c3yuGe8PIotB9M2+TmzKXOqW2spDlmAHz7lclrtx45zsIqFS2M Ugrn0w7Cl+P9fbyE7DIOnF6O/WYCRU6ZaYPpcOCdCNyM8k+lRq9I9OxV5WQGw0gH5BElHLYxZ l5QIGTuiPTRGbuOgOe+lUdbI3tpYJUfwf7LtiITG6+ICrm45oBne/1PE3xDL/CbOThmHhwvq9 Vs5OMTy2OGnrwO3RBU15i1ybHd3e//uyi8vm9WpG7Urh2S+8s95p5FPUbzzjOF7Hf3JVO70P X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247202 Archived-At: Hi Matt, emacs developers, * Matt Armstrong [2022-11-05; 17:04 -07]: > Gregor Zattler 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=3D1 -j 1" to get the most default build process. All test= s >> 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 re= gular 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=3D-Og -g3' 'CXXFLAGS=3D-Og -g3' --enable-checking=3D= 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 =2D- -... --- .-. . -.. ..--.. ...-.-