Re: bug#66964: Request for merging "mesa-updates" branch

[John Kehayias]

Guix-ers,

On Wed, Nov 15, 2023 at 08:28 AM, Efraim Flashner wrote:

> On Tue, Nov 14, 2023 at 08:11:08PM +, John Kehayias wrote:
>> Hi Kaelyn,
>>
>> On Sun, Nov 12, 2023 at 08:01 PM, Kaelyn wrote:
>>
>> > Hi,
>> >
>> > I've just submitted a pair of patches for the mesa-updates branch:
>> >  updating xorgproto and
>> > xorg-server-xwayland. The xorgproto is a high-impact update (guix
>> > refresh reports rebuilding 8710 packages would ensure 22871 dependent
>> > packages are rebuilt), but required to update to the latest xwayland
>> > as xwayland requires a newer version of presentproto than in the
>> > current guix xorgproto package. The updating and ungrafting of mesa
>> > and a number of X.org related libraries seemed like a good time (and
>> > place) to update xorgproto as well.
>> >
>> > Cheers,
>> > Kaelyn
>>
>> Thanks for the patches. I think mesa-updates in this current iteration
>> is set on builds (ended up being a lot more due to the ungrafting but
>> seems done on our main architectures for several days now). I had to
>> make some other changes to fix some larger breakages but at this point I
>> think it will just be taking us back in the build queue too much.
>>
>> So I think it would make more sense on the next big rebuild, either
>> core-updates (talk about doing that with more ungrafts right now) or
>> I'll do mesa-updates again when the next release of mesa hits. Or maybe
>> it makes sense to just do another branch for xwayland?
>>
>> Open to ideas! I'll send a separate message soon on the status of
>> mesa-updates and see what people think, but my thought was to merge this
>> to master in the next day or so if there are no objections.
>
> If the mesa branch is ready to merge so soon then I think we should just
> get that merged and then I'll rebase the rust-team branch on top of new
> master.  The rust-team branch is also ready to merge, but we're way
> behind on aarch64 substitutes.  Either way the substitute servers will
> be rebuilding all of rust so I think it'd be better to merge in
> mesa-updates and then do rust.

Merged as 79765b40fd9b4921b531284c589ace8a2c89a6ea woop!

We got good coverage on x86_64, i686, powerpc64le, aarch64 (all
-linux) especially from Bordeaux. Unfortunately armhf got stuck even
with prodding and waiting, but hopefully it will recover. There may be
some slight catching up across the board with recent issues on Berlin,
but prior to things getting wonky it was looking good (of course all
that happened right when I wanted to merge the other day).

Thanks to Efraim for some fixes and especially getting non-x86 in
better shape.

Feel free anyone to ping me on patches/bugs due to this merge. And
please enjoy updated mesa, fixes to gtk4 applications, some less
grafts, and more.

John

PS: I'll return to mesa-updates soon with next major mesa update and
pending related patches, or in core-updates if that is getting close.

Re: [PATCH] gnu: xorg-server: Update to 21.1.9.

[John Kehayias]

Dear Kaelyn,

On Mon, Nov 27, 2023 at 08:46 PM, Kaelyn wrote:

> Hi,
>
> I wanted to bring folks' attention to
>  which updates xorg-server, including
> a number of security fixes. The patch has been pending for about 17
> days now, and while the QA badge reports "failed" I just spot-checked
> some of the failures and they seem to be unrelated (e.g. a lot of
> builds going from unknown to blocked or vice versa, the one new
> failure for aarch64 being a large download test in the onionshare
> package, etc).
>

Thanks for the update. Yes, QA looked good to me too, all things
considered.

> Is there anything I can do to help the process along? It may also be
> worth noting that "guix refresh -l xorg-server" reports 125 rebuilds.
> I also checked and the update to xorg-server does not appear to alter
> the derivation for the xorg-server-for-tests (which is still at
> version 21.1.1).
>
> Cheers,
> Kaelyn

No, you did exactly what you needed to. I did see this patch when it
came in and was just giving a bit for QA to do the builds. That took
longer, I got distracted hoping I could merge mesa-updates first, then
hit CI delays...all that is to say I should have communicated I had
this on my radar.

Sorry about that! I appreciate the patch and the nudge.

Pushed as 06e0f638abd36f816a221af4542ca4a850d7af2d with a minor tweak
to the commit message to note [security fixes] at the top. I built it
locally for x86_64 with mesa-updates merged.

Which reminds me to make sure we have a way to flagging security
updates just like other teams/tags and get them priority. Now on the
security team, it is a first priority.

Thanks again!
John

Re: what is the status of the core-updates now

[Maxime Devos]

Op 23-11-2023 om 13:02 schreef Z572:


Maxime Devos  writes:


[[PGP Signed Part:Undecided]]


