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

[Maxime Devos]

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? It has a somewhat different structure (the 'Problem 
-> solution’ structure proposed by Julien), Liliana's patch is more 
‘Solution -> relevant problems’.


Liliana's patch works too, but I would like to make sure you haven't 
overlooked my patch.


If Liliana's patch is preferred, we can go with that one, if my patch is 
preserved, I could look at addressing the comments on the wording for a v3.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: guix lint should support overrides

[Development of GNU Guix and the GNU System distribution.]

Hi all,

On Tue, Aug 23, 2022 at 3:23 PM Vagrant Cascadian  wrote:
>
> Debian's correlary, lintian, has a mechanism to do exactly this, where
> you list the various things that aren't appropriate, and can even
> comment on why, in a way that lintian basically hides the issue from
> further attention.

Overrides would also offer a benefit to 'guix lint' maintainers! A
large proportion of overrides relative to the total incidence suggests
the heuristics should be tuned to reduce nuisance, if possible.

Kind regards
Felix Lechner

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Simon Streit]

Hello Théo,

Théo Maxime Tyburn  writes:
> It is here https://github.com/theottm/emacs-guix-clone. There is only
> one branch.
>
>> if you succeed in building the new merged branch please notify me and
>> I'll try to upstream it to
>> https://git.savannah.gnu.org/cgit/guix/emacs-guix.git
>
> I just sucessfuly built it. You can probably use

I could successfully build your branch.  Unfortunately with geiser's
recent upgrade from 0.23.2 to 0.26 emacs-geiser broke on my side.

Geiser has since [1] removed all references to company.  The end result
is, that emacs-geiser will fail to load a REPL while it tries to
initiate geiser-company.

Here is my modification that fixes the REPL again: [2].

It'd be nice to see this pushed too and merge all the branches that now
exist with emacs-guix.


Kind Regards
Simon 


[1] 
https://gitlab.com/emacs-geiser/geiser/-/commit/18faa0ba32c9ce751c16960b2a39b3880b523272
[2] https://git.steel-is-real.com/emacs-guix-clone/log/?h=simons-hack

Re: [EXT] cloud-init?

[Thompson, David]

Hi Simon,

On Fri, Aug 26, 2022 at 4:16 AM Simon Josefsson via Development of GNU
Guix and the GNU System distribution.  wrote:
>
> I would like to deploy Guix VM's and in many VM hosting environments,
> having cloud-init on the Guix VM image would be useful for configuration
> of network interfaces etc.  I tried searching the mailing list archives
> and bug database, but could not find anything except that the
> cloud-utils package has been added to Guix.
>
> The philosophy of cloud-init and Guix system configuration is probably
> at odds, but basic support for booting and starting sshd and printing
> the SSH fingerprint, and possibly some DHCP/network config is probably
> not too difficult to achieve.  A 'cloud-init' package in Guix could do
> as much as is possible to do, or at least document the gap between
> philosophies.
>
> I haven't looked into packaging cloud-init, but first wanted to ask if
> anyone is aware of work in this area?  Are people interested in this?

I can only cite my experiences doing devops on AWS for the past 5
years, but I personally avoid relying on cloud-init on EC2 and try to
catch when other developers use it to do something because there's
always a better way.  That better way is almost always to add a
one-shot systemd service (these are not Guix System servers) to the VM
image that starts on boot.  What are some situations in which
cloud-init is unavoidable?  I wouldn't think cloud-init would need to
start sshd since the init system would automatically do that.

None of this is to say that I wouldn't be in favor of having
cloud-init support.  I'm just trying to understand if it's a necessity
in a certain context or if it would be for the purpose of providing a
familiar tool to help people who are used to using it with other
distros.

- Dave

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

[zimoun]

Hi Ludo,

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?


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

