Re: Fwd: KDE 6 + Wayland : it works or not ?

[Jesper Schmitz Mouridsen]

 that the problems that we see are related to X11 and / or KDE6


On Mon, Jul 22, 2024 at 7:17 PM Mario Marietto 
wrote:


Hello.

I've fixed the compilation error. Now I would like to fix the error 
inside

your script. I've added tmpfs,but I get it anyway.

[image: Istantanea_2024-07-22_19-16-07.png]
[image: Istantanea_2024-07-22_19-16-41.png]

On Mon, Jul 22, 2024 at 5:36 PM Mario Marietto 
wrote:

I'm not sure if poudriere will fix that bug (that I saw every time I 
have
restarted the compilation using an earlier version of the vm). I 
suspect

that learning poudriere can't help me and it is a waste of time.

On Mon, Jul 22, 2024 at 3:16 PM Tobias C. Berner 
wrote:


It builds for both wayland and x11.

Mfg Tobias

-- Forwarded message -
Von: Mario Marietto 
Date: Mo., 22. Juli 2024, 14:53
Subject: Re: KDE 6 + Wayland : it works or not ?
To: Tobias C. Berner 
Cc: 


---> It's x11/kde (
https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6/x11/kde6
<https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6/x11/kde>

I suspect that x11/kde6 will compile kde6 for x11,not for wayland. Are
you sure that it includes the necessary wayland packages ? I want 
to run

kde 6 on wayland,not on x11.

On Mon, Jul 22, 2024 at 2:24 PM Tobias C. Berner 
wrote:


Moin moin

Please use poudriere. I will not look into other compilation 
failures.


mfg Tobias

On Mon, 22 Jul 2024 at 14:17, Mario Marietto 
wrote:


[image: Istantanea_2024-07-22_14-16-04.png]

On Mon, Jul 22, 2024 at 2:11 PM Tobias C. Berner 


wrote:


Moin moin

The issue is that the kf5-packages you have installed come from 
main

and not from the new ports tree.
You can pkg-delete them first, and then have them reinstalled from
the new ports tree. There they are
configured to be co-installable with the kf6-variants.


Here's a good start to using poudriere:
https://docs.freebsd.org/en/books/handbook/ports/#ports-poudriere


mfg Tobias

On Mon, 22 Jul 2024 at 14:07, Mario Marietto 


wrote:


> or cd into it and run make...

that's wrong :

[image: Istantanea_2024-07-22_14-05-17.png]

/never used poudriere/ ; I don't know how to use it.


On Mon, Jul 22, 2024 at 1:44 PM Mario Marietto <
marietto2...@gmail.com> wrote:


What's the kde 6 meta port that I should make as the first one ?
I've compiled the plasma6-plasma port,but when it finished,it 
didn't start

the compilation of the dependencies. I can't compile any port.

On Mon, Jul 22, 2024 at 11:34 AM Tobias C. Berner <
tcber...@gmail.com> wrote:


Moin omin

Add it as a poudriere ports tree and build the package..., or cd
into it and run make...

As to your error with my script, well, I assume you don't have a
/memory - tmpfs :)
  always read and adapt scripts to your situation, don't blindly
run them...

mfg Tobias

On Mon, 22 Jul 2024 at 09:40, Mario Marietto <
marietto2...@gmail.com> wrote:


Hello.

I've downloaded the ports tree. What should I do now ? How 
can I
install kde 6 starting from the ports tree that you gave to 
me ?


On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner <
tcber...@gmail.com> wrote:


Moin moin

No I'm not contradicting myself, it was probably just not
clearly stated... :) -- as I said, they conflict, as they 
install the same

desktop in different versions...
So, don't install plasma5 if you want to use plasma6 -- the 
only

port that might be needed of plasma5-plasma-integration.
If you want to try to use plasma6 and try to get wayland up,
make sure to remove plasma5* and just install the 
plasma6-plasma

package.

I really recommend to use this tree instead of main:

https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6


You can then create a shell-script ala

###
#!/bin/sh
export QT_DEBUG_PLUGINS=1
# export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
export WAYLAND_DEBUG=1
# export XDG_SESSION_TYPE=wayland

ck-launch-session dbus-run-session truss
/usr/local/bin/startplasma-wayland >& /memory/startplasma.log


to try to run plasma... you likely get an output like

###

[...]
qt.core.library: 
"/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded library

Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin 
"wayland" in "" even though it was found.
qt.core.library: 
"/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
library

qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is 
needed to load the Qt xcb platform plugin.

[...]

###
before it fails :/

mfg Tobias

On Sun, 21 Jul 2024 at 14:05, Mario Marietto <
marietto2...@gmail.com> wrote:

---> You should not install any plasma5 components that 
are not
pulled in by plasma6 -- they conflict, as they are both 
the KDE Desktop...
and therefore share files and services :) -- so stick to 
one version.


We can't stick to one version if plasma5 an

Re: KDE 6 + Wayland : it works or not ?

[Mario Marietto]

stem time zone: please check your system
> configuration.
> > kwin_screencast: Failed to connect PipeWire context
> > No backend specified, automatically choosing drm
> > Unable to determine system time zone: please check your system
> configuration.
> > kwin_screencast: Failed to connect PipeWire context
> > No backend specified, automatically choosing drm
> > Unable to determine system time zone: please check your system
> configuration.
> > kwin_screencast: Failed to connect PipeWire context
> > No backend specified, automatically choosing drm
> > Unable to determine system time zone: please check your system
> configuration.
> > kwin_screencast: Failed to connect PipeWire context
> >
> > No backend specified, automatically choosing drm
> >
> > Unable to determine system time zone: please check your system
> configuration.
> > kwin_screencast: Failed to connect PipeWire context
> > org.kde.startup: "kdeinit5_shutdown" QList() exited with code 255
> > Initializing
> "/usr/local/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_style.so"
> > startplasma-wayland: Shutting down...
> > startplasmacompositor: Shutting down...
> > startplasmacompositor: Done.
> >
> > A connection to the bus can't be made
> >
> > /usr/local/bin/xrdb: Connection refused
> > /usr/local/bin/xrdb: Can't open display ':0'
> > /usr/local/bin/xsetroot:  unable to open display ':0'
> >
> > Initializing
> "/usr/local/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_mouse.so"
> > kcm_mouse: Not able to select appropriate backend.
> >
> > Maybe they can be fixed using the proper parameters. Can someone help me
> ?
> > thanks.
> >
> >
> > On /etc/rc.conf I have added : dbus_enable="YES" and DBUS is running.
> >
> > Infact keeping intact all those parameters and changing only this line :
> >
> > ck-launch-session dbus-run-session startplasma-wayland
> >
> >
> > with this :
> >
> > ck-launch-session dbus-run-session wayfire
> >
> >
> > wayland + wayfire start like a charme. So,Wayland is ready to go. Logic
> > wants that the problems that we see are related to X11 and / or KDE6
> >
> >
> > On Mon, Jul 22, 2024 at 7:17 PM Mario Marietto 
> > wrote:
> >
> >> Hello.
> >>
> >> I've fixed the compilation error. Now I would like to fix the error
> inside
> >> your script. I've added tmpfs,but I get it anyway.
> >>
> >> [image: Istantanea_2024-07-22_19-16-07.png]
> >> [image: Istantanea_2024-07-22_19-16-41.png]
> >>
> >> On Mon, Jul 22, 2024 at 5:36 PM Mario Marietto 
> >> wrote:
> >>
> >>> I'm not sure if poudriere will fix that bug (that I saw every time I
> have
> >>> restarted the compilation using an earlier version of the vm). I
> suspect
> >>> that learning poudriere can't help me and it is a waste of time.
> >>>
> >>> On Mon, Jul 22, 2024 at 3:16 PM Tobias C. Berner 
> >>> wrote:
> >>>
> >>>> It builds for both wayland and x11.
> >>>>
> >>>> Mfg Tobias
> >>>>
> >>>> -- Forwarded message -
> >>>> Von: Mario Marietto 
> >>>> Date: Mo., 22. Juli 2024, 14:53
> >>>> Subject: Re: KDE 6 + Wayland : it works or not ?
> >>>> To: Tobias C. Berner 
> >>>> Cc: 
> >>>>
> >>>>
> >>>> ---> It's x11/kde (
> >>>>
> https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6/x11/kde6
> >>>> <
> https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6/x11/kde
> >
> >>>>
> >>>> I suspect that x11/kde6 will compile kde6 for x11,not for wayland. Are
> >>>> you sure that it includes the necessary wayland packages ? I want to
> run
> >>>> kde 6 on wayland,not on x11.
> >>>>
> >>>> On Mon, Jul 22, 2024 at 2:24 PM Tobias C. Berner 
> >>>> wrote:
> >>>>
> >>>>> Moin moin
> >>>>>
> >>>>> Please use poudriere. I will not look into other compilation
> failures.
> >>>>>
> >>>>> mfg Tobias
> >>>>>
> >>>>> On Mon, 22 Jul 2024 at 14:17, Mario Marietto  >
> >>>>> wrote:
> >>>>>
> >>>>>> [image: Istantanea_2024-07-22_14-16-04.png]
> >>>>>

Re: KDE 6 + Wayland : it works or not ?

[Jesper Schmitz Mouridsen]

bus-daemon[1023]: [session uid=1001 pid=1023] Activating service
name='org.gtk.vfs.UDisks2VolumeMonitor' requested by ':1.6' (uid=1001
pid=1037 comm="")

dbus-daemon[1023]: [session uid=1001 pid=1023] Successfully activated
service 'org.gtk.vfs.UDisks2VolumeMonitor'

dbus-daemon[1023]: [session uid=1001 pid=1023] Activating service
name='org.gtk.vfs.MTPVolumeMonitor' requested by ':1.6' (uid=1001
pid=1037 comm="")

dbus-daemon[1023]: [session uid=1001 pid=1023] Successfully activated
service 'org.gtk.vfs.MTPVolumeMonitor'

dbus-daemon[1023]: [session uid=1001 pid=1023] Activating service
name='org.gtk.vfs.GPhoto2VolumeMonitor' requested by ':1.6' (uid=1001
pid=1037 comm="")

dbus-daemon[1023]: [session uid=1001 pid=1023] Successfully activated
service 'org.gtk.vfs.GPhoto2VolumeMonitor'

(/usr/local/libexec/xdg-desktop-portal:1037):
xdg-desktop-portal-WARNING **: 15:03:41.496: Failed connect to
PipeWire: Couldn't connect to PipeWire

(/usr/local/libexec/xdg-desktop-portal:1037):
xdg-desktop-portal-WARNING **: 15:03:41.501: Choosing kwallet.portal
for org.freedesktop.impl.portal.Secret via the deprecated UseIn key

(/usr/local/libexec/xdg-desktop-portal:1037):
xdg-desktop-portal-WARNING **: 15:03:41.501: The preferred method to
match portal implementations to desktop environments is to use the
portals.conf(5) configuration file

dbus-daemon[1023]: [session uid=1001 pid=1023] Successfully activated
service 'org.freedesktop.portal.Desktop'

Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
No backend specified, automatically choosing drm
Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context

No backend specified, automatically choosing drm

Unable to determine system time zone: please check your system configuration.
kwin_screencast: Failed to connect PipeWire context
org.kde.startup: "kdeinit5_shutdown" QList() exited with code 255
Initializing  
"/usr/local/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_style.so"
startplasma-wayland: Shutting down...
startplasmacompositor: Shutting down...
startplasmacompositor: Done.

A connection to the bus can't be made

/usr/local/bin/xrdb: Connection refused
/usr/local/bin/xrdb: Can't open display ':0'
/usr/local/bin/xsetroot:  unable to open display ':0'

Initializing  
"/usr/local/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_mouse.so"
kcm_mouse: Not able to select appropriate backend.

Maybe they can be fixed using the proper parameters. Can someone help me ?
thanks.


On /etc/rc.conf I have added : dbus_enable="YES" and DBUS is running.

Infact keeping intact all those parameters and changing only this line :

ck-launch-session dbus-run-session startplasma-wayland


with this :

ck-launch-session dbus-run-session wayfire


wayland + wayfire start like a charme. So,Wayland is ready to go. Logic
wants that the problems that we see are related to X11 and / or KDE6


On Mon, Jul 22, 2024 at 7:17 PM Mario Marietto 
wrote:


Hello.

I've fixed the compilation error. Now I would like to fix the error inside
your script. I've added tmpfs,but I get it anyway.

[image: Istantanea_2024-07-22_19-16-07.png]
[image: Istantanea_2024-07-22_19-16-41.png]

On Mon, Jul 22, 2024 at 5:36 PM Mario Marietto 
wrote:


I'm not sure if poudriere will fix that bug (that I saw every time I have
restarted the compilation using an earlier version of the vm). I suspect
t

Re: KDE 6 + Wayland : it works or not ?

[Tobias C. Berner]

Moin moin

The issue is that the kf5-packages you have installed come from main and
not from the new ports tree.
You can pkg-delete them first, and then have them reinstalled from the new
ports tree. There they are
configured to be co-installable with the kf6-variants.


Here's a good start to using poudriere:
https://docs.freebsd.org/en/books/handbook/ports/#ports-poudriere


mfg Tobias

On Mon, 22 Jul 2024 at 14:07, Mario Marietto  wrote:

> > or cd into it and run make...
>
> that's wrong :
>
> [image: Istantanea_2024-07-22_14-05-17.png]
>
> /never used poudriere/ ; I don't know how to use it.
>
>
> On Mon, Jul 22, 2024 at 1:44 PM Mario Marietto 
> wrote:
>
>> What's the kde 6 meta port that I should make as the first one ? I've
>> compiled the plasma6-plasma port,but when it finished,it didn't start the
>> compilation of the dependencies. I can't compile any port.
>>
>> On Mon, Jul 22, 2024 at 11:34 AM Tobias C. Berner 
>> wrote:
>>
>>> Moin omin
>>>
>>> Add it as a poudriere ports tree and build the package..., or cd into it
>>> and run make...
>>>
>>> As to your error with my script, well, I assume you don't have a /memory
>>> - tmpfs :)
>>>  always read and adapt scripts to your situation, don't blindly run
>>> them...
>>>
>>> mfg Tobias
>>>
>>> On Mon, 22 Jul 2024 at 09:40, Mario Marietto 
>>> wrote:
>>>
 Hello.

 I've downloaded the ports tree. What should I do now ? How can I
 install kde 6 starting from the ports tree that you gave to me ?

 On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner 
 wrote:

> Moin moin
>
> No I'm not contradicting myself, it was probably just not clearly
> stated... :) -- as I said, they conflict, as they install the same
> desktop in different versions...
> So, don't install plasma5 if you want to use plasma6 -- the only port
> that might be needed of plasma5-plasma-integration.
> If you want to try to use plasma6 and try to get wayland up, make sure
> to remove plasma5* and just install the plasma6-plasma
> package.
>
> I really recommend to use this tree instead of main:
> https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6
>
>
> You can then create a shell-script ala
>
> ###
> #!/bin/sh
> export QT_DEBUG_PLUGINS=1
> # export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
> export WAYLAND_DEBUG=1
> # export XDG_SESSION_TYPE=wayland
>
> ck-launch-session dbus-run-session truss
> /usr/local/bin/startplasma-wayland >& /memory/startplasma.log
> 
>
> to try to run plasma... you likely get an output like
>
> ###
>
> [...]
> qt.core.library: 
> "/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded 
> library
> Failed to create wl_display (No such file or directory)
> qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even 
> though it was found.
> qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
> library
> qt.qpa.xcb: could not connect to display :0
> qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to 
> load the Qt xcb platform plugin.
> [...]
>
> ###
> before it fails :/
>
> mfg Tobias
>
> On Sun, 21 Jul 2024 at 14:05, Mario Marietto 
> wrote:
>
>> ---> You should not install any plasma5 components that are not
>> pulled in by plasma6 -- they conflict, as they are both the KDE 
>> Desktop...
>> and therefore share files and services :) -- so stick to one version.
>>
>> We can't stick to one version if plasma5 and plasma6 components
>> conflict. You are contradicting yourself.
>>
>> If there are no conflicts, the output by :
>>
>> diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
>> /usr/ports/x11-wm/plasma6-kwin/pkg-plist
>>
>> should not have lines started with a single space. Single space of
>> unified diffs on top of lines means it's common with 2 files compared.
>>
>> There are many common lines such as:
>>
>> @@ -1,49 +1,275 @@ bin/kwin_x11
>> bin/kwin_wayland
>> bin/kwin_wayland_wrapper
>> bin/kwin_x11
>> -include/kwin_export.h
>> -include/kwinanimationeffect.h
>>
>> The "-" at the top of lines means it appears on the first file but
>> not on the second.
>>
>> Edit: Quote functionality does not do its work as intended. [image:
>> :(]There should be a single space before bin/kwin_wayland,
>> bin/kwin_wayland_wrapper and bin/kwin_x11 in the quoted example
>> above.
>>
>> On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto <
>> marietto2...@gmail.com> wrote:
>>
>>> Thanks.
>>>
>>> Can you write a small tutorial for us ? I've been working on this
>>> for months.
>>>
>>> On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner <
>>> tcber...@gmail.com> wrote:
>>>

Re: KDE 6 + Wayland : it works or not ?

[Mario Marietto]

> or cd into it and run make...

that's wrong :

[image: Istantanea_2024-07-22_14-05-17.png]

/never used poudriere/ ; I don't know how to use it.


On Mon, Jul 22, 2024 at 1:44 PM Mario Marietto 
wrote:

> What's the kde 6 meta port that I should make as the first one ? I've
> compiled the plasma6-plasma port,but when it finished,it didn't start the
> compilation of the dependencies. I can't compile any port.
>
> On Mon, Jul 22, 2024 at 11:34 AM Tobias C. Berner 
> wrote:
>
>> Moin omin
>>
>> Add it as a poudriere ports tree and build the package..., or cd into it
>> and run make...
>>
>> As to your error with my script, well, I assume you don't have a /memory
>> - tmpfs :)
>>  always read and adapt scripts to your situation, don't blindly run
>> them...
>>
>> mfg Tobias
>>
>> On Mon, 22 Jul 2024 at 09:40, Mario Marietto 
>> wrote:
>>
>>> Hello.
>>>
>>> I've downloaded the ports tree. What should I do now ? How can I install
>>> kde 6 starting from the ports tree that you gave to me ?
>>>
>>> On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner 
>>> wrote:
>>>
 Moin moin

 No I'm not contradicting myself, it was probably just not clearly
 stated... :) -- as I said, they conflict, as they install the same
 desktop in different versions...
 So, don't install plasma5 if you want to use plasma6 -- the only port
 that might be needed of plasma5-plasma-integration.
 If you want to try to use plasma6 and try to get wayland up, make sure
 to remove plasma5* and just install the plasma6-plasma
 package.

 I really recommend to use this tree instead of main:
 https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6


 You can then create a shell-script ala

 ###
 #!/bin/sh
 export QT_DEBUG_PLUGINS=1
 # export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
 export WAYLAND_DEBUG=1
 # export XDG_SESSION_TYPE=wayland

 ck-launch-session dbus-run-session truss
 /usr/local/bin/startplasma-wayland >& /memory/startplasma.log
 

 to try to run plasma... you likely get an output like

 ###

 [...]
 qt.core.library: 
 "/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded 
 library
 Failed to create wl_display (No such file or directory)
 qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even 
 though it was found.
 qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
 library
 qt.qpa.xcb: could not connect to display :0
 qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load 
 the Qt xcb platform plugin.
 [...]

 ###
 before it fails :/

 mfg Tobias

 On Sun, 21 Jul 2024 at 14:05, Mario Marietto 
 wrote:

> ---> You should not install any plasma5 components that are not pulled
> in by plasma6 -- they conflict, as they are both the KDE Desktop... and
> therefore share files and services :) -- so stick to one version.
>
> We can't stick to one version if plasma5 and plasma6 components
> conflict. You are contradicting yourself.
>
> If there are no conflicts, the output by :
>
> diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
> /usr/ports/x11-wm/plasma6-kwin/pkg-plist
>
> should not have lines started with a single space. Single space of
> unified diffs on top of lines means it's common with 2 files compared.
>
> There are many common lines such as:
>
> @@ -1,49 +1,275 @@ bin/kwin_x11
> bin/kwin_wayland
> bin/kwin_wayland_wrapper
> bin/kwin_x11
> -include/kwin_export.h
> -include/kwinanimationeffect.h
>
> The "-" at the top of lines means it appears on the first file but not
> on the second.
>
> Edit: Quote functionality does not do its work as intended. [image:
> :(]There should be a single space before bin/kwin_wayland,
> bin/kwin_wayland_wrapper and bin/kwin_x11 in the quoted example above.
>
> On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto <
> marietto2...@gmail.com> wrote:
>
>> Thanks.
>>
>> Can you write a small tutorial for us ? I've been working on this for
>> months.
>>
>> On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
>> wrote:
>>
>>> Moin moin
>>>
>>> You should not install any plasma5 components that are not pulled in
>>> by plasma6 -- they conflict, as they are both the KDE Desktop... and
>>> therefore share files and services :) -- so stick to one version.
>>>
>>>
>>> I have not yet got the plasma6-wayland session working on my end
>>> though -- I can start the plasma-desktop inside a running wayland
>>> compositor, but I cannot bring up kwin as compositor.
>>>
>>>
>>> mfg Tobias
>>>
>>> On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
>>> wrote:
>>> >
>>> > Hello.
>>> >

Re: KDE 6 + Wayland : it works or not ?

[Tobias C. Berner]

Moin moin

It's x11/kde (
https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6/x11/kde
).

If you have issues with manual compilation, please move to using poudriere.
It will make life much easier for you.


mfg Tobias

On Mon, 22 Jul 2024 at 13:44, Mario Marietto  wrote:

> What's the kde 6 meta port that I should make as the first one ? I've
> compiled the plasma6-plasma port,but when it finished,it didn't start the
> compilation of the dependencies. I can't compile any port.
>
> On Mon, Jul 22, 2024 at 11:34 AM Tobias C. Berner 
> wrote:
>
>> Moin omin
>>
>> Add it as a poudriere ports tree and build the package..., or cd into it
>> and run make...
>>
>> As to your error with my script, well, I assume you don't have a /memory
>> - tmpfs :)
>>  always read and adapt scripts to your situation, don't blindly run
>> them...
>>
>> mfg Tobias
>>
>> On Mon, 22 Jul 2024 at 09:40, Mario Marietto 
>> wrote:
>>
>>> Hello.
>>>
>>> I've downloaded the ports tree. What should I do now ? How can I install
>>> kde 6 starting from the ports tree that you gave to me ?
>>>
>>> On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner 
>>> wrote:
>>>
 Moin moin

 No I'm not contradicting myself, it was probably just not clearly
 stated... :) -- as I said, they conflict, as they install the same
 desktop in different versions...
 So, don't install plasma5 if you want to use plasma6 -- the only port
 that might be needed of plasma5-plasma-integration.
 If you want to try to use plasma6 and try to get wayland up, make sure
 to remove plasma5* and just install the plasma6-plasma
 package.

 I really recommend to use this tree instead of main:
 https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6


 You can then create a shell-script ala

 ###
 #!/bin/sh
 export QT_DEBUG_PLUGINS=1
 # export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
 export WAYLAND_DEBUG=1
 # export XDG_SESSION_TYPE=wayland

 ck-launch-session dbus-run-session truss
 /usr/local/bin/startplasma-wayland >& /memory/startplasma.log
 

 to try to run plasma... you likely get an output like

 ###

 [...]
 qt.core.library: 
 "/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded 
 library
 Failed to create wl_display (No such file or directory)
 qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even 
 though it was found.
 qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
 library
 qt.qpa.xcb: could not connect to display :0
 qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load 
 the Qt xcb platform plugin.
 [...]

 ###
 before it fails :/

 mfg Tobias

 On Sun, 21 Jul 2024 at 14:05, Mario Marietto 
 wrote:

> ---> You should not install any plasma5 components that are not pulled
> in by plasma6 -- they conflict, as they are both the KDE Desktop... and
> therefore share files and services :) -- so stick to one version.
>
> We can't stick to one version if plasma5 and plasma6 components
> conflict. You are contradicting yourself.
>
> If there are no conflicts, the output by :
>
> diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
> /usr/ports/x11-wm/plasma6-kwin/pkg-plist
>
> should not have lines started with a single space. Single space of
> unified diffs on top of lines means it's common with 2 files compared.
>
> There are many common lines such as:
>
> @@ -1,49 +1,275 @@ bin/kwin_x11
> bin/kwin_wayland
> bin/kwin_wayland_wrapper
> bin/kwin_x11
> -include/kwin_export.h
> -include/kwinanimationeffect.h
>
> The "-" at the top of lines means it appears on the first file but not
> on the second.
>
> Edit: Quote functionality does not do its work as intended. [image:
> :(]There should be a single space before bin/kwin_wayland,
> bin/kwin_wayland_wrapper and bin/kwin_x11 in the quoted example above.
>
> On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto <
> marietto2...@gmail.com> wrote:
>
>> Thanks.
>>
>> Can you write a small tutorial for us ? I've been working on this for
>> months.
>>
>> On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
>> wrote:
>>
>>> Moin moin
>>>
>>> You should not install any plasma5 components that are not pulled in
>>> by plasma6 -- they conflict, as they are both the KDE Desktop... and
>>> therefore share files and services :) -- so stick to one version.
>>>
>>>
>>> I have not yet got the plasma6-wayland session working on my end
>>> though -- I can start the plasma-desktop inside a running wayland
>>> compositor, but I cannot bring up kwin as compositor.
>>>
>>>
>>> mfg Tobias
>>>
>>> On Sat, 20 Jul 2024 

