etc/commiter.scm should not commit

[Csepp]

There have been countless times when I was using etc/commiter.scm and it
commited more than it should have and then slapped an incorrect message
on it.
I think it would make a lot more sense if adding changes was left up to
the human at the keyboard (at least by default) and the script was
invoked only when editing the commit message.

Re: FOSDEM’s coming!

[Tobias Platen]

Am Montag, dem 23.01.2023 um 18:39 +0100 schrieb Ludovic Courtès:
> The blog post is on-line now:
> 
>   https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/
> 
> Thanks everyone.  This program is exciting!
> 
> Ludo’.
> 
Unfortunately I'll won't make it to Brussels this year, so I ask if
there is an IRC chat or recording of talks at the fringe event.

Tobias Alexandra

Re: FOSDEM’s coming!

[Ludovic Courtès]

The blog post is on-line now:

  https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/

Thanks everyone.  This program is exciting!

Ludo’.

declarative containers (was Re: [EXT] Re: Enterprise Guix Hosting?)

[Giovanni Biscuolo]

Hello everybody,

(this is an old thread started on help-guix [1])

Ludovic Courtès  writes:

> "Thompson, David"  skribis:
>
>> On Wed, Aug 31, 2022 at 2:40 AM Ricardo Wurmus  wrote:
>>>
>>> Another thing that seems to be missing is a way to supervise and manage
>>> running containers.  I use a shepherd instance for this with
>>> container-specific actions like this:

[...]

>> Hey that's a real nice starting point for a container management tool!
>>  So maybe there should be a system service to manage containers and
>> then a 'docker compose'-like tool for declaratively specifying
>> containers and their network bridging configuration that is a client
>> of the service?
>
> Agreed!  We could turn Ricardo’s code into ‘container-guest-service’ or
> something and have ‘containerized-operating-system’ add it
> automatically.

please there was some progress with this service?

once done, could it be possible to declaratively start a whole network
of containers using a dedicated home-service, or
containerized-operating-systems (also on foreign distros)?

right now with "guix system container" we can imperatively manage
(start/stop, connect to the console with nsenter) and connect them
to the network [2], Ricardo showed us how he do it programmatically;
having a declarative interface (os-records) whould be awesome!

I'm very interested and willing to test it, if needed

thanks! Gio'


[1] id:878rn4syql@elephly.net

[2] thank you Ricardo for the cookbook section!
https://guix.gnu.org/en/cookbook/en/guix-cookbook.html#Guix-System-Containers

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: FOSDEM’s coming!

[Ludovic Courtès]

Hello,

zimoun  skribis:

> When submitting a proposal for a stand (that had been refused :-(), I
> collected all the presentations – if I have not missed some; let me
> know.
>
> In this FOSDEM 2023 session, we have 10 talks about Guix, compared to
> the 31 ones counted over the past years.  Is Guix becoming trendy?  ;-)

Woow, this is impressive!

I won’t put it all in the blog post :-) but we should make sure all of
them can be reached from the web site.

We should also consider launching tv.guix.gnu.org to stream Guix talks
24/7 worldwide.

Ludo’.

Re: FOSDEM’s coming!

[Ludovic Courtès]

Hi John,

John Kehayias  skribis:

> Thanks for doing the work of collecting all this, can't wait to see the talks!
>
> Unfortunately I won't be able to be there in person and the time difference 
> will make attending much of it live difficult, but I'll be around besides for 
> my own short talk.

In past editions, support for on-line interaction was pretty good so I’m
confident it’s going to be nice.

> You may want to clarify what "video only" means. I take it that is for 
> remotely presented talks, which are recorded beforehand, though the presenter 
> should be available virtually during that time for live questions.

Good point, I’ll clarify that.

> Speaking of, just a minor typo I noticed (for my own small part). Here is a 
> quick diff for the change:

Oops, applied.  Thanks!

Ludo’.

Re: FOSDEM’s coming!

[Ludovic Courtès]

Hi,

Lars-Dominik Braun  skribis:

> note that the Guix Days take place on February *2nd and 3rd* (correctly
> identified as Thursday and Friday in the post).

Oops, fixed.  Thanks!

Ludo’.

