Transform options should error on nonexistant targets

2021-08-17 Thread Ryan Prior
I learned today that Guix will chug happily along applying a transform to a 
nonexistent package.

For example, I can run:
guix environment --with-latest=not-exist --ad-hoc which

This shows no warning or errors. I think it would be beneficial to show an 
error & bail if the target of a transformation is a package that doesn't exist, 
as this is likely indicative of an error.

What do you think?

Re: Hundreds of failed build on master following git package update

2021-08-17 Thread Christopher Baines

br...@waegenei.re writes:

> Today I pushed 2 commits¹ related to the package to master, mainly to
> update it to 2.33.0. But since then https://data.guix.gnu.org/ went
> offline and Cuirass' evaluation #4930² has 556 failed build. Newly
> failed builds have unhelpful logs, ending with "cannot build missing
> derivation [...]"³.
>
> Before pushing those commits, I build git and git-minimal successfully
> on x86_64 and assessed the total impacted package for this update to
> be inferior to 300. Did I do something wrong with the update commit?
> Or is it an unrelated issue?

Hey,

Thanks for noticing that data.guix.gnu.org was down. I've had a look,
and the machine that runs it ran out of disk space.

I'm not quite sure why it ran out of disk space, I suspect it was maybe
excessive PostgreSQL logs... anyway, I'll get things going again and
keep an eye on it.

Once data.guix.gnu.org has caught up it will be easier to see what the
impact of this change is. I don't have any reason to think it was wrong
to make these changes.

Thanks,

Chris


signature.asc
Description: PGP signature


Re: Hundreds of failed build on master following git package update

2021-08-17 Thread Sarah Morgensen
Hello,

br...@waegenei.re writes:

> Hello Guix,
>
> Today I pushed 2 commits¹ related to the package to master, mainly to update 
> it to 2.33.0. But since then https://data.guix.gnu.org/ went offline and 
> Cuirass' evaluation #4930² has 556 failed build. Newly failed builds have 
> unhelpful logs, ending with "cannot build missing derivation [...]"³.
>
> Before pushing those commits, I build git and git-minimal successfully on 
> x86_64 and assessed the total impacted package for this update to be inferior 
> to 300. Did I do something wrong with the update commit? Or is it an 
> unrelated issue?
>
> I'm currently locally building some packages which have failed on the CI to 
> see if I can reproduce them and to obtain more verbose build log.
>
> ¹ 
> https://git.savannah.gnu.org/cgit/guix.git/log/?id=ea04295256329511b3201feaefb17900b05053b0
> ² https://ci.guix.gnu.org/eval/4930?status=failed
> ³ https://ci.guix.gnu.org/build/396873/log/raw
>
> Cheers,
> - Brice

That sounds awfully familiar.  I wonder if this is related to the
following issue?

Mathieu Othacehe  writes:

> Hello Sarah,
>
>> substitute: [Kupdating substitutes from 'http://141.80.167.131'...   0.0%
>> substitute: [Kupdating substitutes from 'http://141.80.167.131'... 100.0%
>> cannot build missing derivation 
>> ?/gnu/store/r1p932bjq21nv4g2qf8fydrphr6fwnw7-go-golang-org-x-lint-0.0.0-0.83fdc39.drv?
>
> Yes, I recently configured Cuirass to use the publish server behind
> ci.guix.gnu.org instead of its own server.
>
> This server uses caching and when a remote worker tries do build a
> derivation that is not available locally, it will also try to fetch the
> input derivations. If one of them is being baked and is above the cache
> bypass limit (50 MiB), the publish server will send a 404 error causing
> the build to stop altogether as you noticed.
>
> This is a clear limitation of this bypass/404 mechanism, that I intend
> to solve with: https://issues.guix.gnu.org/50040.
>
> Thanks,
>
> Mathieu

--
Sarah



Hundreds of failed build on master following git package update

2021-08-17 Thread brice
Hello Guix,

Today I pushed 2 commits¹ related to the package to master, mainly to update it 
to 2.33.0. But since then https://data.guix.gnu.org/ went offline and Cuirass' 
evaluation #4930² has 556 failed build. Newly failed builds have unhelpful 
logs, ending with "cannot build missing derivation [...]"³.

Before pushing those commits, I build git and git-minimal successfully on 
x86_64 and assessed the total impacted package for this update to be inferior 
to 300. Did I do something wrong with the update commit? Or is it an unrelated 
issue?

I'm currently locally building some packages which have failed on the CI to see 
if I can reproduce them and to obtain more verbose build log.

¹ 
https://git.savannah.gnu.org/cgit/guix.git/log/?id=ea04295256329511b3201feaefb17900b05053b0
² https://ci.guix.gnu.org/eval/4930?status=failed
³ https://ci.guix.gnu.org/build/396873/log/raw

Cheers,
- Brice




Re: Core updates frozen.

2021-08-17 Thread zimoun
Hi,

On Wed, 28 Jul 2021 at 13:50, Mathieu Othacehe  wrote:

> A new core-updates-frozen branch is available here:
> https://git.savannah.gnu.org/cgit/guix.git/log/?h=core-updates-frozen.

Cool!

> Your help is welcome :).

What is the schedule for the merge?

(I am back from holidays. :-))

Cheers,
simon



Re: bug#22366: Chicken Scheme release tarballs ship non-source C code

2021-08-17 Thread Tobias Geerinckx-Rice

[-bug, +devel]

Mario, Guix,

On 2021-08-17 11:13, Mario Domenech Goulart wrote:

(I tried to post this comment via the form in
http://issues.guix.gnu.org/22366 , but apparently that hasn't worked --
trying e-mail now)


Thank you for mentioning this, or I would have assumed it had been fixed 
by now.  I'm afraid you're not the first.  Probably not even the tenth 
:-(


That's unacceptable so I've simply disabled[0] the Web form[1] entirely 
for now.


Kind regards,

T G-R

[0]: 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=f8deebe7e9b00db1971ff3d32c78eaef3acb6864

[1]: http://issues.guix.gnu.org/22366#comment

Sent from a Web browser.  Excuse or enjoy my brevity.



Re: New signing key

2021-08-17 Thread zimoun
Hi Tobias,

On Tue, 29 Jun 2021 at 16:40, Tobias Geerinckx-Rice  wrote:
> Question: I think committers should be trusted with discretion in 
> how they prefer to manage their keys, but how about briefly 
> documenting a suggested sane key-management strategy to new 
> committers, like we already describe some rando's editor set-up? 
> :-)

Yes, it will be really helpful, I guess. :-)


Cheers,
simon