Re: KDE 6 + Wayland : it works or not ?

[Mario Marietto]

What's the kde 6 meta port that I should make as the first one ? I've
compiled the plasma6-plasma port,but when it finished,it didn't start the
compilation of the dependencies. I can't compile any port.

On Mon, Jul 22, 2024 at 11:34 AM Tobias C. Berner 
wrote:

> Moin omin
>
> Add it as a poudriere ports tree and build the package..., or cd into it
> and run make...
>
> As to your error with my script, well, I assume you don't have a /memory -
> tmpfs :)
>  always read and adapt scripts to your situation, don't blindly run them...
>
> mfg Tobias
>
> On Mon, 22 Jul 2024 at 09:40, Mario Marietto 
> wrote:
>
>> Hello.
>>
>> I've downloaded the ports tree. What should I do now ? How can I install
>> kde 6 starting from the ports tree that you gave to me ?
>>
>> On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner 
>> wrote:
>>
>>> Moin moin
>>>
>>> No I'm not contradicting myself, it was probably just not clearly
>>> stated... :) -- as I said, they conflict, as they install the same
>>> desktop in different versions...
>>> So, don't install plasma5 if you want to use plasma6 -- the only port
>>> that might be needed of plasma5-plasma-integration.
>>> If you want to try to use plasma6 and try to get wayland up, make sure
>>> to remove plasma5* and just install the plasma6-plasma
>>> package.
>>>
>>> I really recommend to use this tree instead of main:
>>> https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6
>>>
>>>
>>> You can then create a shell-script ala
>>>
>>> ###
>>> #!/bin/sh
>>> export QT_DEBUG_PLUGINS=1
>>> # export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
>>> export WAYLAND_DEBUG=1
>>> # export XDG_SESSION_TYPE=wayland
>>>
>>> ck-launch-session dbus-run-session truss
>>> /usr/local/bin/startplasma-wayland >& /memory/startplasma.log
>>> 
>>>
>>> to try to run plasma... you likely get an output like
>>>
>>> ###
>>>
>>> [...]
>>> qt.core.library: 
>>> "/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded library
>>> Failed to create wl_display (No such file or directory)
>>> qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even 
>>> though it was found.
>>> qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
>>> library
>>> qt.qpa.xcb: could not connect to display :0
>>> qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load 
>>> the Qt xcb platform plugin.
>>> [...]
>>>
>>> ###
>>> before it fails :/
>>>
>>> mfg Tobias
>>>
>>> On Sun, 21 Jul 2024 at 14:05, Mario Marietto 
>>> wrote:
>>>
 ---> You should not install any plasma5 components that are not pulled
 in by plasma6 -- they conflict, as they are both the KDE Desktop... and
 therefore share files and services :) -- so stick to one version.

 We can't stick to one version if plasma5 and plasma6 components
 conflict. You are contradicting yourself.

 If there are no conflicts, the output by :

 diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
 /usr/ports/x11-wm/plasma6-kwin/pkg-plist

 should not have lines started with a single space. Single space of
 unified diffs on top of lines means it's common with 2 files compared.

 There are many common lines such as:

 @@ -1,49 +1,275 @@ bin/kwin_x11
 bin/kwin_wayland
 bin/kwin_wayland_wrapper
 bin/kwin_x11
 -include/kwin_export.h
 -include/kwinanimationeffect.h

 The "-" at the top of lines means it appears on the first file but not
 on the second.

 Edit: Quote functionality does not do its work as intended. [image: 
 :(]There
 should be a single space before bin/kwin_wayland,
 bin/kwin_wayland_wrapper and bin/kwin_x11 in the quoted example above.

 On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto 
 wrote:

> Thanks.
>
> Can you write a small tutorial for us ? I've been working on this for
> months.
>
> On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
> wrote:
>
>> Moin moin
>>
>> You should not install any plasma5 components that are not pulled in
>> by plasma6 -- they conflict, as they are both the KDE Desktop... and
>> therefore share files and services :) -- so stick to one version.
>>
>>
>> I have not yet got the plasma6-wayland session working on my end
>> though -- I can start the plasma-desktop inside a running wayland
>> compositor, but I cannot bring up kwin as compositor.
>>
>>
>> mfg Tobias
>>
>> On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
>> wrote:
>> >
>> > Hello.
>> >
>> > Here at forums.freebsd.org we are trying to install KDE 6 with
>> Wayland,but we are failing. The thread is here :
>> >
>> >
>> https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
>> >
>> > Do you have some kind of suggestion to give to us ?
>> > The main problem seems to be that there is a conflict between
>> 

Re: KDE 6 + Wayland : it works or not ?

[Tobias C. Berner]

Moin omin

Add it as a poudriere ports tree and build the package..., or cd into it
and run make...

As to your error with my script, well, I assume you don't have a /memory -
tmpfs :)
 always read and adapt scripts to your situation, don't blindly run them...

mfg Tobias

On Mon, 22 Jul 2024 at 09:40, Mario Marietto  wrote:

> Hello.
>
> I've downloaded the ports tree. What should I do now ? How can I install
> kde 6 starting from the ports tree that you gave to me ?
>
> On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner 
> wrote:
>
>> Moin moin
>>
>> No I'm not contradicting myself, it was probably just not clearly
>> stated... :) -- as I said, they conflict, as they install the same
>> desktop in different versions...
>> So, don't install plasma5 if you want to use plasma6 -- the only port
>> that might be needed of plasma5-plasma-integration.
>> If you want to try to use plasma6 and try to get wayland up, make sure to
>> remove plasma5* and just install the plasma6-plasma
>> package.
>>
>> I really recommend to use this tree instead of main:
>> https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6
>>
>>
>> You can then create a shell-script ala
>>
>> ###
>> #!/bin/sh
>> export QT_DEBUG_PLUGINS=1
>> # export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
>> export WAYLAND_DEBUG=1
>> # export XDG_SESSION_TYPE=wayland
>>
>> ck-launch-session dbus-run-session truss
>> /usr/local/bin/startplasma-wayland >& /memory/startplasma.log
>> 
>>
>> to try to run plasma... you likely get an output like
>>
>> ###
>>
>> [...]
>> qt.core.library: 
>> "/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded library
>> Failed to create wl_display (No such file or directory)
>> qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even 
>> though it was found.
>> qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
>> library
>> qt.qpa.xcb: could not connect to display :0
>> qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load 
>> the Qt xcb platform plugin.
>> [...]
>>
>> ###
>> before it fails :/
>>
>> mfg Tobias
>>
>> On Sun, 21 Jul 2024 at 14:05, Mario Marietto 
>> wrote:
>>
>>> ---> You should not install any plasma5 components that are not pulled
>>> in by plasma6 -- they conflict, as they are both the KDE Desktop... and
>>> therefore share files and services :) -- so stick to one version.
>>>
>>> We can't stick to one version if plasma5 and plasma6 components
>>> conflict. You are contradicting yourself.
>>>
>>> If there are no conflicts, the output by :
>>>
>>> diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
>>> /usr/ports/x11-wm/plasma6-kwin/pkg-plist
>>>
>>> should not have lines started with a single space. Single space of
>>> unified diffs on top of lines means it's common with 2 files compared.
>>>
>>> There are many common lines such as:
>>>
>>> @@ -1,49 +1,275 @@ bin/kwin_x11
>>> bin/kwin_wayland
>>> bin/kwin_wayland_wrapper
>>> bin/kwin_x11
>>> -include/kwin_export.h
>>> -include/kwinanimationeffect.h
>>>
>>> The "-" at the top of lines means it appears on the first file but not
>>> on the second.
>>>
>>> Edit: Quote functionality does not do its work as intended. [image: :(]There
>>> should be a single space before bin/kwin_wayland,
>>> bin/kwin_wayland_wrapper and bin/kwin_x11 in the quoted example above.
>>>
>>> On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto 
>>> wrote:
>>>
 Thanks.

 Can you write a small tutorial for us ? I've been working on this for
 months.

 On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
 wrote:

> Moin moin
>
> You should not install any plasma5 components that are not pulled in
> by plasma6 -- they conflict, as they are both the KDE Desktop... and
> therefore share files and services :) -- so stick to one version.
>
>
> I have not yet got the plasma6-wayland session working on my end
> though -- I can start the plasma-desktop inside a running wayland
> compositor, but I cannot bring up kwin as compositor.
>
>
> mfg Tobias
>
> On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
> wrote:
> >
> > Hello.
> >
> > Here at forums.freebsd.org we are trying to install KDE 6 with
> Wayland,but we are failing. The thread is here :
> >
> >
> https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
> >
> > Do you have some kind of suggestion to give to us ?
> > The main problem seems to be that there is a conflict between
> plasma5-kwin and plasma6-kwin ; some kde5 and kde6 packages are mixed and
> this creates some issues.
> > What should we do ?
> >
> > thanks.
> >
> > --
> > Mario.
>


 --
 Mario.

>>>
>>>
>>> --
>>> Mario.
>>>
>>
>
> --
> Mario.
>

Re: KDE 6 + Wayland : it works or not ?

[Mario Marietto]

# nano kde6 :

#!/bin/sh
export QT_DEBUG_PLUGINS=1
# export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
export WAYLAND_DEBUG=1
# export XDG_SESSION_TYPE=wayland

ck-launch-session dbus-run-session truss /usr/local/bin/startplasma-wayland
>& /memory/startplasma.log

I get this error :

./kde6: 7: Syntax error: Bad fd number

On Mon, Jul 22, 2024 at 9:39 AM Mario Marietto 
wrote:

> Hello.
>
> I've downloaded the ports tree. What should I do now ? How can I install
> kde 6 starting from the ports tree that you gave to me ?
>
> On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner 
> wrote:
>
>> Moin moin
>>
>> No I'm not contradicting myself, it was probably just not clearly
>> stated... :) -- as I said, they conflict, as they install the same
>> desktop in different versions...
>> So, don't install plasma5 if you want to use plasma6 -- the only port
>> that might be needed of plasma5-plasma-integration.
>> If you want to try to use plasma6 and try to get wayland up, make sure to
>> remove plasma5* and just install the plasma6-plasma
>> package.
>>
>> I really recommend to use this tree instead of main:
>> https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6
>>
>>
>> You can then create a shell-script ala
>>
>> ###
>> #!/bin/sh
>> export QT_DEBUG_PLUGINS=1
>> # export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
>> export WAYLAND_DEBUG=1
>> # export XDG_SESSION_TYPE=wayland
>>
>> ck-launch-session dbus-run-session truss
>> /usr/local/bin/startplasma-wayland >& /memory/startplasma.log
>> 
>>
>> to try to run plasma... you likely get an output like
>>
>> ###
>>
>> [...]
>> qt.core.library: 
>> "/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded library
>> Failed to create wl_display (No such file or directory)
>> qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even 
>> though it was found.
>> qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
>> library
>> qt.qpa.xcb: could not connect to display :0
>> qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load 
>> the Qt xcb platform plugin.
>> [...]
>>
>> ###
>> before it fails :/
>>
>> mfg Tobias
>>
>> On Sun, 21 Jul 2024 at 14:05, Mario Marietto 
>> wrote:
>>
>>> ---> You should not install any plasma5 components that are not pulled
>>> in by plasma6 -- they conflict, as they are both the KDE Desktop... and
>>> therefore share files and services :) -- so stick to one version.
>>>
>>> We can't stick to one version if plasma5 and plasma6 components
>>> conflict. You are contradicting yourself.
>>>
>>> If there are no conflicts, the output by :
>>>
>>> diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
>>> /usr/ports/x11-wm/plasma6-kwin/pkg-plist
>>>
>>> should not have lines started with a single space. Single space of
>>> unified diffs on top of lines means it's common with 2 files compared.
>>>
>>> There are many common lines such as:
>>>
>>> @@ -1,49 +1,275 @@ bin/kwin_x11
>>> bin/kwin_wayland
>>> bin/kwin_wayland_wrapper
>>> bin/kwin_x11
>>> -include/kwin_export.h
>>> -include/kwinanimationeffect.h
>>>
>>> The "-" at the top of lines means it appears on the first file but not
>>> on the second.
>>>
>>> Edit: Quote functionality does not do its work as intended. [image: :(]There
>>> should be a single space before bin/kwin_wayland,
>>> bin/kwin_wayland_wrapper and bin/kwin_x11 in the quoted example above.
>>>
>>> On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto 
>>> wrote:
>>>
 Thanks.

 Can you write a small tutorial for us ? I've been working on this for
 months.

 On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
 wrote:

> Moin moin
>
> You should not install any plasma5 components that are not pulled in
> by plasma6 -- they conflict, as they are both the KDE Desktop... and
> therefore share files and services :) -- so stick to one version.
>
>
> I have not yet got the plasma6-wayland session working on my end
> though -- I can start the plasma-desktop inside a running wayland
> compositor, but I cannot bring up kwin as compositor.
>
>
> mfg Tobias
>
> On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
> wrote:
> >
> > Hello.
> >
> > Here at forums.freebsd.org we are trying to install KDE 6 with
> Wayland,but we are failing. The thread is here :
> >
> >
> https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
> >
> > Do you have some kind of suggestion to give to us ?
> > The main problem seems to be that there is a conflict between
> plasma5-kwin and plasma6-kwin ; some kde5 and kde6 packages are mixed and
> this creates some issues.
> > What should we do ?
> >
> > thanks.
> >
> > --
> > Mario.
>


 --
 Mario.

>>>
>>>
>>> --
>>> Mario.
>>>
>>
>
> --
> Mario.
>


-- 
Mario.

Re: KDE 6 + Wayland : it works or not ?

[Mario Marietto]

Hello.

I've downloaded the ports tree. What should I do now ? How can I install
kde 6 starting from the ports tree that you gave to me ?

On Sun, Jul 21, 2024 at 8:38 PM Tobias C. Berner  wrote:

> Moin moin
>
> No I'm not contradicting myself, it was probably just not clearly
> stated... :) -- as I said, they conflict, as they install the same
> desktop in different versions...
> So, don't install plasma5 if you want to use plasma6 -- the only port that
> might be needed of plasma5-plasma-integration.
> If you want to try to use plasma6 and try to get wayland up, make sure to
> remove plasma5* and just install the plasma6-plasma
> package.
>
> I really recommend to use this tree instead of main:
> https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6
>
>
> You can then create a shell-script ala
>
> ###
> #!/bin/sh
> export QT_DEBUG_PLUGINS=1
> # export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
> export WAYLAND_DEBUG=1
> # export XDG_SESSION_TYPE=wayland
>
> ck-launch-session dbus-run-session truss
> /usr/local/bin/startplasma-wayland >& /memory/startplasma.log
> 
>
> to try to run plasma... you likely get an output like
>
> ###
>
> [...]
> qt.core.library: 
> "/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded library
> Failed to create wl_display (No such file or directory)
> qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in "" even 
> though it was found.
> qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so" loaded 
> library
> qt.qpa.xcb: could not connect to display :0
> qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load 
> the Qt xcb platform plugin.
> [...]
>
> ###
> before it fails :/
>
> mfg Tobias
>
> On Sun, 21 Jul 2024 at 14:05, Mario Marietto 
> wrote:
>
>> ---> You should not install any plasma5 components that are not pulled in
>> by plasma6 -- they conflict, as they are both the KDE Desktop... and
>> therefore share files and services :) -- so stick to one version.
>>
>> We can't stick to one version if plasma5 and plasma6 components conflict.
>> You are contradicting yourself.
>>
>> If there are no conflicts, the output by :
>>
>> diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
>> /usr/ports/x11-wm/plasma6-kwin/pkg-plist
>>
>> should not have lines started with a single space. Single space of
>> unified diffs on top of lines means it's common with 2 files compared.
>>
>> There are many common lines such as:
>>
>> @@ -1,49 +1,275 @@ bin/kwin_x11
>> bin/kwin_wayland
>> bin/kwin_wayland_wrapper
>> bin/kwin_x11
>> -include/kwin_export.h
>> -include/kwinanimationeffect.h
>>
>> The "-" at the top of lines means it appears on the first file but not on
>> the second.
>>
>> Edit: Quote functionality does not do its work as intended. [image: :(]There
>> should be a single space before bin/kwin_wayland,
>> bin/kwin_wayland_wrapper and bin/kwin_x11 in the quoted example above.
>>
>> On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto 
>> wrote:
>>
>>> Thanks.
>>>
>>> Can you write a small tutorial for us ? I've been working on this for
>>> months.
>>>
>>> On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
>>> wrote:
>>>
 Moin moin

 You should not install any plasma5 components that are not pulled in
 by plasma6 -- they conflict, as they are both the KDE Desktop... and
 therefore share files and services :) -- so stick to one version.


 I have not yet got the plasma6-wayland session working on my end
 though -- I can start the plasma-desktop inside a running wayland
 compositor, but I cannot bring up kwin as compositor.


 mfg Tobias

 On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
 wrote:
 >
 > Hello.
 >
 > Here at forums.freebsd.org we are trying to install KDE 6 with
 Wayland,but we are failing. The thread is here :
 >
 >
 https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
 >
 > Do you have some kind of suggestion to give to us ?
 > The main problem seems to be that there is a conflict between
 plasma5-kwin and plasma6-kwin ; some kde5 and kde6 packages are mixed and
 this creates some issues.
 > What should we do ?
 >
 > thanks.
 >
 > --
 > Mario.

>>>
>>>
>>> --
>>> Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>

-- 
Mario.

Re: KDE 6 + Wayland : it works or not ?

[Tobias C. Berner]

Moin moin

No I'm not contradicting myself, it was probably just not clearly stated...
:) -- as I said, they conflict, as they install the same
desktop in different versions...
So, don't install plasma5 if you want to use plasma6 -- the only port that
might be needed of plasma5-plasma-integration.
If you want to try to use plasma6 and try to get wayland up, make sure to
remove plasma5* and just install the plasma6-plasma
package.

I really recommend to use this tree instead of main:
https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6


You can then create a shell-script ala

###
#!/bin/sh
export QT_DEBUG_PLUGINS=1
# export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
export WAYLAND_DEBUG=1
# export XDG_SESSION_TYPE=wayland

ck-launch-session dbus-run-session truss /usr/local/bin/startplasma-wayland
>& /memory/startplasma.log


to try to run plasma... you likely get an output like

###

[...]
qt.core.library:
"/usr/local/lib/qt6/plugins/platforms/libqwayland-generic.so" loaded
library
Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland" in ""
even though it was found.
qt.core.library: "/usr/local/lib/qt6/plugins/platforms/libqxcb.so"
loaded library
qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to
load the Qt xcb platform plugin.
[...]

###
before it fails :/

mfg Tobias

On Sun, 21 Jul 2024 at 14:05, Mario Marietto  wrote:

> ---> You should not install any plasma5 components that are not pulled in
> by plasma6 -- they conflict, as they are both the KDE Desktop... and
> therefore share files and services :) -- so stick to one version.
>
> We can't stick to one version if plasma5 and plasma6 components conflict.
> You are contradicting yourself.
>
> If there are no conflicts, the output by :
>
> diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
> /usr/ports/x11-wm/plasma6-kwin/pkg-plist
>
> should not have lines started with a single space. Single space of unified
> diffs on top of lines means it's common with 2 files compared.
>
> There are many common lines such as:
>
> @@ -1,49 +1,275 @@ bin/kwin_x11
> bin/kwin_wayland
> bin/kwin_wayland_wrapper
> bin/kwin_x11
> -include/kwin_export.h
> -include/kwinanimationeffect.h
>
> The "-" at the top of lines means it appears on the first file but not on
> the second.
>
> Edit: Quote functionality does not do its work as intended. [image: :(]There
> should be a single space before bin/kwin_wayland, bin/kwin_wayland_wrapper
> and bin/kwin_x11 in the quoted example above.
>
> On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto 
> wrote:
>
>> Thanks.
>>
>> Can you write a small tutorial for us ? I've been working on this for
>> months.
>>
>> On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
>> wrote:
>>
>>> Moin moin
>>>
>>> You should not install any plasma5 components that are not pulled in
>>> by plasma6 -- they conflict, as they are both the KDE Desktop... and
>>> therefore share files and services :) -- so stick to one version.
>>>
>>>
>>> I have not yet got the plasma6-wayland session working on my end
>>> though -- I can start the plasma-desktop inside a running wayland
>>> compositor, but I cannot bring up kwin as compositor.
>>>
>>>
>>> mfg Tobias
>>>
>>> On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
>>> wrote:
>>> >
>>> > Hello.
>>> >
>>> > Here at forums.freebsd.org we are trying to install KDE 6 with
>>> Wayland,but we are failing. The thread is here :
>>> >
>>> >
>>> https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
>>> >
>>> > Do you have some kind of suggestion to give to us ?
>>> > The main problem seems to be that there is a conflict between
>>> plasma5-kwin and plasma6-kwin ; some kde5 and kde6 packages are mixed and
>>> this creates some issues.
>>> > What should we do ?
>>> >
>>> > thanks.
>>> >
>>> > --
>>> > Mario.
>>>
>>
>>
>> --
>> Mario.
>>
>
>
> --
> Mario.
>

Re: KDE 6 + Wayland : it works or not ?

[Mario Marietto]

---> You should not install any plasma5 components that are not pulled in
by plasma6 -- they conflict, as they are both the KDE Desktop... and
therefore share files and services :) -- so stick to one version.

We can't stick to one version if plasma5 and plasma6 components conflict.
You are contradicting yourself.

If there are no conflicts, the output by :

diff -u -p -N /usr/ports/x11-wm/plasma5-kwin/pkg-plist
/usr/ports/x11-wm/plasma6-kwin/pkg-plist

should not have lines started with a single space. Single space of unified
diffs on top of lines means it's common with 2 files compared.

There are many common lines such as:

@@ -1,49 +1,275 @@ bin/kwin_x11
bin/kwin_wayland
bin/kwin_wayland_wrapper
bin/kwin_x11
-include/kwin_export.h
-include/kwinanimationeffect.h

The "-" at the top of lines means it appears on the first file but not on
the second.

Edit: Quote functionality does not do its work as intended. [image: :(]There
should be a single space before bin/kwin_wayland, bin/kwin_wayland_wrapper
and bin/kwin_x11 in the quoted example above.

On Sat, Jul 20, 2024 at 11:10 PM Mario Marietto 
wrote:

> Thanks.
>
> Can you write a small tutorial for us ? I've been working on this for
> months.
>
> On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
> wrote:
>
>> Moin moin
>>
>> You should not install any plasma5 components that are not pulled in
>> by plasma6 -- they conflict, as they are both the KDE Desktop... and
>> therefore share files and services :) -- so stick to one version.
>>
>>
>> I have not yet got the plasma6-wayland session working on my end
>> though -- I can start the plasma-desktop inside a running wayland
>> compositor, but I cannot bring up kwin as compositor.
>>
>>
>> mfg Tobias
>>
>> On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
>> wrote:
>> >
>> > Hello.
>> >
>> > Here at forums.freebsd.org we are trying to install KDE 6 with
>> Wayland,but we are failing. The thread is here :
>> >
>> >
>> https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
>> >
>> > Do you have some kind of suggestion to give to us ?
>> > The main problem seems to be that there is a conflict between
>> plasma5-kwin and plasma6-kwin ; some kde5 and kde6 packages are mixed and
>> this creates some issues.
>> > What should we do ?
>> >
>> > thanks.
>> >
>> > --
>> > Mario.
>>
>
>
> --
> Mario.
>


-- 
Mario.

Re: KDE 6 + Wayland : it works or not ?

[Mario Marietto]

Thanks.

Can you write a small tutorial for us ? I've been working on this for
months.

On Sat, Jul 20, 2024 at 10:56 PM Tobias C. Berner 
wrote:

> Moin moin
>
> You should not install any plasma5 components that are not pulled in
> by plasma6 -- they conflict, as they are both the KDE Desktop... and
> therefore share files and services :) -- so stick to one version.
>
>
> I have not yet got the plasma6-wayland session working on my end
> though -- I can start the plasma-desktop inside a running wayland
> compositor, but I cannot bring up kwin as compositor.
>
>
> mfg Tobias
>
> On Sat, 20 Jul 2024 at 22:36, Mario Marietto 
> wrote:
> >
> > Hello.
> >
> > Here at forums.freebsd.org we are trying to install KDE 6 with
> Wayland,but we are failing. The thread is here :
> >
> >
> https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
> >
> > Do you have some kind of suggestion to give to us ?
> > The main problem seems to be that there is a conflict between
> plasma5-kwin and plasma6-kwin ; some kde5 and kde6 packages are mixed and
> this creates some issues.
> > What should we do ?
> >
> > thanks.
> >
> > --
> > Mario.
>


-- 
Mario.

Re: KDE 6 + Wayland : it works or not ?

[Tobias C. Berner]

