$EDITOR and “guix edit”

[Simon Tournier]

Hi,

The command “guix edit” returns “+N path/to/file” that is then passed to
$EDITOR.  Therefore $EDITOR needs the command line:

$ $EDITOR +N /path/to/file

Well, that is accepted by many $EDITOR, to my knowledge.  At least,
Emacs, Vi or less are fine with it.

However, some other $EDITOR does not.  I have in mind “kate” or
“VSCode“,

$ kate -l N path/to/file
$ code --goto path/to/file:N

This had been raised in #44272 [1].  The current fix is to wrap $EDITOR
and then make the current correct call.

The question is:

  do we tweak “guix edit” for behaving differently depending on $EDITOR?

or

  do we provide some wrappers for the issues that already popped up?

WDYT?

Cheers,
simon

1: https://issues.guix.gnu.org/44272

Re: Better support remote deployment

[Ricardo Wurmus]

Hi Felix,

> On Wed, Nov 01 2023, Ricardo Wurmus wrote:
>
>> What do you think about changing “guix package” and/or “guix copy” to
>> better support deployment of remote profiles?
>
> As someone who uses 'guix deploy' all the time. I believe remote
> administration is one of our core strengths and selling points. Other
> remote administration tools like Ansible or Puppet are probably no
> longer needed when using GNU Guix System.
>
> I currently have only x86_64 equipment deployed, so there is no
> cross-building happening in my setup. Is that the main purpose of your
> proposal?

No, both machines are x86_64.  I think “guix deploy” could benefit from
a way to not only deploy Guix System (which makes the tool primarily
useful for managing hosts, not applications) but also profiles and
containers.

-- 
Ricardo

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Donnerstag, dem 02.11.2023 um 10:43 +0100 schrieb Simon Tournier:
> Hi,
> 
> The command “guix edit” returns “+N path/to/file” that is then passed
> to $EDITOR.  Therefore $EDITOR needs the command line:
> 
>     $ $EDITOR +N /path/to/file
> 
> Well, that is accepted by many $EDITOR, to my knowledge.  At least,
> Emacs, Vi or less are fine with it.
This appears to be a somewhat archaic convention.  Since less used +N,
many other tools inherited it from it; POSIX requires -p for more since
2008 instead (ironically, it laments the incompatibility with vi and
ex, which use -c).

> However, some other $EDITOR does not.  I have in mind “kate” or
> “VSCode“,
> 
>     $ kate -l N path/to/file
>     $ code --goto path/to/file:N
> 
> This had been raised in #44272 [1].  The current fix is to wrap
> $EDITOR and then make the current correct call.
> 
> The question is:
> 
>   do we tweak “guix edit” for behaving differently depending on
> $EDITOR?
> 
> or
> 
>   do we provide some wrappers for the issues that already popped up?
I think we should at least document our behaviour, so that there's
"less surprise" (at the very least, we can point surprised folk towards
the manual/cookbook then).  Going forward, we might want to call upon
some standards committee to finally have +LINE:COL or similar
standardized behaviour for $EDITOR and $VISUAL and then use that.

Cheers

Re: Proposal: Differentiate products more clearly (Cycle 01)

[pinoaffe]

Hello!

Luis Felipe  writes:
> El 12/10/23 a las 20:30, pinoaffe escribió:
>> I think it's important to clarify what Guix is (and I really like your
>> mockups/some of the concrete proposed changes), but I don't quite agree
>> with the idea behind your proposal.
>>
>> I think it would be more useful to produce and maintain a clear list of
>> what guix can do than to bifurcate guix into a package manager and an
>> operating system, especially since many of the aspects of Guix don't
>> cleanly fall in either of those two categories.
>
> In this proposal, that clear list of what Guix can do would be the
> feature list, linked early in the home page, right after Guix's
> definition. The features list already exists in the manual, but I
> think it could provide more information.
>
> Regarding the separation of both products, as I see it, it already
> exists, it is just that it is not that clear. There are separate
> downloads for both products and the manual, for example, has specific
> sections for the package manager and the operating system.

It kind-of exists, but it kind-of doesn't either - guix and guix system
are developed as one joint project, you interact with both through a
common interface, there is no clear division between what is part of
what, etc
>
> Now, I do agree that "package manager" and "operating system" don't
> quite make potential users picture the whole range of features
> provided by Guix... Would you still disagree with the differentiation
> of both products if the definition of Guix changed from "package
> manager" to, say, "a tool for reproducible deployment at every level
> of scale", as Ricardo suggest
> (https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00142.html)?
> Or something along those lines?

I personally really like that definition, though "guix system" could
also fall under that definition, so that may be an issue or a benefit
depending on your point of view :)

[omitted]

> I may be misreading you, but I think your points are in line with the
> idea of changing the definition of Guix to better communicate its many
> other features, instead of simply calling it a "package manager".

My points are very much in line with that, my opposition is solely with
categorizing Guix/Guix System into a package manager and an operating
system

> If I read you correctly, I think having an additional presentation and
> definition for the Guix System (the OS), as suggested in this
> proposal, would not conflict with a possible change to Guix's
> definition.

Yeah, I really support that

[omitted]

Kind regards,
pinoaffe

August/November update on qa.guix.gnu.org and related things

[Christopher Baines]

Hey,

The last update I sent out was back in July [1].

1: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00144.html

There have been quite a few changes over the last few months, here's a
summary of the changes:

 - QA now stores when it's submitted builds for a issue/branch and
   cancels them when they're no longer needed

 - The README is published at https://qa.guix.gnu.org/README

 - The output when applying patches is stored and displayed if there was
   a failure

 - There's a review feature for marking patches as looking good

 - There are more issue statuses and support filtering by status

 - Merged issues are now handled

 - Patches can be applied to non-master branch

 - The latest patch series are processed, rather than the latest issues

 - There's a page specifically about reproducible builds
   (qa.guix.gnu.org/reproducible-builds)


I've also been doing little bit of work towards speeding up the data
service processing revisions. I've disabled computing the system test
derivations on data.qa.guix.gnu.org as that takes a significant amount
of time, and they aren't being used yet.

The formatting linter takes quite a bit of time, and I've got an open
patch to speed it up:

  https://issues.guix.gnu.org/66796

The performance of computing cross derivations also seems like it could
be improved, I've sent some details here:

  https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00257.html

# Next steps

I'm still planning to stop hosting both data.guix.gnu.org and
data.qa.guix.gnu.org at the end of the year, which is only a few weeks
away now. The qa-frontpage which runs qa.guix.gnu.org is dependent on
data.qa.guix.gnu.org. There's been some discussion of potentially moving
some or all of this to hosting organised through the project/Guix
Europe, but I'm not sure anything has happened on this yet.

I've added a few TODO's to the list in the README off the back of
discussion at the Reproducible Builds summit.

In my mind, while there's still lots to do in the qa-frontpage,
addressing problems in the data service is probably still the most
important thing to do. There's still some reliability issues to
investigate further as well as improving the performance of processing
revisions. If the data service can be sped up, QA will be able to give
feedback faster, and it'll scale to handle more patches.

I'd also really like to see some testing of the patch review feature in
QA, since I think trying to get people without commit access reviewing
patches will really help speed up getting things reviewed and merged.

Let me know if you have any comments or questions!

Thanks,

Chris


signature.asc
Description: PGP signature

Re: August/November update on qa.guix.gnu.org and related things

[Suhail]

Christopher Baines  writes:

>  - The README is published at https://qa.guix.gnu.org/README

The README seems more focused on task planning and TODO items than
explaining how to use the qa.guix.gnu.org website. Could you please
provide a reference for the latter?

Specifically, I submitted a patch some while ago:
. Its QA status is marked as
unknown with a few items highlighted in red. While the UI helps draw
attention to those items, it's not clear (to me) how to remedy them and
who is responsible for doing what. I.e., what are the next steps? I
would like to get that patch reviewed and merged in some way, but I
don't know what, if anything, I can do to help with the matter.

> I'd also really like to see some testing of the patch review feature
> in QA, since I think trying to get people without commit access
> reviewing patches will really help speed up getting things reviewed
> and merged.

Is there a document that outlines how to get started and/or
pre-requisites that one must have before reviewing certain aspects?

-- 
Suhail

This email is not an offer capable of acceptance, does not evidence an
intention to enter into an agreement, has no operative effect until a
definitive agreement is signed in writing by both parties, and that no
party should act in reliance on the email or any representations of the
sender until a definitive agreement is signed in writing by both
parties.

This email may contain information that is privileged, confidential
and/or exempt from disclosure.  No waiver whatsoever is intended by
sending this e-mail which is intended only for the named recipient(s).
Unauthorized use, dissemination or copying is prohibited.  If you
receive this email in error, please notify the sender and destroy all
copies of this email.

Re: RFI response: Strengthening the Free Software Supply Chain via Guix and GNUnet

[Maxim Cournoyer]

Hi Sergio,

Sergio Pastor Pérez  writes:

> Hi, Maxim.
>
> This has been an interesting read. I would like to encourage you to keep
> us updated.
>
> Thanks for sharing!

