bug#23927: 25.0.94; Errors when updating using package.el

bug#23927: 25.0.94; Errors when updating using package.el

[Live System User]

Hi,

        When updating a package `(package-menu-mark-upgrades)',
        I got the following errors/warnings:

package-activate-1: Required feature ‘info’ was not providedInvalid face reference: package-status-builtin-face
Invalid face reference: package-status-builtin-face [3 times]
user-error: No cross-reference here

        
        Thanks.




In GNU Emacs 25.0.94.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.18.9)
 of 2016-05-18 built on copr-builder-587584625.novalocal
Windowing system distributor 'Fedora Project', version 11.0.11799901
Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XWIDGETS

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  cursor-sensor-mode: t
  gnus-undo-mode: t
  tooltip-mode: t
  global-eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
nnimap read 242k from imap.aim.com
nnimap read 249k from imap.aim.com
nnimap read 266k from imap.aim.com [2 times]
nnimap read 282k from imap.aim.com
Fetching headers for nnimap+aol:INBOX...done
Scoring...done
Sorting threads...done
Generating summary...done
Auto-saving...
Discard changes to this group and exit? (y or n) y

Load-path shadows:
None found.

Features:
(misearch multi-isearch eieio-opt speedbar sb-image ezimage dframe
find-func pp shadow emacsbug thingatpt nnagent nnml shr-color color shr
dom subr-x browse-url mailalias smtpmail sendmail sort gnus-cite smiley
ansi-color mail-extr qp gnus-async gnus-bcklg gnus-ml disp-table
cursor-sensor nndraft nnmh nndoc mm-archive timezone url-http url-gw
url-cache url-auth url-handlers utf-7 rfc2104 nnfolder network-stream
nsm starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg nntp gnus-cache epa-file epa derived nnreddit mm-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs url-vars json map seq byte-opt bytecomp byte-compile cl-extra
cconv gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap cl gv
sieve sieve-mode sieve-manage nnir gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc
parse-time gnus-spec gnus-int gnus-range message dired format-spec
rfc822 mml mml-sec password-cache epg epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader gnus-win gnus gnus-ems wid-edit nnoo nnheader
gnus-util mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib
mail-prsvr mail-utils time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help
simple abbrev 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
dbusbind inotify dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 328862 259009)
 (symbols 48 124559 140)
 (miscs 40 296 1375)
 (strings 32 103437 18827)
 (string-bytes 1 3759223)
 (vectors 16 30278)
 (vector-slots 8 1105481 106154)
 (floats 8 590 1468)
 (intervals 56 8360 1572)
 (buffers 976 139)
 (heap 1024 91405 196420))

bug#23927: 25.0.94; Errors when updating using package.el

[Eli Zaretskii]

> From: Live System User <nyc4bos@aol.com>
> Date: Sat, 09 Jul 2016 00:17:03 -0400
> 
>         When updating a package `(package-menu-mark-upgrades)',
>         I got the following errors/warnings:
> 
> package-activate-1: Required feature ‘info’ was not provided

A recipe to reproduce this will be appreciated.  The 'info' feature
comes with Emacs, so the only way I could understand how this can
happen is that somehow load-path doesn't include the standard
directories when this code is run.  But why and how could that happen?

> Invalid face reference: package-status-builtin-face
> Invalid face reference: package-status-builtin-face [3 times]

A typo?  From package.el:

  (defface package-status-built-in
           ^^^^^^^^^^^^^^^^^^^^^^^
    '((t :inherit font-lock-builtin-face))
    "Face used on the status and version of built-in packages."
    :version "25.1")

  (defface package-status-external
    '((t :inherit package-status-builtin-face))
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    "Face used on the status and version of external packages."
    :version "25.1")

Would package.el gurus please take a look at this?  These sound like
very basic problems in package.el, so I'd hate to release 25.1 with
them.

bug#23927: 25.0.94; Errors when updating using package.el

[Glenn Morris]

Eli Zaretskii wrote:

>> package-activate-1: Required feature 'info' was not provided
>
> A recipe to reproduce this will be appreciated.  The 'info' feature
> comes with Emacs, so the only way I could understand how this can
> happen is that somehow load-path doesn't include the standard
> directories when this code is run. 

The above error actually means that the first "info.el" found in
load-path did not "(provide 'info)", not that no "info.el" was found.

> But why and how could that happen?

The OP has some broken info.el early in their load-path, presumably one
that isn't part of Emacs.

> A typo?  From package.el:

Looks like a clear typo.