--8<---cut here---start->8---
$ git log --graph --format="%h %s %d" v1.0.0^..origin/version-1.0.0
* 48aa30ce73 build: Add 'doc/build.scm' to build on-line copies of the manual.  
(origin/version-1.0.0)
* adf577dcc4 doc: Update htmlxref.cnf. 
* 1a9fc8e228 doc: Warn about missing entries in htmlxref.cnf. 
* 2921b6a611 doc: Adjust cross-references for GNU triplets. 
* 3aa11dfbed doc: Provide the actual URL to the VM image. 
* 542e7fb57f doc: Add note about . 
* 3a3e9f2bb5 guix-install.sh: Update URL. 
* 9c941364bf vm: Build ISOs and VM images in a UTF-8 environment. 
* 17acc215bf gnu: guix: Update to 326dcbf. 
* 326dcbf1b3 gnu: guix: Update to 1.0.0. 
* 6298c3ffd9 Update NEWS.  (tag: v1.0.0)
--8<---cut here---end--->8---

Does it make sense to document it?  And does it make sense to merge to
master right after 326dcbf1b3?  And not after some commits:

--8<---cut here---start->8---
$ for i in $(seq 0 3); do \
   git log --graph --format="%h %s %d" v1.$i.0^..origin/version-1.$i.0 \
   | wc -l ;done   
11
6
warning: refname 'v1.2.0' is ambiguous.
10
7
--8<---cut here---end--->8---



Cheers,
simon

Re: okay to merge rekados-rust-queue branch?

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> I have a small branch with minor Rust package upgrades.  I successfully
> built icecat on that branch and the failing rust-* packages seen in the
> latest builds at https://ci.guix.gnu.org/jobset/rekados-rust-queue seem
> to be broken on the master branch as well.
>
> Would it be okay to merge this branch?
>
> I’m asking because the cargo-build-system makes it difficult to see how
> upgrades affect other packages, so building things on ci.guix.gnu.org
> and locally is the only way I can verify that the changes aren’t
> catastrophic.
>
> I’d like to merge this soon while the successful builds are fresh.

I guess that as long as there are no big regressions on ci.guix compared
to the starting point in ‘master’, that should be fine.

Normally we should be able to compare the status of both branches with:

  
https://data.guix.gnu.org/compare?base_commit=b594c7354ce1daedecb3310b55817b69e90adbe9_commit=9ea5ebb9b1f393abba81e90d33ccc0da97f47032=en_US.UTF-8

However, it seems that data.guix hasn’t processed the new branch.

Ludo’.

Re: 100k commits!

[Ludovic Courtès]

Marius Bakke  skribis:

> Congratulations for making it this far, and a big thank you to the 700+
> contributors who made this possible.  You are truly awesome.

+1, well done!

Ludo’.

Re: Idea: Function composition to declare operating-system

[Ludovic Courtès]

Hi Théo,

Théo Maxime Tyburn  skribis:

> I experimented on a functional approach to the operating
> system declaration. My goal was to be able to pass an operating-system
> instance to a composition of functions, modifying it one after another
> and returning the desired operating-system object. I find this approach
> more convenient because it allows for better segmentation of the system
> features. I achieved to make it work for the system declaration I
> usually use and I’d like to share it with you.

Neat!  In some cases, having “transformation” functions is clearer
indeed.  There’s a couple of them in the code, such as
‘virtualized-operating-system’, that make it easy to adapt an OS config
to a specific use case.

Thanks for sharing!

Ludo’.

Re: cloud-init?

[Ludovic Courtès]

Hello!

David Dashyan  skribis:

> I've been interested in adding cloud-init support for a while already.
> It would make Guix much easier to use in a cloud setting.  I did ask
> people weather anyone is interested in it couple of times in #guix and
> also mentioned it on the mailing list couple of times.  People didn't
> seem to express much interest but once they have it they'll like it a
> lot I think :) It is common practice to spawn other distro type and turn
> it into Guix or install Guix on it and do "guix system init" on mounted
> volume and then swap them.  Not to mention the fact that every now and
> then there is a new question on running Guix on some other vendor.  Guix
> deploy was made exactly for that in mind, wasn't it?

Yes!  It may be that the intersection of cloud/devops people and Guix
people is still too small (for one, I know ‘guix deploy’ but I’m just
discovering ‘cloud-init’), but work in this area would be very welcome,
precisely so Guix can become more useful in this area.  It’s a
chicken-and-egg problem that you can help address.  :-)

