Re: libkgapi-18.08 conflicts with kdepim-runtime-18.04.3_2
Am 31.08.18 um 23:37 schrieb Adriaan de Groot: > On Saturday, 25 August 2018 16:04:43 CEST Stefan Esser wrote: >> This might be no problem when upgrading from a package, but upgrading from a >> port (e.g. with portmaster) fails with: >> >> ===> Registering installation for libkgapi-18.08.0 >> Installing libkgapi-18.08.0... >> pkg-static: libkgapi-18.08.0 conflicts with kdepim-runtime-18.04.3_2 >> (installs files into the same place). Problematic file: >> /usr/local/lib/sasl2/libkdexoauth2.so >> *** Error code 70 >> >> I had expected some information in UPDATING or a conflicts entry, which >> matches kdepim-runtime<=18.04 or something like that ... >> >> What is the correct way to deal with that problem? > > For the record on the mailing list: > > This is caused by files moving from one package to another upstream (and no > UPDATING / CONFLICTS being set in the port, downstream). To fix, remove > kdepim- > runtime, then update kmailtransport and libkgapi, then install the rest again. Hi Adriaan, I had assumed that this was the cause, and IMHO that situation should be dealt with by (until the following release or the one after that) having a CONFLICTS entry in devel/libkgabpi/Makefile, e.g.: CONFLICTS_BUILD=kdepim-runtime-18.0[0-4]* That way, users building from a port can see this warning, but tools like portmaster can react and plan the installation steps in such a way, that the upgrade succeeds without intervention. In my case, some 200 ports needed to be upgraded by portmaster, and except for this problem, everything went smooth. If the KDE team decides that building from ports is no longer supported, there is a problem for users that depend on building other ports themselves, since mixing of ports and packages does not work too well. (A pkg upgrade of the KDE ports wants to replace locally built packages with official packages and thus is not usable if ports with non-default options are installed and required.) I understand that the conflict was not due to changes performed by the KDE team, but IMHO the KDE team should consider upgrades from ports as supported and thus should place the required CONFLICTS lines into affected ports. Regards, STefan signature.asc Description: OpenPGP digital signature
libkgapi-18.08 conflicts with kdepim-runtime-18.04.3_2
This might be no problem when upgrading from a package, but upgrading from a port (e.g. with portmaster) fails with: ===> Registering installation for libkgapi-18.08.0 Installing libkgapi-18.08.0... pkg-static: libkgapi-18.08.0 conflicts with kdepim-runtime-18.04.3_2 (installs files into the same place). Problematic file: /usr/local/lib/sasl2/libkdexoauth2.so *** Error code 70 I had expected some information in UPDATING or a conflicts entry, which matches kdepim-runtime<=18.04 or something like that ... What is the correct way to deal with that problem? Regards, STefan
Re: Missing CONFLICTS between x11/kde-runtime-kde4 and sysutils/plasma5-kde-cli-tools
Am 25.05.18 um 13:08 schrieb Adriaan de Groot: > On Thursday, 24 May 2018 22:45:20 CEST Stefan Esser wrote: >> PS: Do you want me to open a PR for such issues? Since I'm currently >> testing the re-implementation of portmaster I'm working on, it is >> highly probable that there will be more such problems found (which >> I need to diagnose to see whether it is a bug in portmaster or an >> omission in the port). > > I'm going to say "no, we don't need a PR for that", just drop the list a > note, > and/or prod us on #kde-freebsd on FreeNode, just in case. > > [ade] (with kde@ hat on) Hi Adrian, thank you your reply and the patch in D15571. I've spent some time today on an effort to identify all affected ports, and the result is the following list: databases/akonadi-kde4 databases/akonadi deskutils/kdepimlibs-kde4 databases/akonadi net/akonadi-mime deskutils/kdepimlibs-kde4 net/kmailtransport deskutils/kdepimlibs-kde4 sysutils/plasma5-ksysguard sysutils/ksysguardd-kde4 sysutils/polkit-kdesysutils/plasma5-polkit-kde-agent-1 x11/kde-workspace-kde4 devel/plasma5-khotkeys x11/kde-workspace-kde4 sysutils/plasma5-kinfocenter x11/kde-workspace-kde4 sysutils/plasma5-kmenuedit x11/kde-workspace-kde4 sysutils/plasma5-ksysguard x11/kde-workspace-kde4 sysutils/plasma5-libksysguard x11/kde-workspace-kde4 sysutils/plasma5-systemsettings x11/kde-workspace-kde4 x11-wm/plasma5-kwin x11/plasma5-kactivitymanagerd x11/kactivitymanagerd x11/plasma5-plasma-desktop x11/kde-runtime-kde4 x11/plasma5-plasma-desktop x11/kde-workspace-kde4 x11/plasma5-plasma-workspace x11/kde-workspace-kde4 Each port in the 1st column contains files also present in the port in the 2nd column, but lacks a CONFLICTS_INSTALL entry. E.g. in the case of akonadi it appears, that the KF5 port is marked as conflicting, but the KDE4 port lacks that conflicts annotation. (I.e., the ports in column 1 need to be marked as conflicting with the ports in column 2.) I have generated this list by fetching all KDE4 and KF5 packages and matching all the files they contain against each other, then identified the ports that correspond to those packages and finally checked for an CONCLICTS entry. I have kept some of the intermediate results and could try to repeat the match steps in case I made a mistake and the results are not correct (I have not verified each of those combinations, but the samples I checked were correctly identified). Seems that most of the conflicts have already been correctly registered, since the list of conflicting pairs was about an order of magnitude longer before I had filtered out all the pairs that were already correctly annotated. Best regards, STefan signature.asc Description: OpenPGP digital signature
Missing CONFLICTS between x11/kde-runtime-kde4 and sysutils/plasma5-kde-cli-tools
Hi KDE-Team! These two ports install kdesu and thus cannot be installed together: x11/kde-runtime-kde4 sysutils/plasma5-kde-cli-tools pkg-static: plasma5-kde-cli-tools-5.12.5 conflicts with kde-runtime-kde4-16.12.3_10 (installs files into the same place). Problematic file: /usr/local/man/man1/kdesu.1.gz Please add appropriate CONFLICTS entries to both of them. Regards, STefan PS: Do you want me to open a PR for such issues? Since I'm currently testing the re-implementation of portmaster I'm working on, it is highly probable that there will be more such problems found (which I need to diagnose to see whether it is a bug in portmaster or an omission in the port).
Re: Conflicts due to renamed KDE4 ports
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
Re: Conflicts due to renamed KDE4 ports
er stack, and for the current > one. But the pain of getting from the mess to something better organized has > to happen at some point. The scheme looks good to me and will work for fresh installs. And I have already pointed out, how such conflicts are generally being dealt with: If it cannot be via MOVE entries, the the necessary preparation steps are given in an UPDATING entry. But they should be complete (i.e. not only "set the new origins following this scheme for all affected ports, since that may be tens and the user cannot easily list them, since there is no simple pkg query command that would generate this list). > 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. Well, you may have said int in the KDE lists, but I'm not following them and I'm just interested in keeping portmaster working for all ports, KDE included but in no way special (except for the breakage caused ;-) ). > 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. I'm not interested in whether the user wants to stay with KDE4. I'm interested in portmaster upgrading the ports on a system that has KDE4 packages installed. And currently it fails, which now has lead to more than 600 ports not being upgraded on my development system. I could (and do for critical packages) upgrade them individually, but a simple "portmaster -a" stops for each affected KDE4 port, with the remainder of the work list dropped. (That is a weakness in portmaster, since it was a basic decision to not make it continue in case any port failed that might be used as a dependency of some other port. I'm considering to change that in the new major portmaster release I'm working on - the way it works now was chosen by the original author of portmaster.) >>> 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. The tools cannot know and cannot decide this. My thinking is, that the old KDE4 ports shall be kept and updated if either manually installed (not as a dependency) and if they are still required (there are still ports that depend on them). Since the KDE5 versions do not cause any conflicts, they can be installed besides the KDE4 versions, and any port that depends on teh KDE5 versions will get them installed as independent ports. But they are not going to cause the KDE4 versions to be uninstalled (unless the KDE4 versions have lost their role as dependencies and are deinstalled by a
Re: Conflicts due to renamed KDE4 ports
Am 16.04.18 um 21:13 schrieb Tijl Coosemans: > On Mon, 16 Apr 2018 20:11:33 +0200 Stefan Esser wrote: >> 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. Seems that I misunderstood your reply ... Yes, adding -kde5 to all ports that have got origins previously used for KDE4 ports, and MOVED entries for those KDE4 ports would solve the issue. It would have helped, if either port origin or package name of the KDE4 ports had been kept, since that would have allowed to link the ports and packages over the change by the unchanged attribute. The absolute minimum would have been a complete set of "pkg set -o" commands to adjust the registered origins of all affected and installed KDE4 ports in an UPDATING entry. I'm not sure that poudriere can create packages that let pkg upgrade succeed without file conflicts, unless the relation is revealed by the MOVED entries. So, I agree with your proposal (previously also suggested by me) of MOVED entries for the KDE4 ports and new non-conflicting origins for those KDE5 ports that re-use the previous KDE4 origins (obviously without MOVED entries, but since the package names (without the version) remain unchanged for those KDE5 ports, automatic port and package upgrades can work for them. Regards, STefan
Re: [kde-freebsd] ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
Am 08.09.2013 08:14, schrieb O. Hartmann: > On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: > >> Synopsis: devel/qt4-script: >> /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is >> ambiguous >> >> State-Changed-From-To: open->patched State-Changed-By: rakuco >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 >> State-Changed-Why: I don't think the previous version worked. >> >> From your description, it looks like you've switched to building >> with libc++ whereas libstdc++ was being used before. >> >> The upcoming Qt 4.8.5 plus a few patches which only made it to >> 4.8.6 (but we've backported) will finally make Qt build with >> libc++. >> >> We've just sent an exp-run request for Qt 4.8.5, and will >> hopefully fix all these errors once it is committed. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > I build the world/kernel since early this year with > > CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= > -std=c++11 > > > in /etc/src.conf. I do not use those flags in /etc/make.conf! > /etc/src.conf is supposed to target ONLY the /usr/src world, not > the ports - this is as I interpret the man page for /etc/src.conf > and it would be logical. But this rule/thinking seems to be broken > by some includes from /usr/ports/Mk ingredients. There are ports that use bsd.prog.mk instead of the Makefile supplied with the source files. Just grep for bsd.port.mk in the port's "files" sub directory, if you find that /etc/src.conf settings affect a port. I think these ports are in violation of POLA and had a longer mail exchange with a port maintainer, who told me that use of bsd.prog.mk was the preferred method to build binaries on FreeBSD, for base and for ports. So no file under /usr/ports/Mk is to blame, but some ports do implicitly reference /etc/src.conf via their use of bsd.prog.mk. Regards, STefan NB: I just performed the grep suggested above and found that the following ports mention bsd.prog.mk in files/*: archivers/parchive archivers/pixz archivers/zipmix audio/id3v2 audio/mp3gain benchmarks/raidtest comms/mlan comms/mlan3 comms/obexapp converters/chmview converters/iconv devel/bcc devel/calibrator devel/frink devel/libpasori devel/linux_kdump devel/opencvs devel/qmake devel/qmake4 devel/ruby-byaccr dns/dnsreflector editors/fb editors/hexpert editors/tamago editors/tweak emulators/cpmtools finance/libstocks ftp/bsdftpd-ssl ftp/ftpsesame games/cre games/xroach graphics/exiftran graphics/s10sh japanese/edyvalue japanese/kon2-16dot japanese/man japanese/suicavalue mail/althea mail/archivesmtp mail/biffer mail/dma math/moo misc/cpuid misc/team net-mgmt/choparp net-mgmt/icmpquery net-mgmt/ipv6mon net/ifdepd net/openntpd net/packetdrill net/pcnfsd net/pppd23 net/pxe-pdhcp net/sharity-light net/skyfish palm/mdbconv print/epsonepl print/mup security/ipv6toolkit security/isakmpd security/openssh-askpass security/sst shells/nologinmsg shells/v7sh sysutils/bsdmoted sysutils/freqsdwn sysutils/jfbterm sysutils/sb16config sysutils/sbniconfig sysutils/setquota textproc/hhm textproc/wordnet www/http_get www/http_load www/http_post www/mathopd www/mohawk x11-wm/vtwm x11/gpctool x11/wmxss ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
