[Bug 227573] devel/cmake build issues with py36
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227573 Matthew Leach changed: What|Removed |Added CC||matt-free...@3kt.co.uk Summary|CMAKE build issues with |devel/cmake build issues |py36|with py36 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 227573] CMAKE build issues with py36
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227573 Bug ID: 227573 Summary: CMAKE build issues with py36 Product: Ports & Packages Version: Latest Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: Individual Port(s) Assignee: k...@freebsd.org Reporter: matt-free...@3kt.co.uk Flags: maintainer-feedback?(k...@freebsd.org) Assignee: k...@freebsd.org Hi, I am trying to build cmake with the the build options of just MANPAGES with uses py-sphinx to build the respective manpages. I am hitting a couple of issues. Firstly, in order to build with python36, and having looked at the Makefile, i have to specify PY_FLAVOR=py36 rather than just FLAVOR=py36 which seems to differ to other ports. root@server:/usr/ports/devel/cmake # make FLAVOR=py36 install clean ===> cmake-3.11.0 FLAVOR is defined (to py36) while this port does not have FLAVORS.. *** Error code 1 Specifying PY_FLAVOR=py36 does work and instigates the build/install of the dependant py36 python packages. Secondly, even with PY_FLAVOR=py36 stated and cmake picking up py36-sphinx being installed, cmake fails to install with the error of -- root@server:/usr/ports/devel/cmake # make PY_FLAVOR=py36 all install clean ===> cmake-3.11.0 depends on executable: sphinx-build - not found ===> cmake-3.11.0 depends on executable: sphinx-build - not found *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/cmake *** Error code 1 Stop. make: stopped in /usr/ports/devel/cmake -- root@server:~ # pkg info | grep py36-sphinx py36-sphinx-1.6.5_1,1 Python documentation generator py36-sphinx_rtd_theme-0.2.4Mobile-friendly py-sphinx theme py36-sphinxcontrib-websupport-1.0.1 Sphinx API for Web Apps root@server:~ # -- You are receiving this mail because: You are the assignee for the bug.
maintainer-feedback requested: [Bug 227573] CMAKE build issues with py36
Bugzilla Automation has asked k...@freebsd.org for maintainer-feedback: Bug 227573: CMAKE build issues with py36 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227573 --- Description --- Hi, I am trying to build cmake with the the build options of just MANPAGES with uses py-sphinx to build the respective manpages. I am hitting a couple of issues. Firstly, in order to build with python36, and having looked at the Makefile, i have to specify PY_FLAVOR=py36 rather than just FLAVOR=py36 which seems to differ to other ports. root@server:/usr/ports/devel/cmake # make FLAVOR=py36 install clean ===> cmake-3.11.0 FLAVOR is defined (to py36) while this port does not have FLAVORS.. *** Error code 1 Specifying PY_FLAVOR=py36 does work and instigates the build/install of the dependant py36 python packages. Secondly, even with PY_FLAVOR=py36 stated and cmake picking up py36-sphinx being installed, cmake fails to install with the error of -- root@server:/usr/ports/devel/cmake # make PY_FLAVOR=py36 all install clean ===> cmake-3.11.0 depends on executable: sphinx-build - not found ===> cmake-3.11.0 depends on executable: sphinx-build - not found *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/cmake *** Error code 1 Stop. make: stopped in /usr/ports/devel/cmake -- root@server:~ # pkg info | grep py36-sphinx py36-sphinx-1.6.5_1,1 Python documentation generator py36-sphinx_rtd_theme-0.2.4Mobile-friendly py-sphinx theme py36-sphinxcontrib-websupport-1.0.1 Sphinx API for Web Apps root@server:~ #
[exp - 103i386-default-build-as-user][math/kig] Failed for kig-17.12.3 in package
You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: k...@freebsd.org Last committer: tcber...@freebsd.org Ident: $FreeBSD: head/math/kig/Makefile 466873 2018-04-09 18:13:24Z tcberner $ Log URL: http://package19.nyi.freebsd.org/data/103i386-default-build-as-user/467443/logs/kig-17.12.3.log Build URL: http://package19.nyi.freebsd.org/build.html?mastername=103i386-default-build-as-user&build=467443 Log: =>> Building math/kig build started at Tue Apr 17 00:32:50 UTC 2018 port directory: /usr/ports/math/kig package name: kig-17.12.3 building for: FreeBSD 103i386-default-build-as-user-job-03 10.3-RELEASE-p29 FreeBSD 10.3-RELEASE-p29 i386 maintained by: k...@freebsd.org Makefile ident: $FreeBSD: head/math/kig/Makefile 466873 2018-04-09 18:13:24Z tcberner $ Poudriere version: 3.2.6-1-ga0ae87a0 Host OSVERSION: 1200060 Jail OSVERSION: 1003000 Job Id: 03 ---Begin Environment--- SHELL=/bin/csh UNAME_p=i386 UNAME_m=i386 OSVERSION=1003000 UNAME_v=FreeBSD 10.3-RELEASE-p29 UNAME_r=10.3-RELEASE-p29 BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 HOME=/root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin LOCALBASE=/usr/local USER=root LIBEXECPREFIX=/usr/local/libexec/poudriere POUDRIERE_VERSION=3.2.6-1-ga0ae87a0 MASTERMNT=/poudriere/data/.m/103i386-default-build-as-user/ref POUDRIERE_BUILD_TYPE=bulk PACKAGE_BUILDING=yes SAVED_TERM= GID=0 UID=0 PWD=/poudriere/data/.m/103i386-default-build-as-user/ref/.p/pool P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS MASTERNAME=103i386-default-build-as-user SCRIPTPREFIX=/usr/local/share/poudriere OLDPWD=/poudriere/data/.m/103i386-default-build-as-user/ref/.p SCRIPTPATH=/usr/local/share/poudriere/bulk.sh POUDRIEREPATH=/usr/local/bin/poudriere ---End Environment--- ---Begin Poudriere Port Flags/Env--- PORT_FLAGS= PKGENV= FLAVOR= DEPENDS_ARGS= MAKE_ARGS= ---End Poudriere Port Flags/Env--- ---Begin OPTIONS List--- ---End OPTIONS List--- --MAINTAINER-- k...@freebsd.org --End MAINTAINER-- --CONFIGURE_ARGS-- --with-qt-includes=/usr/local/include/qt5 --with-qt-libraries=/usr/local/lib/qt5 --with-extra-includes=/usr/local/include --with-extra-libs=/usr/local/lib --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- QT_SELECT=qt5 QMAKEMODULES="/wrkdirs/usr/ports/math/kig/work/kig-17.12.3/mkspecs/modules:/usr/local/lib/qt5/mkspecs/modules" PYTHON="/usr/local/bin/python2.7" XDG_DATA_HOME=/wrkdirs/usr/ports/math/kig/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/math/kig/work HOME=/wrkdirs/usr/ports/math/kig/work TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/math/kig/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin SHELL=/bin/sh CONFIG_SHELL=/bin/sh QTDIR="/usr/local/lib/qt5" QMAKE="/usr/local/lib/qt5/bin/qmake" MOC="/usr/local/lib/qt5/bin/moc" RCC="/usr/local/lib/qt5/bin/rcc" UIC="/usr/local/lib/qt5/bin/uic" QMAKESPEC="/usr/local/lib/qt5/mkspecs/freebsd-$(ccver="$(c++ --version)"; case "$ccver" in *clang*) echo clang ;; *) echo g++ ;; esac)" --End CONFIGURE_ENV-- --MAKE_ENV-- QT_SELECT=qt5 QMAKEMODULES="/wrkdirs/usr/ports/math/kig/work/kig-17.12.3/mkspecs/modules:/usr/local/lib/qt5/mkspecs/modules" XDG_DATA_HOME=/wrkdirs/usr/ports/math/kig/work XDG_CONFIG_HOME=/wrkdirs/usr/ports/math/kig/work HOME=/wrkdirs/usr/ports/math/kig/work TMPDIR="/tmp" PATH=/wrkdirs/usr/ports/math/kig/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin NO_PIE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes SHELL=/bin/sh NO_LINT=YES DESTDIR=/wrkdirs/usr/ports/math/kig/work/stage PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS=" -fstack-protector" LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing " 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="instal l -m 444" --End MAKE_ENV-- --PLIST_SUB-- PORTDOCS="" PORTEXAMPLES="" QT_BINDIR="lib/qt5/bin" QT_INCDIR="include/qt5" QT_LIBDIR="lib/qt5" QT_ARCHDIR="lib/qt5" QT_PLUGINDIR="lib/qt5/plugins" QT_LIBEXECDIR="libexec/qt5" QT_IMPORTDIR="lib/qt5/imports" QT_QMLDIR="lib/qt5/qml" QT_DATADIR="share/qt5" QT_DOCDIR="share/doc/qt5" QT_L10NDIR="share/qt5/translations" QT_EXAMPLEDIR="share/examples/qt5" QT_TESTDIR="share/qt5/tests" QT_MKSPECDIR="lib/qt5/mkspecs" QT_QTCHOOSERDIR="etc/xdg/qtchooser" CMAKE_BUILD_TYPE="release" KDE_APPLICATIONS_SHLIB_VER=5.7.3 KDE_PREFIX="/usr/local" KDE_APPLICATIONS_VERSION="17.12.3" KDE_FRAMEWORKS_VERSION="5.44.0" PYCACHE="" PYC_SUFFIX=pyc PYO_SUFFIX=pyo PYTHON_INCLUDEDIR=include/python2.7 PYTHON_LIBDIR=lib/python2.7 PYTHON_PLATFORM=freebsd10 PYTHON_PYOEXTENSION=pyo
Re: Conflicts due to renamed KDE4 ports
[where did this discussion take place, earlier? this is the first I've seen it] 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 manually and forcefully delete akonadi-1.13.0_6 before > > sta
[Bug 227372] [exp-run] Update devel/cmake to 3.11.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 --- Comment #13 from Adriaan de Groot --- With all these considerations -- we will be updating the CMake port shortly (tuesday or wednesday) to make pkg optional *or* to make stage-qa accept the port. It depends on what is technically feasible; goal is that a poudriere build with -t (which runs stage-qa) will actually succeed. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Conflicts due to renamed KDE4 ports
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. > > 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). > > 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 manually and forcefully delete akonadi-1.13.0_6 before > starting pkg upgrade for the KDE4 ports that depend on it. In that case, > there is no conflict. But pkg autodelete cannot be used, since to remove > the dependency on the old version, the (conflicting) new version must be > registered in the ports that depend on akonadi. > > If akonadi has been directly installed and not (only) as a dependency, > the akonadi-17.12.3 will be considered to be an upgrade of akonadi-1.13.* > (same origin and same package name, except for the version numbers). This > will remove the required dependency from the KDE4 ports and will register > the KDE5 version as new dependency of those ports (although it completely > useless in that role). > > > When not even pkg can deal with this situation, how should portmaster? > > The packages are built without consideration for the requirements of a > running system, and pkg sees all the meta-information of all installed > packages and the one being processed and can e.g. see, that files will > conflict (which portmaster can only do after completely building the > port, which means that this is long after the decision to use that port > has been required). > > > The lack of consideration given by port maintainers is quite frustrating, > since it requires a lot of effort to work around the issues caused. Like I said, IMHO it's not your problem, so you don't need to work around it and you don't have to feel frustrated by it. Without an entry in MOVED there's no way for portmaster or pkg to know that the old akonadi needs to be replaced with akonadi-kde4. If any user contacts you about this you can forward them to kde@ because they created the problem. IMHO, entries in MOVED should stay for at least a year, if not several years, so kde@ should restore the kde4 MOVED entries and give the kde5 ports a -kde5 suffix or something. Hopefully there aren't that many users yet because you can't create MOVED entries for this move.
[Bug 227372] [exp-run] Update devel/cmake to 3.11.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 John Hein changed: What|Removed |Added CC||anto...@freebsd.org --- Comment #12 from John Hein --- (In reply to John Hein from comment #11) I'm surprised an exp-run doesn't catch these Q/A problems. Or are they ignored? -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 --- Comment #11 from John Hein --- I will add that if the libarchive port is installed, cmake will like with that version (/usr/local/lib/libarchive.so.13). But the libarchive dependency is now not flagged as a dependency. Then if the user later removes the libarchive package, cmake will break: Shared object "libarchive.so.13" not found, required by "ccmake" If you want to disable linking with the port version of libarchive, you need to be more explicit (either in devel/cmake and/or adding the option in Mk/Uses/libarchive.mk). The 'pkg' dependency will have a similar problem. -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 --- Comment #10 from John Hein --- Perhaps Mk/Uses/libarchive.mk could grow support for base libarchive (similar to Uses/iconv.mk). -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 John Hein changed: What|Removed |Added CC||z7dr6ut...@snkmail.com --- Comment #9 from John Hein --- (In reply to Yasuhiro KIMURA from comment #8) 'stage-qa' fails here for me as well on 10/stable... Error: Bad linking on libarchive.so.6 for please add USES=libarchive Error: /usr/local/bin/ccmake is linked to /usr/local/lib/libarchive.so.13 from archivers/libarchive but it is not declared as a dependency Warning: you need USES+=libarchive Error: /usr/local/bin/cpack is linked to /usr/local/lib/libpkg.so.4 from ports-mgmt/pkg but it is not declared as a dependency Warning: you need LIB_DEPENDS+=libpkg.so:ports-mgmt/pkg -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 227509] graphics/mesa-libs: make WAYLAND default on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227509 --- Comment #4 from Tobias C. Berner --- Sorry, I had my wires crossed a bit. In fact we should be able to build the X11 part of Plasma5 without this change. But I none the less think, that this change is very non-invasive and does more good than bad :) -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227428 Jan Beich changed: What|Removed |Added Keywords|needs-patch |patch -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 --- Comment #8 from Yasuhiro KIMURA --- (In reply to Adriaan de Groot from comment #7) OK, I understand what you think is problem. But as a simple fact, currently this port cannot be build with poudriere. And as far as I tried same error happens on real 11.1-RELEASE environment. So would you mind my asking under what conditions this port currently can be build successfully? -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227372 --- Comment #7 from Adriaan de Groot --- (In reply to Yasuhiro KIMURA from comment #6) Yes, that is exactly the overlinking problem we have chosen to ignore. We do not want to explicitly make CMake depend on pkg, because pkg and pkg-devel conflict with each other. We do not want to add USES=libarchive, because pkg links to base libarchive (.so.6) while ports provides .so.13 (or later). -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227428
--- Comment #10 from Willem Jan Withagen ---
(In reply to Jan Beich from comment #9)
Oke, I understand the solution, but the Ceph Cmake code is:
list(APPEND BOOST_COMPONENTS python)
..
find_package(Boost 1.66 COMPONENTS ${BOOST_COMPONENTS} REQUIRED)
Which is there because of all kinds of reasons, mainly having to do with
different distro and versions of distros holding boost libs with a too low
version.
So from you remark I conclude that this code WILL require handholding.
Even after things are patched?
I do expect to see some python version in Ceph in the near future, because they
are running into 2.7 <> 3.x issues as well.
The other compilation errors are a "problem" as I have very little time at the
moment. Trying to get $WORK projects finished before I have a little bit of
R&R.
--
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227428 --- Comment #9 from Jan Beich --- If -DBOOST_PYTHON_SUFFIX=27 is passed "find_package(Boost COMPONENTS python)" will look not only for libboost_python.so but also libboost_python27.so. Ideally, CMake should try Python_ADDITIONAL_VERSIONS for Boost then fall back to common suffixes. Requiring ugly Boost.Python ifdefs in consumers is non-starter unless a specifc Boost version is explicitly requested i.e., "find_package(Boost 1.67 ...)". And consumers cannot jump on the latest Boost version without alienating downstream[1]. [1] https://repology.org/metapackage/boost/versions (In reply to Willem Jan Withagen from comment #8) > In which case I'll fix the Cmake build to differentiate on this. No need. With the patch net/ceph makes past "configure" stage until it hits C++ bustage (a la ports r467364). -- You are receiving this mail because: You are on the CC list for the bug.
FreeBSD ports you maintain which are out of date
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/kf5-ktexteditor | 5.44.0 | 5.45.0 +-+ x11-toolkits/kf5-kxmlgui| 5.44.0 | 5.45.0 +-+ 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 227428] devel/cmake: fails to find suffixed libboost_python
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227428
--- Comment #8 from Willem Jan Withagen ---
(In reply to Jan Beich from comment #7)
So to make sure:
`CMAKE_ARGS+= -DBOOST_PYTHON_SUFFIX:STRING=${PYTHON_SUFFIX}`
gets automagically added to the Cmake args if USES=python is set.
In which case I'll fix the Cmake build to differentiate on this.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 227530] graphics/okular: Doesn't show icons for Thumbnales, Reviews, Bookmarks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227530 --- Comment #17 from Yuri Victorovich --- (In reply to Tobias C. Berner from comment #16) No problem! Thank you, Tobias! -- You are receiving this mail because: You are the assignee for the bug.
