use-package not working

use-package not working

[Pedro A. Aranda Gutiérrez]

Hi,

I compiled emacs master yesterday and use-package doesn't work anymore.

When I compile emacs, I delete .emacs.d/elpa and .emacs.d/eln-cache to

I get error messages like:

Error (use-package): Failed to install compat: Wrong type argument: 
package-desc, nil
Error (use-package): Cannot load compat

for all packages, after they are downloaded from ELPA.


Bug reports don't work either except from

emacs -Q

  In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
  3.24.33, cairo version 1.16.0) of 2023-05-24 built on ac93448f1beb
Repository revision: b2b2be98da5825e6bc130999ffe38f5ed615586a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.2 LTS

Configured using:
  'configure --prefix=/usr --program-suffix=30 --with-json --with-x
  --with-x-toolkit=gtk3 --with-cairo --with-compress-install
  --with-modules=yes --with-threads --with-included-regex --with-zlib
  --with-tree-sitter=no --with-native-compilation=yes 'CFLAGS=-g -O2
  -ffile-prefix-map=/home/paag/emacs=. -flto=auto -ffat-lto-objects
  -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
  -Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
  'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects
  -flto=auto -Wl,-z,relro''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB

Important settings:
   value of $LC_MONETARY: es_ES.UTF-8
   value of $LC_NUMERIC: es_ES.UTF-8
   value of $LC_TIME: es_ES.UTF-8
   value of $LANG: en_GB.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
   tooltip-mode: t
   global-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
   buffer-read-only: 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:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib 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 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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 81546 9353)
  (symbols 48 7199 0)
  (strings 32 19683 2048)
  (string-bytes 1 576586)
  (vectors 16 15754)
  (vector-slots 8 328868 16272)
  (floats 8 29 54)
  (intervals 56 360 0)
  (buffers 976 12))

bug#63710: use-package not working

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> Date: Thu, 25 May 2023 07:47:59 +0200
> From: Pedro A. Aranda Gutiérrez <paaguti@gmail.com>
> 
> Hi,
> 
> I compiled emacs master yesterday and use-package doesn't work anymore.
> 
> When I compile emacs, I delete .emacs.d/elpa and .emacs.d/eln-cache to
> 
> I get error messages like:
> 
> Error (use-package): Failed to install compat: Wrong type argument: 
> package-desc, nil
> Error (use-package): Cannot load compat
> 
> for all packages, after they are downloaded from ELPA.
> 
> 
> Bug reports don't work either except from
> 
> emacs -Q
> 
>   In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>   3.24.33, cairo version 1.16.0) of 2023-05-24 built on ac93448f1beb
> Repository revision: b2b2be98da5825e6bc130999ffe38f5ed615586a
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
> System Description: Ubuntu 22.04.2 LTS

Thanks.  I don't see any recent changes to use-package, so bisecting
would be appreciated.

bug#63710: use-package not working

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

I reverted to

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2023-05-15 built on 7d6dc64325f6
Repository revision: ebf5e4ca1cd39d3f23c4e37d9bdfeb2bf347df6d
Repository branch: master

and that works correctly. Time permitting, I'll try to come closer to the
breakage point.
Currently under extreme time pressure... (exam season)

/PA

On Thu, 25 May 2023 at 09:01, Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: emacs-devel@gnu.org
> > Date: Thu, 25 May 2023 07:47:59 +0200
> > From: Pedro A. Aranda Gutiérrez <paaguti@gmail.com>
> >
> > Hi,
> >
> > I compiled emacs master yesterday and use-package doesn't work anymore.
> >
> > When I compile emacs, I delete .emacs.d/elpa and .emacs.d/eln-cache to
> >
> > I get error messages like:
> >
> > Error (use-package): Failed to install compat: Wrong type argument:
> > package-desc, nil
> > Error (use-package): Cannot load compat
> >
> > for all packages, after they are downloaded from ELPA.
> >
> >
> > Bug reports don't work either except from
> >
> > emacs -Q
> >
> >   In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> >   3.24.33, cairo version 1.16.0) of 2023-05-24 built on ac93448f1beb
> > Repository revision: b2b2be98da5825e6bc130999ffe38f5ed615586a
> > Repository branch: master
> > Windowing system distributor 'The X.Org Foundation', version
> 11.0.12101004
> > System Description: Ubuntu 22.04.2 LTS
>
> Thanks.  I don't see any recent changes to use-package, so bisecting
> would be appreciated.
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2791 bytes --]

