bug#45436: dino translations are not used

[Hartmut Goebel]

in dino@0.2.0 translations are not used.

While the package contains translations for quite some languages, these
are not used. When running dino under strace control I could not even
spot any access to any "locale" directory

Expected:

Translated strings are used

Reproduce:

 1. Install dino@0.2.0 (which is the current version as of this writing)
 2. Ensure you have LANG, LC_ALL, LC_MESSAGES and LANUAGE set to an
non-Englich locale
 3. Start dino under strace control: strace -f -e trace=file -o
/tmp/trace.txt dino
 4. Open the menu (left "hamburger")
 5. All texts are still English
 6. Inspect /tmp/trace.txt


-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#45165: binutils-mesboot0 fails at configure, cannot find lex

[Tom Hiller]

I also started to see this issue a few days ago.  The host is currently 
running a variant of Linux 5.9.14-arch1-1 and the docker image is 
Alpine:3.12.  I am not sure if this is helpful but if I remember 
correctly, I rebooted my machine in between the times I was last able to 
binutils-mesboot0 which probably loaded  Linux 5.9.14-arch1-1 into 
memory.  Before it would have been using Linux 5.9.11-arch2 
configuration.  Given the timeline, a change in Linux 5.9.12 or Linux 
5.9.13 may be the cause.

bug#45316: [PATCH]: Re-introduce Emacs packages specific installation prefix.

[Maxim Cournoyer]

Hi Leo!

Leo Prikler  writes:

> Hi Maxim,
>
> Am Dienstag, den 22.12.2020, 13:09 -0500 schrieb Maxim Cournoyer:
>> Hi Leo,
>>
>> Leo Prikler  writes:
>>
>> > Hello Maxim,
>> >
>> > As someone, who lobbied for the current status quo, I have some
>> > thoughts to share.
>>
>> I'm happy you're commenting :-).
>>
>> > Am Montag, den 21.12.2020, 22:28 -0500 schrieb Maxim Cournoyer:
>> > > The Emacs packages built with the Emacs built system used to be
>> > > installed in a sub-directory under the share/emacs/guix.d/
>> > > directory,
>> > > but this was changed in commit
>> > > 65a7dd2950ca13a8b942b2836260a2192351b271
>> > > shortly after having accommodated the site-start.el machinery to
>> > > enable
>> > > loading packages from any profile (via the EMACSLOADPATH search
>> > > path
>> > > specification).
>> > Won't this reintroduce  then?
>>
>> This bug was caused by the EMACSLOADPATH environment variable being
>> too
>> long.  This was because the original search path specification was
>> recursively adding any directories under site-lisp/ so that package
>> installed under a guix.d sub-directory could were directly added to
>> the
>> load path.
>>
>> In the current situation, the EMACSLOADPATH contains only the site-
>> lisp/
>> directory of any profile, plus the versioned lisp/ directory of the
>> installed Emacs package.  This patch series doesn't change that, so
>> no,
>> that bug wouldn't be reintroduced.

> Which is also the reason why our startup code changes and people have
> to accommodate to that, right?

Yes. The startup code is now responsible to activate packages found not
directly in the EMACSLOADPATH (share/emacs/site-lisp), but in
sub-directories under share/emacs/site-lisp/guix.

>> > > While this change allowed to expose simply and directly the
>> > > packages
>> > > found in EMACSLOADPATH, it does introduce the risk of file name
>> > > collisions when multiple Emacs packages are joined in the same
>> > > profile,
>> > > especially with Emacs packages increasing in complexity (e.g.,
>> > > using
>> > > more than a single .el file!) and expecting to have both their
>> > > sources
>> > > and resources extracted under their own nested directory rather
>> > > than
>> > > as
>> > > a flat collection (ELPA, MELPA).
>> > > One recent example I stumbled on was attempting to use the
>> > > emacs-yasnippet-snippets package along with emacs-elpy; both
>> > > wanted
>> > > to
>> > > install a 'snippets' directory to share/emacs/site-lisp/snippets,
>> > > collided and resulted in problems that prove difficult to
>> > > understand.
>> > I believe that to be a problem in those packages.  Data should not
>> > be
>> > installed into share/emacs/site-lisp, but share/emacs/etc.  See for
>> > instance also emacs-telega, which – while not quite adhering to the
>> > above – installs its data in share/emacs/{telega-contrib,telega-
>> > data}.
>> >
>> > Regardless of what you intend to do with site-lisp otherwise, data
>> > files should *not*, I repeat *not* be installed there.  I do
>> > believe
>> > standardizing share/emacs/etc is the way to go, however.
>>
>> While I agree that it would be more elegant the way you propose,
>> that's
>> not the way Emacs packages have been standardized.  So going against
>> the
>> sin--8<---cut here---start->8---
--8<---cut here---start->8---
gle "content directory" (c.f. info "(elisp) Packaging Basics")
>> would
>> break many Elisp library assumptions about where there files are,
>> causing more friction (thus work) to adapt them in Guix.  The content
>> directory of an Elisp package can contain any kind of files (code,
>> images, etc.), according to info "(elisp) Multi-file Packages".
>
> I suppose said manual is perhaps slightly outdated.

The doc/package.texi file of the Emacs git repository is actively
maintained, although cited contents above hasn't changed much for the
last 8 years.  In any case if you look into package.el, you'll see that
package contents are fetched as a single archived, and its content
installed to a single directory.

>> A package is either a “simple package” or a “multi-file package”.  A
>> simple package is stored in a package archive as a single Emacs Lisp
>> file, while a multi-file package is stored as a tar file (containing
>> multiple Lisp files, and possibly non-Lisp files such as a manual).
> When was the last time, you've installed a tar to site-lisp?  I also
> feel as though the expected contents are limited very much to README,
> COPYING and the like:
>
> $ find ~/.guix-profile/share/emacs/27.1/lisp/ -type f \
>   -not -name '*.el' \
>   -and -not -name '*.elc' \
>   -and -not -name '*.el.gz'
> ~/.guix-profile/share/emacs/27.1/lisp/term/README
> ~/.guix-profile/share/emacs/27.1/lisp/COPYING
> ~/.guix-profile/share/emacs/27.1/lisp/README

The lisp/ directory is for "the standard Lisp files that come with
Emacs" (from info "(elisp)Library Se

bug#45404: kiwix-desktop does not start

[宋文武]

Maxime Devos  writes:

> Hello Guix,

Hello!
>
> kiwix-desktop doesn't start. Depending on the environment, I get
> different error messages:
>
> Variant #A (pure environment, in GDM session)
> $ guix time-machine --commit=20a687bbfbc72ffcd802b4bc59db344ad4291577
> environment --ad-hoc --pure kiwix-desktop -- kiwix-desktop
With ‘–-pure’, the process will run in a container that doesn’t have
access to the X server, this is expected behavior.


> Variant #B (installed in user profile, in GDM session)
>
> $ kiwix-desktop
>
>> Could not find QtWebEngineProcess
This is a bug, look like kiwix-desktop should be wrapped with some
environment variables.  In the meantime, you can install qtwebengine and
qtbase into the profile, or use: guix environment --ad-hoc kiwix-desktop
qtbase qtwebengine -- kiwix-desktop