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

2024-07-22 Thread 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 s

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

2024-07-22 Thread 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

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

2024-07-22 Thread 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 ?

2024-07-21 Thread 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 ?

2024-07-20 Thread 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

2024-07-18 Thread 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

2024-07-17 Thread 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

2024-07-14 Thread 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: Plasma 6.1 ?

2024-06-28 Thread 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 ?

2024-06-28 Thread 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: kdenlive

2024-02-03 Thread 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: git: 69e2e87fa56b - main - devel/protobuf: Update to 24.4

2023-12-20 Thread 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: x11/kf6-plasma-framework : Error in Makefile

2023-12-03 Thread 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

2023-12-02 Thread 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: problem building kf5-purpose

2023-11-07 Thread 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: KDE 5.27.8 on FreeBSD 13.2-RELEASE-p4 (64-bit)

2023-10-22 Thread 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: www/qt5-webengine does not build on 14.0-x and 15.0-CURRENT

2023-09-12 Thread 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

2023-08-19 Thread 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)
>
>
>


KDE Plasma 6.0 (dev) ports

2023-08-17 Thread Tobias C. Berner
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
patch [2], also linked on the README in the repo
disables some files in KF5, so that at least the basic applications:
kate, dolphin, okular, gwenview and most importantly
konsole, can be installed.

To get started, just build the x11/kde6 package, which pulls in
(nearly) the whole overlay.

Note, this is highly experimental :) -- patches, fixes, and
improvements are very welcome!


mfg Tobias

[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


Re: KDE Plasma Kickoff does not work after libxmlb update

2023-08-15 Thread 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: graphics/digikam: temporarily disable MEDIAPLAYER option?

2023-05-23 Thread 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?

2023-01-04 Thread 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

2022-12-30 Thread 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+

2022-12-28 Thread 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: Plasma 5.25 release

2022-09-12 Thread 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: Problem(s) with plasma 5.25

2022-06-22 Thread Tobias C. Berner
Moin moin

I have the same issue on my notebook with 5.25 -- I assumed it was
just a local issue.
I'll investigate whether this is caused by a change in the startup script.


mfg Tobias

On Tue, 21 Jun 2022 at 23:45, Jeremy  wrote:
>
> I had a similar issue with 5.24.5... I think somewhere between 5.24.3 and 
> 5.25.5 and frameworks 5.93 and 5.94. My solution was I used ALT+F2 and opened 
> the settings. Then I selected 'restore previous desktop session' (I think it 
> was called), applied it, and then 'start a new desktop session' from startup 
> and shutdown. I logged out and logged back in and it seemed fix the problem. 
> That fix doesn't seem to work for 5.25.
>
> So I might try to install 5.25 and force install it again to see if that 
> might fix it.
>
> On Tue, Jun 21, 2022, 16:31 Adriaan de Groot  wrote:
>>
>> On Tuesday, 21 June 2022 22:55:52 CEST Jeremy wrote:
>> > The issue is, when I try and start plasma from SDDM or even by using startx
>> > from an .xinitrc file with 'exec ck-launch-session startplasma-x11', it
>> > will show the splash screen, and then a blank screen with the mouse cursor,
>> > and then no further activity (no panel on the bottom, no menu to the left,
>> > no icons, nothing).
>>
>> FWIW, I had this recently -- for a week or so -- with Plasma 5.24.5 (from
>> ports, though built locally with poudriere) and finally fixed it by force-
>> upgrading the plasma5\* ports from my poudriere build. I suspect some
>> underlying library has updated, but not all consumers have had versions
>> bumped).
>>
>> After a forced reinstall of plasma from my local builds, the regular desktop
>> came back.
>>
>> [ade] (who is messing with qt6 and ignoring newer plasma for now)


Plasma 5.25 release

2022-06-15 Thread Tobias C. Berner
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.

On my 13.1 notebook it works well, but I don't want to update KDE Plasma
in the tree and cause some people to have unlockable screens.

If you want to test Plasma 5.25, then you can use the ports tree branch [2]
to do so and build your packages manually. Or apply the patch [3] to your
tree. Please let me know if you encounter any problems.

mfg Tobias

[1] https://kde.org/announcements/plasma/5/5.25.0/
[2] https://github.com/freebsd/freebsd-ports-kde/tree/plasma5-5.25
[3] https://people.freebsd.org/~tcberner/patches/plasma5-5.25.0.diff


Re: Bug 452480: Kmail doesn't display calendar invites

2022-04-28 Thread Tobias C. Berner
Moin moin

Fixed in [1]

mfg Tobias


[1]  
https://cgit.FreeBSD.org/ports/commit/?id=9e4ccdf9c71faebdea5abed44dedce800f363b49

On Thu, 28 Apr 2022 at 06:39, Greg Rivers  wrote:
>
> As per Comment 2 (), doing 
> the following does work around the bug for now:
>
> # mv /usr/local/lib/KTextTemplate/kcalendar_grantlee_plugin.so 
> /usr/local/lib/grantlee/5.2/
>
> --
> Greg
>
>


Re: pkg: Fail to create temporary file: /usr/local/include/KF5/GrantleeTheme

2022-04-25 Thread Tobias C. Berner
Moin moin

This is an issue with pkg's update method of creating temporary files
and the file in question changing the type from a file to a directory.
The fix is to first to a "pkg delete -f grantletheeme" and then do the
normal pkg upgrade.

mfg Tobias

On Mon, 25 Apr 2022 at 13:30, Владимир Тимофиев  wrote:
>
> root@A9t:/home/luba # pkg upgrade
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> Checking for upgrades (1 candidates): 100%
> Processing candidates (1 candidates): 100%
> Checking integrity... done (0 conflicting)
> The following 1 package(s) will be affected (of 0 checked):
>
> Installed packages to be UPGRADED:
> grantleetheme: 21.12.3 -> 22.04.0
>
> Number of packages to be upgraded: 1
>
> Proceed with this action? [y/N]: y
> [1/1] Upgrading grantleetheme from 21.12.3 to 22.04.0...
> [1/1] Extracting grantleetheme-22.04.0:   2%
> pkg: Fail to create temporary file:
> /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.jNufDBaNaNzZ:Not
> a directory
> [1/1] Extracting grantleetheme-22.04.0: 100%
> root@A9t:/home/luba #
>
>
> --
> Желаю вам поддержки Свыше и успеха!
>
> С уважением,
> Ваш  Владимир Тимофиев 
> тел./viber: +380504948657


Re: devel/kio-extras fails to package with SAMBA option disabled

2022-04-23 Thread Tobias C. Berner
Moin moin

Thanks for the report -- fixed in 620e51ec7699093fb1abd6fdc581cae3ef523f2e .

mfg Tobias

On Sat, 23 Apr 2022 at 04:10, Jeremy  wrote:
>
> As from the above subject line, devel/kio-extras-22.04.0 fails to package 
> with SAMBA option disabled. Below is a quick plist fix...
>
> --- pkg-plist.orig 2022-04-21 13:18:09.452934000 -0500
> +++ pkg-plist 2022-04-22 20:52:17.38760 -0500
> @@ -48,7 +48,7 @@
>  share/kio_info/kde-info2html
>  share/kio_info/kde-info2html.conf
>  share/konqueror/dirtree/remote/mtp-network.desktop
> -share/konqueror/dirtree/remote/smb-network.desktop
> +%%SAMBA%%share/konqueror/dirtree/remote/smb-network.desktop
>  share/kservices5/directorythumbnail.desktop
>  share/kservicetypes5/thumbcreator.desktop
>  share/locale/ar/LC_MESSAGES/kfileaudiopreview5.mo
> @@ -809,7 +809,7 @@
>  share/locale/zh_TW/LC_MESSAGES/kio5_sftp.mo
>  share/locale/zh_TW/LC_MESSAGES/kio5_smb.mo
>  share/locale/zh_TW/LC_MESSAGES/kio5_thumbnail.mo
> -share/mime/packages/org.kde.kio.smb.xml
> +%%SAMBA%%share/mime/packages/org.kde.kio.smb.xml
>  share/qlogging-categories5/kio-extras.categories
>  share/qlogging-categories5/kio-extras.renamecategories
>  %%MTP%%share/remoteview/mtp-network.desktop


Re: plasma5-xdg-desktop-portal-kde for KDE file dialog

2022-04-11 Thread Tobias C. Berner
Moin moin

sorry for not getting back to you earlier.

For me it seems to just work fine by doing
> GTK_USE_PORTAL=1 firefox

If  I recall correctly, previously I was also required to start some
dbus-service manually -- but that seems no longer to be a requirement.



mfg Tobias


On Wed, 16 Feb 2022 at 09:03, dinu rr  wrote:
>
> Dear KDE FreeBSD team,
>
> Apologies if a direct email like this is not the correct method of 
> communication.
>
> I have tried to use the deskutils/plasma5-xdg-desktop-portal-kde package to 
> make Firefox use the native KDE file dialog, by setting environment variable 
> GTK_USE_PORTAL=1. However, it failed to work, with the error message that xdg 
> desktop portal service was not running.
>
> I could not find a separate package providing xdg desktop portal service, nor 
> any documentation suggesting how to get this service running.
>
> Could you please let me know whether it is possible to achieve what I am 
> looking for?
>
> I have asked this in the FreeBSD Forums, but have not received any replies so 
> far.
>
> Thank you so much for KDE on FreeBSD; it works wonderfully and you have been 
> keeping it up to date promptly with new KDE releases. It's much appreciated.
>
> Best regards.
> Dinu Radhakrishnan
>


Re: Please update MLT7 to 7.4.0 (needed for Kdenlive CI)

2022-03-11 Thread Tobias C. Berner
Moin moin

7.4.0 is now available on the builders.


mfg Tobias

On Fri, 11 Mar 2022 at 09:21, Julius Künzel
 wrote:
>
> Hi everybody,
>
> for the upcoming 22.04 release we are going to make Kdenlive depend on MLT
> 7.4.0. However as you know our CI also uses FreeBSD and the MLT version in the
> backports used by the CI is still 7.0.1. It would be nice to get the MLT
> update soon to fix the CI. So can you please package 7.4.0 and install the
> update to the CI? We also need the MLT Qt bindings.
>
> Thanks in advance and for your packaging work in general!
> Julius
>
>
>


Re: emby-server, digikam and ImageMagick(s)

2022-01-25 Thread Tobias C. Berner
Cool. That means the patch can just be made dynamic to use
${IMAGEMAGICK_DEFAULT}.


mfg Tobias

On Tue, 25 Jan 2022 at 14:45, Andriy Gapon  wrote:
>
> On 25/01/2022 15:41, Andriy Gapon wrote:
> > On 25/01/2022 15:36, Tobias C. Berner wrote:
> >> Moin moin
> >>
> >> Have you also updated the patch files/ImageMagickSharp.dll.config.in
> >> to point to the -7.so of ImageMagick?
> >
> > Umm, no, I haven't.
> > Let me try.
>
> And that helped!
> 2022-01-25 15:43:04.954 Info ImageMagick: ImageMagick version: ImageMagick
> 7.1.0-19 Q16-HDRI amd64 2021-12-22 https://imagemagick.org
>
> So, it seems that the version actually has to be pinned, but it can be pinned 
> to
> 7 now.
>
> Thank you!
>
> >> On Tue, 25 Jan 2022 at 14:34, Andriy Gapon  wrote:
> >>>
> >>> On 25/01/2022 14:29, Adriaan de Groot wrote:
> >>>> On Tuesday, 25 January 2022 12:42:33 CET Adriaan de Groot wrote:
> >>>>> .. and report on which, if any, works, so that that particular 
> >>>>> workaround
> >>>>> can be applied and made available for everyone.
> >>>>>
> >>>>> does emby-server work with magick 7?
> >>>>
> >>>> FWIW, I can tell you (poudriere did all the work, though) that it builds.
> >>>> Since I don't know what it does beyond what the pkg-descr says, I'll 
> >>>> leave it
> >>>> to someone who cares about that specific port to check if it works.
> >>>>
> >>>> [ade]
> >>>
> >>> Fair enough.
> >>> With ImagicMagick 7 emby-server appears generally work, but it logs this 
> >>> on
> >>> startup:
> >>>
> >>> 2022-01-25 15:07:23.206 Info Main: ImageMagick not available. Will try 
> >>> next
> >>> image processor.
> >>>
> >>> Before the change it used to be:
> >>> 2022-01-22 22:46:15.071 Info ImageMagick: ImageMagick version: ImageMagick
> >>> 6.9.12-34 Q16 amd64 2021-12-22 https://imagemagick.org
> >>>
> >>> I am yet to determine how exactly and how badly that affects the emby's
> >>> functionality, but certainly it noticed the change.
> >>>
> >>>
> >>> --
> >>> Andriy Gapon
> >>>
> >
> >
>
>
> --
> Andriy Gapon


Re: emby-server, digikam and ImageMagick(s)

2022-01-25 Thread Tobias C. Berner
Moin moin

Have you also updated the patch files/ImageMagickSharp.dll.config.in
to point to the -7.so of ImageMagick?

mfg Tobias

On Tue, 25 Jan 2022 at 14:34, Andriy Gapon  wrote:
>
> On 25/01/2022 14:29, Adriaan de Groot wrote:
> > On Tuesday, 25 January 2022 12:42:33 CET Adriaan de Groot wrote:
> >> .. and report on which, if any, works, so that that particular workaround
> >> can be applied and made available for everyone.
> >>
> >> does emby-server work with magick 7?
> >
> > FWIW, I can tell you (poudriere did all the work, though) that it builds.
> > Since I don't know what it does beyond what the pkg-descr says, I'll leave 
> > it
> > to someone who cares about that specific port to check if it works.
> >
> > [ade]
>
> Fair enough.
> With ImagicMagick 7 emby-server appears generally work, but it logs this on 
> startup:
>
> 2022-01-25 15:07:23.206 Info Main: ImageMagick not available. Will try next
> image processor.
>
> Before the change it used to be:
> 2022-01-22 22:46:15.071 Info ImageMagick: ImageMagick version: ImageMagick
> 6.9.12-34 Q16 amd64 2021-12-22 https://imagemagick.org
>
> I am yet to determine how exactly and how badly that affects the emby's
> functionality, but certainly it noticed the change.
>
>
> --
> Andriy Gapon
>


Re: Failure to build cmake-3.21.3 port on FreeBSD

2021-10-20 Thread Tobias C. Berner
Moin moin

As far as I can see in the very short log, it does not seem like a
compilation error. So my first guess would be
that you are suffering from resource starvation, like running out of
memory, and the process therefore being killed.


mfg Tobias

On Wed, 20 Oct 2021 at 09:10, Ed Ryan  wrote:
>
> Good morning,
>
> I have been trying to build cmake as a dependency from the ports tree. I am 
> running a clean install of Freebsd Release 13.0, with an up-to-date ports 
> tree. The build stops at the following:
>
> [ 12%] Building CXX object 
> Source/CMakeFiles/CMakeLib.dir/cmCMakePresetsFile.cxx.o
> [ 12%] Building CXX object 
> Source/CMakeFiles/CMakeLib.dir/cmCMakePresetsFileReadJSON.cxx.o
> *** Signal 9
>
> Stop.
> make[4]: stopped in /usr/ports/devel/cmake/work/cmake-3.21.3
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/ports/devel/cmake/work/cmake-3.21.3
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/ports/devel/cmake/work/cmake-3.21.3
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/devel/cmake
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/cmake
>
> ===>>> make build failed for devel/cmake
>
> This is with MAKE_JOBS_UNSAFE=yes set.
>
> Please advise.
>
> Best regards,
> Ed Ryan


Re: Update Kdenlive Pkg for ffplay dependency

2021-10-19 Thread Tobias C. Berner
Moin moin

The multimedia/kdenlive package already run-depends on ffmpeg. So from
kde@ side this is already handled.

However, the issue is, that ffplay is only built in multimedia/ffmpeg
when the SDL option is on -- which is off by default.

Ports cannot depend on a port "with option FOO=on" unfortunately.

I'd suggest you open a bug report on bugs.freebsd.org against
multimedia/ffmpeg to make ffplay installed by default (or split out
into its own package).

mfg Tobias

On Tue, 19 Oct 2021 at 11:36, Aaron S  wrote:
>
> Wanted to ask if on the next build we could update the kdenlive pkg to 
> include the ffplay dependency? You can get this if you port it, but the pkg 
> lacks this and kdenlive throws a message when you boot it. Thank you!
>


Re: FreeBSD Port of Qt6?

2021-10-12 Thread Tobias C. Berner
Moin moin

We have had WIP Qt6 for quite some time [1] already.
Unfortunately, we are plagued by some crashes which no one has had yet
enough time to figure out the cause of :)

It will get into the tree as soon as possible.


mfg Tobias

[1] https://github.com/freebsd/freebsd-ports-kde/tree/qt6_new

On Tue, 12 Oct 2021 at 14:57, J. Preiss  wrote:
>
> Hi folks,
>
> as you are the drivers for the Qt5 port on FreeBSD: do you have already
> started a port of Qt6, or are there no plans to support it in the future?
>


Re: x11-toolkits/qt5-declarative Project ERROR

2021-10-09 Thread Tobias C. Berner
Moin moin

The package was split recently into x11-toolkits/qt5-declarative and
x11-toolkits/qt5-declarative-test to reduce bloat on desktops --
you'll require the latter for the testing parts.

mfg Tobias

