Solved Plasma5 build anomaly

Argentum

Well-Known Member

Reaction score: 230
Messages: 487

Hello,

I have tried to upgrade plasma5 from ports (on 2 separate machines). It ends like this:

Code:
===> Fetching all distfiles required by plasma5-kwin-5.22.0 for building
===>  Extracting for plasma5-kwin-5.22.0
=> SHA256 Checksum OK for KDE/plasma/5.22.0/kwin-5.22.0.tar.xz.
===>  Patching for plasma5-kwin-5.22.0
===>  Applying FreeBSD patches for plasma5-kwin-5.22.0 from /usr/ports/x11-wm/plasma5-kwin/files
File to patch:

Asking file name to patch. I have never seen this before. Pressing enter and Y, the build fails.

Code:
2 out of 2 hunks ignored--saving rejects to Oops.rej
===>  FAILED Applying FreeBSD patch-git-425170b7814c1ff27b165982b93d78422621bddb
===> Cleanly applied FreeBSD patch(es)  patch-cmake_modules_Findhwdata.cmake
===> FAILED to apply cleanly FreeBSD patch(es)  patch-git-425170b7814c1ff27b165982b93d78422621bddb
*** Error code 1

Stop.
...

Any ideas?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 11,983
Messages: 38,438

Looks like your ports tree wasn't updated correctly and you have some left-over patch files in x11-wm/plasma5-kwin that should have been removed and/or updated.
 
OP
Argentum

Argentum

Well-Known Member

Reaction score: 230
Messages: 487

This is strange - I have upgraded the ports tree with gitup ports -v .
and after that trying

Code:
root@CUPRUM /u/p/x/plasma5-kwin# pwd
/usr/ports/x11-wm/plasma5-kwin
root@CUPRUM /u/p/x/plasma5-kwin# make clean
===>  Cleaning for plasma5-kwin-5.22.0
root@CUPRUM /u/p/x/plasma5-kwin# make
===>  License GPLv2 accepted by the user
===>   plasma5-kwin-5.22.0 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by plasma5-kwin-5.22.0 for building
===>  Extracting for plasma5-kwin-5.22.0
=> SHA256 Checksum OK for KDE/plasma/5.22.0/kwin-5.22.0.tar.xz.
===>  Patching for plasma5-kwin-5.22.0
===>  Applying FreeBSD patches for plasma5-kwin-5.22.0 from /usr/ports/x11-wm/plasma5-kwin/files
File to patch:
 
OP
Argentum

Argentum

Well-Known Member

Reaction score: 230
Messages: 487

Good thing I saw this... I'm waiting for KF5 5.83 to land in ports. I was planning to use portsnap do my updating, as per info in the Handbook.

Actually - breaking news: A little over an hour ago, a bugfix was committed to ports by Tobias Berner, so now it's 5.22.1!
Unfortunately this did not help:

Code:
root@Tuna2 /u/p/x/plasma5-libkscreen# make
===>  License LGPL20 accepted by the user
===>   plasma5-libkscreen-5.22.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by plasma5-libkscreen-5.22.1 for building
===>  Extracting for plasma5-libkscreen-5.22.1
=> SHA256 Checksum OK for KDE/plasma/5.22.1/libkscreen-5.22.1.tar.xz.
===>  Patching for plasma5-libkscreen-5.22.1
===>  Applying FreeBSD patches for plasma5-libkscreen-5.22.1 from /usr/ports/x11/plasma5-libkscreen/files
1 out of 1 hunks failed--saving rejects to src/CMakeLists.txt.rej
===>  FAILED Applying FreeBSD patch-src_CMakeLists.txt
===> Cleanly applied FreeBSD patch(es)  patch-backends_CMakeLists.txt
===> FAILED to apply cleanly FreeBSD patch(es)  patch-src_CMakeLists.txt
*** Error code 1

Stop.
make: stopped in /usr/ports/x11/plasma5-libkscreen
 
OP
Argentum

Argentum

Well-Known Member

Reaction score: 230
Messages: 487

Solved the problem by removing the port directory and running gitup ports -v 1 again.

But that rises a question - why did not the gitup update all necessary (patch) files automatically?
 

astyle

Aspiring Daemon

Reaction score: 353
Messages: 819

Solved the problem by removing the port directory and running gitup ports -v 1 again.

But that rises a question - why did not the gitup update all necessary (patch) files automatically?
Because Cron did not tell it to. Computers are pretty lazy that way, you have to order them around and micromanage them every single step of the way. ;)
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 11,983
Messages: 38,438

Sometimes when a port is updated a patch file was not removed when it should be, or a patch file didn't get updated. This doesn't happen very often though and is usually resolved fairly quickly. But it's good to double check.

Always compare your local copy of the port with what's on https://cgit.freebsd.org/ports/. Compare it with your local copy. In this case it was fairly obvious the latest update to this port removed a couple of patch files and those were still left in your local copy causing them to get applied during the build.
 
OP
Argentum

Argentum

Well-Known Member

Reaction score: 230
Messages: 487

Because Cron did not tell it to. Computers are pretty lazy that way, you have to order them around and micromanage them every single step of the way. ;)
No. I am running gitup manually.
 
OP
Argentum

Argentum

Well-Known Member

Reaction score: 230
Messages: 487

Sometimes when a port is updated a patch file was not removed when it should be, or a patch file didn't get updated. This doesn't happen very often though and is usually resolved fairly quickly. But it's good to double check.
I see.
Always compare your local copy of the port with what's on https://cgit.freebsd.org/ports/. Compare it with your local copy. In this case it was fairly obvious the latest update to this port removed a couple of patch files and those were still left in your local copy causing them to get applied during the build.
I am running gitup ports always before any upgrade in ports. So the tree should be the latest.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 11,983
Messages: 38,438

Sure but the tool you use to update your local copy could have made an error (for whatever reason). That's why checking with the actual upstream version is useful.
 
OP
Argentum

Argentum

Well-Known Member

Reaction score: 230
Messages: 487

Sure but the tool you use to update your local copy could have made an error (for whatever reason). That's why checking with the actual upstream version is useful.
Just started thinking that new version of net/gitup has caused this. Never seen that before (with portsnap or the previous gitup version).
 
Top