My pleasure!  I will keep you updated, if anything happens from it.

-- 
Thanks,
Maxim

Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19

[Luis Felipe]

Hi,

El 26/10/23 a las 14:03, Luis Felipe escribió:

El 25/10/23 a las 21:17, Julien Lepiller escribió:
The print service I usually use has a lot of options for flyers, 
{10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think 
15*20 would be best.


Visit cards would be 3.5*7.5, 5.5*8.5 or 5*9 cm
Thanks, Julien, I'll hopefully have something ready for next week. 
I'll let you all know.


Here's a visit card in the same style of the kakemono:

https://luis-felipe.gitlab.io/downloads/pdf/gnu-guix-visit-card-A01-EN-90x50mm.pdf

The source is in https://codeberg.org/luis-felipe/guix-graphics/ 
(promotional/cards).


Please note that I haven't printed a sample yet to see if it works 
alright. So, if you like it and can't wait to print it, I'd recommend 
printing a sample first.


Also, this card is in English. If you'd prefer a French version, please 
help me with the translation, and I'll create a copy :)


Finally, I'm not feeling motivated to design a flyer. Compared to cards, 
I think most people throw flyers away, so it seems kinda wasteful to me.


Anyways, let me know what you think.


Cheers,




OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: packaging Typst

[Alexis Simon]

Thank you very much Steve for those detailed explanations! This is going 
to be super helpful as a starter.

Alexis

On 02/11/2023 13:21, Steve George wrote:

Hi Alexis,

I've been doing some Rust packaging recently, so maybe this will help you to 
get started. Here's how I would approach it.

Explore the software

The first thing I did was explore whether Typst builds in a current Guix 
environment. If we don't have the right version of Rust, for example, there's 
little point continuing:

- clone it into an appropriate place
- start a shell:
 $ guix shell --container --network rust rust-cargo coreutils openssl 
nss-certs gcc-toolchain

We need 'openssl' and 'nss-certs' so that cargo will work.

- build it:
 [env]$ env CC=gcc cargo build

Kept failing on ring v0.17.5 which is looking for 'cc'. It builds with 296 
crates, so we might have our hands full here! Eventually outputs a 
/target/debug/typst command which seems to work.


Import using Guix import
=
Normally, we'd be able to use the `crates` importer. But, the Typst crates are 
just place-holders with no details.

AFAIK the importer only works with crates-io, we can't feed it Cargo.toml file 
directly. We'll need to manually create a package and check for any 
dependencies.

Manually create a top-level package

To manually create the package we have to go through the projects Cargo.toml.

- create an intial typst.scm file in some project directory.
- create a minimal typst package by looking in Cargo.lock at 'typst'
- for each dependency look at what the Cargo.lock used to build it - check 
whether we have it in Guix
- in some cases we will have the crate, but not the right version

Import the dependencies
=
The first crate that I found which we don't have in the Guix archive is 
'comemo' [0]. We can import this with:

 $ guix shell --development guix --container --nesting --network nss-certs
 [env]$ guix import crate --recursive comemo@0.3.0 > comemo-import.scm

Move these package definitions into your main `typst.scm` file. Check them to 
add any missing development dependencies.

The first one in the dependency stack is `rust-comemo-0.3` which we reference 
at the bottom of the file. We try and build it as the importer has pulled it in:

 $ guix shell --development guix --container --nesting
 [env]$ guix build --load-path=./ --file=typst.scm
 

The next one `rust-comemo-macros` which has been set to `skip-build: #t`, we'll 
try building it that way initially:

 - add rust-comemo-macros-0.3 to the bottom of the typst.scm file
 - comment out the rust-comemo-0.3 line
 - try and build with: guix build --load-path=./ --file=typst.scm

 - If it builds successfully, change the `skip-build: #t` part of the 
definition to be #f.
 - error[E0433]: failed to resolve: use of undeclared crate or module 
`comemo`
 - tried adding comemo as a dependency which didn't work
 - set it to #:tests? #f - for now

There's some more things that have to be done to 'contribute' these packages, 
but for now I would move onto the next dependency. And that's all there is to 
this part - finding the dependencies and importing them.

Building a dependent package that's not a crate
===
The cargo-build-system expects to build everything from Crates AFAIK. I believe 
it will take some messing around with the phases to add the typst-lib which 
seems to be a dependency. It looks like librsvg (in gnome.scm) does a lot of 
messing with phases, and greetd (in admin.scm) does some as well - these might 
be good examples to look at.

Hopefully this is enough to get you started!

Steve

[0] https://crates.io/crates/comemo

Re: August/November update on qa.guix.gnu.org and related things

[Christopher Baines]

Suhail  writes:

> Christopher Baines  writes:
>
>>  - The README is published at https://qa.guix.gnu.org/README
>
> The README seems more focused on task planning and TODO items than
> explaining how to use the qa.guix.gnu.org website. Could you please
> provide a reference for the latter?

There isn't much documentation for QA, mostly because I want to see it
improve so that you don't need documentation to use it.

> Specifically, I submitted a patch some while ago:
> . Its QA status is marked as
> unknown with a few items highlighted in red. While the UI helps draw
> attention to those items, it's not clear (to me) how to remedy them and
> who is responsible for doing what. I.e., what are the next steps? I
> would like to get that patch reviewed and merged in some way, but I
> don't know what, if anything, I can do to help with the matter.

I had a look at the QA page for #66644 and yeah, the red highlighted
bits where builds which hadn't happened yet.

I think it's fair to say that these shouldn't be styled the same as
failed builds, so I've changed the styling now. I've also added a new
issue status for when QA is waiting on builds to happen to provide more
information.

So yeah, QA isn't currently pointing out anything for you to do on this
issue.

>> I'd also really like to see some testing of the patch review feature
>> in QA, since I think trying to get people without commit access
>> reviewing patches will really help speed up getting things reviewed
>> and merged.
>
> Is there a document that outlines how to get started and/or
> pre-requisites that one must have before reviewing certain aspects?

On the page for each issue on qa.guix.gnu.org, there's a list of common
things to check. That form gives a way to record a review when you think
the patches look good to merge.

There's also some content in the manual that might be useful when
reviewing patches:

  https://guix.gnu.org/en/manual/devel/en/html_node/Packaging-Guidelines.html
  https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html

But there's no pre-requisites to reviewing Guix patches, so the best way
to learn is to start looking to review things.


signature.asc
Description: PGP signature

Re: August/November update on qa.guix.gnu.org and related things

[Suhail]

"Christopher Baines"  writes:

> There isn't much documentation for QA

Understood.

Is the preferred place to ask questions regd the QA service this mailing
list?

> I think it's fair to say that these shouldn't be styled the same as
> failed builds, so I've changed the styling now.

The neutral blue works better; thank you. On a related note, the
specific build status on data.qa.guix.gnu.org for the "now blue" entries
is "Scheduled". Why does that get presented as "Unknown" in QA? IMO,
either "Scheduled" or "Pending" (in case it's important to maintain a
distinction from the build status of individual jobs as on
data.qa.guix.gnu.org) would be clearer than "Unknown".

> I've also added a new issue status for when QA is waiting on builds to
> happen to provide more information.

This being "Investigate"? Out of curiosity, and in a similar vein as
above, why not simply "Scheduled" or "Pending"? Or is it that it has had
"Scheduled" build jobs for far too long and thus requires someone else
with more privileged access (than myself) to investigate the cause?

I.e., Investigate is a verb and thus makes me wonder what the object is
(what needs to be investigated) and who the subject is (by whom)?
Shouldn't the QA issue status be an adjective instead?

> So yeah, QA isn't currently pointing out anything for you to do on
> this issue.

Okay, thank you for the clarification.

> There's also some content in the manual that might be useful when
> reviewing patches:
>
>   https://guix.gnu.org/en/manual/devel/en/html_node/Packaging-Guidelines.html
>   https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html

Perhaps linking to these from the "Mark patches as reviewed" section on
QA would be helpful?

> But there's no pre-requisites to reviewing Guix patches, so the best
> way to learn is to start looking to review things.

I imagine some of the "common things to check" will get automated in the
near future (e.g. whether or not the changes are adding to the lint
warnings), whereas some others will stay manual (e.g. are things "well
written"). Personally, for such subjective measures (i.e., the latter) I
find having some examples of "what good looks like" readily available
quite helpful. In case the intent is to make it easier for newcomers to
the project (i.e., those who've not yet internalized this knowledge) to
contribute, providing such prototypical examples by linking to commits,
descriptions etc in the existing source tree would help.

-- 
Suhail

This email is not an offer capable of acceptance, does not evidence an
intention to enter into an agreement, has no operative effect until a
definitive agreement is signed in writing by both parties, and that no
party should act in reliance on the email or any representations of the
sender until a definitive agreement is signed in writing by both
parties.

This email may contain information that is privileged, confidential
and/or exempt from disclosure.  No waiver whatsoever is intended by
sending this e-mail which is intended only for the named recipient(s).
Unauthorized use, dissemination or copying is prohibited.  If you
receive this email in error, please notify the sender and destroy all
copies of this email.