Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Thompson, David]

Okay so I was a little confused because gitolite has no test suite.
Turns out this failure is for the system test of the gitolite service
that I didn't know existed.  I figured out how to run that and
reproduced the failure.  Despite git-minimal being sufficient for
everything I use gitolite for on my server, using it breaks the system
test. I reverted back to using the bigger git package and the test is
passing again.  Revert pushed as commit
c4504dfb1da78f2f21fc5139a2fd5e82ed0ef21c.

Sorry for the breakage,

- Dave

Re: guix lint should support overrides

[Vagrant Cascadian]

On 2022-09-05, zimoun wrote:
> On mer., 24 août 2022 at 14:06, Vagrant Cascadian  wrote:
>
>> Maybe something like:
>>
>> (define-public thispackages
>>   (package
>>(name "thispackages"
>>...
>>(lint-overides
>> (list
>> ;; The upstream name is actually "This Packages", not a typo.
>> "typo in description: 'This Packages' should be 'This Package'")) 
>>
>> And then guix lint would hide or ignore things that would otherwise emit
>> the strings listed in lint-overrides ... or something like that. Maybe
>> exact match, maybe get into a little pattern matching, not
>> sure. Implementation is not my strong point here. :)
>
> Well, it is possible to turn off one specific checker for one package;
> using the ’properties’ field.  However, this “overides” requires more
> work. :-)

Though a single checker may check multiple things, and only get some of
them "wrong"; seems it would be worth having granularity for individual
checks.

> Basically, the wish is for description and synopsis and mainly for typo,
> right?

No, it seems odd to me to restrict this to particular categories of
checks. I would say any specific lint check might have cases where it is
not practical to fix the lint check, yet is not appropriate for a
particular package.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[zimoun]

Hi,

On lun., 05 sept. 2022 at 13:08, "Thompson, David"  
wrote:

>> https://ci.guix.gnu.org/build/1333185/details

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> ERROR:
>   1. :
>   uri: #< scheme: http userinfo: #f host: "141.80.167.131"
> port: #f path: "/nar/zstd/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv"
> query: #f fragment: #f>
>   code: 504
>   reason: "Gateway Time-out"
>   2. : 
> "http://141.80.167.131/nar/zstd/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv:
> HTTP download failed: 504 (\"Gateway Time-out\")"
> fetching path `/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv'
> (empty status: '')
> @ substituter-failed
> /gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv  fetching path
> `/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv' (empty
> status: '')

Hum, the previous evaluation reports the same failure:

 https://ci.guix.gnu.org/build/1324235/detail


> Will this build be retried at some point?

Evaluation 1333185 is rescheduled.


Cheers,
simon

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Thompson, David]

On Mon, Sep 5, 2022 at 1:22 PM Tobias Geerinckx-Rice  wrote:
>
> Thompson, David 写道：
> > Will this build be retried at some point?
>
> Yes: now ;-)
>
> (There are no automatic retries.)
>
> Fresh new errors at
> .
>
> I would say these look fundamental and not transient, but if you
> say you built this at home, I don't know what to say…

This log looks much different than the last one I saw.  I'll see if I
can figure out what's going on.

- Dave

Re: guix lint should support overrides

[zimoun]

Hi Vgrant,

On mer., 24 août 2022 at 14:06, Vagrant Cascadian  wrote:

> Maybe something like:
>
> (define-public thispackages
>   (package
>(name "thispackages"
>...
>(lint-overides
> (list
> ;; The upstream name is actually "This Packages", not a typo.
> "typo in description: 'This Packages' should be 'This Package'")) 
>
> And then guix lint would hide or ignore things that would otherwise emit
> the strings listed in lint-overrides ... or something like that. Maybe
> exact match, maybe get into a little pattern matching, not
> sure. Implementation is not my strong point here. :)

Well, it is possible to turn off one specific checker for one package;
using the ’properties’ field.  However, this “overides” requires more
work. :-)

Basically, the wish is for description and synopsis and mainly for typo,
right?


Cheers,
simon

Re: Failure with “guix copy“

[zimoun]

Hi Ludo,

On ven., 02 sept. 2022 at 15:35, Ludovic Courtès  wrote:

>> Well, I was expecting that the items were just copied.  Why ‘guix copy’
>> tries to locally build something?
>
> My guess: use ‘--no-grafts’ and it’ll copy the ungrafted package.

No, nothing is “grafted”. :-) Well, it is from a weird design of the
haskell-build-system applying a minor revision update via ’arguments’
and not via ’source’.  See the discussion here [1].