On Fri, 8 Oct 2021 at 20:17, Janos Dohanics  wrote:
>
> Hello and apologies for the cross-posting.
>
> Trying to build x11-toolkits/qt5-declarative and encountering the error:
>
> Project ERROR: Unknown module(s) in QT: qmltest-private
> *** Error code 3
>
> The system is FreeBSD 11.4-STABLE amd64 1104511
>
> I have posted the problem with details to the FreeBSD ports list, but
> have not received a suggestion which would help me resolve the problem:
>
> https://lists.freebsd.org/archives/freebsd-ports/2021-October/000785.html
>
> Your advice will be much appreciated!
>
> --
> Janos Dohanics


Re: x11-toolkits/qt5-gui turning dbus into an option

2021-10-04 Thread Tobias C. Berner
Moin moin

Thank you for the idea.

The patch looks slightly wrong -- in the option handling at the
bottom, you should include bsd.port.options.mk  [1].
But, even better, use DBUS_VARS=QT_CONIFG+=dbus QT_DEFINES+=DBUS in
the normal options block.

Personally, I'm really not a fan of this option, as it might lead to
people having broken software, as DBus is the de facto IPC for nearly
every modern desktop application.

Please open a bug on https://bugs.freebsd.org/bugzilla/ with the
updated patch attached or a review on https://reviews.freebsd.org/ --
it likely also requires plist masking with %%DBUS%%, and a test run
with the options off for qt5-gui consumers.

mfg Tobias

[1] 
https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-options


On Sat, 2 Oct 2021 at 19:38, Sid  wrote:
>
> Dear k...@freebsd.org,
>
> Here's a Makefile diff to allow Dbus to be turned into an option for the 
> FreeBSD port of x11-toolkits/qt5-gui. There's a lot of interest in the 
> FreeBSD forums for turning dbus off, and making it into an option will be 
> suitable for more people.
>
> QT was first added as an option, and set to default.
> "USE_QT =" dbus was turned into an optional dependency through "DBUS_USE= 
> QT=dbus"
> "LIB_DEPENDS=" "libdbus-1.so:devel/dbus" was turned into an option through 
> "DBUS_LIB_DEPENDS= libdbus-1.so:devel/dbus"
> These first two are shorthand for using those dependencies and libraries, 
> when the respective option is set. Their use is in the Ports Handbook.
>
> The remaining two dbus parts use an if/then statement added towards the end 
> of the Makefile
>
> Thank you very much.
>
>
>
> --- Makefile.orig 2021-10-01 07:16:46.714179000 +
> +++ Makefile 2021-10-01 22:44:22.847818000 +
> @@ -14,8 +14,7 @@
> ${BUILD_DEPENDS_${ARCH}}
> BUILD_DEPENDS_armv6= as:devel/binutils
> BUILD_DEPENDS_armv7= as:devel/binutils
> -LIB_DEPENDS= libdbus-1.so:devel/dbus \
> - libevdev.so:devel/libevdev \
> +LIB_DEPENDS= libevdev.so:devel/libevdev \
> libfontconfig.so:x11-fonts/fontconfig \
> libfreetype.so:print/freetype2 \
> libharfbuzz.so:print/harfbuzz \
> @@ -36,13 +35,13 @@
> qmake:no_env qt-dist:5,base
> USE_GL= egl gl
> USE_GNOME= glib20
> -USE_QT= core dbus network buildtools_build qmake_build
> +USE_QT= core network buildtools_build qmake_build
> QT_BINARIES= yes
> -QT_CONFIG= accessibility accessibility-atspi-bridge dbus \
> +QT_CONFIG= accessibility accessibility-atspi-bridge \
> fontconfig glib opengl png system-freetype system-jpeg \
> system-png xcb xcb-glx xcb-render xcb-xlib xinput2 xlib \
> xrender
> -QT_DEFINES= ACCESSIBILITY DBUS FONTCONFIG FREETYPE GLIB \
> +QT_DEFINES= ACCESSIBILITY FONTCONFIG FREETYPE GLIB \
> IMAGEFORMAT_PNG OPENGL SHAPE XCB XKB XKBCOMMON XRENDER
> USE_XORG= ice sm xi xrender
> HAS_CONFIGURE= yes
> @@ -57,12 +56,14 @@
> BUILD_WRKSRC= ${WRKSRC}/src/${PORTNAME}
> INSTALL_WRKSRC= ${BUILD_WRKSRC}
>
> -OPTIONS_DEFINE= X11
> -OPTIONS_DEFAULT= X11
> +OPTIONS_DEFINE= X11 DBUS
> +OPTIONS_DEFAULT= X11 DBUS
> OPTIONS_SUB= yes
>
> X11_USES= xorg
> X11_USE= xorg=x11
> +DBUS_LIB_DEPENDS= libdbus-1.so:devel/dbus
> +DBUS_USE= QT=dbus
>
> # Build and install QtPlatformSupport and default QPA plugins (XCB,
> # minimal and offscreen). QtGui won't work without (one of) them, but
> @@ -113,3 +114,8 @@
> .endfor
>
> .include 
> +
> +.if ${PORT_OPTIONS:MDBUS}
> +QT_CONFIG+= dbus
> +QT_DEFINES+= DBUS
> +.endif


Re: Kdenlive needs MLT 7 package

2021-06-19 Thread Tobias C. Berner
Moin moin

Adriaan created a port recently, and I will install it on the CI shortly.


mfg Tobias

On Sat, 19 Jun 2021 at 11:07, Julius Künzel
 wrote:
