bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Michael Angelozzi]

[-- 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 --]

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Eli Zaretskii]

> 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.

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Noam Postavsky]

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")

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Eli Zaretskii]

> 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?

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Noam Postavsky]

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.

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Eli Zaretskii]

> 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.

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Lars Ingebrigtsen]

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

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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?

Yes, it should be fixed by this commit this summer:

commit 606b783acb3388249c38264f8e37e08af832e1ea
Author:     Ioannis Kappas <ioannis.kappas@gmail.com>
AuthorDate: Tue Jul 20 15:53:34 2021 +0200

    Allow installing packages with DOS line endings


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Lars Ingebrigtsen]

Michael Angelozzi <mangelozzi@gmail.com> writes:

> Hi, sorry I dont use Emacs anymore, I was trying it out but gave up
> and returned to the dark side... NeoVim =)

😀

OK; I'm closing this bug report, then.

bug#40148: 26.3; Custom package header checked out from GIT in Windows will not parse

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Vim is free software, so it is not evil.

Windows, by contrast, is evil.  It is nonfree, and it is malware too.
Most nonfree programs you will come across are malware -- see
https://gnu.org/malware/.

I hope you will find the strength to refuse to use it any more.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)