Re: Patch Review Flow
On Mon, Nov 06, 2023 at 07:51:58AM +, Christopher Baines wrote: > > "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. I also have the guix-patches repository as a remote, and then I use tig to look at the different branches there. I haven't checked to see if it's possible to use git am or git cherry-pick from tig's interface so I'm doing that one by one. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Patch Review Flow
Hi Efraim, Thanks for sharing your approach as well. IIRC, a user can't interactively cherry-pick a range with tig. If you find a way please do share ;()
Re: Patch Review Flow
On Tue, Nov 07, 2023 at 12:32:35PM +, jgart wrote: > Hi Efraim, > > Thanks for sharing your approach as well. IIRC, a user can't interactively > cherry-pick a range with tig. If you find a way please do share ;() It looks like 'C' (that's a 'big c') over a commit will offer to cherry-pick the commit. Alternatively, if you're still looking at the branches then 'C' will offer to checkout that branch. Tig asks for an explicit y or n, so pressing enter for the prompt won't do anything. I should probably look at the different options tig has. I've had it installed forever but only ever used it for viewing commits and branches. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Divvying up service definitions
Hi Bruno, Bruno Victal writes: > Hi, > > As the gnu/services and gnu/home/services grow, I think we should > consider divvying the services into stand-alone modules or > subdirectories. > > Consider the ⌜dovecot-service-type⌝ in gnu/services/mail.scm: as of > commit 'd22d2a05c389207f8cdcf824be7738b1499a987c' this service > definition is nearly 1600 lines long, with the remainder of the file > comprising of four other services with rudimentary support. > > It becomes troublesome working with such amalgamations as it makes it > hard to keep track of the used modules and bindings, especially when > define-configuration is used since the serializing procedures might be > used by various service definitions. Further complicating things is > 'define-maybe', whose use monopolizes the predicate and serializers for > a particular service definition. > > Now, I'm not saying that we should go and split everything into its own > module, I'm saying that we should be allowed to split some of them if > convenient (all subjective but I believe we can see that working with a > monolithic file in the kilolines where the interactions aren't obvious > is not fun, and that's without bringing in the hygienic issues > surrounding define-configuration and define-maybe). > > Some considerations (using dovecot-service-type as an example): > * Splitting this as gnu/services/mail/dovecot.scm. > We preserve the logical grouping of the services (with the addition > that, for extremely comprehensive definitions, these can be neatly > organized into subdirectories. (same structure seen with gnu/*.scm) > A drawback is that 'use-service-modules' might not work with this > although I wonder whether 'use-service-modules' & co. provide any > value if we are already doing '(use-modules (gnu) …)' to begin with. > They look redundant IMO. > > * Splitting this as gnu/services/dovecot.scm. > We keep it compatible with 'use-service-modules' at the cost of having > a multitude of files under gnu/services, without any logical grouping > (messy). That's a great initiative! I agree that multiple 'define-configuration' services per file can be a bit messy, having to use prefixes everywhere, making the definitions more verbose. I don't have a strong preference of the caterogization of services, but would perhaps prefer the first one (gnu/services/mail/dovecot.scm), which could then make it easy to offer some interface as gnu/services/mail.scm that'd re-export all that is needed (would that work, or reintroduce the same top-level clashes?). -- Thanks, Maxim
Re: Patch Review Flow
> I've had it installed forever but only ever used it for viewing commits and > branches. ditto! -- jgart
Re: Patch Review Flow
Hi jgart, "jgart" writes: > 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? There are many flows... perhaps we should illustrate them via examples in the Guix Cookbook manual? > Does anyone follow a workflow that is more efficient than the above? You can use the 'b4' tool to apply a series via a message's Message-ID that is from that series. Or you can use Emacs-Debbugs patch buffer (which is powered by Gnus), ensure your current directory for the main buffer is set to your Guix checkout (e.g. 'M-x cd RET ~/src/guix'), then apply the patches pressing the '|' to pipe it to 'git am -3' command with it. -- Thanks, Maxim
Re: Patch Review Flow
There's also the following workflow: Click on an individual patch in the mumi web interface to download it to ~/Downloads. cd guix-checkout git am -S ~/Downloads/53019-76.mbox Go back to the mumi interface and click on the next patch. Repeat. 😹😹😹 > Should we document an approach in the manual? Yes.
Re: mesa@23.1.4: missing symbols
Good evening.
Diving on the issues of the official `mission-center' repository I've
noticed this issue:
https://gitlab.com/mission-center-devs/mission-center/-/issues/87
Which has been recently merged into main as per the following merge
request [1]:
1:
https://gitlab.com/mission-center-devs/mission-center/-/merge_requests/76/diffs?commit_id=89fcd7f3d294fef833ba4c3369778d85a13b501b
Using the latest commit [2], authored 2 days ago, the issue ceases to
exist and the app starts successfully.
2: 4fc7268f5dd314580e721825a63d3e34421e8317;
Thanks every one that got involved from the IRC and mailing list.
Greetings,
Sergio.
Sergio Pastor Pérez writes:
> 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(&self, texture: GLTexture) -> GLFramebuffer {
> let mut gl_framebuffer = 0;
> unsafe {
> gl::GenFramebuffers(1, &mut gl_framebuffer); ck();
> gl::BindFramebuffer(gl::FRAMEBUFFER, gl_framebuffer); ck();
> self.bind_texture(&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
Re: Better support remote deployment
Hi, On Tue, Nov 07 2023, Maxim Cournoyer wrote: > Then your suggestion to extend 'guix package' to be able to > install a profile from a store profile sounds useful, or perhaps a new > 'guix deploy-profile' (or a better name / sub-command?) that would > automate the copy and installation in one step. We have a lot of sub-commands already. Could 'guix deploy' instead be fed something other than a 'machine' record? How about a 'remote-user-profile'? Kind regards Felix