>
> Hi everybody!
>
>
> MLT 7 has been released about a month ago (https://github.com/mltframework/ 
> mlt/releases/tag/v7.0.1). MLT is Kdenlive's mediabackend and one of the main 
> dependencies. We want to port Kdenlive from MLT 6 to MLT 7 for version 21.08. 
> However one of our pipelines 
> (https://build.kde.org/job/Applications/job/kdenlive/) is based on FreeBSD 12 
> (https://invent.kde.org/sysadmin/ci-tooling/-/tree/master/doc/FreeBSD) and we 
> are now waiting for FreeBSD to release MLT 7. This massage is to inform you 
> about our plans as you are might not releasing MLT 7 because Kdenlive needs 
> MLT 6 and we are in a vicious circle. Do you have any plans when this will 
> happen?
>
>
> The packages we need for the pipeline are:
>
>  multimedia/mlt
>
> multimedia/mlt-qt5
>
>
> Cheers from the Kdenlive dev team,
>
> Julius Künzel


Re: KDE wacom support on FreeBSD

2021-05-03 Thread Tobias C. Berner
Moin moin

To get the wacom device to work, just install webcamd [1] -- for the
configuration in KDE, it should technically work, but I'm not sure
whether it actually recognizes the webcamd wrapped device.
(You can also configure devd to automatically issue the attach command
to webcamd).

mfg Tobias

[1]
> pkg install webcamd
> service webcamd enable
> service webcamd start
The issue a blank webcamd to get the list of devices
> webcamd
[...]
webcamd [-d ugen1.3] -N Wacom-Co--Ltd--Intuos5-touch-M -S unknown -M 0
[...]
and attach it
> webcamd -d ugen1.3 -N Wacom-Co--Ltd--Intuos5-touch-M -S unknown -M 0


On Thu, 29 Apr 2021 at 17:04, Adriaan de Groot  wrote:
>
> On Thursday, 29 April 2021 08:06:43 CEST John Murphy wrote:
> > Are there any plans to make the KDE wacom support available to FreeBSD
> > users.
>
> What does that mean? Have you tried compiling it -- whatever it is --
> yourself? It might take a Linux box with working support to help you figure
> out where in the software stack this stuff lives, though.
>
> [ade]


Re: selection visibility in konsole 21.04.0

2021-05-03 Thread Tobias C. Berner
Moin moin

Thanks for the heads up -- fixed in [1]

mfg Tobias


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

On Mon, 3 May 2021 at 10:50, Andriy Gapon  wrote:
>
>
> I am sure that I won't be the only one affected, so sort of heads-up:
> https://bugs.kde.org/show_bug.cgi?id=435309
>
> --
> Andriy Gapon


Re: FreeBSD Port: www/qt5-webengine

2021-04-10 Thread Tobias C. Berner
Moin moin

Yes, at the moment this is no issue (well it is an issue, but not a
problem that can
easily be fixed -- as neither of the two upstreams shows any intention
in doing the
work).
We got a bit of time to find a proper workaround (there won't be a solution :D)


mfg Tobias

On Sun, 11 Apr 2021 at 08:54, LuMiWa  wrote:
>
> Hi!
>
> Is it possible to build WT5-Webengine because it needs Python 2.7?
>
> Thank you
>
> --
> “We live in a world where there is more and more information, and less
> and less meaning.”
>
> Jean Baudrillard


Re: QT5-DECLARATIVE FreeBSD compile issues

2021-03-01 Thread Tobias C. Berner
On Mon, 1 Mar 2021 at 17:49, Jason Naughton  wrote:
>
> Well I am using openssl in the ports tree and also do have the line in my 
> make.conf:
>
> DEFAULT_VERSIONS+= ssl=openssl
>
> I doubt that the error is to do with openssl.   Bengt what are the following 
> two compile options that you've identified?
I was not implying it had anything to do with openssl -- what I meant
is, that in the default FreeBSD ports configuration
 qt5-network blocks qt5-declarative from building (due to openssl),
and it is therefore untested by the build cluster and
kde@, and therefore possibly broken [patches welcome] .

mfg Tobias


>
> OPTIONS_UNSET+= GSSAPI_BASE
> OPTIONS_SET+= GSSAPI_NONE
>
> Cheers
>
> Jason Naughton M.E.Sc, P.Eng,  Lead Engineer,
> Electrical, Computer, and BioMedical Engineering, Ryerson University
> 245 Church St., Toronto, Ontario, M5B 2K3
> Office:  (416)-979-5000 x557168   Fax:  (416)-979-5280
>
>
> On Mon, Mar 1, 2021 at 5:44 AM Bengt Ahlgren  wrote:
>>
>> Hi Tobias, All,
>>
>> I regularly build kf5 and virtualbox-ose on 11.4-REL without too much
>> hassle using:
>>
>> DEFAULT_VERSIONS+= ssl=openssl
>>
>> There are some other ports that need option tweaks in addition to this.
>> A common one is:
>>
>> OPTIONS_UNSET+= GSSAPI_BASE
>> OPTIONS_SET+= GSSAPI_NONE
>>
>> For git I recommend:
>>
>> OPTIONS_UNSET+= SEND_EMAIL
>>
>> But you do need to build a complete package set with poudriere so that
>> all of them use openssl from ports!
>>
>> Bengt
>>
>> Ps. Thanks Tobias and the rest of the KDE FreeBSD team for you great
>> work!
>>
>> "Tobias C. Berner"  writes:
>>
>> > Moin moin
>> >
>> > Unfortunately we cannot really support FreeBSD 11.x anymore for Qt --
>> > with the switch to Qt5 5.15
>> > we had to drop support for it, due to its outdated OpenSSL version in
>> > base, which does not work with
>> > qt5-networks requirements.
>> > As qt5-declarative also depends on qt5-network, this is completely
>> > untested, and may likely also fail
>> > with the compiler version present in FreeBSD 11.x.
>> >
>> > My recommendation would be to update to a more current version
>> > FreeBSD, like for example 12.x or
>> > the soon to be released 13.x.
>> >
>> > mfg Tobias
>> >
>> > On Mon, 1 Mar 2021 at 09:47, Jason Naughton  wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I'm attempting to compile virtualbox-ose on FreeBSD 11.4 but it fails to 
>> >> compile due to a dependency on qt5-declarative.  I'm compiling 5.15.2 The 
>> >> compile stops at:
>> >>
>> >> c++ -c -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -std=c++1z 
>> >> -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall 
>> >> -Wextra -Wdate-time -Winconsistent-missing-override -pthread -fPIC 
>> >> -DQT_NO_LINKED_LIST -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS 
>> >> -DQT_ACCESSIBILITY -DQT_NO_URL_CAST_FROM_STRING 
>> >> -DQT_NO_INTEGER_EVENT_COORDINATES -DQT_NO_FOREACH 
>> >> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_QUICK_LIB 
>> >> -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS 
>> >> -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS 
>> >> -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
>> >> -DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_NO_EXCEPTIONS 
>> >> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG 
>> >> -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB 
>> >> -DQT_CORE_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I. -I../../include 
>> >> -I../../include/QtQuick -I../../include/QtQuick/5.15.2 
>> >> -I../../include/QtQuick/5.15.2/QtQuick -I.tracegen 
>> >> -I../../include/QtQmlModels/5.15.2 
>> >> -I../../include/QtQmlModels/5.15.2/QtQmlModels 
>> >> -I../../include/QtQml/5.15.2 -I../../include/QtQml/5.15.2/QtQml 
>> >> -I../../include/QtQmlModels -I../../include/QtQml 
>> >> -I/usr/local/include/qt5/QtGui/5.14.2 
>> >> -I/usr/local/include/qt5/QtGui/5.14.2/QtGui 
>> >> -I/usr/local/include/qt5/QtCore/5.15.2 
>> >> -I/usr/local/include/qt5/QtCore/5.15.2/QtCore -I/usr/local/include/qt5 
>> >> -I/usr/local/include/qt5/QtGui -I/usr/local/include/qt5/QtNetwork 
>> >> -I/usr/local/include/qt5/QtCore -I.moc -I/usr/local/include/libdrm 
>> >> -I/usr/local/in

Re: QT5-DECLARATIVE FreeBSD compile issues

2021-03-01 Thread Tobias C. Berner
Moin moin

Unfortunately we cannot really support FreeBSD 11.x anymore for Qt --
with the switch to Qt5 5.15
we had to drop support for it, due to its outdated OpenSSL version in
base, which does not work with
qt5-networks requirements.
As qt5-declarative also depends on qt5-network, this is completely
untested, and may likely also fail
with the compiler version present in FreeBSD 11.x.

My recommendation would be to update to a more current version
FreeBSD, like for example 12.x or
the soon to be released 13.x.

mfg Tobias

On Mon, 1 Mar 2021 at 09:47, Jason Naughton  wrote:
>
> Hi all,
>
> I'm attempting to compile virtualbox-ose on FreeBSD 11.4 but it fails to 
> compile due to a dependency on qt5-declarative.  I'm compiling 5.15.2 The 
> compile stops at:
>
> c++ -c -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -std=c++1z 
> -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -Wextra 
> -Wdate-time -Winconsistent-missing-override -pthread -fPIC 
> -DQT_NO_LINKED_LIST -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS 
> -DQT_ACCESSIBILITY -DQT_NO_URL_CAST_FROM_STRING 
> -DQT_NO_INTEGER_EVENT_COORDINATES -DQT_NO_FOREACH 
> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_QUICK_LIB 
> -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS 
> -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS 
> -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
> -DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_NO_EXCEPTIONS 
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_QMLMODELS_LIB 
> -DQT_QML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_NETWORK_LIB 
> -DQT_CORE_LIB -I. -I. -I../../include -I../../include/QtQuick 
> -I../../include/QtQuick/5.15.2 -I../../include/QtQuick/5.15.2/QtQuick 
> -I.tracegen -I../../include/QtQmlModels/5.15.2 
> -I../../include/QtQmlModels/5.15.2/QtQmlModels -I../../include/QtQml/5.15.2 
> -I../../include/QtQml/5.15.2/QtQml -I../../include/QtQmlModels 
> -I../../include/QtQml -I/usr/local/include/qt5/QtGui/5.14.2 
> -I/usr/local/include/qt5/QtGui/5.14.2/QtGui 
> -I/usr/local/include/qt5/QtCore/5.15.2 
> -I/usr/local/include/qt5/QtCore/5.15.2/QtCore -I/usr/local/include/qt5 
> -I/usr/local/include/qt5/QtGui -I/usr/local/include/qt5/QtNetwork 
> -I/usr/local/include/qt5/QtCore -I.moc -I/usr/local/include/libdrm 
> -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o 
> .obj/qsgrenderer.o scenegraph/coreapi/qsgrenderer.cpp
> --- .obj/qquickglobal.o ---
> util/qquickglobal.cpp:816:17: error: no viable overloaded '='
> dst = *srcT;
> ~~~ ^ ~
> util/qquickglobal.cpp:828:20: note: in instantiation of function template 
> specialization 'QQuickValueTypeProvider::typedWrite' requested 
> here
> return typedWrite(src, dst);
>^
> /usr/local/include/qt5/QtCore/qvariant.h:275:15: note: candidate function not 
> viable: no known conversion from 'const QColorSpace' to 'const QVariant' for 
> 1st argument
> QVariant& operator=(const QVariant &other);
>   ^
> /usr/local/include/qt5/QtCore/qvariant.h:278:22: note: candidate function not 
> viable: no known conversion from 'const QColorSpace' to 'QVariant' for 1st 
> argument
> inline QVariant &operator=(QVariant &&other) noexcept
>  ^
> 1 error generated.
> *** [.obj/qquickglobal.o] Error code 1
>
> make[3]: stopped in 
> /usr/ports/x11-toolkits/qt5-declarative/work/qtdeclarative-everywhere-src-5.15.2/src/quick
> 1 error
>
> make[3]: stopped in 
> /usr/ports/x11-toolkits/qt5-declarative/work/qtdeclarative-everywhere-src-5.15.2/src/quick
> *** [sub-quick-all-ordered] Error code 2
>
> make[2]: stopped in 
> /usr/ports/x11-toolkits/qt5-declarative/work/qtdeclarative-everywhere-src-5.15.2/src
> 1 error
>
> make[2]: stopped in 
> /usr/ports/x11-toolkits/qt5-declarative/work/qtdeclarative-everywhere-src-5.15.2/src
> *** [sub-src-all] Error code 2
>
> make[1]: stopped in 
> /usr/ports/x11-toolkits/qt5-declarative/work/qtdeclarative-everywhere-src-5.15.2
> 1 error
>
> make[1]: stopped in 
> /usr/ports/x11-toolkits/qt5-declarative/work/qtdeclarative-everywhere-src-5.15.2
> ===> 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/x11-toolkits/qt5-declarative
>
> Any Idea how to resolve this?
>
> Cheers
>
> Jason Naughton M.E.Sc, P.Eng,  Lead Engineer,
> Electrical, Computer, and BioMedical Engineering, Ryerson University
> 245 Church St., Toronto, Ontario, M5B 2K3
> Office:  (416)-979-5000 x557168   Fax:  (416)-979-5280


Re: Ports with version numbers going backwards: devel/okteta

2021-02-05 Thread Tobias C. Berner
Moin moin

This has been addressed in  r564025


mfg Tobias

On Fri, 5 Feb 2021 at 12:47,  wrote:
>
> ** The following ports have a version number that sorts before a previous one 
> **
>
>  For many package tools to work correctly, it is of utmost importance that
>  version numbers of a port form a monotonic increasing sequence over time.
>  Refer to the FreeBSD Porter's Handbook, 'Package Naming Conventions' for
>  more information. Tools that won't work include pkg_version, portupgrade
>  and portaudit. A common error is an accidental deletion of PORTEPOCH.
>
>  Please fix any errors as soon as possible.
>
>  The ports tree was updated at Thu Feb  4 2021 12:30:00 UTC.
>
> - *devel/okteta* : okteta-0.26.5 < okteta-0.26.4,1
>| r563876 | adridg | 2021-02-03 11:18:15 + (Wed, 03 Feb 2021) | 15 
> lines
>|
>| Update devel/okteta to latest upstream commit
>|
>| Okteta is a viewer and editor for raw file data (aka "hex editor").
>| It provides "hex editor" libraries for other applications as well.
>|
>| Changes since 0.26.4:
>| * Improved: Structure definitions allow custom pointer interpretations 
> in JS
>| * Improved: cursor flash time setting of 0 (= no blinking) supported
>| * Improved: cursor shows char/value in background color instead of blank
>| * Improved: new menu entry for selecting custom UI color scheme
>| * Improved: less deprecated Qt/KF code usage
>| * Improved: translations
>|
>| Reported by:   portscout
>|
>
>


Re: security/libkleo fails to build w/error "bad_C++_code"

2021-01-03 Thread Tobias C. Berner
Moin moin

Please make sure your ports tree is up to date, the error has been
fixed by adrdig@ and committed by jhale in  r559796 on 2021-01-01 [1].


mfg Toibas

[1] https://svnweb.freebsd.org/ports?view=revision&revision=559796

On Sun, 3 Jan 2021 at 10:58, Richard Susgin  wrote:
>
> freebsd-version -ku
> 12.1-RELEASE-p11
> 12.1-RELEASE-p12
>
> pkg -v
> 1.16.1
>
> pkg info -x poudriere
> poudriere-devel-3.3.99.20200326_2
>
> It just looks like a lot of errors with functions.


Re: FreeBSD Port: devel/qt5-core

2020-12-31 Thread Tobias C. Berner
Moin moin

This means that you have not fully upgraded your Qt installation --
make sure that everything is up to date,
and it should work again.


mfg Tobias

On Thu, 31 Dec 2020 at 18:54, László Lajos Jánszky
 wrote:
>
> Hi!
>
> I upgraded a few packages with pkg today and since then KDE is down. The x 
> server cannot start, it writes that Cannot mix incompatible Qt library 
> (5.15.0) with this library (5.15.2)


Re: panel clock does not show all digits of the time

2020-12-18 Thread Tobias C. Berner
Moin moin

I remember a similar issue on the lock screen some time ago -- but I
don't see it at the moment.
Have you looked whether there is a bug report upstream? This does not
seem like it should be
caused by our packaging.


mfg Tobias

On Fri, 18 Dec 2020 at 08:32, Matthias Apitz  wrote:
>
>
> Hello,
>
> With a very recent plasma from ports on CURRENT I have the issue that from 
> time
> to time some of the digits of the clock in the panel are going away (look 
> screen at
> http://www.unixarea.de/clock.png ). To make them appear again I change
> the characters for the digits from normal to bold (or vice versa) and
> then after some time they're away again.
>
> What can I do?
>
> matthias
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub


Re: devel/qt5-core: please merge the fix for QTBUG-87010

2020-10-19 Thread Tobias C. Berner
Moin moin

Sure, I try to get it done this week.

mfg Tobias

On Mon, 19 Oct 2020 at 08:42, Alexey Dokuchaev  wrote:
>
> Hi there,
>
> There was a regression in Qt 5.15 which had broken e.g. astro/stellarium:
> https://github.com/Stellarium/stellarium/issues/1131 (with a PoC patch).
>
> It was filed upstream as https://bugreports.qt.io/browse/QTBUG-87010 and
> finally fixed.
>
> Can you please merge the patch to the `devel/qt5-core' so we can unbreak
> `astro/stellarium' again?  Thanks,
>
> ./danfe


Re: Black screen with plasma 5.20.0

2020-10-16 Thread Tobias C. Berner
Moin moin

How lucky that the files that moved between the package are exactly
the ones I used to detect the installation by :D
Good catch.

Fixed in r552498.


mfg Tobias

On Fri, 16 Oct 2020 at 01:01, Jan Henrik Sylvester  wrote:
>
> Hi,
>
> On 10/15/20 3:26 PM, Tobias C. Berner wrote:
> > Can you make sure that both plasma5-plasma-workspace and
> > plasma5-plasma-desktop are installed?
> > A file moved between the two packages, which might lead to pkg
> > removing one of them during the upgrade.
>
> installing plasma5-plasma-desktop fixes the problem, but I think it was
> no due to a bad upgrade:
>
> # grep ^kde-plasma-desktop /usr/ports/Mk/Uses/kde.mk
> kde-plasma-desktop_PORT=x11/plasma5-plasma-desktop
> kde-plasma-desktop_PATH=${KDE_PREFIX}/bin/krdb
> # pkg which /usr/local/bin/krdb
> /usr/local/bin/krdb was installed by package plasma5-plasma-workspace-5.20.0
>
>  From what I understand, plasma5-plasma does not pull
> plasma5-plasma-desktop, since it is looking for bin/krdb, which is
> provided by plasma5-plasma-workspace. Maybe you want to change
> Mk/Uses/kde.mk to something like:
>
> kde-plasma-desktop_PATH=${KDE_PREFIX}/bin/kaccess
>
> Cheers,
> Jan Henrik


Re: Black screen with plasma 5.20.0

2020-10-15 Thread Tobias C. Berner
Moin moin

Can you make sure that both plasma5-plasma-workspace and
plasma5-plasma-desktop are installed?
A file moved between the two packages, which might lead to pkg
removing one of them during the upgrade.

mfg Tobias

On Thu, 15 Oct 2020 at 15:25, Jan Henrik Sylvester  wrote:
>
> Hello,
>
> I have just tried plasma 5.20.0, but only got a black screen after
> login. I could start a Konsole with + to kill plasmashell and
> restart it. This did not help, but I got:
>
> QObject::disconnect: Unexpected nullptr parameter
> QObject::disconnect: Unexpected nullptr parameter
> QObject::disconnect: Unexpected nullptr parameter
> kf.plasma.quick: Applet preload policy set to 1
> Constructing a KPluginInfo object from old style JSON. Please use
> kcoreaddons_desktop_to_json() for "" instead of
> kservice_desktop_to_json() in your CMake code.
> Warning: corona package invalid
> Invalid home screen package
> Containment graphic object not valid
>
> I tried a user with an empty home directory with the same result. It is
> not something in my profile.
>
> Reverting all plasma5 packages to 5.19.5, I got the background and
> desktop, but not the start menu. I had to rollback my home directory, too.
>
> Unfortunately, this is my main work machine and I have to get back to
> work. Hence, I cannot test more. Maybe someone has a clue what is going on.
>
> Cheers,
> Jan Henrik


Re: Falkon 3.1 crashed when try start it.

2020-09-06 Thread Tobias C. Berner
Moin moin

As I recall you recently upgraded your Qt to 5.15 -- did you rebuild
falkon after that?


mfg Tobias

On Sun, 6 Sep 2020 at 11:29, L0T  wrote:
>
> Hello.
>
> Falkon 3.1 crashed when try start it.
>
> 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 r364948 BROTHER  amd64
>
> pkg info | grep qt5-
>
> gpgme-qt5-1.13.1   Gpgme Qt5 bindings
> gstreamer1-qt5-1.2.0_24Qt  bindings for GStreamer 1.x multimedia 
> library
> libaccounts-qt5-1.13_10Qt5 wrapper for SSO framework
> libdbusmenu-qt5-0.9.3.160420160218_10 Qt5 implementation of the DBusMenu 
> protocol
> phonon-qt5-4.11.1  KDE multimedia framework
> pinentry-qt5-1.1.0_1   Qt 5 version of the GnuPG password dialog
> poppler-qt5-20.08.0_1  Qt 5 bindings to poppler
> qjson-qt5-0.9.0_6  Library to manage JSON objects with Qt
> qt5-assistant-5.15.0   Qt 5 documentation browser
> qt5-buildtools-5.15.0  Qt build tools
> qt5-concurrent-5.15.0  Qt multi-threading module
> qt5-core-5.15.0_2  Qt core non-graphical module
> qt5-dbus-5.15.0Qt D-Bus inter-process communication module
> qt5-declarative-5.15.0_1   Qt declarative framework for dynamic user 
> interfaces
> qt5-designer-5.15.0Qt 5 graphical user interface designer
> qt5-graphicaleffects-5.15.0Qt Quick graphical effects
> qt5-gui-5.15.0 Qt graphical user interface module
> qt5-help-5.15.0Qt online help integration module
> qt5-imageformats-5.15.0Qt plugins for additional image formats
> qt5-linguisttools-5.15.0   Qt localization tools
> qt5-location-5.15.0Qt location module
> qt5-multimedia-5.15.0  Qt audio, video, radio and camera support 
> module
> qt5-network-5.15.0 Qt network module
> qt5-opengl-5.15.0  Qt 5-compatible OpenGL support module
> qt5-printsupport-5.15.0Qt print support module
> qt5-qmake-5.15.0   Qt Makefile generator
> qt5-quickcontrols2-5.15.0  Set of controls for building complete 
> interfaces in Qt Quick
> qt5-script-5.15.0  Qt 4-compatible scripting module
> qt5-sensors-5.15.0 Qt sensors module
> qt5-serialport-5.15.0  Qt functions to access serial ports
> qt5-speech-5.15.0  Accessibilty features for Qt5
> qt5-sql-5.15.0 Qt SQL database integration module
> qt5-sqldrivers-mysql-5.15.0Qt MySQL database plugin
> qt5-sqldrivers-sqlite3-5.15.0  Qt SQLite 3 database plugin
> qt5-svg-5.15.0 Qt SVG support module
> qt5-testlib-5.15.0 Qt unit testing module
> qt5-uiplugin-5.15.0Custom Qt widget plugin interface for Qt 
> Designer
> qt5-uitools-5.15.0 Qt Designer UI forms support module
> qt5-webchannel-5.15.0  Qt 5 library for integration of C++/QML with 
> HTML/js clients
> qt5-webengine-5.15.0_2 Qt 5 library to render web content
> qt5-webkit-5.212.0.a4_3QtWebKit with a more modern WebKit code base
> qt5-widgets-5.15.0 Qt C++ widgets module
> qt5-x11extras-5.15.0   Qt platform-specific features for X11-based 
> systems
> qt5-xml-5.15.0 Qt SAX and DOM implementations
> signon-qt5-8.60D-Bus service performing user authentication
>
>
> # $FreeBSD: head/www/falkon/Makefile 516991 2019-11-07 17:20:58Z zeising $
>
> PORTNAME=   falkon
> DISTVERSION=3.1.0
>
>
> Crash log
>
> Time: сб сент. 5 12:38:33 2020
> Qt version: 5.15.0 (compiled with 5.15.0)
> Falkon version: 3.1.0
> Rendering engine: QtWebEngine
>
> == BACKTRACE ==
> #0: 0x204441  at /usr/local/bin/falkon
> #1: 0x47fbf2be <_pthread_sigmask+0x52e> at /lib/libthr.so.3
>
> Can you help me please ?
>
> --
> (  ͡° ͜ʖ ͡°)


Re: kdesu on FreeBSD

2020-08-16 Thread Tobias C. Berner
Hi David

Cool, thank you too :)

mfg Tobias

On Sun, 16 Aug 2020 at 14:39, David Faure  wrote:
>
> On dimanche 16 août 2020 14:31:18 CEST Tobias C. Berner wrote:
> > On Sun, 16 Aug 2020 at 14:29, David Faure  wrote:
> > > Hi Tobias,
> > >
> > > I was completely wrong.
> > > kdesu/autotests/sudo does exist, and it's a python script.
> > >
> > > The "No such file or directory" is probably due to #!/usr/bin/python3
> > > at the top of that script.
> > >
> > > Do you know the portable way to invoke python3?
> >
> > #!/usr/bin/env python3
>
> Oh so it was just the path that was the problem, not the executable name.
> I wasn't sure it was called python3 everywhere.
>
> Cool, done, and the CI finally passes for kdesu on FreeBSD.
> https://build.kde.org/job/Frameworks/job/kdesu/job/kf5-qt5%20FreeBSDQt5.15/
>
> Thanks!
>
> One down, 8 to go
> https://build.kde.org/job/Frameworks/view/Platform%20-%20FreeBSDQt5.15/
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>


Re: kdesu on FreeBSD

2020-08-16 Thread Tobias C. Berner
On Sun, 16 Aug 2020 at 14:29, David Faure  wrote:
>
> Hi Tobias,
>
> I was completely wrong.
> kdesu/autotests/sudo does exist, and it's a python script.
>
> The "No such file or directory" is probably due to #!/usr/bin/python3
> at the top of that script.
>
> Do you know the portable way to invoke python3?
#!/usr/bin/env python3


mfg Tobias

>
> Cheers,
> David.
>
> On dimanche 16 août 2020 12:22:36 CEST Tobias C. Berner wrote:
> > Moin moin
> >
> >
> > # which su ; which sudo
> > /usr/bin/su
> > /usr/local/bin/sudo
> >
> > No, both are installed and in $PATH. So, not finding those is weird.
> >
> >
> > mfg Tobias
> >
> > On Sun, 16 Aug 2020 at 12:13, David Faure  wrote:
> > > On dimanche 16 août 2020 10:31:28 CEST Tobias C. Berner wrote:
> > > > Moin moin
> > > >
> > > > On Sun, 16 Aug 2020 at 01:54, David Faure  wrote:
> > > > > https://build.kde.org/job/Frameworks/job/kdesu/job/kf5-qt5%20FreeBSDQt
> > > > > 5.15
> > > > > /11/testReport/projectroot/autotests/kdesutest/ says `xauth` isn't
> > > > > found.
> > > >
> > > > xauth is now installed on the builders
> > >
> > > Thanks. The call fails with `No X authentication info set for display
> > > ":90"` but maybe the same happens in the Linux builders, I can't see the
> > > output there because the tests pass. It seems very likely to me that it
> > > does happen there as well, and it's certainly not needed for the test to
> > > pass.>
> > > > > Does xauth exist on FreeBSD? Is it maybe not in $PATH? Or is it maybe
> > > > > just
> > > > > not installed in the FreeBSD CI machine?
> > > > >
> > > > > The actual failure isn't related to xauth but to sudo/su output, I'll
> > > > > debug that tomorrow by committing some debug output and reverting it
> > > > > soon
> > > > > after, since I can't get any FreeBSD developer to look into those
> > > > > failing
> > > > > unittests...
> > > >
> > > > harsh, but fair... ;-)
> > >
> > > You mean "unfortunate but true" ;-)
> > >
> > > Anyhow, here's the result:
> > >
> > > execv( \"/usr/home/jenkins/workspace/Frameworks/kdesu/kf5-qt5
> > > FreeBSDQt5.15/autotests/sudo\" ): No such file or directory execv(
> > > \"/usr/home/jenkins/workspace/Frameworks/kdesu/kf5-qt5
> > > FreeBSDQt5.15/autotests/su\" ): No such file or directory
> > >
> > > It seems to me that sudo and su are not installed either?
> > > (I think it's trying them in the current directory, for lack of finding
> > > them in the PATH)
> > >
> > > --
> > > David Faure, fa...@kde.org, http://www.davidfaure.fr
> > > Working on KDE Frameworks 5
>
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>


Re: kdesu on FreeBSD

2020-08-16 Thread Tobias C. Berner
Moin moin


# which su ; which sudo
/usr/bin/su
/usr/local/bin/sudo

No, both are installed and in $PATH. So, not finding those is weird.


mfg Tobias

On Sun, 16 Aug 2020 at 12:13, David Faure  wrote:
>
> On dimanche 16 août 2020 10:31:28 CEST Tobias C. Berner wrote:
> > Moin moin
> >
> > On Sun, 16 Aug 2020 at 01:54, David Faure  wrote:
> > > https://build.kde.org/job/Frameworks/job/kdesu/job/kf5-qt5%20FreeBSDQt5.15
> > > /11/testReport/projectroot/autotests/kdesutest/ says `xauth` isn't found.
> >
> > xauth is now installed on the builders
>
> Thanks. The call fails with `No X authentication info set for display ":90"` 
> but maybe the same happens in the Linux builders, I can't see the output 
> there because the tests pass. It seems very likely to me that it does happen 
> there as well, and it's certainly not needed for the test to pass.
>
> > > Does xauth exist on FreeBSD? Is it maybe not in $PATH? Or is it maybe just
> > > not installed in the FreeBSD CI machine?
> > >
> > > The actual failure isn't related to xauth but to sudo/su output, I'll
> > > debug that tomorrow by committing some debug output and reverting it soon
> > > after, since I can't get any FreeBSD developer to look into those failing
> > > unittests...
> > harsh, but fair... ;-)
> You mean "unfortunate but true" ;-)
>
> Anyhow, here's the result:
>
> execv( \"/usr/home/jenkins/workspace/Frameworks/kdesu/kf5-qt5 
> FreeBSDQt5.15/autotests/sudo\" ): No such file or directory
> execv( \"/usr/home/jenkins/workspace/Frameworks/kdesu/kf5-qt5 
> FreeBSDQt5.15/autotests/su\" ): No such file or directory
>
> It seems to me that sudo and su are not installed either?
> (I think it's trying them in the current directory, for lack of finding them 
> in the PATH)
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>


Re: kdesu on FreeBSD

2020-08-16 Thread Tobias C. Berner
Moin moin


On Sun, 16 Aug 2020 at 01:54, David Faure  wrote:
>
> https://build.kde.org/job/Frameworks/job/kdesu/job/kf5-qt5%20FreeBSDQt5.15/11/testReport/projectroot/autotests/kdesutest/
> says `xauth` isn't found.
xauth is now installed on the builders


>
> Does xauth exist on FreeBSD? Is it maybe not in $PATH? Or is it maybe just 
> not installed in the FreeBSD CI machine?
>
> The actual failure isn't related to xauth but to sudo/su output, I'll debug 
> that tomorrow by committing some debug output and reverting it soon after,
> since I can't get any FreeBSD developer to look into those failing 
> unittests...
harsh, but fair... ;-)


mfg Tobias
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>


Re: qt5-network will not build on FreeBSD 11.4

2020-08-09 Thread Tobias C. Berner
Moin moin


Yes, we are well aware that the situation is bad for people who cannot
upgrade to 12.x.

But as the support for OpenSSL1.0 was dropped, there was not much we
could do about it.
If you only require Qt and none of the Qt-OpenSSL parts, it would be
possible to build
net/qt5-network without OpenSSL support -- this would at least get you
a working Qt5, with
a somewhat partial qt5-network.

Note, that you could also switch to the quarterly ports tree, which
does not contain Qt 5.15
until the next one is cut -- so that gives you time until the end of
september to upgrade.


Again, we're sorry for this.


mfg Tobias

On Sun, 9 Aug 2020 at 10:13, Daniel Drinnon  wrote:
>
> The error is:
>
>
>
> is marked as broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x 
> or add DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf
>
>
>
> Well, setting DEFAULT_VERSIONS+=ssl=openssl
>
>
>
> Causes even more problems with other ports.  There is no solution and I am 
> not ready to “upgrade to 12.x” because of its openssl problems.
>
>
>
> In conclusion, QT5 no longer builds for FreeBSD 11.x even though FreeBSD 11.3 
> AND 11.4 are supported versions.  FreeBSD 12.x move to openssl 1.1.x broke 
> other ports.  I guess my solution is to not use any desktop managers that use 
> QT5.
>
>
>
> This is starting to look like Gnome’s latest, circa 2015.
>
>
>
> Not happy.
>
>


Re: kdenlive 20.04.2: Video codec: libx264 is not supported

2020-07-07 Thread Tobias C. Berner
Moin moin

Could you try reinstalling/rebuilding mlt?
For me that option is present.


mfg Tobias

On Tue, 7 Jul 2020 at 22:55, Dwayne MacKinnon  wrote:
>
> Hey Tobias,
>
> So, I'm running FreeBSD 12.1-RELEASE-p6, amd64. Kdenlive 20.04.2, kf5 5.71.0,
> qt5 5.14.2, all of it built using poudriere.
>
> I've attached a screenshot. You can reproduce by simply opening kdenlive and
> clicking the "Render" button.
>
> Cheers,
> DMK
>
> On Tuesday, July 7, 2020 2:22:39 P.M. EDT Tobias C. Berner wrote:
> > Moin moin
> >
> > How can I reproduce this locally?
> >
> > mfg Tobias
> >
> > On Tue, 7 Jul 2020 at 19:42, Dwayne MacKinnon  wrote:
> >
> > >
> > >
> > > Seeing the same thing myself. Very irritating.
> > >
> > >
> > >
> > > Cheers,
> > > DMK
> > >
> > >
> > >
> > > On Tuesday, July 7, 2020 9:29:01 A.M. EDT Владимир Тимофиев wrote:
> > >
> > > > After updating kdenlive to 04.20.2, this began to appear in the
> > > > options:
> > > >
> > > >
> > > >
> > > > Video codec: libx264 is not supported
> > > > How is it treated?
> > > > Before that, everything worked.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > FreeBSD A9t 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC i386
> > > > --
> > > > Желаю вам поддержки Свыше и успеха!
> > > >
> > > >
> > > >
> > > > С уважением,
> > > > Ваш  Владимир Тимофиев <http://copi.ru/94717/>
> > > > тел./viber: +380504948657
> > >
> > >
>


Re: kdenlive 20.04.2: Video codec: libx264 is not supported

2020-07-07 Thread Tobias C. Berner
Moin moin

How can I reproduce this locally?

mfg Tobias

On Tue, 7 Jul 2020 at 19:42, Dwayne MacKinnon  wrote:
>
> Seeing the same thing myself. Very irritating.
>
> Cheers,
> DMK
>
> On Tuesday, July 7, 2020 9:29:01 A.M. EDT Владимир Тимофиев wrote:
> > After updating kdenlive to 04.20.2, this began to appear in the options:
> >
> > Video codec: libx264 is not supported
> > How is it treated?
> > Before that, everything worked.
> >
> >
> >
> >
> > FreeBSD A9t 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC i386
> > --
> > Желаю вам поддержки Свыше и успеха!
> >
> > С уважением,
> > Ваш  Владимир Тимофиев 
> > тел./viber: +380504948657
>


Re: Missing time in panel

2020-06-22 Thread Tobias C. Berner
Awesome, glad to hear it.

mfg Tobias

On Mon, 22 Jun 2020 at 18:39, Jeremy  wrote:
>
> And voila! You guys saved me about two days of chasing my tail. Creating the 
> symbolic link for /etc/localtime to the Chicago time zone in 
> /use/share/zoneinfo fixed the issue. Now the time and date are properly 
> displayed on the panel and in the sddm greeter.
>
> Thanks for your help,
> Jeremy Cox
>
> On Mon, Jun 22, 2020, 09:05 Adriaan de Groot  wrote:
>>
>> On Monday, 22 June 2020 12:14:51 CEST Jeremy wrote:
>> > My /etc/localtime file is a binary file. It isn't a symbolic link to the
>> > timezone file.
>>
>> That's actually a really important bit, there: try moving it aside for a
>> moment, making it a symlink, and then giving it a try. I thought I had 
>> re-done
>> the patches handling that case for FreeBSD, and landed them in 5.15.
>>
>> [ade]


Re: Missing time in panel

2020-06-22 Thread Tobias C. Berner
Moin moin

Interesting -- I have been using that branch for quite some time now,
and have not noticed this.


mfg Tobias

On Sun, 21 Jun 2020 at 21:20, Jeremy  wrote:
>
> I decided to clone the freebsd-ports-kde qt5-5.15.0 branch and rebuild 
> plasma5 based on qt5.15, instead of waiting for the exp-run to complete.
>
> The qt5 ports and plasma5 ports rebuilt successfully and are running well. 
> However, the digital clock on the lower right hand corner of the panel is 
> missing. I don't see an option to add it. I tried adding a digital clock 
> widget to the panel and it doesn't display either.
>
> And when I click the space where the digital clock should appear, the 
> calendar pops up. It displays the current month as January and below that is 
> a comma and the number zero where I believe a holiday event might appear(?) I 
> don't remember. In the boxes where the numbered days should be, the numbers 
> start with negative five and increase numerically by one as in a normal 
> calendar and end in 36.
>
> I wanted to see if anyone else has experienced these issues before I try a 
> drastic step like clearing out all of the configuration and qml cache files.
>
> Thank you guys for all of your hard work keeping plasma5 current and updated 
> regularly.
>
> Regards,
> Jeremy Cox


Re: Missing files, kf5-extra-cmake-modules

2020-06-12 Thread Tobias C. Berner
Moin moin

what options do you have selected?


mfg Tobias

On Sat, 13 Jun 2020 at 06:14, Chris Nicol  wrote:
>
> Dear kde,
>
> In an effort to build editors/calligra on a SunBlade 100 running FreeBSD
> 12.1, devel/kf5-extra-cmake-modules is called to be built.
>
> Here are the first two lines of the Makefile:
>
> # Created by: Yuri Victorovich 
> # $FreeBSD: head/devel/kf5-extra-cmake-modules/Makefile 534966
> 2020-05-11 23:51:58Z dbaio $
>
> When the build for this port completes, there is an attempt to install
> the result, so that editors/calligra will continue to build. But the
> install fails with this message:
>
> ===>   calligra-3.2.1 depends on executable: pstoedit - found
> ===>   calligra-3.2.1 depends on file: /usr/local/bin/cmake - found
> ===>   calligra-3.2.1 depends on executable: ninja - found
> ===>   calligra-3.2.1 depends on executable: update-desktop-database - found
> ===>   calligra-3.2.1 depends on file:
> /usr/local/libdata/pkgconfig/eigen3.pc - found
> ===>   calligra-3.2.1 depends on executable: msgfmt - found
> ===>   calligra-3.2.1 depends on file: /usr/local/bin/meinproc5 - not found
> ===>   kf5-kdoctools-5.70.0 depends on file:
> /usr/local/share/xsl/docbook/html/docbook.xsl - found
> ===>   kf5-kdoctools-5.70.0 depends on package: docbook-xml>0 - found
> ===>   kf5-kdoctools-5.70.0 depends on package: p5-URI>=0 - found
> ===>   kf5-kdoctools-5.70.0 depends on file: /usr/local/bin/cmake - found
> ===>   kf5-kdoctools-5.70.0 depends on executable: ninja - found
> ===>   kf5-kdoctools-5.70.0 depends on executable: msgfmt - found
> ===>   kf5-kdoctools-5.70.0 depends on file:
> /usr/local/share/ECM/cmake/ECMConfig.cmake - not found
> ===>  Installing for kf5-extra-cmake-modules-5.70.0_1
> ===>  Checking if kf5-extra-cmake-modules is already installed
> ===>   Registering installation for kf5-extra-cmake-modules-5.70.0_1 as
> automatic
> pkg-static: Unable to access file
> /usr/ports/devel/kf5-extra-cmake-modules/work/stage/usr/local/share/doc/extra-cmake-modules/html/_static/default.css:No
> such file or directory
> pkg-static: Unable to access file
> /usr/ports/devel/kf5-extra-cmake-modules/work/stage/usr/local/share/doc/extra-cmake-modules/html/_static/documentation_options.js:No
> such file or directory
> pkg-static: Unable to access file
> /usr/ports/devel/kf5-extra-cmake-modules/work/stage/usr/local/share/doc/extra-cmake-modules/html/_static/jquery-3.4.1.js:No
> such file or directory
> pkg-static: Unable to access file
> /usr/ports/devel/kf5-extra-cmake-modules/work/stage/usr/local/share/doc/extra-cmake-modules/html/_static/language_data.js:No
> such file or directory
> *** Error code 74
>
> Stop.
> make[4]: stopped in /usr/ports/devel/kf5-extra-cmake-modules
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/ports/devel/kf5-extra-cmake-modules
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/ports/devel/kf5-kdoctools
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/editors/calligra
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/editors/calligra
>
> Not sure why these files are missing. Maybe they are supposed to be
> generated by the build? Any advice appreciated. Thank you.
>
> Chris Nicol.
> --
> __


Qt5-5.15 Packages for FreeBSD-11

2020-06-07 Thread Tobias C. Berner
Moin moin

Qt5 dropped support for OpenSSL 1.0 with Qt5-5.15.

As FreeBSD 11 only has OpenSSL 1.0 in base, that means
that there won't be any binary packages for net/qt5-network
and all ports depending on it once Qt5-5.15 lands in the
ports tree.

If you require qt5-network, you have two possible solutions
1) Upgrade to FreeBSD >=12
2) Build your own packages and switch to use OpenSSL from ports
(for all your ports).


