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