Fair points and well argued.
Am Samstag, den 17.07.2021, 01:46 -0400 schrieb Philip McGrath:
> On 7/16/21 6:26 PM, Leo Prikler wrote:> As others point out, it is
> debatable whether or not such a trademark
> > can be enforced, but what we should be discussing -- and I'd be
&g
Am Donnerstag, den 15.07.2021, 13:06 +0200 schrieb Leo Prikler:
> Am Mittwoch, den 14.07.2021, 09:57 -0400 schrieb Bone Baboon:
> > [...]
> >
> > In this response to the pull request I submitted about the
> > questionable files in the cowsay repository
> > <
Am Donnerstag, den 15.07.2021, 13:06 +0200 schrieb Leo Prikler:
> Am Mittwoch, den 14.07.2021, 09:57 -0400 schrieb Bone Baboon:
> > [...]
> >
> > In this response to the pull request I submitted about the
> > questionable files in the cowsay repository
> > <
Am Mittwoch, den 14.07.2021, 09:57 -0400 schrieb Bone Baboon:
> [...]
>
> In this response to the pull request I submitted about the
> questionable files in the cowsay repository
> <
> https://github.com/tnalpgge/rank-amateur-cowsay/pull/4#issuecomment-878092487
> >
> apjanke is requesting
Hello Peter,
Am Dienstag, den 13.07.2021, 22:38 +0800 schrieb Lo Peter:
> Dear all,
>
> I am experimenting with writing a package definition for an example R
> package (https://github.com/jennybc/foofactors) in a PRIVATE channel,
> where the R source is also at a PRIVATE github repository.
>
Hello Giovanni,
overall you make a great summary, there's just some points I wish to
add as I'm also following the drama around audacity.
Am Montag, den 12.07.2021, 10:37 +0200 schrieb Giovanni Biscuolo:
> Can I say that's not a Guix problem? :-)
>
> AFAIU The Muse Group intentions are that
Am Mittwoch, den 30.06.2021, 10:11 +0200 schrieb Mathieu Othacehe:
> Hello,
>
> > I think we do have the obligation to clearly document channels-
> > with-
> > substitutes-available and make it so that this particular piece of
> > documentation can easily be found by everyone who is potentially
>
I think the potential to confuse new users with this enabled by default
is higher than without it. Assume that Alice just sent a bug report to
Guix, that has been closed or has otherwise been made aware of some bug
affecting a software she uses, for which a fix has been pushed.
Naturally, she's
Am Freitag, den 25.06.2021, 16:30 +0200 schrieb Ludovic Courtès:
> Leo Prikler skribis:
>
> > Am Freitag, den 25.06.2021, 13:44 +0200 schrieb Ludovic Courtès:
>
> [...]
>
> > > However, variants of a given package have the same package
> > > name/ve
Am Freitag, den 25.06.2021, 13:44 +0200 schrieb Ludovic Courtès:
> Hello!
>
> Cuirass support in (gnu ci) computes job names as a function of
> package
> names (the ‘job-name’ procedure). I wanted to build several package
> variants using ‘--with-input’, which I expressed in a manifest:
>
>
Am Donnerstag, den 24.06.2021, 20:42 +0300 schrieb Andrew Tropin:
> It should be `guix home build ./path/to/file.scm`. Also, make sure
> that
> before first run you've set proper GUILE_LOAD_PATH. (See
> https://sr.ht/~abcdw/rde/ Guix Home section, Option 2).
>
> It won't be needed, when Guix
Hi jgarte et al.
Am Montag, den 21.06.2021, 16:33 + schrieb jgart:
> Hi Guix,
>
> We've (Ryan, David, Raghav, and others) started packaging crystal for
> guix: https://crystal-lang.org/
>
> See 49142 and 49158 in the issue tracker.
>
> Here are some notes, questions, and a list of
Hi,
Am Montag, den 21.06.2021, 12:32 +0200 schrieb Ricardo Wurmus:
> Hi,
>
> commit ce6efff6eca0ed88cb9538803f5d1252c91a3b5e updated
> virtualenv. As part of this change python-distlib was replaced
> with python-distlib/next.
>
> This broke the *installation* (not the build) of other
Am Samstag, den 19.06.2021, 13:59 +0800 schrieb Zhu Zihao:
> Hello Guix!
>
> In January I'm following up a series of patches(
> https://issues.guix.gnu.org/45784) that fixes Qt build
> system to honor user's environment variable. It has been six months
> now,
> but these patches are still in
Hello Giovanni,
Am Mittwoch, den 16.06.2021, 19:32 +0200 schrieb Giovanni Biscuolo:
> Dear Leo F. and Leo P.
>
> Leo Famulari writes:
>
> > On Tue, Jun 15, 2021 at 11:39:59PM +0200, Leo Prikler wrote:
> > > Am Dienstag, den 15.06.2021, 19:24 +0200 schrieb Giovanni
is very
> reason, for me this is the most important *feature* of a free
> software distribution: no spyware ALSO means no opt-out telemetry.
>
> To be clear: if Guix "only" had the fantastic features it has but was
> not FSDG compliant, I'd use something else (and be ve
Am Montag, den 14.06.2021, 16:29 +0200 schrieb Pjotr Prins:
> On Tue, Jun 08, 2021 at 03:11:31PM +0200, Ludovic Courtès wrote:
> > (I’m late to the party…)
>
> Never late :)
>
> > > I found a cargo -> ninja converter. It is that kind of idea. Guix
> > > would use ninja with rustc instead of
Am Sonntag, den 13.06.2021, 23:54 + schrieb Ryan Prior:
> An easy API to discover whether you have any packages that could be
> upgraded would be very handy as well. Currently I find this
> information by running `guix time-machine --branch=master -- package
> -u --dry-run --no-grafts` but
Am Sonntag, den 13.06.2021, 13:57 -0400 schrieb Leo Famulari:
> On Sun, Jun 13, 2021 at 11:32:01AM +0200, Leo Prikler wrote:
> > Of course, there's the added bonus of the lead developer
> > expressing their views in a… rather aggressive tone to put it
> > mildly,
> >
Am Samstag, den 12.06.2021, 22:03 -0400 schrieb Bone Baboon:
> Leo Prikler writes:
> > Am Samstag, den 12.06.2021, 23:44 +0200 schrieb Tobias Geerinckx-
> > Rice:
> > > Bone Baboon 写道：
> > > > Should the patch be to remove the kitty package?
> > >
>
Am Sonntag, den 13.06.2021, 01:12 +0200 schrieb Leo Prikler:
> Hello everyone,
>
> Am Samstag, den 12.06.2021, 23:44 +0200 schrieb Tobias Geerinckx-
> Rice:
> > Hi Bone,
> >
> > Bone Baboon 写道：
> > > Should the patch be to remove the kitty package?
&
Hello everyone,
Am Samstag, den 12.06.2021, 23:44 +0200 schrieb Tobias Geerinckx-Rice:
> Hi Bone,
>
> Bone Baboon 写道：
> > Should the patch be to remove the kitty package?
>
> No. The telemetry.
If I read terminals.scm, we already disable the telemetry in kitty:
> (invoke "python3" "setup.py"
Guix commit 9178566954cc7f34d2d991d31df4565adad93508 ought to fix this
with a patch and graft. If you haven't updated already, consider doing
so. If you want to play with polkit, you can always roll back :P
> Our issue is a different one: Its about being able to reuse already
> compiled binaries - keeping current behavior of rust binaries being
> statically linked.
>
> While this looks like being the same as dynamic library support, it
> is not: While for dynamic libraries you meet to ensure the
Am Sonntag, den 06.06.2021, 12:14 +0200 schrieb Maxime Devos:
> Leo Prikler schreef op zo 06-06-2021 om 09:39 [+0200]:
> > I think we might want to export a utility procedure
> > (patch-shebangs files inputs)
>
> This procedure already exists, but is undocume
I think we might want to export a utility procedure
(patch-shebangs files inputs)
so that files used during build (e.g. configure, Makefile, etc.) can do
(patch-shebangs build-stuff native-inputs) and the rest implicitly gets
(patch-shebangs files inputs) during the patch-shebangs phase.
Am Dienstag, den 01.06.2021, 13:28 +0200 schrieb Adriano Peluso:
> Il giorno mar, 01/06/2021 alle 13.03 +0200, Leo Prikler ha scritto:
> > Am Dienstag, den 01.06.2021, 12:52 +0200 schrieb Adriano Peluso:
> > > Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikle
Am Dienstag, den 01.06.2021, 12:52 +0200 schrieb Adriano Peluso:
> Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikler ha scritto:
> > > The output could be a collection of .tar.gz files distributed
> > > through
> > > ipfs, bittorrent, syncthing or rsync
> &g
Am Dienstag, den 01.06.2021, 10:59 +0200 schrieb Adriano Peluso:
> Il giorno mar, 01/06/2021 alle 08.24 +0200, Leo Prikler ha scritto:
> > > A sexp-pack would represent the most simple build instructions to
> > > build a package on its own. Now, of course the current guix-
Am Dienstag, den 01.06.2021, 09:23 +0200 schrieb Pjotr Prins:
> On Tue, Jun 01, 2021 at 08:24:51AM +0200, Leo Prikler wrote:
> > > I have a feeling they won't be that interested ;).
> > I do think some of them are interested, but you're right in that
> > the
Am Montag, den 31.05.2021, 19:47 +0200 schrieb Pjotr Prins:
> On Sun, May 30, 2021 at 09:17:20PM +0200, Konrad Hinsen wrote:
> > How about pushing all the other package manager towards producing
> > sexp-packs, and helping them to get there?
>
> I have a feeling they won't be that interested ;).
Am Dienstag, den 25.05.2021, 18:42 +0100 schrieb Paul Garlick:
> Hi Guix,
>
> I recently attempted to reproduce a profile containing emacs-auctex,
> only to find a '404: not found' error.
>
> The reason is that elpa.gnu.org archives previous auctex versions
> with a .tar.lz extension. This
I'm a little confused.
Rather than a package manager, CMake is a build system, but people have
written several[1] package[2] managers[3] in CMake (the language), let
alone the other package managers for C/C++, all of which make me
question if anyone ever asked for any of them. I don't think
Hi,
the blog post you've linked
https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/
seems to neither contain mentions of XDG_CONFIG_DIR, nor mcron.
Did you mean
https://guix.gnu.org/en/blog/2020/gnu-shepherd-user-services/
instead?
FWIW, $XDG_CONFIG_DIR should be
Am Dienstag, den 18.05.2021, 14:37 +0200 schrieb Julien Lepiller:
> Le Tue, 18 May 2021 13:36:43 +0200,
> Leo Prikler a écrit :
>
> > Am Dienstag, den 18.05.2021, 07:15 -0400 schrieb Julien Lepiller:
> > > The old scala is written in a superset of java5, that requires
&
r can target a specific (early) version and we get a
slightly smaller binary or are the gains from that too minimal? This
is also a concern going forward, can we always hope to "bootstrap" the
next Scala version with the one currently packaged in Guix?
> Le 18 mai 2021 05:44:42 GM
Hi Julien,
Am Dienstag, den 18.05.2021, 01:01 +0200 schrieb Julien Lepiller:
> Hi Guix!
>
> I have the attached file that build Scala, although it's not
> bootstrapped at all. It contains %binary-scala, a few dependencies of
> Scala we haven't packaged yet, and the final scala, built from
>
Am Samstag, den 15.05.2021, 15:25 -0400 schrieb Jack Hill:
> Leo,
>
> Thanks for your reply
>
> On Sat, 15 May 2021, Leo Prikler wrote:
>
> > Your code imports (guix utils), but (guix utils) is not present
> > within
> > the module closure present at buil
Am Samstag, den 15.05.2021, 01:07 -0400 schrieb Jack Hill:
> Greetings Guix,
>
> I'm working on creating a build system for Janet [0] modules. This is
> my
> first time working with build systems, and while I have a much
> better
> understanding than when I started, I still don't understand it
Am Samstag, den 08.05.2021, 22:52 +0200 schrieb Maxime Devos:
> Leo Prikler schreef op za 08-05-2021 om 12:16 [+0200]:
> > [... something about dependencies and copyleft ...]
> > [...]
> > However, compliance is not *that* simple. If you're dealing with
> > cop
Am Samstag, den 08.05.2021, 13:17 +0200 schrieb Ricardo Wurmus:
> Leo Prikler writes:
>
> > For the record, what command gives you transitive source
> > closure? I
> > can see transitive binary closure with `guix pack`, but I don't
> > think
> > we do
Hi,
Am Freitag, den 07.05.2021, 11:31 -0700 schrieb Chris Marusich:
> My understanding is that the intent of the "license"
> field (which can be a list) in a Guix package is to call out the
> "main"
> (deliberately vague here) licenses related to the code, not to
> provide
> an exhaustive or
Hi Mark,
Am Montag, den 03.05.2021, 05:00 -0400 schrieb Mark H Weaver:
> Leo Prikler writes:
>
> > Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver:
> > > I don't think I fumbled on the facts at all. It's true that I
> > > didn't
> > &g
Hi Mark,
Am Sonntag, den 02.05.2021, 17:02 -0400 schrieb Mark H Weaver:
> Hi Leo,
>
> Leo Prikler writes:
>
> > Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver:
> >
> > Likewise, there's no middle ground on assuming evil
> > intentions, you e
Hi Mark,
Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver:
> Hi Leo,
>
> Leo Prikler writes:
>
> > Let us assume for
> > the sake of argument I were to introduce a bug into Guix. There
> > are a
> > number of ways this can happen, but let's fo
Am Sonntag, den 02.05.2021, 12:17 +0800 schrieb 宋文武:
> Hello Leo, I see nothing wrong for assuming bad faith when security
> fixes of packages are removed, in the end the truth matter, which I
> believe is: You thought the patches for cario is not needed now on
> core-updates, so you remove them.
Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver:
> Hi Leo,
>
> I took the liberty of refilling the quotations in your email to make
> them more readable.
Please do.
>
> Leo Prikler writes:
>
> > Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H W
Hi Mark,
Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver:
> Hi Leo,
>
> Leo Prikler writes:
>
> > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
> > > I also spent some time re-reading messages that Mark sent in this
> > >
Hello Giovanni,
I am not Mark or Ludo, but as a /generic other/, I'd still like to
reply.
Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo:
> Hello Mark and Ludovic,
>
> please forgive me if I'm going forward with this thread but, after
> some
> hesitation, I decided to write
Hello,
Am Freitag, den 30.04.2021, 01:43 +0200 schrieb Leo Le Bouter:
> I think that the GNU Guix maintainers justify unacceptable behavior
1. What makes you think that?
2. How do you justify your own behaviour, specifically the kind of
behaviour, that others have asked you to justify?
> [The
Am Donnerstag, den 29.04.2021, 11:13 +0200 schrieb Léo Le Bouter:
> On Wed, 2021-04-28 at 17:52 +0200, Marius Bakke wrote:
> > Léo,
> >
> > We maintainers have been disappointed by Marks harsh tone which do
> > not
> > meet the project's communication standards, but also by your
> > apparent
> >
Hi Pjotr,
Am Donnerstag, den 29.04.2021, 07:44 +0200 schrieb Pjotr Prins:
> Hi Leo (Prikler),
>
> On Thu, Apr 29, 2021 at 01:52:12AM +0200, Leo Prikler wrote:
> > I don't know enough about marketing to give you a good answer on
> > that,
> > but when it comes to w
Am Samstag, den 24.04.2021, 01:50 + schrieb Ryan Prior:
> On April 23, 2021, Leo Famulari wrote:
> > On Fri, Apr 23, 2021 at 10:00:14PM +0200, Leo Prikler wrote:
> > > Spreadsheets sounds fine to me, but I think the most important
> > ones
> > > (libreoffice a
Am Freitag, den 23.04.2021, 15:04 + schrieb jgart:
> This is a continuation of the thread started at
> http://issues.guix.gnu.org/47852
>
> Ekaitz: What do we want to be the main point of the programs: their
> UI or their goal?
>
> jgart: I would prefer for them to be catalogued based on
Hi,
Am Freitag, den 23.04.2021, 20:50 +0200 schrieb Léo Le Bouter:
> I think there is no problem in accepting criticism but there is a
> certain way Mark presents criticism and I don't feel like I can
> respond
> to it when it is written in such way. Over several emails Mark was
> looking to
Am Freitag, den 23.04.2021, 14:22 + schrieb Luis Felipe:
> Hi,
>
> Are all these constants (%base-packages, for example)? Is this a Guix
> convention or does it come from Guile? Although looking at Guile's
> Variable index I see many constants in uppercase, and also some
> variables prefixed
Am Donnerstag, den 22.04.2021, 22:01 +0200 schrieb Léo Le Bouter:
> On Thu, 2021-04-22 at 00:08 -0400, Mark H Weaver wrote:
> > Hi Raghav,
> >
> > Raghav Gururajan writes:
> >
> > > > Those commits on 'core-updates' were digitally signed by Léo Le
> > > > Bouter
> > > > and have the same
Hi Mark,
Am Mittwoch, den 21.04.2021, 17:11 -0400 schrieb Mark H Weaver:
> Hello Guix,
>
> Raghav Gururajan has pushed another misleading "cosmetic changes"
> commit. This one is *far* worse than the examples I gave before.
> This one removes the security fixes for CVE-2018-19876 and
>
> One thing I'd like to try is to split up packages into more outputs,
> kinda like what Alpine does. This isn't really technically
> challenging,
> it's mostly just busywork and adding some default build phases and
> maybe some more default outputs. But it is a pretty big change, so,
> is
> this
Hi Vladilen,
Am Freitag, den 16.04.2021, 09:57 +0100 schrieb Vladilen Kozin:
> Hi all.
>
> Could a kind soul handhold me while I try to port a python package to
> guix please. I am not a python programmer, so not on first name basis
> with python ecosystem and new to guix - double trouble.
>
>
Hi Carlo,
Am Donnerstag, den 08.04.2021, 13:17 +1000 schrieb Carlo Zancanaro:
> Hi Leo!
>
> Thanks so much for working to improve Emacs packaging in Guix! I
> have a question and a comment about your approach on the wip-emacs
> branch.
>
> On Tue, Apr 06 2021, Leo Prikler
Am Dienstag, den 06.04.2021, 11:06 +0200 schrieb Leo Prikler:
> Hello Guix,
>
> this is a small progress report on wip-emacs. Emacs now gets its
> core
> lisp path from the wrapper rather than the search path and there's a
> new profile hook adding all top-level subdirectori
Am Dienstag, den 06.04.2021, 20:21 +0200 schrieb Xinglu Chen:
> On Tue, Apr 06 2021, Leo Prikler wrote:
>
> > There are still some packages, that use the old convention, e.g.
> > emacs-
> > geiser.
>
> FYI Geiser has recently been slit up into multiple packages wi
Hello Guix,
this is a small progress report on wip-emacs. Emacs now gets its core
lisp path from the wrapper rather than the search path and there's a
new profile hook adding all top-level subdirectories to a subdirs.el,
that gets loaded at startup. Emacs' build system has been rewritten to
use
Am Sonntag, den 04.04.2021, 11:32 +0200 schrieb Xinglu Chen:
> On Sat, Apr 03 2021, Leo Prikler wrote:
>
> > Your patch LGTM in a vaccum (except that package-version this-
> > package
> > could be abbreviated to just "version" IIUC), but I went for a
>
Am Samstag, den 03.04.2021, 13:57 +0200 schrieb Xinglu Chen:
> On Sat, Apr 03 2021, Xinglu Chen wrote:
>
> > I tried the 'wip-emacs' branch (commit
> > b18d605fcb51bcce56a1114f82645658db9f5b14), and I noticed that
> > 'emacs-emacsql' was failing to install. The 'make-autoloads' phase
> > fails
Hello Guix,
as at least some of you are hopefully aware, the way Emacs interacts
with Guix packaging is unsatisfactory in a few key ways. In
particular, each major version upgrade completely breaks Emacs both
running and not yet running until environment variables are updated
[1]. Also, there
Hello,
Am Freitag, den 26.03.2021, 20:36 +0100 schrieb Léo Le Bouter:
> Hello!
>
> I often meet problems where some packages don't work out of the box
> because they have some runtime dependencies like themes or third
> party
> programs.
>
> I solved these problems on occasion by making commits
Hi raingloom,
Am Montag, den 22.03.2021, 13:40 +0100 schrieb raingloom:
> I'm packaging the Molly Brown Gemini server and I'm trying to play
> nice
> with the already packaged gmnisrv.
> Should the two use the same service name and system users? Most users
> probably won't want to run both
Am Dienstag, den 09.03.2021, 01:08 -0500 schrieb Raghav Gururajan:
> > I like Mark's suggestion of "t-todo-list-manager" as well as
> > Raghav's suggestion for "t-cli"; in that order.
> >
> > Either name sounds good to me, though.
>
> Cool!
>
> Since, we already mention "todo list manager" in
Hello Vinícius
Am Mittwoch, den 03.03.2021, 15:31 -0300 schrieb Vinícius dos Santos
Oliveira:
> Hi,
>
> I was curious about how a language/runtime module system needs to be
> designed to use guix as a package manager. I'm developing my own
> require() function for a Lua host and I'd like to make
> Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to
> have
> a higher version number, but with the old 4.02 package code and
> source?
> Or a manifest including some time-machine thing, or a personal
> package
> transformation that compiles xpdf --with-source=...?
It's up to you,
Hello Sebastian,
Am Donnerstag, den 18.02.2021, 15:04 +0800 schrieb Sebastian:
> Dear developers at Guix,
>
> I am a physics student willing to use the Geant4 simulation toolkit
> from the European Organization for Nuclear Research (CERN).
> https://geant4.web.cern.ch/
> The Geant4 code is
Hello,
Guix itself does not handle any secrets yet -- at best you could
consider the password field of the user-account structure to be one,
and that is not particularly kept a secret either (it shows up as
plaintext). Depending on your use-case, there might also be services
like the
Am Dienstag, den 09.02.2021, 11:22 +0100 schrieb Hartmut Goebel:
> Am 09.02.21 um 11:06 schrieb Leo Prikler:
> > Depends on the package. If it gets propagated into the build
> > environment, the variable is set as well. At other times, it might
> > be
> > set through
Am Dienstag, den 09.02.2021, 04:56 -0500 schrieb Raghav Gururajan:
> Hi Leo!
>
> > Both search-paths and native-search-paths are expanded in a build
> > environment to form an environment variable. search-paths works on
> > inputs whereas native-search-paths works on native-inputs. In
> >
Hello,
Both search-paths and native-search-paths are expanded in a build
environment to form an environment variable. search-paths works on
inputs whereas native-search-paths works on native-inputs. In
addition, native-search-paths also end up in your
$GUIX_PROFILE/etc/profile.
Regards,
Leo
Hi elaexuotee,
> More specifically, the package I have builds separate libraries for
> CPUs with
> AVX, AVX2, and no AVX support. Since build-type isn't sufficiently
> specific to
> distinguish such CPU features, I have, so far, opted to just build
> all three
> libs and stuff them under /lib/.
Hello Raghav,
looking at the way you phrased this in IRC, I just found out, that I
misunderstood your mail. Basically, what you need to do to achieve
something like that with Guix currently, would be to keep two (or more)
config.scms and reconfigure each one after guix pull in a fixed order.
Hello Raghav,
I had a similar idea a little more than a year ago:<
https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html>
See also <
https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00083.html>
for the discussion it spawned.
While the default profile would stay active at
Am Mittwoch, den 20.01.2021, 16:08 -0500 schrieb Mark H Weaver:
> Leo Prikler writes:
>
> > There could potentially be another workaround by synchronizing
> > inside
> > guild, i.e. claiming a lock before reading and evaling any given
> > source
> >
Messed up ML address.
--- Begin Message ---
Hi Ludo,
IIUC this issue potentially affects all packages, that use Guile to
build more than two modules, no?
There could potentially be another workaround by synchronizing inside
guild, i.e. claiming a lock before reading and evaling any given source
Hi Julien,
Am Sonntag, den 10.01.2021, 07:28 -0500 schrieb Julien Lepiller:
> I might be wrong, but I thought fonts were considered non-functional
> data. If that's the case, isn't cc-by-nc-nd acceptable?
Not according to the FSDG:
> [Non-functional data] can be included in a free system
gt; original submission, get it committed with the comment that the
> package needs to be compiled rather than copied, when someone (or I)
> wants to so properly?
>
> Cheers,
> Yasu
>
>
> > On Jan 10, 2021, at 18:16, Leo Prikler <
> > leo.prik...@s
Hello Vincent,
there is no .tar of the fonts however, that's a source tarball
generated by github. To be fair, one should probably build this font
(and other fonts) from source instead. In particular, we might want to
package nerd-fonts[1] first, since Cascadia appears to be an iteration
of it.
Hello Magali,
have you looked into (ice-9 peg)? An easy pretty grammar, that would
catch your example would be the following:
--8<---cut here---start->8---
(use-modules (ice-9 peg))
(define-peg-pattern commit-hash all (ignore "%h"))
(define-peg-pattern
Hello Rovanion,
Am Samstag, den 02.01.2021, 15:43 +0100 schrieb Rovanion Luckey:
> I can get the package to build using the following steps:
>
> git clone https://github.com/nomacs/nomacs.git
> cd nomacs
> mkdir build
> cd build
> guix environment --ad-hoc cmake make gcc libraw exiv2 libtiff
Hi Rovanion,
Am Donnerstag, den 31.12.2020, 16:37 +0100 schrieb Rovanion Luckey:
> [...]
>
> > 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 inputs properly packages.
Hi rovanion,
> (define-module (nomacs)
The nomacs package should probably go to gnu/packages/image-
viewers.scm.
> (source (origin
> (method url-fetch)
> (uri (string-append "
> https://codeload.github.com/nomacs/nomacs/tar.gz/; version))
> (sha256
>
Hello everyone,
earlier today, I was granted commit access to the repository [1]. This
message is signed with the key I will use for signing my commits. It
should have the following info:
pub rsa4096 2020-12-16 [SC]
ACC23BA059F7CCF408F043AD442A84B8C70E2F87
uid [ultimate] Leo
Hello, yasu
I recently submitted #44354, which would set GUIX_GTK*_IM_MODULE_FILE
from the system configuration. Once this patch is merged, you should
be able to add ibus and ibus-anthy to your operating-system packages
and have them picked up from there by gnome.
Note, that this patch would as
Hi,
Am Mittwoch, den 04.11.2020, 14:43 +0100 schrieb Danny Milosavljevic:
> Hi,
>
> On Wed, 04 Nov 2020 10:45:06 +0100
> Leo Prikler wrote:
>
> > But we already know all this from our earlier discussion.
>
> I *know* you already know that--but "we"
Am Mittwoch, den 04.11.2020, 18:05 +0800 schrieb Zhu Zihao:
> Leo Prikler writes:
>
> > launch-environment/container still assumes the command to be a
> > shell
> > script, which I think is not quite what you want. You probably
> > want to
> > take a look at
Hi,
Am Mittwoch, den 04.11.2020, 09:08 +0100 schrieb Danny Milosavljevic:
> Hi,
>
> I've checked guile-gi test/insanity.scm again to find "hard"
> evidence.
>
> For that, I've just checked out guile-gi anew, then ran
> test/insanity.scm.
>
> Steps:
> [...]
> That's it. It fails.
Okay, but it
Hello,
Am Mittwoch, den 04.11.2020, 11:49 +0800 schrieb Zhu Zihao
> "guix environment --container" is a very useful feature for me to
> isolate the untrusted software. But sadly it lacks a interface for
> user
> to use it in Lisp programming.
>
> In (guix scripts environment), only
Hi Danny,
Am Dienstag, den 03.11.2020, 20:26 +0100 schrieb Danny Milosavljevic:
> Hi Leo,
>
> On Tue, 03 Nov 2020 14:41:31 +0100
> Leo Prikler wrote:
>
> > > (note: "-l guix.scm")
> > >
> > > seems to have fixed most of the problems.
&
Hi Danny,
Am Dienstag, den 03.11.2020, 10:14 +0100 schrieb Danny Milosavljevic:
> I've now gotten guile-gi to work okay for me, too.
That is great to hear.
> For me, there were many reasons why it didn't work before--some of
> them follow:
>
> (1) I originally built guile-gi from source using
>
Hi Danny,
Am Montag, den 02.11.2020, 11:17 +0100 schrieb Danny Milosavljevic:
> Hi,
>
> On Mon, 02 Nov 2020 08:44:29 +0100
> Pierre Neidhardt wrote:
>
> > Danny Milosavljevic writes:
> > > Not much more works yet because I've hit this (design) bug in
> Guix and/or
> > > GNOME:
> > >
> > > *
Well, the "functional" way of accessing them all in one go would be to
(map (cute <> foo) (list package-name package-version package-...))
But I assume you want syntax like
(let-field record field exp*)
(let-fields record (field1 field2...) exp*)
analogous to (srfi srfi-9 gnu) set-field and
Hello, Pierre
> Also I wonder why guile is in there.
According to guix graph, guile is pulled by gnutls.
> 1. Does anyone have a recipe for Emacs without GTK+ (that can also
>display pictures)?
Not directly, but you could try building it with motif (package
lesstif) or Lucid/Athena (requires
1 - 100 of 121 matches
Mail list logo
