Chris Billington wrote:
> Stuart Henderson wrote:
>> On 2026/09/10 16:42, Chris Billington wrote:
>>> +EXTRACT_SUFX =        .tar.gz
>>
>> not needed, this is the default
>>
>>> +SHA256 (3b12bc579b99932e3fe307ea1e44b8c1c6d1d5c9.tar.gz) = 
>>> 8F0xFe9bimf51zwRpZdy3EKaUdcFCZ1vuUFOq5VLb1g=
>>
>> not a valid filename for distfiles
>>
>> the patch to PLIST doesn't fully apply:
>>
>> Hunk #22 failed at 1981.
>> 1 out of 124 hunks failed--saving rejects to pkg/PLIST.rej
>>
>>
>> On 2026/09/10 03:07, Anthony J. Bentley wrote:
>>> Chris Billington writes:
>>>> - upstream uses git submodules for pugixml, SingleApplication, and the
>>>> 'elements' library. I have used the same pinned revisions in
>>>> SITES.xxx/DISTFILES.xxx as the upstream branch.
>>>
>>> DIST_TUPLE would be a better fit for this.
>>
>> yes, that would fix the 3b12bc5... filename too. (btw you can use GH_*
>> for the main file and DIST_TUPLE for submodules; portroach is likely to
>> cope better with that)
>>
>>>> - The 'elements' user-submitted library (CC-BY-SA 3.0) is pinned 
>>>> against
>>>> a 9-month-old commit of the submodule repo.
>>>> Is it permissible to use a recent commit instead, since that would 
>>>> still
>>>> make a reproducible build but would include more recent items?
>>>
>>> If doing so provides value and doesn't introduce incompatibility, then
>>> sure.
>>
>> agreed (in many cases there is a reason why upstream pins a particular
>> version, in some other cases there isn't, so do check)
>>
>>>> - portcheck notes 3 Makefile lines longer than 80 chars, but it's not
>>>> easy to break them without sacrificing readability. Is that acceptable?
>>>
>>> Yes.
>>>
>> Attached revised diff (gzipped)
> 
> - use DIST_TUPLE (found it was not possible to mix DIST_TUPLE and GH_*)
> 
> - elements submodule now pinned to a more recent Aug 2026 commit: brings 
> in a lot of networking/dev board library elements
> 
> - diff applies OK to -current ports tree of 11 Sep, but I also attach 
> the port tgz (from the port directory) as a backup.
> 
> - Qt6: I tried building against Qt6/KF6, but the 0.100 branch is not yet 
> Qt6-clean. Specifically, cmake/fetch_kdeaddons.cmake is hardcoded to use 
> KF5. The upstream master branch is KF6/5 agnostic and it seems the next 
> 0.200.x release will be Qt6-capable. Work is ongoing, Windows-first. So 
> we could maybe switch after next release.
> 
> - port-lib-depends-check marked GL and sqlite3 as 'Extra:' WANTLIBS for 
> the cmake build, compared to the 0.91 qmake build. I am assuming this is 
> because Qt5Gui and Qt5Sql pick them up, but why was this not the case 
> with 0.91?
> 
> - On both of my -current machines, both 0.100 AND the present 0.91p0 
> display a redraw bug when inserting a library element: the cursor 
> 'guidelines' do not disappear until a redraw is forced by a tiny zoom 
> in/out with the mouse wheel.
> This effect is NOT present on either the old or new 0.100 builds on my 
> 7.9-stable machine.
> It looks like a DRM issue to me. Have there been changes to Qt5 graphics 
> rendering since 7.9-release that could cause this?
> 
> Regards
> Chris
> 
Further testing shows the redraw bug is not present under cwm or dwm. It 
seems to be an XFCE-specific issue.
Chris