(address . bug-guix@gnu.org)
- Aon 24 Apr 2023 12:13
- Lon 25 Apr 2023 23:48
- Aon 26 Apr 2023 09:28
- Jon 26 Apr 2023 10:45
- Lon 26 Apr 2023 18:59
- Aon 26 Apr 2023 19:25
- Jon 26 Apr 2023 20:39
- Aon 26 Apr 2023 21:21
- Lon 26 Apr 2023 21:34
- Son 28 Apr 2023 17:18
- Lon 3 May 2023 21:33
- Lon 3 May 2023 21:50
- Son 4 May 2023 10:56
- Son 4 May 2023 11:00
- Con 5 May 2023 17:21
- Son 9 May 2023 14:36
- Con 11 May 2023 23:30
- Lon 20 May 2023 18:12
- Aon 20 May 2023 18:38
- Lon 24 May 2023 15:10
"guix pull" requires graphical libraries
L
(name . Andreas Enge)(address . andreas@enge.fr)(address . 63050@debbugs.gnu.org)
875y9jzl9m.fsf@gnu.org
Hi,
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (10 lines)
> 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 such as libxi and libxt). Many of them are related to
> graphical environments, which should not happen for a command line
> program. Chances are they are pulled in for building documentation
> (not necessarily of Guix, but of packages that are needed for pulling);
> but this is still undesirable and should be sorted out.
This is apparently coming from Graphviz:
Toggle snippet (11 lines)
$ guix graph --path guix libx11
guix@1.4.0-5.286cdf0
graphviz@2.49.0
libx11@1.7.3.1
$ guix graph --path guix libxt
guix@1.4.0-5.286cdf0
graphviz@2.49.0
libxaw@1.0.14
libxt@1.2.1
Surprising to me, but apparently it’s been this way from the start,
commit b1b07d72c755ea314fb0c8333cd88293ee504ce4 (2013!).
Maybe these are optional dependencies?
Ludo’.
A
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 63050@debbugs.gnu.org)
ZEjSp8HrY6SyndaH@jurong
Am Tue, Apr 25, 2023 at 11:48:05PM +0200 schrieb Ludovic Courtès:
Toggle quote (5 lines)
> 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" builds what is defined as the guix package, but with the
current checkout as source?
The package definition of guix has this among the native inputs:
;; XXX: Keep the development inputs here even though
;; they're unnecessary, just so that 'guix environment
;; guix' always contains them.
("autoconf" ,autoconf)
("automake" ,automake)
("gettext" ,gettext-minimal)
("texinfo" ,texinfo)
("graphviz" ,graphviz)
("help2man" ,help2man)
("po4a" ,po4a)))
Maybe these could be dropped then, and we could have an expanded package
guix-devel that would add these inputs for "guix shell -D guix-devel"?
Or is it needed for "guix graph"?
$ guix graph --list-backends
- graphviz: Generate graph in DOT format for use with Graphviz.
...
But for this we do not need any graphical output, it is just text file
creation; could we have a graphviz-minimal in console mode?
Andreas
J
(address . 63050@debbugs.gnu.org)
87mt2vc9qp.fsf@jpoiret.xyz
Hi Andreas,
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (3 lines)
> So "guix pull" builds what is defined as the guix package, but with the
> current checkout as source?
No, guix pull uses (guix self), and the dependencies there are not used
in a singular place like (inputs ...) or (native-inputs ...), but are
peppered throughout the file. However, it uses a reduced dictionary for
specification->package to speed it up, and so gives a pretty good idea
of what's used:
Toggle snippet (28 lines)
(("guile" . ,(ref 'guile 'guile-3.0-latest))
("guile-avahi" . ,(ref 'guile-xyz 'guile-avahi))
("guile-json" . ,(ref 'guile 'guile-json-4))
("guile-ssh" . ,(ref 'ssh 'guile-ssh))
("guile-git" . ,(ref 'guile 'guile-git))
("guile-semver" . ,(ref 'guile-xyz 'guile-semver))
("guile-lib" . ,(ref 'guile-xyz 'guile-lib))
("guile-sqlite3" . ,(ref 'guile 'guile-sqlite3))
("guile-zlib" . ,(ref 'guile 'guile-zlib))
("guile-lzlib" . ,(ref 'guile 'guile-lzlib))
("guile-zstd" . ,(ref 'guile 'guile-zstd))
("guile-gcrypt" . ,(ref 'gnupg 'guile-gcrypt))
("guile-gnutls" . ,(ref 'tls 'guile-gnutls))
("guix-daemon" . ,(ref 'package-management 'guix-daemon))
("disarchive" . ,(ref 'backup 'disarchive))
("guile-lzma" . ,(ref 'guile 'guile-lzma))
("gzip" . ,(ref 'compression 'gzip))
("bzip2" . ,(ref 'compression 'bzip2))
("xz" . ,(ref 'compression 'xz))
("po4a" . ,(ref 'gettext 'po4a))
("gettext-minimal" . ,(ref 'gettext 'gettext-minimal))
("gcc-toolchain" . ,(ref 'commencement 'gcc-toolchain))
("glibc-utf8-locales" . ,(ref 'base 'glibc-utf8-locales))
("graphviz" . ,(ref 'graphviz 'graphviz))
("texinfo" . ,(ref 'texinfo 'texinfo)))
Toggle quote (17 lines)
> The package definition of guix has this among the native inputs:
> ;; XXX: Keep the development inputs here even though
> ;; they're unnecessary, just so that 'guix environment
> ;; guix' always contains them.
> ("autoconf" ,autoconf)
> ("automake" ,automake)
> ("gettext" ,gettext-minimal)
> ("texinfo" ,texinfo)
> ("graphviz" ,graphviz)
> ("help2man" ,help2man)
> ("po4a" ,po4a)))
>
> Maybe these could be dropped then, and we could have an expanded package
> guix-devel that would add these inputs for "guix shell -D guix-devel"?
>
> Or is it needed for "guix graph"?
No, guix graph uses its own graphviz implementation! It is used to
generated png files from .dot files while building the documentation.
I don't really know if we can skip graphical libraries for this reason.
Best,
--
Josselin Poiret
-----BEGIN PGP SIGNATURE-----
iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmRI5K4QHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5FhcaigPzC/4wvOkFeZbWkbvqCTzwEkRTTy19CDRMufrc
kCuzg84nYkCzSq55GwLC81sKAoI/6p2yVyBIuLqv7YEW7hjzo8uhniFwBrwtVg4b
0rcRsKsrzMCxBsBaHZv4MWuJM9NX8xwnrw3WpJRLhGKE8Wm5uzcWVmgHByO/WS3x
eaYQAB6KD0cVobnb4cwS4UuCzWYeOSGsrVyYNTEWr2WC2gRgDQgScu+v2MERsX6O
fH6skQj1a52qO9CEFAM9uXm4EQGcP2qa0ZzZ46GJitPrErUxjizgIIPB4XhPCxLU
PydSbN/qV5yAjTvMHnwPsG3OtY/SK5ymZ7ilEXu+b3QfpsMvyW+y1Cs9Xvx/lhjQ
U494atykM1UwdNIRpfBugLD18TBCeOob+zdRsfiTUFDY/Uhv3TtBD5IBd5ToIIPK
nlTYVL/+I6QeTnnxP0/oK3qMNP4RpJiWeeJqz250YI5/pS5y/KVS/72rso+bBm5k
slxGLPEQ3kPr8FfHLCUhdB4Z8MXApRg=
=v4yW
-----END PGP SIGNATURE-----
L
(address . 63050@debbugs.gnu.org)
e97944559fd9661c56dd88131cbd49c5ec8228ec.camel@gmail.com
Hi folks, just dropping by real quick
Am Mittwoch, dem 26.04.2023 um 10:45 +0200 schrieb Josselin Poiret:
Toggle quote (5 lines)
> No, guix graph uses its own graphviz implementation! It is used to
> generated png files from .dot files while building the documentation.
>
> I don't really know if we can skip graphical libraries for this
> reason.
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.
Cheers
A
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
ZElee8kEs8ReZbDv@jurong
Hello,
Am Wed, Apr 26, 2023 at 06:59:44PM +0200 schrieb Liliana Marie Prikler:
Toggle quote (4 lines)
> 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 `guix build texinfo`
/gnu/store/5j85qqflgx8nnzk86i43mxn0rjm8h2gv-perl-archive-zip-1.68
/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib
/gnu/store/a5i8avx826brw5grn3n4qv40g514505c-coreutils-9.1
/gnu/store/bcc053jvsbspdjr17gnnd9dg85b3a0gy-ncurses-6.2.20210619
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1
/gnu/store/lj75fc25zx2y9pqvfp95la84rdhlj4f8-perl-5.36.0
/gnu/store/m8waimifhdjm8slb85jfihsm18jp1vc8-texinfo-7.0.3
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16
So texinfo should be fine.
It is this explicit inclusion of graphviz that poses problems (glib is
then pulled in also).
Andreas
J
87jzxyh4hs.fsf@jpoiret.xyz
Hi Andreas,
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (10 lines)
> 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 `guix build texinfo`
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.
Best,
--
Josselin Poiret
-----BEGIN PGP SIGNATURE-----
iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmRJb/8QHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5FhcaiuwAC/9x5DZiXYkm0i0q0+nIXnhqI1m9Jun/uunO
CSR1XrRS2BhCGtH+0Kq9xJLooBLyB7DyeuDX/J9PFo+XQqCp2MUuO59BfVTX911e
M2//ORD4CleHCwnAuyV1NBHXBNEU/0YderEICKjUlbM3EjZhCHj/4ra73cnfoPWv
SOSsIxBJNXphyovEuGuxv68v5mOJpEf11/u7Wn/qDn82In29Ombbx9RYbVOp6oql
/W4bdOq9iTB+XHiKp9MrygV4d2sjk+pb9RGir8EBcF64EEzLtHXnN7+F3XFd8mxD
buD67jxcqTwjYGa2n1rNJx7d6bWgHAe/9s+TVGBoUixbJuUNTf7X4w3/exZAuImi
TKeXzXHZHVrR1xYgoKo6oq7wrhioYC3SJC+n4Jftw3p56ww12aEYXn88Nrgtkhfj
HKq703jfm0oBYdlYhdVgtnV9DuvtLQliSfCBiSRa1vodULAEFvdxCiEuvGJ4fenL
9yfmJ7xZanz3ZsCG8BtxISYmJB47AhQ=
=Wsnf
-----END PGP SIGNATURE-----
A
(name . Josselin Poiret)(address . dev@jpoiret.xyz)
ZEl50w11Ejqw8yAf@jurong
Am Wed, Apr 26, 2023 at 08:39:59PM +0200 schrieb Josselin Poiret:
Toggle quote (4 lines)
> 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
L
22bc26fad9923242bf3296b5ff9d32e2ba9a1ea3.camel@gmail.com
Am Mittwoch, dem 26.04.2023 um 20:39 +0200 schrieb Josselin Poiret:
Toggle quote (19 lines)
> Hi Andreas,
>
> Andreas Enge <andreas@enge.fr> writes:
>
> > 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 `guix build texinfo`
>
> 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.
It does turn out there's no `guix graph texinfo --path-to texlive'
either, though, so I was actually mistaken.
Sorry for the noise
L
Reducing the closure size of Graphviz
(name . Andreas Enge)(address . andreas@enge.fr)(address . 63050@debbugs.gnu.org)
874jot19fd.fsf_-_@gnu.org
Hey!
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (17 lines)
> This is apparently coming from Graphviz:
>
> $ guix graph --path guix libx11
> guix@1.4.0-5.286cdf0
> graphviz@2.49.0
> libx11@1.7.3.1
> $ guix graph --path guix libxt
> guix@1.4.0-5.286cdf0
> graphviz@2.49.0
> libxaw@1.0.14
> libxt@1.2.1
>
> Surprising to me, but apparently it’s been this way from the start,
> commit b1b07d72c755ea314fb0c8333cd88293ee504ce4 (2013!).
>
> Maybe these are optional dependencies?
All the X libraries can be seen in the output of:
ldd $(guix build graphviz |grep -v 'doc$')/lib/graphviz/libgvplugin_xlib.so
I haven’t checked but I suppose that’s used by ‘xdot’.
We can get an X11-free Graphviz like so:
Toggle diff (22 lines)
diff --git a/gnu/packages/graphviz.scm b/gnu/packages/graphviz.scm
index 26ee96afd4..3a5d33e662 100644
--- a/gnu/packages/graphviz.scm
+++ b/gnu/packages/graphviz.scm
@@ -94,16 +94,12 @@ (define-public graphviz
(string-append extdir
"/libgv_guile.so"))))))))
(inputs
- (list libxrender
- libx11
- gts
+ (list gts
gd
guile-3.0 ;Guile bindings
- pango
fontconfig
freetype
libltdl
- libxaw
expat
libjpeg-turbo
libpng))
S
Re: bug#63050: "guix pull" requires graphical libraries
(name . Ludovic Courtès)(address . ludo@gnu.org)
86ttwsxyo7.fsf@gmail.com
Hi,
On Wed, 03 May 2023 at 21:33, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (4 lines)
>> Why does Guix require ’graphviz’ in the first place?
>
> It uses it to build images in the manual.
Ah. So we are dragging X11 libraries as libx11 for one or two figures
in the manual. :-)
Although that’s not exactly the same as “guix pull”,
guix graph guix -t bag-emerged
gives an idea. Well, for example, there is a path from guix to ninja
via graphviz.
While I understand that the documentation is important, could we skip it
for some architectures?
Cheers,
simon
$ guix graph guix -t bag-emerged | grep label | cut -f2 -d'=' | cut -f1 -d',' | sort
"acl@2.3.1"
"attr@2.5.1"
"autoconf@2.69"
"autoconf-wrapper@2.69"
"automake@1.16.3"
"avahi@0.8"
"bash@5.1.8"
"bash-completion@2.8"
"bash-minimal@5.1.8"
"bash-minimal@5.1.8"
"bash-static@5.1.8"
"bdb@6.2.32"
"binutils@2.37"
"bison@3.7.6"
"bison@3.7.6"
"boost@1.77.0"
"bzip2@1.0.8"
"bzip2@1.0.8"
"cairo@1.16.0"
"cairo@1.16.0"
"c-ares@1.17.2"
"cmake-bootstrap@3.21.4"
"cmake-minimal@3.21.4"
"config@0.0.0-1.c8ddc84"
"coreutils@8.32"
"coreutils@8.32"
"coreutils-minimal@8.32"
"cunit@2.1-3"
"curl@7.79.1"
"datefudge@1.23"
"dbus@1.12.20"
"diffutils@3.8"
"disarchive@0.4.0"
"docbook-xml@4.1.2"
"docbook-xml@4.4"
"docbook-xsl@1.79.2"
"doxygen@1.9.1"
"expat@2.4.1"
"file@5.39"
"file@5.39"
"findutils@4.8.0"
"flex@2.6.4"
"fontconfig-minimal@2.13.94"
"font-dejavu@2.37"
"fontforge@20201107"
"font-ghostscript@8.11"
"freetype@2.10.4"
"fribidi@1.0.9"
"gawk@5.1.0"
"gawk@5.1.0"
"gcc@10.3.0"
"gd@2.3.2"
"gdbm@1.20"
"gettext-minimal@0.21"
"ghostscript@9.54.0"
"glib@2.70.2"
"glibc@2.33"
"glibc@2.33"
"glibc-utf8-locales@2.33"
"glibc-utf8-locales@2.33"
"gmp@6.2.1"
"gnutls@3.7.2"
"gnutls@3.7.7"
"gobject-introspection@1.66.1"
"gperf@3.1"
"graphite2@1.3.13"
"graphviz@2.49.0"
"grep@3.6"
"grep@3.6"
"gts@0.7.6"
"guile@3.0.7"
"guile@3.0.8"
"guile-avahi@0.4.0-1.6d43caf"
"guile-bytestructures@1.0.10"
"guile-gcrypt@0.3.0"
"guile-git@0.5.2"
"guile-gnutls@3.7.9"
"guile-json@4.7.1"
"guile-lib@0.2.7"
"guile-lzlib@0.0.2"
"guile-lzma@0.1.1"
"guile-quickcheck@0.1.0"
"guile-sqlite3@0.1.3"
"guile-ssh@0.15.1"
"guile-zlib@0.1.0"
"guile-zstd@0.1.1"
"guix@1.3.0-31.3170843"
"gzip@1.10"
"gzip@1.10"
"harfbuzz@2.8.2"
"help2man@1.48.5"
"http-parser@2.9.4-1.ec8b5ee"
"icu4c@69.1"
"intltool@0.51.0"
"iproute2@5.15.0"
"iptables@1.8.7"
"itstool@2.0.6"
"jansson@2.13.1"
"jbig2dec@0.19"
"jemalloc@5.2.1"
"jsoncpp@1.9.4"
"kmod@29"
"lcms@2.12"
"ld-wrapper@0"
"libarchive@3.5.1"
"libbsd@0.10.0"
"libcap@2.62"
"libdaemon@0.14"
"libdatrie@0.2.13"
"libdrm@2.4.107"
"libelf@0.8.13"
"libev@4.33"
"libevent@2.1.12"
"libffi@3.3"
"libgc@8.0.4"
"libgcrypt@1.8.8"
"libgit2@1.3.0"
"libgpg-error@1.42"
"libice@1.0.10"
"libidn@1.37"
"libidn2@2.3.1"
"libjpeg-turbo@2.0.5"
"libltdl@2.4.6"
"libmnl@1.0.4"
"libnftnl@1.2.0"
"libpaper@1.1.24"
"libpciaccess@0.16"
"libpng@1.6.37"
"libpthread-stubs@0.4"
"libsigsegv@2.13"
"libsm@1.2.3"
"libspectre@0.2.9"
"libspiro@20200505"
"libssh@0.9.6"
"libssh2@1.9.0"
"libtasn1@4.17.0"
"libthai@0.1.28"
"libtiff@4.3.0"
"libtool@2.4.6"
"libungif@4.1.4"
"libuninameslist@20200313"
"libunistring@0.9.10"
"libuv@1.41.1"
"libx11@1.7.3.1"
"libxau@1.0.9"
"libxaw@1.0.14"
"libxcb@1.14"
"libxdmcp@1.1.3"
"libxext@1.3.4"
"libxfixes@6.0.0"
"libxft@2.3.3"
"libxi@1.7.10"
"libxml2@2.9.12"
"libxmu@1.1.3"
"libxpm@3.5.13"
"libxrender@0.9.10"
"libxslt@1.1.34"
"libxt@1.2.1"
"linux-libre-headers@5.10.35"
"lzlib@1.13"
"lzo@2.10"
"m4@1.4.18"
"make@4.3"
"mallard-ducktype@1.0.2"
"meson@0.60.3"
"mit-krb5@1.19.2"
"mpfr@4.1.0"
"nasm@2.15.05"
"ncurses@6.2.20210619"
"net-base@5.3"
"nettle@3.7.3"
"net-tools@1.60-0.479bb4a"
"nghttp2@1.44.0"
"ninja@1.10.2"
"openjpeg@2.4.0"
"openjpeg-data@2020.11.30"
"openssl@1.1.1l"
"p11-kit@0.23.22"
"pango@1.48.10"
"patch@2.7.6"
"pciutils@3.7.0"
"pcre2@10.37"
"pcre@8.45"
"perl@5.34.0"
"perl-common-sense@3.75"
"perl-cpanel-json-xs@4.30"
"perl-cpan-meta@2.150010"
"perl-cpan-meta-requirements@2.140"
"perl-cpan-meta-yaml@0.018"
"perl-extutils-config@0.008"
"perl-extutils-helpers@0.026"
"perl-extutils-installpaths@0.012"
"perl-gettext@1.07"
"perl-json-maybexs@1.004003"
"perl-module-build@0.4231"
"perl-module-build-tiny@0.039"
"perl-parse-cpan-meta@2.150010"
"perl-pod-parser@1.65"
"perl-test-harness@3.42"
"perl-test-needs@0.002009"
"perl-test-pod@1.52"
"perl-xml-parser@2.46"
"perl-yaml-tiny@1.73"
"pixman@0.40.0"
"pkg-config@0.29.2"
"po4a@0.63"
"poppler@21.07.0"
"potrace@1.16"
"python@3.9.9"
"python-fonttools@4.28.5"
"python-libxml2@2.9.12"
"python-minimal@3.9.9"
"python-minimal-wrapper@3.9.9"
"python-wrapper@3.9.9"
"readline@8.1.1"
"rhash@1.4.2"
"ruby@2.7.4"
"ruby-hydra-minimal@0.0-0.5abfa37"
"sed@4.8"
"sed@4.8"
"socat@1.7.4.1"
"sqlite@3.36.0"
"swig@4.0.2"
"tar@1.34"
"tar@1.34"
"tcl@8.6.11"
"tcsh@6.22.03"
"teckit@2.5.10"
"texinfo@6.7"
"texlive-amscls@59745"
"texlive-amsmath@59745"
"texlive-babel@59745"
"texlive-bin@20210325"
"texlive-cm@59745"
"texlive-cm-super@59745"
"texlive-dehyph-exptl@59745"
"texlive-docstrip@59745"
"texlive-dvips@59745"
"texlive-etex@59745"
"texlive-fontname@59745"
"texlive-fonts-latex@59745"
"texlive-generic-babel-english@59745"
"texlive-graphics-cfg@59745"
"texlive-graphics-def@59745"
"texlive-hyphen-afrikaans@59745"
"texlive-hyphen-ancientgreek@59745"
"texlive-hyphen-armenian@59745"
"texlive-hyphen-base@59745"
"texlive-hyphen-basque@59745"
"texlive-hyphen-belarusian@59745"
"texlive-hyphen-bulgarian@59745"
"texlive-hyphen-catalan@59745"
"texlive-hyphen-chinese@59745"
"texlive-hyphen-churchslavonic@59745"
"texlive-hyphen-coptic@59745"
"texlive-hyphen-croatian@59745"
"texlive-hyphen-czech@59745"
"texlive-hyphen-danish@59745"
"texlive-hyphen-dutch@59745"
"texlive-hyphen-english@59745"
"texlive-hyphen-esperanto@59745"
"texlive-hyphen-estonian@59745"
"texlive-hyphen-ethiopic@59745"
"texlive-hyphen-finnish@59745"
"texlive-hyphen-french@59745"
"texlive-hyphen-friulan@59745"
"texlive-hyphen-galician@59745"
"texlive-hyphen-georgian@59745"
"texlive-hyphen-german@59745"
"texlive-hyphen-greek@59745"
"texlive-hyphen-hungarian@59745"
"texlive-hyphen-icelandic@59745"
"texlive-hyphen-indic@59745"
"texlive-hyphen-indonesian@59745"
"texlive-hyphen-interlingua@59745"
"texlive-hyphen-irish@59745"
"texlive-hyphen-italian@59745"
"texlive-hyphen-kurmanji@59745"
"texlive-hyphen-latin@59745"
"texlive-hyphen-latvian@59745"
"texlive-hyphen-lithuanian@59745"
"texlive-hyphen-macedonian@59745"
"texlive-hyphen-mongolian@59745"
"texlive-hyphen-norwegian@59745"
"texlive-hyphen-occitan@59745"
"texlive-hyphen-pali@59745"
"texlive-hyphen-piedmontese@59745"
"texlive-hyphen-polish@59745"
"texlive-hyphen-portuguese@59745"
"texlive-hyphen-romanian@59745"
"texlive-hyphen-romansh@59745"
"texlive-hyphen-russian@59745"
"texlive-hyphen-sanskrit@59745"
"texlive-hyphen-schoolfinnish@59745"
"texlive-hyphen-serbian@59745"
"texlive-hyphen-slovak@59745"
"texlive-hyphen-slovenian@59745"
"texlive-hyphen-spanish@59745"
"texlive-hyphen-swedish@59745"
"texlive-hyphen-thai@59745"
"texlive-hyphen-turkish@59745"
"texlive-hyphen-turkmen@59745"
"texlive-hyphen-ukrainian@59745"
"texlive-hyphen-uppersorbian@59745"
"texlive-hyphen-welsh@59745"
"texlive-hyph-utf8@59745"
"texlive-knuth-lib@59745"
"texlive-kpathsea@59745"
"texlive-latex-base@59745"
"texlive-latexconfig@59745"
"texlive-latex-cyrillic@59745"
"texlive-latex-epstopdf-pkg@59745"
"texlive-latex-graphics@59745"
"texlive-latex-l3backend@59745"
"texlive-latex-l3kernel@59745"
"texlive-latex-l3packages@59745"
"texlive-latex-tools@59745"
"texlive-metafont@59745"
"texlive-psnfss@59745"
"texlive-ruhyphen@59745"
"texlive-tetex@59745"
"texlive-tex-ini-files@59745"
"texlive-tex-plain@59745"
"texlive-tiny@59745"
"texlive-ukrhyph@59745"
"texlive-unicode-data@59745"
"tk@8.6.11.1"
"tzdata@2022a"
"unzip@6.0"
"util-linux@2.37.2"
"util-macros@1.19.3"
"which@2.21"
"xcb-proto@1.14"
"xmlto@0.0.28"
"xorgproto@2021.5"
"xtrans@1.4.0"
"xz@5.2.5"
"xz@5.2.5"
"yelp-tools@3.32.2"
"yelp-xsl@41.0"
"zip@3.0"
"zlib@1.2.11"
"zstd@1.5.0"
"zziplib@0.13.72"
S
Re: bug#63050: Reducing the closure size of Graphviz
(address . 63050@debbugs.gnu.org)
86pm7gxyi1.fsf@gmail.com
Hi,
On Wed, 03 May 2023 at 21:50, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (15 lines)
> - (list libxrender
> - libx11
> - gts
> + (list gts
> gd
> guile-3.0 ;Guile bindings
> - pango
> fontconfig
> freetype
> libltdl
> - libxaw
> expat
> libjpeg-turbo
> libpng))
Ah that’s better than my proposal elsewhere. ;-)
Toggle quote (10 lines)
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix size graphviz | tail -1
> total: 183.6 MiB
> $ guix size graphviz | tail -1
> total: 242.3 MiB
> --8<---------------cut here---------------end--------------->8---
>
> But I suspect we’d still need the full-blown variant for things like
> xdot.
Yeah, we could have graphviz (with libx11) and graphviz-minimal (without
libx11) and make Guix depends on graphviz-minimal. WDYT?
Cheers,
simon
C
Re: bug#63050: "guix pull" requires graphical libraries
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
87ttwq952b.fsf@riseup.net
Simon Tournier <zimon.toutoune@gmail.com> writes:
Toggle quote (21 lines)
> Hi,
>
> On Wed, 03 May 2023 at 21:33, Ludovic Courtès <ludo@gnu.org> wrote:
>
>>> Why does Guix require ’graphviz’ in the first place?
>>
>> It uses it to build images in the manual.
>
> Ah. So we are dragging X11 libraries as libx11 for one or two figures
> in the manual. :-)
>
> Although that’s not exactly the same as “guix pull”,
>
> guix graph guix -t bag-emerged
>
> gives an idea. Well, for example, there is a path from guix to ninja
> via graphviz.
>
> While I understand that the documentation is important, could we skip it
> for some architectures?
Or just move it to a separate output or package? That should really be
something done for all packages automatically tbh. Alpine gets this right.
S
(name . Csepp)(address . raingloom@riseup.net)
87v8h165rn.fsf@gmail.com
Hi,
On ven., 05 mai 2023 at 15:21, Csepp <raingloom@riseup.net> wrote:
Toggle quote (3 lines)
> Or just move it to a separate output or package? That should really be
> something done for all packages automatically tbh. Alpine gets this right.
Well, I do not think a separate output would be possible and we are not
talking about the package named ’guix’ but about what is implemented by
the module (guix self).
Somehow, I agree that one direction would to make optional some
features. The current proposal for tackling this issue is the reduction
of the closure by removing lix11 and libxrender as discussed in [1].
Cheers,
simon
C
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
871qjmr1t3.fsf@riseup.net
Simon Tournier <zimon.toutoune@gmail.com> writes:
Toggle quote (21 lines)
> Hi,
>
> On ven., 05 mai 2023 at 15:21, Csepp <raingloom@riseup.net> wrote:
>
>> Or just move it to a separate output or package? That should really be
>> something done for all packages automatically tbh. Alpine gets this right.
>
> Well, I do not think a separate output would be possible and we are not
> talking about the package named ’guix’ but about what is implemented by
> the module (guix self).
>
> Somehow, I agree that one direction would to make optional some
> features. The current proposal for tackling this issue is the reduction
> of the closure by removing lix11 and libxrender as discussed in [1].
>
> 1: https://issues.guix.gnu.org/msgid/874jot19fd.fsf_-_@gnu.org
>
>
> Cheers,
> simon
It should be made possible IMHO. It's nice that our packages come with
docs, including Guix, but they are often unnecessary. If an output
won't work because guix-self is special, then maybe it could be moved to
a separate package.
L
(name . Andreas Enge)(address . andreas@enge.fr)
87fs7rvv5s.fsf_-_@gnu.org
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (36 lines)
> We can get an X11-free Graphviz like so:
>
> diff --git a/gnu/packages/graphviz.scm b/gnu/packages/graphviz.scm
> index 26ee96afd4..3a5d33e662 100644
> --- a/gnu/packages/graphviz.scm
> +++ b/gnu/packages/graphviz.scm
> @@ -94,16 +94,12 @@ (define-public graphviz
> (string-append extdir
> "/libgv_guile.so"))))))))
> (inputs
> - (list libxrender
> - libx11
> - gts
> + (list gts
> gd
> guile-3.0 ;Guile bindings
> - pango
> fontconfig
> freetype
> libltdl
> - libxaw
> expat
> libjpeg-turbo
> libpng))
>
>
> 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 for things like
> xdot.
A
(name . Ludovic Courtès)(address . ludo@gnu.org)
ZGj3hGKGwu3mQklT@jurong
Am Sat, May 20, 2023 at 06:12:47PM +0200 schrieb Ludovic Courtès:
Toggle quote (10 lines)
> > 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 for things like
> > xdot.
> Here’s a proposal:
> https://issues.guix.gnu.org/63610
Typo? The issue is not found.
Note that I do not care so much about the closure size, but about the
number of packages that are needed to just build guix (although of course
the two are related). Or otherwise said, the dependencies for "guix pull".
On "exotic" architectures, each dependency is a potential cause of failure,
and all in all it may take hours (days?) to run "guix pull" without
substitutes, with a high chance of failure.
Andreas
L
(name . Andreas Enge)(address . andreas@enge.fr)
878rddooy4.fsf@gnu.org
Hi,
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (13 lines)
> 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 for things like
>> > xdot.
>> Here’s a proposal:
>> https://issues.guix.gnu.org/63610
>
> Typo? The issue is not found.
Typo on your side then? :-)
Toggle quote (4 lines)
> Note that I do not care so much about the closure size, but about the
> number of packages that are needed to just build guix (although of course
> the two are related). Or otherwise said, the dependencies for "guix pull".
Yes, understood. Graphviz is not in the closure anyway, it’s a
build-only dependency.
With commit 9fa92acbf0c4dbc734ac7d83b31bd6d12e09a401 this is mostly
fixed. There’s still another path leading to libx11 though:
Toggle snippet (8 lines)
$ ./pre-inst-env guix graph --path guix libx11
guix@1.4.0-6.dc5430c
guile-avahi@0.4.1
avahi@0.8
dbus@1.14.0
libx11@1.8.1
(The same applies to “guix pull”.)
Not sure what can be done about it.
Ludo’.
?