On 2022-07-27 22:05, Maxime Devos wrote:
> On 27-07-2022 21:00, Tomasz Jeneralczyk wrote:
> IIUC, that's for using Guile modules defined in packages -- but mpv is
> not a Guile package, so I expect that the surrounding with-extensions
> can be dropped.
You're right. I dropped it with no negative consequences.

> This sounds like something upstream should be informed about, otherwise 
> they wouldn't know there is something to fix.
I had a friend on arch linux run those tests and everything worked just 
fine, so it might have something to do with guix
itself or an incomplete package definition. In any case, I'll make sure 
to write a proper bug report in the upstream repo later.


> Look for substitute-keyword-arguments, which isn't stateful and hence
> there is less risk of accidentally modifying the arguments of the
> parent package.  Also, any reason for not adding this to the original
> package? (Possibly there is one).
Thanks, this macro is not documented in manual, but it looks much nicer 
now.
The reason I made a new package is simply because someone on irc 
recommended me to do as such. Though your question made me realize
that just adding one flag worked because all the necessary packages to 
build python buildings were in opencv package already...
maybe originally it was intended for the python bindings to be included 
in opencv? And so I added the flag to opencv and removed
my original package - it works all the same.


> Run "./pre-inst-env guix lint hydrus-network", it will have a remark
> about this.  Also, technically this is racy -- it's possible for
> python to start before Xvfb is ready though so far this doesn't seem
> to have caused trouble for other packages yet AFAIK -- I recommend
> "xvfb-run" "--" "python" "test.py" instead.
I though I missed something so I ran lint again, but it only said 
there's a new version of hydrus available.
Nevertheless I changed the invocation to what you recommended. I also 
updated hydrus to version 493.


> (I just scrolled quickly through the patches, a more full review will
> have to come later.)
Thank you for all your comments so far.
I made changes but I wont send them as patches until I fix all the 
problems or get a confirmation that there's nothing more to do.

However I'm attaching a "preview" diff of the changes I'll want to 
iclude in v2 of my patches.
I suppose I should only send v2 of the ones I changed, right?.