1: 


> Otherwise, Guix starts by building the package so it can compute the
> grafting derivation, at which point it’ll happily copy the grafted
> variant from that other machine.  But that’s typically not what you
> want.

What I want is just transfer ghc-lucid from one machine having it to
another.


Cheers,
simon

Re: Idea: fallback for guix pull?

[zimoun]

Hi,

Sorry for the late reply.

On sam., 06 août 2022 at 14:12, Christopher Rodriguez  
wrote:
> I haven't looked at the code at all, but perhaps it would be useful to
> users of Guix if, upon a guix pull with a commit that fails to
> authenticate, guix pull would still pull up to the last in the chain of
> successfully authenticated commmits?
>
> Right now, it stops the entire operation if one commit from one channel
> fails to authenticate, which has value (and might be useful as a setting
> or flag, for those with greater security concerns or those maintaining
> the channel).
>
> But assuming the authentications are done in order, could we make the
> default an effective "pin" to the last authenticated commit? This is
> probably the way users /should/ deal with this kind of issue anyway
> (disable-authentication is worrisome), and having the default be this
> kind of fallback would make it so users are still able to pull other
> channels they might have, or at least update to the last "good" commit.

Indeed, authentications are done in order (see ’authenticate-commits’
from (guix git-authenticate)) but the failure raises an error (see
’authenticate-commit’).

Note that the Git repository is already updated.  So, some tweaks would
be necessary to implement your suggestion.  Well, I am not convinced the
use-case is worth the effort.

However, I agree that a channel failing (for whatever reason) should not
be blocking for pulling all the others.  As discussed in bug#57559 [1].


Cheers,
simon

1: 

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Tobias Geerinckx-Rice]

Thompson, David 写道：

Will this build be retried at some point?


Yes: now ;-)

(There are no automatic retries.)

Fresh new errors at 
.


I would say these look fundamental and not transient, but if you 
say you built this at home, I don't know what to say…


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Thompson, David]

On Mon, Sep 5, 2022 at 9:01 AM Mathieu Othacehe  wrote:
>
>
> Hello David,
>
> I noticed that the gitolite test is now failing. Any chance it is
> related to the recent work on the package?
>
> https://ci.guix.gnu.org/build/1333185/details

Hmm, it built successfully for me and worked when I deployed it to my
own server. Looking at the log file from the CI system it seems that
the build failed due to a network issue:

@ substituter-started
/gnu/store/pszh9ml0nz1izsxi6d6x08dfl6cc11qb-manual-database-builder
substitute
  2172:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
Downloading 
http://141.80.167.131/nar/lzip/pszh9ml0nz1izsxi6d6x08dfl6cc11qb-manual-database-builder...
  1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
   771:15 11 (_)