Moin moin

You should not install any plasma5 components that are not pulled in
by plasma6 -- they conflict, as they are both the KDE Desktop... and
therefore share files and services :) -- so stick to one version.


I have not yet got the plasma6-wayland session working on my end
though -- I can start the plasma-desktop inside a running wayland
compositor, but I cannot bring up kwin as compositor.


mfg Tobias

On Sat, 20 Jul 2024 at 22:36, Mario Marietto  wrote:
>
> Hello.
>
> Here at forums.freebsd.org we are trying to install KDE 6 with Wayland,but we 
> are failing. The thread is here :
>
> https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/
>
> Do you have some kind of suggestion to give to us ?
> The main problem seems to be that there is a conflict between plasma5-kwin 
> and plasma6-kwin ; some kde5 and kde6 packages are mixed and  this creates 
> some issues.
> What should we do ?
>
> thanks.
>
> --
> Mario.

Re: Problem building cmake-core on newly upgraded system

[Jason E. Hale]

On Thu, Jul 18, 2024 at 7:52 AM Olivier  wrote:
>
> Hi,
>
> I recently upgraded an old system from 13.2 to 13.3 and now 14.1.
>
> When I tried to rebuild cmake-core, it failed with an error about libuv
> being 1.16 when 1.38 is expected.
>
> I did make sure that libuv is the most recent 1.48
>
> uname -a
> FreeBSD fbsd35.cs.ait.ac.th 14.1-RELEASE-p2 FreeBSD 14.1-RELEASE-p2 
> releng/14.1-n267685-dcdea9e8623e GENERIC amd64
>
> pkg info | grep libuv
> libuv-1.48.0   Multi-platform support library with a focus on 
> asynchronous I/O
>
> The error is:
> -- Could NOT find LibUV: Found unsuitable version "1.16.1", but required is 
> at least "1.28.0" (found /usr/local/lib/libuv.so)
> CMake Error at Source/Modules/CMakeBuildUtilities.cmake:334 (message):
>   CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!
> Call Stack (most recent call first):
>   CMakeLists.txt:442 (include)
>
> It was triggered by
> work/cmake-3.29.6/Source/Modules/CMakeBuildUtilities.cmake line 331
> find_package(LibUV 1.28.0)
>
> Best regards,
>
> Olivier
>

You asked this same question on this list a little over a month ago,
but since you never responded to my solution, I'll repeat it here with
some more context:

This looks like bug 272895 [1].

You probably still have some leftover bits from an old libuv
installation on your system. If you have any
${LOCALBASE}/include/uv-\*.h files, please remove them manually. The
headers are now supposed to be in the ${LOCALBASE}/include/uv
directory. There should still be a ${LOCALBASE}/include/uv.h, however.

Having these leftover includes is problem because FindLibUV.cmake
first checks for ${LibUV_INCLUDE_DIR}/uv-version.h and then for
${LibUV_INCLUDE_DIR}/uv/version.h to determine the version of libuv,
where ${LibUV_INCLUDE_DIR} is normally ${LOCALBASE}/include. The
former is the older format and it would probably make more sense to
first check for the newer format. I'll probably patch FindLibUV.cmake
to do just that with CMake 3.30.1, since this seems to be a recurring
problem with some users who don't build in a clean environment, but
those old files really shouldn't be there.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272895

- Jason

Re: Problem building cmake-core on newly upgraded system

[Tobias C. Berner]

Moin moin

How are you building the port? Are you using poudriere or an unclean
environment?


mfg Tobias

On Thu, 18 Jul 2024 at 13:52, Olivier  wrote:
>
> Hi,
>
> I recently upgraded an old system from 13.2 to 13.3 and now 14.1.
>
> When I tried to rebuild cmake-core, it failed with an error about libuv
> being 1.16 when 1.38 is expected.
>
> I did make sure that libuv is the most recent 1.48
>
> uname -a
> FreeBSD fbsd35.cs.ait.ac.th 14.1-RELEASE-p2 FreeBSD 14.1-RELEASE-p2 
> releng/14.1-n267685-dcdea9e8623e GENERIC amd64
>
> pkg info | grep libuv
> libuv-1.48.0   Multi-platform support library with a focus on 
> asynchronous I/O
>
> The error is:
> -- Could NOT find LibUV: Found unsuitable version "1.16.1", but required is 
> at least "1.28.0" (found /usr/local/lib/libuv.so)
> CMake Error at Source/Modules/CMakeBuildUtilities.cmake:334 (message):
>   CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!
> Call Stack (most recent call first):
>   CMakeLists.txt:442 (include)
>
> It was triggered by
> work/cmake-3.29.6/Source/Modules/CMakeBuildUtilities.cmake line 331
> find_package(LibUV 1.28.0)
>
> Best regards,
>
> Olivier
>
> --

Re: Qt-free VLC library

[Tobias C. Berner]

Moin moin

Sorry, I have been behind my mails for a while, and they just keep piling on :D
I will update the vlc package to not depend on Qt -- and then notify
bcooksley to rebuild the docker image.


mfg Tobias

On Wed, 17 Jul 2024 at 09:29, David Jarvie  wrote:
>
> As a follow-up to the kde-devel thread entitled:
>
> Re: KDE Gear projects with failing CI (master) (9 July 2024)
>
> I wonder whether you can provide any update as to whether it is likely that 
> VLC libraries will be able to be provided for FreeBSD?
>
> Thanks.
>
> On 10 July 2024 12:59:50 BST, Ben Cooksley  wrote:
> > On Wed, Jul 10, 2024 at 11:53 AM David Jarvie  wrote:
> >
> > > On Tuesday, 9 July 2024 23:57:09 BST Albert Astals Cid wrote:
> > > > Please work on fixing them, otherwise i will remove the failing CI jobs
> > > on
> > > > their 4th failing week, it is very important that CI is passing for
> > > multiple
> > > > reasons.
> > > >
> > > > Good news: 4 repositories have been fixed
> > > >
> > > >
> > > > Bad news: 1 repository is still failing, 3+ repositories have started
> > > > failing
> > >
> > > > kalarm - NEW
> > > >  * https://invent.kde.org/pim/kalarm/-/pipelines/731010
> > > >   * New dependencies where introduced the wrong way
> > >
> > > I've already asked on this list how to add the CI dependency, but I need
> > > an
> > > answer to know how to fix this.
> > >
> >
> > The Linux side of this is now sorted.
> >
> > Tobias, for FreeBSD is there any reason we're not able to get a Qt 5 free
> > VLC?
> >
> > > --
> > > David Jarvie.
> > > KDE developer, KAlarm author.
> > >
> >
> > Thanks,
> > Ben
>
> --
> David Jarvie
> KAlarm author, KDE developer

Re: dolphin-devel out of date and question about testing plasma 6 applications

[Tobias C. Berner]

Moin moin

Thanks for testing!
We have a branch on github that contains more  up-to-date versions of
the  packages (and cleaning out some of the Qt5 bits).

https://github.com/freebsd/freebsd-ports-kde/tree/kde-it_goes_to_6

I personally use that branch to dog-food the update -- it is what will
be merged to main at some later point in time.



mfg Tobias

On Sun, 14 Jul 2024 at 09:20,  wrote:
>
> Been testing plasma 6 in preparation for the upcoming switch over and 
> observed Dolphin has been crashing on launch since I started testing a couple 
> months ago.
>
> Pretty sure it's just related to the package not being updated since 
> "2024-03-01". It is a testing package though so I don't have an expectation 
> of it being maintained / supported.
>
> Just wondering if these devel packages will be updated again before plasma 6 
> goes live or if it's a better idea to use the kde-src build system to test 
> plasma6 applications and just rely on ports for the base plasma. Which is 
> best?
>
> Thanks,
>
> Brad

Re: [package - 132amd64-default][deskutils/plasma6-xdg-desktop-portal-kde] Failed for plasma6-xdg-desktop-portal-kde-6.1.1 in build

[Jason E. Hale]

On Fri, Jun 28, 2024 at 10:30 PM  wrote:
> /wrkdirs/usr/ports/deskutils/plasma6-xdg-desktop-portal-kde/work/xdg-desktop-portal-kde-6.1.1/src/inputcapture.cpp:229:18:
>  error: no member named 'transform' in namespace 'std::ranges'
> std::ranges::transform(qGuiApp->screens(), 
> std::back_inserter(screenGeometries), ::geometry);
> ~^
> 1 error generated.

ranges::transform was implemented in llvm15. Very much not worth
fixing for 13.2 (with llvm 14) since it is EOL today.

Re: Plasma 6.1 ?

[Tobias C. Berner]

Moin moin

Done in

* acd77861e62460839d395782cbc7a3924668b36e KDE: update KDE Plasma Desktop to 6.1
* 3a9a604e88b3f50e9add98319c7205b70ddff21bKDE: remove patches
required to add support for Plasma 6.0
* 2144c48273eb65a095e19391857dc88e86e8f992  KDE: KDE Plasma 6.1.1,
Bugfix Release for June


I'm not going to merge it to Q2, as Q3 is only a week away.

mfg Tobias

Re: Plasma 6.1 ?

[Tobias C. Berner]

Moin moin


Yes, the update will land shortly


mfg Tobias

On Wed, 26 Jun 2024 at 20:12, Jan Beich  wrote:
>
> Do you plan to update plasma6-* ports to 6.1 before 2024Q3 branches ?
> If so, please, remove the following workarounds during the update:
>
> - x11-toolkits/como/files/patch-plasma-6.0
> - x11-wm/theseus-ship/files/patch-plasma-6.0
> - x11/kdisplay/files/patch-plasma-6.0
>
> See also
> - https://kde.org/announcements/plasma/6/6.1.0/
> - https://kde.org/announcements/plasma/6/6.1.1/
>
> Note, ignore Wayland for now due to
> - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279753
> - https://github.com/winft/theseus-ship/issues/9
> - https://github.com/freebsd/drm-kmod/issues/278 (explicit sync)

Re: Problem building cmake-core on FreeBSD 13.3

[Jason E. Hale]

On Wed, Jun 5, 2024 at 6:22 AM Olivier  wrote:
>
> Hi,
>
> I have a system that I try to upgrade from 13.2 to 13.3
>
> FreeBSD fbsd35.cs.ait.ac.th 13.3-RELEASE-p2 FreeBSD 13.3-RELEASE-p2 
> releng/13.3-n257433-be4f1894ef39 GENERIC amd64
>
> When making cmake-core, I get the following error:
>
> -- Found JsonCpp: /usr/local/lib/libjsoncpp.so (found suitable version 
> "1.9.5", minimum required is "1.6.0")
> -- Could NOT find LibUV: Found unsuitable version "1.16.1", but required is 
> at least "1.28.0" (found /usr/local/lib/libuv.so)
> CMake Error at Source/Modules/CMakeBuildUtilities.cmake:332 (message):
>   CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!
> Call Stack (most recent call first):
>   CMakeLists.txt:441 (include)
>
>
> -- Configuring incomplete, errors occurred!
> -
> Error when bootstrapping CMake:
> Problem while running initial CMake
> -
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to k...@freebsd.org [maintainer] and attach the
> "/usr/ports/devel/cmake-core/work/cmake-3.28.3/config.log" including the
> output of the failure of your make command. Also, it might be a good idea to
> provide an overview of all packages installed on your system (e.g. a
> /usr/local/sbin/pkg-static info -g -Ea).
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/devel/cmake-core
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/cmake-core
>
> I checked that LibUV is at the right version:
>
> pkg info |grep -i libuv
> libuv-1.48.0   Multi-platform support library with a focus on 
> asynchronous I/O
>
> There is no /usr/ports/devel/cmake-core/work/cmake-3.28.3/config.log
> but I have attached the packages list and 
> ./work/cmake-3.28.3/CMakeFiles/CMakeError.log
>
> Best regards,
>
> Olivier
> --

This looks like bug 272895 [1].

You probably still have some leftover bits from an old libuv
installation on your system. If you have any
${LOCALBASE}/include/uv-\*.h files, please remove them manually. The
headers are now in the ${LOCALBASE}/include/uv directory. There should
still be a ${LOCALBASE}/include/uv.h, however.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272895

- Jason

Re: www/qt5-webengine fails to compile

[William Bulley]

According to "Jason E. Hale"  on Wed, 06/05/24 at 01:31:
> 
> This looks like bugs 278279 [1] and 278633 [2] again. You will have to
> deinstall the currently installed version of www/qt5-webengine before
> attempting to rebuild.
> 
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278279
> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278633

Thanks!  That was the solution to the problem.

-- 
William Bulley
E-MAIL: w...@umich.edu

Re: www/qt5-webengine fails to compile

[Jason E. Hale]

On Tue, Jun 4, 2024 at 8:57 PM William Bulley  wrote:
>
> I also tried this:
>
>unix# make MAKE_JOBS_UNSAFE=yes install clean
>
> while in the www/qt5-webengine subdirectory of
> the /usr/ports directory of FreeBSD 14.0-STABLE.
>
> This is the error message I got both times:
>
> --- ../../libexec/QtWebEngineProcess ---
> c++ -B/usr/local/bin -Wl,--undefined-version -Wl,--as-needed 
> -fstack-protector-strong -pthread -Wl,-rpath,/usr/local/lib/qt5 
> -Wl,-rpath-link,/usr/local/lib/qt5 -o ../../libexec/QtWebEngineProcess 
> .obj/main.o   -L/usr/ports/www/qt5-webengine/work/.build/lib -L/usr/local/lib 
> /usr/local/lib/qt5/libQt5Gui.so /usr/local/lib/qt5/libQt5Core.so -lGL 
> /usr/local/lib/qt5/libQt5WebEngineCore.so /usr/local/lib/qt5/libQt5Quick.so 
> /usr/local/lib/qt5/libQt5QmlModels.so /usr/local/lib/qt5/libQt5WebChannel.so 
> /usr/local/lib/qt5/libQt5Qml.so /usr/local/lib/qt5/libQt5Network.so 
> /usr/local/lib/qt5/libQt5Gui.so /usr/local/lib/qt5/libQt5Positioning.so 
> /usr/local/lib/qt5/libQt5Core.so
> /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined 
> reference to `snappy::RawCompress(char const*, unsigned long, char*, unsigned 
> long*)'
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [../../libexec/QtWebEngineProcess] Error code 1
>
> make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/process
> 1 error
>
> make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/process
> *** [sub-process-make_first] Error code 2
>
> make[1]: stopped in /usr/ports/www/qt5-webengine/work/.build/src
> --- sub-webengine-make_first ---
> *** [sub-module-pro-make_first] Error code 6
>
> make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/webengine
> 1 error
>
> make[2]: stopped in /usr/ports/www/qt5-webengine/work/.build/src/webengine
> *** [sub-webengine-make_first] Error code 2
>
> make[1]: stopped in /usr/ports/www/qt5-webengine/work/.build/src
> --- sub-tools-qwebengine_convert_dict-make_first ---
> *** [sub-tools-qwebengine_convert_dict-make_first] Error code 6
>
> make[1]: stopped in /usr/ports/www/qt5-webengine/work/.build/src
> --- sub-pdf-make_first ---
> WARNING at the command-line "--args":1:1128: Build argument has no effect.
> use_qt=true init_stack_vars=false is_component_build=false is_shared=true 
> enable_debugallocation=false enable_media_remoting=false 
> enable_message_center=false enable_nacl=false enable_remoting=false 
> enable_reporting=false enable_resource_allowlist_generation=false 
> enable_swiftshader=false enable_swiftshader_vulkan=false 
> angle_enable_swiftshader=false enable_web_speech=false enable_widevine=true 
> forbid_non_component_debug_builds=false has_native_accessibility=false 
> safe_browsing_mode=0 skia_use_dawn=false toolkit_views=false 
> treat_warnings_as_errors=false use_allocator_shim=false use_allocator="none" 
> use_custom_libcxx=false chrome_pgo_phase=0 
> enable_hangout_services_extension=true optimize_webui=false 
> enable_js_type_check=false v8_use_external_startup_data=false 
> strip_absolute_paths_from_debug_symbols=false use_jumbo_build=true 
> jumbo_file_merge_limit=8 jumbo_build_excluded=["browser"] 
> enable_precompiled_headers=false is_official_build=true is_debug=false 
> symbol_level=0 blink_symbol_level=0 remove_v8base_debug_symbols=true 
> use_cups=false use_gio=false use_gnome_keyring=false use_udev=true 
> use_bundled_fontconfig=false use_sysroot=false enable_session_service=false 
> is_cfi=false use_ozone=true use_x11=false ozone_auto_platforms=false 
> ozone_platform_headless=false ozone_platform_external=true 
> ozone_platform="qt" 
> ozone_extra_path="/usr/ports/www/qt5-webengine/work/kde-qtwebengine-5.15.17p2/src/core/ozone/ozone_extra.gni"
>  use_gold=false use_lld=false is_clang=true clang_use_chrome_plugins=false 
> clang_use_default_sample_profile=false clang_base_path="/usr -B/usr" 
> custom_toolchain="/usr/ports/www/qt5-webengine/work/.build/src/toolchain:target"
>  host_toolchain="/usr/ports/www/qt5-webengine/work/.build/src/toolchain:host" 
> host_cpu="x64" pkg_config="pkg-config" 
> host_pkg_config="/usr/local/bin/pkg-config" use_system_zlib=true 
> use_system_minizip=true pdfium_use_system_zlib=true use_system_libpng=true 
> pdfium_use_system_libpng=true use_system_libjpeg=true 
> use_system_freetype=true use_system_harfbuzz=true use_glib=false 
> enable_basic_printing=true enable_print_preview=true use_dbus=true 
> use_udev=false use_nss_certs=false pdf_enable_v8=false pdf_enable_xfa=false 
> pdf_enable_xfa_bmp=false pdf_enable_xfa_gif=false pdf_enable_xfa_png=false 
> pdf_enable_xfa_tiff=false 
> qtwebengine_target="/usr/ports/www/qt5-webengine/work/.build/src/pdf/release:QtPdf"
>
>   
>   
>^
> The variable "use_bundled_fontconfig" was set as a build argument
> but never 

Re: [package - 132i386-quarterly][devel/qtcreator] Failed for qtcreator-12.0.2 in build

[Jason E. Hale]

I cherry-picked [1] and [2] into 2024Q2 to fix these.

There was a breaking change in the Qt >= 6.7.1 private API [3] that
previous versions of qtcreator did not account for.

[1] 
https://cgit.freebsd.org/ports/commit/?id=9e251d0efb9fab2729c2e777ce14fb96b13d6f35
[2] 
https://cgit.freebsd.org/ports/commit/?id=89f7441ae82f34dc8324655bfda2a7fe1a36c9ed
[3] 
https://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/io?h=6.7.1=22d1a437cb4431a3e7ca1bf8e3b6ba4290d0a0cf

Re: [package - main-i386-default][science/qt6-quick3dphysics] Failed for qt6-quick3dphysics-6.7.1 in patch

[Jason E. Hale]

All of these have been fixed in [1] and [2]. A typo in Mk/Uses/qt.mk
that I made when adding science/qt6-qtquick3dphysics resulted in it
being excluded from the devel/qt6 metaport, which is usually how I
test the qt6 ports in poudriere as it conveniently adds a dependency
on all of them, but obviously only when working properly.

[1] 
https://cgit.freebsd.org/ports/commit/?id=4b17f0c82bfeabcb0770ebc6aabbf8ace3e714af
[2] 
https://cgit.freebsd.org/ports/commit/?id=d91f6afc0d275f794e10c955bdace138bf5a0063
(cherry-pick of above to 2024Q2)

Re: git: cc268ca874a8 - main - net-im/telegram-desktop: bump PORTREVISION after qt5 update

[makc]

Folks,

I've seen this with a couple of kf5-/KDE ports and other Qt ports, so
telegram-desktop is not the only affected by this issue: when app requires
for runtime exactly the same version of Qt it was built against. I suspect
these ports rely on private Qt headers and they have to be rebuilt alongside
the Qt upgrade. poudriere rebuilds packages anyway, therefore the problem
can be easily solved by forced reinstall of the affected packages.

To improve experience of pkg users we could bump PORTREVISION after Qt
update, however bumping all Qt ports would be overkill. Any idea how can we
find out in advance which ports do need the PORTREVISION bump?

Max


> The branch main has been updated by vishwin:
> 
> URL: 
> https://cgit.FreeBSD.org/ports/commit/?id=cc268ca874a81aece7aadf066a671d2a94690d84
> 
> commit cc268ca874a81aece7aadf066a671d2a94690d84
> Author: Charlie Li 
> AuthorDate: 2024-04-05 18:29:47 +
> Commit: Charlie Li 
> CommitDate: 2024-04-05 18:31:56 +
> 
> net-im/telegram-desktop: bump PORTREVISION after qt5 update
> 
> Otherwise crashes because pkg(8) does not update this port/package:
> 
> Cannot mix incompatible Qt library (5.15.12) with this library (5.15.13)
> Abort (core dumped)
> ---
>  net-im/telegram-desktop/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net-im/telegram-desktop/Makefile 
> b/net-im/telegram-desktop/Makefile
> index ff549da08699..e3a6bb920554 100644
> --- a/net-im/telegram-desktop/Makefile
> +++ b/net-im/telegram-desktop/Makefile
> @@ -1,5 +1,6 @@
>  PORTNAME=telegram-desktop
>  DISTVERSION= 4.15.2
> +PORTREVISION=1
>  CATEGORIES=  net-im
>  MASTER_SITES=
> https://github.com/${GH_ACCOUNT}/${GH_PROJECT}/releases/download/v${DISTVERSION}/
>  DISTNAME=tdesktop-${DISTVERSION}-full
> 

Re: kdenlive

[Tobias C. Berner]

Moin moin

This sounds like you have the FILESHARE option off , which would add a
dependency on purpose. It might be that the option toggle in cmake was
changed, so it no longer deactivates the feature activation properly.


mfg Tobias

On Fri, 2 Feb 2024 at 17:10, Andrew Johnson  wrote:
>
> Does this mean I have to retrograde my system to KF5-5.92.0 to be able to 
> compile kdenlive?
>
> ===> kdenlive-23.08.4_1 depends on shared library: libQt5Svg.so - found 
> (/usr/local/lib/qt5/libQt5Svg.so)
> ===> kdenlive-23.08.4_1 depends on shared library: libQt5Widgets.so - found 
> (/usr/local/lib/qt5/libQt5Widgets.so)
> ===> kdenlive-23.08.4_1 depends on shared library: libQt5Xml.so - found 
> (/usr/local/lib/qt5/libQt5Xml.so)
> ===> Configuring for kdenlive-23.08.4_1
> ===> Performing out-of-source build
> /bin/mkdir -p /usr/ports/multimedia/kdenlive/work/.build
> -- The C compiler identification is Clang 14.0.5
> -- The CXX compiler identification is Clang 14.0.5
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Could NOT find KF5Purpose: found neither KF5PurposeConfig.cmake nor 
> kf5purpose-config.cmake
> CMake Error at 
> /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 
> (message):
> Could NOT find KF5 (missing: Purpose) (found suitable version "5.113.0",
> minimum required is "5.92.0")
> Call Stack (most recent call first):
> /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 
> (_FPHSA_FAILURE_MESSAGE)
> /usr/local/share/ECM/find-modules/FindKF5.cmake:93 
> (find_package_handle_standard_args)
> CMakeLists.txt:83 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/multimedia/kdenlive
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/multimedia/kdenlive

Re: [exp - 140amd64-default-build-as-user][graphics/gmic-qt] Failed for gmic-qt-3.3.3, 1 in configure

[Jason E. Hale]

On Sat, Jan 20, 2024 at 11:04 AM  wrote:
>
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
>
> Maintainer: k...@freebsd.org
> Log URL:
> https://pkg-status.freebsd.org/package19/data/140amd64-default-build-as-user/f99755cf7cc4/logs/gmic-qt-3.3.3,1.log
> Build URL:  
> https://pkg-status.freebsd.org/package19/build.html?mastername=140amd64-default-build-as-user=f99755cf7cc4
> Log:
>

< --snip-->

> ===
> ===
> = env: NO_DEPENDS=yes USER=nobody UID=65534 GID=65534
> ===>  Configuring for gmic-qt-3.3.3,1
> cp -f /wrkdirs/usr/ports/graphics/gmic-qt/work-none/CImg-v.3.3.3/CImg.h 
> /wrkdirs/usr/ports/graphics/gmic-qt/work-none/gmic-v.3.3.3/src
> cp -f /portdistfiles/KDE/gmic-qt/3.3.3/gmic_stdlib_community333.h 
> /wrkdirs/usr/ports/graphics/gmic-qt/work-none/gmic-v.3.3.3/src/gmic_stdlib_community.h
> cp: /portdistfiles/KDE/gmic-qt/3.3.3/gmic_stdlib_community333.h: No such file 
> or directory
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/graphics/gmic-qt

These graphics/gmic-qt* failures should be fixed now in [1]. My bad.

[1] 
https://cgit.freebsd.org/ports/commit/?id=93d219605f6b24813b161e968377542bc73dd18e

-Jason

Re: graphics/qt5-imageformats not building in 14.0-STABLE

[Jason E. Hale]

On Mon, Jan 8, 2024 at 3:57 AM William Bulley  wrote:
>
> I am attempting to build graphics/qt5-imageformats using
> portmaster on 14.0-STABLE.  The O/S is up-to-date as of
> 1/4/2024.  The ports are up-to-date as of 4/6/2024.
>
> Here are the errors that I get today:
>
> + -Wl,--undefined-version -Wl,--as-needed -fstack-protector-strong 
> -Wl,--no-undefined -pthread -Wl,-rpath,/usr/local/lib/qt5 -shared -o 
> libqmng.so .obj/main.o  .obj/qmnghandler.o  
> -L/usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/lib 
> -L/usr/local/lib /usr/local/lib/qt5/libQt5Gui.so 
> /usr/local/lib/qt5/libQt5Core.so -lGL -lmng
> ld: error: undefined symbol: mng_setcb_writedata
> >>> referenced by qmnghandler.cpp
> >>>   
> >>> .obj/qmnghandler.o:(QMngHandlerPrivate::QMngHandlerPrivate(QMngHandler*))
>
> ld: error: undefined symbol: mng_create
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
>
> ld: error: undefined symbol: mng_putchunk_mhdr
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
>
> ld: error: undefined symbol: mng_putchunk_term
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
>
> ld: error: undefined symbol: mng_putchunk_ihdr
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
>
> ld: error: undefined symbol: mng_putimgdata_ihdr
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
>
> ld: error: undefined symbol: mng_putchunk_iend
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
>
> ld: error: undefined symbol: mng_putchunk_mend
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
>
> ld: error: undefined symbol: mng_write
> >>> referenced by qmnghandler.cpp
> >>>   .obj/qmnghandler.o:(QMngHandlerPrivate::writeImage(QImage 
> >>> const&))
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [../../../../plugins/imageformats/libqmng.so] Error code 1
>
> make[5]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src/plugins/imageformats/mng
> 1 error
>
> make[5]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src/plugins/imageformats/mng
> *** [sub-mng-all] Error code 2
>
> make[4]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src/plugins/imageformats
> --- sub-webp-all ---
> *** [sub-webp-all] Error code 6
>
> make[4]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src/plugins/imageformats
> 2 errors
>
> make[4]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src/plugins/imageformats
> *** [sub-imageformats-all] Error code 2
>
> make[3]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src/plugins
> 1 error
>
> make[3]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src/plugins
> *** [sub-plugins-all] Error code 2
>
> make[2]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src
> 1 error
>
> make[2]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12/src
> *** [sub-src-all] Error code 2
>
> make[1]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12
> 1 error
>
> make[1]: stopped in 
> /usr/ports/graphics/qt5-imageformats/work/kde-qtimageformats-5.15.12p12
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/graphics/qt5-imageformats
>
> ===>>> make build failed for graphics/qt5-imageformats
> ===>>> Aborting update
>
> ===>>> Update for graphics/qt5-imageformats failed
> ===>>> Aborting update
>
> ===>>> Update for devel/py-qt5-pyqt@py39 failed
> ===>>> Aborting update
>
> ===>>> Update for www/py-qt5-webengine@py39 failed
> ===>>> Aborting update
>
> --
> William Bulley
> E-MAIL: w...@umich.edu
> 

Hi,

We're working on it. So far, I've tracked the problem down to
graphics/libmng. A patch was inexplicably deleted from its files a few
days ago and that seems to be what is causing these errors. Feel free
to track the issue progress at [1].

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276182

-Jason

Re: git: 69e2e87fa56b - main - devel/protobuf: Update to 24.4

[Tobias C. Berner]

Moin moin

The main issue is the following:
When using poudriere, you get:
-- Could NOT find Protobuf (missing: Protobuf_LIBRARIES Protobuf
_INCLUDE_DIR)

As you built your ports outside of poudriere, this optional dependency was
picked up.
So we need to properly handle this in the port -- while poudrieres testport
won't find an issue :)

mfg Tobias

On Mon, 18 Dec 2023 at 15:23, Vladimir Druzenko  wrote:

>
>  Forwarded message 
> Subject: Re: git: 69e2e87fa56b - main - devel/protobuf: Update to 24.4
> Date: Fri, 15 Dec 2023 16:45:45 +0300
> From: Vladimir Druzenko  
> To: Po-Chuan Hsieh  ,
> k...@freebsd.org
> CC: dev-commits-ports-m...@freebsd.org, ports-committ...@freebsd.org,
> dev-commits-ports-...@freebsd.org
>
> 15.12.2023 00:09, Po-Chuan Hsieh wrote:
>
> Hello,
>
> On Fri, Dec 15, 2023 at 4:38 AM Vladimir Druzenko  wrote:
>
>> 14.12.2023 20:03, Po-Chuan Hsieh wrote:
>> > The branch main has been updated by sunpoet:
>> >
>> > URL:
>> https://cgit.FreeBSD.org/ports/commit/?id=69e2e87fa56b54e267429b326f7f6188a7baaa71
>> >
>> > commit 69e2e87fa56b54e267429b326f7f6188a7baaa71
>> > Author: Po-Chuan Hsieh  
>> > AuthorDate: 2023-12-14 16:35:30 +
>> > Commit: Po-Chuan Hsieh  
>> > CommitDate: 2023-12-14 17:03:10 +
>> >
>> >  devel/protobuf: Update to 24.4
>> >
>> >  - Use USES=pathfix to fix .pc installation
>> >  - Bump PORTREVISION of dependent ports for shlib change
>> >
>> >  Changes:
>> https://github.com/protocolbuffers/protobuf/releases
>> > ---
>> >   astro/kosmindoormap/Makefile   |   1 +
>> >   astro/libosmpbf/Makefile   |   2 +-
>> >   astro/merkaartor/Makefile  |   2 +-
>> >
>> > …
>> >
>> >   72 files changed, 234 insertions(+), 248 deletions(-)
>> >
>> > …
>> >
>> > *** 426 LINES SKIPPED ***
>>
>> # pkg check -d
>> marble is missing a required shared library: libprotobuf.so.32
>>
>> # pkg info astro/marble
>> Shared Libs required:
>>  libprotobuf.so.32
>>
>> # readelf -d /usr/local/lib/marble/plugins/OsmPlugin.so
>>   0x0001 NEEDED   Shared library:
>> [libprotobuf.so.32]
>>
>
> You have to report it to the maintainer (kde@).
> That means it is a hidden/potential dependency.
> I did my best to check all dependent ports via "git grep".
> It is not caught because it does not list protobuf in the Makefile.
>
> % cd /usr/ports/astro/marble/
> % make run-depends-list | grep protobuf | wc -l
>0
>
> I know. And I also know that kde@ read this list too.
> This email for kde@. :-)
>
> --
> Best regards,
> Vladimir Druzenko
>
>

Re: git: 69e2e87fa56b - main - devel/protobuf: Update to 24.4

[Vladimir Druzenko]

15.12.2023 00:09, Po-Chuan Hsieh пишет:

Hello,

On Fri, Dec 15, 2023 at 4:38 AM Vladimir Druzenko  wrote:

14.12.2023 20:03, Po-Chuan Hsieh пишет:
> The branch main has been updated by sunpoet:
>
> URL:

https://cgit.FreeBSD.org/ports/commit/?id=69e2e87fa56b54e267429b326f7f6188a7baaa71


>
> commit 69e2e87fa56b54e267429b326f7f6188a7baaa71
> Author:     Po-Chuan Hsieh 
> AuthorDate: 2023-12-14 16:35:30 +
> Commit:     Po-Chuan Hsieh 
> CommitDate: 2023-12-14 17:03:10 +
>
>      devel/protobuf: Update to 24.4
>
>      - Use USES=pathfix to fix .pc installation
>      - Bump PORTREVISION of dependent ports for shlib change
>
>      Changes: https://github.com/protocolbuffers/protobuf/releases
> ---
>   astro/kosmindoormap/Makefile               |   1 +
>   astro/libosmpbf/Makefile                   |   2 +-
>   astro/merkaartor/Makefile                  |   2 +-
>
> …
>
>   72 files changed, 234 insertions(+), 248 deletions(-)
>
> …
>
> *** 426 LINES SKIPPED ***

# pkg check -d
marble is missing a required shared library: libprotobuf.so.32

# pkg info astro/marble
Shared Libs required:
 libprotobuf.so.32

# readelf -d /usr/local/lib/marble/plugins/OsmPlugin.so
  0x0001 NEEDED   Shared library:
[libprotobuf.so.32]


You have to report it to the maintainer (kde@).
That means it is a hidden/potential dependency.
I did my best to check all dependent ports via "git grep".
It is not caught because it does not list protobuf in the Makefile.

% cd /usr/ports/astro/marble/
% make run-depends-list | grep protobuf | wc -l
       0


I know. And I also know that kde@ read this list too.
This email for kde@. :-)

--
Best regards,
Vladimir Druzenko



OpenPGP_0x8006FAABBF942F73.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [rsadow...@cvs.openbsd.org: CVS: cvs.openbsd.org: ports]

[Jason E. Hale]

On Wed, Dec 13, 2023 at 10:27 PM Rafael Sadowski  wrote:
>
> Hi FreeBSD KDE hackers,
>
> I see you are still depending on QtAV in your digikam port. It's time to
> remove it.
>
> Cheers, Rafael
>
> - Forwarded message from Rafael Sadowski  -
>
> From: Rafael Sadowski 
> Date: Mon, 15 May 2023 23:20:08 -0600 (MDT)
> Subject: CVS: cvs.openbsd.org: ports
> To: ports-chan...@cvs.openbsd.org
>
> CVSROOT:/cvs
> Module name:ports
> Changes by: rsadow...@cvs.openbsd.org   2023/05/15 23:20:08
>
> Modified files:
> graphics/digikam: Makefile
>
> Log message:
> Remove QtAV as dependency
>
> Upstream has confirmed that it is no longer used.
>
> Thanks Brad
>
>
> - End forwarded message -https

QtAV is long gone from the FreeBSD ports tree. We removed
multimedia/QtAV on 2023-08-22 [1] as it was abandoned by the author
and incompatible with FFmpeg >= 6.x. Our graphics/digikam port has
also not directly depended on it since I updated it to 8.1.0 in [2].
DigiKam now bundles its own copy of QtAV which includes such
improvements as supporting newer versions of FFmpeg at least to 6.0,
at least to the point of building. From my understanding, future
kf6/Qt6-based releases of DigiKam are striving to drop QtAV altogether
and depend solely on qt-multimedia.

[1] 
https://cgit.freebsd.org/ports/commit/?id=635ccfbf59522ddd44cd9283b321e2d9b3bc9876
[2] 
https://cgit.freebsd.org/ports/commit/?id=dbbf964f8cad61eb67b21f2f1e5b09f7ed63d3d6

- Jason

Re: devel/shiboken2 build with python-3.11

[Jason E. Hale]

On Mon, Dec 11, 2023 at 2:48 AM wen heping  wrote:
>
> Then we shall set USES=python:3.8-3.11.
> It will help the switch DEFAULT_PYTHON form 3.9 to 3.11.
>
> Would you commit it if you approve it ?
>

I've committed the change in [1]. I didn't do any runtime testing with
Python 3.11, though.

[1] 
https://cgit.freebsd.org/ports/commit/?id=bfe377d24c6148e442fd0b102b08a3d0131b8adb

- Jason

Re: devel/shiboken2 build with python-3.11

[Jason E. Hale]

On Fri, Dec 8, 2023 at 4:45 AM wen heping  wrote:
>
> Hi,
>
> Here is a simple patch to build devel/shiboken2 when
> DEFAULT_PYTHON=3.11.
>
> Upstream seems build with python-3.11 :
> https://forum.qt.io/topic/144843/pyside2-shiboken2-support-for-python-3-11
>
> Now it build well but I am not sure whether or not there would
> be run error. Would you have a test of it ?
>
>
> Regards,
> wen

Seems reasonable, but for safety we should probably restrict it to
3.11 for when 3.12 hits the ports tree. As far as runtime goes, there
are very few ports that actually use it. If devel/pyside2 builds and
something like cad/freecad works, it is probably fine. Qt 5.15.LTS
public releases tend to lag a year behind the commercial releases,
partially to encourage the open source community to move on to newer
offerings, meaning we should be seeing Qt/shiboken2/pyside2 5.15.12 at
the end of this month with potentially improved support for Python
3.11. Not sure about how well Python 3.12 will work since it was
released just a couple months ago and we don't yet have a port for it.
Pardon the pun, but it may take over a year to catch up on the PySide
of things, at which point actively maintained projects will have
hopefully switched to Qt6/PySide6. In reality, though, we'll probably
be having this conversation all over again at the same time next year
:).

- Jason

Re: x11/kf6-plasma-framework : Error in Makefile

[Tobias C. Berner]

Moin moin

this should be fixed with e491adb75a25d6e25737518b08aa7c0237505dfa

mfg Tobias

On Sun, 3 Dec 2023 at 10:32, Ken  wrote:
>
> Hi There,
>
> There is an issues with the Makefile :
>
> $ sudo synth prepare-system
> Regenerating flavor index: this may take a while ...
> Scanning entire ports tree.
>  progress: 94.64%
> culprit: x11/kf6-plasma-framework
>   Scan aborted because 'make' encounted an error in the Makefile.
>   x11/kf6-plasma-framework (return code = 2)
> Flavor index generation failed: ports scan
>
> Ken

Re: KDE Plasma 6.0 (dev) ports

[void]

On Sat, Dec 02, 2023 at 09:05:52AM +0100, Tobias C. Berner wrote:

Moin moin

I'm working on an import of the beta-release into the ports tree. This
will hopefully land this weekend.


TYVM :D i look forward to trying it.

What's the most recent poudriere-approved method of *enforcing* [1] qt6?

[1] by that, i mean if it something tries qt5 I want it to break. 
Ideally to fail to build noisily so it can be seen whats broken.

--

Re: KDE Plasma 6.0 (dev) ports

[Tobias C. Berner]

Moin moin

I'm working on an import of the beta-release into the ports tree. This
will hopefully land this weekend.

mfg Tobias

On Thu, 30 Nov 2023 at 19:11, Adriaan de Groot  wrote:
>
> On Wednesday, 29 November 2023 15:26:33 CET void wrote:
> > On Thu, Aug 17, 2023 at 08:59:34PM +0200, Tobias C. Berner wrote:
> > >I created ports to build the upcoming Qt 6 based Plasma desktop from git.
> > >At the moment, these ports can be found here [1] as an overlay. The
>
> > I'd like to build qt6-only for all qt. Would the above overlay & patch
> > still be expected to work? Asking because the overlay was last updated
> > 3 months ago and I guess things have moved on a lot. If no longer
> > applicable, how would poudriere enforce qt6-only today? thanks,
>
> If you're Qt6-only, the Qt6 ports are in good shape in the regular ports tree.
> The overlay is important only if you want KDE Plasma 6. For that, the best
> thing to do is to just try the overlay -- I have no idea if it's tied to a
> specific git commit or what. The KDE Plasma 6 beta release is out today,
> though, so it is probably time to land things in the main ports tree now.
>
> [ade]

Re: KDE Plasma 6.0 (dev) ports

[Adriaan de Groot]

On Wednesday, 29 November 2023 15:26:33 CET void wrote:
> On Thu, Aug 17, 2023 at 08:59:34PM +0200, Tobias C. Berner wrote:
> >I created ports to build the upcoming Qt 6 based Plasma desktop from git.
> >At the moment, these ports can be found here [1] as an overlay. The

> I'd like to build qt6-only for all qt. Would the above overlay & patch
> still be expected to work? Asking because the overlay was last updated
> 3 months ago and I guess things have moved on a lot. If no longer
> applicable, how would poudriere enforce qt6-only today? thanks,

If you're Qt6-only, the Qt6 ports are in good shape in the regular ports tree. 
The overlay is important only if you want KDE Plasma 6. For that, the best 
thing to do is to just try the overlay -- I have no idea if it's tied to a 
specific git commit or what. The KDE Plasma 6 beta release is out today, 
though, so it is probably time to land things in the main ports tree now.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: KDE Plasma 6.0 (dev) ports

[void]

Hello,

On Thu, Aug 17, 2023 at 08:59:34PM +0200, Tobias C. Berner wrote:

Moin moin

I created ports to build the upcoming Qt 6 based Plasma desktop from git.
At the moment, these ports can be found here [1] as an overlay. The


(snip)


[1] https://github.com/tcberner/kde6-overlay/
[2] 
https://people.freebsd.org/~tcberner/patches/0001-KDE6-mask-some-file-in-Qt-5-base-ports-that-are-inst.patch


I'd like to build qt6-only for all qt. Would the above overlay & patch
still be expected to work? Asking because the overlay was last updated
3 months ago and I guess things have moved on a lot. If no longer
applicable, how would poudriere enforce qt6-only today? thanks,
--

Re: devel/kio-extras: lib dep libsmbclient -> deprecated samba413

[Joseph Holsten]

FYI: the issue is default samba version, filed a ticket: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275224

On Sun, Nov 19, 2023, at 18:17, Joseph Holsten wrote:
> Howdy kde@ !
>
> Been trying to update the docs for joining FreeBSD to Active Directory, 
> couldn’t make sssd-devel play live with kde5 because sssd wants 
> samba416.
>
> Looks like kio-extras stubbornly insists on sticking with providing 
> libsmbclient.so via samba413. It doesn’t look like it’s just my 
> machine, https://www.freshports.org/devel/kio-extras/ also resolves it 
> this way.
>
> Any idea how we can unpin that dependency?
>
> And timur@:
> Is updating always the right strategy? Any known issues where we’d need 
> to keep 4.13? 
>
> --
> Joseph Holsten
> http://josephholsten.com
> mailto:jos...@josephholsten.com
> tel:+1-360-927-7234

Re: [package - main-i386-default][x11/plasma5-plasma-workspace] Failed for plasma5-plasma-workspace-5.27.9.1 in run-depends

[Jason E. Hale]

On Fri, Nov 10, 2023 at 10:50 PM  wrote:
>
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
>
> Maintainer: k...@freebsd.org
> Log URL:
> https://pkg-status.freebsd.org/beefy17/data/main-i386-default/pae2c790c6a86_s105c7c4b8d/logs/plasma5-plasma-workspace-5.27.9.1.log
> Build URL:  
> https://pkg-status.freebsd.org/beefy17/build.html?mastername=main-i386-default=pae2c790c6a86_s105c7c4b8d
> Log:
>
> =>> Building x11/plasma5-plasma-workspace
> build started at Sat Nov 11 03:20:41 UTC 2023
> port directory: /usr/ports/x11/plasma5-plasma-workspace
> package name: plasma5-plasma-workspace-5.27.9.1
> building for: FreeBSD main-i386-default-job-07 15.0-CURRENT FreeBSD 
> 15.0-CURRENT 153 i386
> maintained by: k...@freebsd.org
> Makefile datestamp: -rw-r--r--  1 root wheel 2579 Oct 28 01:01 
> /usr/ports/x11/plasma5-plasma-workspace/Makefile
> Ports top last git commit: ae2c790c6a8
> Ports top unclean checkout: no
> Port dir last git commit: 5eb35959cbb
> Port dir unclean checkout: no
> Poudriere version: poudriere-git-3.3.0-1251-ge8a0e12e
> Host OSVERSION: 150
> Jail OSVERSION: 153
> Job Id: 07
>

The pkgconfig file was removed from x11/xkeyboard-config when it was
last updated [1] for some reason, which was causing this port to fail.
I restored the pkgconfig file and corrected several other pkg-plist
errors in [2].

[1] 
https://cgit.freebsd.org/ports/commit/?id=e6f66fef02554459d756c1510fc74a52de40f049
[2] 
https://cgit.freebsd.org/ports/commit/?id=5a4eeed2e2cd1458f8a1b14c0801f1c7e1885329

Re: problem building kf5-purpose

[Jason E. Hale]

On Mon, Nov 6, 2023 at 11:50 AM Robert Huff  wrote:
>
> Merging translations into 
> /data/port-work/usr/ports/misc/kf5-purpose/work/.build/src/plugins/youtube/google-youtube.service.
> CMake Error at /usr/local/lib/cmake/KAccounts/KAccountsMacros.cmake:33 
> (message):
>   error processing
>   
> /data/port-work/usr/ports/misc/kf5-purpose/work/purpose-5.111.0/src/plugins/youtube/google-youtube.service.in
>   with /usr/local/bin/intltool-merge: 2 You must have XML::Parser installed
>   to run /usr/local/bin/intltool-merge
>

This is an error coming from intltool-merge. Check your
textproc/intltool installation. Do you have textproc/p5-XML-Parser
installed like it's asking for?

-Jason

Re: problem building kf5-purpose

[Tobias C. Berner]

Moin moin

what's the output of
> pkg which /usr/local/share/ECM/modules/ECMQMLModules.cmake

In short: make sure, all your packages are up-to-date before manually
building outside of poudriere.


mfg Tobias

On Mon, 6 Nov 2023 at 17:50, Robert Huff  wrote:
>
>
> Hello:
> On a asystem running:
>
> FreeBSD 14.0-CURRENT #0 main-f0a15aafcb
> Mon Oct 31 08:19:54 EDT 2022
> amd64
>
> with dependant ports updated, why is this:
>
> ===>  Configuring for kf5-purpose-5.111.0
> ===>  Performing out-of-source build
> /bin/mkdir -p /data/port-work/usr/ports/misc/kf5-purpose/work/.build
> CMake Deprecation Warning at 
> /usr/local/share/ECM/modules/ECMQMLModules.cmake:7 (message):
>   ECMQMLModules.cmake is deprecated since 5.88.0, please use
>   ECMFindQmlModule.cmake instead
> Call Stack (most recent call first):
>   CMakeLists.txt:26 (include)
>
>
> Merging translations into 
> /data/port-work/usr/ports/misc/kf5-purpose/work/.build/src/plugins/youtube/google-youtube.service.
> CMake Error at /usr/local/lib/cmake/KAccounts/KAccountsMacros.cmake:33 
> (message):
>   error processing
>   
> /data/port-work/usr/ports/misc/kf5-purpose/work/purpose-5.111.0/src/plugins/youtube/google-youtube.service.in
>   with /usr/local/bin/intltool-merge: 2 You must have XML::Parser installed
>   to run /usr/local/bin/intltool-merge
>
>
>
> Call Stack (most recent call first):
>   src/plugins/youtube/CMakeLists.txt:4 (kaccounts_add_service)
>
>
> -- Configuring incomplete, errors occurred!
> *** Error code 1
>
>
> ... happening?
> More importantly: what do I do to fix it?
>
>
> Respectfully,
>
>
> Robert Huff
>

Re: [package - 124i386-default][science/qt6-quick3dphysics] Failed for qt6-quick3dphysics-6.5.3 in build

[Jason E. Hale]

On Sat, Oct 28, 2023 at 11:20 AM  wrote:
>
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
>
> Maintainer: k...@freebsd.org
> Log URL:
> https://pkg-status.freebsd.org/beefy5/data/124i386-default/16bdcaa2bc90/logs/qt6-quick3dphysics-6.5.3.log
> Build URL:  
> https://pkg-status.freebsd.org/beefy5/build.html?mastername=124i386-default=16bdcaa2bc90
> Log:
>
> =>> Building science/qt6-quick3dphysics
> build started at Sat Oct 28 15:19:29 UTC 2023
> port directory: /usr/ports/science/qt6-quick3dphysics
> package name: qt6-quick3dphysics-6.5.3
> building for: FreeBSD 124i386-default-job-09 12.4-RELEASE-p6 FreeBSD 
> 12.4-RELEASE-p6 i386
> maintained by: k...@freebsd.org
> Makefile ident:
> Poudriere version: 3.2.8-23-ga7f8d188
> Host OSVERSION: 150
> Jail OSVERSION: 1204000
> Job Id: 09
>

These failures of science/qt6-quick3dphysics on i386 should now be
fixed with bf02e174350c. PhysX makes the assumption that all i386
processors support SSE2. A SIMD option was added to correct this.

Re: KDE 5.27.8 on FreeBSD 13.2-RELEASE-p4 (64-bit)

[Oleksandr Kryvulia]

Same situation for me on latest current.

23.10.23 09:47, Ronald the Bruce:

Hello Tobias,

Thanks for taking the time to look at this. I am pretty certain it was 
working fine in FreeBSD 13.2-RELEASE-p3. Could it have anything to do 
with this:


FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED]

Ron

On 23/10/23 17:06, Tobias C. Berner wrote:

Moin moin

Indeed, this setting seems to be grayed out.
This might be a regression in a recent update.
Do you know when that setting was last working?


mfg Tobias

On Wed, 18 Oct 2023 at 16:16, Ronald the Bruce 
 wrote:

Hello,

First of all, thanks for the work you do bringing KDE to the FreeBSD 
platform.


I am reaching out to try and solve an issue which has alluded me - 
specifically the apparent disabling of regional settings. 
Specifically, SYSTEM SETTINGS/REGIONAL SETTINGS/REGION & LANGUAGE 
are greyed out and cannot be changed. I have searched the web and 
not found any reference to the issue.


I am an experienced user who has used KDE on FreeBSD as my principle 
desktop for many years and it has performed very well and has been 
very stable; the problem I am seeking your help to fix occurred when 
I reinstalled FreeBSD 13.2 Release following a SSD failure. I have 
reviewed Section 25 of the FreeBSD Handbook and changed my 
.login_conf to read as follows:


me:\
    :charset=UTF-8:\
    :lang=en_AU.UTF-8:

locale:

LANG=en_AU.UTF-8
LC_CTYPE="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_ALL=

I hope you can help solve this problem.

Thanks again and regards,

Ron Chambers

Melbourne, Australia

Re: Image viewer gwenview needs 27 secs to start

[Fernando Apesteguía]

On Sun, Oct 22, 2023 at 1:27 PM Matthias Apitz  wrote:

> El día domingo, octubre 22, 2023 a las 12:54:40p. m. +0200, Ronald Klop
> escribió:
>
> > Hi,
> >
> > This needs some debugging of the application.
> >
> > During these 27 seconds it can be interesting to get the output of:
>
> I found the point where it spends this amount of time. I run
>
> $ truss -o gwenview.tr -d gwenview
>
> and with grep/vim I found the point in time where it waits 25 secs for
> something:
>
> ...
> 2.001783437 socket(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0) = 21 (0x15)
> 2.002053139 connect(21,{ AF_UNIX "/var/run/dbus/system_bus_socket" },33) =
> 0 (0x0)
> ...
> 2.019812505 sendmsg(21,{NULL,0,[{"l\^A\0\^A
> \0\0\0\v\0\0\0\M^H\0\0"...,152},{"\^V\0\0\0org.freedesktop.UPower"...,32}],2,{},0,0},MSG_NOSIGNAL)
> = 184 (0xb8)
> 27.024832498 poll({ 11/POLLIN 12/POLLIN 21/POLLIN },3,25068) = 1 (0x1)
> 27.024978322
> recvmsg(21,{NULL,0,[{"l\^C\^A\^Ac\0\0\0\a\0\0\0m\0\0\0"...,2048}],1,{},0,MSG_CMSG_CLOEXEC},MSG_CMSG_CLOEXEC)
> = 227 (0xe3)
> 27.025182480 recvmsg(21,0x896a197b0,MSG_CMSG_CLOEXEC) ERR#35 'Resource
> temporarily unavailable'
>
> i.e. it sends something to /var/run/dbus/system_bus_socket and waits 25
> secs in poll(2) for the answer until it timesout after 25086 millisecs.
>
> matthias
>

Try having a look with qdbusviewer and exporting DBUS_SESSION_BUS_ADDRESS
if necessary.
>From your log it seems it is accessing org.freedesktop.UPower the specific
method is not shown.

What if you try to call UPower by hand?

dbus-send --print-reply \ --system \ --dest=org.freedesktop.UPower \
/org/freedesktop/UPower \ org.freedesktop.UPower.EnumerateDevices

Cheers.

>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
> +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
>
> I am not at war with Russia.
> Я не воюю с Россией.
> Ich bin nicht im Krieg mit Russland.
>
>

Re: KDE 5.27.8 on FreeBSD 13.2-RELEASE-p4 (64-bit)

[Ronald the Bruce]

Hello Tobias,

Thanks for taking the time to look at this. I am pretty certain it was 
working fine in FreeBSD 13.2-RELEASE-p3. Could it have anything to do 
with this:


FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED]

Ron

On 23/10/23 17:06, Tobias C. Berner wrote:

Moin moin

Indeed, this setting seems to be grayed out.
This might be a regression in a recent update.
Do you know when that setting was last working?


mfg Tobias

On Wed, 18 Oct 2023 at 16:16, Ronald the Bruce  wrote:

Hello,

First of all, thanks for the work you do bringing KDE to the FreeBSD platform.

I am reaching out to try and solve an issue which has alluded me - specifically the 
apparent disabling of regional settings. Specifically, SYSTEM SETTINGS/REGIONAL 
SETTINGS/REGION & LANGUAGE are greyed out and cannot be changed. I have 
searched the web and not found any reference to the issue.

I am an experienced user who has used KDE on FreeBSD as my principle desktop 
for many years and it has performed very well and has been very stable; the 
problem I am seeking your help to fix occurred when I reinstalled FreeBSD 13.2 
Release following a SSD failure. I have reviewed Section 25 of the FreeBSD 
Handbook and changed my .login_conf to read as follows:

me:\
:charset=UTF-8:\
:lang=en_AU.UTF-8:

locale:

LANG=en_AU.UTF-8
LC_CTYPE="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_ALL=

I hope you can help solve this problem.

Thanks again and regards,

Ron Chambers

Melbourne, Australia

Re: Image viewer gwenview needs 27 secs to start

[Ronald Klop]

Hi,

This needs some debugging of the application.

During these 27 seconds it can be interesting to get the output of:

procstat -kk 
procstat -t 

This shows if the application is waiting for the kernel.

Use 'top' to see if the application is running 100% CPU or not.
Use 'iostat -d -x 1' to see if it is waiting for IO.

Dtrace might also be useful to see what the application is doing, but I don't 
know the proper syntax from the top of my head.

Regards,
Ronald.


Van: Matthias Apitz 
Datum: zondag, 22 oktober 2023 11:11
Aan: k...@freebsd.org, freebsd-po...@freebsd.org
Onderwerp: Image viewer gwenview needs 27 secs to start


I'm used to use gwenview for image viewing and manipulating. Since I
updated to recent ports (via git at September 22, exact version see
below) the start is VERY lazy. It takes 27 secs to present the image
when started with 'gwenview file.jpg' from a shell.

Any ideas or help?

matthias


gwenview-23.08.0
Name   : gwenview
Version: 23.08.0
Installed on   : Sun Sep 24 11:27:49 2023 CEST
Origin : graphics/gwenview
Architecture   : FreeBSD:14:amd64
Prefix : /usr/local
Categories : kde-applications kde graphics
Licenses   : LGPL20
Maintainer : k...@freebsd.org
WWW: http://gwenview.sourceforge.net
Comment: Image viewer and browser for KDE
Options:
DOCS   : on
Shared Libs required:
libwayland-client.so.0
libtiff.so.5
libpng16.so.16
libphonon4qt5.so.4
liblcms2.so.2
libkImageAnnotator.so.0
libjpeg.so.8
libexiv2.so.28
libX11.so.6
libQt5Xml.so.5
libQt5X11Extras.so.5
libQt5Widgets.so.5
libQt5WaylandClient.so.5
libQt5Svg.so.5
libQt5PrintSupport.so.5
libQt5Network.so.5
libQt5Gui.so.5
libQt5DBus.so.5
libQt5Core.so.5
libQt5Concurrent.so.5
libKF5XmlGui.so.5
libKF5WindowSystem.so.5
libKF5WidgetsAddons.so.5
libKF5TextWidgets.so.5
libKF5SonnetUi.so.5
libKF5Solid.so.5
libKF5Service.so.5
libKF5Parts.so.5
libKF5Notifications.so.5
libKF5KIOWidgets.so.5
libKF5KIOGui.so.5
libKF5KIOFileWidgets.so.5
libKF5KIOCore.so.5
libKF5KDcraw.so.5
libKF5JobWidgets.so.5
libKF5ItemViews.so.5
libKF5ItemModels.so.5
libKF5IconThemes.so.5
libKF5I18n.so.5
libKF5GuiAddons.so.5
libKF5FileMetaData.so.3
libKF5CoreAddons.so.5
libKF5ConfigWidgets.so.5
libKF5ConfigGui.so.5
libKF5ConfigCore.so.5
libKF5Completion.so.5
libKF5Codecs.so.5
libKF5Bookmarks.so.5
libKF5Baloo.so.5
libKF5AuthCore.so.5
libKF5Auth.so.5
libKF5Activities.so.5
Shared Libs provided:
libgwenviewlib.so.5
Annotations:
FreeBSD_version: 1400094
build_timestamp: 2023-09-22T01:09:11+
built_by   : poudriere-git-3.3.99.20220831
port_checkout_unclean: no
port_git_hash  : 2a6cfd50d
ports_top_checkout_unclean: no
ports_top_git_hash: 1a898a009
repo_type  : binary
repository : FreeBSD
Flat size  : 11.1MiB
Description:
Gwenview is a fast and easy to use image viewer for KDE.

Features:
 - Supports simple image manipulations: rotate, mirror, flip, and resize.
 - Supports basic file management actions such as copy, move, delete,
   and others.
 - Functions both as a standalone application and an embedded viewer
   in the Konqueror web browser.
 - Can be extended using KIPI plugins.
--
Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.
.
Ich bin nicht im Krieg mit Russland.
 

Re: KDE 5.27.8 on FreeBSD 13.2-RELEASE-p4 (64-bit)

[Tobias C. Berner]

Moin moin

Indeed, this setting seems to be grayed out.
This might be a regression in a recent update.
Do you know when that setting was last working?


mfg Tobias

On Wed, 18 Oct 2023 at 16:16, Ronald the Bruce  wrote:
>
> Hello,
>
> First of all, thanks for the work you do bringing KDE to the FreeBSD platform.
>
> I am reaching out to try and solve an issue which has alluded me - 
> specifically the apparent disabling of regional settings. Specifically, 
> SYSTEM SETTINGS/REGIONAL SETTINGS/REGION & LANGUAGE are greyed out and cannot 
> be changed. I have searched the web and not found any reference to the issue.
>
> I am an experienced user who has used KDE on FreeBSD as my principle desktop 
> for many years and it has performed very well and has been very stable; the 
> problem I am seeking your help to fix occurred when I reinstalled FreeBSD 
> 13.2 Release following a SSD failure. I have reviewed Section 25 of the 
> FreeBSD Handbook and changed my .login_conf to read as follows:
>
> me:\
>:charset=UTF-8:\
>:lang=en_AU.UTF-8:
>
> locale:
>
> LANG=en_AU.UTF-8
> LC_CTYPE="en_AU.UTF-8"
> LC_COLLATE="en_AU.UTF-8"
> LC_TIME="en_AU.UTF-8"
> LC_NUMERIC="en_AU.UTF-8"
> LC_MONETARY="en_AU.UTF-8"
> LC_MESSAGES="en_AU.UTF-8"
> LC_ALL=
>
> I hope you can help solve this problem.
>
> Thanks again and regards,
>
> Ron Chambers
>
> Melbourne, Australia

Re: Image viewer gwenview needs 27 secs to start

[Matthias Apitz]

El día domingo, octubre 22, 2023 a las 02:15:31p. m. +0200, Fernando Apesteguía 
escribió:

> Try having a look with qdbusviewer and exporting DBUS_SESSION_BUS_ADDRESS
> if necessary.
> From your log it seems it is accessing org.freedesktop.UPower the specific
> method is not shown.
> 
> What if you try to call UPower by hand?
> 
> dbus-send --print-reply \ --system \ --dest=org.freedesktop.UPower \
> /org/freedesktop/UPower \ org.freedesktop.UPower.EnumerateDevices

This gave the same delay. The name org.freedesktop.UPower.EnumerateDevices
gave me the hint: Days ago I move away /usr/local/libexec/upowerd to
/usr/local/libexec/upowerd.away and copied /bin/true to 
/usr/local/libexec/upowerd
to investigate another issue I have with KDE5 (switching between the
virtual desktops does not work fast). I renamed it again and gwenview
behaves normal.

Thanks for your help.

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Re: Image viewer gwenview needs 27 secs to start

[Matthias Apitz]

El día domingo, octubre 22, 2023 a las 12:54:40p. m. +0200, Ronald Klop 
escribió:

> Hi,
> 
> This needs some debugging of the application.
> 
> During these 27 seconds it can be interesting to get the output of:

I found the point where it spends this amount of time. I run 

$ truss -o gwenview.tr -d gwenview

and with grep/vim I found the point in time where it waits 25 secs for
something:

...
2.001783437 socket(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0) = 21 (0x15)
2.002053139 connect(21,{ AF_UNIX "/var/run/dbus/system_bus_socket" },33) = 0 
(0x0)
...
2.019812505 sendmsg(21,{NULL,0,[{"l\^A\0\^A 
\0\0\0\v\0\0\0\M^H\0\0"...,152},{"\^V\0\0\0org.freedesktop.UPower"...,32}],2,{},0,0},MSG_NOSIGNAL)
 = 184 (0xb8)
27.024832498 poll({ 11/POLLIN 12/POLLIN 21/POLLIN },3,25068) = 1 (0x1)
27.024978322 
recvmsg(21,{NULL,0,[{"l\^C\^A\^Ac\0\0\0\a\0\0\0m\0\0\0"...,2048}],1,{},0,MSG_CMSG_CLOEXEC},MSG_CMSG_CLOEXEC)
 = 227 (0xe3)
27.025182480 recvmsg(21,0x896a197b0,MSG_CMSG_CLOEXEC) ERR#35 'Resource 
temporarily unavailable'

i.e. it sends something to /var/run/dbus/system_bus_socket and waits 25
secs in poll(2) for the answer until it timesout after 25086 millisecs.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Re: FreeBSD Port: x11-toolkits/qt5-widgets build fails

[Jason E. Hale]

On Sun, Oct 15, 2023 at 7:00 AM mr44er  wrote:
>
> kernel/qwidget.cpp:112:10: fatal error: 
> 'QtPlatformHeaders/qxcbwindowfunctions.h' file not found
> #include 
>  ^

This looks to be the same as [1]. Please ensure that the X11 option is
enabled in x11-toolkits/qt5-gui and rebuild/reinstall it. This option
is a requirement of x11-toolkits/qt5-widgets and since over 90% of the
ports that require Gui also require Widgets, it should only be turned
off for very specific use cases.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266378

-Jason

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Matthias Apitz]

This morning my firefox crashed on startup. While digging into this I
found as reason "Too many open files" (and my kernel value for this is:

# sysctl kern.maxfiles
kern.maxfiles: 62558

With Don Google I found the reason in this issue against KDE5 baloo:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273669

I disabled baloo and have had already deleted /usr/local/libexec/upowerd
with

# mv /usr/local/libexec/upowerd /usr/local/libexec/upowerd.away
# cp /usr/bin/true /usr/local/libexec/upowerd

With these two changes the switching between the virtual desktops is
much better.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Matthias Apitz]

El día lunes, septiembre 18, 2023 a las 07:44:40 +0300, Gleb Popov escribió:

> On Mon, Sep 18, 2023 at 7:39 PM Matthias Apitz  wrote:
> >
> > When I kill kglobalaccel5, Xorg stressed with repeated 'Control_L' goes
> > only to 20% but Control_L + TAB does not switch to my virtual desktops.
> > When I restart kglobalaccel5 from the shell, switching works again with
> > the same CPU symptom.
> 
> Ugh, this doesn't give a hint, then. Do you have fancy effects enabled
> for the virtual desktop switching? If yes, can you try disabling it or
> the compositor altogether to see if the problem goes away? I don't
> really remember how to do that, so you'd have to search for these
> settings in System Settings yourself.

I've removed now ~/.config and ~/.cache so plasma created a new fresh
desktop on the next 'startx'. I did the following config changes after
the desktop was up:

- configured 4 virtual desktops
- Ctrl+TAB to cycle forward between them
- Shift+Ctrl+TAB to cycle backward
- Ctrl+F1 ... to jump to desktop 1 ...

With this the problem is again visible: kglobalaccel5 and Xorg process
CPU utilisation goes up when switching and when I switch to fast,
it does not even switch anymore and later replays fast the movement.

What next to check? File a PR?

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: port www/qt5-webengine fails reproducible at the same place compilation

[Matthias Apitz]

El día jueves, septiembre 21, 2023 a las 05:03:15p. m. +0300, Gleb Popov 
escribió:

> On Thu, Sep 21, 2023 at 4:47 PM Matthias Apitz  wrote:
> >
> > Should I file a new PR?
> 
> You should check git log:
> https://cgit.freebsd.org/ports/commit/?id=190bd2d090115c5c38661198d16fd55288aeb9c1
> This commit is just several commits later than the one you're building.
> 

I checked the git log, but in direction of the past because on August
nn, it still compiled, with

cd www/qt5-webengine
git log .

to see if one of the recent changes could cause it.

OK, lesson learned. Thanks


matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: port www/qt5-webengine fails reproducible at the same place compilation

[Gleb Popov]

On Thu, Sep 21, 2023 at 4:47 PM Matthias Apitz  wrote:
>
> Should I file a new PR?

You should check git log:
https://cgit.freebsd.org/ports/commit/?id=190bd2d090115c5c38661198d16fd55288aeb9c1
This commit is just several commits later than the one you're building.

[Bug 273937] Security: graphics: private content on screen, during an otherwise effective screen lock (was: x11-wm/plasma5-kwin with x11/nvidia-driver-470: occasional title bar failures kwin_x11 --re

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273937

Graham Perrin  changed:

   What|Removed |Added

 CC|k...@freebsd.org |

--- Comment #4 from Graham Perrin  ---
FFS, I forgot to remove kde@ 

Removing it now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 273937] Security: graphics: private content on screen, during an otherwise effective screen lock (was: x11-wm/plasma5-kwin with x11/nvidia-driver-470: occasional title bar failures kwin_x11 --re

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273937

Graham Perrin  changed:

   What|Removed |Added

   See Also|https://bugs.freebsd.org/bu |
   |gzilla/show_bug.cgi?id=2738 |
   |12  |
   Priority|--- |Normal
Version|Latest  |unspecified
Summary|x11-wm/plasma5-kwin with|Security: graphics: private
   |x11/nvidia-driver-470:  |content on screen, during
   |occasional title bar|an otherwise effective
   |failures on at least one|screen lock (was:
   |external display, worked|x11-wm/plasma5-kwin with
   |around with kwin_x11|x11/nvidia-driver-470:
   |--replace   |occasional title bar
   ||failures  kwin_x11
   ||--replace)
  Component|Individual Port(s)  |Base
   Assignee|da...@freebsd.org   |sect...@freebsd.org
  Flags|maintainer-feedback?(danfe@ |
   |FreeBSD.org)|
  Group||freebsd_committer
   Keywords||security
Product|Ports & Packages|Security

--- Comment #3 from Graham Perrin  ---
To any privileged user of Bugzilla who reads this bug report: 

* please do not discuss in public.

In particular: 

* please do not treat open non-encrypted IRC in a publicised channel as a 
  suitable venue to encourage discussion of what should be private.


danfe@ I am making this report private. Keyword:

* security


secteam@ I am genuinely sorry for the public beginning of this report. I could,
or should, have predicted what follows.

Symptoms recurred after waking the computer from sleep (resume from suspend). 

Texts were visible, photographed, whilst a screen lock was active.

To help distinguish this report from other reports:

* I could not use the desktop environment until after I entered my 
  passphrase to end the active lock.

I can not be certain that this is a ports bug … consider the possibility of a
bug in base causing, or partly causing, security issues that affect (or
involve) multiple graphics drivers; drivers that are quite different from each
other.



% date ; uptime ; grep -e BOOT -e suspend /var/log/messages
Wed 20 Sep 2023 00:33:59 BST
12:33a.m.  up  5:50, 5 users, load averages: 0.61, 0.74, 0.66
Sep 19 06:54:36 mowa219-gjp4-8570p-freebsd acpi[16951]: suspend at 20230919
06:54:36
Sep 19 12:43:11 mowa219-gjp4-8570p-freebsd kernel: ---<>---
Sep 19 13:28:10 mowa219-gjp4-8570p-freebsd kernel: ---<>---
Sep 19 16:34:20 mowa219-gjp4-8570p-freebsd acpi[2826]: suspend at 20230919
16:34:20
Sep 19 19:56:58 mowa219-gjp4-8570p-freebsd acpi[11760]: suspend at 20230919
19:56:58
% 



Information set aside, for reference, includes copies of: 

/var/log/console.log
/var/log/dmesg.today
/var/log/dmesg.yesterday
/var/log/messages



There's more, but first I should restart the computer, because now (whilst
writing) I see that flickering can recur after 'kwin_x11 --replace' and before
putting the computer to sleep.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Matthias Apitz]

El día lunes, septiembre 18, 2023 a las 10:41:52p. m. +0200, Michael Gmelin 
escribió:

> 
> 
> > On 18. Sep 2023, at 18:03, Matthias Apitz  wrote:
> > 
> > El día lunes, septiembre 18, 2023 a las 11:36:17a. m. +0200, Matthias 
> > Apitz escribió:
> > 
> >>> El día lunes, septiembre 18, 2023 a las 11:08:16 +0300, Gleb Popov 
> >>> escribió:
> >>> 
> >>> On Mon, Sep 18, 2023 at 10:42 AM Matthias Apitz  wrote:
> >>>> 
> >>>> 
> >>>> I investigated the problem described below further and modified
> >>>> ~/.xinitrc to not start plasma, but twm and one xterm. The issue depends
> >>>> clearly on KDE5. On KeyPress event of Control_L the two processes
> >>>> Xorg and kglobalaccel jump in top on the list, Xorg with 30++%.
> >>>> 
> >>>> If one uses multiple time Control_L + TAB to rotate between the virtual
> >>>> desktops, this is lazy at the beginning and later the requests get
> >>>> somehow stacked nd re-played by its own like a movie.
> >>>> 
> >>>> This is not with my older laptop installation with ports from end of
> >>>> 2020 (which have been bleeding edge at this time).
> >>>> 
> >>>> Should I file a bug in bugs.kde.org or is that somehow a known issue?
> >>>> 
> >>>> Thanks
> >>> 
> >>> Probably you have something strange bound to this shortcut. Does the
> >>> problem exist for a newly created user (with empty ~/.config and
> >>> ~/.cache) ?
> >> 
> >> The trees ~/.config and ~/.cache have been copied from the 2020's system
> >> which is still in use. But I will follow your advice and test with a
> >> newly created user.
> > 
> > I created a new user 'test', did login as 'test', copied my ~guru/.xinitrc
> > to ~/.xinitrc, started KDE with 'startx' and started on the empty desktop
> > 'Konsole' from the Application launcher and with 'Konsole' the command
> > 'top'. Using the key 'Control_L' a few times, let's say 10 times in 10
> > seconds, brings the proc Xorg to 60% and kglobalaccel to 20% CPU 
> > utilization.
> > 
> > Please let me know, if I could check something.
> > 
> 
> Could you share the content of your .xinitrc (excuse if you had before).

It's attached. There is also nothing fancy configured for the desktop
switch. Each new desktop just moves in from right to the left. I have
configured 4 virtual desktops and from the fourth it cycles back to the
first.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
#
# test section to not boot KDE
#
# setxkbmap de -option terminate:ctrl_alt_bksp
# twm &
# xterm -fn 10x20
# exit
#
# end of test section

#
setxkbmap de -option terminate:ctrl_alt_bksp
xrandr --output default --mode 1366x768
/usr/local/bin/xbindkeys

# Trackpad section
#
device="Cypress APA I2C Trackpad"
#
xinput set-prop "$device" "libinput Tapping Enabled" 1
#
# for those who like "natural" scrolling:
#
xinput set-prop "$device" "libinput Natural Scrolling Enabled" 1
#
# this gives three buttons in the lower part of the TP:
#
xinput set-prop "$device" "libinput Middle Emulation Enabled"  0
#
#
#  Trackpad layout (see man cyapa)
#
#   2/3   1/3
#  +++
#  ||   Middle   |
#  ||   Button   |
#  |   Left ||
#  |  Button++
#  ||   Right|
#  ||   Button   |
#  ++|
#  | Thumb/Button Area   | 15%
#  +-+
# see also:
# https://wayland.freedesktop.org/libinput/doc/latest/clickpad-softbuttons.html
#
# end of Trackpad section


#
# startplasma-x11
#
echo .xinitrc-StartKDE > startkde.log
exec ck-launch-session startplasma-x11 \
  2>&1 | while read line; do echo -n "$(date '+%T'): "; echo $line ; test 
"$line" = "startkde: Done." && exit ; done | tee -a startkde.log

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2, 1 && key Control_L)

[Michael Gmelin]

> On 18. Sep 2023, at 18:03, Matthias Apitz  wrote:
> 
> El día lunes, septiembre 18, 2023 a las 11:36:17a. m. +0200, Matthias Apitz 
> escribió:
> 
>>> El día lunes, septiembre 18, 2023 a las 11:08:16 +0300, Gleb Popov escribió:
>>> 
>>> On Mon, Sep 18, 2023 at 10:42 AM Matthias Apitz  wrote:
>>>> 
>>>> 
>>>> I investigated the problem described below further and modified
>>>> ~/.xinitrc to not start plasma, but twm and one xterm. The issue depends
>>>> clearly on KDE5. On KeyPress event of Control_L the two processes
>>>> Xorg and kglobalaccel jump in top on the list, Xorg with 30++%.
>>>> 
>>>> If one uses multiple time Control_L + TAB to rotate between the virtual
>>>> desktops, this is lazy at the beginning and later the requests get
>>>> somehow stacked nd re-played by its own like a movie.
>>>> 
>>>> This is not with my older laptop installation with ports from end of
>>>> 2020 (which have been bleeding edge at this time).
>>>> 
>>>> Should I file a bug in bugs.kde.org or is that somehow a known issue?
>>>> 
>>>> Thanks
>>> 
>>> Probably you have something strange bound to this shortcut. Does the
>>> problem exist for a newly created user (with empty ~/.config and
>>> ~/.cache) ?
>> 
>> The trees ~/.config and ~/.cache have been copied from the 2020's system
>> which is still in use. But I will follow your advice and test with a
>> newly created user.
> 
> I created a new user 'test', did login as 'test', copied my ~guru/.xinitrc
> to ~/.xinitrc, started KDE with 'startx' and started on the empty desktop
> 'Konsole' from the Application launcher and with 'Konsole' the command
> 'top'. Using the key 'Control_L' a few times, let's say 10 times in 10
> seconds, brings the proc Xorg to 60% and kglobalaccel to 20% CPU utilization.
> 
> Please let me know, if I could check something.
> 

Could you share the content of your .xinitrc (excuse if you had before).

Best

> Thanks
> 
>matthias
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> 

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Gleb Popov]

On Mon, Sep 18, 2023 at 7:39 PM Matthias Apitz  wrote:
>
> When I kill kglobalaccel5, Xorg stressed with repeated 'Control_L' goes
> only to 20% but Control_L + TAB does not switch to my virtual desktops.
> When I restart kglobalaccel5 from the shell, switching works again with
> the same CPU symptom.

Ugh, this doesn't give a hint, then. Do you have fancy effects enabled
for the virtual desktop switching? If yes, can you try disabling it or
the compositor altogether to see if the problem goes away? I don't
really remember how to do that, so you'd have to search for these
settings in System Settings yourself.

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Matthias Apitz]

El día lunes, septiembre 18, 2023 a las 07:09:13p. m. +0300, Gleb Popov 
escribió:

> On Mon, Sep 18, 2023 at 7:04 PM Matthias Apitz  wrote:
> >
> > I created a new user 'test', did login as 'test', copied my ~guru/.xinitrc
> > to ~/.xinitrc, started KDE with 'startx' and started on the empty desktop
> > 'Konsole' from the Application launcher and with 'Konsole' the command
> > 'top'. Using the key 'Control_L' a few times, let's say 10 times in 10
> > seconds, brings the proc Xorg to 60% and kglobalaccel to 20% CPU 
> > utilization.
> 
> This is peculiar. At least we now know that it isn't your personal
> setup's problem. However, I'm not sure how to debug this further.
> 
> How about killing the kglobalaccel process? Does this stop the CPU 
> consumption?
> 

When I kill kglobalaccel5, Xorg stressed with repeated 'Control_L' goes
only to 20% but Control_L + TAB does not switch to my virtual desktops.
When I restart kglobalaccel5 from the shell, switching works again with
the same CPU symptom.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Gleb Popov]

On Mon, Sep 18, 2023 at 7:04 PM Matthias Apitz  wrote:
>
> I created a new user 'test', did login as 'test', copied my ~guru/.xinitrc
> to ~/.xinitrc, started KDE with 'startx' and started on the empty desktop
> 'Konsole' from the Application launcher and with 'Konsole' the command
> 'top'. Using the key 'Control_L' a few times, let's say 10 times in 10
> seconds, brings the proc Xorg to 60% and kglobalaccel to 20% CPU utilization.

This is peculiar. At least we now know that it isn't your personal
setup's problem. However, I'm not sure how to debug this further.

How about killing the kglobalaccel process? Does this stop the CPU consumption?

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Matthias Apitz]

El día lunes, septiembre 18, 2023 a las 11:36:17a. m. +0200, Matthias Apitz 
escribió:

> El día lunes, septiembre 18, 2023 a las 11:08:16 +0300, Gleb Popov escribió:
> 
> > On Mon, Sep 18, 2023 at 10:42 AM Matthias Apitz  wrote:
> > >
> > >
> > > I investigated the problem described below further and modified
> > > ~/.xinitrc to not start plasma, but twm and one xterm. The issue depends
> > > clearly on KDE5. On KeyPress event of Control_L the two processes
> > > Xorg and kglobalaccel jump in top on the list, Xorg with 30++%.
> > >
> > > If one uses multiple time Control_L + TAB to rotate between the virtual
> > > desktops, this is lazy at the beginning and later the requests get
> > > somehow stacked nd re-played by its own like a movie.
> > >
> > > This is not with my older laptop installation with ports from end of
> > > 2020 (which have been bleeding edge at this time).
> > >
> > > Should I file a bug in bugs.kde.org or is that somehow a known issue?
> > >
> > > Thanks
> > 
> > Probably you have something strange bound to this shortcut. Does the
> > problem exist for a newly created user (with empty ~/.config and
> > ~/.cache) ?
> 
> The trees ~/.config and ~/.cache have been copied from the 2020's system
> which is still in use. But I will follow your advice and test with a
> newly created user.

I created a new user 'test', did login as 'test', copied my ~guru/.xinitrc
to ~/.xinitrc, started KDE with 'startx' and started on the empty desktop
'Konsole' from the Application launcher and with 'Konsole' the command
'top'. Using the key 'Control_L' a few times, let's say 10 times in 10
seconds, brings the proc Xorg to 60% and kglobalaccel to 20% CPU utilization.

Please let me know, if I could check something.

Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Matthias Apitz]

El día lunes, septiembre 18, 2023 a las 11:08:16 +0300, Gleb Popov escribió:

> On Mon, Sep 18, 2023 at 10:42 AM Matthias Apitz  wrote:
> >
> >
> > I investigated the problem described below further and modified
> > ~/.xinitrc to not start plasma, but twm and one xterm. The issue depends
> > clearly on KDE5. On KeyPress event of Control_L the two processes
> > Xorg and kglobalaccel jump in top on the list, Xorg with 30++%.
> >
> > If one uses multiple time Control_L + TAB to rotate between the virtual
> > desktops, this is lazy at the beginning and later the requests get
> > somehow stacked nd re-played by its own like a movie.
> >
> > This is not with my older laptop installation with ports from end of
> > 2020 (which have been bleeding edge at this time).
> >
> > Should I file a bug in bugs.kde.org or is that somehow a known issue?
> >
> > Thanks
> 
> Probably you have something strange bound to this shortcut. Does the
> problem exist for a newly created user (with empty ~/.config and
> ~/.cache) ?

The trees ~/.config and ~/.cache have been copied from the 2020's system
which is still in use. But I will follow your advice and test with a
newly created user.

Thanks

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Re: CPU consumtion by kglobalaccel / Xorg (was: Fwd: xorg-server-21.1.8_2,1 && key Control_L)

[Gleb Popov]

On Mon, Sep 18, 2023 at 10:42 AM Matthias Apitz  wrote:
>
>
> I investigated the problem described below further and modified
> ~/.xinitrc to not start plasma, but twm and one xterm. The issue depends
> clearly on KDE5. On KeyPress event of Control_L the two processes
> Xorg and kglobalaccel jump in top on the list, Xorg with 30++%.
>
> If one uses multiple time Control_L + TAB to rotate between the virtual
> desktops, this is lazy at the beginning and later the requests get
> somehow stacked nd re-played by its own like a movie.
>
> This is not with my older laptop installation with ports from end of
> 2020 (which have been bleeding edge at this time).
>
> Should I file a bug in bugs.kde.org or is that somehow a known issue?
>
> Thanks

Probably you have something strange bound to this shortcut. Does the
problem exist for a newly created user (with empty ~/.config and
~/.cache) ?

Re: www/qt5-webengine does not build on 14.0-x and 15.0-CURRENT

[Rainer Hurling]

Hi Michael,

Am 14.09.23 um 00:36 schrieb Michael Butler:

On 9/13/23 05:02, Rainer Hurling wrote:
/usr/local/bin/ld: warning: libre2.so.10, needed by 
/usr/local/lib/qt5/libQt5WebEngineCore.so, not found (try using -rpath 
or -rpath-link)


  .. would seem to suggest that it's picking up the previously installed 
library and failing because it was linked to the now replaced libre2.so.


To fix, you might try .. saving the currently installed version with 
'pkg create qt5-webengine' (just in case ;-)); remove it with 'pkg 
delete -f qt5-webeingine' and then build and install the updated port 
from a cleaned port directory. If that fails, you can always reinstall 
what was there with 'pkg add qt5-webengine-5.15.8_5.pkg' or whatever the 
'create' command built.


You are right. Removing the installed version before rebuilding it does 
the trick!


Many thanks :)

Best wishes,
Rainer



I'm taking this approach myself but it'll take more than a few hours on 
this laptop (i5-3340) to confirm :-(


 Michael

Re: www/qt5-webengine does not build on 14.0-x and 15.0-CURRENT

[Michael Butler]

On 9/13/23 05:02, Rainer Hurling wrote:
/usr/local/bin/ld: warning: libre2.so.10, needed by 
/usr/local/lib/qt5/libQt5WebEngineCore.so, not found (try using -rpath 
or -rpath-link)


 .. would seem to suggest that it's picking up the previously installed 
library and failing because it was linked to the now replaced libre2.so.


To fix, you might try .. saving the currently installed version with 
'pkg create qt5-webengine' (just in case ;-)); remove it with 'pkg 
delete -f qt5-webeingine' and then build and install the updated port 
from a cleaned port directory. If that fails, you can always reinstall 
what was there with 'pkg add qt5-webengine-5.15.8_5.pkg' or whatever the 
'create' command built.


I'm taking this approach myself but it'll take more than a few hours on 
this laptop (i5-3340) to confirm :-(


Michael

Re: www/qt5-webengine does not build on 14.0-x and 15.0-CURRENT

[Rainer Hurling]

Moin Tobias,

Am 13.09.23 um 08:07 schrieb Tobias C. Berner:

Moin moin

Should be fixed with 190bd2d090115c5c38661198d16fd55288aeb9c1


Many thanks for the quick fix! In Poudriere the patched version now 
builds well under 15.0-CURRENT.


Unfortunately, there is a (new) problem in unclean environments. If 
devel/re2 is installed (needed for chromium, electron2x, etc.), the 
build aborts with error message, see below:



mfg Tobias

On Wed, 13 Sept 2023 at 07:30, Rainer Hurling  wrote:


Dear KDE-Team, dear devs,

On 14.0-x and 15.0-CURRENT, I am no longer able to build
www/qt5-webengine. The following error is triggered in an unclean
environment and even in Poudriere:


[ 49% 12002/24388] CXX
obj/gpu/command_buffer/service/gles2_sources/program_manager.o
FAILED: obj/gpu/command_buffer/service/gles2_sources/program_manager.o
[..snip..]
../../../../qtwebengine-everywhere-src-5.15.8/src/3rdparty/chromium/gpu/command_buffer/service/program_manager.cc:627:25:
error: no member named 'as_string' in 'absl::string_view'
return output + input.as_string();
~ ^

If a full build log is needed, I can provide it. Thanks in advance for
any help.

Best wishes,
Rainer Hurling



[..snip..]
ninja: Entering directory 
`/usr/ports/www/qt5-webengine/work/.build/src/core/release'

