Re: Packaging Jami progress
Jan writes: > On Sat, 28 Dec 2019 10:40:09 +0100 > Pierre Neidhardt wrote: > >> This is indeed your problem, I suspect that something broke the >> wrapper somehow. >> Can you share your patch set again? I can have a look. > I didn't really break anything - it works when launching Jami normally > or using the ring.cx script or the jami-gnome script manually. ring.cx > starts both the daemon and the client using "jami-gnome", jami-gnome is > also a script, which exports the path and then starts > ".jami-gnome-real". Jami works during normal use, but I couldn't debug > like this, because by passing only ".jami-gnome-real" which is a > binary, to gdb, the needed path wasn't exported. You can run “gdb --args /bin/sh /path/to/wrapper” and then "set follow-fork-mode child" in gdb. -- Ricardo
Re: Packaging Jami progress
Jan writes: > Bad news: > I still haven't got any response that would solve the bug present only > in our package: > https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/1123 > I have not much experience with debugging and reading backtraces, but > could it be there's something wrong with our glibc package? That’s very unlikely as we would probably see errors like this in most packages then. cogl issues an optimized instruction (__memcpy_ssse3), which then fails. I’m just guessing, but I wonder if this comment is a hint at what’s wrong here: ;; NOTE: mutter exports a bundled fork of cogl, so when making changes to ;; cogl, corresponding changes may be appropriate in mutter as well. cogl is up to date, but mutter is not (it’s tied to the current Gnome version in Guix, which is a few releases behind). It may also be interesting to see if this can be reproduced on Wayland. -- Ricardo
Re: Allow system configuration without a bootloader
Yes, I just checked and it actually does work. I must have misremembered something. I also should have looked into how the bootloaders are defined. Since it is just a public record type, I guess there is no problem whatsoever in reality. Thanks. 03.01.2020, 01:28, "Ludovic Courtès" : > Hi, > > "kanic...@yandex.ru" skribis: > >> Yes, AFAIR it only works with ‘init’ and has no effect at all with >> ‘reconfigure’. > > ‘--no-bootloader’ should definitely work for ‘reconfigure’; could you > double-check and report a bug if it doesn’t work? > > Now, if that’s useful, we could easily define a “noop” bootloader in > (gnu bootloader noop), along these lines: > > (define noop-bootloader > (bootloader > (name 'noop) > (package #f) > (installer #~(cons #t)) > (configuration-file #f) > (configuration-file-generator #f))) > > Thanks, > Ludo’.
Re: Package file indexing
Hi, On Thu, 2 Jan 2020 at 18:12, Pierre Neidhardt wrote: > Last but not least: previously we suggested adding a subcommand like > "guix which" or "guix filesearch". In another thread, Simon suggested > that this would be a bad idea and factoring the file search into "guix > search" is probably better. It appears to me better for 2 reasons: 1. because obviously "filesearch" is a kind of "search" ;-) so it adds consistency. 2. because it allows (in the near future) mixed research: "guix search bin/hg python" applying the "python" filter only to the packages returned by "bin/hg". And "guix search python bin/hg" search the binary file "hg" only to the packages matching "python. > For instance, we could do > > guix search bin/foo > > and it would report the packages containing the "bin/foo" path. This > could mean that we need to adapt the output to display the file listing > as well. If listing all files would be too verbose, we can list only > the matching files: > > --8<---cut here---start->8--- > name: jami [...] > filepaths: > + bin/foo > + share/bar/bin/foo-blah > relevance: 24 > --8<---cut here---end--->8--- How do you compute the relevance/score? Currently, when searching with regexp, the relevance is computed by counting the number of matches applying different weights depending on if the match is about name, synopsis, description, etc. It is not perfect and there is room of improvements as discussed elsewhere, but it works (nicely when you know what you are searching ;-). For example, let consider 2 packages: a- 'bin/foo' b- 'share/baz/bin/foo' How to do you order/score the result? What do you expect first? The package a- I guess. Therefore, weight should be applied, isn't it? > That said, some terms may match too frequently. For instance, "guix > search lib" would match almost all packages that have libraries and > result in a huge, useless output. > > I suggest the following: > > - Add a "--search-file-paths=[auto|on|off]" option. I do not find this option name explaining by itself. Personally, I am inclined to provide a path to the option and not a boolean. > - When --search-file-paths is "auto", file paths are automatically > searched for against terms that contain a slash. E.g. "lib" won't > return file paths but "lib/" will. This should be cool. With regexp too. Time to time, I am looking for header C file or latex style but I do not know the path. I would like to have something like: guix search gmsh.h or guix search ieee*.sty > Another feature that could be nice: list the file paths for the given > packages. > I think we need a separate subcommand for this, e.g. "guix list-files". Yes, cool! IMHO, it should be included under "guix package", i.e., guix package gmsh --list-files should returns something like: --8<---cut here---start->8--- bin/gmsh share/applications/gmsh.desktop share/doc/gmsh/README.Debian share/doc/gmsh/TODO.Debian share/doc/gmsh/changelog.Debian.gz share/doc/gmsh/changelog.gz share/doc/gmsh/copyright share/info/gmsh.info.gz share/man/man1/gmsh.1.gz share/pixmaps/gmsh_16x16.xpm share/pixmaps/gmsh_32x32.xpm --8<---cut here---end--->8--- (list from https://packages.debian.org/buster/amd64/gmsh/filelist) All the best, simon
Re: Allow system configuration without a bootloader
Hi, "kanic...@yandex.ru" skribis: > Yes, AFAIR it only works with ‘init’ and has no effect at all with > ‘reconfigure’. ‘--no-bootloader’ should definitely work for ‘reconfigure’; could you double-check and report a bug if it doesn’t work? Now, if that’s useful, we could easily define a “noop” bootloader in (gnu bootloader noop), along these lines: (define noop-bootloader (bootloader (name 'noop) (package #f) (installer #~(cons #t)) (configuration-file #f) (configuration-file-generator #f))) Thanks, Ludo’.
Re: How can I set architecture/system-specific origin sources?
Hi, Mathieu Othacehe skribis: > Well, it's not really a bug, but quite suprising at first. If you look > at the definition of in (guix packages), you'll see that some > fields are (thunked). %current-system and %current-target-system will > only return valid results in (thunked) fields. > > As "source" is not thunked, you can make it thunked, but it can hurt > performances. You can also make multiple packages for each architecture, > and use them as inputs conditionned by %current-system and > %current-target-system. I should say that it’s because source is architecture-independent. :-) The package definition for ‘mit-scheme’, for example, passes the bootstrap binaries, which are architecture-dependent, as inputs. Ludo’.
Re: [Proposal] The Formal Methods in GNU Guix Working Group
Hello! (Cc: maintainers.) Brett Gilio skribis: > Dec 30, 2019 3:34:22 PM Ludovic Courtès : > >> Guix-HPC is “institutional”, that’s part of the reason behind this. >> Regarding gitlab.inria.fr, that’s because it used to be hosted at Inria. >> Also, is a channel developed >> by colleagues at Inria, so it’s more convenient to have it there. > > > Hey Ludo, thanks for the explanation. > > It makes sense why Guix-HPC lives somewhere else. Given this, what do you > propose for initiating the conversation on where the formal methods haunt > page should live with the other maintainers? I personally think the > repository should live on Savannah, but the address needs to be discussed. It’s fine to host the repo on Savannah: we can ask for a new repo under the Guix umbrella, the downside being that access control will be the same as for the other repos (we can only grant access to all the repos or none of them.) If you plan to open it more to formal methods people that do not yet contribute to Guix, it might be easier to use a separate repo. You tell us! As for the domain name: I think it would be fine to use formal-methods.guix.gnu.org as long as the web site follows GNU and Guix policy, which mostly means referring only to free software, avoiding the phrase “open source” to describe it, and probably avoiding institution logos and such (I don’t think there’s any written policy but I would personally find it out of place on gnu.org.) Anyway, the two of you are webmasters so you probably know this better than I do. IOW, if you want to flatter your employers and labs, you might want to opt for a separate web site. :-) Maintainers, what do you think? Anyway, step #1 is to get a web page ready. :-) Ludo’.
Re: Cross-compilation broken on canonical packages.
Hi, > It’s more than I thought but I think it’s OK. (Also, how come > bare-bones takes 1.5 GiB?!) That's one of my next subject of investigation :) >> (define %default-locale-libcs >>;; The libcs for which we build locales by default. >> - (list (canonical-package glibc))) >> + (list glibc)) > > I would leave this bit unchanged if possible, because that way the glibc > used would really match that programs are linked against. operating-system-locale-libcs defaults to %default-locale-libcs, so keeping (canonical-package glibc) prevents cross-compilation :( We could use a thunk field to write something like: --8<---cut here---start->8--- (define (default-locale-libcs ...) (if target glibc (canonical-package glibc)) --8<---cut here---end--->8--- But I'd like to avoid that. I'll see if I can figure out something better after a good night. Thanks, Mathieu
Re: Claws Mail missing libetpan
Je 2 jan 20:52 skribis Efraim: > On Thu, Jan 02, 2020 at 12:29:47PM -0500, Julien Lepiller wrote: > > Le 2 janvier 2020 12:14:50 GMT-05:00, Marco van Hulten a > > écrit : > > >Hello— > > > > > >I get an error compiling Claws Mail (claws-mail): > > > > > >checking for libetpan-config... no > > >*** Claws Mail requires libetpan 0.57 or newer. See > > >http://www.etpan.org/ > > >[...] > > > > > >First installing libetpan (the Guix package) does not help. > > > > > >—Marco > > > > There's no reason it should help: builds are completely isolated > > from the host environment. There is nothing you can do to influence > > them. But that means builds may be reproducible! > > [...] > > I recently upgraded libetpan from 1.9.3 to 1.9.4, and with it we lost > the libetpan-config binary. There's an open bug¹ with libetpan > upstream to mention the now missing binary. There's also an upstream > patch² but I'm having a hard time getting it to work. On a different Guix (System) system I already had Claws Mail 3.17.4 running. After 'guix pull' it grabbed libetpan-1.9.4 and wanted to compile Claws Mail anew. Indeed, same compilation error. —Marco
Re: new micro release to address bug 36074 for new binary installs on foreign distributions with systemd
On 02.01.20 20:21, Danny Milosavljevic wrote: > There were also changes to the DVD bootloader (grub-mkrescue) which would be > important to release. Adding the requirement on guile-json 3.x.x which is on master for 7 months or so now. Makes it easier to use guix-master on foreign distros, which you wanna use because it's more recent :) > Why not just release a new version from master? Is it broken? I fully support a new release :)
Re: qtwenengine anybody?
Hartmut Goebel writes: > Am 01.01.20 um 23:30 schrieb mike.ros...@gmail.com: >> I think the package is looking pretty good now. I sent some changes >> requested by Hartmut today so we might need to wait on any more changes >> he might have. > > I tried applying the patches to see the complete/compiled diff, but `git > am` failed. Can you please send an updated patch or provide a link to > some online-repo to view the complete diff. Thanks Apologies this is probably a failure in my ML workflow. And just my luck I'm in the process of doing some working related moving todoy. Here is a complete diff https://gitlab.com/mike.rosset/guix/compare/master...qtwebengine hope this helps. Mike
Re: new micro release to address bug 36074 for new binary installs on foreign distributions with systemd
Le 2 janvier 2020 14:21:33 GMT-05:00, Danny Milosavljevic a écrit : >Hi Julien, > >On Thu, 02 Jan 2020 11:07:47 -0500 >Julien Lepiller wrote: > >> Instead of a release from the master branch, maybe we can apply the >fix on top of the version-1.0.1 branch and release that? That way we >won't need the build farms to rebuild anything, while fixing the issue. >We could also apply patches to the graphical installer that were pushed >after 1.0.1 maybe? > >There were also changes to the DVD bootloader (grub-mkrescue) which >would be >important to release. > >In any case, I'm doubtful whether fixing version-1.0.1 branch buys us >much. > >Why not just release a new version from master? Is it broken? It's not broken, but a release always takes time. I was proposing a quicker solution.
Re: Parameterized packages
Hi!
Bringing this topic back to life now that I'm starting working on this.
1. Everyone seems to agree that we need a dedicated field in the package
declaration.
For now, 3 names were proposed:
- parameters
- options
- argument-overrides
I find "argument-overrides" a bit too verbose :p
I'll go with "parameters" for now since it's the title of this thread.
2. As Tobias and Ison suggested, we need to centralize the declaration of
parameters, so that we can list them and centralize metadata like the
description & types. Any suggestion on how to implement this in practice?
Where do we store them? How?
3. From Ludo's comment:
> • We’d need to store more info in manifest entries so that
> transformation options are preserved upon ‘guix upgrade’.
> ...
> • We might want to make the CLI option less verbose too, but how?
We'd also need a way to specify the parameters in the manifest specs and from
command line.
Now we have "@" and ":" for versions and outputs respectively. What about
parentheses? E.g.
"foo@2.0(:locale fr_FR.UTF-8 :audio pulseaudio :gui X)"
I think a plist like above would be less verbose than an alist.
To apply parameters to the rest of the command line, we could also do:
guix install --with-parameters="(:locale ...)" package-foo package-bar
4. From Ludo's comment:
> • We might need to expose the package parameters somehow, so that if
>one types ‘--with-argument=foobar=baz’, they get a correct error
>message saying that “foobar” is not a known parameter.
I think we should only display a warning so that we can emulate global USE
flags as Ison suggested.
5. Global parameter storage
When using "guix install" it can be convenient not to have to repeat the
parameter specification. So it'd be nice to store it somewhere. What about
a file in ~/.config/guix/parameters.scm with something like
(parameters
:locale fr_FR.UTF-8
:audio pulseaudio
...)
?
6. Leverage build systems to automate parameterization when possible.
Some build systems use well-known flags. For instance, for the
gnu-build-system if the user sets the parameter "(:audio pulseaudio)" we
could
automatically pass --enable-pulseaudio to the "configure" flags, even
for packages that didn't specify their own well-known parameters.
It would be nice if build systems had a way to report if a flag is supported
or not. Any clue?
To implement this, we could do the following:
(define-parameter audio
"Some description"
(types ...)
(argument
(lambda (pkg)
(match (package-build-system pkg)
(gnu-build-system
(add-to-configure-flags "--enable-pulseaudio"))
(cmake-build-system
(...))
7. Dependency management.
Also known as the USE flag nightmare among Gentoo users...
This is where hell breaks loose! :p
The problem: the user wants to specify a parameter to use globally where it
applies, on all installed packages and all their inputs, recursively.
For instance, use guile-2.2.4 instead of guile for all guile libraries, or
use pulseaudio everywhere, including in dependencies that are not explicitly
installed to the user profile.
The obstacle: A package may require inputs with a specific parameter.
For instance, BAR depends on a FOO package built with ":audio
pulseaudio". What happens if the user seta ":audio alsa" globally
and installs BAR? BAR needs to specify explicitly that its FOO input
requires pulseaudio. Otherwise BAR would fail to build.
To specify that a package input depends on a specific parameter, we could
extend the syntax of the (inputs ...) and (native-inputs ...) fields like so:
(input
`(("foo" ,foo "(:audio pulseaudio)")))
A bigger problem is that the parameter compatibility issue is combinatorial:
"Which parameter combination does BAR support?" It's hard to know it in
advance. Any idea how to tackle this?
The easy way around this is to not propagate the global parameters by
default, but this seriously limits the usefulness of global parameters.
Maybe a better workaround would be to automatically fall back to the default
value of all parameters when a build fails.
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Re: new micro release to address bug 36074 for new binary installs on foreign distributions with systemd
Hi Julien, On Thu, 02 Jan 2020 11:07:47 -0500 Julien Lepiller wrote: > Instead of a release from the master branch, maybe we can apply the fix on > top of the version-1.0.1 branch and release that? That way we won't need the > build farms to rebuild anything, while fixing the issue. We could also apply > patches to the graphical installer that were pushed after 1.0.1 maybe? There were also changes to the DVD bootloader (grub-mkrescue) which would be important to release. In any case, I'm doubtful whether fixing version-1.0.1 branch buys us much. Why not just release a new version from master? Is it broken? pgpvWBUz1LNWg.pgp Description: OpenPGP digital signature
Re: Package file indexing
Pierre Neidhardt writes: > Hello again! > > I'm resurrecting this since I've just started working on this as part of > the NGI application! :) > Internally it’d call ‘guix substitute’ to fetch the file index from the substitute server, check its signature, cache it locally, and then look up the file. > > What about storing the file listing in the narinfo instead? > Is this doable? If so, then it should be quite simple to implement, it > would basically mimic "guix size." I haven't followed this thread particularly well, but at least from my recent experience messing with nar and narinfo stuff in the Guix Data Service, I'd be cautious about trying to adapt narinfo files for this purpose. It seems to me that the narinfo file is a good at capturing the information about the hash, size, location and signature of the nar. They're small, and human readable. I think making information about the contents of Guix store items more available is great, but even in the average case, it seems like that's too much information to pack in to a narinfo file. Imagining a manifest in abstract, having a list of the files and directories as well as the hashes and sizes of the files could be really useful, but that for most store items, all that information is much larger than the narinfo files. A separate file might be more flexible. Additionally, now that I'm thinking about this, having information about each store item is great, but if you want to know which store items in a particular revision of Guix contain files called foo, then it might take a while to download and search them all. Having something that's focused around the packages in a channel, and acts as an index for all of the files in all of the available outputs might be faster to search, by doing the combining of the data upfront. Chris signature.asc Description: PGP signature
Re: Claws Mail missing libetpan
On Thu, Jan 02, 2020 at 12:29:47PM -0500, Julien Lepiller wrote: > Le 2 janvier 2020 12:14:50 GMT-05:00, Marco van Hulten a > écrit : > >Hello— > > > >I get an error compiling Claws Mail (claws-mail): > > > >checking for libetpan-config... no > >*** Claws Mail requires libetpan 0.57 or newer. See > >http://www.etpan.org/ > >*** You can use --disable-libetpan if you don't need IMAP4 and/or NNTP > >support. > >configure: error: libetpan 0.57 not found > >command > >"/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" > >"./configure" > >"CONFIG_SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" > >"SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" > >"--prefix=/gnu/store/knhrmn4cjqyxrmbwqm33vwakma8gcpql-claws-mail-3.17.4" > >"--enable-fast-install" "--build=x86_64-unknown-linux-gnu" > >"--enable-gnutls" "--enable-pgpmime-plugin" "--enable-enchant" > >"--enable-ldap" failed with status 1 > > > >First installing libetpan (the Guix package) does not help. > > > >—Marco > > There's no reason it should help: builds are completely isolated from the > host environment. There is nothing you can do to influence them. > > I'm sorry I can't help though, because I have a charger issue for my laptop. > I don't remember having an issue with claws-mail recently, so maybe try to > run guix pull if you're not already on the latest version. > > Otherwise, what is the version of libetpan in guix and does it contain a > libetpan-config? > I recently upgraded libetpan from 1.9.3 to 1.9.4, and with it we lost the libetpan-config binary. There's an open bug¹ with libetpan upstream to mention the now missing binary. There's also an upstream patch² but I'm having a hard time getting it to work. ¹ https://github.com/dinhviethoa/libetpan/issues/338 ²https://git.claws-mail.org/?p=claws.git;a=commit;h=f4ea5707862db1678e418fbdde805d09efaa2ee5 -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Cross-compilation broken on canonical packages.
Hola! Mathieu Othacehe skribis: >> Two simple solutions here, I think: >> >> 1. Make ‘packages’ a thunked field. >> >> 2. Stop using ‘canonical-package’ altogether in ‘%base-packages’. >> >> I actually have a preference for #2. We’d need to check what impact it >> has on the system closure size, but I suspect it’s going to be minimal. >> >> Thoughts? > > Option #2 seems nicer. There are other canonical-package calls when > building services. I have a patch attached that removes all those calls. > > The image produced when running "guix system disk-image bare-bones.tmpl" > increases by: > > * 30MB when removing the canonical-package of %base-packages > * 30MB for all other calls. OK. (It may be slightly more accurate to look at the output of: guix size $(guix system build …).) > So altogether, that's a 60MB increase on a 1.5GB image (4%). I find it > acceptable, WDYT? It’s more than I thought but I think it’s OK. (Also, how come bare-bones takes 1.5 GiB?!) > From a55eb86975c5f1c2783b0af265364821259e3351 Mon Sep 17 00:00:00 2001 > From: Mathieu Othacehe > Date: Tue, 31 Dec 2019 09:56:51 +0100 > Subject: [PATCH] system: Stop using canonical-package. > > Usage of canonical-package outside of thunked fields breaks cross-compilation, > see: https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00410.html. > > * gnu/installer.scm (installer-program): Remove canonical-package. > * gnu/services/base.scm (): Ditto, > (%base-services): ditto. > * gnu/services/xorg.scm: Remove useless canonical-package import. > * gnu/system.scm (%base-packages): Remove canonical-package. > * gnu/system/install.scm (%installation-services): Ditto, > (installation-os): ditto. > * gnu/system/locale.scm (single-locale-directory): Ditto, > (%default-locale-libcs): ditto. [...] > --- a/gnu/system/locale.scm > +++ b/gnu/system/locale.scm > @@ -86,7 +86,7 @@ or #f on failure." > #f))) > > (define* (single-locale-directory locales > - #:key (libc (canonical-package glibc))) > + #:key (libc glibc)) >"Return a directory containing all of LOCALES for LIBC compiled. > > Because locale data formats are incompatible when switching from one libc to > @@ -147,7 +147,7 @@ data format changes between libc versions." > > (define %default-locale-libcs >;; The libcs for which we build locales by default. > - (list (canonical-package glibc))) > + (list glibc)) I would leave this bit unchanged if possible, because that way the glibc used would really match that programs are linked against. The rest LGTM, thanks! Ludo’.
Re: Claws Mail missing libetpan
Le 2 janvier 2020 12:14:50 GMT-05:00, Marco van Hulten a écrit : >Hello— > >I get an error compiling Claws Mail (claws-mail): > >checking for libetpan-config... no >*** Claws Mail requires libetpan 0.57 or newer. See >http://www.etpan.org/ >*** You can use --disable-libetpan if you don't need IMAP4 and/or NNTP >support. >configure: error: libetpan 0.57 not found >command >"/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" >"./configure" >"CONFIG_SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" >"SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" >"--prefix=/gnu/store/knhrmn4cjqyxrmbwqm33vwakma8gcpql-claws-mail-3.17.4" >"--enable-fast-install" "--build=x86_64-unknown-linux-gnu" >"--enable-gnutls" "--enable-pgpmime-plugin" "--enable-enchant" >"--enable-ldap" failed with status 1 > >First installing libetpan (the Guix package) does not help. > >—Marco There's no reason it should help: builds are completely isolated from the host environment. There is nothing you can do to influence them. I'm sorry I can't help though, because I have a charger issue for my laptop. I don't remember having an issue with claws-mail recently, so maybe try to run guix pull if you're not already on the latest version. Otherwise, what is the version of libetpan in guix and does it contain a libetpan-config?
Claws Mail missing libetpan
Hello— I get an error compiling Claws Mail (claws-mail): checking for libetpan-config... no *** Claws Mail requires libetpan 0.57 or newer. See http://www.etpan.org/ *** You can use --disable-libetpan if you don't need IMAP4 and/or NNTP support. configure: error: libetpan 0.57 not found command "/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" "./configure" "CONFIG_SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" "SHELL=/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash" "--prefix=/gnu/store/knhrmn4cjqyxrmbwqm33vwakma8gcpql-claws-mail-3.17.4" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--enable-gnutls" "--enable-pgpmime-plugin" "--enable-enchant" "--enable-ldap" failed with status 1 First installing libetpan (the Guix package) does not help. —Marco
Re: new micro release to address bug 36074 for new binary installs on foreign distributions with systemd
Le 2 janvier 2020 04:28:28 GMT-05:00, Calvin Heim a écrit : >Hi Guix developers, > >I would like to encourage interest in a new (micro?) release >for the website. > >Every new systemd user who installs Guix v1.0.1 >from the binary release on a foreign distribution >encounters the solved bug 36074 [1]. It is solved, >but `guix pull` can't administer the solution because >the affected file isn't located under /var/guix. >So each new systemd user that installs the binary on a foreign >distribution >must manually fix their /etc/systemd/system/guix-daemon.service >to get the quotation marks right. > >I understand that a new release is a sizable request and I respect your >authority over this matter. > >Sincerely > >Calvin > >[1] https://issues.guix.gnu.org/issue/36074 Instead of a release from the master branch, maybe we can apply the fix on top of the version-1.0.1 branch and release that? That way we won't need the build farms to rebuild anything, while fixing the issue. We could also apply patches to the graphical installer that were pushed after 1.0.1 maybe?
new micro release to address bug 36074 for new binary installs on foreign distributions with systemd
Hi Guix developers, I would like to encourage interest in a new (micro?) release for the website. Every new systemd user who installs Guix v1.0.1 from the binary release on a foreign distribution encounters the solved bug 36074 [1]. It is solved, but `guix pull` can't administer the solution because the affected file isn't located under /var/guix. So each new systemd user that installs the binary on a foreign distribution must manually fix their /etc/systemd/system/guix-daemon.service to get the quotation marks right. I understand that a new release is a sizable request and I respect your authority over this matter. Sincerely Calvin [1] https://issues.guix.gnu.org/issue/36074
Re: qtwenengine anybody?
Am 01.01.20 um 23:30 schrieb mike.ros...@gmail.com: > I think the package is looking pretty good now. I sent some changes > requested by Hartmut today so we might need to wait on any more changes > he might have. I tried applying the patches to see the complete/compiled diff, but `git am` failed. Can you please send an updated patch or provide a link to some online-repo to view the complete diff. Thanks -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: How can I set architecture/system-specific origin sources?
Thank you Efraim, this is exactly what I needed. I've applied the trick used by GHC (simpler in my opinion), it works perfectly. As Mathieu pointed out, this is a bit unsettling at first. Is this (thunked) behaviour documented anywhere? If not, shall we documented it? Where? Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Stop generating ‘fonts-dir’ directories
Hello. Currently Guix attempts to ‘merge’ font packages which install themselves into the same file path by generating ‘…-fonts-dir’ directories with symbolic links and combined fonts.dir files. Needless to say, it is completely broken. The X.org server has not been following symbolic links to font files for some time now for security reasons. This is the kind of hack required currently to make X server fonts work: XFONTDIRS="$(realpath -z ~/.guix-profile/share/fonts/X11/*/!(fonts.dir) | sed 's:[^/]*\x00:\x00:g' | sort -zu | tr '\0' ,)" There appears to be simply no way to fix the current approach. The X server will not follow symbolic links. So there is not point in generating these font directories.
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
On Fri 20 Dec 2019 22:08, Ricardo Wurmus writes: > zimoun writes: > >> - I propose the name "guix shell" > > This is not a bad idea, especially considering that “guix environment” > was meant to get shebang support, so that you could use it as the > interpreter in a script that handles the environment configuration. > > It is also shorter. I like this idea. It would also allow us to deprecate "guix environment" over a period of a year or so, and we can probably show an equivalent "guix shell" invocation in the deprecation message. Andy