In ice-9/exceptions.scm:
   406:15 10 (process-substitution # _ "/gnu/store/?" ?)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
479:9  8 (_)
In ice-9/boot-9.scm:
  1747:15  7 (with-exception-handler # ?)
  1685:16  6 (raise-exception _ #:continuable? _)
  1683:16  5 (raise-exception _ #:continuable? _)
  1685:16  4 (raise-exception _ #:continuable? _)
  1780:13  3 (_ #< components: (#<> #)
  1685:16  2 (raise-exception _ #:continuable? _)
  1683:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
  1. :
  uri: #< scheme: http userinfo: #f host: "141.80.167.131"
port: #f path: "/nar/zstd/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv"
query: #f fragment: #f>
  code: 504
  reason: "Gateway Time-out"
  2. : 
"http://141.80.167.131/nar/zstd/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv:
HTTP download failed: 504 (\"Gateway Time-out\")"
fetching path `/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv'
(empty status: '')
@ substituter-failed
/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv  fetching path
`/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv' (empty
status: '')

Will this build be retried at some point?

- Dave

Re: [PATCH v2] doc: Update contribution guidelines on patches, etc.

[Maxime Devos]

On 05-09-2022 15:12, Maxime Devos wrote:


On 05-09-2022 11:47, Ludovic Courtès wrote:

Hi,

Maxime Devos  skribis:


On 02-09-2022 15:12, Ludovic Courtès wrote:

Hello,

Liliana Marie Prikler  skribis:


* doc/contributing.texi ("Snippets versus Phases"): Replaced with...
("Modifying Sources"): ... this.  List more use cases and some 
principles.
It’s been a while; this looks like a nice improvement to me.  It’s 
a bit
long, but perhaps that’s avoidable.  If there are no objections, 
I’d say

go for it.

Have you seen my v2?

I guess I haven’t (I was catching up with email as I returned from
vacation).

Hmm should you send the latest agreed-upon version to 
guix-patc...@gnu.org for clarity?


I'll integrate the agreed-on changes into a v3 and merge some parts of 
Liliana' version and send it ...


See: #57598.

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Maxime Devos]

On 09-08-2022 18:30, Maxime Devos wrote:

  the
result of 'guix build --source' would be unusable on non-Guix systems, and also 
likely unusable on
Guix systems of another architecture.
--8<---cut here---end--->8---


The Oxford comma or lack thereof are acceptable stylistic conventions, 
but not a grammatical error. There are only two conjucts here though, 
so I don't think the Oxford comma applies here. Additionally, the two 
conjucts are about mostly the same thing, but just different 
(similar!) subcases that merely happen to need different 
qualifications (unusable on non-Guix vs. likely unusable on 
different-arch Guix), so I don't think that 'also' brings something here.


Oops, the 'also' was present in the original. I removed 'also', but 
found it to be more readable with 'also', so I'm keeping 'also' anyways.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2] doc: Update contribution guidelines on patches, etc.

[Maxime Devos]

On 05-09-2022 11:47, Ludovic Courtès wrote:

Hi,

Maxime Devos  skribis:


On 02-09-2022 15:12, Ludovic Courtès wrote:

Hello,

Liliana Marie Prikler  skribis:


* doc/contributing.texi ("Snippets versus Phases"): Replaced with...
("Modifying Sources"): ... this.  List more use cases and some principles.

It’s been a while; this looks like a nice improvement to me.  It’s a bit
long, but perhaps that’s avoidable.  If there are no objections, I’d say
go for it.

Have you seen my v2?

I guess I haven’t (I was catching up with email as I returned from
vacation).

Hmm should you send the latest agreed-upon version to guix-patc...@gnu.org for 
clarity?


I'll integrate the agreed-on changes into a v3 and merge some parts of 
Liliana' version and send it ...


Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Maxime Devos]

On 08-08-2022 23:51, Andreas Enge wrote:

20.4.5.3 Fixing technical issues (compilation errors, test failures, other bugs
...)
Usually, a bug fix comes in the form of a patch copied from upstream or another
distribution. In that case, simply adding the patch to the 'patches' field is
the most convenient and usually does not cause any problems; there is no need
to rewrite it as a snippet or a phase.
If no ready-made patch already exists, then choosing between a patch or a
snippet is a matter of convenience. However, there are two things to keep in
mind:
First, when the fix is not Guix-specific, it is strongly desired to upstream
the fix to avoid the additional maintenance cost to Guix. As upstreams cannot
accept a snippet, writing a patch can be a more efficient use of time.
Secondly, if the fix of a technical issue embeds a store file name, then it has
to be a phase. Otherwise, if a store file name was embedded in the source, the
result of 'guix build --source' would be unusable on non-Guix systems and
likely also unusable on Guix systems of another architecture.

Do you mean "phase" here instead of "snippet"? That is what I usually do...
My practice is to use a patch when the goal is to eventually change the
source code upstream (or it is already changed upstream and we can take a
patch from their git repo, say), and a phase when one cannot expect upstream
to incorporate the changes since they are specific to Guix (like embedding
store paths, as Liliana writes, where apparently a phase is the only option
anyway).


I meant 'snippet' in this subsubsection. Bugfixes seem useful to have in 
the result of "guix build --source", and appear to be required to be in 
there for the 'corresponding source' thing.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Mathieu Othacehe]

Hello David,

I noticed that the gitolite test is now failing. Any chance it is
related to the recent work on the package?

https://ci.guix.gnu.org/build/1333185/details

Thanks

Mathieu

Re: [POSTMORTEM] Subkey is not authorized by .guix-authorizations

[Tobias Geerinckx-Rice]

Ludovic Courtès 写道：
I’m busy these days so I’d rather not commit to starting a 
discussion on

this, but I’d suggest testing waters on #savannah on IRC.


They weren't wild about it.  We'd be asking for a lot from their 
perspective.  I haven't given up on convincing them otherwise, but 
an alternative approach would be to write a minimum viable 
verifier (the machine has Guile \o/ although it might need 
updating), and then just regularly pull the guix repository as 
(keyring) data, without executing any of its code.


Kind regards,

T G-R


signature.asc
Description: PGP signature

September update on bordeaux.guix.gnu.org

[Christopher Baines]

Hey,

The last update was sent out in May [1], so this update roughly covers
the last 3 months.

1: https://lists.gnu.org/archive/html/guix-devel/2022-05/msg00202.html

This hasn't been my primary focus, so some of the changes that somewhat
involve bordeaux.guix.gnu.org relate to using it for patch review, but
to keep this update short I'll mention those elsewhere.

## Numbers

Available from bordeaux.guix.gnu.org now, there's ~1.5 million nars,
which take up ~6.2TiB of space available.

Substitute availability for recent guix revisions is generally good,
although powerpc64le-linux substitute availability is lower than it
could be as there's not currently an always available machine to carry
out the builds.

## Hardware

In terms of machines, there was more work needed in the last few months
as hatysa, the HoneyComb LX2 machine building ARM things was running low
on storage and stopped booting. There's a couple of messages on
guix-sysadmin about this but it was eventually resolved.

Mixed up with this is the addition of another HoneyComb LX2 machine
(hamal), this brings the total number of machines doing ARM builds to 3
(hatysa, hamal and monokuma).

## The build coordinator

Hooks, which are used when various things happen can now run in
parallel. This is important to avoid delays when builds are submitted or
succeed.

Also, there was a bug in the agent that led to spurious build
failures. That's now been fixed.

## Mirrors

There's a few test mirror machines setup, and I asked for people to test
these to see what difference they make [2][3].

2: https://lists.gnu.org/archive/html/guix-devel/2022-05/msg00203.html
3: https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00186.html

A couple of responses [4][5] have come in to the mailing list, both of
which seem to suggest that mirrors could provide a significant boost to
substitute download speed.

4: https://lists.gnu.org/archive/html/guix-devel/2022-07/msg00163.html
5: https://lists.gnu.org/archive/html/guix-devel/2022-07/msg00320.html

Those test servers have been running for a while now, and are generally
unused. I'll probably shut them down shortly to save money, and try to
send out a more concrete plan of getting mirrors in place for
bordeaux.guix.gnu.org.

## Serving fixed output files by hash

There's a separate thread about this:

  https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00333.html

One thing that has changed is that the Guile fibers concurrent web
server (which is used by the nar-herder) now supports streaming
responses, which will reduce the memory usage of serving fixed output
files:

  https://github.com/wingo/fibers/pull/63

## Next steps

Building patches and non-master branches is starting to happen, and
that'll indirectly improve bordeaux.guix.gnu.org substitutes since it'll
have already built some things by the time the patches are merged.

As said above, from the limited data available, I think an argument
could be made that mirrors are worth it in terms of the reliability
benefits and potential performance improvements. I'll try to keep moving
this forward.

Operationally, I think the goal should be that it's not dependent on a
single person. Currently it's probably too dependent on me. Things like
moving the build-coordinator and nar-herder Git repositories to Savannah
and getting more of the machines owned by guix-europe are ways to
improve this.

zstd compression support has been requested, and I don't see any
significant blockers to this. I think the way forward is to add support
for cached recompression of the nar files in the nar-herder.

For build hardware, I think it remains to be seen how the addition of
the patch and non-master branch builds affect the load. As mentioned
above, having an always available powerpc64le-linux system would help
avoid a backlog of builds for that architecture.

It should also be much easier to see what the bordeaux build coordinator
is doing. I think this requires a web interface to expose the active
agents and builds.

If you're interested in working on any of this, do let me know as while
I don't have time to work on much of it myself, I should be able to make
time to help others.

Let me know if you have any comments or questions!

Thanks,

Chris


signature.asc
Description: PGP signature

Re: [POSTMORTEM] Subkey is not authorized by .guix-authorizations

[Ludovic Courtès]

Hi,

Andrew Tropin  skribis:

>> Setting a pre-push hook that invokes ‘guix git authenticate’, as
>> recommended in the manual (info "(guix) Commit Access"), should be
>> enough: ‘git push’ would just fail in that situation.
>
> For some reason I thought it does git verify-commit, which I used
> manually to check if commit is signed, but it does make authenticate,
> which of course works the other way.  Missed it, my bad.

OK.

> I have elaborated on this topic a little more in the manual.
>
> From e510ea1595c54bec788485f0638967d457afaf3d Mon Sep 17 00:00:00 2001
> From: Andrew Tropin 
> Date: Mon, 5 Sep 2022 09:46:23 +0300
> Subject: [PATCH] doc: Add more info about commits signature local
>  verification.
>
> * doc/contributing.texi (Commit Access): Add more info about commits signature
> local verification.

It’s certainly an improvement, LGTM!

> Let's ask savannah admins if it possible to install guix on those
> machines and add pre-receive/update hook?  If not, we will look for
> other options.

I’m busy these days so I’d rather not commit to starting a discussion on
this, but I’d suggest testing waters on #savannah on IRC.

Thanks,
Ludo’.

Re: A real-life test of long-term reproducibility

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Konrad Hinsen  skribis:
>
>>   $ guix time-machine --commit=48aa30ce73d45dc5f126f42f01e65f1be4a9b578‘> -- 
>> environment guix
>>   Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>>   Authenticating channel 'guix', commits 9edb3f6 to 48aa30c (6 new 
>> commits)...
>>   guix time-machine: error: commit
>>   48aa30ce73d45dc5f126f42f01e65f1be4a9b578 is not a descendant of
>>   introductory commit 9edb3f66fd807b096b48283debdcddccfea34bad
>
> Here you would need ‘--allow-downgrades’.

Sorry I replied to quickly; it should have been
‘--disable-authentication’.

Why?  Because here you’re trying to travel to a commit that’s not part
of the “authenticated history”—that is, it’s not a descendant of the
“introductory commit”, which is the first commit in history starting
from which the “authentication invariant” holds.

Hopefully this is clearer; maybe?  :-)

Cheers,
Ludo’.

Re: [PATCH v2] doc: Update contribution guidelines on patches, etc.

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> On 02-09-2022 15:12, Ludovic Courtès wrote:
>> Hello,
>>
>> Liliana Marie Prikler  skribis:
>>
>>> * doc/contributing.texi ("Snippets versus Phases"): Replaced with...
>>> ("Modifying Sources"): ... this.  List more use cases and some principles.
>> It’s been a while; this looks like a nice improvement to me.  It’s a bit
>> long, but perhaps that’s avoidable.  If there are no objections, I’d say
>> go for it.
>
> Have you seen my v2?

I guess I haven’t (I was catching up with email as I returned from
vacation).

Hmm should you send the latest agreed-upon version to
guix-patc...@gnu.org for clarity?

TIA,
Ludo’.

Re: A real-life test of long-term reproducibility

[zimoun]

Hi Konrad,

On lun., 05 sept. 2022 at 09:49, Konrad Hinsen  
wrote:
> Hi Ludo and Simon,
>
>> On Fri, 02 Sep 2022 at 15:17, Ludovic Courtès  wrote:
>>
>>> Here you would need ‘--allow-downgrades’.
>>
>> Maybe time-machine could advertise of this option?
>
> And explain what it's about. I don't consider myself an absolute
> beginner with Guix, but I don't understand what's going on here!

Well, it is documented. ;-) The entry of ’time-machine’ [1] is the
manual says:

The general syntax is:

guix time-machine options… -- command arg…

where command and arg… are passed unmodified to the guix command
of the specified revision. The options that define this revision
are the same as for guix pull (see Invoking guix pull):

then the entry of ’guix pull’ [2] explains the option:

--allow-downgrades

  Allow pulling older or unrelated revisions of channels than
  those currently in use.

  By default, guix pull protects against so-called “downgrade
  attacks” whereby the Git repository of a channel would be
  reset to an earlier or unrelated revision of itself,
  potentially leading you to install older, known-vulnerable
  versions of software packages.

Last, a blog post [3] provides some details.

I agree it could be improved.  Any suggestion? :-)


1: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-time_002dmachine
2: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-pull
3: https://guix.gnu.org/en/blog/2020/securing-updates/


> OK, now I do a well... but should users need to understand the
> developers' git workflow?

I agree.


> Ultimately, the issue here is that guix works on the implementation
> level of git commit references, whereas the development process uses an
> abstraction layer on top of it. Maybe "guix pull" and "guix
> time-machine" should acquire some built-in intelligence when given a tag
> instead of a hash? Issue a warning when an inappropriate tag is given,
> and suggest a correction?

Well, the tags are there and usable.  But, Guix relies on guile-git and
uses string->oid; which supporting hash-commit and not string-tag.
That’s a technical limitation which could be easily improved, I guess.

Even, we could imagine local Git-tags using “guix git tag” and reuse
them via the time-machine.  Some code are around for “guix git log” (see
branch wip-guix-log [4]).

(However, although convenient, Git-tag is extrinsic (mutable) and thus it
is not suitable for long-term, where intrinsic (immutable) seems
preferred.)

4: https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-guix-log


Cheers,
simon

Re: A real-life test of long-term reproducibility

[Konrad Hinsen]

Hi Ludo and Simon,

> On Fri, 02 Sep 2022 at 15:17, Ludovic Courtès  wrote:
>
>> Here you would need ‘--allow-downgrades’.
>
> Maybe time-machine could advertise of this option?

And explain what it's about. I don't consider myself an absolute
beginner with Guix, but I don't understand what's going on here!

> Well aside, it can be indeed confusing that the version-1.x branch does
> not match the tag v1.x; I understand why.

OK, now I do a well... but should users need to understand the
developers' git workflow?

Ultimately, the issue here is that guix works on the implementation
level of git commit references, whereas the development process uses an
abstraction layer on top of it. Maybe "guix pull" and "guix
time-machine" should acquire some built-in intelligence when given a tag
instead of a hash? Issue a warning when an inappropriate tag is given,
and suggest a correction?

Cheers,
  Konrad.

Re: [POSTMORTEM] Subkey is not authorized by .guix-authorizations

[Andrew Tropin]

On 2022-09-02 15:23, Ludovic Courtès wrote:

> Hello!
>
> I’m late to the party, but thanks a lot for sending this analysis!
>
> Andrew Tropin  skribis:
>
>> * What could be done better?
>> - guix pull could be done from local checkout, before pushing.
>
> Setting a pre-push hook that invokes ‘guix git authenticate’, as
> recommended in the manual (info "(guix) Commit Access"), should be
> enough: ‘git push’ would just fail in that situation.

For some reason I thought it does git verify-commit, which I used
manually to check if commit is signed, but it does make authenticate,
which of course works the other way.  Missed it, my bad.

I have elaborated on this topic a little more in the manual.
From e510ea1595c54bec788485f0638967d457afaf3d Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Mon, 5 Sep 2022 09:46:23 +0300
Subject: [PATCH] doc: Add more info about commits signature local
 verification.

* doc/contributing.texi (Commit Access): Add more info about commits signature
local verification.
---
 doc/contributing.texi | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index b1d236c011..17a54f94cc 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -1627,14 +1627,23 @@ git config commit.gpgsign true
 git config user.signingkey CABBA6EA1DC0FF33
 @end example
 
-You can prevent yourself from accidentally pushing unsigned commits to
-Savannah by using the pre-push Git hook located at
-@file{etc/git/pre-push}:
+To check that commits are signed with correct key, use:
+
+@example
+make authenticate
+@end example
+
+You can prevent yourself from accidentally pushing unsigned or signed
+with the wrong key commits to Savannah by using the pre-push Git hook
+located at @file{etc/git/pre-push}:
 
 @example
 cp etc/git/pre-push .git/hooks/pre-push
 @end example
 
+It additionally calls @code{make check-channel-news} to be sure
+@file{news.scm} file is correct.
+
 @subsection Commit Policy
 
 If you get commit access, please make sure to follow
-- 
2.37.2


>> - Accept subkey on guix pull if master key is in .guix-authorizations.
>
> Reported at .
>
>> - Add pre-push hook, which checks authorization on Savannah.
>
> That one is difficult: Guix is not installed on those machines.
>
> Another option would be to push to a different machine, one that we
> control, and make Savannah a mirror of that one.

It can work, but looks fragile.

>
> Thoughts?

Let's ask savannah admins if it possible to install guix on those
machines and add pre-receive/update hook?  If not, we will look for
other options.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature