Re: Conflicts due to renamed KDE4 ports

[Stefan Esser]

Am 17.04.18 um 20:29 schrieb Tobias C. Berner:
> Moin moin
> 
> Here's a script which should automatically fix the origin for the
> kde4-versioned ports (based on the MOVED entries of r465345):
>    http://people.freebsd.org/~tcberner/scripts/fix_kde4_origins.sh
> 
> It //should// set the origins properly for the moved ports, and the output
> should be on the lines of
> # ./fix_kde4_origins.sh
> [...]
> - sysutils/baloo-widgets [sysutils/baloo-widgets-kde4] is not installed.
> + Changing origin of nepomuk-core-4.14.3_14 from sysutils/nepomuk-core to
> sysutils/nepomuk-core-kde4.
> - sysutils/kfloppy [sysutils/kfloppy-kde4] is not installed.
> - sysutils/ksystemlog [sysutils/ksystemlog-kde4] is not installed.
> + Changing origin of baloo-4.14.3_5 from sysutils/baloo to 
> sysutils/baloo-kde4.
> + Changing origin of kfilemetadata-4.14.3_13 from sysutils/kfilemetadata to
> sysutils/kfilemetadata-kde4.
> [...]
> 
> 
> Please let me know if that works for you, or how I could improve it.

My suggested version (that does not depend on any hard-coded version
strings in the script) is:

#!/bin/sh

