> The package description reads as:
>
>This package provides a small sample of UTF-8 locales mostly useful
>in test environments.
>
While true does not change that the name is, in my opinion, misleading.
> Perhaps it should simply be marked as a hidden package (not discoverable
> via
I prefer names to not be lying about what they are, despite any
documentation. It is a UX problem if the user has to search the
documentation for any given package name before installing it, just to make
sure that it contains what it says on the can so to speak.
The name glibc-utf8-locales when
Hi,
I have on different occasions had the issue of the package manager Guix
hinting that locales were not installed or that GUIX_LOCPATH was not set,
even though they were. Today I went to the bottom of the issue [0] and have
found what in my opinion is the root cause:
Despite its name, the
Hello rekado!
I saved your document in a file “doc.tex” and then ran this
> command successfully:
>
> guix environment --pure --ad-hoc \
> texlive-base \
> texlive-url \
> texlive-latex-hyperref \
> texlive-fonts-ec \
> texlive-lm \
> texlive-babel-swedish
Hi,
I'm trying to define a Guix environment that enables the following LaTeX
document to be compiled:
\documentclass[a4paper,12pt]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[swedish]{babel}
> \usepackage{url}
> \usepackage{color}
> \usepackage[colorlinks=true, linkcolor=blue,
Thank you for your kind help. Thanks to you Zimon and Adrianos who answered
off-list. I was able to whip up a patch that should help future users avoid
my confusion: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46805
Hi,
Today I encountered an issue with Guix's user interface. I was trying to
load a Scheme file defining a development environment with `guix
environment --ad-hoc --load=file.scm`, but Guix kept telling me that the
file did not exist even though I could swear it did:
> $ head -n 1
Hi again Leo!
That doesn't say much, because `guix environment` provides little
> isolation. You might try with pure environments, but the better way of
> replicating the build environment is using `-K`.
>
Ran in a `guix environment --pure --container` and it still built
successfully.
> I
wp4bzb8b-nomacs-3.16.224/lib"
"-DCMAKE_VERBOSE_MAKEFILE=ON" "-DENABLE_TRANSLATIO\
NS=true" "-DUSE_SYSTEM_QUAZIP=true" "-DENABLE_OPENCV=true"
make -j 8
./nomacs
For some reason that is different than when `guix package --from-file` runs.
Den fre 1 jan. 2021
Hi Leo and thank you for explaining. And hi again guix-devel.
I've now rewritten the file according to your comments except that its
still its own file/module, something I'll fix later.
Now I'm stuck trying to figure out a build error after going from the
tarball release through url-fetch to the
Hi Leo and thank you for your comments.
The nomacs package should probably go to gnu/packages/image-
> viewers.scm.
>
Yup.
> Use git-fetch instead and don't recurse into submodules. You will
> likely encounter some errors, because it doesn't seem as though nomacs
> expects you to have its
Hi,
I ended up working on a package for the image viewer Nomacs over Jul and
would like some feedback on what I've managed so far. One thing that's
missing is the plugins that are developed in a separate git repository [0]
and not included in the source tarballs of the main repository [1]. Ideas
From: Rovanion Luckey
Date: Tue, 15 Dec 2020 12:33:12 +0100
Subject: [PATCH] doc: contributing: Added detail to instructions on generating
pre-inst-env
The file ./configure does not exist before the new developer runs ./bootstrap.
---
doc/contributing.texi | 17 +
1 file changed, 9
13 matches
Mail list logo
