Call for fixing packages from mass rebuild

Development Cooker (development)
1

Hi,

we are getting closer to 4.0 release. One task is left, a fixing failed packages from last mass rebuild for i686, x86_64 and znver1 architectures.

Here is the list. If you fixed one of them please remove it from the list:
https://pad.openmandriva.org/p/failed_buildlists

2 Likes
2

I’ve built a script that automatically detects packages that have been fixed already (and also labels common errors in packages that still need to be fixed).
The script is still running, so as of right now this isn’t a complete list - but it should be complete (and auto-updating) soon.
http://lindev.ch/massbuild.html

3 Likes
3

OK, I suspect for most of us there needs to be some training and education before we can help. What specifically do we look for? And how do we fix a given problem? Or are there other things we can do like put certain packages in a queue catagory to be fixed as a group or something along these lines? I’m short on specifics on this until I know more but I would like to know more.

Given some instruction so I have a little more knowledge I am willing to help.

:monkey:

It would seem that doing this could/should also be a beginning for developers to start teaching those of us willing to help how to do some of the more basic, easier tasks of package management thus freeing developers for the more grand things you are all capable of? That’s my theory anyway.

4

Post-edit: This is jovie for znver1 arch: https://abf.openmandriva.org/build_lists/193389

For instance I look at the list @bero provided and selected jovie at random. Don’t see anything in the build.log but in the root.log I see:

DEBUG util.py:497:  BUILDSTDERR: Error: 
DEBUG util.py:497:  BUILDSTDERR:  Problem: conflicting requests
DEBUG util.py:497:  BUILDSTDERR:   - nothing provides devel(libstdc++(64bit)) needed by kdelibs-devel-5:4.14.33-1.x86_64
DEBUG util.py:497:  BUILDSTDERR:   - nothing provides devel(libphonon(64bit)) needed by kdelibs-devel-5:4.14.33-1.x86_64
DEBUG util.py:497:  BUILDSTDERR:   - nothing provides devel(libattica(64bit)) needed by kdelibs-devel-5:4.14.33-1.x86_64
DEBUG util.py:497:  BUILDSTDERR:   - nothing provides devel(libdbusmenu-qt(64bit)) needed by kdelibs-devel-5:4.14.33-1.x86_64
DEBUG util.py:497:  BUILDSTDERR:   - nothing provides devel(libqca(64bit)) needed by kdelibs-devel-5:4.14.33-1.x86_64
DEBUG util.py:640:  Child return code was: 1
DEBUG util.py:234:  kill orphans

Is this the cause of the build failure or a partial cause? In either case what do I do next? Or is there more I need to do to be sure I really have the correct cause?

:hear_no_evil: :see_no_evil: :speak_no_evil:

Post-edit: I do have Github and ABF accounts but I would like to learn how to do some things that help with package management. This seems like an ideal time to do so.

5

Hey.

Maybe I’m not the best person to answer this question, but I’ll try.
If I say something wrong - please correct me :grinning:

Yes, that’s the reason of build failure and at least the first we encountered.
So to move forward you must first fix it.

So we see that the reason is: kdelibs-devel - which must be rebuilt first.
So before we start building our package JOVIE, we must first deal with kdelibs.

Now we need to go to kdelibs and check what wrong with it and then fix it.
When kdelibs build fine, then back to JOVIE and rebuild it again and and pray for no more problems :grinning:

3 Likes
6

Thanks, that all makes sense to me. And honestly I hadn’t thought it through that far because at this time I don’t know what to do when I get to the root cause which in this case appears like it is going to be whatever is failing kdelibs-devel.

And part of that is told in the jovie root.log because those dependencies are listed and needed by kdelibs-devel. But there may be more.

Observation: Finding a specific package in that list is a lot like hard work. Maybe because it won’t have that name in the list? Maybe it would be either kdelibs or kdelibs4support. kdelibs4support I’m guessing.

If it is kdelibs4support then maybe this is why kdelibs4support is busted all to heck:

kdelibs4support-busted-all-to heck.txt (1.3 KB)

7

Everything you’re saying is correct, just a couple of extra things to add:

  • devel(SOMETHING) dependencies are something rpm 5 generated but rpm 4 doesn’t. Anything requiring devel(*) simply needs to be rebuilt to get rid of that dependency. This will automatically be solved in the next stage of the mass build.
  • kdelibs is from KDE4 and will be removed (or at the very least moved to contrib). If anything still requires it, we should update it if possible, or look into replacing it with something similar if it still hasn’t been updated to KDE5 4 years after its release.
  • Don’t worry about errors you can’t fix (ask someone here or on irc to help) – detecting what’s going on requires experience more than anything. Keep trying, you’ll figure it out at some point.
2 Likes
8

kdelibs4support simply needs a rebuild – the error there means that the build order wasn’t right, someone tried to update kdelibs4support to 5.48 before updating kcompletion to 5.48.
In the mean time, kcompletion has already been updated to 5.48, so another attempt at building kdelibs4support will succeed (or fail with a completely different error).

1 Like
9

Thanks @bero and @AngryPenguin , this is giving me a bit more to work with.

10

New repoclosure report based on DNF is available
http://repoclosure.openmandriva.org/

For now only for cooker main repository for all architectures

1 Like