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?
No comments:
Post a Comment