Problems with updating protobuf

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

1 Like

Yes, you are correct. It is being looked at and puzzled over. Will report more when I have it.

Thanks Ben

1 Like

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.

1 Like

Damn, looks like old porotobuf were pulled in, rather than 3.3.2 version… investigating

1 Like

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]
1 Like

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
1 Like

Found the culprit. It was not needed macro in spec file

2 Likes

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) :dizzy_face:. 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 :slight_smile:

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.

2 Likes

This certainly appears fixed now here. Again thanks @TPG.

1 Like

Yes it is fixed.
Thanks for your help.

Everything working here. Thanks all.

1 Like