We're sorry for the inconvenience.


mfg Tobias, with hat kde@.


Re: qt5-widgets fails to build

2020-05-31 Thread Tobias C. Berner
Moin moin

Are all your Qt5-ports up to date?


mfg Tobias

On Sun, 31 May 2020 at 11:02, Chris Nicol  wrote:
>
> Dear "kde"
>
> I am tring to build //usr/ports/graphics/xpdf, a simple programme,
> apparently, which calls for the build of x11-toolkits/qt5-widgets, for
> which you are maintainer according to the Makefile:
>
> # $FreeBSD: head/x11-toolkits/qt5-widgets/Makefile 531601 2020-04-13
> 12:35:58Z tcberner $
>
> This build is on a SunBlade 100 running FreeBSD 12.1. This is an old
> machine, so the build goes on for some time, but results in a failure at
> the linker stage - "undefined reference to QAbstractSlider", with the
> following crash dump file:
>
>
> ===>   xpdf-4.02,1 depends on file:
> /usr/local/share/ghostscript/fonts/d05l.pfb - found
> ===>   xpdf-4.02,1 depends on file: /usr/local/bin/cmake - found
> ===>   xpdf-4.02,1 depends on executable: ninja - found
> ===>   xpdf-4.02,1 depends on executable: update-desktop-database - found
> ===>   xpdf-4.02,1 depends on executable: gcc9 - found
> ===>   xpdf-4.02,1 depends on file: /usr/local/bin/as - found
> ===>   xpdf-4.02,1 depends on file: /usr/local/lib/qt5/bin/moc - found
> ===>   xpdf-4.02,1 depends on file: /usr/local/lib/qt5/bin/qmake - found
> ===>   xpdf-4.02,1 depends on shared library: libfreetype.so - found
> (/usr/local/lib/libfreetype.so)
> ===>   xpdf-4.02,1 depends on shared library: libpng.so - found
> (/usr/local/lib/libpng.so)
> ===>   xpdf-4.02,1 depends on shared library: libpaper.so - found
> (/usr/local/lib/libpaper.so)
> ===>   xpdf-4.02,1 depends on shared library: libcups.so - found
> (/usr/local/lib/libcups.so)
> ===>   xpdf-4.02,1 depends on shared library: libQt5Concurrent.so -
> found (/usr/local/lib/qt5/libQt5Concurrent.so)
> ===>   xpdf-4.02,1 depends on shared library: libQt5Core.so - found
> (/usr/local/lib/qt5/libQt5Core.so)
> ===>   xpdf-4.02,1 depends on shared library: libQt5Gui.so - found
> (/usr/local/lib/qt5/libQt5Gui.so)
> ===>   xpdf-4.02,1 depends on shared library: libQt5Network.so - found
> (/usr/local/lib/qt5/libQt5Network.so)
> ===>   xpdf-4.02,1 depends on shared library: libQt5PrintSupport.so -
> not found
> ===>   qt5-printsupport-5.14.2 depends on package: pkgconf>=1.3.0_1 - found
> ===>   qt5-printsupport-5.14.2 depends on executable: gcc9 - found
> ===>   qt5-printsupport-5.14.2 depends on file: /usr/local/bin/as - found
> ===>   qt5-printsupport-5.14.2 depends on file:
> /usr/local/lib/qt5/bin/moc - found
> ===>   qt5-printsupport-5.14.2 depends on file:
> /usr/local/lib/qt5/bin/qmake - found
> ===>   qt5-printsupport-5.14.2 depends on shared library: libcups.so -
> found (/usr/local/lib/libcups.so)
> ===>   qt5-printsupport-5.14.2 depends on shared library: libQt5Core.so
> - found (/usr/local/lib/qt5/libQt5Core.so)
> ===>   qt5-printsupport-5.14.2 depends on shared library: libQt5Gui.so -
> found (/usr/local/lib/qt5/libQt5Gui.so)
> ===>   qt5-printsupport-5.14.2 depends on shared library:
> libQt5Widgets.so - not found
> ===>  Building for qt5-widgets-5.14.2
> cd
> /usr/ports/x11-toolkits/qt5-widgets/work/qtbase-everywhere-src-5.14.2/src/tools/uic
> &&  /usr/bin/env QT_SELECT=qt5
> QMAKEMODULES="/usr/ports/x11-toolkits/qt5-widgets/work/qtbase-everywhere-src-5.14.2/mkspecs/modules:/usr/local/lib/qt5/mkspecs/modules"
> XDG_DATA_HOME=/usr/ports/x11-toolkits/qt5-widgets/work
> XDG_CONFIG_HOME=/usr/ports/x11-toolkits/qt5-widgets/work
> HOME=/usr/ports/x11-toolkits/qt5-widgets/work
> PATH=/usr/ports/x11-toolkits/qt5-widgets/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
> NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh
> NO_LINT=YES ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar"
> AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt"
> GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld"
> NM="/usr/local/bin/nm" OBJCOPY="/usr/local/bin/objcopy"
> OBJDUMP="/usr/local/bin/objdump" RANLIB="/usr/local/bin/ranlib"
> READELF="/usr/local/bin/readelf" SIZE="/usr/local/bin/size"
> STRINGS="/usr/local/bin/strings" LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8
> PREFIX=/usr/local  LOCALBASE=/usr/local  CC="gcc9" CFLAGS="-O2 -pipe
> -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9
> -fno-strict-aliasing "  CPP="cpp9" CPPFLAGS=""  LDFLAGS="
> -Wl,--as-needed -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9
> -L/usr/local/lib/gcc9 " LIBS=""  CXX="g++9" CXXFLAGS="-O2 -pipe
> -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9
> -Wl,-rpath=/usr/local/lib/gcc9 "  MANPREFIX="/usr/local"
> BSD_INSTALL_PROGRAM="install  -s -m 555"  BSD_INSTALL_LIB="install  -s
> -m 0644"  BSD_INSTALL_SCRIPT="install  -m 555"
> BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
> make -f Makefile
> INSTALL_ROOT=/usr/ports/x11-toolkits/qt5-widgets/work/stage all
> rm -f libQt5Widgets.so.5.14.2 libQt5Widgets.so libQt5Widgets.so.5
> libQt5Widgets.so.5.14
> g++9 -Wl,--as-needed -fstack-protector-strong
> -Wl,-rpath=/usr/local/lib/gcc9 -L/u

