Re: misc/compat11x pkg-descr correction

[Adriaan de Groot]

On Tuesday, 27 April 2021 11:23:51 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> From: Simon Wright 
> To: freebsd-ports@freebsd.org
> Subject: Bug 242248 - misc/compat11x pkg-descr correction [PATCH],
> committer love pls!
> Message-ID: <6c276940-b0e4-28f6-8bb3-c373b3642...@gmx.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi all,
> 
> Would any committer with a few spare cycles please look at the
> correction to the pkg-descr in compat11x? It's a very minor issue but so
> quick to fix :).
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242248

The pkg-descr was fixed a year ago, but the PR wasn't closed; the PORTREVISION 
at the time wasn't bumped like in the patch you provided. I'm not going to 
bump it now, though, and have closed the PR.

[ade]


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

Re: freebsd-ports Digest, Vol 933, Issue 7

[Adriaan de Groot]

On Sunday, 18 April 2021 14:00:01 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> >> So perhaps that is the best way to avoid having to deal with ABI/API
> >> breakage...
> >> After that it is up to the maintainers of the dependant packages to
> >> update their package and start using boost-1.75.
> > 
> > There is the implicit assumption that a patch that updates
> > boost for all the dependent ports should also provide fixes
> > if those ports fail to build after the update. That is
> > the major task.
> 
> There are "only" 490 ports that have boost in their Makefile.

Compare this to CMake, which has about 1900 direct consumers. While there's 
less ABI-breakage and more configure- and build-time breakage, a CMake update 
looks like this:
- build all the consumers with the current version of CMake
- fix the ones that don't build, or mark BROKEN
- bump CMake locally
- build everything again
- fix the ones that don't build

The actual CMake parts are the easy bits. Dealing with 15-year old C++ code 
that happens to use CMake and falls over for totally unrelated reasons is the 
real time sink. Ceph, too, is one of those things that eventually gets added 
to my ignore list as "doesn't build in any recent ports checkout":