>   (defface package-status-built-in

It is a shame this was named "built-in" (with hyphen), when compared to
the long-standing "font-lock-builtin-face" (without hyphen) from which
it inherits.

bug#23927: 25.0.94; Errors when updating using package.el

[Live System User]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Live System User <nyc4bos@aol.com>
>> Date: Sat, 09 Jul 2016 00:17:03 -0400
>> 
>>         When updating a package `(package-menu-mark-upgrades)',
>>         I got the following errors/warnings:
>> 
>> package-activate-1: Required feature ‘info’ was not provided
>
> A recipe to reproduce this will be appreciated.

0. In .emacs:

(add-to-list 'package-archives '(("melpa"
.                                 "https://melpa.org/packages/")))

(setq package-user-dir (expand-file-name "~/.emacs.d/elpa"))


1. M-x package-list-packages

2. I then typed "U" which executes `package-menu-mark-upgrades'

3. I then typed "x" which executes `package-menu-execute' to
   upgrade all installed packages, if any upgrades are available

   There was one package upgrade available.

   I then got the errors I am reporting.

>                                                  The 'info' feature
> comes with Emacs, so the only way I could understand how this can
> happen is that somehow load-path doesn't include the standard
> directories when this code is run.  But why and how could that happen?

  No idea.
>
>> Invalid face reference: package-status-builtin-face
>> Invalid face reference: package-status-builtin-face [3 times]
>
> A typo?  From package.el:
>
>   (defface package-status-built-in
>            ^^^^^^^^^^^^^^^^^^^^^^^
>     '((t :inherit font-lock-builtin-face))
>     "Face used on the status and version of built-in packages."
>     :version "25.1")
>
>   (defface package-status-external
>     '((t :inherit package-status-builtin-face))
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     "Face used on the status and version of external packages."
>     :version "25.1")
>
> Would package.el gurus please take a look at this?  These sound like
> very basic problems in package.el, so I'd hate to release 25.1 with
> them.

  Thanks.

bug#23927: 25.0.94; Errors when updating using package.el

[Live System User]

Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>
>>> package-activate-1: Required feature 'info' was not provided
>>
>> A recipe to reproduce this will be appreciated.  The 'info' feature
>> comes with Emacs, so the only way I could understand how this can
>> happen is that somehow load-path doesn't include the standard
>> directories when this code is run. 
>
> The above error actually means that the first "info.el" found in
> load-path did not "(provide 'info)", not that no "info.el" was found.
>
>> But why and how could that happen?
>
> The OP has some broken info.el early in their load-path, presumably one
> that isn't part of Emacs.

  There is a MELPA package I have installed called "realgud" that
  has the file:

      ~/.emacs.d/elpa/realgud/common/buffer/info.el(.elc)

  Perhaps package.el should deal with this type of issue, otherwise
  package authors will have to avoid naming their .el files names
  that are the same as (some) Emacs library names?

  I'll contact the author of "realgud".

>
>> A typo?  From package.el:
>
> Looks like a clear typo.
>
>>   (defface package-status-built-in
>
> It is a shame this was named "built-in" (with hyphen), when compared to
> the long-standing "font-lock-builtin-face" (without hyphen) from which
> it inherits.


  Thanks.

bug#23927: 25.0.94; Errors when updating using package.el

[Glenn Morris]

Live System User wrote:

>> The OP has some broken info.el early in their load-path, presumably one
>> that isn't part of Emacs.
>
>   There is a MELPA package I have installed called "realgud" that
>   has the file:
>
>       ~/.emacs.d/elpa/realgud/common/buffer/info.el(.elc)
>
>   Perhaps package.el should deal with this type of issue, otherwise
>   package authors will have to avoid naming their .el files names
>   that are the same as (some) Emacs library names?

Emacs uses a PATH-type lookup in which first match wins. Twas ever thus.
("Private" namespaces are possible using the subdirectory approach used
by eg cedet in Emacs.)

>>>   (defface package-status-built-in

I fixed this.

This issue is now resolved from the Emacs side.

bug#23927: 25.0.94; Errors when updating using package.el

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 879 bytes --]

On 2016-07-13 19:14, Glenn Morris wrote:
> Live System User wrote:
>>> The OP has some broken info.el early in their load-path, presumably one
>>> that isn't part of Emacs.
>>
>>   There is a MELPA package I have installed called "realgud" that
>>   has the file:
>>
>>       ~/.emacs.d/elpa/realgud/common/buffer/info.el(.elc)
>>
>>   Perhaps package.el should deal with this type of issue, otherwise
>>   package authors will have to avoid naming their .el files names
>>   that are the same as (some) Emacs library names?
> 
> Emacs uses a PATH-type lookup in which first match wins. Twas ever thus.
> ("Private" namespaces are possible using the subdirectory approach used
> by eg cedet in Emacs.)

Sorry, I didn't follow this very closely. I'm one of the Realgud maintainers; is there anything we can do on our side to make things smoother?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#23927: 25.0.94; Errors when updating using package.el

[Glenn Morris]

Clément Pit--Claudel wrote:

>>>       ~/.emacs.d/elpa/realgud/common/buffer/info.el(.elc)
[...]
> Sorry, I didn't follow this very closely. I'm one of the Realgud
> maintainers; is there anything we can do on our side to make things
> smoother?

Don't distribute files that live in load-path whose basename matches
an item in Emacs's load-path (or is likely to match that in some other
package). Else (require 'foo) may get the wrong foo.

(If common/buffer/ isn't supposed to be in load-path, then you are fine.)

bug#23927: 25.0.94; Errors when updating using package.el

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 212 bytes --]

On 2016-07-13 22:57, Glenn Morris wrote:
> (If common/buffer/ isn't supposed to be in load-path, then you are fine.)

I don't think it's expected to be, but I'll double check. Thanks for the clarification!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]