cd /usr/ports
for origin in */*-kde4; do
origin_old=$(dirname $origin)/$(basename $origin -kde4)
pkgname=$(make -C $origin -V PKGNAME)
pkg_glob="${pkgname%%.*}.*"
package=$(pkg query -g "%n-%v" "$pkg_glob")
pkg set -y -o $origin_old:$origin $package
done

Regards, STefan

[Bug 227428] devel/cmake: fails to find suffixed libboost_python

[bugzilla-noreply]

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

--- Comment #17 from Willem Jan Withagen  ---
(In reply to Jan Beich from comment #16)

extracts from the Cpeh-python discussion:

Mimic - after a "best effort" to migrate, some Python code still runs on Python
2, but Shaman has a Python 3 build flavor and teuthology is capable of testing
in Python 3-only environment.

Nautilus - all remaining packaged Python code has been migrated and explicitly
runs (and is tested) on Python 3. Python 2 versions of our code do not need to
be provided or packaged, because all target platforms support Python 3. There
might still be some Python 2 scripts in the git repo, but these are either
special cases or for developer use only, and are not packaged. 

(These are the 2 upcoming releases)

And also:
> I'm not objecting to making the leap (it's better than trying to
> support 2 and 3 at the same time!), but let's make sure we understand
> consequences for users.

Meaning that Ceph never intended to have both a 2.7 and 3.x python version.
And it is currently 2.7 for most of the consumer facing items.
Some of the test parts are actually already 3.x compatible, and or running on
3.x

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

[Bug 227428] devel/cmake: fails to find suffixed libboost_python

[bugzilla-noreply]

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

--- Comment #16 from Jan Beich  ---
Boost 1.67 has landed. Try commenting out -DBOOST_PYTHON_SUFFIX in
Mk/Uses/python.mk then build devel/libarea in order to better understand CMake
3.11.0 shortcomings.

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

[Bug 227428] devel/cmake: fails to find suffixed libboost_python

[bugzilla-noreply]

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

--- Comment #15 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jbeich
Date: Wed Apr 18 13:58:16 UTC 2018
New revision: 467712
URL: https://svnweb.freebsd.org/changeset/ports/467712

Log:
  devel/cmake: allow consumers to qualify boost_python version

  PR:   227428
  Exp-run by:   antoine

Changes:
  head/Mk/Uses/python.mk
  head/devel/cmake/Makefile
  head/devel/cmake/files/patch-Modules_FindBoost.cmake

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

[Bug 227428] devel/cmake: fails to find suffixed libboost_python

[bugzilla-noreply]

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

--- Comment #14 from Jan Beich  ---
(In reply to Jan Beich from comment #13)
> If "pythonXY" is used then Boost < 1.67 users are out of luck.

Err, mainly FreeBSD Ports users. According to FindBoost.cmake some
distributions (Debian/Ubuntu, Gentoo, RPMs) implemented their own versioning
*before* Boost 1.67.

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

[Bug 227428] devel/cmake: fails to find suffixed libboost_python

[bugzilla-noreply]

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

--- Comment #13 from Jan Beich  ---
(In reply to Adriaan de Groot from comment #11)
> how much of that would just go away if we fix the CMake module?

None. My ${PY_BOOST_LIB} fixes are for non-CMake ports or CMake ports with
their own way to find Boost.Python.

> how much goes away by itself with CMake 3.11.0?

None. CMake added "pythonXY" (versioned) support as Boost component. If a
project doesn't switch from "python" to "pythonXY" CMake won't find
libboost_pythonXY installed by Boost 1.67. If "pythonXY" is used then Boost <
1.67 users are out of luck. Obviously, downstream (e.g., FreeBSD Ports) maybe
unhappy with whatever Python version was requested, often preferring a more
recent one.

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

[Bug 227428] devel/cmake: fails to find suffixed libboost_python

[bugzilla-noreply]

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

--- Comment #12 from Willem Jan Withagen  ---
(In reply to Adriaan de Groot from comment #11)

If the fix in the Cmake stuff (either FreeBSD specific or not) allows for
this call
find_package(Boost 1.66 COMPONENTS ${BOOST_COMPONENTS} REQUIRED)
to do "the right thing" (tm), then No changes to the ceph-source are needed.

As things go now I'll have to add a selector on FreeBSD to append the
python-version. No biggie, but again specific code for a specific problem.

That said, to has started with a discussion on ceph-dev to determine what to do
with 2.7 and how fast to fase it out, and make all 3.x code. 

That could/would leave FreeBSD users that are mainly on 2.7 in the cold.
Which should not be a major problem from opperational point, since you do not
want to do much other on the ceph storage nodes. It could however conflict on
compute nodes where scripting depends on 2.7 and 2.7 compatible classes.

So I'm driven here by what Ceph does in the code, and by FreeBSD packages in
what is possible and desirable. And that in the negative time I have available
ATM.

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

[Bug 227428] devel/cmake: fails to find suffixed libboost_python

[bugzilla-noreply]

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

--- Comment #11 from Adriaan de Groot  ---
I see jbeich@ committing lots of workarounds for Boost::Python 1.67 .. how much
of that would just go away if we fix the CMake module? Also, how much goes away
by itself with CMake 3.11.0? There's a specific commit in there

FindBoost: Add support for Boost 1.67 with Python version suffixes

Which, if it doesn't work, needs fixing on our (my, CMake) end.

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

[Bug 224185] [cmake] net/ceph and net/ceph-devel: fails to build with boost 1.66

[bugzilla-noreply]

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

--- Comment #30 from Willem Jan Withagen  ---
(In reply to Jan Beich from comment #29)

Just this morning one the the core developers for Ceph started the dicussion of
EOL-ing all stuff that depends on 2.7, and only work on using 3.x. Because 2.7
is EOL in 2020
So I'm expecting even more fallout.

Question what is going to be needed to keep FreeBSD packages happy. But I guess
I'll find out in due time.

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

[Bug 227372] [exp-run] Update devel/cmake to 3.11.0

[bugzilla-noreply]

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

--- Comment #19 from Yasuhiro KIMURA  ---
(In reply to Adriaan de Groot from comment #18)

I checked with ports r467657 and confirmed this port can be build successfuly
on both poudriere and real environment. Thank you for fixing the problem.

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

[Bug 220394] graphics/digikam-kde4: too many open files

[bugzilla-noreply]

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

Adriaan de Groot  changed:

   What|Removed |Added

 CC||adr...@freebsd.org
 Status|New |Closed
 Resolution|--- |Feedback Timeout

--- Comment #3 from Adriaan de Groot  ---
There are workarounds, and a newer version of the application, and I'm not in a
position to test this (because I don't have 30k photos).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 224030] devel/cmake: fails to build with flavors; py-sphinx missing

[bugzilla-noreply]

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

--- Comment #17 from Adriaan de Groot  ---
This was fixed in ports r460715 (amdmi3)

-- 
You are receiving this mail because:
You are the assignee for the bug.

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/k...@freebsd.org.html


Port| Current version | New version
+-+
devel/cmake | 3.11.0  | 3.11.1
+-+
devel/cmake-doc | 3.11.0  | 3.11.1
+-+
devel/cmake-gui | 3.11.0  | 3.11.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.

[Bug 224137] devel/qt5-qmake: Doesn't use the right compiler in case USE_GCC is selected

[bugzilla-noreply]

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

Adriaan de Groot  changed:

   What|Removed |Added

 CC||adr...@freebsd.org

--- Comment #3 from Adriaan de Groot  ---
This is basically the same as PR 204923. Because of the way qmake's mkspecs
work, the compiler from the mkspec is used, rather than ${CC} or ${CXX}.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 226959] devel/cmake: find_package(BLAS REQUIRED) doesn't find blas

[bugzilla-noreply]

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

Adriaan de Groot  changed:

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

--- Comment #11 from Adriaan de Groot  ---
Plain find_package(BLAS) now works (with the patches introduced with the
packaging of CMake 3.11.0).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 223678] devel/cmake: find_package(OpenMP) doesn't find the openmp package

[bugzilla-noreply]

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

Adriaan de Groot  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

--- Comment #15 from Adriaan de Groot  ---
Plain find_package(OpenMP) now works, as do ports that use it (e.g. Wesnoth).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 227372] [exp-run] Update devel/cmake to 3.11.0

[bugzilla-noreply]

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

--- Comment #18 from Adriaan de Groot  ---
(In reply to Yasuhiro KIMURA from comment #6)

Thank you for your earlier comments. Could you please confirm that CMake
3.11.0_1 (latest ports) does build in your poudriere setup?

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