ninja: no work to do.
cd api/ && ( test -e Makefile.core_api || /usr/local/lib/qt5/bin/qmake 
-o Makefile.core_api 
/usr/ports/www/qt5-webengine/work/qtwebengine-everywhere-src-5.15.8/src/core/api/core_api.pro 
-spec /usr/local/lib/qt5/mkspecs/freebsd-clang 'QMAKE_CC=cc 
-B/usr/local/bin' 'QMAKE_CXX=c++ -B/usr/local/bin' 'QMAKE_LINK_C=cc 
-B/usr/local/bin' 'QMAKE_LINK_C_SHLIB=cc -B/usr/local/bin' 
'QMAKE_LINK=c++ -B/usr/local/bin' 'QMAKE_LINK_SHLIB=c++ 
-B/usr/local/bin' 'QMAKE_CFLAGS=-O2 -pipe  -fstack-protector-strong 
-fno-strict-aliasing ' 'QMAKE_CXXFLAGS=-O2 -pipe 
-fstack-protector-strong -fno-strict-aliasing  ' 'QMAKE_LFLAGS= 
-Wl,--as-needed -fstack-protector-strong ' QMAKE_LIBS= 
QMAKE_CFLAGS_DEBUG= QMAKE_CFLAGS_RELEASE= QMAKE_CXXFLAGS_DEBUG= 
QMAKE_CXXFLAGS_RELEASE= PREFIX=/usr/local CONFIG+=release 'CONFIG-=debug 
separate_debug_info' QT_CONFIG+=release 'QT_CONFIG-=debug 
separate_debug_info' ) && /usr/bin/make -f Makefile.core_api
( test -e Makefile.core_module || /usr/local/lib/qt5/bin/qmake -o 
Makefile.core_module 
/usr/ports/www/qt5-webengine/work/qtwebengine-everywhere-src-5.15.8/src/core/core_module.pro 
-spec /usr/local/lib/qt5/mkspecs/freebsd-clang 'QMAKE_CC=cc 
-B/usr/local/bin' 'QMAKE_CXX=c++ -B/usr/local/bin' 'QMAKE_LINK_C=cc 
-B/usr/local/bin' 'QMAKE_LINK_C_SHLIB=cc -B/usr/local/bin' 
'QMAKE_LINK=c++ -B/usr/local/bin' 'QMAKE_LINK_SHLIB=c++ 
-B/usr/local/bin' 'QMAKE_CFLAGS=-O2 -pipe  -fstack-protector-strong 
-fno-strict-aliasing ' 'QMAKE_CXXFLAGS=-O2 -pipe 
-fstack-protector-strong -fno-strict-aliasing  ' 'QMAKE_LFLAGS= 
-Wl,--as-needed -fstack-protector-strong ' QMAKE_LIBS= 
QMAKE_CFLAGS_DEBUG= QMAKE_CFLAGS_RELEASE= QMAKE_CXXFLAGS_DEBUG= 
QMAKE_CXXFLAGS_RELEASE= PREFIX=/usr/local CONFIG+=release 'CONFIG-=debug 
separate_debug_info' QT_CONFIG+=release 'QT_CONFIG-=debug 
separate_debug_info' ) && /usr/bin/make -f Makefile.core_module
cd process/ && ( test -e Makefile || /usr/local/lib/qt5/bin/qmake -o 
Makefile 
/usr/ports/www/qt5-webengine/work/qtwebengine-everywhere-src-5.15.8/src/process/process.pro 
-spec /usr/local/lib/qt5/mkspecs/freebsd-clang 'QMAKE_CC=cc 
-B/usr/local/bin' 'QMAKE_CXX=c++ -B/usr/local/bin' 'QMAKE_LINK_C=cc 
-B/usr/local/bin' 'QMAKE_LINK_C_SHLIB=cc -B/usr/local/bin' 
'QMAKE_LINK=c++ -B/usr/local/bin' 'QMAKE_LINK_SHLIB=c++ 
-B/usr/local/bin' 'QMAKE_CFLAGS=-O2 -pipe  -fstack-protector-strong 
-fno-strict-aliasing ' 'QMAKE_CXXFLAGS=-O2 -pipe 
-fstack-protector-strong -fno-strict-aliasing  ' 'QMAKE_LFLAGS= 
-Wl,--as-needed -fstack-protector-strong ' QMAKE_LIBS= 
QMAKE_CFLAGS_DEBUG= QMAKE_CFLAGS_RELEASE= QMAKE_CXXFLAGS_DEBUG= 
QMAKE_CXXFLAGS_RELEASE= PREFIX=/usr/local CONFIG+=release 'CONFIG-=debug 
separate_debug_info' QT_CONFIG+=release 'QT_CONFIG-=debug 
separate_debug_info' ) && /usr/bin/make -f Makefile
c++ -B/usr/local/bin -Wl,--as-needed -fstack-protector-strong -pthread 
-Wl,-rpath,/usr/local/lib/qt5 -Wl,-rpath-link,/usr/local/lib/qt5 -o 
../../libexec/QtWebEngineProcess .obj/main.o 
-L/usr/ports/www/qt5-webengine/work/.build/lib -L/usr/local/lib 
/usr/local/lib/qt5/libQt5Gui.so /usr/local/lib/qt5/libQt5Core.so -lGL 
/usr/local/lib/qt5/libQt5WebEngineCore.so 
/usr/local/lib/qt5/libQt5Quick.so /usr/local/lib/qt5/libQt5QmlModels.so 
/usr/local/lib/qt5/libQt5WebChannel.so /usr/local/lib/qt5/libQt5Qml.so 
/usr/local/lib/qt5/libQt5Network.so /usr/local/lib/qt5/libQt5Gui.so 
/usr/local/lib/qt5/libQt5Positioning.so /usr/local/lib/qt5/libQt5Core.so
/usr/local/bin/ld: warning: libre2.so.10, needed by 
/usr/local/lib/qt5/libQt5WebEngineCore.so, not found (try using -rpath 
or -rpath-link)
/usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined 
reference to 

Re: www/qt5-webengine does not build on 14.0-x and 15.0-CURRENT

[Tobias C. Berner]

Moin moin

Should be fixed with 190bd2d090115c5c38661198d16fd55288aeb9c1

mfg Tobias

On Wed, 13 Sept 2023 at 07:30, Rainer Hurling  wrote:
>
> Dear KDE-Team, dear devs,
>
> On 14.0-x and 15.0-CURRENT, I am no longer able to build
> www/qt5-webengine. The following error is triggered in an unclean
> environment and even in Poudriere:
>
>
> [ 49% 12002/24388] CXX
> obj/gpu/command_buffer/service/gles2_sources/program_manager.o
> FAILED: obj/gpu/command_buffer/service/gles2_sources/program_manager.o
> [..snip..]
> ../../../../qtwebengine-everywhere-src-5.15.8/src/3rdparty/chromium/gpu/command_buffer/service/program_manager.cc:627:25:
> error: no member named 'as_string' in 'absl::string_view'
>return output + input.as_string();
>~ ^
>
> If a full build log is needed, I can provide it. Thanks in advance for
> any help.
>
> Best wishes,
> Rainer Hurling

Re: FreeBSD KDE Broke

[Thomas Covert]

Thank you I really appreciate your quick reply. Can't wait for a fix

Sent from my T-Mobile 5G Device
Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Tobias C. Berner 
Sent: Sunday, August 20, 2023 2:13:13 AM
To: Thomas Covert 
Cc: k...@freebsd.org 
Subject: Re: FreeBSD KDE Broke

Moin moin

This issue was previously reported already. There seems to be a
missing bump in appstream after updates to libxmlb.


mfg Tobias

p.s.: if you want to help, feel free to drop in #freebsd-desktop on libera.

On Sat, 19 Aug 2023 at 10:04, Thomas Covert  wrote:
>
> What is going on with KDE on FreeBSD? I have Windows 11 FreeBSD 14 Aplha1 and 
> NixOs and Kali Purple Linux all on Partitions that I can boot from each. So 
> about a week ago a KDE update on FreeBSD completely broke my system with this 
> error below when you click on Panel for apps i use Latte Docks but it happens 
> on default apps Panel. I sent a screenshot of error. So I had to compile 
> XFCE4 to even use my system. I have used KDE since the beginning and have 
> stuck with KDE on all my Linux and FreeBSD systems. I am getting so tired of 
> this. Its like FreeBSD is not as important as Linux. All my updates on all my 
> Linux systems go with NO problems at all. But almost always updates of KDE on 
> FreeBSD mess up my system. I use FreeBSD as my main OS so I really need my 
> system up and running. So this error lasted for about 3 updates and just 
> yesterday a KDE update fixed this error. But Today KDE Plasma updates AGAIN 
> and wow the error is back. I gotta say I was really impressed with XFCE4 it 
> compiled with NO errors and it runs like a dream. I really want KDE to work 
> on FreeBSD but I cant lie im about to switch and do away with KDE if these 
> BUGS continue to happen. Does anyone TEST these updates before they put them 
> out?  You try and get answers on FreeBSD and KDE forums and you never get a 
> answer how to fix ANYTHING on KDE. Do you need to GET a NEW Team working on 
> FreeBSD? They would not want to work for me because I would not TOLERATE 
> this. FreeBSD is just as important as Linux and much better. Please can we 
> get this problem fixed? I LOVE KDE but theirs to many problems with the KDE 
> ports and Updates and when an updates takes down my system that cost me money 
> I have to consider doing away with KDE that's SAD.
>
>
> file:///usr/local/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/Kickoff.qml:19:1:
>  plugin cannot be loaded for module "org.kde.plasma.private.kicker": Cannot 
> load library 
> /usr/local/lib/qt5/qml/org/kde/plasma/private/kicker/libkickerplugin.so: 
> (/usr/local/lib/libxmlb.so.2: version LIBXMLB_0.1.0 required by 
> /usr/local/lib/libappstream.so.4 not defined)
>
>
>

Re: FreeBSD KDE Broke

[Tobias C. Berner]

Moin moin

This issue was previously reported already. There seems to be a
missing bump in appstream after updates to libxmlb.


mfg Tobias

p.s.: if you want to help, feel free to drop in #freebsd-desktop on libera.

On Sat, 19 Aug 2023 at 10:04, Thomas Covert  wrote:
>
> What is going on with KDE on FreeBSD? I have Windows 11 FreeBSD 14 Aplha1 and 
> NixOs and Kali Purple Linux all on Partitions that I can boot from each. So 
> about a week ago a KDE update on FreeBSD completely broke my system with this 
> error below when you click on Panel for apps i use Latte Docks but it happens 
> on default apps Panel. I sent a screenshot of error. So I had to compile 
> XFCE4 to even use my system. I have used KDE since the beginning and have 
> stuck with KDE on all my Linux and FreeBSD systems. I am getting so tired of 
> this. Its like FreeBSD is not as important as Linux. All my updates on all my 
> Linux systems go with NO problems at all. But almost always updates of KDE on 
> FreeBSD mess up my system. I use FreeBSD as my main OS so I really need my 
> system up and running. So this error lasted for about 3 updates and just 
> yesterday a KDE update fixed this error. But Today KDE Plasma updates AGAIN 
> and wow the error is back. I gotta say I was really impressed with XFCE4 it 
> compiled with NO errors and it runs like a dream. I really want KDE to work 
> on FreeBSD but I cant lie im about to switch and do away with KDE if these 
> BUGS continue to happen. Does anyone TEST these updates before they put them 
> out?  You try and get answers on FreeBSD and KDE forums and you never get a 
> answer how to fix ANYTHING on KDE. Do you need to GET a NEW Team working on 
> FreeBSD? They would not want to work for me because I would not TOLERATE 
> this. FreeBSD is just as important as Linux and much better. Please can we 
> get this problem fixed? I LOVE KDE but theirs to many problems with the KDE 
> ports and Updates and when an updates takes down my system that cost me money 
> I have to consider doing away with KDE that's SAD.
>
>
> file:///usr/local/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/Kickoff.qml:19:1:
>  plugin cannot be loaded for module "org.kde.plasma.private.kicker": Cannot 
> load library 
> /usr/local/lib/qt5/qml/org/kde/plasma/private/kicker/libkickerplugin.so: 
> (/usr/local/lib/libxmlb.so.2: version LIBXMLB_0.1.0 required by 
> /usr/local/lib/libappstream.so.4 not defined)
>
>
>

Re: KDE Plasma Kickoff does not work after libxmlb update

[Rainer Hurling]

Hi Tobias,

Am 15.08.2023 um 21:13 schrieb Tobias C. Berner:

HI Rainer

Could you try to re-install the devel/appstream package, -- it likely
should have been bumped in the libxmlb update.


I had already reinstalled appstream-glib and libxmlb and it didn't help :(

Interestingly, the starter (kickoff) in one of my 14.0 boxes works again 
as expected. Probably it is due to some other combination of 
dependencies ...


Best wishes,
Rainer




mfg Tobias

On Mon, 14 Aug 2023 at 15:01, Rainer Hurling  wrote:


Hi KDE team,

After the update of textproc/libxmlb [1], the KDE Plasma Kickoff no
longer works. If I try to use Kickoff from the taskbar, I get the
following message box:

file:///usr/local/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/Kickoff.qml:19:1:
plugin cannot be loaded for module "org.kde.plasma.private.kicker":
Cannot load library
/usr/local/lib/qt5/qml/org/kde/plasma/private/kicker/libkickerplugin.so:
(/usr/local/lib/libxmlb.so.2: version LIBXMLB_0.1.0 required by
/usr/local/lib/libappstream.so.4 not defined)

This is on a recent 14.0-ALPHA1 amd64 with ports up to date.

Is there anything I can do to get it working again?

Thanks for any hint. Please let me know, if you need more details or if
there is anything I can test.

Best regards,
Rainer Hurling


[1]
https://cgit.freebsd.org/ports/commit/?id=e425bfcc5c7bc9f0ca1718ebc06774eaec3ef5f5

Re: KDE Plasma Kickoff does not work after libxmlb update

[Tobias C. Berner]

HI Rainer

Could you try to re-install the devel/appstream package, -- it likely
should have been bumped in the libxmlb update.

mfg Tobias

On Mon, 14 Aug 2023 at 15:01, Rainer Hurling  wrote:
>
> Hi KDE team,
>
> After the update of textproc/libxmlb [1], the KDE Plasma Kickoff no
> longer works. If I try to use Kickoff from the taskbar, I get the
> following message box:
>
> file:///usr/local/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/Kickoff.qml:19:1:
> plugin cannot be loaded for module "org.kde.plasma.private.kicker":
> Cannot load library
> /usr/local/lib/qt5/qml/org/kde/plasma/private/kicker/libkickerplugin.so:
> (/usr/local/lib/libxmlb.so.2: version LIBXMLB_0.1.0 required by
> /usr/local/lib/libappstream.so.4 not defined)
>
> This is on a recent 14.0-ALPHA1 amd64 with ports up to date.
>
> Is there anything I can do to get it working again?
>
> Thanks for any hint. Please let me know, if you need more details or if
> there is anything I can test.
>
> Best regards,
> Rainer Hurling
>
>
> [1]
> https://cgit.freebsd.org/ports/commit/?id=e425bfcc5c7bc9f0ca1718ebc06774eaec3ef5f5
>
>

Re: KDE5 question

[Adriaan de Groot]

On Monday, 24 July 2023 15:28:59 CEST Paul Pham wrote:
> I was wondering whether there is a KDE5 way of reading these variables that
> help me start IBUS below as for myself I tried the equivalent of
> $HOME/.kde4/env for KDE5 (unsuccessfully) which was tested first on KDE4 by
> someone (successfully). Things work instead if I set those variables in my
> shell startup script.

Hello Paul Pham,

On FreeBSD it shouldn't be any different than on Linuxes, whatever it is that 
is needed to start ibus / input methods on startup. That said, I don't see 
easy and conclusive instructions on Linux either: Arch suggests putting things 
in /etc/environment and then also adding an autostart entry. 

https://userbase.kde.org/Tutorials/Kimpanel might be relevant.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: graphics/qgis: Can't build after PyQt5 update anymore

[Rainer Hurling]

Am 30.07.23 um 09:10 schrieb Rainer Hurling:

Hi devs,

After update of Qscintilla (and other Qt/KDE related ports) a few days 
before I am not able to build graphics/qgis anymore:


[...]
sip-build: 
/usr/local/lib/python3.9/site-packages/PyQt5/bindings/Qsci/qscimodcommon.sip: line 63: column 10: 'qscilexerasm.sip' could not be found

/usr/local/lib/python3.9/site-packages/PyQt5/bindings/Qsci/qscimodcommon.sip: 
line 77: column 10: 'qscilexerhex.sip' could not be found
/usr/local/lib/python3.9/site-packages/PyQt5/bindings/Qsci/qscimodcommon.sip: 
line 80: column 10: 'qscilexerintelhex.sip' could not be found
/usr/local/lib/python3.9/site-packages/PyQt5/bindings/Qsci/qscimodcommon.sip: 
line 87: column 10: 'qscilexermasm.sip' could not be found
/usr/local/lib/python3.9/site-packages/PyQt5/bindings/Qsci/qscimodcommon.sip: 
line 89: column 10: 'qscilexernasm.sip' could not be found
/usr/local/lib/python3.9/site-packages/PyQt5/bindings/Qsci/qscimodcommon.sip: 
line 101: column 10: 'qscilexersrec.sip' could not be found
/usr/local/lib/python3.9/site-packages/PyQt5/bindings/Qsci/qscimodcommon.sip: 
line 103: column 10: 'qscilexertekhex.sip' could not be found
gmake[4]: *** 
[python/CMakeFiles/python_module_qgis__gui.dir/build.make:1325: 
python/gui/build/_gui/sip_guipart0.cpp] Error 1

gmake[4]: Leaving directory '/usr/ports/graphics/qgis/work/.build'
gmake[3]: *** [CMakeFiles/Makefile2:10492: 
python/CMakeFiles/python_module_qgis__gui.dir/all] Error 2



The files qscimodcommon.sip complains about are indeed not present.

This is on a recent 14.0-CURRENT amd64.

Any ideas?

Regards,
Rainer Hurling


I think I found the reason for the breakage. The not updated pkg-plist 
of devel/py-qt5-qscintilla2 was the reason, that some files where not 
installed before. I filed a PR on Bugzilla:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272817

Re: Unresolved symbol in libQt6WebEngineCore.so.6.4.2

[Alexander Leidinger]

Quoting Jan Beich  (from Mon, 24 Jul 2023 14:50:48 +0200):


Alexander Leidinger  writes:

Quoting Jan Beich  (from Mon, 24 Jul 2023  
13:52:43 +0200):



Alexander Leidinger  writes:


Hi,

a build with non-standard port options (mostly nox11 und related stuff
for a headless system, except for some ports where this doesn't work)
is giving me an unresolved symbol in
libQt6WebEngineCore.so.6.4.2. This symbol is
_ZN7sandbox6policy12SandboxLinux11GetInstanceEv.

I'm seeking some insight where this symbol comes from, so it would be
nice if someone could report back if their
libQt6WebEngineCore.so.6.4.2 also has this symbol as unresolved and
which libary does provide this symbol via:
  find /usr/local/lib -type f -print0 | xargs -0 nm -dynamic
  --print-file-name | grep SandboxLinux


The symbol is defined by WebEngine itself.

$ cd www/qt6-webengine
$ make clean patch
$ cd `make -V WRKSRC`
$ rg -lF 'SandboxLinux::GetInstance() {'
src/3rdparty/chromium/sandbox/policy/linux/sandbox_linux.cc
src/3rdparty/chromium/sandbox/policy/openbsd/sandbox_openbsd.cc
src/3rdparty/chromium/sandbox/policy/freebsd/sandbox_freebsd.cc


That doesn't sound promising. The qt6-webengine build succeeded, but
this symbol is missing... :(
As the port only has the audio options, it's not some direct influence
which is causing it, but some indirect dependency on something in the
dependecy chain I would assume.


If -Wl,--no-undefined (or -Wl,-z,defs) isn't passed then DSOs are
allowed to have unresolved references. This is useful for plugins
unlike shared libraries.


But then the sandbox code should be linked in even if there are some  
symbols (e.g. from X11) not available...



I had a look at the faq and explanation of the sandbox at
chromium.googlesource.com, but I didn't see any low level stuff which
could help to identify why it isn't in the lib.


Check the build glue and/or ifdefs.

src/3rdparty/chromium/sandbox/policy/BUILD.gn:

  if ((is_linux || is_chromeos) && !is_bsd) {
sources += [
...
  "linux/sandbox_linux.cc",
  "linux/sandbox_linux.h",
...
]
  ...
  }
  if (is_openbsd) {
sources += [
  "openbsd/sandbox_openbsd.cc",
  "openbsd/sandbox_openbsd.h",
]
  ...
  }
  # Required to avoid assertion errors during build of QtPDF
  if (is_freebsd && ozone_platform_x11) {
sources += [
  "freebsd/sandbox_freebsd.cc",
  "freebsd/sandbox_freebsd.h",
]
  ...
  }

src/3rdparty/chromium/build/config/ozone.gni:

} else if (is_linux && !is_bsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = true
  ozone_platform_x11 = true
} else if (is_openbsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = false
  ozone_platform_x11 = true
} else if (is_freebsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = true
  ozone_platform_x11 = true



In general I have X11 and wayland disabled in the port options, except  
in some strategic places which resulted in build failures before.  
Seems some ports have changed regarding this and I need to find out  
what causes the sandbox code not to be included. I see references to  
X11 libs in the webengine libs, so :

---snip---
/usr/local/lib/qt6/libQt6WebEngineCore.so.6.4.2:
libthr.so.3 => /lib/libthr.so.3 (0x2762513e)
libnss3.so => /usr/local/lib/libnss3.so (0x27625c482000)
libsmime3.so => /usr/local/lib/libsmime3.so (0x27625bb0c000)
libnssutil3.so => /usr/local/lib/libnssutil3.so (0x27625d457000)
libplds4.so => /usr/local/lib/libplds4.so (0x27625dd34000)
libplc4.so => /usr/local/lib/libplc4.so (0x27625ef9f000)
libnspr4.so => /usr/local/lib/libnspr4.so (0x27625e74)
libdl.so.1 => /usr/lib/libdl.so.1 (0x27625fb67000)
libkvm.so.7 => /lib/libkvm.so.7 (0x2762606d3000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x276260b5a000)
libutil.so.9 => /lib/libutil.so.9 (0x2762625a6000)
libevent-2.1.so.7 => /usr/local/lib/libevent-2.1.so.7 (0x2762617bd000)
libz.so.6 => /lib/libz.so.6 (0x276263772000)
libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x276262755000)
libm.so.5 => /lib/libm.so.5 (0x2762646e6000)
libopus.so.0 => /usr/local/lib/libopus.so.0 (0x2762655ce000)
libavcodec.so.60 => /usr/local/lib/libavcodec.so.60 (0x276268c0)
libavformat.so.60 => /usr/local/lib/libavformat.so.60 (0x27626573)
libavutil.so.58 => /usr/local/lib/libavutil.so.58 (0x2762660a4000)
libopenh264.so.6 => /usr/local/lib/libopenh264.so.6 (0x276266a54000)
libvpx.so.8 => /usr/local/lib/libvpx.so.8 (0x27626773d000)
libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1  
(0x2762689f2000)

libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x27626b144000)
libwebp.so.7 => /usr/local/lib/libwebp.so.7 (0x27626cfce000)
libwebpmux.so.3 => /usr/local/lib/libwebpmux.so.3 (0x27626a5c6000)
libwebpdemux.so.2 => 

Re: Unresolved symbol in libQt6WebEngineCore.so.6.4.2

[Alexander Leidinger]

Quoting Jan Beich  (from Mon, 24 Jul 2023 14:50:48 +0200):


Alexander Leidinger  writes:

Quoting Jan Beich  (from Mon, 24 Jul 2023  
13:52:43 +0200):



Alexander Leidinger  writes:


Hi,

a build with non-standard port options (mostly nox11 und related stuff
for a headless system, except for some ports where this doesn't work)
is giving me an unresolved symbol in
libQt6WebEngineCore.so.6.4.2. This symbol is
_ZN7sandbox6policy12SandboxLinux11GetInstanceEv.

I'm seeking some insight where this symbol comes from, so it would be
nice if someone could report back if their
libQt6WebEngineCore.so.6.4.2 also has this symbol as unresolved and
which libary does provide this symbol via:
  find /usr/local/lib -type f -print0 | xargs -0 nm -dynamic
  --print-file-name | grep SandboxLinux


The symbol is defined by WebEngine itself.

$ cd www/qt6-webengine
$ make clean patch
$ cd `make -V WRKSRC`
$ rg -lF 'SandboxLinux::GetInstance() {'
src/3rdparty/chromium/sandbox/policy/linux/sandbox_linux.cc
src/3rdparty/chromium/sandbox/policy/openbsd/sandbox_openbsd.cc
src/3rdparty/chromium/sandbox/policy/freebsd/sandbox_freebsd.cc


That doesn't sound promising. The qt6-webengine build succeeded, but
this symbol is missing... :(
As the port only has the audio options, it's not some direct influence
which is causing it, but some indirect dependency on something in the
dependecy chain I would assume.


If -Wl,--no-undefined (or -Wl,-z,defs) isn't passed then DSOs are
allowed to have unresolved references. This is useful for plugins
unlike shared libraries.


But then the sandbox code should be linked in even if there are some  
symbols (e.g. from X11) not available...



I had a look at the faq and explanation of the sandbox at
chromium.googlesource.com, but I didn't see any low level stuff which
could help to identify why it isn't in the lib.


Check the build glue and/or ifdefs.

src/3rdparty/chromium/sandbox/policy/BUILD.gn:

  if ((is_linux || is_chromeos) && !is_bsd) {
sources += [
...
  "linux/sandbox_linux.cc",
  "linux/sandbox_linux.h",
...
]
  ...
  }
  if (is_openbsd) {
sources += [
  "openbsd/sandbox_openbsd.cc",
  "openbsd/sandbox_openbsd.h",
]
  ...
  }
  # Required to avoid assertion errors during build of QtPDF
  if (is_freebsd && ozone_platform_x11) {
sources += [
  "freebsd/sandbox_freebsd.cc",
  "freebsd/sandbox_freebsd.h",
]
  ...
  }

src/3rdparty/chromium/build/config/ozone.gni:

} else if (is_linux && !is_bsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = true
  ozone_platform_x11 = true
} else if (is_openbsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = false
  ozone_platform_x11 = true
} else if (is_freebsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = true
  ozone_platform_x11 = true



In general I have X11 and wayland disabled in the port options, except  
in some strategic places which resulted in build failures before.  
Seems some ports have changed regarding this and I need to find out  
what causes the sandbox code not to be included. I see references to  
X11 libs in the webengine libs, so :

---snip---
/usr/local/lib/qt6/libQt6WebEngineCore.so.6.4.2:
libthr.so.3 => /lib/libthr.so.3 (0x2762513e)
libnss3.so => /usr/local/lib/libnss3.so (0x27625c482000)
libsmime3.so => /usr/local/lib/libsmime3.so (0x27625bb0c000)
libnssutil3.so => /usr/local/lib/libnssutil3.so (0x27625d457000)
libplds4.so => /usr/local/lib/libplds4.so (0x27625dd34000)
libplc4.so => /usr/local/lib/libplc4.so (0x27625ef9f000)
libnspr4.so => /usr/local/lib/libnspr4.so (0x27625e74)
libdl.so.1 => /usr/lib/libdl.so.1 (0x27625fb67000)
libkvm.so.7 => /lib/libkvm.so.7 (0x2762606d3000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x276260b5a000)
libutil.so.9 => /lib/libutil.so.9 (0x2762625a6000)
libevent-2.1.so.7 => /usr/local/lib/libevent-2.1.so.7 (0x2762617bd000)
libz.so.6 => /lib/libz.so.6 (0x276263772000)
libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x276262755000)
libm.so.5 => /lib/libm.so.5 (0x2762646e6000)
libopus.so.0 => /usr/local/lib/libopus.so.0 (0x2762655ce000)
libavcodec.so.60 => /usr/local/lib/libavcodec.so.60 (0x276268c0)
libavformat.so.60 => /usr/local/lib/libavformat.so.60 (0x27626573)
libavutil.so.58 => /usr/local/lib/libavutil.so.58 (0x2762660a4000)
libopenh264.so.6 => /usr/local/lib/libopenh264.so.6 (0x276266a54000)
libvpx.so.8 => /usr/local/lib/libvpx.so.8 (0x27626773d000)
libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1  
(0x2762689f2000)

libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x27626b144000)
libwebp.so.7 => /usr/local/lib/libwebp.so.7 (0x27626cfce000)
libwebpmux.so.3 => /usr/local/lib/libwebpmux.so.3 (0x27626a5c6000)
libwebpdemux.so.2 => 

Re: Unresolved symbol in libQt6WebEngineCore.so.6.4.2

[Alexander Leidinger]

Quoting Jan Beich  (from Mon, 24 Jul 2023 13:52:43 +0200):


Alexander Leidinger  writes:


Hi,

a build with non-standard port options (mostly nox11 und related stuff
for a headless system, except for some ports where this doesn't work)
is giving me an unresolved symbol in
libQt6WebEngineCore.so.6.4.2. This symbol is
_ZN7sandbox6policy12SandboxLinux11GetInstanceEv.

I'm seeking some insight where this symbol comes from, so it would be
nice if someone could report back if their
libQt6WebEngineCore.so.6.4.2 also has this symbol as unresolved and
which libary does provide this symbol via:
  find /usr/local/lib -type f -print0 | xargs -0 nm -dynamic
  --print-file-name | grep SandboxLinux


The symbol is defined by WebEngine itself.

$ cd www/qt6-webengine
$ make clean patch
$ cd `make -V WRKSRC`
$ rg -lF 'SandboxLinux::GetInstance() {'
src/3rdparty/chromium/sandbox/policy/linux/sandbox_linux.cc
src/3rdparty/chromium/sandbox/policy/openbsd/sandbox_openbsd.cc
src/3rdparty/chromium/sandbox/policy/freebsd/sandbox_freebsd.cc


That doesn't sound promising. The qt6-webengine build succeeded, but  
this symbol is missing... :(
As the port only has the audio options, it's not some direct influence  
which is causing it, but some indirect dependency on something in the  
dependecy chain I would assume.


I had a look at the faq and explanation of the sandbox at  
chromium.googlesource.com, but I didn't see any low level stuff which  
could help to identify why it isn't in the lib.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpqFgHX67ChD.pgp
Description: Digitale PGP-Signatur

Re: Unresolved symbol in libQt6WebEngineCore.so.6.4.2

[Jan Beich]

Alexander Leidinger  writes:

> Quoting Jan Beich  (from Mon, 24 Jul 2023 13:52:43 +0200):
>
>> Alexander Leidinger  writes:
>>
>>> Hi,
>>>
>>> a build with non-standard port options (mostly nox11 und related stuff
>>> for a headless system, except for some ports where this doesn't work)
>>> is giving me an unresolved symbol in
>>> libQt6WebEngineCore.so.6.4.2. This symbol is
>>> _ZN7sandbox6policy12SandboxLinux11GetInstanceEv.
>>>
>>> I'm seeking some insight where this symbol comes from, so it would be
>>> nice if someone could report back if their
>>> libQt6WebEngineCore.so.6.4.2 also has this symbol as unresolved and
>>> which libary does provide this symbol via:
>>>   find /usr/local/lib -type f -print0 | xargs -0 nm -dynamic
>>>   --print-file-name | grep SandboxLinux
>>
>> The symbol is defined by WebEngine itself.
>>
>> $ cd www/qt6-webengine
>> $ make clean patch
>> $ cd `make -V WRKSRC`
>> $ rg -lF 'SandboxLinux::GetInstance() {'
>> src/3rdparty/chromium/sandbox/policy/linux/sandbox_linux.cc
>> src/3rdparty/chromium/sandbox/policy/openbsd/sandbox_openbsd.cc
>> src/3rdparty/chromium/sandbox/policy/freebsd/sandbox_freebsd.cc
>
> That doesn't sound promising. The qt6-webengine build succeeded, but
> this symbol is missing... :(
> As the port only has the audio options, it's not some direct influence
> which is causing it, but some indirect dependency on something in the
> dependecy chain I would assume.

If -Wl,--no-undefined (or -Wl,-z,defs) isn't passed then DSOs are
allowed to have unresolved references. This is useful for plugins
unlike shared libraries.

> I had a look at the faq and explanation of the sandbox at
> chromium.googlesource.com, but I didn't see any low level stuff which
> could help to identify why it isn't in the lib.

Check the build glue and/or ifdefs.

src/3rdparty/chromium/sandbox/policy/BUILD.gn:

  if ((is_linux || is_chromeos) && !is_bsd) {
sources += [
...
  "linux/sandbox_linux.cc",
  "linux/sandbox_linux.h",
...
]
  ...
  }
  if (is_openbsd) {
sources += [
  "openbsd/sandbox_openbsd.cc",
  "openbsd/sandbox_openbsd.h",
]
  ...
  }
  # Required to avoid assertion errors during build of QtPDF
  if (is_freebsd && ozone_platform_x11) {
sources += [
  "freebsd/sandbox_freebsd.cc",
  "freebsd/sandbox_freebsd.h",
]
  ...
  }

src/3rdparty/chromium/build/config/ozone.gni:

} else if (is_linux && !is_bsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = true
  ozone_platform_x11 = true
} else if (is_openbsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = false
  ozone_platform_x11 = true
} else if (is_freebsd) {
  ozone_platform = "x11"
  ozone_platform_wayland = true
  ozone_platform_x11 = true

Re: Unresolved symbol in libQt6WebEngineCore.so.6.4.2

[Jan Beich]

Alexander Leidinger  writes:

> Hi,
>
> a build with non-standard port options (mostly nox11 und related stuff
> for a headless system, except for some ports where this doesn't work)
> is giving me an unresolved symbol in
> libQt6WebEngineCore.so.6.4.2. This symbol is
> _ZN7sandbox6policy12SandboxLinux11GetInstanceEv.
>
> I'm seeking some insight where this symbol comes from, so it would be
> nice if someone could report back if their
> libQt6WebEngineCore.so.6.4.2 also has this symbol as unresolved and
> which libary does provide this symbol via:
>   find /usr/local/lib -type f -print0 | xargs -0 nm -dynamic
>   --print-file-name | grep SandboxLinux

The symbol is defined by WebEngine itself.

$ cd www/qt6-webengine
$ make clean patch
$ cd `make -V WRKSRC`
$ rg -lF 'SandboxLinux::GetInstance() {'
src/3rdparty/chromium/sandbox/policy/linux/sandbox_linux.cc
src/3rdparty/chromium/sandbox/policy/openbsd/sandbox_openbsd.cc
src/3rdparty/chromium/sandbox/policy/freebsd/sandbox_freebsd.cc

Re: OpenSSL 3.0 is in the tree

[Rainer Hurling]

Am 03.07.23 um 16:53 schrieb Guido Falsi:

On 03/07/23 15:27, Rainer Hurling wrote:

Am 29.06.23 um 18:27 schrieb Pierre Pronchery:

 Hi Guido, freebsd-current@,

On 6/29/23 15:14, Guido Falsi wrote:

On 24/06/23 16:22, Ed Maste wrote:

Last night I merged OpenSSL 3.0 to main. This, along with the update
to Clang 16 and other recent changes may result in some challenges
over the next few days or weeks for folks following -CURRENT, such as
ports that need to be updated or unanticipated issues in the base
system.

We need to get this work done so that we can continue moving on with
FreeBSD 14; I apologize for the trouble it might cause in the short
term. Please follow up to report any trouble you encounter.


Not sure where to ask this, following up to this announcement looks 
like a reasonable choice.


After updating head to this version I have had some ports provided 
software fail with messages including: "Unable to load legacy 
provider."


Most of the time I am able to workaround it by forcing newer 
algorithms via some configuration. Some other times I have no direct 
control of what is being asked (like values hardcoded in npm modules)/


This is also happening to me with node, for example, has happened 
with RDP (looks like windows by default prefers RC4 for RDP 
sessions), where I was able to fix it though.


Question is, does FreeBSD provide this legacy provider module? Or is 
it available via ports or some other solution? Or maybe it can be 
provided via a port? Would make the transition much easier!


The legacy provider module is part of OpenSSL 3.0, it should be 
installed in /usr/lib/ossl-modules/legacy.so alongside fips.so as 
part Iddd

of the base system.

It's possible that some programs leveraging capsicum will fail to 
load it, if the initialization of legacy algorithms in OpenSSL is 
performed past entering capabilities mode (since it now requires a 
dlopen() to access the module).


Let me know if you have any additional details regarding issues with 
the module.


HTH,


If this thread is not the appropriate one for my problem, I apologize.

I am the maintainer of the graphics/qgis port. Now that my system 
14.0-CURRENT is updated to clang16 and OpenSSL-3.0, I get the 
following abort message when starting qgis:


#qgis
Failed to load Legacy provider

Apparently there is now also a problem with the legacy provider here. 
As I understand it, QGIS uses the port devel/qca for authorization and 
encryption, so it is also possible that devel/qca is not able to 
provide the legacy provider. Therefore I have taken kde@ into CC.


Please let me know, if you need more information or some testing.


This is being worked on by Pierre.

He pointed me to a patch from him, which I tested successfully:

https://github.com/freebsd/freebsd-src/pull/787

I'm now running head with this patch and the legacy provider works fine.

Hope this helps.



I applied the patch. After rebuilding my system, now the legacy provider 
also works fine for me. graphics/qgis starts again and seems to work as 
expected.


Interestingly, when I start QGIS, I now get the following warnings:

Warning: Incompatible version of OpenSSL (built with OpenSSL 1.x, 
runtime version is >= 3.x)

Warning: QSslSocket: cannot call unresolved function d2i_X509
Warning: QSslSocket::connectToHostEncrypted: TLS initialization failed

These warnings disappeared after rebuilding net/qt5-network and 
net/qt5-networkauth :)


Many thanks for the link with the patch!

Best wishes,
Rainer

Re: OpenSSL 3.0 is in the tree

[Guido Falsi]

On 03/07/23 15:27, Rainer Hurling wrote:

Am 29.06.23 um 18:27 schrieb Pierre Pronchery:

 Hi Guido, freebsd-current@,

On 6/29/23 15:14, Guido Falsi wrote:

On 24/06/23 16:22, Ed Maste wrote:

Last night I merged OpenSSL 3.0 to main. This, along with the update
to Clang 16 and other recent changes may result in some challenges
over the next few days or weeks for folks following -CURRENT, such as
ports that need to be updated or unanticipated issues in the base
system.

We need to get this work done so that we can continue moving on with
FreeBSD 14; I apologize for the trouble it might cause in the short
term. Please follow up to report any trouble you encounter.


Not sure where to ask this, following up to this announcement looks 
like a reasonable choice.


After updating head to this version I have had some ports provided 
software fail with messages including: "Unable to load legacy provider."


Most of the time I am able to workaround it by forcing newer 
algorithms via some configuration. Some other times I have no direct 
control of what is being asked (like values hardcoded in npm modules)/


This is also happening to me with node, for example, has happened 
with RDP (looks like windows by default prefers RC4 for RDP 
sessions), where I was able to fix it though.


Question is, does FreeBSD provide this legacy provider module? Or is 
it available via ports or some other solution? Or maybe it can be 
provided via a port? Would make the transition much easier!


The legacy provider module is part of OpenSSL 3.0, it should be 
installed in /usr/lib/ossl-modules/legacy.so alongside fips.so as part 
Iddd

of the base system.

It's possible that some programs leveraging capsicum will fail to load 
it, if the initialization of legacy algorithms in OpenSSL is performed 
past entering capabilities mode (since it now requires a dlopen() to 
access the module).


Let me know if you have any additional details regarding issues with 
the module.


HTH,


If this thread is not the appropriate one for my problem, I apologize.

I am the maintainer of the graphics/qgis port. Now that my system 
14.0-CURRENT is updated to clang16 and OpenSSL-3.0, I get the following 
abort message when starting qgis:


#qgis
Failed to load Legacy provider

Apparently there is now also a problem with the legacy provider here. As 
I understand it, QGIS uses the port devel/qca for authorization and 
encryption, so it is also possible that devel/qca is not able to provide 
the legacy provider. Therefore I have taken kde@ into CC.


Please let me know, if you need more information or some testing.


This is being worked on by Pierre.

He pointed me to a patch from him, which I tested successfully:

https://github.com/freebsd/freebsd-src/pull/787

I'm now running head with this patch and the legacy provider works fine.

Hope this helps.

--
Guido Falsi 

Re: OpenSSL 3.0 is in the tree

[Rainer Hurling]

Am 29.06.23 um 18:27 schrieb Pierre Pronchery:

     Hi Guido, freebsd-current@,

On 6/29/23 15:14, Guido Falsi wrote:

On 24/06/23 16:22, Ed Maste wrote:

Last night I merged OpenSSL 3.0 to main. This, along with the update
to Clang 16 and other recent changes may result in some challenges
over the next few days or weeks for folks following -CURRENT, such as
ports that need to be updated or unanticipated issues in the base
system.

We need to get this work done so that we can continue moving on with
FreeBSD 14; I apologize for the trouble it might cause in the short
term. Please follow up to report any trouble you encounter.


Not sure where to ask this, following up to this announcement looks 
like a reasonable choice.


After updating head to this version I have had some ports provided 
software fail with messages including: "Unable to load legacy provider."


Most of the time I am able to workaround it by forcing newer 
algorithms via some configuration. Some other times I have no direct 
control of what is being asked (like values hardcoded in npm modules)/


This is also happening to me with node, for example, has happened with 
RDP (looks like windows by default prefers RC4 for RDP sessions), 
where I was able to fix it though.


Question is, does FreeBSD provide this legacy provider module? Or is 
it available via ports or some other solution? Or maybe it can be 
provided via a port? Would make the transition much easier!


The legacy provider module is part of OpenSSL 3.0, it should be 
installed in /usr/lib/ossl-modules/legacy.so alongside fips.so as part Iddd

of the base system.

It's possible that some programs leveraging capsicum will fail to load 
it, if the initialization of legacy algorithms in OpenSSL is performed 
past entering capabilities mode (since it now requires a dlopen() to 
access the module).


Let me know if you have any additional details regarding issues with the 
module.


HTH,


If this thread is not the appropriate one for my problem, I apologize.

I am the maintainer of the graphics/qgis port. Now that my system 
14.0-CURRENT is updated to clang16 and OpenSSL-3.0, I get the following 
abort message when starting qgis:


#qgis
Failed to load Legacy provider

Apparently there is now also a problem with the legacy provider here. As 
I understand it, QGIS uses the port devel/qca for authorization and 
encryption, so it is also possible that devel/qca is not able to provide 
the legacy provider. Therefore I have taken kde@ into CC.


Please let me know, if you need more information or some testing.

Thanks for your work,
Rainer

Re: Wireshark + qt5-core with CPU Alderlake and AVX512

[Joe Marcus Clarke]

First, let me say that I wish all reports were this detailed.

It seems to me that if the Qt test in qt5-core that says YES to AVX512 
is succeeding feels like a bug.  But it sounds like you worked around 
this and still see the crash.


This looks similar (though a different instruction) to 
https://forums.freebsd.org/threads/build-host-to-client-issue-incompatible-processor-this-qt-build-requires-the-following-features-aes.69580/. 
 The workaround there was to remove the abort from qt5-core.  That's 
not a solution, though.


I defer to the Qt maintainers and also suggest you report this upstream 
as I feel you would not be alone.


Joe

On 6/21/23 00:17, Francois Ranchin wrote:

Dear maintainers,


I have a new Intel NUC 12th generation 
https://ark.intel.com/content/www/us/en/ark/products/121613/intel-nuc-12-pro-kit-nuc12wski3.html
under freebsd release 13.2

Running wireshark from ports or from source end with :

[1]3187 illegal hardware instruction (core dumped)  wireshark

After some research and try I think it’s a AVX-512 related trouble.

1 - lldb inside the core just show the same pattern with qt5-core ans SIGILL


2 - Intel physically fused off AVX-512 after non uniformity trouble between 
Efficiency and Performance core. https://en.wikipedia.org/wiki/Alder_Lake P 
core and E cores have different set of instructions.

“AVX-512 (including FP16) is present but disabled by default to match E-cores. 
On early revisions of microprocessors it still can be enabled on some 
motherboards with some BIOS versions by disabling the E-cores.[18][19] Intel 
has physically fused off AVX-512 on later revisions of Alder Lake CPUs 
manufactured in early 2022 and onward.[20][21]”

qt5-core can’t obey to instruction to remove AVX-512. Quick force removing 
AVX512 in the source leads to this error :

Incompatible processor. This Qt build requires the following features:
X5^!!
Aborted. Incompatible processor: missing feature 0xc200 -X.
[1]13603 abort (core dumped)  wireshark



——
make config of at5-core :
Checking for AVX512 F instructions... yes
Checking for AVX512 BW instructions... yes
Checking for AVX512 CD instructions... yes
Checking for AVX512 DQ instructions... yes
Checking for AVX512 ER instructions... yes
Checking for AVX512 IFMA instructions... yes
Checking for AVX512 PF instructions... yes
Checking for AVX512 VBMI instructions... yes
Checking for AVX512 VL instructions... yes
[…]
Checking for AVX512 F instructions... yes
Checking for AVX512 BW instructions... yes
Checking for AVX512 CD instructions... yes
Checking for AVX512 DQ instructions... yes
Checking for AVX512 ER instructions... yes
Checking for AVX512 IFMA instructions... yes
Checking for AVX512 PF instructions... yes
Checking for AVX512 VBMI instructions... yes
Checking for AVX512 VL instructions... yes
——

BUT


llvm-tblgen -version
LLVM (http://llvm.org/):
   LLVM version 11.0.1
   Optimized build.
   Default target: x86_64-unknown-freebsd13.0
   Host CPU: goldmont
—

goldmont is an old Atom CPU rebranded inside the E-core of the new non uniform 
Intel CPU… The E-core is likely to be this old Atom architecture.


—
cc -v -x c -E -march=native /dev/null -o /dev/null

FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git 
llvmorg-14.0.5-0-gc12386ae247c)
Target: x86_64-unknown-freebsd13.2
Thread model: posix
InstalledDir: /usr/bin
  (in-process)
  "/usr/bin/cc" -cc1 -triple x86_64-unknown-freebsd13.2 -E -disable-free 
-clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name 
null -mrelocation-model static -mframe-pointer=all -ffp-contract=on -fno-rounding-math 
-mconstructor-aliases -funwind-tables=2 -target-cpu alderlake -target-feature -avx512pf 
-target-feature -tsxldtrk -target-feature +cx16 -target-feature +sahf -target-feature 
-tbm -target-feature -avx512ifma -target-feature +sha -target-feature +crc32 
-target-feature -fma4 -target-feature +vpclmulqdq -target-feature +prfchw -target-feature 
+bmi2 -target-feature -cldemote -target-feature +fsgsbase -target-feature +ptwrite 
-target-feature -amx-tile -target-feature -uintr -target-feature +gfni -target-feature 
+popcnt -target-feature -widekl -target-feature +aes -target-feature -avx512bitalg 
-target-feature +movdiri -target-feature +xsaves -target-feature -avx512er 
-target-feature +avxvnni -target-feature -avx512fp16 -target-feature -avx512vnni 
-target-feature -amx-bf16 -target-feature -avx512vpopcntdq -target-feature -pconfig 
-target-feature +clwb -target-feature -avx512f -target-feature +xsavec -target-feature 
-clzero -target-feature +pku -target-feature +mmx -target-feature -lwp -target-feature 
+rdpid -target-feature -xop -target-feature +rdseed -target-feature +waitpkg 
-target-feature -kl -target-feature +movdir64b -target-feature -sse4a -target-feature 
-avx512bw -target-feature +clflushopt -target-feature +xsave 

Re: graphics/podofo: 0.10.x requirement

[Guido Falsi]

On 27/05/23 19:37, Guido Falsi wrote:

On 27/05/23 13:24, Po-Chuan Hsieh wrote:


 >
 >> plan 2 - Another option is doing the same as above, but my 
updating

 >> podofo to the latest version and moving old 0.9.x to a
    graphics/podofo09
 >> (or whatever) port, updating all dependencies to use the older
    port for now.
 >
 > Also fine.
 >


I'd like to choose plan 2.


Since you are the maintainer, I'll be happy to align myself with this 
preference.






    Suspected that, I'm also waiting for sunpoet (as podofo maintainer)
    opinion. Maybe he also already has a plan or is working on something
    that I don't know about.


Guido, do you have a patch for podofo and calibre already?
Since podofo has only 5 dependent ports, it should be possible to test 
them all with podofo (0.10.0) and move incompatible ones to podofo09.




I admit I did not count the dependencies. With such a number your plan 
is definitely the best one.


I have no patches at present, before investing time in this I thought 
I'd check what the situation is and if work is already underway.


I'll start looking into it, except I'm at present busy with a strange 
xfce4 issue I need to address.


Give me a few days to look into this.



Hi all,

I created a review for this, could you all take a look and give feedback?

https://reviews.freebsd.org/D40328

Thanks in advance!

--
Guido Falsi 

Re: graphics/digikam: temporarily disable MEDIAPLAYER option?

[Tobias C. Berner]

Moin moin

Done in 4f90439e95f668a431d87796f9052056bd1a4119

mfg Toibas

On Tue, 23 May 2023 at 22:05, Andriy Gapon  wrote:
>
>
> It looks like multimedia/QtAV has been broken and marked as such for some time
> now.  graphics/digikam has a dependency on that port under MEDIAPLAYER option.
> The option is on by default.  Hence, digikam cannot be built as well.
>
> Maybe it would be good to turn off MEDIAPLAYER until QtAV is fixed?
>
> Thank you.
> --
> Andriy Gapon

Re: Is there now the pkg binary packages for area51?

[Tobias C. Berner]

Moin moin

area51 is no longer available or needed, as we tend to directly push
to the main branch now.
There is the kde-freebsd github repo too, which has some WIP branches.
But no binary packages are available.


mfg Tobias

On Wed, 4 Jan 2023 at 16:05, ykla  wrote:
>
> HI,
>
> I remember that a few years ago there was a pre-compiled binary pkg package 
> available from area51 at 
> http://meatwad.mouf.net/rubick/poudriere/packages/110-amd64-kde/ but this 
> link no longer works. Where is the current pkg binary package for 51area 
> located?
>
> Thanks.

Re: Translation issues with the port qt5-l10n

[Tobias C. Berner]

Moin moin

The port is being built from the 'translations' distfile [1] or rather the
kde-patch one [2] created from [3].
You can just install the translation package manually by doing 'pkg install
qt5-l10n'.


mfg Tobias

[1]
https://download.qt.io/official_releases/qt/5.15/5.15.7/submodules/qttranslations-everywhere-opensource-src-5.15.7.tar.xz
[2]
http://distcache.FreeBSD.org/local-distfiles/kde/KDE/Qt/5.15.7/kde-qttranslations-5.15.7p0.tar.xz
[3] https://invent.kde.org/qt/qt/qttranslations


On Fri, 30 Dec 2022 at 16:04, ykla  wrote:

> Hi.,
>
> see also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236518
> that some QT ports not depends on the qt5-l10n. And the translation in
> devel/creator  on windows and linux are complete likes zh-cn. I can't
> found any website or github for qt5-l10n.  Where is the official repository
> for qt5-l10n?
>
> Thanks.
>

Re: cmake port fails to compile on pi3b+

[Tobias C. Berner]

Moin moin

My best guess (from the limited log) is that your build was killed due
to resource starvation (i.e. out of memory/storage).


mfg Tobias

On Wed, 28 Dec 2022 at 09:48, Aaron Beck  wrote:
>
> freshly installed pi3b+ using the 13.1 sd card image, with ports tree from 
> portsnap.  Trying to build comms/rtl-433 which requires cmake.
>
>
> --- cmGlobalUnixMakefileGenerator3.o ---
> Killed
> *** [cmGlobalUnixMakefileGenerator3.o] Error code 137
>
> make[4]: stopped in 
> /usr/ports/devel/cmake-core/work/cmake-3.24.3/Bootstrap.cmk
> --- cmake.o ---
> Killed
> *** [cmake.o] Error code 137
>
> make[4]: stopped in 
> /usr/ports/devel/cmake-core/work/cmake-3.24.3/Bootstrap.cmk
> 4 errors
>
> make[4]: stopped in 
> /usr/ports/devel/cmake-core/work/cmake-3.24.3/Bootstrap.cmk
> -
> Error when bootstrapping CMake:
> Problem while running make
> -
> Log of errors: 
> /usr/ports/devel/cmake-core/work/cmake-3.24.3/Bootstrap.cmk/cmake_bootstrap.log
> -
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to k...@freebsd.org [maintainer] and attach the
> "/usr/ports/devel/cmake-core/work/cmake-3.24.3/config.log" including the
> output of the failure of your make command. Also, it might be a good idea to
> provide an overview of all packages installed on your system (e.g. a
> /usr/local/sbin/pkg-static info -g -Ea).
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/ports/devel/cmake-core
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/ports/devel/cmake-core
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/devel/cmake
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/cmake

Re: KDE application do not start (over SSH into jail)

[Andrea Venturoli]

On 9/6/22 10:49, Adriaan de Groot wrote:


I haven't been able to reproduce this


Thanks in any case.
I don't know why, but today it works again :-/
I'm sure I didn't upgrade any port in the "target" jail (where the 
program should run).
I've upgraded the "client" (actually where the X server runs), though, 
from 12.3 to 13.1.





A most likely approach would be to (a) use truss or strace to see what kind of
calls are being made by the application


I'll keep this in mind if it ever happens again.
Sorry for the noise.

 bye & Thanks
av.

Re: Plasma 5.25 release

[Tobias C. Berner]

Moin moin

The blocker at the moment is this upstream PR
https://bugs.kde.org/show_bug.cgi?id=458356 -- that I personally don't
have enough time to focus on now unfortunately.


mfg Tobias

On Sun, 11 Sept 2022 at 18:32, Jan Beich  wrote:
>
> "Tobias C. Berner"  writes:
>
> > Moin moin
> >
> > The KDE Plasma 5.25 release [1] uses PAM to unlock the screenlocker.
> > This requires (in some cases) a patch to the FreeBSD PAM implementation
> > for PAM not to segfault. So far this change has only been applied to 
> > current.
> [...]
>
> What currently blocks 5.25 merge into main branch? 
> security/unix-selfauth-helper
> landed 1.5 months ago and EN-22:19.pam_exec (FreeBSD 13-only) published 1 
> month ago.
>
> For one, I need newer x11-wm/plasma5-kdecoration for x11-wm/kwinft:
>
> CMake Error at CMakeLists.txt:110 (find_package):
>   Could not find a configuration file for package "KDecoration2" that is
>   compatible with requested version "5.25".
>
>   The following configuration files were considered but not accepted:
>
> /usr/local/lib/cmake/KDecoration2/KDecoration2Config.cmake, version: 
> 5.24.6
>
> effect/effects/blur/blur.cpp:304:49: error: no member named 'blurRegion' in 
> 'KDecoration2::Decoration'
> return w->decoration() && !w->decoration()->blurRegion().isNull();
>~~~  ^
> effect/effects/blur/blur.cpp:316:58: error: no member named 'blurRegion' in 
> 'KDecoration2::Decoration'
> return decorationRegion.intersected(w->decoration()->blurRegion());
> ~~~  ^
> plugins/kdecorations/aurorae/src/aurorae.cpp:624:5: error: use of undeclared 
> identifier 'setBlurRegion'
> setBlurRegion(mask);
> ^
>
> https://gitlab.com/kwinft/kwinft/-/commit/e4c356c44b35 # depends on blurRegion
> https://gitlab.com/kwinft/kwinft/-/commit/9213daf630dd # depends on 
> setBlurRegion
> https://invent.kde.org/plasma/kdecoration/-/commit/fb5634960306 # provides 
> blurRegion + setBlurRegion
> https://github.com/freebsd/freebsd-ports/compare/main...jbeich:kwinft-5.25

Re: Plasma 5.25 release

[Jan Beich]

"Tobias C. Berner"  writes:

> Moin moin
>
> The KDE Plasma 5.25 release [1] uses PAM to unlock the screenlocker.
> This requires (in some cases) a patch to the FreeBSD PAM implementation
> for PAM not to segfault. So far this change has only been applied to current.
[...]

What currently blocks 5.25 merge into main branch? security/unix-selfauth-helper
landed 1.5 months ago and EN-22:19.pam_exec (FreeBSD 13-only) published 1 month 
ago.

For one, I need newer x11-wm/plasma5-kdecoration for x11-wm/kwinft:

CMake Error at CMakeLists.txt:110 (find_package):
  Could not find a configuration file for package "KDecoration2" that is
  compatible with requested version "5.25".

  The following configuration files were considered but not accepted:

/usr/local/lib/cmake/KDecoration2/KDecoration2Config.cmake, version: 5.24.6

effect/effects/blur/blur.cpp:304:49: error: no member named 'blurRegion' in 
'KDecoration2::Decoration'
return w->decoration() && !w->decoration()->blurRegion().isNull();
   ~~~  ^
effect/effects/blur/blur.cpp:316:58: error: no member named 'blurRegion' in 
'KDecoration2::Decoration'
return decorationRegion.intersected(w->decoration()->blurRegion());
~~~  ^
plugins/kdecorations/aurorae/src/aurorae.cpp:624:5: error: use of undeclared 
identifier 'setBlurRegion'
setBlurRegion(mask);
^

https://gitlab.com/kwinft/kwinft/-/commit/e4c356c44b35 # depends on blurRegion
https://gitlab.com/kwinft/kwinft/-/commit/9213daf630dd # depends on 
setBlurRegion 
https://invent.kde.org/plasma/kdecoration/-/commit/fb5634960306 # provides 
blurRegion + setBlurRegion 
https://github.com/freebsd/freebsd-ports/compare/main...jbeich:kwinft-5.25

Re: KDE application do not start (over SSH into jail)

[Adriaan de Groot]

On Friday, 19 August 2022 17:45:04 CEST Andrea Venturoli wrote:
> Now it does not work anymore: if I type kcachegrind, it just stays there
> and nothing happens.
> 
> If I press ^t, I see something like:
> > load: 0.33  cmd: kcachegrind 93739 [select] 5.19r 0.04u 0.03s 0% 75044k


I haven't been able to reproduce this; if I have $DISPLAY set, graphical 
applications -- I'll admit I didn't specifically try kcachegrind, nor did I 
ssh to a jail rather than a physical machine -- work normally.

> Any hint on how to solve (or at least debug) this?


A most likely approach would be to (a) use truss or strace to see what kind of 
calls are being made by the application (b) set suitable Qt debugging 
environment variables (but I couldn't tell you which those are).

Suggestive, but not definitive search results:

https://community.kde.org/Frameworks/Frameworks_Logging_Policy
https://doc.qt.io/qt-5/qloggingcategory.html
https://unix.stackexchange.com/questions/423870/where-are-the-kde-plasmashell-logs

[ade]

signature.asc
Description: This is a digitally signed message part.

Resolved: Re: kdenlive-22.04.3 crashes on FreeBSD 13.1

[Simon Gerraty]

FYI after rebooting the system, kdenlive is working.

On Sat, 30 Jul 2022 23:11:33 -0700, Simon Gerraty writes:
>In case it is useful, backtrace from the core file is below
>
>On Sat, 30 Jul 2022 23:07:15 -0700, Simon Gerraty writes:
>>I did pkg upgrade after upgrading my machine to 13.1
>>I just did pkg upgrade again.
>>
>>I now have kdenlive-22.04.3 which does not work.
>>If I remove /homes/sjg/.config/kdenliverc
>>and run it I get:

Re: kdenlive-22.04.3 crashes on FreeBSD 13.1

[Simon Gerraty]

quot;
>plugin not available: "ladspa"
>plugin not available: "ladspa"
>plugin not available: "ladspa"
>plugin not available: "ladspa"
>plugin not available: "movit.unsharp_mask"
>plugin not available: "oldfilm"
>plugin not available: "rbpitch"
>plugin not available: "rbpitch"
>plugin not available: "region"
>plugin not available: "lines"
>plugin not available: "timewarp"
>plugin not available: "tcolor"
>plugin not available: "opencv.tracker"
>plugin not available: "vignette"
>plugin not available: "region"
>QKqueueFileSystemWatcherEngine::addPaths: open: No such file or directory
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freede=
>sktop.DBus.Error.Disconnected" =
>
> "Not connected to D-Bus server"
>QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-sjg'
>QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-sjg'
>"kf5-applications.menu"  not found in  ()
>kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not fo=
>und
>kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not fo=
>und
>Found FFMpeg binary:  "/usr/local/bin/ffmpeg"
>// FFMPEG ARGS:  ("-hide_banner", "-y", "-vaapi_device", "/dev/dri/renderD=
>128", "-f", "lavfi", "-i", "smptebars=3Dduration=3D5:size=3D1280x720:rate=3D=
>25", "-vf", "format=3Dnv12,hwupload", "-c:v", "h264_vaapi", "-an", "-f", "=
>mp4", "/tmp/CmoBqU.mp4")
>/// ++ VAAPI FAILED ::
>// FFMPEG ARGS:  ("-hide_banner", "-y", "-hwaccel", "vaapi", "-hwaccel_out=
>put_format", "vaapi", "/dev/dri/renderD128", "-f", "lavfi", "-i", "smpteba=
>rs=3Dduration=3D5:size=3D1280x720:rate=3D25", "-vf", "scale_vaapi=3Dw=3D64=
>0:h=3D-2:format=3Dnv12,hwupload", "-c:v", "h264_vaapi", "-an", "-f", "mp4"=
>, "/tmp/CmoBqU.mp4")
>/// ++ VAAPI FAILED ::
>// FFMPEG ARGS:  ("-hide_banner", "-y", "-hwaccel", "cuvid", "-f", "lavfi"=
>, "-i", "smptebars=3Dduration=3D5:size=3D1280x720:rate=3D25", "-c:v", "h26=
>4_nvenc", "-an", "-f", "mp4", "/tmp/QWSUJK.mp4")
>/// ++ NVENC FAILED ::
>// FFMPEG ARGS:  ("-hide_banner", "-filters")
>/// ++ SCALE_NPP NOT SUPPORTED
>qt.qpa.xcb: QXcbConnection: XCB error: 8 (BadMatch), sequence: 508, resour=
>ce id: 41943063, major code: 42 (SetInputFocus), minor code: 0
>QWidget::setMinimumSize: (effect_list/QDockWidget) Negative sizes (0,-1) a=
>re not possible
>Failed to create OpenGL context for format QSurfaceFormat(version 2.0, opt=
>ions QFlags(), depthBufferSize 24, redBuffer=
>Size -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stenci=
>lBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swap=
>Interval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfac=
>eFormat::NoProfile) =
>
>Abort (core dumped) =
>
>
>Fwiw
>
>ldd /usr/local/bin/kdenlive
>/usr/local/bin/kdenlive:
>   libKF5KIOFileWidgets.so.5 

Re: How do I install KDE on FreeBSD?

[Turritopsis Dohrnii Teo En Ming]

Thanks for the link.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

On Fri, 22 Jul 2022 at 10:07, Graham Perrin  wrote:
>
> On 21/07/2022 04:44, Turritopsis Dohrnii Teo En Ming wrote:
>
> > Subject: How do I install KDE on FreeBSD? …
>
> Quick start: 
>
> (Graphics first, then KDE and the rest.)
>
>

Re: How do I install KDE on FreeBSD?

[Turritopsis Dohrnii Teo En Ming]

Thanks for the link.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

On Fri, 22 Jul 2022 at 02:27, Rusty Nejdl  wrote:
>
> This is probably the easiest method to get going:
>
> https://community.kde.org/FreeBSD/Setup/Ports
>
>
>  # pkg install x11/kde5
>
> Rusty Nejdl
>
> On 2022-07-20 22:44, Turritopsis Dohrnii Teo En Ming wrote:
>
> Subject: How do I install KDE on FreeBSD?
>
> Good day from Singapore,
>
> How do I install KDE on FreeBSD?
>
> Thank you.
>
> Regards,
>
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> 21 July 2022 Thursday
> Blogs:
> https://tdtemcerts.blogspot.com
> https://tdtemcerts.wordpress.com

Re: How do I install KDE on FreeBSD?

[Graham Perrin]

On 21/07/2022 04:44, Turritopsis Dohrnii Teo En Ming wrote:


Subject: How do I install KDE on FreeBSD? …


Quick start: 

(Graphics first, then KDE and the rest.)