Hello Eric,
Eric Bavier writes:
>
> Could you try again after doing a 'make clean-go' and making sure that
> all .go files have been removed? This is the same error I was seeing
> earlier that was caused by a stale .go file in the build tree.
That indeed solved the problem. Thank you very mu
On 2016-08-31 22:28, Lukas Gradl wrote:
Hello!
Since early this week I seem to be unable to build some packages in
master. I am not sure what the problem is, I think I am working with
a clean copy of origin/master, so I doubt that any of my own hacking
broke anything. Here is what I see:
[..
Hello!
Since early this week I seem to be unable to build some packages in
master. I am not sure what the problem is, I think I am working with
a clean copy of origin/master, so I doubt that any of my own hacking
broke anything. Here is what I see:
---8<--- cut here start
On 2016-08-31 18:11, Leo Famulari wrote:
On Wed, Aug 31, 2016 at 02:25:49PM -0400, Troy Sankey wrote:
I understand why this happens:
% khal --help
Usage: .khal-real [OPTIONS] COMMAND [ARGS]...
[...]
but I think it sorta sucks for user experience. Just thought I'd
point this
out, and I
On Wed, Aug 31, 2016 at 02:25:49PM -0400, Troy Sankey wrote:
> I understand why this happens:
>
> % khal --help
> Usage: .khal-real [OPTIONS] COMMAND [ARGS]...
> [...]
>
> but I think it sorta sucks for user experience. Just thought I'd point this
> out, and I was wondering if there were a
I understand why this happens:
% khal --help
Usage: .khal-real [OPTIONS] COMMAND [ARGS]...
[...]
but I think it sorta sucks for user experience. Just thought I'd point this
out, and I was wondering if there were any ideas to address this.
Specifically, argv[0] references the name of the "
Quoting Ludovic Courtès (2016-08-31 16:21:49)
> (That said, more and more software is distributed via Git rather than as
> tarballs, and most repos are unsigned; even if they were, there are
> basically no tools to meaningfully authenticate a Git checkout…)
In that case, not all hope is lost---I'v
>> I think there’s currently no easy way to cross build a full GuixSD
>> anyway, like ‘guix system build --target=mips64el-linux-gnu’ (the
>> --target flag doesn’t exist yet). Or did you experiment in this area?
I'm operating under the assumption that when using the --target flag
packages aren't
Hi Ludo,
>> So one issue that happens when cross building is for things that have
>> the #:no-substitutes #t enabled. This is mainly found in service
>> derivations for generating configuration files.
>
> I think there’s currently no easy way to cross build a full GuixSD
> anyway, like ‘guix syste
Ludovic Courtès writes:
> Hi,
>
> Arun Isaac skribis:
>
>> When you are building a package from source, the Parabola build system
>> verifies the GPG signature of the source archive if the developer's key
>> is in your keyring. Else, it raises an error and asks you to get the
>> required key man
On Wednesday 31. August 2016 22.04.35 Ludovic Courtès wrote:
>
> Paul Boddie skribis:
> >
> > OK. I tend to run things in chroots for basic protection against things
> > deciding to install stuff in places I would rather keep "clean", and to
> > use different distro versions and packages.
>
> P
Hi,
Arun Isaac skribis:
> When you are building a package from source, the Parabola build system
> verifies the GPG signature of the source archive if the developer's key
> is in your keyring. Else, it raises an error and asks you to get the
> required key manually. There is also an option that
Hi David,
David Craven skribis:
> So one issue that happens when cross building is for things that have
> the #:no-substitutes #t enabled. This is mainly found in service
> derivations for generating configuration files.
I think there’s currently no easy way to cross build a full GuixSD
anyway,
Hi Paul,
Paul Boddie skribis:
>> > Are there any recommended methods of running guix-daemon in a chroot and
>> > have it create new chroots, or do I have to use some kind of
>> > virtualisation or container technology? Is any kind of
>> > fakeroot/fakechroot mechanism supported?
>>
>> I think f
> Does Parabola have some sort of keyring that all the upstream keys go
> into? Or did I misinterpret your suggestion? I'm not familiar with the
> Parabola package management system.
No, Parabola does not collect upstream keys into any centralized keyring.
When you are building a package from so
On Wed, Aug 31, 2016 at 01:17:57PM +0530, Arun Isaac wrote:
Alex Kost wrote:
> > I think the procedure is: a packager verifies the source and that's it.
> > Since a package has a hash of the source, we can be sure that the source
> > wasn't changed since it was packaged, so if we find that a packag
Hi,
So one issue that happens when cross building is for things that have
the #:no-substitutes #t enabled. This is mainly found in service
derivations for generating configuration files. I guess if you aren't
using substitutes at all and want to cross-compile everything, it will
take a while till
Arun Isaac writes:
> [ Unknown signature status ]
>
>> I think the procedure is: a packager verifies the source and that's it.
>> Since a package has a hash of the source, we can be sure that the source
>> wasn't changed since it was packaged, so if we find that a package has
>> a compromised sou
> I think the procedure is: a packager verifies the source and that's it.
> Since a package has a hash of the source, we can be sure that the source
> wasn't changed since it was packaged, so if we find that a package has
> a compromised source, we can blame the packager.
Ah, that sounds good eno
Arun Isaac (2016-08-31 08:37 +0300) wrote:
> I am trying to package a package that provides a GPG signed source
> archive. Is there any way to get Guix to verify this signature, by say,
> specifying it in the 'origin' object of the 'source' field of the
> package? What is the standard way this is
20 matches
Mail list logo
