Bug 1204608 - Fedora build target reports stale unfulfilled requirements for mesa-libGL
Summary: Fedora build target reports stale unfulfilled requirements for mesa-libGL
Status: REOPENED
Alias: None
Product: openSUSE.org
Classification: openSUSE
Component: BuildService (show other bugs)
Version: unspecified
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Marco Strigl
QA Contact: Adrian Schröter
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-23 18:11 UTC by Elmar Stellnberger
Modified: 2022-11-02 05:33 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elmar Stellnberger 2022-10-23 18:11:49 UTC
package where this is being observed: https://build.opensuse.org/package/show/home:estellnb:mageiaupdtst/mesa

It reports unfulfilled requirements trying to install mesa-libGL for Fedora36 and Fedora35. I have installed the same system here in a chroot, namely Fedora36 x86_64 and here it installed mesa-libGL without any problem. One of the dependencies reported as unfulfilled is "glx". However an "rpm -q --whatprovides glx" has reported nothing provides glx, although mesa-libGL was installed here. Either the dependencies do not come from mesa-libGL as claimed or the same package has other and/or wrong dependencies in the obs version of Fedora36. Strange also that a few minutes ago all the build targets of mesa-22.2 did compile well while I can not remember having changed anything about a BuildRequires tag.
Comment 1 Adrian Schröter 2022-10-24 09:01:52 UTC
this dependency comes from the packages you build in your own project. You need to fix the dependencies there.

You may need to wipe the existing binaries to get building using

 # osc wipebinaries

command
Comment 2 Elmar Stellnberger 2022-10-24 09:16:27 UTC
Hmm, I did not know that a package uses its own repository as a source which constitutes a circular dependency.
> osc wipebinaries --all
has trigger a rebuild for Fedora35 and Fedora36 i686 but did not seem to work for Fedora36 x86_64. Thus I had tried:

> osc wipebinaries --all home:estellnb:mageiaupdtst -M mesa                                                                                 
Traceback (most recent call last):                                                                                                                                                    
  File "/bin/osc", line 45, in <module>                                                                                                                                               
    r = babysitter.run(osccli)                                                                                                                                                        
  File "/usr/lib/python3.8/site-packages/osc/babysitter.py", line 67, in run                                                                                                          
    return prg.main(argv)                                                                                                                                                             
  File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 347, in main                                                                                           0,0-1         All
    return self.cmd(args)
  File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 370, in cmd
    retval = self.onecmd(argv)
  File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 504, in onecmd
    return self._dispatch_cmd(handler, argv)
  File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 1235, in _dispatch_cmd
    return handler(argv[0], opts, *args)
  File "/usr/lib/python3.8/site-packages/osc/commandline.py", line 7431, in do_wipebinaries
    packages.append(package + ":" + subpackage)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

  Looks like a bug to me.
Comment 3 Elmar Stellnberger 2022-10-24 15:01:54 UTC
May I reopend this report because of the -M switch?
Comment 4 Adrian Schröter 2022-10-25 05:23:53 UTC
it is in any case also a bad usage as you provide a flavor for a package, but not the package name itself.

Yes, should not crash, but it can not work.
Comment 5 Elmar Stellnberger 2022-10-25 09:08:40 UTC
  Ahh, the package does not have flavours. I was using -M because --all did not delete the i586 arch for Fedora if I remember it correctly. The following command did now what I wanted to do:

osc wipebinaries -a i586 -r Fedora_36 home:estellnb:mageiaupdtst mesa

  If mesa isn´t a multibuild package I´d still adore to know what a multibuild package is?