Hello Lars,
thanks for the patch! Concerning "Machine characteristics", I see it only
in petscmachineinfo.h, so we can probably drop looking for petscconf.h
in find-files.
There is already the cleaning phase 'clean-install after 'install.
So I would either suggest to keep the phase
Hello,
it looks like the dark green colour is wrongly chosen in QA,
for instance here:
https://qa.guix.gnu.org/issue/69441
The issue has been reviewed, but "Comparison unavailable
Yet to process revision".
I think dark green should only appear when the package is reviewed
AND builds correctly
Hello,
I installed guix-build-coordinator-agent-only into my user profile to try
it out, and wondered today why "guix build" would build the wrong version
of a software; then why "guix describe" showed a wrong date; until I
realised that the package propagates guix, and that the thus propagated
After reading through the first tenth of what seems to be an interesting
discussion and skimming through the remainder, I take the liberty to close
this bug. Such a discussion had better take place on guix-devel; the report
itself does not start with an actionable proposal: "People need to..."
Am Tue, Feb 06, 2024 at 09:22:43AM -0500 schrieb Maxim Cournoyer:
> Thanks for the report. It occurred a few times in the past weeks, where
> the 'mumi' service had to be restarted on Berlin. Let's keep this open
> to see if it'll occur again. Otherwise I'll close it in a week or two.
It has
My mail client has secretly updated the file while I was carrying out
the experiment; the attached version should be the one before refreshing.
Andreas
(define-module (example)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix download)
#:use-module (guix packages)
Hello,
to reproduce this weird (and very specific!) problem, do the following:
cd /tmp
mkdir proj
copy the attached example.scm into /tmp/proj
Now
guix refresh -u -L proj python-numpy-illustrated
yields the error
proj/example.scm:10:2: python-numpy-illustrated: updating from version 0.3
reopen 57402
thanks
Sorry, this was a mistake.
Andreas
Hopefully really closing the bug this time.
Andreas
Since we are at nextcloud@3.8.2 right now, the issue should have disappeared;
closing it.
Thanks for the report and the helpful comments!
Andreas
Hello,
this has most likely been solved by either the new monolithic texlive
package, or the vastly expanded modular texlive. So I am closing the report,
please reopen it if the problem persists.
Thanks for the report,
Andreas
Hello,
has there been any progress on this? Is there a way forward, or should
we close the issue?
Andreas
Closing the bug, as the immediate problem appears to be solved,
and handling of transient network failures is discussed in other issues.
Thanks for your report,
Andreas
Hello,
the monolithic texlive package should not be mixed with additional
texlive packages. With the recent remodelling of the texlive packages,
it would be better to install something like texlive-scheme-medium
instead. Eventually we aim for reaching a metapackage for a full
texlive installation
Hello,
as far as I can tell, this report is not relevant any more to the current
modular texlive build system, so I am closing it.
Please reopen it if anything remains to be addressed.
Andreas
This has probably been solved for a while, closing.
Thanks for the report!
Andreas
Hello,
this bug has probably been addressed by the recent changes to texlive,
so I am closing it. If you still experience problems, please come back
to us, reopen the report or create a new one.
Thanks for your report!
Andreas
Hello,
I can confirm that the same problem presents itself on
guix 9896b37
Repository-URL: https://git.savannah.gnu.org/git/guix.git
Branch: master
Commit: 9896b37ac53e9b0504de55dd5ba4bfa2c241a7ed
of August 17.
A likely culprit is
commit 3481a5cb37cacbb54f74a2b1fa52ffc5c972b09f
Am Wed, Aug 09, 2023 at 05:54:07PM +0800 schrieb 宋文武:
> Yes, kmessagelib build fine now.
As this has been merged to master now, I am closing the bug.
Thank you!
Andreas
Am Thu, Aug 17, 2023 at 03:17:55PM +0200 schrieb Nicolas Goaziou:
> I think it is simpler to to use a new module, as there's currently much
> work going on in "tex.scm".
As nothing depends on it, I have just pushed the changes to master and
deleted the wip branch. Thanks for your comments,
Am Thu, Aug 17, 2023 at 01:54:58PM +0200 schrieb Andreas Enge:
> Okay then, fine to remove biber again!
Done in wip-texlive-mono. I also dropped disabling tests for mips64,
as anyway we have no means of testing the architecture any more, so I see
no point in complicating the build recipe.
Wh
Am Sun, Aug 13, 2023 at 10:48:16PM +0200 schrieb Nicolas Goaziou:
> I don't know if the monolithic texlive from the wip branch does, but the
> current monolithic `texlive' can be installed without fuss alongside
> `texlive-biber'. I don't expect additional issues with `texlive' from
> the "wip"
Hello,
Am Wed, Aug 09, 2023 at 06:35:22PM +0200 schrieb Nicolas Goaziou:
> It would be nice to list what simplifications can be done on
> `texlive-bin', so we can apply them on a new "texlive-team" branch.
see the last commit on the wip-texlive-mono branch; the commit message
and the diff should
Closing an old bug report, as it is unlikely we will receive more info.
Andreas
Am Mon, Aug 07, 2023 at 06:16:04PM +0200 schrieb Andreas Enge:
> Two phases and the --with-system-libgs configure flag can be dropped
> (which will also be the case for the modular package).
And two more tests can also be dropped; I have compiled the package
successfully on i686 and armhf w
Hello,
my suggestion for the monolithic texlive package is in the branch
wip-texlive-mono. It is now updated to the latest version from 2023.
Two phases and the --with-system-libgs configure flag can be dropped
(which will also be the case for the modular package).
So far, everything is in a
Am Thu, Jul 27, 2023 at 12:59:21PM +0200 schrieb Andreas Enge:
> PS: While trying to push I noticed that there is a branch wip-texlive
> from January 2022; I suppose this can be deleted now?
Done. The branch appears to have been merged around that time.
Andreas
Hello,
Am Thu, Jul 27, 2023 at 11:55:01AM +0200 schrieb Nicolas Goaziou:
> I'm sorry as I have limited time and bandwidth right now to help you
> solve this issue. It doesn't seem too bad, tho.
no problem, this is also my last day before vacations.
> I think this may be fixed by tweaking
Hello again,
Am Wed, Jul 26, 2023 at 09:51:49PM +0200 schrieb Andreas Enge:
> Would it be feasible to revert these commits, or is everything too
> mixed now?
I confirm that going back to commit
0561616a3208aa17fe5b1f9c425c44fe00218b08 ,
which is one
Am Wed, Jul 26, 2023 at 08:17:02PM +0200 schrieb Andreas Enge:
> Oh wait...
> Before:
> $ ll $HOME/.guix-profile/share/texmf-dist/ls-R
> -r--r--r-- 5 root root 4812162 1. Jan 1970
> /home/andreas/.guix-profile/share/texmf-dist/ls-R
> After:
> lrwxrwxrwx 1 root root 82
Am Wed, Jul 26, 2023 at 06:33:51PM +0200 schrieb Andreas Enge:
> > You seem to have some clues about the slowness; you reported there are
> > too many symlinks in monolithic TeX Live. This is not intended and
> > should be fixed.
> Clues, yes, but not a full understanding yet
Hello!
Am Wed, Jul 26, 2023 at 05:25:59PM +0200 schrieb Nicolas Goaziou:
> This should still be the same. The main difference is that `texlive-bin'
> was renamed `texlive-bin-full'. Any other change was probably not intended.
Okay, I understand. It looks like there was another change, but I do
Am Wed, Jul 26, 2023 at 04:51:06PM +0200 schrieb Nicolas Goaziou:
> Would it be possible to remove the ".texlive2023" directory?
Yes. Compilation works now, but I still cannot install texlive and
texlive-biber concurrently, and the incredible slowness also remains.
Andreas
Hello,
Am Tue, Jul 25, 2023 at 12:09:06AM +0200 schrieb Ricardo Wurmus:
> > I can't find the format file `pdflatex.fmt'!
> This sounds like a sibling of https://issues.guix.gnu.org/64729
it looks similar indeed. But notice that I use the monolithic package
"texlive".
And I just tried it again
This patch updates wget to the latest release version and replaces the
self-hosted tarball we introduced to enable the core-updates merge.
I built a few random dependent packages.
"guix refresh -l" shows 974 dependent packages; nevertheless, if QA is not
too busy, it would be nice to build it
Patch attached.
Andreas
>From 12e010849549aa6810fd57dacd566d7ff9b8662c Mon Sep 17 00:00:00 2001
Message-ID:
<12e010849549aa6810fd57dacd566d7ff9b8662c.1690199971.git.andr...@enge.fr>
From: Andreas Enge
Date: Mon, 24 Jul 2023 13:58:14 +0200
Subject: [PATCH] gnu: wget: Update to 1.21.
Hello,
below are more details on the current test failure of python-dolfin-adjoint
version 2019.1.0. Maybe an option would be to try to update to a newer
version? There is 2019.1.2.
Andreas
=== FAILURES ===
Well, it looks like all of texlive broke for me. In a profile with texlive,
I now get this:
$ pdflatex xyz.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/GNU Guix)
(preloaded format=pdflatex)
restricted \write18 enabled.
kpathsea: Running mktexfmt pdflatex.fmt
mktexfmt:
Hello,
the latest texlive update (cudos!) has left texlive-biber broken, at least
in conjunction with the monolithic texlive:
$ guix shell texlive texlive-biber
The following derivation will be built:
/gnu/store/b2dzc8ayda5dp53s5dq40v0f41290b4c-profile.drv
building CA certificate bundle...
I get a text box with a similar, but not the same error:
Traceback (most recent call last):
File
"/gnu/store/zjc4ijkrrp1b9v1va40a3fki0gkgcp6w-inkscape-1.2.1/share/inkscape/extensions/inkex/gui/__init__.py",
line 38, in
import gi
ModuleNotFoundError: No module named 'gi'
During handling
In current master, webrtc-for-telegram-desktop-0-328.5098730 builds.
Closing.
Andreas
Hello,
Am Mon, Jul 10, 2023 at 11:38:47PM +0200 schrieb Ludovic Courtès:
> Is there any more data you can grab? Perhaps in
> /var/log/guix-daemon.log or similar if that’s on a foreign distro?
it is a GNU system virtual machine. And I have this in /var/log/messages:
Jul 19 11:57:51 localhost
Am Fri, Jul 07, 2023 at 04:09:13PM +0200 schrieb Ludovic Courtès:
> Is it reproducible for you? Could it be a transient failure?
It is not transient, it happens consistently.
Can I do anything myself to trick it into working?
Andreas
Hello,
here is what happens on a server I do not manage to update for about a year now:
$ guix pull
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 1bc878d (1,055 new commits)...
Building from this
Hello Andy,
Am Tue, May 30, 2023 at 10:54:20AM -0700 schrieb Andy Tai:
> Hi, following previous comments (thanks) I have submitted a patch to
> correctly fix a build failure due to compiler warnings, instead of
> avoiding not building tests, on this Guix bug issue:
>
Am Sat, May 20, 2023 at 06:12:47PM +0200 schrieb Ludovic Courtès:
> > The closure size reduction is substantial:
> > $ ./pre-inst-env guix size graphviz | tail -1
> > total: 183.6 MiB
> > $ guix size graphviz | tail -1
> > total: 242.3 MiB
> > But I suspect we’d still need the full-blown variant
When working on a branch and deciding whether to merge it, we need a way
of comparing its status with that of the master branch. As far as I can see,
there is currently no way in cuirass to compare arbitrary evaluations and
get a list (or a dashboard) of builds that fail in one, but not the other.
Stopping and starting builds in cuirass is not very comfortable.
When working on core-updates, I stopped builds for some old evaluations
on aarch64, where our build power would not be enough, assuming that many
of the old builds were made obsolete by newer changes. (For instance,
these could be
This is a wishlist bug, but it is important for architectures where we
are currently short on build power, and where this issue can stall builds
and waste an arbitrary amount of build power.
Cuirass should sort builds and only offload derivations for which all
inputs are available.
In my current
Am Wed, Apr 26, 2023 at 08:39:59PM +0200 schrieb Josselin Poiret:
> This would check the store path's references, but not necessarily all of
> its inputs! I would hope that no package with docs ever keeps
> references to texlive.
Indeed! But here these are also the (native) inputs.
Andreas
Hello,
Am Wed, Apr 26, 2023 at 06:59:44PM +0200 schrieb Liliana Marie Prikler:
> Having built glib from scratch more often than is fun, I am quite
> certain that the package pulling in our graphics stack is texinfo with
> its reference to texlive.
where do you see this?
$ guix gc --references
Am Tue, Apr 25, 2023 at 11:48:05PM +0200 schrieb Ludovic Courtès:
> This is apparently coming from Graphviz
> Surprising to me, but apparently it’s been this way from the start,
> commit b1b07d72c755ea314fb0c8333cd88293ee504ce4 (2013!).
> Maybe these are optional dependencies?
So "guix pull"
Am Tue, Apr 25, 2023 at 08:23:22PM +0200 schrieb Ludovic Courtès:
> I probably missed important items, maybe build system changes?
Honestly, I do not know... Version updates all over the place.
But I do not know earth shattering ones. These should come in the
feature branches now.
Andreas
Closing this bug, the topic is treated through the patches in
https://issues.guix.gnu.org/62967
Andreas
Core-updates has been merged, and hopefully addresses all your problems.
If some remain, please feel free to open new issues and submit corresponding
patches.
Thanks!
Andreas
Mesa has been updated in the latest core-updates merge.
Andreas
While trying out a "guix pull" on an aarch64 machine, for which many
packages are currently not available as substitutes, I notice an extra-
ordinary amount of dependencies, see below (and since I interrupted and
restarted it, there are even more dependencies in reality; I remember
X11 libraries
Am Mon, Apr 24, 2023 at 10:51:31AM +0200 schrieb Simon Tournier:
> Please note #62956 reporting the failure and proposing a patch.
Thanks for the notice! On core-updates, the current gajim requires
python-gssapi, which fails to build; so this would have to be repaired
additionally to the above
This is not related to the dancefloor. Someone on IRC mentioned that
"make clean-go" leaves a stray file guix/build/po.go.
I suppose that it should be added to Makefile.am in the line
that currently reads:
GOBJECTS = $(MODULES:%.scm=%.go) guix/config.go $(dist_noinst_DATA:%.scm=%.go)
but would
Am Fri, Apr 21, 2023 at 09:59:37AM +0200 schrieb Simon Tournier:
> Because it is two “mailing lists“ under the hood: guix-patches and bug-guix.
> Last, on the pragmatic side, I do not know if the CI is following
> bug-guix and if it tries to extract patches from it.
Ah indeed, I suppose it does
Am Thu, Apr 20, 2023 at 03:25:17PM +0200 schrieb Simon Tournier:
> See #62967 [1] for an attempt. I am rebuilding to detect the potential
> problem.
Not sure why we need a second issue... All this should work, let us wait
till after the core-updates merge.
Andreas
Am Thu, Apr 20, 2023 at 01:26:37PM +0200 schrieb Simon Tournier:
> shows that most of the paths do not involve texlive-ms. Instead, it
> seems related to lz4 or openmpi or jq.
So I start to understand. lz4 depends on valgrind. I do not know why.
It is given as a native input, so probably the
Currently r-minimal depends on texlive-latex-xkeyval, which depends on
texlive-ms, which for a reason I do not see pulls in the valgrind variable.
This is at version 3.17, which fails on powerpc64le. The user facing
variable valgrind/interactive, however, is at 3.20, and it builds.
After the
Am Wed, Apr 19, 2023 at 06:37:08PM +0200 schrieb Ludovic Courtès:
> Given that the ‘guix’ package builds fine on ‘core-updates’, it’s most
> likely a build environment issue.
> What does ‘config.log’ say?
My environment is Debian on aarch64, with Guix as the package manager.
So it is possible
Hello,
this looks to me like it could be a duplicate of #62936, but since this
bug is closed, I am simply opening a new one.
The libgcrypt version was updated from 1.8.8 to 1.10.1 from master to
core-updates.
This causes ./configure to fail like so:
...
checking for gcry_md_open in -lgcrypt...
Current mesa builds on master (@21) and core-updates (@22), so the
problem has apparently been solved.
Andreas
Closing the bug, feel free to open a new one if the problem persists with
newer versions.
Andreas
Am Fri, Apr 14, 2023 at 11:37:05AM +0100 schrieb Christopher Baines:
> I've made those changes to the commit you pushed earlier and pushed to
> core-updates now.
That did it, lots of green dots in the dashboard. Thanks!
Closing the bug now.
Andreas
Am Fri, Apr 14, 2023 at 09:20:03AM +0100 schrieb Christopher Baines:
> I haven't tried this yet, but I've had a quick look. I'm not sure
> search-patches will work where it is, since that'll be running in the
> build environment, without any access to the patches in the Guix git
> repository.
Am Thu, Apr 13, 2023 at 06:57:41PM +0200 schrieb Andreas Enge:
> attached is a new commit in old syntax, mixing both our commits.
> I have confirmed that it does not change the gcc-11 build on x86_64 and i686.
> But do we need "--force" for patching?
> Could you may
feel free to gexpify it in a separate commit.
Andreas
>From 9900f9e9b86550e7d336b04ad46fba088e28cbd6 Mon Sep 17 00:00:00 2001
From: Andreas Enge
Date: Thu, 13 Apr 2023 11:46:47 +0200
Subject: [PATCH] gnu: gcc-11: Fix build on powerpc64le.
* gnu/packages/patches/gcc-11-libstdc++-powerpc.pa
Am Thu, Apr 13, 2023 at 02:46:00PM +0100 schrieb Christopher Baines:
> Thanks for figuring this out Andreas! I've managed to apply this change
> in the relevant place, and it appears to work.
Good news, thanks!
> + #$@(if (and (target-ppc64le?)
> + (version>=?
.
Andreas
>From 5eb50bdc34759d4c917f2143e037fad62bc08ed7 Mon Sep 17 00:00:00 2001
From: Andreas Enge
Date: Thu, 13 Apr 2023 11:46:47 +0200
Subject: [PATCH] gnu: gcc-11: Fix build on powerpc64le.
* gnu/packages/patches/gcc-11-libstdc++-powerpc.patch: New file.
* gnu/local.mk (dist_patch_DATA): Regis
Hello,
recently I claimed that powerpc was repaired, but I must have made a mistake.
It is still completely broken:
https://ci.guix.gnu.org/eval/391720/dashboard?system=powerpc64le-linux
due to this:
https://issues.guix.gnu.org/61879
It does not look easy to fix, but might be *the*
Am Mon, Apr 10, 2023 at 07:00:16PM + schrieb Kaelyn:
> I just mailed https://issues.guix.gnu.org/62758 to add a snippet to fix the
> build error. I used a similar approach as the existing snippet for fixing a
> format overflow error. (I also forgot to set the subject prefix to "PATCH
>
Hello,
autogen fails to build on i686-linux like so, for instance on master commit
c9af27d4ca733b20f09019f1465d3e5fdc1ec724:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts
-DPKGDATADIR=\"/gnu/store/n29inqv3rnwix1jqsxc1gd2yw0q8jkr0-autogen-5.18.16/share/autogen\"
-g -O2
Am Thu, Mar 16, 2023 at 02:50:53PM +0100 schrieb Ludovic Courtès:
> I occasionally offload from my laptop to machines at work but didn’t hit
> this bug, so we’ll have to see if it’s specific to berlin or not.
My impression is that in my case, the problem is not with ssh, but somehow
with the guix
I do not know which error I made, but libaio *does* build with the
current core-updates HEAD. Sorry for the noise.
Andreas
Libaio has started to fail on core-updates; this is very annoying since:
Building the following 1068 packages would ensure 2078 dependent packages are
rebuilt,
among which qt@5 and gnome.
Here is the result of "git bisect":
0ad86e94f518c70690641c1d6f3a04037974a25b is the first bad commit
commit
Am Thu, Feb 16, 2023 at 04:03:15PM +0100 schrieb Janneke Nieuwenhuizen:
> Great, thanks so much for checking! Are you using any of tmpfs or btrfs
> on /tmp?
No, it is all on SSD, so we probably cannot conclude for the bugs,
unfortunately.
Andreas
Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret:
> 4. staging merge happens, and the branch gets deleted.
I tried to build staging for my profile on x86_64, but it failed with
a dependency of ffmpeg, rust-rav1e-0.5.1. There is a newer version 0.6.3,
but I did not simply update
Am Wed, Sep 07, 2022 at 01:13:25PM +0200 schrieb Maxime Devos:
> Also, we _do_ have concrete evidence that the curves are flawed -- the website
> on the link mentions many issues in the process
The website (you mean the blog by D. Bernstein?) also mentions the use of
a hash function to arrive at
Hello,
Am Tue, Sep 06, 2022 at 10:02:55PM +0200 schrieb Ludovic Courtès:
> (Cc’ing Andreas for extra advice.)
well, I agree with your analysis. There is no concrete evidence that the
NIST curves may be flawed, and a general belief that not all crypto
standards of NIST are flawed or backdoored...
Hello,
when updating python-sympy, I noticed that its dependent python-dolfin-adjoint
fails to build. Probably this was also true before, since we do not have a
substitute.
I think the problem was in FEniCS, with an assertion failure, so my
impression was that the code computed a wrong solution.
Hello,
guix-jupyter currently fails to build with the error message below. While I
noticed it when updating python-sympy, the problem was already present
before.
Andreas
test-name: execute_request
location: /tmp/guix-build-guix-jupyter-0.2.2.drv-0/source/tests/kernels.scm:100
source:
+
After removing the patch that works around this problem in fplll
with commit 5dec5f65ec3c7371dde309a101b85b930e423a46, I noticed that it
actually still does occur.
We used to have the problem with gcc-toolchain@10.2 that with test.cpp equal to
#include
int main() {
std::fesetround
The mysterious problem disappeared mysteriously after making a new git
checkout and bootstrapping. Closing the bug.
Andreas
Am Thu, Apr 14, 2022 at 02:07:02PM +0200 schrieb Andreas Enge:
> I had already removed it, and the problem persisted. I suppose that
> autoreconf or configure created it again in version 2.4.6, and during
> make my version 2.4.7 was used instead.
Actually it is "configure", in
Am Thu, Apr 14, 2022 at 01:29:46PM +0200 schrieb Liliana Marie Prikler:
> libtool causes at least 13802 (mere two thirds of all our packages), so
> one might want to ensure that there are no gratuitous bumps when making
> new versions of it available :)
Quite understandable, but if then the new
Recently even after a
./bootstrap
./configure --localstatedir=/var --prefix=/usr/local/guix
make
any command prefixed by ./pre-inst-env starts by recompiling a bunch of
scheme files with the following messages:
;;; WARNING: loading compiled file
Hello,
is there a good reason to have added libtool-2.4.7 without it replacing
the libtool variable (at version 2.4.6)? I have installed libtool@2.4.7
into my profile, as well as a number of other development tools, and
apparently both libtool versions are now used and are colliding when doing
Hello,
I am also experiencing problems with setting up nginx and certbot, but I
think it is more nginx that is to blame. After reconfiguring and restarting
nginx, it is still running with the old configuration. Only rebooting solves
the problem for me.
Here is what it looks like (everything as
Actually this seems to be a thing of the service, not nginx itself.
When I stop the service with the old configuration file, manually run
/gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -p
/var/run/nginx -c new_configuration_file
kill the process, and "herd restart nginx",
Am Tue, Apr 20, 2021 at 11:24:59AM +0200 schrieb Ludovic Courtès:
> I think we can close it. I have the attached improvements that I can
> commit to ‘staging’ (or ‘core-updates’?) to avoid another rebuild.
I think they can easily go to master; the time for rebuilds is not very
high, I just ran
Hello,
Am Mon, Apr 19, 2021 at 08:18:03PM +0200 schrieb Ricardo Wurmus:
> I just looked over the patch, and while I’m not sure it’s the best way to do
> things (matching “openjdk” or “icedtea” in the package name seems a little
> error prone in the presence of packages whose names might include
Hello Carlo,
Am Sat, Apr 17, 2021 at 07:38:11PM +1000 schrieb Carlo Zancanaro:
> On Sat, Apr 17 2021, Carlo Zancanaro wrote:
> > I'm in the process of rebuilding Java from icedtea-8 upwards to check,
>
> I've now built and checked the JRE/JDKs from 10 to 14, and none of them
> retain a reference
Hello Sergiu,
Am Sat, Mar 27, 2021 at 08:22:30PM +0100 schrieb Sergiu Ivanov:
> I have trouble running lualatex from the TeX Live distribution (package
> texlive) :
> $ lualatex
> /home/scolobb/.guix-profile/bin/lualatex: error while loading shared
> libraries: libzzip-0.so.13: cannot open
Am Mon, Mar 22, 2021 at 07:16:28AM -0400 schrieb Julien Lepiller:
> I think this has already been fixed a few days ago on master. Have you tried
> pulling and upgrading inkscape again?
Indeed, closing this bug, thanks!
The discussion on grafts and version numbers is continued here:
Hello,
$ guix environment --ad-hoc inkscape
[env]$ inkscape /tmp/guixtile.svg
/gnu/store/7bs616gpgnmj4g5d0g88dkphd1gqbicy-inkscape-1.0.2/bin/.inkscape-real:
error while loading shared libraries: libMagickCore-6.Q16.so.6: cannot open
shared object file: No such file or directory
The same
Hello,
Am Wed, Mar 10, 2021 at 12:25:05PM +0100 schrieb Ludovic Courtès:
> Could you instead try the latest patch?
> https://issues.guix.gnu.org/47007#6
it looks like my reply was missed, I tried this patch, and it solves the
problem for me, as for Jelle. So please push.
Thanks!
Andreas
1 - 100 of 490 matches
Mail list logo