Re: Patch Review Flow

[Christopher Baines]

"jgart"  writes:

> Does anyone follow this workflow for reviewing patches?
>
> git clone https://git.guix-patches.cbaines.net/guix-patches/
> git checkout issue-x
> git format-patch ...
> # then in the development checkout of Guix:
> git am ...; make; ./pre-inst-env guix build
>
> Should we document it in the manual?
>
> Does anyone follow a workflow that is more efficient than the above?

I have the guix-patches repository as a remote, which I then cherry pick
from (via Magit), which makes it quick and easy to apply patches.


signature.asc
Description: PGP signature

Re: mesa-updates: call for patches

[John Kehayias]

> Details of changes below, which included some more ungrafting:
>
>>> Here is a list of what has been on my radar and I'll be looking to
>>> apply on the mesa-updates branch. If there's something I missed and
>>> you think makes sense here (e.g. lower level graphical/X related
>>> libraries) please let me know. And yes, I need to make a Mesa team. It
>>> is on my list!
>>>
>>> 1. ungraft libx11 and libxpm
>>>
>
> These are done.
>
> Also, since I didn't realize libx11 means building python, and rust,
> and so on, I figured I would ungraft more that was being rebuilt
> anyway. So nghttp2 and curl have been ungrafted.
>
> The only more involved change was in ungrafting curl (to keep another
> test skip for Hurd), in
> 
> and then running parallel tests (very nice speed up for building curl
> I came across in the documentation!) in
> .
> Please do take a look in case I missed something here, but all built
> fine locally on x86_64 at least.
>
>>> 2. update mesa (23.2.1)
>>>
>>> 3.  (libepoxy fix for GTK, see
>>> )
>>>
>
> These are done.
>
>>> 4.  (mesa vulkan search-paths)
>>>
>
> I don't think this is a correct change as written (search-path should
> be in vulkan-loader if I'm understanding what is supposed to happen
> here). Anyway, will follow up on that issue and left it out for now.
>
>>> 5.  (sdl2 vulkan-loader; and update 
>>> sdl2?)
>>>
>>> 6.  (libdrm update; to even newer 
>>> version now)
>>>
>>> 7.  (libxkbcommon update)
>>>
>>> 8.  (pixman update)
>>>
>
> All these done (sdl2 was also updated to latest version).
>
>>> 9. submit patch for mesa team
>>>
>
> But not this one, the easy one :) It will be sent.
>
>>> Thanks everyone! And when you see the updates pushed on mesa-updates
>>> and builds become available, please do test and let me know. Or if
>>> you'd like to join this team of one, happy to have you on board.
>>
>> Sounds like a fine plan!  Thank you for tackling this!
>
> Happy to! Substitutes will eventually become available, but there's
> quite a few builds to be done. This takes care of some ungrafts and
> updates with I hope minimal disruption. I'll be keeping an eye out and
> using locally as well. Please test and report, thanks everyone!
>
> John

An issue was created to track merging the mesa-updates branch here:
. Please use that bug number as
needed (and cc me or use wide-reply in emacs debbugs).

Re: mesa-updates: call for patches

[John Kehayias]

Hi Maxim and guix-devel,

On Tue, Oct 31, 2023 at 09:27 AM, Maxim Cournoyer wrote:

> Hi John,
>
> John Kehayias  writes:
>
[...]
>
> If you're going to put a branch for it and build it whole, I'd simply
> merge it whole after it's done building and hasn't regressed on package
> failures or other things.
>
[...]
>
> I'd say go for a branch!
>

Yes, pushed a bunch of changes to mesa-updates after I built up
through mesa locally. Then I hit the rust compiler chain so I decided
to let the CI take over and build everything else too.

Details of changes below, which included some more ungrafting:

>> Here is a list of what has been on my radar and I'll be looking to
>> apply on the mesa-updates branch. If there's something I missed and
>> you think makes sense here (e.g. lower level graphical/X related
>> libraries) please let me know. And yes, I need to make a Mesa team. It
>> is on my list!
>>
>> 1. ungraft libx11 and libxpm
>>

