update_problem.txt (34.3 KB)
When I run urpmi --auto-update today, I get the messages listed in the attached file. Something is strange with the protobuf update.
I have put kdepim & akonadi into the skip.list.
Regards,
Chris
update_problem.txt (34.3 KB)
When I run urpmi --auto-update today, I get the messages listed in the attached file. Something is strange with the protobuf update.
I have put kdepim & akonadi into the skip.list.
Regards,
Chris
Yes, you are correct. It is being looked at and puzzled over. Will report more when I have it.
Thanks Ben
Nothing is strange. Just a normal procedure of up dating packages based on user request Issues · OpenMandrivaAssociation/distribution · GitHub
there are two packages that depends on protobuf:
clementine
qt5-qtwebengine
Both packages were rebuilded.
Damn, looks like old porotobuf were pulled in, rather than 3.3.2 version… investigating
It because the new protobuf devel packages doesn’t provide for pkgconfig() and devel() so rpmbuild selects form the old protobuf. I think it is due to the presence of javapackages_macros so I built protobuf without it (you may find this in my personal repo) however devel(*) provides are still missing. This is odd.
postedit:
$ urpmq --provides protobuf-devel
protobuf-devel: devel(libprotobuf(64bit))
protobuf-devel: devel(libprotoc(64bit))
protobuf-devel: lib64protobuf-devel[== 2.6.1-3:2015.0]
protobuf-devel: pkgconfig(protobuf)[== 2.6.1]
protobuf-devel: protobuf-devel[== 2.6.1-3:2015.0]
protobuf-devel: lib64protobuf-devel[== 3.3.2-1:2015.0]
protobuf-devel: protobuf-devel[== 3.3.2-1:2015.0]
Yes i’ve noticed this also.
Well this seems strange:
Finding Provides: /usr/lib/rpm/javapackages-tools.sh prov /builddir/build/BUILD 708 sed: couldn't write 111621 items to stdout: Broken pipe
Found the culprit. It was not needed macro in spec file
protobuf-3.3.2-2 still wants to install lib64kf5akonadicalendar5-16.04.3-1 which still creates a long list of KDE packages to remove. Strange as I don’t think lib64kf5akonadicalendar5-16.04.3-1 exists in repos?
This is no needed only if maven and osgi provides are added manually (as you did for protobuf) . It’s because I didn’t push my tests on official repo. I can’t understand why javapackages_macros behaves so I really hope next versions o javapackages will fix this.
Here is an example with protobuf-java-util:
$ rpm -qp --provides Downloads/protobuf-java-util-3.3.2-1-omv3001.noarch.rpm
mvn(com.google.protobuf:protobuf-java-util) = 3.3.2
mvn(com.google.protobuf:protobuf-java-util:pom:) = 3.3.2
osgi(com.google.protobuf.util) = 3.3.2
protobuf-java-util = 3.3.2-1:3001
$ rpm -qp --provides Downloads/protobuf-java-util-3.3.2-2-omv2015.0.noarch.rpm
protobuf-java-util = 3.3.2-2:2015.0
This is false positive, as couple of packages needs a rebuild for new protobuf.
Ah, OK, so I be patient and it will all work out.
Anyway thanks @TPG for your work on this and other things like Firefox/Rust/Cargo you must be tired.
Now problem is to build firefox on 3.0
Well I’m impressed with how much work has been done since we found out about the issue with libfreetype. The Lx 3.03 release is looking stronger than ever to me.
I hope I can find a way to let our user base know how much @TPG and @Colin have done to make this happen in the last 10 days. A ton of excellent work. Much appreciated here.
Yes it is fixed.
Thanks for your help.
Everything working here. Thanks all.