Would it be an option to add a ‘guix deploy’ backend for cloud-init?
There are currently two backends under gnu/machine/*.scm.  This would
add a third one that uses cloud-init to perform deployment.

Does that make sense?

If there’s interest in it, I’m happy to provide guidance for the code.

Thanks,
Ludo’.

Re: guix lint should support overrides

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> IIRC, there was some package where I proposed to modify the
> description a little to be more informative and fit better in Guix,
> but then the gnu-description proposed to use the upstream
> description. Consequently, it was decided to use the original, IMO
> worse, description.
>
> Unfortunately I cannot find the relevant e-mails anymore.
>
> This was a true positive, not a false positive, but I think it would
> have been useful to silence the linter there anyway.
>
> At least for these kind of cases, I would go for a package property
> (properties '((silence-linters gnu-description))).

Yes, properties are the way to go IMO.

Note that there’s already one or two checker-specific properties, such
as ‘lint-hidden-cve’.  We could add more of that if needed.

A higher-level ‘lint-silenced-checkers’ property like you propose (I
think that’s a better name) would also be welcome.

It’s incidentally a good programming task to get started; who’s in?  :-)

Ludo’.

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

[Ludovic Courtès]

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.

> - 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.

Thoughts?

Ludo’.

Re: Failure with “guix copy“

[Ludovic Courtès]

Hi,

zimoun  skribis:

> $ guix copy --from=desktop hledger
> The following derivations will be built:
>   /gnu/store/gz1qzalbg3dzwvfvj81f13n8pd47rzw2-hledger-1.21.drv
>   /gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv
>   /gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv
>   /gnu/store/vhxlqj1d5pll79vfdi06wl77k5mx45vb-ghc-hledger-lib-1.21.drv
> process 307420 acquired build slot '/var/guix/offload/x.x.x.x:22/0'
> normalized load on machine 'x.x.x.x' is 0.01
> building 
> /gnu/store/vhxlqj1d5pll79vfdi06wl77k5mx45vb-ghc-hledger-lib-1.21.drv...
> building 
> /gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv...
>
> Starting download of 
> /gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal
> From https://hackage.haskell.org/package/lucid-2.9.12.1/revision/1.cabal...
> downloading from 
> https://hackage.haskell.org/package/lucid-2.9.12.1/revision/1.cabal ...
>
> sha256 hash mismatch for 
> /gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal:
>   expected hash: 1f0whk5ncanxfjjanrf6rqyncig2xgc5mh2j0sqy3nrlyjr9aqq9
>   actual hash:   1xllyf26ypk37k807g5v6fl1449mhpvk18dljmqgwj723n0v8rpj
> hash mismatch for store item 
> '/gnu/store/rj33x41i86vgw6c0iwffzwrgzrib1shb-ghc-lucid-2.9.12.1-1.cabal'
> build of 
> /gnu/store/i62zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv 
> failed
> View build log at 
> '/var/log/guix/drvs/i6/2zr0ykqyxfwyc270csnhbwyrk3l3bb-ghc-lucid-2.9.12.1-1.cabal.drv.gz'.
> cannot build derivation 
> `/gnu/store/9m71fs1i0anv89f5zq44hbh2wn2lavxz-ghc-lucid-2.9.12.1.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/gz1qzalbg3dzwvfvj81f13n8pd47rzw2-hledger-1.21.drv': 1 
> dependencies couldn't be built
> guix copy: error: build of 
> `/gnu/store/gz1qzalbg3dzwvfvj81f13n8pd47rzw2-hledger-1.21.drv' failed
>
>
> 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.

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.

I suppose we could do better, for instance by computing the derivation
on the remote store, though that can be a bit slow.

Ludo’.

Re: branch master updated: gnu: python-lxml: Update to 4.6.5.

[Ludovic Courtès]

Hi Danny!

While you’re here :-), could you reply to that request of mine
concerning blog post licensing?  TIA!  :-)

  https://lists.gnu.org/archive/html/guix-devel/2022-07/msg00059.html

Ludo’.

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

[Ludovic Courtès]

Hi,

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’.

Ludo’.

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

[Ludovic Courtès]

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.

> +might be subjective, though it should lie somewhere between 10~20 lines.

Rather “10--20 lines” (Texinfo replaces dash-dash with an en dash).

Thanks!

Ludo’.