These are done.

Also, since I didn't realize libx11 means building python, and rust,
and so on, I figured I would ungraft more that was being rebuilt
anyway. So nghttp2 and curl have been ungrafted.

The only more involved change was in ungrafting curl (to keep another
test skip for Hurd), in

and then running parallel tests (very nice speed up for building curl
I came across in the documentation!) in
.
Please do take a look in case I missed something here, but all built
fine locally on x86_64 at least.

>> 2. update mesa (23.2.1)
>>
>> 3.  (libepoxy fix for GTK, see
>> )
>>

These are done.

>> 4.  (mesa vulkan search-paths)
>>

I don't think this is a correct change as written (search-path should
be in vulkan-loader if I'm understanding what is supposed to happen
here). Anyway, will follow up on that issue and left it out for now.

>> 5.  (sdl2 vulkan-loader; and update sdl2?)
>>
>> 6.  (libdrm update; to even newer version 
>> now)
>>
>> 7.  (libxkbcommon update)
>>
>> 8.  (pixman update)
>>

All these done (sdl2 was also updated to latest version).

>> 9. submit patch for mesa team
>>

But not this one, the easy one :) It will be sent.

>> Thanks everyone! And when you see the updates pushed on mesa-updates
>> and builds become available, please do test and let me know. Or if
>> you'd like to join this team of one, happy to have you on board.
>
> Sounds like a fine plan!  Thank you for tackling this!

Happy to! Substitutes will eventually become available, but there's
quite a few builds to be done. This takes care of some ungrafts and
updates with I hope minimal disruption. I'll be keeping an eye out and
using locally as well. Please test and report, thanks everyone!

John

Patch Review Flow

[jgart]

Hi Guixers,

Does anyone follow this workflow for reviewing patches?

git clone https://git.guix-patches.cbaines.net/guix-patches/
git checkout issue-x
git format-patch ...
# then in the development checkout of Guix:
git am ...; make; ./pre-inst-env guix build

Should we document it in the manual?

Does anyone follow a workflow that is more efficient than the above?

all best,

jgart

Re: Moment de convivialité Guix@Paris en octobre

[Edouard Klein]

Je souhaite venir également :) J'avais raté l'annonce pour octobre.

J'aurais deux trucs à présenter:
- Du sucre syntaxique pour instancier, étendre, modifier, ou supprimer
des services,
- Comment monter des systèmes de fichier 9P au sein d'un guix container.

C'est pas super formel, ce sont des recherches en cours, mais si je peux
rétroprojeter mon écran et blablater pendant environ 20 minutes (en
tout), ça serait super.

Il faut apporter à manger/boire pour partager ?

++

Edouard.

Tanguy LE CARROUR  writes:

> Quoting Tanguy LE CARROUR (2023-10-27 09:04:26)
>> Vu que l'on a passé une bonne soirée, on va remettre ça ! À priori,
>> le jeudi 1er décembre. La date sera confirmée sur ces listes une ou deux
>> semaines avant.
>
> Erreur ! Il fallait lire « le jeudi 7 décembre ».
>
> Bonne journée,

Re: mesa@23.1.4: missing symbols

[Sergio Pastor Pérez]

Hello John.

