Re: UPDATE: audio/picard-2.9.1

[Jose Maldonado]

El 31/8/23 a las 10:58, Stefan Hagen escribió:

Jose Maldonado wrote (2023-08-31 09:21 CEST):

El 31/8/23 a las 3:18, Stefan Hagen escribió:

Hi Jose,

Jose Maldonado wrote (2023-08-31 08:26 CEST):

Hi, this is my first contribution. Bump version for audio/picard to 2.9.1.
All tested in amd64, not problems.

You did a good job. For some reason your patch contained line breaks in
the PLIST that shouldn't be there. But no problem - I just regenerated
it.

+MODPY_EGG_VERSION =    2.9.1
   DISTNAME =           picard-${MODPY_EGG_VERSION}
   REVISION =           0

When the port version is bumped up, the REVISION can be removed.
Everything else looks fine to me.

Diff below with the following changes:
- REVISION removed
- RUN_DEPENDS sorted
- Comment that pthread is needed, so the next person updating it won't
    trip over it.

A runtime test was successful.

The test target runs to 38% and then get's stuck at
test/test_util_pipe.py where it loops at 100% cpu forever.

ktrace:
5861148  46436 python3.10 CALL  open(0x80316d14050,0x10000<O_RDONLY|O_CLOEXEC>)
5861149  46436 python3.10 RET   open -1 errno 2 No such file or directory
5861150  46436 python3.10 CALL  
futex(0x803b2dc4ec0,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0)
5861151  46436 python3.10 RET   futex 0
5861152  46436 python3.10 CALL  
futex(0x803b2dc8210,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0)
5861153  46436 python3.10 RET   futex 0
5861154  46436 python3.10 CALL  open(0x80316d14050,0x10000<O_RDONLY|O_CLOEXEC>)
5861155  46436 python3.10 RET   open -1 errno 2 No such file or directory

It seems not to hurt picard though.

Best Regards,
Stefan

Thanks for the comments, I will take them into account for the next diff.

Right now, I'm taking a look at Picard Github, to see what I can find that
gives an explanation to the problem indicated in the list.

I just opened picard 20 times in a row and clicked around without a
crash. I turned HW acceleration off in xorg.conf (amdgpu):
     Option "Accel"    "off"

With this option "on", roughly every third picard start would kill X.

Is this the issue others are facing too, or did I stumble at something
new?

Best regards,
Stefan

Ok I have tested this package further and found the following:

1.- Picard only crashes using the media player features (made possible by the use of PyQT5 and its QTMultimedia modules). If I launch Picard with the -M option (disabling these features), it does not crash and I can use the software without problems. 2.- I can replicate the problem (complete failure of Xenocara) using another software that I have written using PyQT5. This software uses the QtMultimedia modules, and I get the problem, one run and Xenocara dies. I have read this topic (https://www.mail-archive.com/tech@openbsd.org/msg72531.html) and maybe this is related to the crashes, because this is directly related to XCB, DRM and Xenocara.

In fact, I have tested the latest snapshot of current, and now the Xenocara segfault has changed (this latest snapshot includes some changes in the DRM code). I am going to submit an issue to bugs mail list, because this looks like a bug in the Xenocara/DRM code (possibly a regression). 3.- I have cleaned up the pthreads in the Makefile...and Picard compiles and runs correctly. Are you ok with this or are we waiting for a fix for the Xenocara crash problem?

rev-picard-plist-2.9.1
Description: Unix manual page

rev-picard-makefile-2.9.1
Description: Unix manual page

rev-picard-distinfo-2.9.1
Description: Unix manual page