On 28. Nov 2019, at 00:37, EuAndreh wrote:
> Does your blog have an Atom feed?
Yes, at https://vllmrt.net/spam/atom.xml, though I neglected to link it properly
previously. Should be fixed now, thanks!
Cheers
Robert
Hi guix-devel,
I wrote a series of articles related to my Elm packaging for Guix:
https://vllmrt.net/spam/guix-elm-1.html
https://vllmrt.net/spam/guix-elm-2.html
https://vllmrt.net/spam/guix-elm-3.html
It covers packaging, adding a build system, and adding and
deploying a service. Part 2 in
On 18. Nov 2019, at 21:40, John Soo wrote:
>
> Hi Robert,
>
> Interesting. Looks alright to me. Also I did just package ormolu myself and
> everything worked alright. One thing to try is using `guix repl` to reproduce
> the error. Can you open one up and see what happens?
Actually that
Hi,
I’m in writing up some notes on my Guix packaging work earlier this year, and
am running into an unexpected problem that I’m lost with. A concrete example:
$ guix import hackage ormolu > ormolu.scm
add missing imports at the top of ormolu.scm:
(use-modules (guix packages))
(use-modules
Hi Ricardo,
> On 16. Aug 2019, at 20:07, Ricardo Wurmus wrote:
>
>> I have some Haskell-related changes ready for review and ideally merge
>> on wip-haskell-updates.
>>
>> I’ve tested them locally to the extent I managed; is CI broken or did I break
>> something there?
Hi,
I have some Haskell-related changes ready for review and ideally merge
on wip-haskell-updates.
I’ve tested them locally to the extent I managed; is CI broken or did I break
something there? http://ci.guix.gnu.org/jobset/wip-haskell-updates
Changes are:
1. move libraries out of haskell.scm
On 8. Aug 2019, at 18:40, Chris Marusich wrote:
> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
>> 'switch-to-system-generation' doesn't call out to
>> 'upgrade-shepherd-services'. I'm not sure if this was an intentional
>> decision or not
>
> It is intentional, but only because
On 8. Aug 2019, at 15:12, Marius Bakke wrote:
> I have one comment about the series: we've disabled tests on some
> packages that have been broken "forever" on i686. It would be better to
> do so selectively on just the affected architectures. I.e.:
>
> #:tests? (if (string-prefix? "i686"
Could we get some input on this bug?
Maybe I’m misunderstanding something, but it seems that a core guix
feature (atomic rollbacks) doesn’t work…
> On 30. Jul 2019, at 12:00, Robert Vollmert wrote:
>
> What I see:
>
> 1. edit ~/pzprnode/pzprnode
>
> rob@garp ~/pzprnode$
Oh, I meant to ask:
On 6. Aug 2019, at 06:29, Timothy Sample wrote:
> Robert Vollmert writes:
>
>> Hi all, Timothy,
>
> Cool! I’m in the process of looking everything over. In the meantime,
> I have some early questions and comments.
>
>> I’ve incorporated you
Hi Timothy,
> On 6. Aug 2019, at 06:29, Timothy Sample wrote:
>
>> #36663: adding elm compiler dependencies (just a few extra ghc
>> packages)
>
> These commits seem to be in the wrong order. I think I can untangle
> them, though.
>
>> #36692: GHC version 8.6.5 (just as a package for now,
askell packages that fail on i686 only
(and seem harmless): ghc-trifecta, ghc-yaml, ghc-libmpd-haskell.
Cheers
Robert
> Hi Robert,
>
> Robert Vollmert writes:
>
>> This series removes some outdated packages that don’t build and
>> aren’t depend on.
>
> I
> On 31. Jul 2019, at 20:16, Jakob L. Kreuze
> wrote:
>
> Hi Robert,
>
> Robert Vollmert writes:
>
>> The concrete problem is this:
>>
>> 1. nginx is running with config file A
>> 2. make some change to nginx config
>> 3. run guix syste
> On 31. Jul 2019, at 18:45, Jakob L. Kreuze
> wrote:
> Robert Vollmert writes:
>
>> Hi,
>>
>> it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012
>>
>> guix system: Reimplement 'reconfigure’.
>>
>> breaks guix
Hi,
it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012
guix system: Reimplement 'reconfigure’.
breaks guix system reconfigure. In particular, after reconfiguring,
shepherd doesn’t know about the updated versions of services.
The usual output below is missing; after reverting the
> On 31. Jul 2019, at 17:27, Ricardo Wurmus wrote:
>
>> I’ve been working on some patches on the wip-haskell-updates branch. For now,
>> I’ve been making new commits, and occasionally merging master, not least
>> because forced push is rejected. But this makes the branch more messy than
>>
Hi,
I’ve been working on some patches on the wip-haskell-updates branch. For now,
I’ve been making new commits, and occasionally merging master, not least
because forced push is rejected. But this makes the branch more messy than
necessary — do you generally not rebase the wip-branches, or if
On 25. Jul 2019, at 19:38, Ludovic Courtès wrote:
> Robert Vollmert skribis:
>
>>>> The current status of the evaluation of wip-haskell-updates is quite
>>>> confusing. There are a number of jobs listed as “Scheduled” with a red
>>>> X mark at the fron
Hi,
some questions that the ci interface should answer, but makes quite hard:
- on a given branch, which packages are broken? (the answer seems to be:
all packages that have a failed build in some evaluation and that don’t
have a successful build anytime later)
- on a given branch, which
Hi,
On 29. Jul 2019, at 18:10, Ricardo Wurmus wrote:
> Most build systems inherit from the gnu-build-system, so they’ll get to
> reuse the “unpack” phase, which conveniently checks if the source is a
> tarball. In the case of Java archives it doesn’t do the right thing,
> because it doesn’t
> On 29. Jul 2019, at 17:49, Ricardo Wurmus wrote:
>> currently, when using the git-fetch origin, the resulting source will have
>> all files read-only. Further phases trying to do reproducibility patches
>> have
>> to manually chmod in order to be able to patch.
>>
>> Can we change that?
On 23. Jul 2019, at 18:35, Marius Bakke wrote:
>
> Robert Vollmert writes:
>
>> There are a couple of tests that fail (on master, but also the haskell
>> updates
>> branch), compare
>>
>> http://ci.guix.gnu.org/eval/6534?status=failed
>>
There are a couple of tests that fail (on master, but also the haskell updates
branch), compare
http://ci.guix.gnu.org/eval/6534?status=failed
They all seem to fail with the following:
Starting test basic (Writing full log to "basic.log")
marionette is ready
> On 22. Jul 2019, at 22:44, Robert Vollmert wrote:
>
>
>
>> On 22. Jul 2019, at 21:50, Robert Vollmert wrote:
>>
>> Hi Ricardo,
>>
>>> On 22. Jul 2019, at 21:01, Ricardo Wurmus wrote:
>>>
>>>> Now I was wondering how
> On 22. Jul 2019, at 21:50, Robert Vollmert wrote:
>
> Hi Ricardo,
>
>> On 22. Jul 2019, at 21:01, Ricardo Wurmus wrote:
>>
>>> Now I was wondering how to get CI to test that.
>>
>> Adding branches is currently done manually. I’ll
Hi Ricardo,
> On 22. Jul 2019, at 21:01, Ricardo Wurmus wrote:
>
>> Now I was wondering how to get CI to test that.
>
> Adding branches is currently done manually. I’ll just update the
> table of branches to build on ci.guix.gnu.org in a few minutes.
nice, thanks!
The current status of the
Hi all,
just pushed my first commit to the new branch wip-haskell-updates,
yay!
Now I was wondering how to get CI to test that. From a trip through
the sources, the following would appear to work:
In guix/gnu/ci.scm:
Define %haskell-packages, e.g. as all packages defined in
I’m getting the following warnings when running “make” in the guix repo:
WARNING: (guix scripts archive): `error-source' imported from both (gcrypt
common) and (gcrypt pk-crypto)
WARNING: (guix scripts archive): `error-string' imported from both (gcrypt
common) and (gcrypt pk-crypto)
When I run `make` in the guix repository, I always get the following
block of warnings at the start:
configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its
use is discouraged.
configure.ac:23: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro
instead,
Hi Danny,
I don’t particularly care about this interface improvement making
it in, I’m ok with leaving things as they are. I do however feel
that some of the points made against deserve a reply.
On 19. Jul 2019, at 10:32, Danny Milosavljevic wrote:
> On Fri, 19 Jul 2019 09:46:15 +0200
>
1c6bf7e150445126448f1d5be4822889961f451f Mon Sep 17 00:00:00 2001
From: Robert Vollmert
Date: Fri, 19 Jul 2019 09:40:53 +0200
Subject: [PATCH] columnize list-installed and list-available
---
guix/scripts/package.scm | 49
1 file changed, 30 insertions(+), 19
On 15. Jul 2019, at 20:38, Robert Vollmert wrote:
>
>> On 15. Jul 2019, at 17:40, Ricardo Wurmus wrote:
>>
>> P writes:
>>
>>>> Hi Pierre,
>>>>
>>>>> Quite often when packaging and iterating, the daemon produces backtrace
> On 15. Jul 2019, at 14:25, Ludovic Courtès wrote:
>
> Hi,
>
> Robert Vollmert skribis:
>
>> It’s a bit my fault, for remarking on the fact that the cargo build
>> system does use guile-json. I suppose that’s not worth fixing either
>> at this point?
&
> On 15. Jul 2019, at 17:40, Ricardo Wurmus wrote:
>
>
> P writes:
>
>>> Hi Pierre,
>>>
Quite often when packaging and iterating, the daemon produces backtraces
on errors, which could be very useful to understand what's wrong, but
unfortunately the output is truncated to
> On 15. Jul 2019, at 19:21, Jesse Gibbons wrote:
>
> On Sun, 14 Jul 2019 15:54:10 +0200
> Ludovic Courtès wrote:
>
>> Hello!
>>
>> Jesse Gibbons skribis:
>>
>>> I noticed that a few files have only one package definition and are
>>> named for that package. I think these packages can be
> On 15. Jul 2019, at 15:47, Robert Vollmert wrote:
>
> This adds the elm compiler, version 0.19.0. This provides the
> `elm` command, with the exception of the `elm reactor` subcommand.
>
> Named `elm-compiler`, to leave space for `elm` as the full elm
> including reactor.
On 14. Jul 2019, at 20:19, Julien Lepiller wrote:
>
> Le Sun, 14 Jul 2019 15:40:43 +0200,
> Ludovic Courtès a écrit :
>> The effect of this change is to import the (json parser) from the host
>> side into the build side.
>>
>> As a result, if I have installed Guile-JSON 1.2 and you have
>>
> On 12. Jul 2019, at 22:42, Robert Vollmert wrote:
> I’m a bit at a loss right now with respect to how to make fonts available
> to system services.
>
> I’m running a service that uses rsvg-convert (from package librsvg) to
> raster some SVG graphics. However, it appear
Hi all,
I’m a bit at a loss right now with respect to how to make fonts available
to system services.
I’m running a service that uses rsvg-convert (from package librsvg) to
raster some SVG graphics. However, it appears that the default fonts
are missing some Unicode character.
It seems that I
Hi,
I’m trying to figure out how to package elm apps nicely. There are:
- elm apps, which typically result in some compiled elm code as *.js
files, and which depend on a number of elm “packages” by precise
version.
- elm packages, libraries of elm source; as usual, these come in
various
> On 9. Jul 2019, at 12:22, Ricardo Wurmus wrote:
>
>
> Hi Robert,
>
- more consistent and useful output — currently it’s very easy to miss the
actual cause of an error between a lot of noise, e.g. all those
“recompiling
scheme module” messages
>>>
>>> When do you see
Hi all,
I realize this isn’t generally an aim for guix proper, but I’d like
to be able to build a package from a local git repository (or
optionally from a local tar ball). In my specific case, it’s while
working out the packaging of a project I intend to publish but
haven’t published yet.
What
Hi,
I’m currently writing some slightly repetitive mcron jobs
in my config.scm that use gexps / program-file. I’m wondering
whether there’s a better way to share code between these than
writing a separate scheme file and importing that via
with-imported-modules?
That approach works, but it’s a
On 5. Jul 2019, at 23:41, Ludovic Courtès wrote:
> Robert Vollmert skribis:
>
>>> On 1. Jul 2019, at 12:28, Ludovic Courtès wrote:
>>>
>>> Hello,
>>>
>>> Robert Vollmert skribis:
>>>
>>>> I’d like to improve the debug
Hi,
On 6. Jul 2019, at 03:08, Timothy Sample wrote:
> Ludovic Courtès writes:
>> Robert Vollmert skribis:
>>> * I’m a bit unclear on where to file the various new
>>> ghc-* packages. Currently it’s more or less aribtrarily spread
>>> across a bunch of mo
> On 1. Jul 2019, at 12:28, Ludovic Courtès wrote:
>
> Hello,
>
> Robert Vollmert skribis:
>
>> I’d like to improve the debug output here more generally: At (high enough)
>> debug level, it seems to make sense to log every operation. What I’m unclear
>>
> On 1. Jul 2019, at 11:55, Ludovic Courtès wrote:
>
> Hello,
>
> Robert Vollmert skribis:
>
>> - better stack traces when things go wrong (this would be both guile work
>> and guix guile-module work as far as I can tell)
>
> I agree that we must keep
> On 4. Jul 2019, at 13:28, Ricardo Wurmus wrote:
>
>
> Hi Robert,
>
>> I’ve just updated and rebundled them to fix the haskell packages
>> that were added to Guix in the meantime (original patch from Jun 1:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36038).
>
> thank you for these
this was discussed was that we should implicitly
depend on the GHC-included packages instead of re-packaging them:
https://lists.gnu.org/archive/html/guix-patches/2019-06/msg0.html
Cheers
Robert
> On 4. Jul 2019, at 09:57, Robert Vollmert wrote:
>
> These are ghc-8.4-bundled packages, removing
> On 1. Jul 2019, at 23:48, Ricardo Wurmus wrote:
>> - `guix search` would ignore library packages by default
>
> I think it’s valid for users to want to install libraries. For Python,
> for example, installing modules that don’t provide any executables
> appears to be the norm.
The idea
Hi,
now that postgrest 6.0.0 has made it to hackage:
http://hackage.haskell.org/package/postgrest
I’d like to submit my packaging of it for inclusion
in guix. The current state is visible here:
https://github.com/robx/guix-postgrest
Some questions/open issues:
* I’ve submitted a few
> On 30. Jun 2019, at 20:01, Pierre Neidhardt wrote:
>
> Hi Robert!
>
> `guix search` and other user-facing tools ignore non-exported packages.
>
> So you can simply use `define` instead of `define-public` to declare a
> package.
Good point, but that breaks down once a library is used by a
Hi,
I’m currently packaging some tools that would add a decent
amount of source-only dependencies. (Some from npm, some for
elm).
Clearly they should somehow be packaged properly in order
to track licensing information and refer to upstream. On the
other hand, it doesn’t feel particularly useful
(this should really be a top-level reply, but I missed the original mail)
On 30. Jun 2019, at 15:13, Giovanni Biscuolo wrote:
>
> Hello,
>
> Ludovic Courtès writes:
>
> [...]
>
>> What do *you* want Guix to address in the future?
>>
>> #+TITLE: GNU Guix Beyond 1.0—A Road Map
A bit of an
Hi,
thanks for the detailed reply.
On 27. Jun 2019, at 17:34, Ludovic Courtès wrote:
> Robert Vollmert skribis:
>
>> I’m trying to investigate why guix-daemon appears to spend
>> a lot of time locking store directories. (It’s possible that
>> it’s doing useful work a
Hi all,
not sure where’s the best place to ask this, but:
I’m not receiving follow-up emails from debbugs.gnu.org to bugs I’ve
submitted, at least not reliably. (I do get replies when I’m CC’d
explicitly, but mails to @debbugs.gnu.org don’t seem to come
through.)
Is this normal, or is there
Hi,
I’m trying to investigate why guix-daemon appears to spend
a lot of time locking store directories. (It’s possible that
it’s doing useful work and just the debug output is useless.)
To do this, I’ve tried adding some debug statements to the
C++ files in guix/nix/…. I’m having trouble getting
> On 18. Jun 2019, at 15:32, Ludovic Courtès wrote:
>
> Hi,
>
> Danny Milosavljevic skribis:
>
>> I think it could be made part of shepherd and be exported there, then
>> everyone
>> could use it. Logging to syslog isn't exactly an obscure requirement :)
>
> +1!
>
>> Although shepherd
> On 17. Jun 2019, at 14:45, Danny Milosavljevic wrote:
>
> But doesn't shepherd already log to /dev/kmsg and/or /dev/log (so that ends up
> in syslog)? Since exec-command keep the standard output and standard
> error,
> they (and thus all shepherd services) should also already log to the
>
Hi all,
I came up with the following wrapper that uses logger to redirect a
program’s console output to syslog:
(define* (logger-wrapper name exec . args)
"Return a derivation that builds a script to start a process with
standard output and error redirected to syslog via logger."
(define exp
On 14. Jun 2019, at 22:24, Ricardo Wurmus wrote:
> Timothy Sample writes:
>>
>> We mostly do this already. There is a Stackage importer, and a little
>> while ago I updated most of our Haskell packages to their LTS 12
>> versions.
>
> At the beginning we just had all the latest packages from
[ missed the list cc previously ]
> On 14. Jun 2019, at 21:59, Ricardo Wurmus wrote:
>> * I can run etc/indent-code.el by hand from the guix source
>> repo, but it would be much nicer to have it available as a
>> regular executable.
>
> I would not package it. Isn’t it already usable as an
Hi,
a couple of questions regarding indenting scheme code.
* I can run etc/indent-code.el by hand from the guix source
repo, but it would be much nicer to have it available as a
regular executable. I tried briefly but failed to package it
— should the package definition fail to the in-tree local
On 13. Jun 2019, at 16:25, Timothy Sample wrote:
>
>> I remembered one more: guix refresh. As far as I understand, it works
>> only on the level of the source field, thus having the revision there
>> would help make it revision-aware. I’m unsure though whether the
>> snippet approach actually
Hi Timothy,
thanks for your reply.
> On 12. Jun 2019, at 06:54, Timothy Sample wrote:
>
> Hi Robert,
>
> I patched the “cabal-revision” stuff into the build system, so I suppose
> I should weigh in here. :)
>
> Robert Vollmert writes:
>
>> Hello all,
>&
Hello all,
I have a question regarding how cabal revisions are handled
for haskell packages. Namely, would it make sense / is it
possible to make the revised cabal file part of the source
field in the package definition?
Summary for non-haskell-experts: A hackage package of
a given version can
66 matches
Mail list logo