Op 21-11-2023 om 18:21 schreef Maxime Devos:

  > [PATCH] gnu: ephemeralpg: Fix cross-compilation.
There is already a patch for that:

and (a rebased version of) it effectively has already been applied:


ok, close it.

I guess you could copy it from c-u to master if you don't want to
wait for the c-u merge, but please use the search function at
:


what is the status of the core-updates now,it on ci.guix.gnu.org only build
'core', is this a configuration error?


I don't know.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: shepherd GEXP module import mystery

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

Hi Attila,

On Mon, Nov 27 2023, Attila Lendvai wrote:

> a start GEXP of my service sees bindings that come from the module
> called (shepherd support), but i have no idea who and where imports
> that module.

Without code it's hazardous to speculate, but could the Guix service
(gnu service mcron) cause that issue when it is being logged?

In my code tree, which is a month behind, (gnu services mcron) is the
only Guix service that imports (shepherd support).

Kind regards
Felix

shepherd GEXP module import mystery

[Attila Lendvai]

dear Guix,

context: i'm adding logging to shepherd, and while i was testing it i 
encountered a conflict with my service code that shouldn't happen.

i'm probably missing something from my mental model around guile modules, 
and/or how shepherd compiles and loads them.

the symptom is that a start GEXP of my service sees bindings that come from the 
module called (shepherd support), but i have no idea who and where imports that 
module.

i added the following two format lines to the beginning of my start GEXP:

(format #t "*** start gexp speaking, current module is ~A, module-uses: ~A~%  
ringbuffer: ~A~%"
  (current-module)
  (module-uses (current-module))
  (and=> (module-variable (current-module) 'ring-buffer) variable-ref))

(format #t "*** ringbuffer in packages: ~A~%"
  (map (lambda (module-name)
 (and=> (module-variable (resolve-interface module-name)
 'ringbuffer)
variable-ref))
   '((guile) (oop goops) (shepherd service) (srfi srfi-34)
 (system repl error-handling) (guix build utils) (guix build syscalls)
 (gnu build file-systems

and they print:

*** start gexp speaking,
current module is #
module-uses: (
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
# 

*** ringbuffer in packages: (#f #f #f #f #f #f #f #f) 

how else can a definition (i.e. 'ringbuffer) get into this module without it 
coming from one of the modules in its module-uses list?

i'm pretty sure that it's coming from (shepherd support) because i'm neck deep 
in debugging the original issue: a macro from (shepherd support) overwrote my 
function that errored when it was called at runtime as a function.

i'm also seeing this warning (i.e. my root issue):

WARNING: (#{ g108}#): `log.debug' imported from both (guix-crypto utils) and 
(shepherd support)

i've checked the module list of the gexp, and how guix compiles the .go files 
that are then given to shepherd, and i see nothing obvious. i even looked at 
the source file that gets generated and compiled for the service in question, 
and it doesn't contain any mention of this module.

there are no direct mentions of (shepherd support) in the source, that's why i 
thought maybe something re-exports the entire module, so i checked the presence 
of 'ringbuffer in all the used modules... but it's not in any of them.

could it be a bug in how different versions/instances of guile serialize/load a 
.go file? or could it be due to the module magic in (gnu services shepherd) 
that compiles the shepherd config into a .go file?

i'm out of ideas, any hint is appreciated!

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“People always find partners [with] exactly the same level of unresolved 
traumas they are at, without any exception. Now the trauma may look 
differently, and how it manifests may look differently, but the degree of 
trauma is always equal, I mean with perfect accuracy. […] And that trauma then 
shows up in the relationship.”
— Gábor Máté (1944–), 'On The Spot - Az ellenség gyermekei', 48m50s

Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations)

[Liliana Marie Prikler]

Am Sonntag, dem 26.11.2023 um 21:46 +0100 schrieb Edouard Klein:
> 
> Liliana Marie Prikler  writes:
> > >     (instantiate nginx)
> > I do wish you spelled out service.  Also, instantiate takes as much
> > characters to type as add-service.
> > 
> 
> Done, see below. I was worried about the paronymy between add-service
> and add-services which already exists. I defer to you and your
> experience on this, naming things is hard.
That's not that much of a deal in scheme, see let and let* for example.

> > > To see the value of this syntactic sugar, try to replicate this
> > > MWE
> > > with the standard syntax. It's not horrendous, but it *is* off-
> > > putting to many newcomers to git, whereas this sugary piece is
> > > more
> > > readable for them (sample size of 1, p=0.0005).
> > Well, that'd be
> > ...
> 
> I tried:
> 
> (let ((base (minimal-ovh "osef")))
>   (operating-system
>     (inherit base)
>     (services
>   (cons*
>    (service nginx-service-type)
>    (service mumble-server-service-type
>     (mumble-server-configuration
>  (welcome-text "couocu")
>  (port 64738)))
>    (service openssh-service-type
>     (openssh-configuration
>  (password-authentication? #f)
>  (allow-empty-passwords? #t)
>  (authorized-keys `(("alice" ,(local-file
> "/home/edouard/.ssh/id_rsa.pub"))
>    (operating-system-user-services base)
> 
> 
> I admit that this is as readable as the sweet version, but:
> 
> - Openssh is already defined in  (minimal-ovh "osef"), so the build
>   fails with: 'guix system: error: service 'ssh-daemon' provided more
>   than once'
> - you forgot the removal of guix-service, which admitedly is not used
> much in practice
>   anyway
Nice catch.

> The problem with those two is that they break the nice structure of
> just adding services, and now one has to first remove an element from
> (operating-system-user-services base), then edit one of the element
> of the resulting list, then add to elements to it. It is probably
> possible to write it in a readable way, maybe less so than the sweet
> version, but not so much as to justify adding the new macros to guix.
Fair enough, but you could still implement that as an (extended)
modify-services.  We haven't reached the level of complexity where we'd
touch multiple fields, which is when operating-system really becomes a
pain to work with.  (The ssh-user from beaverlabs is one such example,
that IIRC is also used extensively on the-dam.)

> However the readability is not the main selling point, the
> writeability is. Please do not discount how hard it is to write that
> kind of stuff when scheme's not your main language. It is possible
> people here forgot how hard this is for beginners, especially those
> like me whose brain is deformed from years using algol-derived
> syntaxes.
> 
> I think we are losing a lot of mindshare because of the hard step of
> learning both guile and guix, and the kind of syntactic sugar I
> suggest may help bridge the gap long enough for newcomers to ease
> into the syntax, after they get a taste of guix' capabilities.
Fair point, and I'm not really opposed to making things more
readable/writable.  The problem comes with groking the additional
syntax.  It is not something the manuals would prepare you for and
probably also encounters weird corner cases like services using
something else than SERVICE-configuration for its configuration data.

> Another experiment: with the sweet syntax, you can easily extend
> services, without having to define a -record-type, etc. Just define a
> function. I can write more at length about that if you want.
That's again just simple-service doing its job tho :)

In essence, what I'm trying to get here is something that'd let us
implement the more complicated part of OS config fiddling with few
lines of code.  I think hyper-focusing on syntax to make services
"nicer" might be the wrong approach here: You could greatly reduce the
complexity by making them procedures instead of syntax and still keep
most of the configuration readable to a great extent.

Maybe we should start with making modify-services more powerful to also
cover the "adding services" case: modify-inputs already does that, so
it's weird that modify-services doesn't.  We should also think on how
to best wrap this in a lambda then; defining a new syntax for most
operations doesn't seem all that useful and scalable to me.

Cheers
> 

Re: [PATCH] gnu: xorg-server: Update to 21.1.9.

[Kaelyn]

Hi,

I wanted to bring folks' attention to https://issues.guix.gnu.org/67047 which 
updates xorg-server, including a number of security fixes. The patch has been 
pending for about 17 days now, and while the QA badge reports "failed" I just 
spot-checked some of the failures and they seem to be unrelated (e.g. a lot of 
builds going from unknown to blocked or vice versa, the one new failure for 
aarch64 being a large download test in the onionshare package, etc). 

Is there anything I can do to help the process along? It may also be worth 
noting that "guix refresh -l xorg-server" reports 125 rebuilds. I also checked 
and the update to xorg-server does not appear to alter the derivation for the 
xorg-server-for-tests (which is still at version 21.1.1).

Cheers,
Kaelyn

Re: role of core-updates

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

Hi Leo,

On Mon, Nov 27 2023, Leo Famulari wrote:

> The core-updates branch was / is for updating core packages, which are listed 
> here:
>
>  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/ci.scm?h=v1.4.0#n136

I was surprised to see guile-3.0 there. Should it read guile-3.0/pinned
instead?

Kind regards
Felix

Re: role of core-updates

[Leo Famulari]

On Mon, Nov 27, 2023, at 01:53, Andy Tai wrote:
> Hi, hope Guix maintainers can clarify the role of the now core-updates
> branch; the current documentation does not specify the core-updates
> branch as a thing but there are clearly interests and uses of this
> branch for package updates not belonging to a feature branch like
> gnome and it is useful for, say, updating to the GNU make package
> which would have caused world rebuild.  Thanks

Hi!

I'm not a maintainer but I did suggest the new 'feature branch' workflow so I 
will speak up.

The core-updates branch was / is for updating core packages, which are listed 
here:

 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/ci.scm?h=v1.4.0#n136

Perhaps other packages like 'make' could be considered honorary members of this 
group as well, or maybe some other workflow can be imagined by the project.

I hope that helps!

Leo