Re: Proposed changes to the commit policy (#59513)

[Simon Tournier]

Hi Andreas,

On Sun, 22 Jan 2023 at 18:18, Andreas Enge  wrote:

> So I tried it once, and find the hassle offputting. It feels like doubling
> the effort - after doing the real work, I need to get back to it a week
> later and more or less go through the motions again (rebase the commit
> and resign it, recompile Guix, build the package again just in case),
> plus the debbugs effort.

As mentioned here [1], it was possible to see the result of the QA for
this patch here:

https://qa.guix.gnu.org/issue/60931

where the patch has been built on several architectures and all the
dependants too.  Now, because the patch had been pushed, this result is
not visible anymore. :-)

1: 


That’s said, the patch had been built for all architectures and all the
dependants too, “guix lint” is applied systematically, etc.

For example, “guix lint” currently allows to be sure that the package is
archived in Software Heritage; maybe this will change in the future.

For what it is worth, I barely build for all the architectures the
patches I submit.  And I do not systematically rebuild all the
dependants because sometimes I “feel confident” it is a “trivial” change
that does not deserve such rebuild.  For sure, I do not remember rebuild
all the dependants for all the architectures.


Well, between the lines, are you suggesting that it is broken by design? :-)

Other said, it would not be possible to have the dashboard [2] all
green, right?  Because the QA provides some green lights for a state but
then you push to another state where the lights are unknown.

2: 


> So expect even less package updates from my part in the future... These
> were the kind of instant gratification actions one could do more or less
> in the background, and they have become more complex administrative
> endeavours with delayed gratification.

While I understand this “extra“ work is a burden, what would you suggest
to reduce the number of broken packages?  Because all the red circles in
the dashboard [2] is a strong issue, IMHO.

When using Debian, I cross the fingers each time I run ‘apt upgrade’.
Using Guix, I cross the fingers each time I run ‘guix pull’.  Surprise,
surprise. :-)  Sometimes, the package that worked still works, sometimes
not.

This kind of example [3]:

Well, for a concrete example, please give a look at [0].  A “trivial”
and apparently inoffensive update of the package ’git’ from 2.38.0 to
2.38.1 breaks some Julia packages.  And, “guix refresh -l git” does not
mention these Julia packages.  The package ’git-minimal’ inherits from
’git’ and some Julia packages depends on ’git-minimal’.

0: 

happens more than often.  Give a look at the dashboard. ;-) Obviously,
no blame. :-) Moreover, the complexity of all the parameters is not
tractable only by manual actions, IMHO.

At work, the feedback I often get is: Guix is not enough stable to daily
work and users cannot spend time to investigate if they are doing
something wrong or if it is broken.  People are fix again and again
something unrelated to their current task just because they did “guix
pull” (for having some new packages, some security fixes, etc.).

To avoid misunderstanding, I daily work with Guix and I am happy. :-)

Well, as I also wrote earlier [3]. :-) « We – from core developers to
user just wanting the things done – are all pulling the same branch.
This branch cannot satisfy in the same time all the constraints; is the
current push/pull branch model satisfying the best optimum with the
resource and tools at hand? »

Maybe the current full rolling-release applied to functional package
management does not scale well?

3: 


> Am Wed, Jan 18, 2023 at 04:54:58PM + schrieb Kaelyn:
>> On a side note, I'd recently discovered the flag to pass. To have a
>>subject prefix like "[PATCH core-updates]" (as mentioned in the manual
>>for staging and core-updates patches) instead of the default "[PATCH]",
>>one can pass "--subject-prefix="PATCH core-updates" to git
>>format-patch. 
>
> This sounds like it could be a useful addition to the QA process.

To my knowledge, it is not possible to continuously build core-updates
because the project does not have enough resource (both human power and
machine power).

Or do you mean mentioning this option of git-format-patch under point #9
of «Submitting Patches» [4]?  Because this option is already in the
manual under «Sending a Patch Series» section:

 Tip: To add a prefix to the subject of your patch, you may use the
 ‘--subject-prefix’ option.  The Guix project uses this to specify
 that the patch is intended for a branch or repository other than
 the ‘master’ branch of
 .

  git send-email -1 -a