Re: weird problem with 'win' key

2020-05-09 Thread Tobias C. Berner
Glad to hear :)

mfg Tobias

On Sat, 9 May 2020 at 17:46, Andriy Gapon  wrote:
>
> On 04/05/2020 10:23, Andriy Gapon wrote:
> > Those \t entries were a red herring.
> > From a cursory look through the code I see that \t is indeed a separator 
> > used by
> > kglobalaccel to multiple separate key combinations assigned to the same 
> > action
> > and type (default, custom).  Not sure if the UI supports such multiple
> > combinations, but the backend certainly does.
> >
> > Anyway, more importantly, simply restarting kglobalaccel ('kquitapp5
> > kglobalaccel ; kglobalaccel5 &') fixes the meta key shortcuts, no need to 
> > edit
> > kglobalshortcutsrc.
> >
> > So, it must be something in startup code of some kde/plasma component that
> > messes up "Meta" key.
> > But what and how?..
>
> Good news.
> After a recent update from 5.18.4.1 to 5.18.5 the problem is gone.
>
> --
> Andriy Gapon


Re: Why is video capture patched out?

2020-04-09 Thread Tobias C. Berner
Moin moin

Kai recently provided patches to enable it again in Qt5.14 which will land
in the tree soonish.


https://github.com/freebsd/freebsd-ports-kde/commit/28d0600bd27b3c39d678f3106da9dff0d82a41c6

Mfg Tobias

Tamas Szakaly  schrieb am Do., 9. Apr. 2020, 12:57:

> Dear kde@ and chromium@ team!
>
> Due to the situation the world is in right now, I needed WebRTC-based
> video conferencing to work, so I was poking around in the www/qt5-webengine
> code. What I've found is that video capture is patched out with the
> following two files:
>
>  -
> patch-src_3rdparty_chromium_media_capture_video_linux_video__capture__device__factory__linux.cc
>  -
> patch-src_3rdparty_chromium_media_capture_video_linux_video__capture__device__linux.cc
>
> With these patches applied,
> VideoCaptureDeviceFactoryLinux::HasUsableFormats always returns false, so
> capable devices are not even detected. When I remove those "#if
> !defined(OS_FREEBSD)" lines, video capture works fine; I've been using
> Jitsi and Facebook Messenger for a few days now from qutebrowser. I haven't
> tried them yet, but www/chromium and www/iridium has these patches too. I
> should also say that I've made a comment with essentially the same content
> on a Bugzilla issue (
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245250), so apologies
> if this mail is redundant.
>
> What I'd like to ask is if there's any reason for these patches (maybe
> some known problems that do not occur on my box), or they are just leftover
> files from earlier versions. I've tried searching for some info on this,
> tried git --follow, but couldn't find anything.
>
> Best regards,
> Tamas
>
> --
> Tamas Szakaly
> @sghctoma
>
>


Re: apps show background, menus show as black boxes or background

2020-03-15 Thread Tobias C. Berner
Moin moin

Your original message in February did reach the list (it just required
some manual interaction in the spam filter to allow it):
https://mail.kde.org/pipermail/kde-freebsd/2020-February/033281.html

Have you tried disabling/enabling the compositor?

mfg Tobias

On Sun, 15 Mar 2020 at 22:23, David L. Sanford  wrote:
>
> I have been using kde5 on freebsd for some time now.  But the latest
> version is not working for me.  Here is my current setup:
>
> VirtualBox Graphical User Interface Version 6.0.12_SUSE r132055
> FreeBSD 12.1-RELEASE r354233 GENERIC  amd64
> xorg-7.7_3
> kde5-5.17.4.19.12.0
>
> When I open Konsole and try to pull the bottom down to make the display
> higher, the background starts showing through rather than the Konsole
> content.  And any pop-up or pull down dialogs I try to open just show a
> black box or the background.
>
> This did not happen with the original version of kde5 that installed
> with FreeBSD 12.0-RELEASE.  It has only started happening when I tried
> to update to kde5-5.17.3 on FreeBSD 12.0-RELEASE.  I decided to install
> the latest of everything, and the problem still persists.
>
> I tried sending you this report before with a screenshot attached, but
> got the following response:
>
> ==
>
> Your mail to 'kde-freebsd' with the subject
>
>  apps show background, menus show as black boxes
>
> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
>  Message body is too big: 439899 bytes with a limit of 100 KB
>
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.
>
> ==
>
> I never received a notification nor had my message posted to the list.
>
>
>


Re: kdenlive-19.12.0 and 19.12.1 too slow to be usable

2020-01-25 Thread Tobias C. Berner
Moin moin

Could you open an upstream bug-report at  https://bugs.kde.org/


mfg Tobias

On Thu, 23 Jan 2020 at 21:41, Simon Gerraty  wrote:
>
> FYI, I fecthed and installed:
>
> https://pkg.freebsd.org/FreeBSD:11:amd64/release_3/All/kdenlive-18.12.3.txz
>
> which works much better.  I still get noise on tty - presumably from
> some of the libraries that kdenlive uses (there are all still from
> quarterly collection), but kdenlive works better, playhead tracks video
> ok and audio plays in sync.
>
> --sjg
>
> On Wed, 22 Jan 2020 10:19:30 -0800, Simon Gerraty writes:
> >Hi all.
> >
> >I cc'd ports, since kdenlive depends on lots of other packages.
> >
> >kdenlive-18.x was working fine on my
> >i9-7900X CPU @ 3.30GHz (10 core), with
> >NVIDIA GPU GeForce GTX 1050 Ti
> >
> >I recently ran pkg upgrade -f, and now with kdenlive-19.12.0
> >is it completely unusable.
> >
> >The display is sluggish (to put it kindly); the play head moves in big
> >jumps (stalls for several seconds at times), the video does not display
> >even close to smoothly, and the audio is out of sync.
> >
> >There is also a huge volume of debug info being spewed to tty, with what
> >looks like lots of errors.  Which I did not see with 18.x
> >
> >Since the release notes for kdenlive 19.12.1 mentioned disabling debug,
> >I tried downloading the kdenlive-19.12.1 from the latest pkg build, and
> >that installs and runs, but I still see lots of debug noise on tty
> >and the performance is still too bad to allow editing of anything.
> >
> >Just to confuse things further, a machine at work, which run pkg
> >upgrade -f at about the same time, kdenlive-19.12.0 works tollerably
> >despite the endless stream of debug output.
> >
> >That box has Xeon(R) CPU E5-2637 v3 @ 3.50GHz (8 core) with
> >NVIDIA GPU Quadro K4200 (GK104GL)
> >
> >Thoughts?
> >--sjg


Re: [kmail2] [Bug 387061] Large messages don't display in the viewer pane

2020-01-18 Thread Tobias C. Berner
Moin moin

Qt5.14 should land in the tree in the next few weeks; in the meantime
I added upstreams fix for this in r523504.


mfg Tobias

On Sat, 18 Jan 2020 at 23:34, Greg Rivers  wrote:
>
> FYI, for those of you who have suffered with this problem for the past 2+ 
> years, this was fixed upstream a few days ago. The commit message says 
> "FIXED-IN: 5.14.0".
>
> Is there a time estimate for when this version will be picked up by the 
> FreeBSD port?
>
> 
>
> --
> Greg
>
>


Re: Does FreeBSD have HAL?

2020-01-05 Thread Tobias C. Berner
Moin moin

We will replace (ancient) hal with Gleb's implementation of usdisks2
"bsdisks2" in the near future by default.

Hald is likely not enabled on the CI hosts -- I could enable it :) --
or we could push the switch and make bsdisks2 the default in master,
which I would prefer.
What is your thought on this Gleb?


mfg Tobias

On Sat, 4 Jan 2020 at 18:16, David Faure  wrote:
>
> solid/src/CMakeLists.txt offers the option to use "UDisks2/bsdisks backend 
> instead of HAL to manage disk devices" on FreeBSD, but OFF by default.
>
> So the default is the HAL backend, which however completely fails on CI:
> https://build.kde.org/job/Frameworks/view/Platform%20-%20FreeBSDQt5.13/job/solid/job/kf5-qt5%20FreeBSDQt5.13/52/testReport/projectroot/autotests/halbasictest/
> basically says that org.freedesktop.Hal is not running (on the system bus)
>
> FreeBSD users: does `qdbus --system org.freedesktop.HalManager` work for you?
> If it does, any idea what should be done on the CI to make that work there?
>
> I'm really hoping for fully-green unittests one day, but FreeBSD isn't really 
> helping with that :-)
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>


Re: KDE session display scrambled (was Re: sddm blank screen)

2019-12-19 Thread Tobias C. Berner
Moin moin


Why are you starting plasmashell directly? And not using
startplasma-x11, the latter does all the init.

The second part of your description sounds like an incomplete installation.
Could you check if your packages are all installed properly or if they
have files missing (-> pkg check).


mfg Tobias

On Thu, 19 Dec 2019 at 10:07, Graham Menhennitt
 wrote:
>
> So, I've got things partially working, but it's not very good.
>
> I created a .xinitrc containing:
>  kwin_x11 &
>  exec plasmashell
> and then run startx.
>
> I do get a plasma desktop with a Task Manager and an Application
> Launcher. But the launcher is mostly empty (Favourites, Applications,
> Computer, History, and Leave but no applications in any of them). And
> when I manually add things to them, they've disappeared when I restart.
>
> I'm tempted to blow the whole machine away and reinstall from scratch,
> but I'd like to try any alternatives first.
>
> Any further help would be appreciated.
>
> Thanks,
>  Graham
>
>
> On 15/12/19 10:25 pm, Graham Menhennitt wrote:
> > Thanks again for the reply.
> >
> > When I do the .xinitrc change and run startx, I get the problem again.
> > If I do startx without the .xinitrc, then do the "exec ck.." bit from
> > a xterm, I also get the problem. But if I do startx and then run
> > plasmashell from an xterm, it's all ok.
> >
> > Any more clues?
> >
> > Thanks,
> >
> > Graham
> >
> > On 15/12/19 8:40 pm, Tobias C. Berner wrote:
> >> Moin moin
> >>
> >> Correct; You can check the pkg-message of plasma5-plasma-workspace on
> >> how to start it directly:
> >> Create a ~/.xinitrc with the following content:
> >> exec ck-launch-session startplasma-x11
> >>
> >> Then use 'startx' to start X.
> >>
> >> As a side-note, can you make sure, that all your installed software is
> >> up-to-date?
> >>
> >> mfg Tobias
> >>
> >> On Sun, 15 Dec 2019 at 09:54, Graham Menhennitt
> >>  wrote:
> >>> Thanks for replying, Tobias.
> >>>
> >>> I'm not sure that I know how to do that. A bit of googling suggests
> >>> running startx from the console and then running plasmashell from an
> >>> xterm.
> >>>
> >>> When I do that, I get a good working desktop. I don't get the KDE
> >>> window
> >>> manager though - I get my twm from startx.
> >>>
> >>> Is that what you meant? If so, and since the desktop looks good, what's
> >>> my next step to getting back to sddm?
> >>>
> >>> Thanks again,
> >>>
> >>>   Graham
> >>>
> >>> On 15/12/19 5:42 pm, Tobias C. Berner wrote:
> >>>> Moin moin
> >>>>
> >>>> does it work properly if you start plasma desktop via startx
> >>>> instead of sddm?
> >>>>
> >>>>
> >>>> mfg Tobias
> >>>>
> >>>> On Sun, 15 Dec 2019 at 03:00, Graham Menhennitt
> >>>>  wrote:
> >>>>> It turns out that the problem I described below was due to the
> >>>>> wrong NVidia driver being loaded. It appears that I now need to
> >>>>> use the -390 version rather than the default -440 version. So now
> >>>>> sddm-greeter doesn't crash and I get the login screen correctly.
> >>>>>
> >>>>> But after I login, the screen goes crazy. I get a bunch of
> >>>>> horizontal white lines appearing which make it seem like I'm
> >>>>> looking out a window through venetian blinds. I can make out the
> >>>>> icons for some of the programs that are running (Firefox etc.) but
> >>>>> it's effective unusable.
> >>>>>
> >>>>> My video card is a GeForce GT 730. And I'm running 12-Stable on
> >>>>> AMD64.
> >>>>>
> >>>>> Do I now need an Xorg.conf perhaps?
> >>>>>
> >>>>> Does anybody have any ideas, please?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>>   Graham
> >>>>>
> >>>>>
> >>>>> On 11/12/19 10:28 pm, Graham Menhennitt wrote:
> >>>>>
> >>>>> Following up myself...
> >>>>>
> >>>>> Some 

Re: KDE session display scrambled (was Re: sddm blank screen)

2019-12-15 Thread Tobias C. Berner
Moin moin

Correct; You can check the pkg-message of plasma5-plasma-workspace on
how to start it directly:
Create a ~/.xinitrc with the following content:
   exec ck-launch-session startplasma-x11

Then use 'startx' to start X.

As a side-note, can you make sure, that all your installed software is
up-to-date?

mfg Tobias

On Sun, 15 Dec 2019 at 09:54, Graham Menhennitt
 wrote:
>
> Thanks for replying, Tobias.
>
> I'm not sure that I know how to do that. A bit of googling suggests
> running startx from the console and then running plasmashell from an xterm.
>
> When I do that, I get a good working desktop. I don't get the KDE window
> manager though - I get my twm from startx.
>
> Is that what you meant? If so, and since the desktop looks good, what's
> my next step to getting back to sddm?
>
> Thanks again,
>
>  Graham
>
> On 15/12/19 5:42 pm, Tobias C. Berner wrote:
> > Moin moin
> >
> > does it work properly if you start plasma desktop via startx instead of 
> > sddm?
> >
> >
> > mfg Tobias
> >
> > On Sun, 15 Dec 2019 at 03:00, Graham Menhennitt
> >  wrote:
> >> It turns out that the problem I described below was due to the wrong 
> >> NVidia driver being loaded. It appears that I now need to use the -390 
> >> version rather than the default -440 version. So now sddm-greeter doesn't 
> >> crash and I get the login screen correctly.
> >>
> >> But after I login, the screen goes crazy. I get a bunch of horizontal 
> >> white lines appearing which make it seem like I'm looking out a window 
> >> through venetian blinds. I can make out the icons for some of the programs 
> >> that are running (Firefox etc.) but it's effective unusable.
> >>
> >> My video card is a GeForce GT 730. And I'm running 12-Stable on AMD64.
> >>
> >> Do I now need an Xorg.conf perhaps?
> >>
> >> Does anybody have any ideas, please?
> >>
> >> Thanks,
> >>
> >>  Graham
> >>
> >>
> >> On 11/12/19 10:28 pm, Graham Menhennitt wrote:
> >>
> >> Following up myself...
> >>
> >> Some time after the screen goes blank (about 10 seconds), I get a message 
> >> logged:
> >>
> >>  pid 1178 (sddm-greeter), jid 0, uid 219: exited on signal 6 (core 
> >> dumped)
> >>
> >> When I run lldb with sddm-greeter and the core file, I get the following 
> >> stack backtrace. Does that help?
> >>
> >> In the meantime, I'll try building Qt with debug symbols.
> >>
> >> Thanks,
> >>
> >>  Graham
> >>
> >> * thread #1, name = 'sddm-greeter', stop reason = signal SIGABRT
> >>* frame #0: 0x000801c3b86a libc.so.7`__sys_thr_kill at thr_kill.S:3
> >>  frame #1: 0x000801c39c94 libc.so.7`__raise(s=6) at raise.c:52:10
> >>  frame #2: 0x000801badf09 libc.so.7`abort at abort.c:67:8
> >>  frame #3: 0x000801655919 
> >> libQt5Core.so.5`___lldb_unnamed_symbol156$$libQt5Core.so.5 + 9
> >>  frame #4: 0x000801656f7e 
> >> libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 202
> >>  frame #5: 0x000800527e99 
> >> libQt5Quick.so.5`QSGRenderLoop::handleContextCreationFailure(QQuickWindow*,
> >>  bool) + 297
> >>  frame #6: 0x000800528539 
> >> libQt5Quick.so.5`___lldb_unnamed_symbol2048$$libQt5Quick.so.5 + 505
> >>  frame #7: 0x000800528cf8 
> >> libQt5Quick.so.5`___lldb_unnamed_symbol2049$$libQt5Quick.so.5 + 72
> >>  frame #8: 0x00080104b21b libQt5Gui.so.5`QWindow::event(QEvent*) + 
> >> 907
> >>  frame #9: 0x00080059dd5e 
> >> libQt5Quick.so.5`QQuickWindow::event(QEvent*) + 814
> >>  frame #10: 0x000801839842 
> >> libQt5Core.so.5`QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) 
> >> + 338
> >>  frame #11: 0x000801839362 
> >> libQt5Core.so.5`QCoreApplication::notifyInternal2(QObject*, QEvent*) + 210
> >>  frame #12: 0x00080103ebcc 
> >> libQt5Gui.so.5`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*)
> >>  + 332
> >>  frame #13: 0x000801020afc 
> >> libQt5Gui.so.5`QWindowSystemInterface::sendWindowSystemEvents(QFlags)
> >>  + 220
> >>  frame #14: 0x0008055b58bf 
> >> libQt5XcbQpa.so.5`___lldb_unnamed_symbol344$$libQt5XcbQpa.so.5 + 31
> >>  frame #15: 0x00080