/usr/local/bin/ld: ../../../lib/libkv.a(LevelDBStore.cc.o):
(.data.rel.ro._ZTI17CephLevelDBLogger[_ZTI17CephLevelDBLogger]+0x10): 
undefined reference to `typeinfo for leveldb::Logger'

I fix what I can, send mail to maintainers when I can't and so we hope that 
progress happens.

[ade]

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

fs_violations for ports that build using python tools

[Adriaan de Groot]

I build many ports in poudriere with the `-t` (test port) flag. Ports that use 
Python-based tools tend to fail with a fs_violation. For instance, FreeCAD:

=>> Checking for filesystem violations... done
=>> Error: Filesystem touched during build:
extra: usr/local/lib/python3.7/site-packages/shiboken2/__pycache__
extra: usr/local/lib/python3.7/site-packages/shiboken2/files.dir/
shibokensupport/__pycache__
extra: usr/local/lib/python3.7/site-packages/shiboken2/files.dir/
shibokensupport/signature/lib/__pycache__

or nextpnr:

=>> Checking for filesystem violations... done
=>> Error: Filesystem touched during build:
extra: usr/local/share/trellis/util/common/__pycache__
extra: usr/local/share/trellis/timing/util/__pycache__

On the build cluster, these don't seem to cause problems. Note that these 
pycache files are **not** from the port being built, but from other, python-
based, tools that are run as part of the build: trellis is a BUILD_DEPENDS for 
nextpnr.

What can I do to resolve this kind of build failure? I'd like to avoid false-
failures because they mask and confuse local exp-runs for (say) CMake updates.

[ade]

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

@sample surprises (dns/knot-resolver)

[Adriaan de Groot]

As prep-work for CMake updates I locally "exp-run" all the ports that use 
CMake. I use poudriere for this, with the `-t` flag to test each port.

dns/knot-resolver fails to package like that, with this error:

===
===>  Building package for knot-resolver-5.3.0
@sample with 1 single argument expect ".sample" extension
pkg-static: Fail to apply keyword 'sample'
*** Error code 1


The same failure occurs on the build cluster. I checked the porter's handbook 
and it describes 1- and 2-argument forms of @sample, but neither seemed 
applicable here without digging into the port itself to rename the installed 
configuration file. What's the right approach here?

(CC'ed maintainer and last committer; I'm going to locally stop building this 
one in preparation of a CMake update)

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

Re: freebsd-ports Digest, Vol 930, Issue 4

[Adriaan de Groot]

On Thursday, 25 March 2021 13:00:02 CET freebsd-ports-requ...@freebsd.org 
wrote:
> The idea is to try to have www/qt5-webengine fixed before the expiration
> time, saving with it a bunch of innocent ports depending on it, correct?

In the sense of "have one guy take a stab at it over the weekend because 
multi-billion-dollar companies can't be arsed", yes. I'm not sure what the 
situation over in Linux-land is.

[ade]

PS1. I'm going to primarily blame Google; the Qt Company, though, is far from 
blameless in its maintainence of WebEngine (or lack thereof). I have hope for 
TurtleBrowser, but they are also kind of waiting on me for a breakthrough on 
the Python3 front.

PS2. Works-in-progress are the branches *webengine-python3* (old, but does 
complete an entire build that then doesn't actually **work**) and *webengine-
logpy27* (new, currently more hacky, doesn't build) in the https://github.com/
freebsd/freebsd-ports-kde.git ports repo.

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

Re: FreeBSD Port: kf5-kparts-5.80.0 error update

[Adriaan de Groot]

On Saturday, 20 March 2021 04:42:32 CET Alex V. Petrov wrote:

> ===>>> Update for kf5-kparts-5.79.0 failed
> ===>>> Aborting update

Looks like you're trying to install in a dirty (previous version is installed) 
system. Please don't do that. 

The log isn't all that useful: it looks like the build is repeatedly 
regenerating itself, which might be https://bugs.freebsd.org/bugzilla/
show_bug.cgi?id=239512 , but for that we'd need to know why the build is re-
generating.

[ade]

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

Re: Broken Ports Tree Neochat/kquickimageeditor r560251

[Adriaan de Groot]

On Monday, 4 January 2021 04:22:32 CET Li-Wen Hsu wrote:
> On Mon, Jan 4, 2021 at 9:42 AM Nick Wolff  wrote:
> > Hello  Adriaan ,
> > 
> > https://svnweb.freebsd.org/ports?view=revision=560251 Seems to
> > cause poudriere to puke due to a missing line in graphics/Makefile for new
> > port dependency you added.
> 
> I've committed this in r560258. Thanks for the patch!

Thank you Li-Wen for cleaning up after me. I can guess how this passed my 
local builds, but not elsewhere: I built the kquickimageeditor port (and 
package) with poudriere explicitly, first .. so it was already lying around 
for use when I then tried to build neochat; I never needed the INDEX.

/me adds a "srsly, don't add a new port as part of an update to another" to 
his checklist

[ade]

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

Re: Error: MOVED: net/kblog EXPIRED 2020-08-13 No longer shipped

[Adriaan de Groot]

On Sunday, 16 August 2020 14:00:01 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> Message: 10
> Date: Sun, 16 Aug 2020 13:53:21 +0200
> From: Christoph Moench-Tegeder 
> 
> ## Carmel (carmel...@outlook.com):
> > I would have expected to see something in"UPDATING". The only mention
> > is in "MOVED": net/kblog||2020-08-13|No longer shipped
> 
> Simple port deletions are rarely in UPDATING.
> On the other hand, and as I'm not familiar with KDE and it's ports
> layout: wouldn't it make sense to have only the toplevel port (there
> is x11/kde5) in your ports-list and have poudriere figure out all
> the dependencies on it's own?

If you want "all the stuff from the KDE community" then x11/kde5 is a good 
thing to install (although that doesn't install **all** ofall of it). But you 
could run any one of a number of applications from the KDE community 
individually. Like krita, if you're a painter, or kdenlive if you want to do 
video editing or .. 

> 
> > Obviously, poudriere cannot handle this situation on its own. To bad.
> 
> You did request a port to be built which does not exist (anymore) -
> I'm not sure what you did expect. Silently ignoring the problem and
> leaving you with the outdated package (perhaps even in your repo?)
> seems worse.

As far as net/kblog goes, it was removed upstream, see the not-very-
informative upstream issue at

https://phabricator.kde.org/T12157


The (Wordpress?) blogging client from KDE is unmaintained, so the supporting 
stack for that application goes away upstream eventually as well.

[ade]

PS. Thanks for reminding .. I saw that blogilo was still mentioned in the 
kdepim pkg-descr, which I've now removed.

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

libusb & API versions

[Adriaan de Groot]

I'm wondering about libusb, because the libusb in base is missing a bunch of 
"current" API, and the API version number doesn't match Linux (upstream?) idea 
of what was available in historical versions.

tl;dr: would a libusb port make any sense? Is updating libusb in base 
feasible?

Background:
 - KDE Plasma currently displays nothing useful in the System Information 
panel about USB devices. This is because it reads data from files in /sys .. 
and doesn't expect to find the source code of the operating system there.
 - Switching to libusb is an obvious improvement: libusb supports a dozen 
OS'es, with backends for NetBSD, OpenBSD, Solaris .. and not FreeBSD, for 
whatever reason, but we have our own libusb in base anyway.
 - *Current* upstream libusb has at least these two things that original 
version 1.0 libusb from 2010 or so didn't have:
   - libusb_device *libusb_get_parent(libusb_device *)
   - LIBUSB_SPEED_SUPER_PLUS
 - Our libusb.h defines an API version #define LIBUSB_API_VERSION 0x01000102
 - libusb upstream introduced libusb_get_parent in v1.0.12
 - libusb upstream introduced LIBUSBX_API_VERSION in v1.0.13, as 0x01000100
 - much later LIBUSBX_API_VERSION was renamed LIBUSB_API_VERSION

But it comes down to this: the API_VERSIONs don't match up with the available 
functionality; libusb 2.0 was though-about in 2012 or so, but never gained any 
traction. Our libusb has things for the apparently abandoned 2.0 API, but 
nothing for the continued evolution of the 1.0 API.

Any recommendations? I'd like to avoid patches upstream, but if things need to 
be rewritten to match our libusb, so be it.

[ade]

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

Chromium (& derivatives) and Python 2.7

[Adriaan de Groot]

The Chromium build system -- and as a consequence, also QtWebEngine -- still 
uses Python 2.7. This is going to be a real problem about six months down the 
line, and I have no idea how upstream is going to deal with it. I've heard 
there are patches buried deep within the chocolate factory, but not from 
reliable sources.

QtWebEngine is an even specialer case, since it's an LTS and also the last LTS 
in the Qt5 series, and I have real doubts about upstream -- The Qt Company -- 
being able or willing to deal with Python 2.7 deprecation there.

Has anyone in FreeBSD tried to port the stuff over? I got about an hour or two 
into the porting process (making configure accept Python 3 is easy, but 
there's all these wretched code-generating scripts) and hit a brick wall of 
templating engines doing sensible Python 2.7 things.

[ade]

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

Re: audoi/openal-soft fails (Andy Farkas)

[Adriaan de Groot]

On Thursday, 2 July 2020 14:00:01 CEST freebsd-ports-requ...@freebsd.org 
wrote:
>1. audoi/openal-soft fails (Andy Farkas)
> 
> 
> # portmaster audio/openal-soft
> 

What you're showing here are a couple of *warnings* from CMake (known issues, 
not harmful: recent CMake is more picky about naming conventions, in an effort 
to make things more predictable to consumers of find-modules).

>  ? The package name passed to `find_package_handle_standard_args` (OPENSL)
>  ? does not match the name of the calling package (OpenSL).? This can
> lead to
>  ? The package name passed to `find_package_handle_standard_args` (MYSOFA)
>  ? does not match the name of the calling package (MySOFA).? This can
> lead to

^^ These are just warnings due to variations in capitalization. They are not 
the problem.


> -- Configuring incomplete, errors occurred!
> See also
> "/usr/ports/audio/openal-soft/work/.build/CMakeFiles/CMakeOutput.log".
> See also
> "/usr/ports/audio/openal-soft/work/.build/CMakeFiles/CMakeError.log".
> *** Error code 1

The actual error is elsewhere. Remember that CMake, like C or C++ compilers, 
can carry on and on and on after an actual error, spitting out warnings and 
stuff-that-sort-of-makes-sense. You'll need to go back in the logs.

FWIW, in poudriere and with default options, this builds ok.

[ade]

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

Re: kf5 issues (The Doctor)

[Adriaan de Groot]

On Wednesday, 13 May 2020 14:00:02 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> Just found the tip pf the iceberg.

Gentoo kindly pointed me to a good explanation:

https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-qt/qtcore/files/
qtcore-5.14.1-cmake-macro-backward-compat.patch

That's a patch we'll be adding to QtCore soon; your workaround right now is 
"remove Qt, build and install Qt, then build and install other things" or 
follow the supported-and-encouraged-by-kde@ path "build with poudriere".

[ade]

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

Re: kde5/qt5 problem

[Adriaan de Groot]

On Thursday, 16 April 2020 00:05:02 CEST The Doctor wrote:
> On Wed, Apr 15, 2020 at 09:20:17PM +0200, Adriaan de Groot wrote:
> > Qt ports are annoying like that; it's an incompatibility between pre-5.14
> > and (current) 5.14 where it picks up the wrong CMake support bits.
> > Uninstall Qt < 5.14, then build Qt 5.14. Or use poudriere, which builds
> > in a clean environment.
> 
> All right, just that I use portmaster.  How can I use poudriere for this?

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html

That's from the perspective of someone working on the ports themselves, not so 
much for the consumer of ports, but it'll do to get you started.

[ade]

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

re: kde5/qt5 problem

[Adriaan de Groot]

Qt ports are annoying like that; it's an incompatibility between pre-5.14 and 
(current) 5.14 where it picks up the wrong CMake support bits. Uninstall Qt < 
5.14, then build Qt 5.14. Or use poudriere, which builds in a clean 
environment.

[ade]

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

Re: freebsd-ports Digest, Vol 879, Issue 7

[Adriaan de Groot]

On Saturday, 4 April 2020 14:00:14 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> Message: 8
> Date: Fri, 3 Apr 2020 21:58:29 +0200 (CEST)
> From: Wojciech Puchar 
> Subject: Re: qrc:/Desktop.qml:26 module "QtQuick.Dialogs" is not
> installed

If this is about net-im/ruqola, then kde@ (in CC) is the maintainer and the 
right group to approach about this. If quickcontrols are needed then that's a 
bug in the port (which kde@ people generally won't notice, because testing the 
application in a Plasma environment will work -- the missing runtime 
dependency is not-missing for us).

> well. partially. ruquola starts and shows menu for log in
> but doesn't log in

Looks like another runtime service -- you *do* have DBus running in your 
environment? 

[ade]

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

Re: freebsd-ports Digest, Vol 879, Issue 6

[Adriaan de Groot]

On Friday, 3 April 2020 14:00:11 CEST freebsd-ports-requ...@freebsd.org wrote:
> Message: 1
> Date: Fri, 3 Apr 2020 08:44:14 +0200 (CEST)
> From: Wojciech Puchar 
> To: freebsd-ports@freebsd.org
> Subject: qrc:/Desktop.qml:26 module "QtQuick.Dialogs" is not installed
> Message-ID: 
> Content-Type: text/plain; format=flowed; charset=US-ASCII
> 
> what package am i missing?

You'll want x11-toolkits/qt5-quickcontrols

[ade]


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

Re: freebsd-ports Digest, Vol 874, Issue 1

[Adriaan de Groot]

On 2020 febula d. 24id 13:00:05 CET freebsd-ports-requ...@freebsd.org wrote:
> Date: Mon, 24 Feb 2020 12:48:11 +0100
> From: Miroslav Lachman <000.f...@quip.cz>
> To: freebsd-ports@freebsd.org
> Subject: Cannot build qt5-webkit with debug
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Short story:
> I am trying to build qt5-webkit with WITH_DEBUG=yes in make.conf on our
> E3 Xeon machine with FreeBSD 11.3, poudriere-devel, 16GB of RAM and 10GB
> of swap.

That's very optimistic of you. Both WebKit and -- worse -- WebEngine are 
*huge*. I wouldn't even bother starting on this with only 32GB of RAM. Note 
also that the resulting debug files may be larger than 4GB, and that breaks 
down on some filesystems. 

I thought there was a PR about this, too, but I can't find it all that 
quickly.

Note, too, that WebKit is considered obsolete, and it's not receiving much 
(any?) attention.

[ade] (sorry, no positive-useful contributions today)

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

Re: "devel/kio-extras" with samba v4-10

[Adriaan de Groot]

On Thursday, December 5, 2019 5:22:39 PM CET Carmel NY wrote:
> I have Samba Version 4.10.10 installed. When attempting to build
> devel/kio-extras with the:
> 
>  SAMBA=on: Needed to build the SMB kioslave
> 
> which is the default setting in the port, the build fails with the
> message that the wrong version of 'samba' is installed.

It would really help if you included the actual error message from such a 
build. (Also, fails during configure, or some other time?)



> What I want to know is why the "devel/kio-extras" port is still
> dependent on samba -= v4.8 if it is EOL'd? If the port cannot be made to
> work with a modern version of samba; then the option should either be
> removed or turned off as the default in the makefile, preferable with a
> notation of why.

I can't reproduce the problem, though: in a poudriere, after building and 
installing samba410, I built and installed kio-extras:

root@uild:/usr/ports/devel/kio-extras # pkg info | egrep 'samba|kio'
kf5-kio-5.64.0 KF5 resource and network access abstraction
kio-extras-19.08.3 Plasma5 library to increase the functionality 
of KIO
samba410-4.10.10   Free SMB/CIFS and AD/DC server and client for 
Unix

I have no idea how to tell if it *works*, but it certainly compiles (for me).

[ade]

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

Re:Falkon ( freebsd-ports Digest, Vol 855, Issue 2)

[Adriaan de Groot]

Responding specifically to falkon, not to pkg-meta-issue.

On Tuesday, 15 October 2019 14:00:02 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> Today I wanted to reinstall falkon (due to some library updates,
> related to other packages on my system).
> 
> root@kg-core2# pkg install -f falkon
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> pkg: No packages available to install matching 'falkon' have been
> found in the repositories

That looks like a hiccup (in the package-building, I guess), since it's there 
now

root@beastie:~ # pkg search -f falkon 
falkon-3.1.0
Name   : falkon
Version: 3.1.0
Origin : www/falkon
Architecture   : FreeBSD:12:amd64
Prefix : /usr/local
Repository : FreeBSD [pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest]

(granted, you're on 11 and I'm on 12). We (kde@) didn't see any fallout about 
falkon, either. 

[ade]

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

Re: Can't update qt5-gui on 11.2-RELEASE-p13

[Adriaan de Groot]

On Thursday, 10 October 2019 14:05:56 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> > I've run into the same error just yesterday. As a workaround, deinstall
> > the devel/evdev-proto port (it's not the libmtdev port which is the
> > problem) and it will use the base-system evdev includes.
> > 
> > Bye,
> > Alexander.
> 
> Problem solved!  Thanks for your help.  -- George

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

Basically, Qt is using internal headers that it shouldn't .. but that means we 
need to make Qt depend on evdev-proto. There is a fix in the works.

[ade]

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

Re: freebsd-ports Digest, Vol 846, Issue 7

[Adriaan de Groot]

On Sunday, 18 August 2019 14:00:01 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> > So I hoped to collect experiences on this.
> 
> I was favorably impressed by Otter Browser, but have not been able to update
> because my FreeBSD installation, 11.1-STABLE, is too far behind for
> updating ports.

You "otter" be able to build current Qt 5.12.2 and all the bits underneath 
otter, although that's not something that the kde@ team does or supports.

Otter itself is in active development, which is nice. Its main HTML / JS / 
all-the-modern-crap engine can be either Qt WebKit or Qt WebEngine (Chromium). 
The latter is clearly more capable, ever since the official WebKit cooperation 
collapsed, and there's now just a handful of WebKit volunteers in the open-
source world.

www/falkon, www/otter-browser and www/quitebrowser all use (or can use) 
WebEngine; I use falkon most of every day. The differences in the browsers are 
largely in the "chrome" around the central web-viewing widget.

And of course there's www/chromium itself, if you want to get Borged.

[ade]

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

Re: textproc/qt5-xmlpatterns compilation error

[Adriaan de Groot]

On Sunday, 30 June 2019 22:19:33 CEST Andy Farkas wrote:
> On 29/06/2019 05:29, Adriaan de Groot wrote:
> > On Friday, 28 June 2019 14:00:01 CEST freebsd-ports-requ...@freebsd.org 
wrote:
> >> [FreeBSD 11.3-PRERELEASE #1 r349440 amd64 / ports at r505184]
> >> 
> >> Getting a compilation error when build ports/textproc/qt5-xmlpatterns
> > That suggests that you still have older Qt bits installed, while building
> > newer Qt bits. You will want to follow the common instructions we (kde@)
> > give if you're not building with poudriere: remove the Qt5 packages and
> > build them all afresh.
> 
> erm, didn't go so well:
> 


 
> separate_debug_info' QT_CONFIG+=release 'QT_CONFIG-=debug
> separate_debug_info' ) && /usr/bin/make -f Makefile all
> make[3]: make[3]: don't know how to make /usr/local/lib/qt5/bin/rcc. Stop

Couldn't reproduce in a poudriere jail. What you are hitting here is missing 
tools, but:

/usr/local/lib/qt5/bin/rcc was installed by package qt5-buildtools-5.12.2

and the Makefile I have for textproc/qt5-xmlpatterns says

USE_QT= core network buildtools_build

so the ports framework *should* have built and installed devel/qt5-buildtools 
for you. At this point I don't have much useful to suggest anymore, except 
maybe "install qt5-buildtools, then try qt5-xmlpatterns again". Are you sure 
your ports checkout is healthy?

[ade]

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

Re: freebsd-ports Digest, Vol 839, Issue 5

[Adriaan de Groot]

On Friday, 28 June 2019 14:00:01 CEST freebsd-ports-requ...@freebsd.org wrote:
> [FreeBSD 11.3-PRERELEASE #1 r349440 amd64 / ports at r505184]
> 
> Getting a compilation error when build ports/textproc/qt5-xmlpatterns
> 
> I'm doing a 'portmaster -a' but a
> 'cd /usr/ports/textproc/qt5-xmlpatterns ; make clean all' does the same.
> 
> Any clues as to why this might be happening?  or better still how to fix?

I see this in your compile line:

/usr/local/include/qt5/QtQml/5.9.4 

That suggests that you still have older Qt bits installed, while building 
newer Qt bits. You will want to follow the common instructions we (kde@) give 
if you're not building with poudriere: remove the Qt5 packages and build them 
all afresh.

[ade]

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

Re: freebsd-ports Digest, Vol 836, Issue 1

[Adriaan de Groot]

On Monday, 3 June 2019 14:00:01 CEST freebsd-ports-requ...@freebsd.org wrote:
> From: Gary Aitken 
> 
> I'm trying to port some linux code which uses cmake, and clearly don't
> know what I'm doing.
> 
> I have
>USES=  cmake
> set, but a
>make build
> terminates with:
>cd: /usr/ports/cad/prusa-slicer/work/.build: No such file or directory
> 
> What am I missing?  I presume the .build directory should be automatically
> created by the build process.

Are you sure that the configure step is completing succesfully? You'd have to 
take a look in WRKDIR (e.g. try WRKDIR=/tmp/bare make configure ) to see what 
it's created exactly and where -- if anywhere -- the build-dir has ended up.

I know I've run into this same problem with cmake-based ports, but I don't 
remember what I did to resolve it. Feel free to pop into #kde-freebsd on 
Freenode IRC to bounce ideas off the FreeBSD devel/cmake maintainers.

[ade]


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

Re: 32-bit powerpc using g++8 via poudriere for net/qt5-network:

[Adriaan de Groot]

On Monday, 11 March 2019 13:01:43 CET freebsd-ports-requ...@freebsd.org wrote:
> ../qbearerengine_impl.h:48:1: error: expected class-name before '{' token

I *imagine* (since I don't have anything that can try to reproduce this build 
sensibly) that you're hitting a case where QT_NO_BEARERMANAGEMENT is defined, 
which suppresses the bearer classes, but other logic is still trying to 
compile tests of something that make use of it.

This is something that's going to need .. well, preferably Pjotr Kubaj who has 
access to suitable machines .. someone to chase the build and figure out what 
is #defined exactly and which (qmake) configurations are in use.

[ade]

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

FreeCAD 0.17

[Adriaan de Groot]

On Saturday, February 9, 2019 1:00:02 PM CET freebsd-ports-requ...@freebsd.org 
wrote:
> From: Torfinn Ingolfsen 
> To: FreeBSD Ports ML 
> Subject: FreeCAD 0.17 - is anyone using it?
> Message-ID:
> 
> Content-Type: text/plain; charset="UTF-8"
> 
> Just checking: is anyone using FreeCAD 0.17 (cad/freecad) under FreeBSD at
> all? I installed it from ports, I'm running
> tingo@kg-core1$ uname -a
> FreeBSD kg-core1.kg4.no 11.2-STABLE FreeBSD 11.2-STABLE #0 r342545:
> Thu Dec 27 00:29:46 CET 2018
> r...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> but the windows in FreeCAD have graphics corruption all over them,
> making it very hard to use.
> See picture in this message at the FreeBSD forums:
> https://forums.freebsd.org/threads/freecad-0-17-graphics-corruption.69429/

Not using it, and just now I couldn't build it (bash failed, which seems 
nonsensible, in poudriere).

The port really needs an update to switch to Qt5 (otherwise it's going to get 
dropped soon). Who knows, maybe just switching BUILD_QT5 to ON (and changing 
USES, etc.) will fix it.

[ade]

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

mea + llvm60 (and devel/qt5-qdoc)

[Adriaan de Groot]

On Friday, 18 January 2019 13:01:37 CET freebsd-ports-requ...@freebsd.org 
wrote:
> Since mesa uses llvm libraries (not just toolchain to build) this can
> not be made in to a build time only dependency.
> 
> There is some more information on this issue here:
> https://wiki.freebsd.org/WhyDoIHaveToBuildLLVMWhenIAlreadyHaveClangInstalled
> 
> There is work in progress to move to llvm70, however, this only means
> that you need llvm70 installed alongside mesa-dri, instead of llvm60.

This is, right now, what is holding me back from changing llvm60 to llvm$
{LLVM_DEFAULT} in devel/qt5-qdoc -- for a *typical* setup building or using 
Qt-related things, you're going to have mesa-dri installed as well. I don't 
feel happy about pulling in llvm60 (for mesa) *and* llvm70 (for qdoc) just 
because the latter needs a C++ parser.

[ade]


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

Re: freebsd-ports Digest, Vol 816, Issue 2

[Adriaan de Groot]

On Tuesday, 15 January 2019 13:00:02 CET freebsd-ports-requ...@freebsd.org 
wrote:
> While I can't go through all of them, but qr5-qdoc builds fine with llvm70,
> though I can't promise that it will work. I suspect that the port just
> needs updating to allow either port.

Yes, kde@ wants to update that to ${LLVM_DEFAULT} instead of specifically 
llvm60.

[ade]


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

Re: vim - GTK2 or GTK3?

[Adriaan de Groot]

Niclas wrote:

On Thursday, 3 January 2019 13:00:02 CET freebsd-ports-requ...@freebsd.org 
wrote:
> > Firefox and Chromium both depend on GTK3, so it's highly likely that a
> > typical desktop user has GTK3 installed.
> 
> +1, GTK3 is probably the best choice.
> 
> As a side note, it looks like libreoffice defaults to GTK2 as well,
> perhaps it should be switched to GTK3 also?

As a not-really-GTK-using person, I still have both GTK2 and GTK3 installed on 
my system running KDE Plasma. Not for vim though:

Installed packages to be REMOVED:
gtk2-2.24.32
fontforge-20170731
mftrace-1.2.18_1

Installed packages to be REMOVED:
gtk3-3.22.30_4
gpsd-3.17

I'm a fan of pushing for toolkit migration, so reducing the number of things 
that pull in GTK2 is a good thing.


So if we're expressing hopes that ports might be made GTK2-free (by porting to 
GTK3 for instance) then I'd hope that fontforge gets that treatment, too. From 
looking at the source repo, I don't think the GTK2 option actually works (and 
the comments suggest it's not all that good anyway). In the configure.ac it 
looks like there are spelling-inconsistencies between
fontforge_can_use_gtk=yes
and, e.g,,
FONTFORGE_ARG_ENABLE_GDK

(mtrace depends on fontforge, so fixing fontforge would clean GTK2 off my 
system)

[ade]

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

Re: SVN r488276 breaks net/qt5-network compilation

[Adriaan de Groot]

On Monday, 24 December 2018 18:14:51 CET Michael Butler wrote:
> As follows:

.. and here I had tested on 11.2 with base SSL, openssl, openssl111, .. and 
not considered that 12.0 would remove the definition of IFM_FDDI entirely.

Fixed, I hope, in r488281 (which built for me in a 12.0-RC3 VM).

[ade]


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

Re: category qt?

[Adriaan de Groot]

On Monday, 24 December 2018 13:00:02 CET freebsd-ports-requ...@freebsd.org 
wrote:
> > The qt* ports spreads around in the whole portstree.
> > 
> > It is reasonable to concentrate all these ports in a qt category? I
> > think it is easier to find (and also easier to maintain).
> 
> Indeed it is a bit annoying for me when I have to update qt* ports.
> I don't use portmaster or similar (I don't like them): I wrote my own
> utility, but it has still some issues, such as this one. I guess having
> all the qt* ports in the same category would help.

You might argue that all (?) the Qt ports are libraries and development tools, 
and so could live in the devel/ category. Or along other lines, that the split 
of Qt into a bunch of separate packages is superfluous and they should be 
merged (like gtk3, which is one big port -- I don't know if this is a useful 
functional analogy though).

But what makes Qt special in this regard? (One answer I'll accept is "the 
ports need to be updated in a coordinated fashion"). The reason (for instance) 
that two of the Qt5 ports live in textproc/ is .. that they're concerned with 
doing text processing. That functional-categorization in the ports tree has 
been there since always.

I guess it depends on the original post: "easier to find" for what?

If you're calling for a *virtual* category (like KDE ports have), that makes 
immediate sense to me (but would leave the ports scattered around the ports 
tree).

[ade]

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

Re: freebsd-ports Digest, Vol 807, Issue 5

[Adriaan de Groot]

On Wednesday, 14 November 2018 22:05:38 CET freebsd-ports-requ...@freebsd.org 
wrote:
> Date: Wed, 14 Nov 2018 21:00:20 +0900
> From: KIRIYAMA Kazuhiko 
> To: freebsd-ports@freebsd.org
> Cc: k...@kx.openedu.org
> Subject: multimedia/umplayer build failed (13.0-CURRENT/r339677)
> Message-ID: <201811141200.waec0kdi079...@kx.openedu.org>
> Content-Type: text/plain; charset=US-ASCII
> 
> Hi all,
> 
> umplayer-0.97_4 (multimedia/umplaye) failed to build in
> 13.0-CURRENT with port revision r339677 (detail log in [1]):

This is unrelated to multimedia/umplayer, and is simply that net/qt4-qnetwork 
does not build with the latest openssl. *Some* fixes have gone in (and out), 
but they are not enough and I'm having a devil of a time finding hours in the 
day to work on this (aside from the fact that Qt4 is scheduled for removal and 
was EOL'ed upstream years ago).

[ade]

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

KDE4 ports marked DEPRECATED

[Adriaan de Groot]

A bunch of ports commits at the end of August marked all the KDE4 ports that 
kde@ is responsible for, as DEPRECATED, e.g. for x11/kdelibs-kde4/

r478483 | adridg | 2018-08-30 20:40:36 +0200 (Thu, 30 Aug 2018) | 10 lines
Deprecate KDE4 software, categories www-x11-themes

Since not everyone reads the ports commits, or my blog [1], let's repeat the 
message in some more official places: KDE4 ports have been marked DEPRECATED 
and 
will be removed by kde@ around December 31st, after a four month deprecation 
period. We've tried to contact ports maintainers who have USES=kde:4, to 
inform them as well of the deprecation. This has been partly successful [2]. 
Some of those ports are rapidly transitioning to a KDE Frameworks version; 
others now have flavors.

Exactly how removal will work hasn't been decided yet. A one-shot "svn rm" and 
modification of Mk/Uses/kde.mk is possible, but it will probably be slightly 
less abrupt than that.

kde@ also maintains Qt4 ports. We have not said anything about them yet, but 
that software has been EOL upstream since 2015, and as soon as the 
maintainence burden from that ramps up at all, expect it to be cast upon the 
dungheap of software history as well (via a similar months-long deprecation 
process).


[ade]


[1] https://euroquis.nl/bobulate/?p=1969
[2] e.g. getting bounces from bitmail saying "pay $0.15 to deliver" is not a 
success

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

Re: Conflicts due to renamed KDE4 ports

[Adriaan de Groot]

[where did this discussion take place, earlier? this is the first I've seen it 
-- oh, the ports@ list]

So, there are roughly two migration paths: supposing someone has x11/kde4 
installed, which has dependencies on many applications and a Plasma 4 desktop, 
kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop, 
while renaming everything to have a -kde4 suffix. The other path is to migrate 
to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and 
if we do get one it probably won't be called x11/kde5.

For single applications, the migration looks similar: you had, around january 
2018, port . That's the KDE4 version. Now there is port -kde4, if 
you want to stick to KDE4 software (which is no longer released upstream, and 
is based on an EOL toolkit, but some people feel quite strongly about this). 
Ports  are returning, without a suffix, to mean "the latest-and-greatest-
version-of-". This is consistent with other ports which have a , 
sometimes a -devel for upcoming things, and a - for older 
versions if you have specific dependencies on old versions.

Historically, things were a mess with naming with the KDE ports. We think 
we've got a good scheme now: -kde4 (and in the far future, -kf5) for 
versions of the software based on an older stack, and  for the current 
one. But the pain of getting from the mess to something better organized has 
to happen at some point.

I think we've been saying this -- that things were going to happen this way -- 
for nearly a year. Maybe not in all the right places, though. 

On Monday, 16 April 2018 21:13:29 CEST Tijl Coosemans wrote:
> On Mon, 16 Apr 2018 20:11:33 +0200 Stefan Esser  wrote:
> > Am 16.04.18 um 12:38 schrieb Tijl Coosemans:
> >> On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser  wrote:
> >>> The way the new KDE5/KF5 ports have been introduced a few weeks back has
> >>> caused me quite some effort (more than 100 hours of work), and now there
> >>> have been further changes to implement KDE5 support (which I generally
> >>> appreciate), which cause further complications and seem not to be well
> >>> thought out.
> >>> 
> >>> These problems affect at least all portmaster users, but I guess
> >>> portupgrade is affected as well and a "pkg upgrade" dry-run indicates,
> >>> that it will also cause breakage to binary upgrades of KDE4
> >>> installations.
> >> 
> >> Removing entries from MOVED after only a few weeks is a bad idea, but
> >> it's not something you have to worry about.  As long as portmaster
> >> behaves more or less the same as pkg you're good.
> > 
> > I only tried a dry run, but it appears, that pkg does not deal with this
> > situation correctly. Grzegorz Junka reported, that it did not work for
> > him and he had to manually delete all KDE ports and re-install them from
> > his repository built with poudriere.
> > 
> > 
> > A correct decision is impossible given on the information in the ports.
> > 
> > It is correct to upgrade e.g. databases/akonadi (akonadi-1.13.0_6) to
> > databases/akonadi-kde4 (akonadi-kde4-1.13.0_7), but neither the origin
> > nor package name nor a MOVED entry provide that information.

This is correct if, and only if, you want the migration path of staying-with-
KDE4.

> > It is not correct to replace databases/akonadi (akonadi-1.13.0_6) by
> > databases/akonadi (akonadi-17.12.3), but this can only be seen by
> > checking the forward and backward dependencies (which are for KDE5/QT5
> > instead of KDE4/QT4 of the installed port).

. and this is the correct move if you want to go with KDE Applications (the 
current releases). The package manager and the ports-management tools can't 
know which one you want, I don't think.

Consider vim -- it doesn't have one blessed-and-eternal version called "vim", 
editors/vim is the most-recent version. We've adopted that same convention.

What I *do* understand is that the package and ports-management tools don't 
deal well with this. There was a window where we tried to do all the moving.

> > 
> > The same considerations applied to another port may lead to different
> > results. While pkg requires exact dependencies to be installed, it is
> > possible to use alternatives to satisfy dependencies with portmaster.
> > And this feature is heavily used, e.g. to use a different version of
> > samba than the default hard-wired into package dependencies. But this
> > flexibility needs a basis for deciding, whether such a replacement is
> > valid and how to perform upgrades in that situation.
> > 
> > 
> > If akonadi is installed only as a dependency of other ports, then pkg will
> > install the akonadi-kde4 version. But since the old version is installed
> > as an in-use dependency of other KDE4 ports, it will not be removed before
> > the installation of the new version is attempted (which will lead to an
> > install conflict, since files of an installed port are to be overwritten).
> > 
> > It is possible to 

Re: [kde-freebsd] Unable to build deskutils/kdepimlibs4

[Adriaan de Groot]

On Friday, January 04, 2013 07:24:28 PM Jerry wrote:
 Following the directions in UPDATING, I used the following command:
 
   portupgrade -fr devel/libical
 
 That port updated correctly; however, the next port:

 The entire build log is available here:
 
   https://www.seibercom.net/logs/kdep.txt
 
 I do not see an obvious reason for the build failure. I tried it three
 times including doing a distclean and updating the ports tree.


There is an obvious reason, but you have to scroll back a ways in the log:

 
/usr/ports/deskutils/kdepimlibs4/work/kdepimlibs-4.8.4/kioslave/smtp/command.cpp
In file included from 
/usr/ports/deskutils/kdepimlibs4/work/kdepimlibs-4.8.4/kioslave/smtp/command.h:37,
 from 
/usr/ports/deskutils/kdepimlibs4/work/kdepimlibs-4.8.4/kioslave/smtp/command.cpp:32:
/usr/local/include/sasl/sasl.h:228: error: typedef 'sasl_malloc_t' is 
initialized (use __typeof__ instead)
/usr/local/include/sasl/sasl.h:228: error: 'size_t' was not declared in this 
scope


This is because of the new sasl port, which does not include all the headers 
it needs in its own headers (e.g. defining size_t). You can patch 
/usr/local/include/sasl/sasl.h to fix that, or patch command.cpp to #include 
the right headers before sasl.h.

[ade]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org