I've been experimenting with `libglvnd'. I've patched the calls to
`dlopen` so they pick the `libGL.so.1` from the package `inputs`, which
includes `libglvnd'.

That's all well and good but a new issue seems to arise. At runtime, the
application panics when asserting the creation a `FRAMEBUFFER`. This is
the error:
--8<---cut here---start->8---
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `36053`', 
/tmp/guix-build-mission-center-0.3.3.drv-0/pathfinder/gl/src/lib.rs:600:13
--8<---cut here---end--->8---

It originates on the following rust function:
--8<---cut here---start->8---
fn create_framebuffer(, texture: GLTexture) -> GLFramebuffer {
let mut gl_framebuffer = 0;
unsafe {
gl::GenFramebuffers(1,  gl_framebuffer); ck();
gl::BindFramebuffer(gl::FRAMEBUFFER, gl_framebuffer); ck();
self.bind_texture(, 0);
gl::FramebufferTexture2D(gl::FRAMEBUFFER,
gl::COLOR_ATTACHMENT0,
gl::TEXTURE_2D,
texture.gl_texture,
0); ck();
assert_eq!(gl::CheckFramebufferStatus(gl::FRAMEBUFFER), 
gl::FRAMEBUFFER_COMPLETE);
}

GLFramebuffer { gl_framebuffer, texture }
}
--8<---cut here---end--->8---

I've been trying to fix the issue for a few days already but this goes
out of my knowledge.

I'm witting this mail with the hope that someone could have an idea on
how to tackle this issue.

In will attach the package definition and the required dependencies to
build it. Any help would be appreciated. I believe this is an
interesting package for Guix since it would be the first example on how
to build a rust application that uses the `meson-build-system'. As an
addition, I've packaged many rust dependencies which, most of them,
build successfully.

The package requires dependencies only available on the `gnome-team`
branch. In order to build the application the following command can be
used:
--8<---cut here---start->8---
guix time-machine -q --commit=e38d6a9c2fba815ac34e74baa843f15e33846813 -- build 
mission-center
--8<---cut here---end--->8---

Note that this package requires glib schemas to be installed. The only
solution I know for testing, is to install the package with:
--8<---cut here---start->8---
guix time-machine -q --commit=e38d6a9c2fba815ac34e74baa843f15e33846813 -- 
install mission-center
--8<---cut here---end--->8---

You can execute it with:
--8<---cut here---start->8---
$(guix time-machine -q --commit=e38d6a9c2fba815ac34e74baa843f15e33846813 -- 
build mission-center)/bin/missioncenter
--8<---cut here---end--->8---

Thanks everyone for your time.
Have a great day.

[ATTACHMENT]:
<>

John Kehayias  writes:

> Hi Sergio,
>
> On Fri, Nov 03, 2023 at 06:05 PM, Sergio Pastor Pérez wrote:
>
>> Hi.
>>
>> I've noticed that the `mesa' package we provide is missing some
>> symbols that according to the OpenGL specification should be present on
>> the `libGL.so.1` library.
>>
>
> I'll put the punchline up top with a few more details below. But the
> symbol you want is in the libglvnd package:
>
> --8<---cut here---start->8---
> ❯ nm -gD $(guix build libglvnd)/lib/libGL.so | grep glBindTextureUnit
> 0004cb60 T glBindTextureUnit
> 0004cb80 T glBindTextureUnitParameterEXT
> --8<---cut here---end--->8---
>
>> The following commands demonstrate the issue:
>>
>> $ guix build mesa
>> /gnu/store/ds15k8bzqf1m861w17hshd8i54pffig9-mesa-23.1.4-bin
>> /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4
>>
>> $ nm -gD 
>> /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4/lib/libGL.so.1 | 
>> grep glBindTextureUnit
>>
>> $ glxinfo | grep "OpenGL version"
>> OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.4
>>
>>
>
> Indeed, I found this very puzzling as you did. I looked for other
> symbols defined in the same Mesa headers and it was hit or miss
> (mostly miss).
>
>> As you can see the grep does not match any symbol. In contrast, if we do
>> the same under an Ubuntu installation, we can see the following output:
>>
>> $ nm -gD /usr/lib/x86_64-linux-gnu/libGL.so.1 | grep glBindTextureUnit
>> 00046b60 T glBindTextureUnit
>> 00046b80 T glBindTextureUnitParameterEXT
>>
>> $ glxinfo | grep "OpenGL version"
>> OpenGL version string: 4.6 (Compatibility Profile) Mesa 
>> 23.0.4-0ubuntu1~22.04.1
>>
>
> I have a laptop with Arch on it and I saw the same thing you did on
> Unbuntu. However, I decided to double check where libGL comes from and
> it is owned not by the mesa package there but libglvnd! And that's how
> I found libGL