bug#63710: use-package not working

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

Could free up a couple CPU cycles and last working commit for me is

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2023-05-25 built on 66fdd82711e1
Repository revision: 1d5b164109b59559d34c545c2a163fa067ca22b2
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.2 LTS

Best, /PA

On Thu, 25 May 2023 at 10:01, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> I reverted to
>
> In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.33, cairo version 1.16.0) of 2023-05-15 built on 7d6dc64325f6
> Repository revision: ebf5e4ca1cd39d3f23c4e37d9bdfeb2bf347df6d
> Repository branch: master
>
> and that works correctly. Time permitting, I'll try to come closer to the
> breakage point.
> Currently under extreme time pressure... (exam season)
>
> /PA
>
> On Thu, 25 May 2023 at 09:01, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > Cc: emacs-devel@gnu.org
>> > Date: Thu, 25 May 2023 07:47:59 +0200
>> > From: Pedro A. Aranda Gutiérrez <paaguti@gmail.com>
>> >
>> > Hi,
>> >
>> > I compiled emacs master yesterday and use-package doesn't work anymore.
>> >
>> > When I compile emacs, I delete .emacs.d/elpa and .emacs.d/eln-cache to
>> >
>> > I get error messages like:
>> >
>> > Error (use-package): Failed to install compat: Wrong type argument:
>> > package-desc, nil
>> > Error (use-package): Cannot load compat
>> >
>> > for all packages, after they are downloaded from ELPA.
>> >
>> >
>> > Bug reports don't work either except from
>> >
>> > emacs -Q
>> >
>> >   In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>> >   3.24.33, cairo version 1.16.0) of 2023-05-24 built on ac93448f1beb
>> > Repository revision: b2b2be98da5825e6bc130999ffe38f5ed615586a
>> > Repository branch: master
>> > Windowing system distributor 'The X.Org Foundation', version
>> 11.0.12101004
>> > System Description: Ubuntu 22.04.2 LTS
>>
>> Thanks.  I don't see any recent changes to use-package, so bisecting
>> would be appreciated.
>>
>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 4171 bytes --]

bug#63710: use-package not working

[Robert Pluim]

>>>>> On Thu, 25 May 2023 12:50:31 +0200, Pedro Andres Aranda Gutierrez <paaguti@gmail.com> said:

    Pedro> Could free up a couple CPU cycles and last working commit for me is
    Pedro> In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
    Pedro>  3.24.33, cairo version 1.16.0) of 2023-05-25 built on 66fdd82711e1
    Pedro> Repository revision: 1d5b164109b59559d34c545c2a163fa067ca22b2
    Pedro> Repository branch: HEAD
    Pedro> Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
    Pedro> System Description: Ubuntu 22.04.2 LTS

You mean 87da87730f9f69fa29a73ac504b690c40b1bc98f breaks this? That
seems very unlikely.

BTW, if you have a more-or-less cut down recipe for this, that would
help, since a simple

    (use-package "compat")

works fine for me.

Robert
-- 

bug#63710: use-package not working

[Eli Zaretskii]

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Thu, 25 May 2023 12:50:31 +0200
> Cc: 63710@debbugs.gnu.org
> 
> Could free up a couple CPU cycles and last working commit for me is
> 
> In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.33, cairo version 1.16.0) of 2023-05-25 built on 66fdd82711e1
> Repository revision: 1d5b164109b59559d34c545c2a163fa067ca22b2
> Repository branch: HEAD
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
> System Description: Ubuntu 22.04.2 LTS

You mean, the very next one, 87da87730f9f69fa29a73ac504b690c40b1bc98f,
already doesn't work?  But that only touched Tramp, so how can this
affect package.el and/or use-package?

Are you sure that 1d5b164109b59559d34c545c2a163fa067ca22b2 does work?
Could it be that this is the first commit that does NOT work?

Thanks.

bug#63710: use-package not working

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

