Przemysław Kryger <pkryger@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 79188) by debbugs.gnu.org; 8 Aug 2025 11:07:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 08 07:07:32 2025
Received: from localhost ([127.0.0.1]:37414 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ukKwd-0004cS-8S
for submit <at> debbugs.gnu.org; Fri, 08 Aug 2025 07:07:32 -0400
Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:44089)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <pkryger@HIDDEN>)
id 1ukKwX-0004c4-L0; Fri, 08 Aug 2025 07:07:29 -0400
Received: by mail-wm1-x331.google.com with SMTP id
5b1f17b1804b1-459ebb6bbdfso13197535e9.0;
Fri, 08 Aug 2025 04:07:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1754651239; x=1755256039; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:cc:references:in-reply-to
:subject:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=ZQOFB19jutiNe16VqKa4qnB5yIBLOl7aFrsZcPVe+J8=;
b=DvT6mZ3j0sBtEtm3LppUwCe3AoT3R1SLJ3XmYkhCGakLJKs3LB1r0hcQEtYKj1g7aC
G0rUGiG8FS2C5QzhgIXlhY7ztASZX9444PVjoeF9413/O6tWh5iUDN4tp4PPPoN2p1fA
EFLWQI82WJUFXtys35p7RsjXwATWnuZGkK35oYmARGUjddKNK1kE3W9tUC0NzQFu/tum
Ai3L+4VPSCQGuOwHG2qwNRrXGS4g9ZubDAcyCeV4zDjE04pkgbUYPpgDs9tvTGaMIB0u
GOGPAdn1Uw+pt6R/uyqnf/z7kQVTkqNIOt1gsDmIGL70IQ6G5k3VKzQGR3KFx6DQxhVj
S26A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1754651239; x=1755256039;
h=mime-version:user-agent:message-id:date:cc:references:in-reply-to
:subject:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=ZQOFB19jutiNe16VqKa4qnB5yIBLOl7aFrsZcPVe+J8=;
b=YXWrIFGQ1GThwGUMXFUfvpfjVdk7f2y16JpZTviKjdasjcem0E7kLFCRTs6D45PGFB
VX+MpLPM1P/YdG7Ilt0jveZWeQLNBFiMXweSyRpY68Xif/1OBR191dTwdSg2g9yDRIX9
LsxQnuJLVY2rJIwMWQRJbDAo6udayfisEOIQZRn6l/4WrID8sKKyqVzeNZYGxCcgSF70
0jwH3L4EW8VbuQf5lUqsNCwiBPmAE8EvTzwe7oi+Abt28StX1Nak1iEOfjF8SB9zfHh/
LTOAC80gi8wzz46FnYWWvNIv87MyMUeTAIR/az7weaE+22+N6M5DSOXnOaKIwjM3HqHy
85qg==
X-Forwarded-Encrypted: i=1;
AJvYcCWvfN+CVlYu44WdAtA1XaxPv5v4AiMnzy5BDQRZfMJiCAEO75201PFBUGGAy409IbaXenhprZn/@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxjGLWzpsK2bK7vs1bEw1UPuWXq2NBcZS19XZneZinP3IKR4O/K
/Dpk2x2Zpm8uxyde5Ts6VL4U5qLFX+79CCpzUYbl3PuY2Q0m3JLt2OLeLtCvliBi
X-Gm-Gg: ASbGnctdaxBR99FjGBrYULs1UdCxSENkEU42yz3TSFgDENFMnpCm4q2f1C+wMgMzVa2
HcV51KTwH66lCd+Zx/CTHgDcElvrvkqKHiIES3YezjFG+e6CC1XGbr6/q034VH7BKPk9xNoX4Xo
UNCnh6XWQ1jjplo6m2rBVZK7FTCeLcl635IOIrK1pveQ6ArRHvErvBiGpqtVumYt6sETZQazq6k
j7LPTZfDwdUY1OVIm894O3Ioe49qmZNeRu8O/lo9Dtv48MVkX8meFOUEOQVl8DEmQ0G94XmxVw2
mhp2WeM13wVPtoAfDMFbAfBSzKYKO1nymTjLgXbmG7ET6OcaSd9a1x92XoLfk2V/tpmbU6eFNSR
D/pQaYLCiMlduFWA9L38KwRYPae+Qq1rp3iHa3y3rxkvddIWGm1RlVqkQLhzYYEI=
X-Google-Smtp-Source: AGHT+IEJfEWQyHvFMRGKyKCLfbUiEmHpRzVQDMJQn9nc3HGSpNUl7OGFC2Rr8R0wK2DgMCg+7CcCsg==
X-Received: by 2002:a05:600c:15ca:b0:459:dde3:1a55 with SMTP id
5b1f17b1804b1-459f5507f88mr13471325e9.24.1754651238532;
Fri, 08 Aug 2025 04:07:18 -0700 (PDT)
Received: from Przemyslaws-MacBook-Air.local
([2a00:23c8:b1c:3801:b8d6:64db:4c9b:7a99])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-459e5862fd9sm141886855e9.16.2025.08.08.04.07.17
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 08 Aug 2025 04:07:17 -0700 (PDT)
From: =?utf-8?Q?Przemys=C5=82aw_Kryger?= <pkryger@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
In-Reply-To: <CAPXM7TwOm9fF_nUsAZoDgrchp4Eg_991NmuBZgN2VCqjsUuShQ@HIDDEN>
(=?utf-8?Q?=22Przemys=C5=82aw?= Kryger"'s message of "Thu, 7 Aug 2025
17:53:00 +0100")
References: <m2ectn9xif.fsf@HIDDEN>
<87jz3f2svk.fsf@HIDDEN> <m2cy97w04t.fsf@HIDDEN>
<CAPXM7TwOm9fF_nUsAZoDgrchp4Eg_991NmuBZgN2VCqjsUuShQ@HIDDEN>
Date: Fri, 08 Aug 2025 12:07:14 +0100
Message-ID: <m2a54avzq5.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79188
Cc: 79188 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
tags 79188 + patch
quit
Przemys=C5=82aw Kryger <pkryger@HIDDEN> writes:
>> That seems reasonable, but in that case we should be able to reproduce
>> the issue with a more simple example (especially one that doesn't involve
>> use-package, MELPA and missing dependencies). [...]
I managed to reproduce the issue with
https://github.com/pkryger/basic-stats.el, which has no extra
dependencies. I could reproduce all the issues I described in previous
message (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D79188#11).
In addition I noticed, that `package-vc-upgrade' doesn't work as
well. This one was trying to pull inside the package install directory,
i.e, under `packgage-user-dir'.
>> This should fix the first issue, but it probably won't change anything
>> about the latter:
>>
>> diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
>> index db12c76133e..f2c7c460f6d 100644
>> --- a/lisp/package/package-vc.el
>> +++ b/lisp/package/package-vc.el
>> @@ -549,7 +549,14 @@ package-vc--unpack-1
>> ;; FIXME: Compilation should be done as a separate, optional, s=
t=3D
> ep.
>> ;; E.g. for multi-package installs, we should first install all=
=3D
> packages
>> ;; and then compile them.
>> - (package--compile new-desc)
>> + (package--compile
>> + (if lisp-dir
>> + ;; In case we are installing a package from a local
>> + ;; checkout, we want to compile the checkout, not the
>> + ;; redirection!
>> + (package-desc-create :dir lisp-dir)
>> + new-desc))
>> +
>> (when package-native-compile
>> (package--native-compile-async new-desc))
>> ;; After compilation, load again any files loaded by
>>
>
> I don't have lisp/pakcage/package-vc.el, but I changed the file name to
> lisp/emacs-lisp/packgage-vc.el and the patch applied cleanly.
>
> [...]
>
> After I repeated the experiment the package installed with just
> `package-vc-install-from-checkout' (as described above) and
> helm-projectile.elc file has been produced into package source
> directory.
Based on that work I developed a new patch. With both of the attached
patches applied I was able to run `package-vc-rebuild' and
`package-vc-reinstall' on the aforementioned package basic-stats and
observed that *.elc files were created in the source directory (i.e.,
the local checkout) and not in package install directory.
> A question: shouldn't the newly generated *.elc files be put in
> package install directory, just like the (non compiled) autoloads file
> is? In my - very na=3DC3=3DAFve - view this would not only remove burden
> of doubling `load-path' entries (will that happen) but would also
> allow for a complete separation of compiled files between multiple
> Emacs versions coexisting on the same machine and reusing the same
> package source directories.
While the patch attached fixes basic workflows, I wonder idea of having
*.elc in a package install directory is worth exploring. Would that
affect other functionalities? For example `load' and `require' should
just work (provided the package install directory is in front of package
source directory in `load-pat'), but what will happen with
`find-library'/`locate-library'? Are there any others?
--=-=-=
Content-Type: text/plain
Content-Disposition: attachment;
filename=0001-Compile-file-in-local-checkout-directory.patch
Content-Description: patch
From 56fa1014b1f8f2eb7f6d87304c3f31604fed48ba Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@HIDDEN>
Date: Fri, 8 Aug 2025 11:43:24 +0100
Subject: [PATCH 1/2] Compile file in local checkout directory
This partially fixes bug#79188.
* lisp/emacs-lisp/package-vc.el (package-vc--unpack-1): Compile package
in a local checkout directory when it is installed from such a
location, for example with `package-vc-install-from-checkout'.
---
lisp/emacs-lisp/package-vc.el | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index 7433fce2d89..9e118c7af02 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -546,7 +546,14 @@ package-vc--unpack-1
;; FIXME: Compilation should be done as a separate, optional, step.
;; E.g. for multi-package installs, we should first install all packages
;; and then compile them.
- (package--compile new-desc)
+ (package--compile
+ (if lisp-dir
+ ;; In case we are installing a package from a local
+ ;; checkout, we want to compile the checkout, not the
+ ;; redirection!
+ (package-desc-create :dir lisp-dir)
+ new-desc))
+
(when package-native-compile
(package--native-compile-async new-desc))
;; After compilation, load again any files loaded by
--
2.50.1
--=-=-=
Content-Type: text/plain
Content-Disposition: attachment;
filename=0002-Store-local-checkout-directory-in-autoloads-indirect.patch
Content-Description: patch
From 07596327df8bee5831003b62c811dd3fc53f2a88 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Przemys=C5=82aw=20Kryger?= <pkryger@HIDDEN>
Date: Fri, 8 Aug 2025 11:43:52 +0100
Subject: [PATCH 2/2] Store local checkout directory in autoloads indirection
* lisp/emacs-lisp/package-vc.el (package-vc--unpack-1): When installing
from a local checkout, store the value of `:lisp-dir' property of
`pkg-spec' in a "Package-spec" header in a generated autoloads
indirection file.
* lisp/emacs-lisp/package-vc.el (package-vc--pkg-spec-from-autoloads):
New function to retrieve package spec from a "Package-spec" header
from autoloads indirection file (if any).
* lisp/emacs-lisp/package-vc.el (package-vc-rebuild): Retrieve package
spec from autoloads indirection file (if any) and use it while calling
`package-vc--unpack-1'.
* lisp/emacs-lisp/package-vc.el (package-vc-upgrade): Retrieve package
spec from autoloads indirection file (if any) and use it while calling
`package-vc--unpack-1' and for `vc-pull'.
fixes: bug#79188
---
lisp/emacs-lisp/package-vc.el | 46 +++++++++++++++++++++++++++++------
1 file changed, 39 insertions(+), 7 deletions(-)
diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
index 9e118c7af02..400e648b8f5 100644
--- a/lisp/emacs-lisp/package-vc.el
+++ b/lisp/emacs-lisp/package-vc.el
@@ -508,7 +508,14 @@ package-vc--unpack-1
(when lisp-dir
(write-region
(with-temp-buffer
- (insert ";; Autoload indirection for package-vc\n\n")
+ (insert ";; Autoload indirection for package-vc\n")
+ (insert ";; Package-spec: ")
+ ;; Store the pkg-spec such that it can be reused by
+ ;; `package-rebuild' and `package-vc-upgrade' to restore
+ ;; the same conditions as were when the indirection has
+ ;; been created for the first time.
+ (prin1 pkg-spec (current-buffer))
+ (insert "\n\n")
(prin1 `(load (expand-file-name
,(expand-file-name auto-name lisp-dir)
(or (and load-file-name
@@ -589,6 +596,19 @@ package-vc--unpack-1
(declare-function project-remember-projects-under "project" (dir &optional recursive))
+(defun package-vc--pkg-spec-from-autoloads (pkg-desc)
+ "Read a \"Packcage-spec\" header from autoloads file for PKG-DESC."
+ (when-let* ((name (package-desc-name pkg-desc))
+ (autoloads (expand-file-name (format "%s-autoloads.el" name)
+ (package-desc-dir pkg-desc)))
+ ((file-exists-p autoloads))
+ (spec (with-temp-buffer
+ (insert-file-contents autoloads)
+ (ignore-errors
+ (read (lm-header "package-spec"))))))
+ (cons (symbol-name name)
+ spec)))
+
(defun package-vc--clone (pkg-desc pkg-spec dir rev)
"Clone the package PKG-DESC whose spec is PKG-SPEC into the directory DIR.
REV specifies a specific revision to checkout. This overrides the `:branch'
@@ -756,7 +776,10 @@ package-vc-upgrade
;;
;; If there is a better way to do this, it should be done.
(cl-assert (package-vc-p pkg-desc))
- (letrec ((pkg-dir (package-desc-dir pkg-desc))
+ (letrec ((pkg-spec (package-vc--pkg-spec-from-autoloads pkg-desc))
+ (pkg-dir (package-desc-dir pkg-desc))
+ (source-dir (or (plist-get (cdr pkg-spec) :lisp-dir)
+ pkg-dir))
(vc-flags)
(vc-filter-command-function
(lambda (command file-or-list flags)
@@ -764,18 +787,22 @@ package-vc-upgrade
(list command file-or-list flags)))
(post-upgrade
(lambda (_command _file-or-list flags)
- (when (and (file-equal-p pkg-dir default-directory)
+ (when (and (file-equal-p source-dir default-directory)
(eq flags vc-flags))
(unwind-protect
(with-demoted-errors "Failed to activate: %S"
- (package-vc--unpack-1 pkg-desc pkg-dir))
+ (let ((package-vc-selected-packages
+ (if pkg-spec
+ (cons pkg-spec package-vc-selected-packages)
+ package-vc-selected-packages)))
+ (package-vc--unpack-1 pkg-desc pkg-dir)))
(remove-hook 'vc-post-command-functions post-upgrade))))))
(add-hook 'vc-post-command-functions post-upgrade)
(with-demoted-errors "Failed to fetch: %S"
(require 'vc-dir)
(with-current-buffer (vc-dir-prepare-status-buffer
- (format " *package-vc-dir: %s*" pkg-dir)
- pkg-dir (vc-responsible-backend pkg-dir))
+ (format " *package-vc-dir: %s*" source-dir)
+ source-dir (vc-responsible-backend source-dir))
(vc-pull)))))
(defun package-vc--archives-initialize ()
@@ -966,7 +993,12 @@ package-vc-rebuild
is the responsibility of `package-vc-upgrade'. Interactively,
prompt for the name of the package to rebuild."
(interactive (list (package-vc--read-package-desc "Rebuild package: " t)))
- (package-vc--unpack-1 pkg-desc (package-desc-dir pkg-desc)))
+ (let* ((pkg-spec (package-vc--pkg-spec-from-autoloads pkg-desc))
+ (package-vc-selected-packages
+ (if pkg-spec
+ (cons pkg-spec package-vc-selected-packages)
+ package-vc-selected-packages)))
+ (package-vc--unpack-1 pkg-desc (package-desc-dir pkg-desc))))
;;;###autoload
(defun package-vc-prepare-patch (pkg-desc subject revisions)
--
2.50.1
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79188; Package emacs.
Full text available.
Received: (at 79188) by debbugs.gnu.org; 7 Aug 2025 16:53:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 07 12:53:21 2025
Received: from localhost ([127.0.0.1]:35718 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uk3rk-0001SJ-R0
for submit <at> debbugs.gnu.org; Thu, 07 Aug 2025 12:53:21 -0400
Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]:55663)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <pkryger@HIDDEN>) id 1uk3rh-0001Rz-Ft
for 79188 <at> debbugs.gnu.org; Thu, 07 Aug 2025 12:53:18 -0400
Received: by mail-pj1-x1036.google.com with SMTP id
98e67ed59e1d1-3214762071bso1522523a91.3
for <79188 <at> debbugs.gnu.org>; Thu, 07 Aug 2025 09:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1754585591; x=1755190391; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=4C6CwUQ8WPrNCJE1oMOd+L11AcyE8reQkwVcHGaKb8I=;
b=h67uALqfZ5YekZ+iU56sCWWEG77BufommcGPmLMIz0XsFnTpt3cNC8aalVnkZ/USdW
yCKHBeZW7WkGXTvs5bQWGUzbYb6z3EqyV0z9sjWoS3sztf6zG96EgMOIDlPPCd5v4kf7
rasF027djjpTAyIr+zi0WLgz9fcwUIUr+zOsWhK6q2PlMnTQgzQesJ8hhXO0cwl2zd9O
ccn9tt+wC5J+uccjO0l+Vx+c5lbkaZYVYxYilwfqY25tIrHGn8Q1lR02Ba0um6KaexlG
m7Y/W0q1johpV2rTDoFd5QY32bcFkcNhV6ZLao5PoYvptpdvWiJWWY+wsmCahMdxx/RW
q6kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1754585591; x=1755190391;
h=content-transfer-encoding:cc:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=4C6CwUQ8WPrNCJE1oMOd+L11AcyE8reQkwVcHGaKb8I=;
b=Xz1xQBQ8loWHY5okQwqJj1zBHY9hdtF0uQEjT/F4PqaVJ4zkLWidEn+3t2+X+MpNC0
e5JmXaMbzE88XuWyJJ1JYXh+NhPakpn0ClwUiasScknsy8iKRAm40UYUMuXhcHP5VvB7
69TrHbqTnXp1E+79eIZsRm8LDEpJMjBddqulH2z9rgOEGniA512u1CiH02XDvjcw+eAx
21skxsJDRHVKbz05DqiLKKS5nkGNWqJ+aSJ0bJjTcwP+Bq2AbUyJbNkam0d6E2fX82o1
8spwzrEwXE0sDua5HWmqskC9zqGwdQ82aDLdA6Ca6bQDQuZwR6VWZt9VBCRUhE/VoXby
RIOQ==
X-Gm-Message-State: AOJu0YyIy30DX8Y9JJb0xPRmkvwY9cxEKJIO4/xf8XnT7XHDh848exXT
peTBldZNga0YYUs9IPRxfcN1gkhvacAQc4eosQao1pryDCY5QOYEl4cxAhZI15RN5sSNUUmARFM
D3aYgn+zQb0w6XPPAYmg1pM1gaZKs3GEo9g==
X-Gm-Gg: ASbGncvJvk8FADQzjpMiqrGdalOGdvSDcMAxJl4apUV3VYHpqjAZdSWedAQ084T7XfL
KP9HIwmWFyvt+oNuIxGofZAQ/aNZKMXrZE1oOYTLnUZQ19snYwlaIpAaEtOT3eK/EutYywXO3hB
wU6kDeJe9vnk/c31oGgB86bSPrL3YFPIOtZIunz1hy481e4YMk5MhlmiJIt9ks+ROOdKUMzMI+y
yy9+S6W01s974Cd8c4vj41ZkX3DP+aut52RcRQRX740O/3HAuA=
X-Google-Smtp-Source: AGHT+IE3ZzNnk/ikvriWlm9i2gA9Un0YQ35IXyUkVUV6bXF77Vf+D5ADt7LDhvseAi0CTfvWDSeXlI0esatLn3bwJGQ=
X-Received: by 2002:a17:90b:3c4b:b0:31e:ff94:3fa0 with SMTP id
98e67ed59e1d1-32166c10291mr9505743a91.6.1754585590965; Thu, 07 Aug 2025
09:53:10 -0700 (PDT)
MIME-Version: 1.0
References: <m2ectn9xif.fsf@HIDDEN>
<87jz3f2svk.fsf@HIDDEN> <m2cy97w04t.fsf@HIDDEN>
In-Reply-To: <m2cy97w04t.fsf@HIDDEN>
From: =?UTF-8?Q?Przemys=C5=82aw_Kryger?= <pkryger@HIDDEN>
Date: Thu, 7 Aug 2025 17:53:00 +0100
X-Gm-Features: Ac12FXykuCtVBaEfHQF2gbNoLSxWChl1jE_gmkr01oNSOi5YpMM5NP-bwJXwj5M
Message-ID: <CAPXM7TwOm9fF_nUsAZoDgrchp4Eg_991NmuBZgN2VCqjsUuShQ@HIDDEN>
Subject: Fwd: bug#79188: 31.0.50; Cannot build packages installed from VC
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.4 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Forwarding - missed the debbugs Forwarded message ---------
From: Przemysław Kryger Date: Thu, 7 Aug 2025 at 17:46 Subject: Re: bug#79188:
31.0.50; Cannot build packages installed from V [...]
Content analysis details: (3.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (pkryger[at]gmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2607:f8b0:4864:20:0:0:0:1036 listed in]
[list.dnswl.org]
2.2 MALFORMED_FREEMAIL Bad headers on message from free email
service
X-Debbugs-Envelope-To: 79188
Cc: 79188 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Forwarding - missed the debbugs Forwarded message ---------
From: Przemysław Kryger Date: Thu, 7 Aug 2025 at 17:46 Subject: Re: bug#79188:
31.0.50; Cannot build packages installed from V [...]
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2607:f8b0:4864:20:0:0:0:1036 listed in]
[list.dnswl.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (pkryger[at]gmail.com)
2.2 MALFORMED_FREEMAIL Bad headers on message from free email
service
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Forwarding - missed the debbugs
---------- Forwarded message ---------
From: Przemys=C5=82aw Kryger <pkryger@HIDDEN>
Date: Thu, 7 Aug 2025 at 17:46
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
To: Philip Kaludercic <philipk@HIDDEN>
Philip Kaludercic <philipk@HIDDEN> writes:
> Przemyslaw Kryger <pkryger@HIDDEN> writes:
>
>> I am using package-vc to manage a few pakcages I maintain. However, in =
Emacs
>> 31 I observed a couple issues.
>>
>> The first discrepancy with what used to happen on Emacs 30 is when a pac=
kage is
>> installed from a custom location, no *.elc files are produced. I don't =
know
>> what the expected behaviour should be here.
>>
>> In addition to that when I attempt to rebuild such a package with
>> package-vc-rebuild it signals an error, which I believe shouldn't happen=
,
>> should it? In this case no *.elc files have been produced nor updated. =
Such a
>> workflow used to work on Emacs 30.
>
> Both of these shouldn't happen.
Thank you for taking a look and for confirmation.
[...]
>> (add-to-list 'package-archives '(melpa . "https://melpa.org/packages/"))
> ^
> this should be a string!
Thanks for pointing out. It seems to work regardless.
>> ;; Just to avoid using existing elpa
>> (setq package-user-dir (expand-file-name "tmp/elpa" (getenv "HOME")))
>
> (Unrelated, but is there a reason you aren't doing (expand-file-name
> "~/tmp/elpa")?)
No, not really.
[...]
>> (let ((pkg-dir (expand-file-name "tmp/helm-projectile" (getenv "HOME")))=
)
>> (eval
>> `(use-package helm-projectile
>> :vc t
>> :load-path ,pkg-dir)))
>
> For posterity, this expands to
>
[...]
> which in turn would invoke
>
> (package-vc-install-from-checkout "/tmp/helm-projectile/" "helm-projectil=
e")
I think I reached very similar same conclusion. When I changed the
installation bit to:
(package-vc-install-from-checkout (expand-file-name "~/tmp/helm-projectile"=
)
"helm-projectile")
both issues still reproduce. That is after installation there are no
*.elc files to be found and an attempt to rebuild the package with
`package-vc-rebuild' yielded the same stack.
[...]
>> Which yields the following:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>> expand-file-name(nil)
>> vc-file-getprop(nil vc-working-revision)
>> vc-working-revision(nil)
>> package-vc--unpack-1(#s(package-desc :name helm-projectile :version (1=
3 1)
>> :summary "Helm integration for Projectile" :reqs nil :kind vc :archive n=
il
>> :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit
>> . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil)
>> "/Users/pkryger/tmp/elpa/helm-projectile/")
>> package-vc-rebuild(#s(package-desc :name helm-projectile :version (1 3=
1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive =
nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2e=
cd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
>> funcall-interactively(package-vc-rebuild #s(package-desc :name helm-pr=
ojectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs =
nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :=
extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil=
))
>> call-interactively(package-vc-rebuild record nil)
>> command-execute(package-vc-rebuild record)
>> execute-extended-command(nil "package-vc-rebuild" "pack-v-re")
>> funcall-interactively(execute-extended-command nil "package-vc-rebuild=
" "pack-v-re")
>> call-interactively(execute-extended-command nil nil)
>> command-execute(execute-extended-command)
>
> I couldn't reproduce this stack trace :/ It seems like
> `package-vc--main-file' returned nil. Can you check what the function
> returns, perhaps using edebug?
I run `package-vc-rebuild' and indeed the `package-vc--main-file' yields
is nil in Edebug instrumented `package-vc--unpack-file-1'.
>> Could these be introduced by 4226eb2b20408ba49787195bbc59bb0066c9c9e4?
>
> That seems reasonable, but in that case we should be able to reproduce
> the issue with a more simple example (especially one that doesn't involve
> use-package, MELPA and missing dependencies). I tried it out with a
> local package I had lying around and I also noticed that we don't
> byte-compile files anymore!
>
> This should fix the first issue, but it probably won't change anything
> about the latter:
>
> diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
> index db12c76133e..f2c7c460f6d 100644
> --- a/lisp/package/package-vc.el
> +++ b/lisp/package/package-vc.el
> @@ -549,7 +549,14 @@ package-vc--unpack-1
> ;; FIXME: Compilation should be done as a separate, optional, st=
ep.
> ;; E.g. for multi-package installs, we should first install all =
packages
> ;; and then compile them.
> - (package--compile new-desc)
> + (package--compile
> + (if lisp-dir
> + ;; In case we are installing a package from a local
> + ;; checkout, we want to compile the checkout, not the
> + ;; redirection!
> + (package-desc-create :dir lisp-dir)
> + new-desc))
> +
> (when package-native-compile
> (package--native-compile-async new-desc))
> ;; After compilation, load again any files loaded by
>
I don't have lisp/pakcage/package-vc.el, but I changed the file name to
lisp/emacs-lisp/packgage-vc.el and the patch applied cleanly.
Below I will use:
- "package source directory" to denote where package
resides (i.e., ${HOME}/tmp/helm-projectile)
- "package install directory" to denote where package is installed,
i.e. a result of:
(expand-file-name "helm-projectile" package-user-dir)
After I repeated the experiment the package installed with just
`package-vc-install-from-checkout' (as described above) and
helm-projectile.elc file has been produced into package source
directory.
Not sure if it is important but at this point my `load-path' has only
the package source directory and no package install directory. I wonder
how the helm-projectile-autoloads.el that has been produced into the
package install directory is going to take part further (in the same and
in a future Emacs session). Will both directories eventually end up in
the `load-path'?
I removed the compiled helm-projectile.elc from package source directory
and executed:
M-x package-vc-rebuild RET helm-projectile RET
which yield familiar stack trace.
The funny thing is that this time around, the package source directory
had no *.elc files created. However, the package install directory
contained helm-projectile-autoloads.elc [sic!].
I run the patched `package-vc--unpack-1' and this time `lisp-dir' was nil
(in l.550, where patch has been applied) and 'package-desc--main-file'
yielded nil again.
A question: shouldn't the newly generated *.elc files be put in package
install directory, just like the (non compiled) autoloads file is? In
my - very na=C3=AFve - view this would not only remove burden of doubling
`load-path' entries (will that happen) but would also allow for a
complete separation of compiled files between multiple Emacs versions
coexisting on the same machine and reusing the same package source
directories.
Last but not least. When stepping through `package-vc--unpack-1' under
Edebug for `package-vc-rebuild' I noticed that when it scans for
dependencies it examines files in package install directory. However,
these files (i.e., helm-projectile-pkg.el and
helm-projectile-autoloads.el) define no dependencies. Shouldn't the
scan happen for files in the package source directory? I think this was
what Emacs 30 did, due to symlink.
bug-gnu-emacs@HIDDEN:bug#79188; Package emacs.
Full text available.
Received: (at 79188) by debbugs.gnu.org; 7 Aug 2025 12:55:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 07 08:55:55 2025
Received: from localhost ([127.0.0.1]:34010 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uk09y-0006Cs-3z
for submit <at> debbugs.gnu.org; Thu, 07 Aug 2025 08:55:55 -0400
Received: from mout01.posteo.de ([185.67.36.65]:55601)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <philipk@HIDDEN>)
id 1uk09v-0006CX-2D
for 79188 <at> debbugs.gnu.org; Thu, 07 Aug 2025 08:55:52 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 77CFD240027
for <79188 <at> debbugs.gnu.org>; Thu, 7 Aug 2025 14:55:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net;
s=1984.ea087b; t=1754571344;
bh=Bz/AmoCwUG2eK15/vp/qodAT60wY6JhiY9im7rGh9fQ=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
From;
b=infYiHWx1tCpQngh7Zke+BmO4U9zXtPYIyvckVv+PpFeJilQRHcvnS5hsRegz/Csu
s77uhtohW3bRTcZoSIWmCOhfnqD5dVOqqC3pz0KKRKbmwwwSzXzwHysPQETutYzESI
hREoXEas2/LF5lv52LZmKlW3fHr0f7cb0+ZpR0V1oD16UqZwlIrxEznwbo53WfuXq/
KUMqeSAD1QqJXpMVjVBnWT2z8R2U8y+9htftFkxEZVa76Yyrq+hRrNMZtJZp+G3JH5
fVlAyHdX7/SNEG2x7zu0CwMK4e6bHwmWdMWc5n7KgDLSO25suhHp8NViy9cDm8UaN7
uC+UaFcfCFVtHi3KMshlN+trYEYgzl2N5yj9Zi3YaHFHqs0QTP/3jERcq3jFxBM3PE
r7GvQQ8O5fCbSvU8iS0h1mmc6bzcXQcEe8CC15GbJbg3z+gty75ow+QhtpqtFe5Z4T
aIbyq7D4EvJt9WfgvplRbHPGnNESYGnYpcVCsckVJUFf4uPH9yd
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4byRwb4hLrz9rxK;
Thu, 7 Aug 2025 14:55:43 +0200 (CEST)
From: Philip Kaludercic <philipk@HIDDEN>
To: Przemyslaw Kryger <pkryger@HIDDEN>
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
In-Reply-To: <m2ectn9xif.fsf@HIDDEN>
References: <m2ectn9xif.fsf@HIDDEN>
Date: Thu, 07 Aug 2025 12:55:43 +0000
Message-ID: <87jz3f2svk.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79188
Cc: 79188 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
Przemyslaw Kryger <pkryger@HIDDEN> writes:
> I am using package-vc to manage a few pakcages I maintain. However, in Emacs
> 31 I observed a couple issues.
>
> The first discrepancy with what used to happen on Emacs 30 is when a package is
> installed from a custom location, no *.elc files are produced. I don't know
> what the expected behaviour should be here.
>
> In addition to that when I attempt to rebuild such a package with
> package-vc-rebuild it signals an error, which I believe shouldn't happen,
> should it? In this case no *.elc files have been produced nor updated. Such a
> workflow used to work on Emacs 30.
Both of these shouldn't happen.
> I observed this on a Emacs macport (from
> https://github.com/jdtsmith/emacs-mac/tree/emacs-mac-gnu_master_exp), but the
> issue is reproducible on master (68aaeb3519fd7f6176050e142f0dbc27e07992d2) as
> well.
>
> git clone https://github.com/pkryger/helm-projectile "${HOME}/tmp/helm-projectile"
> emacs -Q
>
> (require 'package)
> (add-to-list 'package-archives '(melpa . "https://melpa.org/packages/"))
^
this should be a string!
> ;; Just to avoid using existing elpa
> (setq package-user-dir (expand-file-name "tmp/elpa" (getenv "HOME")))
(Unrelated, but is there a reason you aren't doing (expand-file-name
"~/tmp/elpa")?)
> (package-refresh-contents)
> ;; In my config I use hardcoded paths, but `use-package' needs a
> ;; string for `:load-path', so just for this sample
> (let ((pkg-dir (expand-file-name "tmp/helm-projectile" (getenv "HOME"))))
> (eval
> `(use-package helm-projectile
> :vc t
> :load-path ,pkg-dir)))
For posterity, this expands to
--8<---------------cut here---------------start------------->8---
(progn
(eval-and-compile (add-to-list 'load-path "/tmp/helm-projectile/"))
(use-package-vc-install '(helm-projectile) "/tmp/helm-projectile/")
(defvar use-package--warning0
#'(lambda (keyword err)
(let
((msg
(format "%s/%s: %s" 'helm-projectile keyword
(error-message-string err))))
(display-warning 'use-package msg :error))))
(condition-case-unless-debug err
(if (not (require 'helm-projectile nil t))
(display-warning 'use-package
(format "Cannot load %s" 'helm-projectile)
:error))
(error (funcall use-package--warning0 :catch err))))
--8<---------------cut here---------------end--------------->8---
which for us means that we are interested in
(use-package-vc-install '(helm-projectile) "/tmp/helm-projectile/")
which in turn would invoke
(package-vc-install-from-checkout "/tmp/helm-projectile/" "helm-projectile")
>
> ;; At this point `helm-projectile' has been installed, but no *.elc files are
> ;; produced, which differs from Emacs 30.
>
> (setq debug-on-error t)
> M-x package-vc-rebuild RET helm-projectile RET
>
> Which yields the following:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> expand-file-name(nil)
> vc-file-getprop(nil vc-working-revision)
> vc-working-revision(nil)
> package-vc--unpack-1(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil) "/Users/pkryger/tmp/elpa/helm-projectile/")
> package-vc-rebuild(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
> funcall-interactively(package-vc-rebuild #s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
> call-interactively(package-vc-rebuild record nil)
> command-execute(package-vc-rebuild record)
> execute-extended-command(nil "package-vc-rebuild" "pack-v-re")
> funcall-interactively(execute-extended-command nil "package-vc-rebuild" "pack-v-re")
> call-interactively(execute-extended-command nil nil)
> command-execute(execute-extended-command)
I couldn't reproduce this stack trace :/ It seems like
`package-vc--main-file' returned nil. Can you check what the function
returns, perhaps using edebug?
> Could these be introduced by 4226eb2b20408ba49787195bbc59bb0066c9c9e4?
That seems reasonable, but in that case we should be able to reproduce
the issue with a more simple example (especially one that doesn't involve
use-package, MELPA and missing dependencies). I tried it out with a
local package I had lying around and I also noticed that we don't
byte-compile files anymore!
This should fix the first issue, but it probably won't change anything
about the latter:
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline
diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
index db12c76133e..f2c7c460f6d 100644
--- a/lisp/package/package-vc.el
+++ b/lisp/package/package-vc.el
@@ -549,7 +549,14 @@ package-vc--unpack-1
;; FIXME: Compilation should be done as a separate, optional, step.
;; E.g. for multi-package installs, we should first install all packages
;; and then compile them.
- (package--compile new-desc)
+ (package--compile
+ (if lisp-dir
+ ;; In case we are installing a package from a local
+ ;; checkout, we want to compile the checkout, not the
+ ;; redirection!
+ (package-desc-create :dir lisp-dir)
+ new-desc))
+
(when package-native-compile
(package--native-compile-async new-desc))
;; After compilation, load again any files loaded by
--=-=-=
Content-Type: text/plain
>
> In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.5.0, X toolkit,
> cairo version 1.18.4, Xaw3d scroll bars) of 2025-08-07 built on
> Przemyslaws-MacBook-Air.local
> Repository revision: 68aaeb3519fd7f6176050e142f0dbc27e07992d2
> Repository branch: master
> System Description: macOS 15.5
>
> Configured using:
> 'configure --without-ns --with-gnutls --with-modules
> --with-native-compilation=no --with-jpeg=ifavailable
> --with-gif=ifavailable --with-tiff=ifavailable CFLAGS=-O3'
>
> Configured features:
> ACL CAIRO FREETYPE GLIB GNUTLS GSETTINGS HARFBUZZ LCMS2 LIBXML2 MODULES
> NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS
> TREE_SITTER WEBP X11 XAW3D XDBE XIM XINERAMA XPM XRANDR LUCID ZLIB
>
> Important settings:
> value of $LANG: en_GB.UTF-8
> locale-coding-system: utf-8-unix
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
> xterm-mouse-mode: t
> tooltip-mode: t
> global-eldoc-mode: t
> eldoc-mode: t
> show-paren-mode: t
> electric-indent-mode: t
> mouse-wheel-mode: t
> tool-bar-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> minibuffer-regexp-mode: t
> line-number-mode: t
> indent-tabs-mode: t
> transient-mark-mode: t
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
>
> Load-path shadows:
> /Users/pkryger/tmp/elpa/helm-4.0.4/helm-packages hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-packages
> /Users/pkryger/tmp/elpa/helm-4.0.4/helm-x-icons hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-x-icons
>
> Features:
> (shadow sort mail-extr emacsbug use-package-ensure help-fns cl-print
> debug backtrace find-func helm-projectile projectile helm-files
> image-dired image-dired-tags image-dired-external image-dired-util
> image-mode exif filenotify dired-x ffap tramp rx trampver
> tramp-integration tramp-message tramp-compat shell pcomplete parse-time
> iso8601 tramp-loaddefs helm-tags helm-buffers helm-x-icons helm-occur
> helm-grep helm-regexp format-spec helm-utils helm-locate helm-help helm
> helm-types helm-global-bindings helm-easymenu edmacro kmacro helm-core
> helm-source helm-multi-match helm-lib cus-edit pp cus-start cus-load
> wid-edit helm-projectile-autoloads helm-autoloads helm-core-autoloads
> vc-git diff-mode track-changes files-x wfnames-autoloads smtpmail
> dired-async dired-aux async-bytecomp async bug-reference async-autoloads
> project skeleton ibuf-macs pcase find-dired grep ibuf-ext ibuffer
> ibuffer-loaddefs thingatpt compile comint ansi-osc ansi-color ring
> projectile-autoloads easy-mmode loaddefs-gen radix-tree tar-mode
> arc-mode archive-mode package-vc vc vc-dispatcher lisp-mnt cl-extra
> help-mode use-package-core finder-inf mm-archive message sendmail
> yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived gnus-util
> text-property-search mailabbrev gmm-utils mailheader mm-decode mm-bodies
> mm-encode mail-utils gnutls network-stream url-cache warnings url-http
> url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
> mail-prsvr url-gw nsm puny epg rfc6068 epg-config package browse-url xdg
> url url-proxy url-privacy url-expand url-methods url-history url-cookie
> generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
> auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
> map url-vars time-date subr-x cl-loaddefs cl-lib xt-mouse term/xterm
> xterm byte-opt gv bytecomp byte-compile rmc iso-transl tooltip cconv
> eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
> elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
> tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
> newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
> rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
> font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
> simple cl-generic indonesian philippine cham georgian utf-8-lang
> misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
> cp51932 hebrew greek romanian slovak czech european ethiopic indian
> cyrillic chinese composite emoji-zwj charscript charprop case-table
> epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
> loaddefs theme-loaddefs faces cus-face macroexp files window
> text-properties overlay sha1 md5 base64 format env code-pages mule
> custom widget keymap hashtable-print-readable backquote threads kqueue
> lcms2 dynamic-setting system-font-setting font-render-setting cairo
> x-toolkit x multi-tty move-toolbar make-network-process tty-child-frames
> emacs)
>
> Memory information:
> ((conses 16 349318 58285) (symbols 48 22829 1) (strings 32 68024 3090)
> (string-bytes 1 2006739) (vectors 16 34746)
> (vector-slots 8 661887 21587) (floats 8 132 421)
> (intervals 56 1420 25) (buffers 1064 20))
>
>
--
Philip Kaludercic
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79188; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 7 Aug 2025 11:34:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 07 07:34:05 2025
Received: from localhost ([127.0.0.1]:33849 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ujysm-0002EI-Sb
for submit <at> debbugs.gnu.org; Thu, 07 Aug 2025 07:34:05 -0400
Received: from lists.gnu.org ([2001:470:142::17]:42316)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pkryger@HIDDEN>) id 1ujysk-0002Dc-S7
for submit <at> debbugs.gnu.org; Thu, 07 Aug 2025 07:34:03 -0400
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 <pkryger@HIDDEN>) id 1ujysa-0007WK-Mi
for bug-gnu-emacs@HIDDEN; Thu, 07 Aug 2025 07:33:55 -0400
Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <pkryger@HIDDEN>) id 1ujysW-0007qp-Mu
for bug-gnu-emacs@HIDDEN; Thu, 07 Aug 2025 07:33:51 -0400
Received: by mail-wm1-x32f.google.com with SMTP id
5b1f17b1804b1-459d62184c9so5663865e9.1
for <bug-gnu-emacs@HIDDEN>; Thu, 07 Aug 2025 04:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1754566426; x=1755171226; darn=gnu.org;
h=mime-version:message-id:date:subject:to:from:from:to:cc:subject
:date:message-id:reply-to;
bh=SL9tP2R0BjZ7TeEKpinYo5S9siboij0lwOHCGWJG7g0=;
b=OTCCsCILlwqE8y18losbzhBWyFisFYVPc9BSnbeQyfWhT4ztz1X5vFdFNYnrOaK2UR
A32lQs8pY6oL4RzNkJ3Q3aQJ6kLNNU37biKkUwaBzh5uLiQfagcSJ4wMqQRcXKV7TKiS
EA9WL5oRfvjfF1rSyUGDpoeIXmwq3ENkY6MYRxLFbqkNLGGhMyUCeBPB9OtugKfHALwN
lEaTrzlVzbCRvqFyxSR/HB2ayq4sBBYffgHYas6QlItJ5CihUDvhO6vuBndIiw6mjc7c
Gxvl+tNSWgnZ1k0DAcpkOcdBQ47LYIXj6dLvHpGjTpLgMvqjGA8jXu+nVHEqp4es5l/u
ImqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1754566426; x=1755171226;
h=mime-version:message-id:date:subject:to:from:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=SL9tP2R0BjZ7TeEKpinYo5S9siboij0lwOHCGWJG7g0=;
b=FdA4FTtRupia3Gx0MISp/FecO2rjLAV3NhnZNKYgnT5K3vnMO/vtCr4sMuHXHhgWb1
4c3DCgnHwtcBeSZmxE8l2hLheGh65im3uLztmQ2Cm2cVsIVhzCfRi3TLmL1QhI+qSSwT
/KghCM/6E+IipKK4HR0Z8caeEXyWEXhrePprS0J/R3U4mkUCtbC1r8695OfyrUonGSlo
y89+qxjoE4QI77lytTPNl4RI5C1aeuKaeISN8pQIYYWnLOJKxaHL+9cDKc87gkCntcuW
GQ3CDZjnx22XGDHOL7GOzkHT4Tb/bXfHJmClHaLaeM7J+1k7GVLV2y07JHuaVEDJkqq9
iynQ==
X-Gm-Message-State: AOJu0YwkuvagC4+/QvCgGQ2XtpBCv4bonE9FOlbIBcMuCaMhvLVP0bzU
a5YBp/wHHAy8kHfAD8sUmNTcRRv4cXp0WcJDo3ohJx3isRFEyF+fCfnPPbpkiQ==
X-Gm-Gg: ASbGncthvgjMOtktH1e/yu0iu6INXDUE2j4t222a05M64XBR24AZ5I52AeX9qBAaKfc
Kx8npQH5LA+GYMpsm7X50ZwG8yfIg+UoItxrdlso6wxW8q4kzMKSKnFu0dBgWTgcSYcM4NrxLyF
tGyjkr+BxDwYzeI6/zaUIllDC8r/3rDOt1RfwEX+MwiJVqOMLJQzbi43kjJYSnJDu+m+liq3F8X
pum5JNDwGmQGTY8HeRPkyA9Iuk5zrtFwWuvBcevky13uh4ZdoqrwERad/t9G6SUiY4afv1hbWG/
JdNox/+J3WZf1EbjGOGL5XL5quysBEUsv13X85b3cOvR8Grrd9bXOuqHha0CXxx3MekHTPs1SDn
4YnkvmF5WiPfDWAozt4rHFdXtmsXLcz3J/sF/u+xwnEv/2/OQUK1qn0JIY+yhgGw=
X-Google-Smtp-Source: AGHT+IGOBUIT3i5F07Z0HqRXP4m7g3PdTVBMi6XEUf6qeOOId3X7ndTsbcKtfYuTkqB6TqLntW8/KQ==
X-Received: by 2002:a05:600c:4ece:b0:458:a559:a693 with SMTP id
5b1f17b1804b1-459e70d9e6cmr63833075e9.18.1754566425914;
Thu, 07 Aug 2025 04:33:45 -0700 (PDT)
Received: from Przemyslaws-MacBook-Air.local
([2a00:23c8:b1c:3801:1c7a:76b8:c20f:aea9])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-459e0e70218sm118594055e9.20.2025.08.07.04.33.45
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 07 Aug 2025 04:33:45 -0700 (PDT)
From: Przemyslaw Kryger <pkryger@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; Cannot build packages installed from VC
X-Debbugs-Cc: Philip Kaludercic <philipk@HIDDEN>
Date: Thu, 07 Aug 2025 12:33:44 +0100
Message-ID: <m2ectn9xif.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2a00:1450:4864:20::32f;
envelope-from=pkryger@HIDDEN; helo=mail-wm1-x32f.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
I am using package-vc to manage a few pakcages I maintain. However, in Emacs
31 I observed a couple issues.
The first discrepancy with what used to happen on Emacs 30 is when a package is
installed from a custom location, no *.elc files are produced. I don't know
what the expected behaviour should be here.
In addition to that when I attempt to rebuild such a package with
package-vc-rebuild it signals an error, which I believe shouldn't happen,
should it? In this case no *.elc files have been produced nor updated. Such a
workflow used to work on Emacs 30.
I observed this on a Emacs macport (from
https://github.com/jdtsmith/emacs-mac/tree/emacs-mac-gnu_master_exp), but the
issue is reproducible on master (68aaeb3519fd7f6176050e142f0dbc27e07992d2) as
well.
git clone https://github.com/pkryger/helm-projectile "${HOME}/tmp/helm-projectile"
emacs -Q
(require 'package)
(add-to-list 'package-archives '(melpa . "https://melpa.org/packages/"))
;; Just to avoid using existing elpa
(setq package-user-dir (expand-file-name "tmp/elpa" (getenv "HOME")))
(package-refresh-contents)
;; In my config I use hardcoded paths, but `use-package' needs a
;; string for `:load-path', so just for this sample
(let ((pkg-dir (expand-file-name "tmp/helm-projectile" (getenv "HOME"))))
(eval
`(use-package helm-projectile
:vc t
:load-path ,pkg-dir)))
;; At this point `helm-projectile' has been installed, but no *.elc files are
;; produced, which differs from Emacs 30.
(setq debug-on-error t)
M-x package-vc-rebuild RET helm-projectile RET
Which yields the following:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
expand-file-name(nil)
vc-file-getprop(nil vc-working-revision)
vc-working-revision(nil)
package-vc--unpack-1(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil) "/Users/pkryger/tmp/elpa/helm-projectile/")
package-vc-rebuild(#s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
funcall-interactively(package-vc-rebuild #s(package-desc :name helm-projectile :version (1 3 1) :summary "Helm integration for Projectile" :reqs nil :kind vc :archive nil :dir "/Users/pkryger/tmp/elpa/helm-projectile/" :extras ((:commit . "2ecd3d85b7077f39bb2fefe2227cc46931d4b92b")) :signed nil))
call-interactively(package-vc-rebuild record nil)
command-execute(package-vc-rebuild record)
execute-extended-command(nil "package-vc-rebuild" "pack-v-re")
funcall-interactively(execute-extended-command nil "package-vc-rebuild" "pack-v-re")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
Could these be introduced by 4226eb2b20408ba49787195bbc59bb0066c9c9e4?
In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.5.0, X toolkit,
cairo version 1.18.4, Xaw3d scroll bars) of 2025-08-07 built on
Przemyslaws-MacBook-Air.local
Repository revision: 68aaeb3519fd7f6176050e142f0dbc27e07992d2
Repository branch: master
System Description: macOS 15.5
Configured using:
'configure --without-ns --with-gnutls --with-modules
--with-native-compilation=no --with-jpeg=ifavailable
--with-gif=ifavailable --with-tiff=ifavailable CFLAGS=-O3'
Configured features:
ACL CAIRO FREETYPE GLIB GNUTLS GSETTINGS HARFBUZZ LCMS2 LIBXML2 MODULES
NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XAW3D XDBE XIM XINERAMA XPM XRANDR LUCID ZLIB
Important settings:
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
xterm-mouse-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/Users/pkryger/tmp/elpa/helm-4.0.4/helm-packages hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-packages
/Users/pkryger/tmp/elpa/helm-4.0.4/helm-x-icons hides /Users/pkryger/tmp/elpa/helm-core-4.0.4/helm-x-icons
Features:
(shadow sort mail-extr emacsbug use-package-ensure help-fns cl-print
debug backtrace find-func helm-projectile projectile helm-files
image-dired image-dired-tags image-dired-external image-dired-util
image-mode exif filenotify dired-x ffap tramp rx trampver
tramp-integration tramp-message tramp-compat shell pcomplete parse-time
iso8601 tramp-loaddefs helm-tags helm-buffers helm-x-icons helm-occur
helm-grep helm-regexp format-spec helm-utils helm-locate helm-help helm
helm-types helm-global-bindings helm-easymenu edmacro kmacro helm-core
helm-source helm-multi-match helm-lib cus-edit pp cus-start cus-load
wid-edit helm-projectile-autoloads helm-autoloads helm-core-autoloads
vc-git diff-mode track-changes files-x wfnames-autoloads smtpmail
dired-async dired-aux async-bytecomp async bug-reference async-autoloads
project skeleton ibuf-macs pcase find-dired grep ibuf-ext ibuffer
ibuffer-loaddefs thingatpt compile comint ansi-osc ansi-color ring
projectile-autoloads easy-mmode loaddefs-gen radix-tree tar-mode
arc-mode archive-mode package-vc vc vc-dispatcher lisp-mnt cl-extra
help-mode use-package-core finder-inf mm-archive message sendmail
yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived gnus-util
text-property-search mailabbrev gmm-utils mailheader mm-decode mm-bodies
mm-encode mail-utils gnutls network-stream url-cache warnings url-http
url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm puny epg rfc6068 epg-config package browse-url xdg
url url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
map url-vars time-date subr-x cl-loaddefs cl-lib xt-mouse term/xterm
xterm byte-opt gv bytecomp byte-compile rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads kqueue
lcms2 dynamic-setting system-font-setting font-render-setting cairo
x-toolkit x multi-tty move-toolbar make-network-process tty-child-frames
emacs)
Memory information:
((conses 16 349318 58285) (symbols 48 22829 1) (strings 32 68024 3090)
(string-bytes 1 2006739) (vectors 16 34746)
(vector-slots 8 661887 21587) (floats 8 132 421)
(intervals 56 1420 25) (buffers 1064 20))
Przemyslaw Kryger <pkryger@HIDDEN>:philipk@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.philipk@HIDDEN, bug-gnu-emacs@HIDDEN:bug#79188; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.