Re: KDE session display scrambled (was Re: sddm blank screen)

2019-12-14 Thread Tobias C. Berner
Moin moin

does it work properly if you start plasma desktop via startx instead of sddm?


mfg Tobias

On Sun, 15 Dec 2019 at 03:00, Graham Menhennitt
 wrote:
>
> It turns out that the problem I described below was due to the wrong NVidia 
> driver being loaded. It appears that I now need to use the -390 version 
> rather than the default -440 version. So now sddm-greeter doesn't crash and I 
> get the login screen correctly.
>
> But after I login, the screen goes crazy. I get a bunch of horizontal white 
> lines appearing which make it seem like I'm looking out a window through 
> venetian blinds. I can make out the icons for some of the programs that are 
> running (Firefox etc.) but it's effective unusable.
>
> My video card is a GeForce GT 730. And I'm running 12-Stable on AMD64.
>
> Do I now need an Xorg.conf perhaps?
>
> Does anybody have any ideas, please?
>
> Thanks,
>
> Graham
>
>
> On 11/12/19 10:28 pm, Graham Menhennitt wrote:
>
> Following up myself...
>
> Some time after the screen goes blank (about 10 seconds), I get a message 
> logged:
>
> pid 1178 (sddm-greeter), jid 0, uid 219: exited on signal 6 (core dumped)
>
> When I run lldb with sddm-greeter and the core file, I get the following 
> stack backtrace. Does that help?
>
> In the meantime, I'll try building Qt with debug symbols.
>
> Thanks,
>
> Graham
>
> * thread #1, name = 'sddm-greeter', stop reason = signal SIGABRT
>   * frame #0: 0x000801c3b86a libc.so.7`__sys_thr_kill at thr_kill.S:3
> frame #1: 0x000801c39c94 libc.so.7`__raise(s=6) at raise.c:52:10
> frame #2: 0x000801badf09 libc.so.7`abort at abort.c:67:8
> frame #3: 0x000801655919 
> libQt5Core.so.5`___lldb_unnamed_symbol156$$libQt5Core.so.5 + 9
> frame #4: 0x000801656f7e libQt5Core.so.5`QMessageLogger::fatal(char 
> const*, ...) const + 202
> frame #5: 0x000800527e99 
> libQt5Quick.so.5`QSGRenderLoop::handleContextCreationFailure(QQuickWindow*, 
> bool) + 297
> frame #6: 0x000800528539 
> libQt5Quick.so.5`___lldb_unnamed_symbol2048$$libQt5Quick.so.5 + 505
> frame #7: 0x000800528cf8 
> libQt5Quick.so.5`___lldb_unnamed_symbol2049$$libQt5Quick.so.5 + 72
> frame #8: 0x00080104b21b libQt5Gui.so.5`QWindow::event(QEvent*) + 907
> frame #9: 0x00080059dd5e 
> libQt5Quick.so.5`QQuickWindow::event(QEvent*) + 814
> frame #10: 0x000801839842 
> libQt5Core.so.5`QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) + 
> 338
> frame #11: 0x000801839362 
> libQt5Core.so.5`QCoreApplication::notifyInternal2(QObject*, QEvent*) + 210
> frame #12: 0x00080103ebcc 
> libQt5Gui.so.5`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*)
>  + 332
> frame #13: 0x000801020afc 
> libQt5Gui.so.5`QWindowSystemInterface::sendWindowSystemEvents(QFlags)
>  + 220
> frame #14: 0x0008055b58bf 
> libQt5XcbQpa.so.5`___lldb_unnamed_symbol344$$libQt5XcbQpa.so.5 + 31
> frame #15: 0x0008029483c7 libglib-2.0.so.0`g_main_context_dispatch + 
> 311
> frame #16: 0x000802948753 
> libglib-2.0.so.0`___lldb_unnamed_symbol117$$libglib-2.0.so.0 + 515
> frame #17: 0x000802948804 libglib-2.0.so.0`g_main_context_iteration + 
> 100
> frame #18: 0x000801891e06 
> libQt5Core.so.5`QEventDispatcherGlib::processEvents(QFlags)
>  + 102
> frame #19: 0x000801834a0e 
> libQt5Core.so.5`QEventLoop::exec(QFlags) + 494
> frame #20: 0x000801839ace libQt5Core.so.5`QCoreApplication::exec() + 
> 142
> frame #21: 0x002696a4 
> sddm-greeter`___lldb_unnamed_symbol211$$sddm-greeter + 996
> frame #22: 0x0025510f 
> sddm-greeter`___lldb_unnamed_symbol1$$sddm-greeter + 271
>
>
> On 11/12/19 6:39 pm, Graham Menhennitt wrote:
>
> Hello all,
>
> I'm running KDE on FreeBSD 12-Stable as of last week. I rebuilt all of my 
> ports and now I can't get sddm to start properly. When it starts, my display 
> switches to vt 9 and all I see is an empty screen. I've uninstalled, rebuilt, 
> and reinstalled the port.
>
> If I stop sddm and run startx, I correctly get a few xterms so I think the X 
> side of things is working correctly.
>
> Below is a session from sddm.log.
>
> Does anybody have any clues, please?
>
> Thanks in advance for any help,
>
> Graham
>
>
> On starting with "service sddm onestart":
>
> [18:11:50.940] (II) DAEMON: No session manager found
>
> [18:11:50.940] (II) DAEMON: Adding new display on vt 9 ...
> [18:11:50.941] (II) DAEMON: Loading theme configuration from ""
> [18:11:50.941] (II) DAEMON: Display server starting...
> [18:11:50.941] (II) DAEMON: Running: /usr/local/bin/X -nolisten tcp -auth 
> /var/run/sddm/{96b45809-91c0-4a86-8533-01e4ef2920f9} -background none 
> -noreset -displayfd 11 -seat seat0 vt9
> [18:11:51.629] (II) DAEMON: Setting default cursor
> [18:11:51.631] (WW) DAEMON: Could not setup default cursor
> [18:11:51.631] (II) DAEMON: Running display setup script 
> "/usr/local/share/sddm/scripts

Re: FreeBSD Port: graphics/digikam

2019-10-09 Thread Tobias C. Berner
Hi Holger

Sorry for the breakage. Due to a lack of free time, I could not yet
investigate the breakage.I will, as soon as I can :)

The quarterly branch gives you no guarantees at all -- it is cut at a given
time, and if you are lucky the tree was in a good state at the time.
Afterwards it just mostly gets older :D -- so there is no process of
choosing "stable" staff for the quarterly (so it's purely timing based --
quarterly, literally).

I think this time it was just bad luck, I assume, I did some testing and
found it working, but apparently it wasn't, or I didn't  :)  -- totally my
bad here.

I hope to have time to fix it by this or the next weekend -- no promises,
patches are welcome :D.

If you really require it to be working right now, you can just grab the
port from the revision prior to its upgrade and built the old one -- that
should work.


mfg Tobias


On Wed, 9 Oct 2019 at 07:29, Holger Wagemann 
wrote:

> Dear maintainer,
>
> I'm a desktop user, like the work of kde-freebsd team to have a current
> plasma5 desktop and other applications like digikam.
>
> I use pkg and latest stuff, sometimes head branch and ports and apart from
> some instabilities, which were fixed in the past in a short time, I'm
> satisfied with combination of FreeBSD and plasma5 and further desktop stuff.
>
> After switching from digikam 6.0.0 to a newer version some weeks ago in
> "latest" this software is broken, it starts reproducible with a segfault.
> This bug is reported since 2019-09-10.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240466
>
> Okay, in quarterly branch 2019Q3 there was digikam in version 6.0.0 and
> this version works. So some days ago I've switched from head to quarterly,
> to reduce such issues.
>
> But yesterday you switched to new quarterly branch 2019Q4 and with a pkg
> upgrade I get new binaries, also digikam, and now in version 6.3.0. And it
> starts with a segfault.
>
> My question: Why putting broken stuff from head in a new quarterly branch?
> I thought, that quarterly protects user from such issues and only working
> stuff from head was putting into a new quarterly branch (like manjaro:
> stuff from testing repo was putting to stable repo, when it is stable). But
> it seems, that a new quartely branch only get a snapshot of binaries from
> head without any inspection, if this stuff works or not.
>
> What can I do to get a working version of digikam in combination with
> FreeBSD?
>
> And how can I avoid such issues in the future? Still using quarterly seems
> not to be enough. Please keep in mind, that I'm a user and not a developer.
>
> Kind regards
>   Holger
>


Re: qt5-gui compile error

2019-10-03 Thread Tobias C. Berner
Moin moin

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

mfg Tobias

On Thu, 3 Oct 2019 at 12:38, Maryse LEVAVASSEUR <
maryse.levavass...@stormshield.eu> wrote:

> Hello,
>
> I am experiencing a blocking issue while trying to update
> x11-toolkits/qt5-gui from 5.12.2_1 to 5.13.0_1.
>
> I am using FreeBSD 11.3 and I have some linux packages installed.
>
> You can find below the compilation error, my "uname -a" and the list of
> linux packages I am using.
>
> If you need more information, please let me know.
>
> Regards,
>
> Maryse
>
>
>
> --- .obj/qevdevtouchhandler.o ---
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:27:8: error: redefinition of 'input_event'
> struct input_event {
> ^
> /usr/include/dev/evdev/input.h:44:8: note: previous definition is here
> struct input_event {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:53:8: error: redefinition of 'input_id'
> struct input_id {
> ^
> /usr/include/dev/evdev/input.h:53:8: note: previous definition is here
> struct input_id {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:84:8: error: redefinition of
> 'input_absinfo'
> struct input_absinfo {
> ^
> /usr/include/dev/evdev/input.h:60:8: note: previous definition is here
>
> struct input_absinfo {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:108:8: error: redefinition of
> 'input_keymap_entry'
> struct input_keymap_entry {
> ^
> /usr/include/dev/evdev/input.h:71:8: note: previous definition is here
> struct input_keymap_entry {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:300:8: error: redefinition of 'ff_replay'
> struct ff_replay {
> ^
> /usr/include/dev/evdev/input.h:164:8: note: previous definition is here
> struct ff_replay {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:310:8: error: redefinition of 'ff_trigger'
> struct ff_trigger {
> ^
> /usr/include/dev/evdev/input.h:170:8: note: previous definition is here
> struct ff_trigger {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:327:8: error: redefinition of
> 'ff_envelope'
> struct ff_envelope {
> ^
> /usr/include/dev/evdev/input.h:176:8: note: previous definition is here
> struct ff_envelope {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:339:8: error: redefinition of
> 'ff_constant_effect'
> struct ff_constant_effect {
> ^
> /usr/include/dev/evdev/input.h:183:8: note: previous definition is here
> struct ff_constant_effect {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:350:8: error: redefinition of
> 'ff_ramp_effect'
> struct ff_ramp_effect {
> ^
> /usr/include/dev/evdev/input.h:188:8: note: previous definition is here
> struct ff_ramp_effect {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:366:8: error: redefinition of
> 'ff_condition_effect'
> struct ff_condition_effect {
> ^
> /usr/include/dev/evdev/input.h:194:8: note: previous definition is here
> struct ff_condition_effect {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:395:8: error: redefinition of
> 'ff_periodic_effect'
> struct ff_periodic_effect {
> ^
> /usr/include/dev/evdev/input.h:221:8: note: previous definition is here
> struct ff_periodic_effect {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:416:8: error: redefinition of
> 'ff_rumble_effect'
> struct ff_rumble_effect {
> ^
> /usr/include/dev/evdev/input.h:232:8: note: previous definition is here
> struct ff_rumble_effect {
> ^
> In file included from evdevtouch/qevdevtouchhandler.cpp:62:
> In file included from /usr/local/include/mtdev.h:36:
> /usr/local/include/linux/input.h:444:8: error: redefinition of 'ff_effect'
> struct ff_effect {

Re: FreeBSD Port: x11-toolkits/qt5-gui

2019-10-02 Thread Tobias C. Berner
Moin moin

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

mfg Tobias

On Thu, 3 Oct 2019 at 01:14,  wrote:

> Hi!
>
> I tried to update ports on FreeBSD 12.0-RELEASE-p10 (amd64) and it
> stopped in qt5-gui:
>
>  --- .obj/qevdevtouchhandler.o ---
> *** [.obj/qevdevtouchhandler.o] Error code 1
>
> make[3]: stopped in
>
> /usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport/input
> 1 error
>
> make[3]: stopped in
>
> /usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport/input
> *** [sub-input-support-pro-all-ordered] Error code 2
>
> make[2]: stopped in
>
> /usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport/input
> 1 error
>
> make[2]: stopped in
>
> /usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport/input
> *** [sub-input-all] Error code 2
>
> make[1]: stopped in
>
> /usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport
> 1 error
>
> make[1]: stopped in
>
> /usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport
> *** Error code 2
>
> Stop.
> make: stopped in /usr/ports/x11-toolkits/qt5-gui
>
> Thank you.
>
> --
> “Hungry man, reach for the book: it is a weapon.”
>
> ― Bertolt Brecht
>


Re: display manager that supports multiple X servers

2019-07-09 Thread Tobias C. Berner
Moin moin

Have you looked at x11/sddm [1] [2]


mfg Tobias

[1] https://www.freshports.org/x11/sddm/
[2] https://github.com/sddm/sddm

On Tue, 9 Jul 2019 at 20:40, Andriy Gapon  wrote:

>
> Now that kdm is gone I need to find a replacement for a feature that I
> want to
> use on some systems.  Since switching users in KDE never worked for me
> (either
> in KDE 4 or now), I used to start several X servers, each on its own VT,
> each
> with a greeter.  One user could log in on VT9 and another on VT10, etc.
> They
> could not work at the same time, of course.  But they could time share the
> computer.  This setup was easy with kdm.
>
> Now, I have looked at several still supported DM-s and none of them seems
> to
> support that feature.  Various Linux documentation talks a lot of
> multi-seat and
> I think that what I want is a simpler subset of the multi-seat.  But it
> seems
> all mainstream DMs support multi-seat only via Linux / systemd based
> infrastructure like logind / loginctl etc.  I could not find a way to
> explicitly
> configure multiple X servers on multiple VTs.
>
> I guess that I should be able to achieve what I want with xdm and
> /etc/ttys, but
> xdm is so ugly...
>
> --
> Andriy Gapon
>


Re: moving from KDE4 to KDE5

2019-06-17 Thread Tobias C. Berner
On Mon, 17 Jun 2019 at 21:02, Matthias Apitz  wrote:

> El día lunes, junio 17, 2019 a las 09:50:47a. m. -0400, Dwayne MacKinnon
> escribió:
>
> > Hi Matthias,
> >
> > If I'm not using sddm, I use the following in my .xinitrc for kf5:
> >
> > exec ck-launch-session startkde
> >
> > There are advantages, I've found, to having ConsoleKit invoked.
> >
> > As for poudriere, doing a bulk build on x11/kde5 should pull in
> everything you
> > need. I use poudriere all the time with that entry in my build file.
>
>
> Hi,
>
> I have a poudriere build file of around 400++ lines of ports:
>
> $ wc -l myThings/FreeBSD/poudriere-list
>  432 myThings/FreeBSD/poudriere-list
>
> among these (now) x11/kde5. My poudriere oven (a rackmount Dell
> PowerEdge r210) builds based on this around 2100 packages in around 48
> hours. This afternoon I installed the system (r349041) and the repo of
> the 2100 ports to an external USB disk, pkg-installed kde5 and xorg
> while chrooting into it, rebooted from it, tweaked a bit my home and
> KDE5 came up fine with 'startx' with the .xinitrc as you say, just for
> run a test. Ofc there is a lot to change/configure inside KDE5 (and a
> lot to learn if one comes from KDE4).
>
> A big thanks to all KDE @ FreeBSD folks to bring this to our ports tree.

No worries :)

mfg Tobias

>
> Btw: What is 'kf5' exactly as naming?
>
> matthias
>
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
> +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
>


Re: Error when bootstrapping CMake

2019-05-20 Thread Tobias C. Berner
Hi Paul

I would suggest you make sure your FreeBSD base installation is not broken.
It still sounds like that is the problem on your machine.


mfg Tobias

On Tue, 21 May 2019 at 03:42, Paul Beard  wrote:

> /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.20 required by
> /usr/ports/devel/cmake/work/cmake-3.14.4/Bootstrap.cmk/cmake not found
> -
> 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/work/cmake-3.14.4/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
>
> ls -l /usr/ports/devel/cmake/work/cmake-3.14.4/config.log
> ls: /usr/ports/devel/cmake/work/cmake-3.14.4/config.log: No such file or
> directory
>
> ImageMagick6-6.9.10.22_1,1 Image processing tools (legacy version)
> aalib-1.4.r5_13ASCII art library
> adobe-cmaps-20051217_4 Adobe CMap collection
> alsa-lib-1.1.2_2   ALSA compatibility library
> apache-ant-1.10.5  Java- and XML-based build tool,
> conceptually similar to make
> apr-1.6.5.1.6.1_1  Apache Portability Library
> argyllcms-1.9.2_4  ICC compatible color management system
> aspell-0.60.6.1_8  Spelling checker with better suggestion
> logic than ispell
> atk-2.28.1 GNOME accessibility toolkit (ATK)
> atkmm-2.24.2_3 C++ wrapper for ATK API library
> autoconf-2.69_2Automatically configure source code on many
> Un*x platforms
> autoconf-wrapper-20131203  Wrapper script for GNU autoconf
> automake-1.16.1_1  GNU Standards-compliant Makefile generator
> avahi-app-0.7_2Service discovery on a local network
> bash-5.0.7 GNU Project's Bourne Again SHell
> binutils-2.32,1GNU binary tools
> bison-3.3.2,1  Parser generator from FSF, (mostly)
> compatible with Yacc
> boehm-gc-8.0.4 Garbage collection and memory leak
> detection for C and C++
> boost-libs-1.70.0_1Free portable C++ libraries (without
> Boost.Python)
> bsdadminscripts2-0.2.1 BSD Administration Scripts 2
> c-ares-1.15.0  Asynchronous DNS resolver library
> c3p0-0.9.5.3   Library for augmenting JDBC drivers with
> JNDI-bindable DataSources
> ca_root_nss-3.44   Root certificate bundle from the Mozilla
> Project
> cacti-1.2.3Web-driven graphing interface for RRDTool
> cadaver-0.23.3_4   Commandline client for DAV
> cairo-1.16.0,2 Vector graphics library with cross-device
> output support
> cairomm-1.12.2_3   C++ interface to cairo
> cdrtools-3.01_1CD/DVD/BluRay and ISO-9660 image creation
> and extraction tools
> clit-1.8   Microsoft Lit to HTML and Open eBooks
> converter
> clone-1.0.7_4  File tree cloning tool
> cmake-3.14.3   Cross-platform Makefile generator
> cmocka-1.1.1_1 Unit testing framework for C with support
> for mock objects
> colord-1.3.5   Manage color profiles to accurately color
> input/output devices
> compat11x-i386-11.2.1102000.20181014 Convenience package to install the
> compat11x libraries
> coreutils-8.31 Free Software Foundation core utilities
> create-cert-2.7Create openssl client key and certificates
> cuetools-1.4.1 Utilities for working with CUE and TOC files
> cups-2.2.11Common UNIX Printing System
> cups-filters-1.22.5Additional backends, filters and other
> software for CUPS
> curl-7.64.1_1  Command line tool and library for
> transferring data with URLs
> cvsps-2.1_2Create patchset information from CVS
> cyrus-sasl-2.1.27  RFC  SASL (Simple Authentication and
> Security Layer)
> daemontools-0.76_18Service monitoring and logging utilities by
> djb
> db5-5.3.28_7   Oracle Berkeley DB, revision 5.3
> dbus-1.12.12   Message bus system for inter-application
> communication
> dbus-glib-0.110GLib bindings for the D-BUS messaging system
> dejavu-2.37_1  Bitstream Vera Fonts clone with a wider
> range of characters
> desktop-file-utils-0.23Couple of command line utilities for
> working with desktop entries
> dialog4ports-0.1.6 Console Interface to configure ports
> djbdns-1.05_22,1   Collection of secure and reliable DNS tools
> docbook-1.5Meta-port for the diffe

Re: Make errors

2019-04-25 Thread Tobias C. Berner
Moin moin

How are you building cmake? And can you send the full output of the build
process?

mfg Tobias

On Fri, 26 Apr 2019 at 02:36, Paul Beard  wrote:

> Pkg shit the bed a couple of days ago and I am trying to rebuild the ports
> I had installed. This kind of thing makes it challenging:
>
> file /usr/ports/devel/cmake/work/cmake-3.14.2/config.log
> /usr/ports/devel/cmake/work/cmake-3.14.2/config.log: cannot open
> `/usr/ports/devel/cmake/work/cmake-3.14.2/config.log' (No such file or
> directory)
>
>
> Installing from a package doesn’t work. Pkg itself keeps reinstalling
> itself over a library change. Best I can make, pkg seems to have reached
> the same level of helpfulness as the old pkgdb system or even rpm.
>
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to k...@freebsd.org [maintainer] and attach the
> "/usr/ports/devel/cmake/work/cmake-3.14.2/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
>
>
> alsa-lib-1.1.2_2   ALSA compatibility library
> apache-ant-1.10.5  Java- and XML-based build tool,
> conceptually similar to make
> apr-1.6.5.1.6.1_1  Apache Portability Library
> asciidoc-8.6.10_1  Text document format for writing short
> documents and man pages
> autoconf-2.69_2Automatically configure source code on many
> Un*x platforms
> autoconf-wrapper-20131203  Wrapper script for GNU autoconf
> autoconf213-2.13.000227_7  Automatically configure source code on many
> Un*x platforms (legacy 2.13)
> automake-1.16.1_1  GNU Standards-compliant Makefile generator
> avahi-app-0.7_2Service discovery on a local network
> bash-5.0.7 GNU Project's Bourne Again SHell
> binutils-2.32,1GNU binary tools
> bison-3.3.2,1  Parser generator from FSF, (mostly)
> compatible with Yacc
> bootstrap-openjdk8-r450802 Java Development Kit 8
> ca_root_nss-3.43   Root certificate bundle from the Mozilla
> Project
> cabextract-1.9.1   Program to extract Microsoft cabinet (.CAB)
> files
> cacti-1.2.3Web-driven graphing interface for RRDTool
> cairo-1.16.0,2 Vector graphics library with cross-device
> output support
> cdrtools-3.01_1CD/DVD/BluRay and ISO-9660 image creation
> and extraction tools
> clit-1.8   Microsoft Lit to HTML and Open eBooks
> converter
> clone-1.0.7_4  File tree cloning tool
> compat11x-i386-11.2.1102000.20181014 Convenience package to install the
> compat11x libraries
> coreutils-8.31 Free Software Foundation core utilities
> create-cert-2.7Create openssl client key and certificates
> cuetools-1.4.1 Utilities for working with CUE and TOC files
> cups-2.2.11Common UNIX Printing System
> curl-7.64.1_1  Command line tool and library for
> transferring data with URLs
> daemontools-0.76_18Service monitoring and logging utilities by
> djb
> db5-5.3.28_7   Oracle Berkeley DB, revision 5.3
> dbus-1.12.12   Message bus system for inter-application
> communication
> dbus-glib-0.110GLib bindings for the D-BUS messaging system
> dejavu-2.37_1  Bitstream Vera Fonts clone with a wider
> range of characters
> dialog4ports-0.1.6 Console Interface to configure ports
> djbdns-1.05_22,1   Collection of secure and reliable DNS tools
> docbook-1.5Meta-port for the different versions of the
> DocBook DTD
> docbook-sgml-4.5_1 DocBook SGML DTD
> docbook-xml-5.0_3  DocBook XML DTD
> docbook-xsl-1.79.1_1,1 XSL DocBook stylesheets
> encodings-1.0.4_4,1X.Org Encoding fonts
> expat-2.2.6_1  XML 1.0 parser written in C
> font-bh-ttf-1.0.3_4X.Org Bigelow & Holmes TTF font
> font-misc-ethiopic-1.0.3_4 X.Org miscellaneous Ethiopic font
> font-misc-meltho-1.0.3_4   X.Org miscellaneous Meltho font
> font-util-1.3.1Create an index of X font files in a
> directory
> fontconfig-2.12.6,1XML-based font configuration API for X
> Windows
> freetype2-2.9.1Free and portable TrueType font rendering
> engine
> fribidi-0.19.7 Free Implementation of the Unicode
> Bidirectional Algorithm
> gcc8-8.3.0_2   GNU Compiler Collection 8
> gdbm-1.18.1_1  GNU database manager
> gettext-runtime-0.19.8.1_2 GNU gettext runtime libraries and programs
> giflib-5.1.4   Tools and library routines for working with
> GIF images
> glib-2.56.3_4,1Some useful routines of C programming
> 

Re: kdepim-runtime failure

2019-04-24 Thread Tobias C. Berner
Hi Dwayne

Sorry, I did not yet have time to check while it's failing -- it worked for
me, so likely a timing issue that can be fixed by disabling make jobs.
I'll try to get to it soon.

mfg Tobias

On Wed, 24 Apr 2019 at 01:22, Dwayne MacKinnon  wrote:

> Hi,
>
> My poudriere build is reporting the following failure, which seems to
> match
> the pkg-fallout notifications:
>
> In file included from
> /wrkdirs/usr/ports/deskutils/kdepim-runtime/work/kdepim-
> runtime-19.04.0/resources/mbox/mboxresource.cpp:35:
> /wrkdirs/usr/ports/deskutils/kdepim-runtime/work/kdepim-runtime-19.04.0/
> resources/mbox/compactpage.h:25:10: fatal error: 'ui_compactpage.h' file
> not
> found
> #include "ui_compactpage.h"
>  ^~
> 1 warning and 1 error generated.
> ninja: build stopped: subcommand failed.
> *** Error code 1
>
> Should I open a bug report, or is the fact that the exp-run is failing
> sufficient?
>
> Cheers,
> DMK
>
>
>


Re: Was kdepim overlooked in the update to 19.04.0?

2019-04-21 Thread Tobias C. Berner
Hi Greg

deskutils/kdepim is a metaport only pulling in dependencies, therefore most
often you don't see any commit to it on upgrades :), it however gets its
version changed to the one set in kde.mk.

> make -VPKGNAME -C deskutils/kdepim
kdepim-19.04.0


mfg Tobias

On Mon, 22 Apr 2019 at 07:41, Greg Rivers 
wrote:

> Looking more closely, it appears that the update to deskutils/kdepim
> has yet to be committed to the svn repo.
>
> 
>
> --
> Greg
>


Re: kdenlive qt errors

2019-04-12 Thread Tobias C. Berner
Moin moin

You have exactly what the error says :) -- You have stuff that linked
against an older/never Qt version than the one you have installed.
Make sure all your packages are up to date, then it should work again.

mfg Tobias

On Fri, 12 Apr 2019 at 20:12, Nathan Koch  wrote:

> Hello,
>
> I have attempted to install kdenlive but am having qt related issues. I
> was wondering if you could advise.
>
>
> "Cannot mix incompatible Qt library (version 0x50c02) with this library
> (version 0x50c01)"
>
>
> Thank you,
>
> Nathan
>
>


Re: Should x11/qimageblitz remain maintained by kde@ ?

2019-04-12 Thread Tobias C. Berner
Hi Yuri


As long as it is not part of say kde-applications (or one of the other
"groups")
I do not mind having it maintained by someone else.

But I'm not sure if that project is really alive still, as its not even on
KDE's github mirror.
Is it needed for something? Otherwise it just seems like adding dead weight.


mfg Tobias

On Fri, 12 Apr 2019 at 20:12, Yuri  wrote:

> Hello kde@,
>
>
> I am going to re-add the recently removed x11/qimageblitz, attaching the
> approximate shar.
>
> Should I keep MAINTAINER=k...@freebsd.org. or should I maintain it myself?
>
>
> qimageblitz is a part of the "kdesupport" collection that isn't packaged
> anywhere, including FreeBSD.
>
>
> See here: https://launchpad.net/kdesupport
>
>
> Regards,
>
> Yuri
>
>
>


Re: FreeBSD Port: devel/qt5-core

2019-03-14 Thread Tobias C. Berner
Moin moin

Why aren't you using the ports? We have that version.

You can check the config flags we pass in the tree to make it compile
there.

Mfg Tobias

ОАО НИИВС Спектр  schrieb am Do., 14. März 2019,
15:05:

> Hello.
>
>
>
> I am trying to compile Qt5 (5.12.1) from GIT 
> (https://wiki.qt.io/Building_Qt_5_from_Git) and from archive 
> «qt-everywhere-src-5.12.1.tar.xz», but no success. Would you be so kind to 
> give some advice about how you compile your port on freshports.org?
>
>
>
> FreeBSD is «FreeBSD FreeBSDBuildServer 11.2-RELEASE-p8 FreeBSD 
> 11.2-RELEASE-p8 #0: Tue Jan  8 21:31:23 UTC 2019 
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386».
>
>
>
> Last error is:
>
>
>
> clang++ -c -pipe -O2 -std=c++1z -fvisibility=hidden 
> -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wdate-time 
> -Winconsistent-missing-override -pthread -fPIC -DQT_DEPRECATED_WARNINGS 
> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_EXCEPTIONS 
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_PLUGIN 
> -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../../../include/QtGui/5.12.1 
> -I../../../../include/QtGui/5.12.1/QtGui -I../../../../include 
> -I../../../../include/QtGui -I../../../../include/QtCore/5.12.1 
> -I../../../../include/QtCore/5.12.1/QtCore -I../../../../include/QtCore 
> -I.moc -I/usr/local/include -I../../../../mkspecs/freebsd-clang -o 
> .obj/main.o main.cpp
>
> /root/qt5/qtbase/bin/moc -DQT_DEPRECATED_WARNINGS 
> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_EXCEPTIONS 
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_PLUGIN 
> -DQT_GUI_LIB -DQT_CORE_LIB --include 
> /root/qt5/qtbase/src/plugins/generic/bsdmouse/.moc/moc_predefs.h 
> -I/root/qt5/qtbase/mkspecs/freebsd-clang 
> -I/root/qt5/qtbase/src/plugins/generic/bsdmouse 
> -I/root/qt5/qtbase/include/QtGui/5.12.1 
> -I/root/qt5/qtbase/include/QtGui/5.12.1/QtGui -I/root/qt5/qtbase/include 
> -I/root/qt5/qtbase/include/QtGui -I/root/qt5/qtbase/include/QtCore/5.12.1 
> -I/root/qt5/qtbase/include/QtCore/5.12.1/QtCore 
> -I/root/qt5/qtbase/include/QtCore -I/usr/include/c++/v1 
> -I/usr/lib/clang/4.0.0/include -I/usr/include qbsdmouse.h -o 
> .moc/moc_qbsdmouse.cpp
>
> clang++ -c -pipe -O2 -std=c++1z -fvisibility=hidden 
> -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wdate-time 
> -Winconsistent-missing-override -pthread -fPIC -DQT_DEPRECATED_WARNINGS 
> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_EXCEPTIONS 
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_PLUGIN 
> -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../../../include/QtGui/5.12.1 
> -I../../../../include/QtGui/5.12.1/QtGui -I../../../../include 
> -I../../../../include/QtGui -I../../../../include/QtCore/5.12.1 
> -I../../../../include/QtCore/5.12.1/QtCore -I../../../../include/QtCore 
> -I.moc -I/usr/local/include -I../../../../mkspecs/freebsd-clang -o 
> .obj/moc_qbsdmouse.o .moc/moc_qbsdmouse.cpp
>
> rm -f libqbsdmouseplugin.so
>
> clang++ -Wl,--no-undefined -pthread -Wl,-rpath,/usr/local/Qt-5.12.1/lib 
> -shared -o libqbsdmouseplugin.so .obj/main.o  .obj/qbsdmouse.o  
> .obj/moc_qbsdmouse.o  -L/root/qt5/qtbase/lib -lQt5Gui -L/usr/local/lib 
> -lQt5Core  -L/usr/local/lib
>
> mv -f libqbsdmouseplugin.so ../../../../plugins/generic/libqbsdmouseplugin.so
>
> cd styles/ && ( test -e Makefile || /root/qt5/qtbase/bin/qmake -o Makefile 
> /root/qt5/qtbase/src/plugins/styles/styles.pro ) && make -f Makefile
>
> cd printsupport/ && ( test -e Makefile || /root/qt5/qtbase/bin/qmake -o 
> Makefile /root/qt5/qtbase/src/plugins/printsupport/printsupport.pro ) && make 
> -f Makefile
>
> cd qmake/ && ( test -e Makefile.qmake-aux || /root/qt5/qtbase/bin/qmake -o 
> Makefile.qmake-aux /root/qt5/qtbase/qmake/qmake-aux.pro ) && make -f 
> Makefile.qmake-aux
>
> make binary
>
> clang++ -c -o qlibraryinfo_final.o   -std=c++11 -ffunction-sections 
> -fdata-sections -g -g   -I/root/qt5/qtbase/qmake 
> -I/root/qt5/qtbase/qmake/library -I/root/qt5/qtbase/qmake/generators  
> -I/root/qt5/qtbase/qmake/generators/unix 
> -I/root/qt5/qtbase/qmake/generators/win32 
> -I/root/qt5/qtbase/qmake/generators/mac  -I../include -I../include/QtCore  
> -I../include/QtCore/5.12.1 -I../include/QtCore/5.12.1/QtCore  
> -I../src/corelib/global  -I/root/qt5/qtbase/mkspecs/freebsd-clang  
> -DQT_VERSION_STR=\"5.12.1\" -DQT_VERSION_MAJOR=5 -DQT_VERSION_MINOR=12 
> -DQT_VERSION_PATCH=1  -DQT_BUILD_QMAKE -DQT_BOOTSTRAPPED -DPROEVALUATOR_FULL  
> -DQT_NO_FOREACH
>
> clang++: error: no input files
>
> *** Error code 1
>
>
>
> Stop.
>
> make[3]: stopped in /root/qt5/qtbase/qmake
>
> *** Error code 1
>
>
>
> Stop.
>
> make[2]: stopped in /root/qt5/qtbase/qmake
>
> *** Error code 1
>
>
>
> Stop.
>
> make[1]: stopped in /root/qt5/qtbase
>
> *** Error code 1
>
>
>
> Stop.
>
> make: stopped in /root/qt5
>
>
>
>
>
>
>
> Best regards,
>
> Alexey
>


Re: Stuff for the whishlist: Please update digikam to version 6.0.0

2019-02-26 Thread Tobias C. Berner
Hi Holger

We have a branch with it in it on github, but I need to clean up the new
options a bit first.
But it should land in the tree in the next week or so.


mfg Tobias

On Wed, 27 Feb 2019 at 06:36, Holger Wagemann 
wrote:

> Dear developers,
>
> as user of plasma5 / kde stuff I also like it to work with digikam for
> organizing and managing my collection of photos.
>
> I don't want to push - but I've to admit, that I'm a little bit nosy of
> a bundle of new features. :-)
>
> Apart from that: Thanks a lot for your work.
>
> Kind regards
>
>Holger
>
>
>


Re: FreeBSD Port: accessibility/qt5-speech

2019-02-24 Thread Tobias C. Berner
This should be fixed by r493747.

mfg Tobias

On Sat, 16 Feb 2019 at 09:17,  wrote:

> Hi!
>
> I am building FreeCAD on FreeBSD-Release 12.0-p3 (amd64) with default
> optins  and I have a problem with QT5-speech. I had audio/flit
> installed.
>
> Reading
> /usr/ports/accessibility/qt5-speech/work/qtspeech-everywhere-src-5.12.1/src/plugins/tts/speechdispatcher/
> speechdispatcher.pro
>
> [/usr/ports/accessibility/qt5-speech/work/.build/src/plugins/tts/speechdispatcher]
>   Reading
> /usr/ports/accessibility/qt5-speech/work/qtspeech-everywhere-src-5.12.1/src/plugins/tts/flite/
> flite.pro
>   [/usr/ports/accessibility/qt5-speech/work/.build/src/plugins/tts/flite]
>   Project ERROR: Unknown module(s) in QT: multimedia *** Error code 3
>
> Stop.
> make: stopped in /usr/ports/accessibility/qt5-speech
>
> --
> by ajtiM
> --
> FreeBSD 12.0-Release
>


Re: desktop@ for maintainance of freedesktop related applications

2019-02-23 Thread Tobias C. Berner
Moin moin


I think it's a good idea. If kwm agrees, poppler, libproxy and Co could go
to desktop@ as well.


mfg Tobias

On Sat, 23 Feb 2019 at 09:10, Baptiste Daroussin  wrote:

> Hello,
>
> I would like to use (and revive) the desktop@ group by making it the
> maintainer
> of some of the comme libs/applications that are composing modern desktops,
> in
> particular freedesktop things, like mime-share-info, xdg-utils etc.
>
> by default we will consider that anyone being in gnome@, kde@, xfce@ will
> be
> part of desktop@, what do you think?
>
> If noone objects, I will start by creating a wiki page stating that and
> then
> start migrating some ports from gnome@ to desktop@ (if Koop agrees :))
>
> Best regards,
> Bapt
>


Re: devel/cmake: change some default CFLAGS from -O3 to -O2

2019-02-21 Thread Tobias C. Berner
So it is something you should take upstream then :-)

With my kde@ hat on I have not been convinced that  there is  any benefit
in doing it.


Mfg Tobias


Alexey Dokuchaev  schrieb am Do., 21. Feb. 2019, 13:42:

> On Thu, Feb 21, 2019 at 01:22:48PM +0100, Tobias C. Berner wrote:
> > Moin moin
> >
> > Why? Is there a reason you would prefer -O2?   [ Don't take this as me
> > saying no to doing it, just curious about the reasons].
>
> Because cd /usr/ports/any/port && make -V CFLAGS -V CXXFLAGS
>
> -O2 -pipe  -fstack-protector -fno-strict-aliasing
> -O2 -pipe -fstack-protector -fno-strict-aliasing
>
> Basically, for the same reason why Fedora did that.  In most environments
> -O2 used as a balanced default.  I'm curious why CMake guys opted-in for
> -O3 in the first place...
>
> ./danfe
>


Re: devel/cmake: change some default CFLAGS from -O3 to -O2

2019-02-21 Thread Tobias C. Berner
Moin moin

Why? Is there a reason you would prefer -O2?   [ Don't take this as me
saying no to doing it, just curious about the reasons].

mfg Tobias

On Thu, 21 Feb 2019 at 13:19, Alexey Dokuchaev  wrote:

> Hi there,
>
> I was building some software on Fedora Linux with CMake and noticed
> that it was using -O2 optimization level while on FreeBSD, the same
> build was performed with -O3 for some reason.
>
> I've downloaded source .rpm for their CMake and found that they had
> to patch several Modules/{Compiler,Platform}/*.cmake files so they
> use -O2 for RELEASE mode.  I'm attaching the patch for convenience.
>
> I'm proposing we do the same in FreeBSD, esp. given that we default
> to -O2 elsewhere.
>
> ./danfe
>


Re: lang/basic256 runtime error

2019-01-27 Thread Tobias C. Berner
Hi Fernando

Did you rebuild qt5* and basic256 after r490472?

mfg Tobias

On Sun, 27 Jan 2019 at 10:03, Fernando Apesteguía 
wrote:

> Hi there!
>
> I was testing some changes to lang/basic256 from PR 235204 and I
> realized the port is broken at run time with this error:
>
> ld-elf.so.1: /usr/local/lib/qt5/libQt5SerialPort.so.5: Undefined
> symbol "_ZN16QIODevicePrivate13putCharHelperEc@Qt_5_PRIVATE_API"
>
> I don't know exactly when or why this ibroke. Is comms/qt5-serialport
> working fine?
>
> tijl@ in copy since it seems he did some fixes (r490472) related to
> Qt_5_PRIVATE_API so he might know what this is about.
>
> Thanks in advance!
>


Re: changing user passwords

2019-01-20 Thread Tobias C. Berner
Moin moin

It looks like we'll need to do some code-writing here to support this. I'll
let you know once I have something to test :)



mfg Tobias

On Fri, 18 Jan 2019 at 12:05, Jeff Boman  wrote:

> Hello,
>
>   When a user tries to change their own password, KDE asks for
> root permission to change the password.  When the same user tries to change
> their password from the freebsd terminal (outside of KDE and Xorg), it does
> not ask for the root permission.  How can a user change their password
> through KDE without needing root permission?
>
>   I am running KDE5 and FreeBSD 12 (both updated today)
>
>
>
>   Thanks,
>
> Jeff
>


Re: Plasma Browser Integration

2019-01-15 Thread Tobias C. Berner
Hi Dwayne

Its in www/plasma5-plasma-browser-integration -- and yes, it is working,
and worth it :)
I mostly like notifications and media player controls [1].

mfg Tobias

[1] https://community.kde.org/Plasma/Browser_Integration

On Tue, 15 Jan 2019 at 22:19, Dwayne MacKinnon  wrote:

> Hey all,
>
> Is this working on FreeBSD? Anyone tried it? Is it worth it?
>
> Cheers,
> DMK
>
>
>


Re: devel/qt5-core upgrade failure

2018-12-24 Thread Tobias C. Berner
--->  Preserving /usr/local/lib/qt5/libQt5Network.so.5 as
/usr/local/lib/compat/pkg/libQt5Network.so.5
cp: symlink: libQt5Network.so.5.12.0: File exists

Maybe check why portupgrade does this and fails with it, maybe the
developers of portupgrade can help you out there.
I don't see that there is anything for kde@ to do here, as this seems to be
an issue with the tool used to upgrade rather
than the ports tree.



mfg Tobias

On Mon, 24 Dec 2018 at 22:32, Paul Beard  wrote:

>
>
> On Dec 24, 2018, at 1:31 PM, Tobias C. Berner  wrote:
>
> I mean how are you "building" the updates :)
>
>
> portupgrade -a
>


Re: devel/qt5-core upgrade failure

2018-12-24 Thread Tobias C. Berner
I mean how are you "building" the updates :)

On Mon, 24 Dec 2018 at 21:01, Paul Beard  wrote:

>
>
> > On Dec 24, 2018, at 10:54 AM, Tobias C. Berner 
> wrote:
> >
> > How are you updating the ports?
>
> ? Through svn, same as for all of them, same as I have done for years.
>
> Seems like this message is trying to tell us something…
>
> > pkg-static: Warning: @exec is deprecated, please use @[pre|post][un]exec
>
>
>


Re: devel/qt5-core upgrade failure

2018-12-24 Thread Tobias C. Berner
Moin moin

How are you updating the ports?


Mfg Tobias


Am Mo., 24. Dez. 2018, 18:42 hat Paul Beard 
geschrieben:

>
>
> On Dec 17, 2018, at 5:15 AM, Adriaan de Groot  wrote:
>
> I suppose that's the error message from whatever tool you were using --
> portupgrade? Since subsequent deinstall from the port *did* work, I'd like
> to
> chalk this up to "something was wrong once”.
>
>
> Subsequent deinstall does work but I don’t see much value in a pkg/ports
> system that requires a manual step for a subset of ports. Happens with
> every qt-* port.
>
>
> > Compressing man pages (compress-man)
> ===>   Installing ldconfig configuration file
> --->  Build of net/qt5-network ended at: Mon, 24 Dec 2018 09:28:38 -0800
> (consumed 00:11:11)
> --->  Updating dependency info
> --->  Uninstallation of qt5-network-5.12.0 started at: Mon, 24 Dec 2018
> 09:28:38 -0800
> --->  Fixing up dependencies before creating a package
> --->  Backing up the old version
> --->  Uninstalling the old version
> [Reading data from pkg(8) ... - 550 packages found - done]
> --->  Deinstalling 'qt5-network-5.12.0'
> --->  Preserving /usr/local/lib/qt5/libQt5Network.so.5 as
> /usr/local/lib/compat/pkg/libQt5Network.so.5
> cp: symlink: libQt5Network.so.5.12.0: File exists
> Copy failed!
> [Reading data from pkg(8) ... - 550 packages found - done]
> ** Listing the failed packages (-:ignored / *:skipped / !:failed)
> ! qt5-network-5.12.0(copy failed)
> --->  Uninstallation of qt5-network-5.12.0 ended at: Mon, 24 Dec 2018
> 09:28:41 -0800 (consumed 00:00:02)
> --->  Upgrade of net/qt5-network ended at: Mon, 24 Dec 2018 09:28:41 -0800
> (consumed 00:11:14)
> --->  ** Upgrade tasks 1: 0 done, 0 ignored, 0 skipped and 1 failed
> --->  Listing the results (+:done / -:ignored / *:skipped / !:failed)
> ! net/qt5-network (qt5-network-5.12.0)  (uninstall error)
>
>
> /usr/ports/net/qt5-network]# make deinstall reinstall
> ===>  Deinstalling for qt5-network
> ===>   Deinstalling qt5-network-5.12.0
> Updating database digests format: 100%
> Checking integrity... done (0 conflicting)
> Deinstallation has been requested for the following 1 packages (of 0
> packages in the universe):
>
> Installed packages to be REMOVED:
> qt5-network-5.12.0
>
> Number of packages to be removed: 1
>
> The operation will free 2 MiB.
> [1/1] Deinstalling qt5-network-5.12.0...
> [1/1] Deleting files for qt5-network-5.12.0: 100%
> ===>  Installing for qt5-network-5.12.0_1
> ===>   Registering installation for qt5-network-5.12.0_1
> pkg-static: Warning: @exec is deprecated, please use @[pre|post][un]exec
> Installing qt5-network-5.12.0_1...
>


Re: KMail problem

2018-12-16 Thread Tobias C. Berner
Hi Dwayne

There was a similar report in #kde-devel in IRC recently. There is probably
an open PR upstream for this.


You can add somethin like this for Qt5


# Build Qt with debug flags
.if ${.CURDIR:M*/qt5-*} && ! ${.CURDIR:M*www/qt5-webkit*} && !
${.CURDIR:M*www/qt5-webengine*}
WITH_DEBUG= yes
.endif
And analogously for KF5. You neee to exclude the two www as your machine
wont survive the build otherwise =)

There are also environment variables you can set to make akonadi more
verbose.

Mfg Tobias


Am Mo., 17. Dez. 2018, 05:02 hat Dwayne MacKinnon  geschrieben:

> Hi all,
>
> This weekend I upgraded to FreeBSD 12.0-RELEASE, wiped out all my ports,
> upgraded my poudriere jail and then rebuilt everything. Most things are ok.
> However, I have a major problem with KMail 5.10.0 now. Every time I try to
> open one of my imap emails it segfaults and dies.
>
> Unfortunately Dr. Konqui had no useful information.
>
> Anyone else see this? And can someone tweak my memory as to how to build
> with useful crash dumps? is it WITH_DEBUG=YES in make.conf or something
> like that?
>
> Thanks,
> DMK
>


Re: FreeBSD Port: marble-18.08.3_2

2018-12-14 Thread Tobias C. Berner
Hi Alex

Thanks for the report, this should be fixed with r487420.


mfg Tobias

On Fri, 14 Dec 2018 at 08:49, Alex V. Petrov  wrote:

> ===>  Installing for marble-18.12.0
> ===>  Checking if marble already installed
> ===>   Registering installation for marble-18.12.0 as automatic
> pkg-static: Unable to access file
>
> /usr/ports/astro/marble/work/stage/usr/local/include/marble/NullMarbleWebView.h:No
> such file or directory
>
> pkg-static: Unable to access file
>
> /usr/ports/astro/marble/work/stage/usr/local/include/marble/NullTinyWebBrowser.h:No
> such file or directory
>
> *** Error code 74
>
> Stop.
> make[1]: stopped in /usr/ports/astro/marble
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/astro/marble
>
> --
> -
> Alex.
>


Re: cmake-3.13.1 build error

2018-12-14 Thread Tobias C. Berner
Moin moin

Cmake is trying to use clang6 not gcc8 as you said.
There is probalby an error in your config that should switch it to gcc. How
do you do it?


Mfg Tobias

Am Fr., 14. Dez. 2018, 10:23 hat David Gessel 
geschrieben:

>
> I got on FreeBSD 11.2-RELEASE-p6 #0 r341740
>
> gcc8-8.2.0_4
>
>
> loading initial cache file
> /var/ports/usr/ports/devel/cmake/work/cmake-3.13.1/Bootstrap.cmk/InitialCacheFlags.cmake
> -- The C compiler identification is Clang 6.0.0
> -- The CXX compiler identification is Clang 6.0.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Checking if compiler supports needed C++17 constructs
> -- Checking if compiler supports needed C++17 constructs - yes
> -- Checking if compiler supports C++ make_unique
> -- Checking if compiler supports C++ make_unique - no
> -- Checking if compiler supports C++ unique_ptr
> -- Checking if compiler supports C++ unique_ptr - no
> CMake Error at CMakeLists.txt:92 (message):
>   The C++ compiler does not support C++11 (e.g.  std::unique_ptr).
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/var/ports/usr/ports/devel/cmake/work/cmake-3.13.1/CMakeFiles/CMakeOutput.log".
> See also
> "/var/ports/usr/ports/devel/cmake/work/cmake-3.13.1/CMakeFiles/CMakeError.log".
> -
> 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
> "/var/ports/usr/ports/devel/cmake/work/cmake-3.13.1/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
>
>
>
> ImageMagick-nox11-6.9.9.28_2,1 Image processing tools (legacy version)
> acme-client-0.1.16_4   Native C client for Let's Encrypt, designed
> for security
> apache24-2.4.37Version 2.4.x of Apache web server
> apr-1.6.5.1.6.1_1  Apache Portability Library
> autoconf-2.69_2Automatically configure source code on many
> Un*x platforms
> autoconf-wrapper-20131203  Wrapper script for GNU autoconf
> automake-1.16.1_1  GNU Standards-compliant Makefile generator
> bind-tools-9.12.3_1Command line tools from BIND: delv, dig,
> host, nslookup...
> binutils-2.30_6,1  GNU binary tools
> bison-3.2.2,1  Parser generator from FSF, (mostly)
> compatible with Yacc
> brotli-1.0.7_1,1   Generic-purpose lossless compression
> algorithm
> ca_root_nss-3.41   Root certificate bundle from the Mozilla
> Project
> cclient-2007f_3,1  C-client mail access routines by Mark
> Crispin
> cmake-3.13.1   Cross-platform Makefile generator
> curl-7.62.0Command line tool and library for
> transferring data with URLs
> db5-5.3.28_7   Oracle Berkeley DB, revision 5.3
> dialog4ports-0.1.6 Console Interface to configure ports
> distcache-1.5.1Distributed OpenSSL session caching tools
> docbook-1.5Meta-port for the different versions of the
> DocBook DTD
> docbook-sgml-4.5_1 DocBook SGML DTD
> docbook-xml-5.0_3  DocBook XML DTD
> docbook-xsl-1.79.1_1,1 XSL DocBook stylesheets
> expat-2.2.6_1  XML 1.0 parser written in C
> ezjail-3.4.2_1 Framework to easily create, manipulate, and
> run FreeBSD jails
> fftw3-3.3.8_3  Fast C routines to compute the Discrete
> Fourier Transform
> fontconfig-2.12.6,1XML-based font configuration API for X
> Windows
> freetype2-2.9.1Free and portable TrueType font rendering
> engine
> gamin-0.1.10_9 File and directory monitoring system
> gcc-ecj-4.5Eclipse Java Compiler used to build GCC Java
> gcc8-8.2.0_4   GNU Compiler Collection 8
> gdbm-1.18.1GNU database manager
> gettext-runtime-0.19.8.1_2 GNU gettext runtime libraries and programs
> gettext-tools-0.19.8.1_1   GNU gettext development and translation
> tools
> ghostscript9-agpl-base-9.25_1  PostScript and PDF interpreter
> giflib-5.1.4   Tools and library routines for working with
> GIF images
> glib-2.56.3_2,1Some useful routine

  1   2   3   >