First: the .emacs.d/init.el test file

------
;;
;; My .emacs file
;;
(require 'package)
(setq package-archives '(("melpa" . "https://melpa.org/packages/")
("gnu" . "https://elpa.gnu.org/packages/")
                         ("melpa-stable" . "
https://stable.melpa.org/packages/")
("nongnu" . "https://elpa.nongnu.org/nongnu/")))
(eval-when-compile
  (require 'use-package))
(unless (file-directory-p package-user-dir)
    (package-refresh-contents))
(require 'use-package-ensure)
(setq use-package-always-ensure t)

(use-package "compat")
------

Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work

BTW,  it has to do with native compilation. I have accidentally not deleted
the eln-cache in on of the tests and the 'wrong' Emacs has started
correctly:
1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache
---> OK
2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from the
last start --> OK
3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache
---> KO



On Thu, 25 May 2023 at 13:36, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> > Date: Thu, 25 May 2023 12:50:31 +0200
> > Cc: 63710@debbugs.gnu.org
> >
> > Could free up a couple CPU cycles and last working commit for me is
> >
> > In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> >  3.24.33, cairo version 1.16.0) of 2023-05-25 built on 66fdd82711e1
> > Repository revision: 1d5b164109b59559d34c545c2a163fa067ca22b2
> > Repository branch: HEAD
> > Windowing system distributor 'The X.Org Foundation', version
> 11.0.12101004
> > System Description: Ubuntu 22.04.2 LTS
>
> You mean, the very next one, 87da87730f9f69fa29a73ac504b690c40b1bc98f,
> already doesn't work?  But that only touched Tramp, so how can this
> affect package.el and/or use-package?
>
> Are you sure that 1d5b164109b59559d34c545c2a163fa067ca22b2 does work?
> Could it be that this is the first commit that does NOT work?
>
> Thanks.
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 3897 bytes --]

bug#63710: use-package not working

[Eli Zaretskii]

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Thu, 25 May 2023 14:42:48 +0200
> Cc: 63710@debbugs.gnu.org
> 
> BTW,  it has to do with native compilation. I have accidentally not deleted the eln-cache in on of the
> tests and the 'wrong' Emacs has started correctly:
> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache ---> OK
> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from the last start --> OK
> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache ---> KO

So this likely has nothing to do with use-package, but rather with the
latest changes in native compilation.  There are already bug reports
about that, and I'm sure Andrea will fix the problems soon enough.

bug#63710: use-package not working

[Andrea Corallo]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> First: the .emacs.d/init.el test file
>
> ------
> ;;
> ;; My .emacs file
> ;;
> (require 'package)
> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
> ("gnu" . "https://elpa.gnu.org/packages/")
>                          ("melpa-stable" . "https://stable.melpa.org/packages/")
> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
> (eval-when-compile
>   (require 'use-package))
> (unless (file-directory-p package-user-dir)
>     (package-refresh-contents))
> (require 'use-package-ensure)
> (setq use-package-always-ensure t)
>
> (use-package "compat")
> ------
>
> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
>
> BTW,  it has to do with native compilation. I have accidentally not deleted the eln-cache in on of the tests and the
> 'wrong' Emacs has started correctly:
> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache ---> OK
> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from the last start --> OK
> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache ---> KO

From these SHA1s looks like there's good chance it's my fault...

I'll have a look.

Thanks

  Andrea

bug#63710: use-package not working

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

No worries, just let me know how I can help when and if I have a free cycle
:-)

/PA

On Thu, 25 May 2023 at 15:13, Andrea Corallo <akrl@sdf.org> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > First: the .emacs.d/init.el test file
> >
> > ------
> > ;;
> > ;; My .emacs file
> > ;;
> > (require 'package)
> > (setq package-archives '(("melpa" . "https://melpa.org/packages/")
> > ("gnu" . "https://elpa.gnu.org/packages/")
> >                          ("melpa-stable" . "
> https://stable.melpa.org/packages/")
> > ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
> > (eval-when-compile
> >   (require 'use-package))
> > (unless (file-directory-p package-user-dir)
> >     (package-refresh-contents))
> > (require 'use-package-ensure)
> > (setq use-package-always-ensure t)
> >
> > (use-package "compat")
> > ------
> >
> > Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
> >
> > BTW,  it has to do with native compilation. I have accidentally not
> deleted the eln-cache in on of the tests and the
> > 'wrong' Emacs has started correctly:
> > 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache
> ---> OK
> > 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from
> the last start --> OK
> > 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache
> ---> KO
>
> From these SHA1s looks like there's good chance it's my fault...
>
> I'll have a look.
>
> Thanks
>
>   Andrea
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2986 bytes --]

bug#63710: use-package not working

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
>> First: the .emacs.d/init.el test file
>>
>> ------
>> ;;
>> ;; My .emacs file
>> ;;
>> (require 'package)
>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
>> ("gnu" . "https://elpa.gnu.org/packages/")
>>                          ("melpa-stable" . "https://stable.melpa.org/packages/")
>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
>> (eval-when-compile
>>   (require 'use-package))
>> (unless (file-directory-p package-user-dir)
>>     (package-refresh-contents))
>> (require 'use-package-ensure)
>> (setq use-package-always-ensure t)
>>
>> (use-package "compat")
>> ------
>>
>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
>>
>> BTW,  it has to do with native compilation. I have accidentally not deleted the eln-cache in on of the tests and the
>> 'wrong' Emacs has started correctly:
>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache ---> OK
>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from the last start --> OK
>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache ---> KO
>
>>From these SHA1s looks like there's good chance it's my fault...
>
> I'll have a look.

Okay I did some investigation and understood the issue.

`package-load-descriptor' was misscompiled and returning always nil as
the compiler was not fully picking up the user defined types at compile
time, it worked only after the first faulty compilation (thing that made
the investigaiton a bit slower).

I'm working on a more complete fix but this requires careful testing, I
pushed now c8e527cbeee in order to have master stable again while I keep
working on the most comprehensive fix.

Best regards

  Andrea

bug#63710: use-package not working

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>>
>>> First: the .emacs.d/init.el test file
>>>
>>> ------
>>> ;;
>>> ;; My .emacs file
>>> ;;
>>> (require 'package)
>>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
>>> ("gnu" . "https://elpa.gnu.org/packages/")
>>>                          ("melpa-stable" . "https://stable.melpa.org/packages/")
>>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
>>> (eval-when-compile
>>>   (require 'use-package))
>>> (unless (file-directory-p package-user-dir)
>>>     (package-refresh-contents))
>>> (require 'use-package-ensure)
>>> (setq use-package-always-ensure t)
>>>
>>> (use-package "compat")
>>> ------
>>>
>>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
>>>
>>> BTW,  it has to do with native compilation. I have accidentally not deleted the eln-cache in on of the tests and the
>>> 'wrong' Emacs has started correctly:
>>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache ---> OK
>>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from the last start --> OK
>>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache ---> KO
>>
>>>From these SHA1s looks like there's good chance it's my fault...
>>
>> I'll have a look.
>
> Okay I did some investigation and understood the issue.
>
> `package-load-descriptor' was misscompiled and returning always nil as
> the compiler was not fully picking up the user defined types at compile
> time, it worked only after the first faulty compilation (thing that made
> the investigaiton a bit slower).
>
> I'm working on a more complete fix but this requires careful testing, I
> pushed now c8e527cbeee in order to have master stable again while I keep
> working on the most comprehensive fix.

Hi all,

I pushed what I think is the final fix and reverted the temporary one.

As of fbc96dcc4ea I'm not aware of any issue with package.el or other
code.

Please let us know if works for you and we can close the bug or, if any
other issue arise (please remember to clean the eln-cache before testing
as it may contain misscompiled code ;).

Thanks

  Andrea

bug#63710: use-package not working

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>>
>>> First: the .emacs.d/init.el test file
>>>
>>> ------
>>> ;;
>>> ;; My .emacs file
>>> ;;
>>> (require 'package)
>>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
>>> ("gnu" . "https://elpa.gnu.org/packages/")
>>>                          ("melpa-stable" . "https://stable.melpa.org/packages/")
>>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
>>> (eval-when-compile
>>>   (require 'use-package))
>>> (unless (file-directory-p package-user-dir)
>>>     (package-refresh-contents))
>>> (require 'use-package-ensure)
>>> (setq use-package-always-ensure t)
>>>
>>> (use-package "compat")
>>> ------
>>>
>>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
>>>
>>> BTW,  it has to do with native compilation. I have accidentally not deleted the eln-cache in on of the tests and the
>>> 'wrong' Emacs has started correctly:
>>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache ---> OK
>>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from the last start --> OK
>>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache ---> KO
>>
>>>From these SHA1s looks like there's good chance it's my fault...
>>
>> I'll have a look.
>
> Okay I did some investigation and understood the issue.
>
> `package-load-descriptor' was misscompiled and returning always nil as
> the compiler was not fully picking up the user defined types at compile
> time, it worked only after the first faulty compilation (thing that made
> the investigaiton a bit slower).
>
> I'm working on a more complete fix but this requires careful testing, I
> pushed now c8e527cbeee in order to have master stable again while I keep
> working on the most comprehensive fix.

Okay RE-sending from this account and ditching my sdf.org probably
forever as I'm getting a bunch of bounces classifying it again as spam:

Hi all,

I pushed what I think is the final fix and reverted the temporary one.

As of fbc96dcc4ea I'm not aware of any issue with package.el or other
code.

Please let us know if works for you and we can close the bug or, if any
other issue arise (please remember to clean the eln-cache before testing
as it may contain misscompiled code ;).

Thanks

  Andrea

bug#63710: use-package not working

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

OK, I'll try right now and let you know.

/PA

On Mon, 29 May 2023 at 18:21, Andrea Corallo <acorallo@gnu.org> wrote:

> Andrea Corallo <akrl@sdf.org> writes:
>
> > Andrea Corallo <akrl@sdf.org> writes:
> >
> >> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> >>
> >>> First: the .emacs.d/init.el test file
> >>>
> >>> ------
> >>> ;;
> >>> ;; My .emacs file
> >>> ;;
> >>> (require 'package)
> >>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
> >>> ("gnu" . "https://elpa.gnu.org/packages/")
> >>>                          ("melpa-stable" . "
> https://stable.melpa.org/packages/")
> >>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
> >>> (eval-when-compile
> >>>   (require 'use-package))
> >>> (unless (file-directory-p package-user-dir)
> >>>     (package-refresh-contents))
> >>> (require 'use-package-ensure)
> >>> (setq use-package-always-ensure t)
> >>>
> >>> (use-package "compat")
> >>> ------
> >>>
> >>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
> >>>
> >>> BTW,  it has to do with native compilation. I have accidentally not
> deleted the eln-cache in on of the tests and the
> >>> 'wrong' Emacs has started correctly:
> >>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean
> cache ---> OK
> >>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache
> from the last start --> OK
> >>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean
> eln-cache ---> KO
> >>
> >>>From these SHA1s looks like there's good chance it's my fault...
> >>
> >> I'll have a look.
> >
> > Okay I did some investigation and understood the issue.
> >
> > `package-load-descriptor' was misscompiled and returning always nil as
> > the compiler was not fully picking up the user defined types at compile
> > time, it worked only after the first faulty compilation (thing that made
> > the investigaiton a bit slower).
> >
> > I'm working on a more complete fix but this requires careful testing, I
> > pushed now c8e527cbeee in order to have master stable again while I keep
> > working on the most comprehensive fix.
>
> Okay RE-sending from this account and ditching my sdf.org probably
> forever as I'm getting a bunch of bounces classifying it again as spam:
>
> Hi all,
>
> I pushed what I think is the final fix and reverted the temporary one.
>
> As of fbc96dcc4ea I'm not aware of any issue with package.el or other
> code.
>
> Please let us know if works for you and we can close the bug or, if any
> other issue arise (please remember to clean the eln-cache before testing
> as it may contain misscompiled code ;).
>
> Thanks
>
>   Andrea
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 4693 bytes --]

bug#63710: use-package not working

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 3662 bytes --]

OK, first tests are very encouraging. During the 'hick-up' I saw many
strange things happening which now seem to have gone.
Just as an example, emacs froze when I was resizing the screen and eglot
and jinx did what they wanted,not what I needed ;-)

I'll continue testing and let you know if something comes across,
Best, /PA

On Tue, 30 May 2023 at 09:55, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> OK, I'll try right now and let you know.
>
> /PA
>
> On Mon, 29 May 2023 at 18:21, Andrea Corallo <acorallo@gnu.org> wrote:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>> > Andrea Corallo <akrl@sdf.org> writes:
>> >
>> >> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>> >>
>> >>> First: the .emacs.d/init.el test file
>> >>>
>> >>> ------
>> >>> ;;
>> >>> ;; My .emacs file
>> >>> ;;
>> >>> (require 'package)
>> >>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
>> >>> ("gnu" . "https://elpa.gnu.org/packages/")
>> >>>                          ("melpa-stable" . "
>> https://stable.melpa.org/packages/")
>> >>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
>> >>> (eval-when-compile
>> >>>   (require 'use-package))
>> >>> (unless (file-directory-p package-user-dir)
>> >>>     (package-refresh-contents))
>> >>> (require 'use-package-ensure)
>> >>> (setq use-package-always-ensure t)
>> >>>
>> >>> (use-package "compat")
>> >>> ------
>> >>>
>> >>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
>> >>>
>> >>> BTW,  it has to do with native compilation. I have accidentally not
>> deleted the eln-cache in on of the tests and the
>> >>> 'wrong' Emacs has started correctly:
>> >>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean
>> cache ---> OK
>> >>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache
>> from the last start --> OK
>> >>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean
>> eln-cache ---> KO
>> >>
>> >>>From these SHA1s looks like there's good chance it's my fault...
>> >>
>> >> I'll have a look.
>> >
>> > Okay I did some investigation and understood the issue.
>> >
>> > `package-load-descriptor' was misscompiled and returning always nil as
>> > the compiler was not fully picking up the user defined types at compile
>> > time, it worked only after the first faulty compilation (thing that made
>> > the investigaiton a bit slower).
>> >
>> > I'm working on a more complete fix but this requires careful testing, I
>> > pushed now c8e527cbeee in order to have master stable again while I keep
>> > working on the most comprehensive fix.
>>
>> Okay RE-sending from this account and ditching my sdf.org probably
>> forever as I'm getting a bunch of bounces classifying it again as spam:
>>
>> Hi all,
>>
>> I pushed what I think is the final fix and reverted the temporary one.
>>
>> As of fbc96dcc4ea I'm not aware of any issue with package.el or other
>> code.
>>
>> Please let us know if works for you and we can close the bug or, if any
>> other issue arise (please remember to clean the eln-cache before testing
>> as it may contain misscompiled code ;).
>>
>> Thanks
>>
>>   Andrea
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 5962 bytes --]

bug#63710: use-package not working

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Andrea Corallo <akrl@sdf.org> writes:
>>
>>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>>>
>>>> First: the .emacs.d/init.el test file
>>>>
>>>> ------
>>>> ;;
>>>> ;; My .emacs file
>>>> ;;
>>>> (require 'package)
>>>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
>>>> ("gnu" . "https://elpa.gnu.org/packages/")
>>>>                          ("melpa-stable" . "https://stable.melpa.org/packages/")
>>>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
>>>> (eval-when-compile
>>>>   (require 'use-package))
>>>> (unless (file-directory-p package-user-dir)
>>>>     (package-refresh-contents))
>>>> (require 'use-package-ensure)
>>>> (setq use-package-always-ensure t)
>>>>
>>>> (use-package "compat")
>>>> ------
>>>>
>>>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
>>>>
>>>> BTW,  it has to do with native compilation. I have accidentally not deleted the eln-cache in on of the tests and the
>>>> 'wrong' Emacs has started correctly:
>>>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean cache ---> OK
>>>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache from the last start --> OK
>>>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean eln-cache ---> KO
>>>
>>>>From these SHA1s looks like there's good chance it's my fault...
>>>
>>> I'll have a look.
>>
>> Okay I did some investigation and understood the issue.
>>
>> `package-load-descriptor' was misscompiled and returning always nil as
>> the compiler was not fully picking up the user defined types at compile
>> time, it worked only after the first faulty compilation (thing that made
>> the investigaiton a bit slower).
>>
>> I'm working on a more complete fix but this requires careful testing, I
>> pushed now c8e527cbeee in order to have master stable again while I keep
>> working on the most comprehensive fix.
>
> Okay RE-sending from this account and ditching my sdf.org probably
> forever as I'm getting a bunch of bounces classifying it again as spam:
>
> Hi all,
>
> I pushed what I think is the final fix and reverted the temporary one.
>
> As of fbc96dcc4ea I'm not aware of any issue with package.el or other
> code.
>
> Please let us know if works for you and we can close the bug or, if any
> other issue arise (please remember to clean the eln-cache before testing
> as it may contain misscompiled code ;).

Okay one week passed since the fix was pushed and no more issues were
reported on this, so I'm closing it.  Happy to reopen in case.

BR

  Andrea

bug#63710: use-package not working

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]

HI,
I was going to suggest it. I have rebuilt emacs w/native today and it seems
to be stable.

Thanks! /PA

On Mon, 5 Jun 2023 at 10:36, Andrea Corallo <acorallo@gnu.org> wrote:

> Andrea Corallo <acorallo@gnu.org> writes:
>
> > Andrea Corallo <akrl@sdf.org> writes:
> >
> >> Andrea Corallo <akrl@sdf.org> writes:
> >>
> >>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
> >>>
> >>>> First: the .emacs.d/init.el test file
> >>>>
> >>>> ------
> >>>> ;;
> >>>> ;; My .emacs file
> >>>> ;;
> >>>> (require 'package)
> >>>> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
> >>>> ("gnu" . "https://elpa.gnu.org/packages/")
> >>>>                          ("melpa-stable" . "
> https://stable.melpa.org/packages/")
> >>>> ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
> >>>> (eval-when-compile
> >>>>   (require 'use-package))
> >>>> (unless (file-directory-p package-user-dir)
> >>>>     (package-refresh-contents))
> >>>> (require 'use-package-ensure)
> >>>> (setq use-package-always-ensure t)
> >>>>
> >>>> (use-package "compat")
> >>>> ------
> >>>>
> >>>> Second: 1d5b164109b59559d34c545c2a163fa067ca22b2 does work
> >>>>
> >>>> BTW,  it has to do with native compilation. I have accidentally not
> deleted the eln-cache in on of the tests and the
> >>>> 'wrong' Emacs has started correctly:
> >>>> 1. started 1d5b164109b59559d34c545c2a163fa067ca22b2 with eln-clean
> cache ---> OK
> >>>> 2. started b2b2be98da5825e6bc130999ffe38f5ed615586a with eln-cache
> from the last start --> OK
> >>>> 3. started b2b2be98da5825e6bc130999ffe38f5ed615586a with clean
> eln-cache ---> KO
> >>>
> >>>>From these SHA1s looks like there's good chance it's my fault...
> >>>
> >>> I'll have a look.
> >>
> >> Okay I did some investigation and understood the issue.
> >>
> >> `package-load-descriptor' was misscompiled and returning always nil as
> >> the compiler was not fully picking up the user defined types at compile
> >> time, it worked only after the first faulty compilation (thing that made
> >> the investigaiton a bit slower).
> >>
> >> I'm working on a more complete fix but this requires careful testing, I
> >> pushed now c8e527cbeee in order to have master stable again while I keep
> >> working on the most comprehensive fix.
> >
> > Okay RE-sending from this account and ditching my sdf.org probably
> > forever as I'm getting a bunch of bounces classifying it again as spam:
> >
> > Hi all,
> >
> > I pushed what I think is the final fix and reverted the temporary one.
> >
> > As of fbc96dcc4ea I'm not aware of any issue with package.el or other
> > code.
> >
> > Please let us know if works for you and we can close the bug or, if any
> > other issue arise (please remember to clean the eln-cache before testing
> > as it may contain misscompiled code ;).
>
> Okay one week passed since the fix was pushed and no more issues were
> reported on this, so I'm closing it.  Happy to reopen in case.
>
> BR
>
>   Andrea
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 5280 bytes --]