* bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
@ 2020-03-20 8:50 Michael Angelozzi
2020-03-20 13:58 ` Eli Zaretskii
2021-12-05 1:18 ` Lars Ingebrigtsen
0 siblings, 2 replies; 10+ messages in thread
From: Michael Angelozzi @ 2020-03-20 8:50 UTC (permalink / raw)
To: 40148
[-- Attachment #1: Type: text/plain, Size: 5421 bytes --]
Hi,
Been using a custom theme in Ubuntu 18.04 with no problems.
Now tweaking my setup to also work with Windows 10, but I
get the following error (even though it has a package version):
*emacs error: Package lacks a "Version" or "Package-Version" header*
As you can see it does have a version:
;;; michael-theme.el --- Emacs theme with a dark background and bright
colors for use with a projector.
;; Author: Michael
;; Version: 0.1
;; Keywords: michael theme
I see other people have encountered the problem here:
https://emacs.stackexchange.com/questions/52142/debugging-package-lacks-a-file-header
https://github.com/syl20bnr/spacemacs/issues/10645
It is most perplexing when trying to solve. It one version controls one's
config with GIT (as many do), GIT automatically changes CR's to CRLF's in
windows when checking out the code. I am guessing the package header parser
part that split fields is not identifying the line termination character.
Curse the day CRLF ever became a thing!
There are certinaly ways around it, but I feel many others maybe tripped up
by this.
Kind Regards
Michael
In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 10.0.17134
Recent messages:
Loading paren...done
Loading c:/Users/Michael/AppData/Roaming/.emacs.d/custom.el (source)...done
Turning on magit-auto-revert-mode...done
Truncate long lines enabled
For information about GNU Emacs and the GNU system, type C-h C-a.
Truncate long lines enabled
Making completion list...
delete-backward-char: Text is read-only [2 times]
Entering debugger...
Making completion list...
Quit
Configured using:
'configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2
Important settings:
value of $LANG: ENG
locale-coding-system: cp1252
Major mode: Debugger
Minor modes in effect:
show-paren-mode: t
save-place-mode: t
global-magit-file-mode: t
diff-auto-refine-mode: t
magit-auto-revert-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
which-key-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug sendmail cl-print debug vc-git
browse-url url-util elec-pair warnings lisp-mnt paren cus-start cus-load
saveplace magit-submodule magit-obsolete magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff smerge-mode diff-mode magit-core
magit-autorevert autorevert filenotify magit-margin magit-transient
magit-process magit-mode git-commit transient magit-git magit-section
magit-utils crm log-edit message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils
mailheader pcvs-util add-log with-editor async-bytecomp async shell
pcomplete comint ansi-color ring server subr-x dash which-key advice
whitespace cl-extra help-mode use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core finder-inf info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads w32notify w32
lcms2 multi-tty make-network-process emacs)
Memory information:
((conses 16 311911 38471)
(symbols 48 33537 1)
(miscs 40 95 233)
(strings 32 101197 2343)
(string-bytes 1 2658699)
(vectors 16 34044)
(vector-slots 8 813898 65712)
(floats 8 100 366)
(intervals 56 1894 1765)
(buffers 992 16))
[-- Attachment #2: Type: text/html, Size: 6282 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
2020-03-20 8:50 bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse Michael Angelozzi
@ 2020-03-20 13:58 ` Eli Zaretskii
2020-03-20 14:25 ` Noam Postavsky
2021-12-05 1:18 ` Lars Ingebrigtsen
1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2020-03-20 13:58 UTC (permalink / raw)
To: Michael Angelozzi; +Cc: 40148
> From: Michael Angelozzi <mangelozzi@gmail.com>
> Date: Fri, 20 Mar 2020 10:50:59 +0200
>
> Been using a custom theme in Ubuntu 18.04 with no problems.
> Now tweaking my setup to also work with Windows 10, but I
> get the following error (even though it has a package version):
> emacs error: Package lacks a "Version" or "Package-Version" header
>
> As you can see it does have a version:
> ;;; michael-theme.el --- Emacs theme with a dark background and bright colors for use with a projector.
>
> ;; Author: Michael
> ;; Version: 0.1
> ;; Keywords: michael theme
>
> I see other people have encountered the problem here:
> https://emacs.stackexchange.com/questions/52142/debugging-package-lacks-a-file-header
> https://github.com/syl20bnr/spacemacs/issues/10645
>
> It is most perplexing when trying to solve. It one version controls one's config with GIT (as many do), GIT
> automatically changes CR's to CRLF's in windows when checking out the code. I am guessing the package
> header parser part that split fields is not identifying the line termination character.
>
> Curse the day CRLF ever became a thing!
Contrary to the advice on the Internet and the defaults of the Git for
Windows installation, you are well advised (by me) to configure Git
not to convert the end-of-line convention. That is, install Git with
"check out as-is, commit in as-is" option. Then all your problems
with CRLF will go away.
It may be the case that package.el should be more tolerant in this
case, but that's just the tip of an iceberg, because there are files
out there where LF to CR-LF conversions are a no-no (just one example:
Unix shell scripts). Just say no to this "feature", and Bob's your
uncle.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
2020-03-20 13:58 ` Eli Zaretskii
@ 2020-03-20 14:25 ` Noam Postavsky
2020-03-20 14:47 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2020-03-20 14:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 40148, Michael Angelozzi
Eli Zaretskii <eliz@gnu.org> writes:
> It may be the case that package.el should be more tolerant in this
> case, but that's just the tip of an iceberg, because there are files
> out there where LF to CR-LF conversions are a no-no (just one example:
> Unix shell scripts). Just say no to this "feature", and Bob's your
> uncle.
The problem happens without git conversion as well (because Emacs
defaults to "dos" encoding on windows-nt systems):
emacs -Q -f toggle-debug-on-error
C-x C-f test-package.el ;; (visit a non-existing file)
insert the following text
;;; michael-theme.el --- Emacs theme with a dark background and bright colors for use with a projector.
;; Author: Michael
;; Version: 0.1
;; Keywords: michael theme
;;; michael-theme.el ends here
C-x C-s
M-x package-install-file test-package.el RET
Debugger entered--Lisp error: (error "Package lacks a \"Version\" or \"Package-Version\" header")
signal(error ("Package lacks a \"Version\" or \"Package-Version\" header"))
error("Package lacks a \"Version\" or \"Package-Version\" header")
package-buffer-info()
package-install-from-buffer()
package-install-file("~/test-package.el")
funcall-interactively(package-install-file "~/test-package.el")
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
2020-03-20 14:25 ` Noam Postavsky
@ 2020-03-20 14:47 ` Eli Zaretskii
2020-03-20 19:47 ` Noam Postavsky
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2020-03-20 14:47 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 40148, mangelozzi
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Michael Angelozzi <mangelozzi@gmail.com>, 40148@debbugs.gnu.org
> Date: Fri, 20 Mar 2020 10:25:11 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > It may be the case that package.el should be more tolerant in this
> > case, but that's just the tip of an iceberg, because there are files
> > out there where LF to CR-LF conversions are a no-no (just one example:
> > Unix shell scripts). Just say no to this "feature", and Bob's your
> > uncle.
>
> The problem happens without git conversion as well (because Emacs
> defaults to "dos" encoding on windows-nt systems):
You are saying that creating a package (or a new file in a package)
should leave the EOL format of the Lisp files at "dos", and distribute
the package's files like that via the elpa's?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
2020-03-20 14:47 ` Eli Zaretskii
@ 2020-03-20 19:47 ` Noam Postavsky
2020-03-21 7:35 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2020-03-20 19:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 40148, mangelozzi
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Noam Postavsky <npostavs@gmail.com>
>> Cc: Michael Angelozzi <mangelozzi@gmail.com>, 40148@debbugs.gnu.org
>> Date: Fri, 20 Mar 2020 10:25:11 -0400
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > It may be the case that package.el should be more tolerant in this
>> > case, but that's just the tip of an iceberg, because there are files
>> > out there where LF to CR-LF conversions are a no-no (just one example:
>> > Unix shell scripts). Just say no to this "feature", and Bob's your
>> > uncle.
>>
>> The problem happens without git conversion as well (because Emacs
>> defaults to "dos" encoding on windows-nt systems):
>
> You are saying that creating a package (or a new file in a package)
> should leave the EOL format of the Lisp files at "dos", and distribute
> the package's files like that via the elpa's?
My message above says only what does happen, not what should happen (for
the latter, see below).
But I'm not sure exactly what you mean by "create a package". I don't
think Emacs has a particular action/command which corresponds to that.
Distribution via repos is mostly outside the responsibility of Emacs'
code (there are some upload functions in package-x.el, but none of the
existing repos make use of them, as far as I know).
About what should happen: I think detecting and giving a specific error
about CRLF from package-buffer-info could be a satisfactory solution to
this bug. Or perhaps package-install-file could be more lenient.
Actually, if I'm reading the code right, it's already more lenient in
case of installing from a .tar file containing CRLF elisp files.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
2020-03-20 19:47 ` Noam Postavsky
@ 2020-03-21 7:35 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-03-21 7:35 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 40148, mangelozzi
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: 40148@debbugs.gnu.org, mangelozzi@gmail.com
> Date: Fri, 20 Mar 2020 15:47:27 -0400
>
> > You are saying that creating a package (or a new file in a package)
> > should leave the EOL format of the Lisp files at "dos", and distribute
> > the package's files like that via the elpa's?
>
> My message above says only what does happen, not what should happen (for
> the latter, see below).
>
> But I'm not sure exactly what you mean by "create a package".
What I mean is that when someone makes a package, or more generally,
creates a Lisp file that will be made available for others on the
Internet, he/she should save that file with utf-8-unix. IOW, the
Emacs default for saving new files is not what should determine the
EOL format of such files. And that includes Lisp files that are part
of a package.
> About what should happen: I think detecting and giving a specific error
> about CRLF from package-buffer-info could be a satisfactory solution to
> this bug. Or perhaps package-install-file could be more lenient.
Both solutions would be fine, IMO.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse
2020-03-20 8:50 bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse Michael Angelozzi
2020-03-20 13:58 ` Eli Zaretskii
@ 2021-12-05 1:18 ` Lars Ingebrigtsen
2021-12-05 1:19 ` Lars Ingebrigtsen
[not found] ` <CAFNYG9f3OaP=a+NbKq73XNxKdK4SJX9T4EBL-hbCCwD82+P+Kw@mail.gmail.com>
1 sibling, 2 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-05 1:18 UTC (permalink / raw)
To: Michael Angelozzi; +Cc: 40148
Michael Angelozzi <mangelozzi@gmail.com> writes:
> Been using a custom theme in Ubuntu 18.04 with no problems.
> Now tweaking my setup to also work with Windows 10, but I
> get the following error (even though it has a package version):
> emacs error: Package lacks a "Version" or "Package-Version" header
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I seem to recall this being fixed a while ago -- would it be possible
for you to try Emacs 28 and see whether you can still see the issue
there?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-12-07 4:13 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-20 8:50 bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse Michael Angelozzi
2020-03-20 13:58 ` Eli Zaretskii
2020-03-20 14:25 ` Noam Postavsky
2020-03-20 14:47 ` Eli Zaretskii
2020-03-20 19:47 ` Noam Postavsky
2020-03-21 7:35 ` Eli Zaretskii
2021-12-05 1:18 ` Lars Ingebrigtsen
2021-12-05 1:19 ` Lars Ingebrigtsen
[not found] ` <CAFNYG9f3OaP=a+NbKq73XNxKdK4SJX9T4EBL-hbCCwD82+P+Kw@mail.gmail.com>
2021-12-05 19:55 ` Lars Ingebrigtsen
2021-12-07 4:13 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.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).