Re: Updating mumi on berlin

[zimoun]

Hi,

On Fri, 22 Apr 2022 at 11:08, Arun Isaac  wrote:

> I would like to update the mumi running on berlin to the latest
> version.

The update of Mumi adds a GraphQL thing to issues.guix.gnu.org, IIUC.
Quoting Ricardo from #guix-hpc [1].

--8<---cut here---start->8---
 mumi’s API is very limited  [20:53]
 but Arun has recently added a graphql thing
 for example, you can write this query to a file “req”:  [21:01]
 {"query": "query { issues(search: \"tag:easy\") { title tags open
 submitter { name address } } }" }
 and then do: curl --data-binary @req
 https://issues.guix.gnu.org/graphql | jq  [21:02]
 that’ll return a JSON response formatted as the query prescribes,
 containing all issues that match the given search string “tag:easy”.
--8<---cut here---end--->8---

Therefore, such update of Mumi looks very promising. :-)

Thanks Arun for working on that.


>  I spoke to Ricardo off-list and he tells me that there are
> issues running `guix system reconfigure' on the server. Are there any
> updates on that?

What are the blockers (issues) for updating the server (Berlin and/or
Bayfront)?


Cheers,
simon


1: 

Re: Hardened toolchain

[Katherine Cox-Buday]

raingloom  writes:

> People shouldn't have to take extra steps and burn extra CPU cycles
> for security.

To be clear, I don't have a strong opinion on this, but I wanted to give an 
alternative viewpoint: people shouldn't have to take extra steps and burn extra 
CPU cycles for performance.

Everyone has different threat models and needs. A lot of computers have CPU 
speculative execution attack mitigation disabled because those types of attacks 
will never affect those computers, and it reduces the performance of the CPU a 
lot.

I suggest we pick our default with care, and if possible with data about what 
most users would like.

-- 
Katherine

Re: go importer documentation/exceptions

[Katherine Cox-Buday]

I agree with the gist of what you're saying, but I first need to establish that 
Guix is actually not doing anything wrong before we can talk about how to make 
things better.

> On Saturday, April 23rd, 2022 at 9:51 AM, jgart  wrote:
>
> The Guix docs do not explicitly state that a uri like
> https://git.sr.ht/~emersion/chathistorysync@0.1.0 is not allowed:
>
> https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-import.html
>
> This leaves footguns for new users trying to use the go importer for
> the first time since a new user might want to just copy paste the go
> package's url into the terminal.

I'll explain more below, but a "package's URL" is a misnomer.

> Should we be explicit in the docs about what uri syntax is and is not
> allowed

Here is the output from `guix import go --help`:

Usage: guix import go PACKAGE-PATH[@VERSION] Import and convert the Go
module for PACKAGE-PATH. Optionally, a version can be specified after
the arobas (@) character.

And here is the definition of a package path from
https://go.dev/ref/mod#glos-package-path:

#+begin_quote

  package path: The path that uniquely identifies a package. A package
  path is a module path joined with a subdirectory within the module.
  For example "golang.org/x/net/html" is the package path for the
  package in the module "golang.org/x/net" in the "html" subdirectory.
  Synonym of import path.
  
#+end_quote

So I disagree that Guix doesn't explicitly state that a URI like the one you've 
given is not allowed, because it doesn't say to pass in a URI, it says to pass 
in a PACKAGE-PATH, which has a very specific meaning in Go.

Package paths happen to look like URLs, but they're not. They're URIs with 
special properties that go far beyond where to fetch code. As an example, you 
could fetch the package foo.bar/baz from 
https://my-repository.com/katco/my-lib. There is an algorithm[1] for resolving 
a module path to a SCS to fetch from, and Guix re-implements[2] this.

Now, having said all that, I can see how someone familiar with Guix, but not 
Go, would make this mistake. And since we're here to help humans, but not 
pedants, and not computers, we should keep that in mind when thinking about 
designing the tool.

In my opinion, we should assume the person importing Go packages knows what a 
Go package is, and therefore knows what a package path is. If they get it wrong 
and try and use a URL, that's when we should surface the difference between the 
two, and suggest they try again without any URL syntax.

WDYT?

[1] - https://go.dev/doc/modules/managing-source#tools
[2] - https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/go.scm#n474

-- 
Katherine