Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 679386 - dev-util/catalyst: Patches to fix a few items
Summary: dev-util/catalyst: Patches to fix a few items
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Catalyst Developers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 434268
  Show dependency tree
 
Reported: 2019-03-04 06:50 UTC by Joshua Kinard
Modified: 2019-05-04 18:41 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Remove MIPS R10K subarch (catalyst-3.0.4-remove-r10k-bits.patch,1.90 KB, patch)
2019-03-04 06:50 UTC, Joshua Kinard
Details | Diff
Add missing stage3 override functions (catalyst-3.0.4-fix-stage3-overrides.patch,1.05 KB, patch)
2019-03-04 06:51 UTC, Joshua Kinard
Details | Diff
Add missing ASFLAGS override functions (catalyst-3.0.4-add-missing-asflags-overrides.patch,1.88 KB, patch)
2019-03-04 06:52 UTC, Joshua Kinard
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Kinard gentoo-dev 2019-03-04 06:50:34 UTC
Created attachment 567718 [details, diff]
Remove MIPS R10K subarch

Attaching a few patches to fix some things in dev-util/catalyst-3.0.x:

- catalyst-3.0.4-remove-r10k-bits.patch
Removes the MIPS R10K subarch definitions, as they are no longer needed.  A few years ago, gcc-upstream decided to make -march=r10000 the default for the MIPS-IV ISA, thus building with a "mips4" subarch is the same now as using the R10K subarchs.
Comment 1 Joshua Kinard gentoo-dev 2019-03-04 06:51:18 UTC
Created attachment 567720 [details, diff]
Add missing stage3 override functions

- catalyst-3.0.4-fix-stage3-overrides.oatch
Adds the missing *_override functions in catalyst/targets/stage3.py.  As noted by the XXX comments in the stage1/stage2 target modules, these may be redundant.  However, until the class hierarchy issue in catalyst is sorted out, that would permit the versions in stagebase.py to cover all the stage-specific modules, we need these overrides in place to avoid issues in stage3.  This is a blocker for Bug #434628 (which I think is reporting this very issue).
Comment 2 Joshua Kinard gentoo-dev 2019-03-04 06:52:09 UTC
Created attachment 567722 [details, diff]
Add missing ASFLAGS override functions

- catalyst-3.0.4-add-missing-asflags-overrides.patch
Adds the missing "asflag_override" functions in catalyst/targets/stage{1,2,3}.py, which is needed to properly support defining specific ASFLAGS for each stage build.  Partial support for defining ASFLAGS already exists, but will not work without these missing overrides as a short-term fix until the class hierarchy mess is sorted.
Comment 3 Joshua Kinard gentoo-dev 2019-03-04 06:52:53 UTC
(In reply to Joshua Kinard from comment #1)
> Created attachment 567720 [details, diff] [details, diff]
> Add missing stage3 override functions
> 
> - catalyst-3.0.4-fix-stage3-overrides.oatch
> Adds the missing *_override functions in catalyst/targets/stage3.py.  As
> noted by the XXX comments in the stage1/stage2 target modules, these may be
> redundant.  However, until the class hierarchy issue in catalyst is sorted
> out, that would permit the versions in stagebase.py to cover all the
> stage-specific modules, we need these overrides in place to avoid issues in
> stage3.  This is a blocker for Bug #434628 (which I think is reporting this
> very issue).

Typo, I meant Bug #434268
Comment 4 Brian Dolbec gentoo-dev 2019-03-04 07:53:06 UTC
quote:

"... until the class hierarchy mess is sorted."

What do you mean by that?


Rather than adding the same override functions to each stage, why not just merge them into the stagebase functions to use either the make.conf or spec file supplied override setting?   Are these overrides bad for any other target stages?
Comment 5 Joshua Kinard gentoo-dev 2019-03-04 08:44:58 UTC
(In reply to Brian Dolbec from comment #4)
> quote:
> 
> "... until the class hierarchy mess is sorted."
> 
> What do you mean by that?
> 
> 
> Rather than adding the same override functions to each stage, why not just
> merge them into the stagebase functions to use either the make.conf or spec
> file supplied override setting?   Are these overrides bad for any other
> target stages?

My assumption is the way catalyst2 did things is still not sorted out, given the XXX comment(s) in stage1/stage2 target modules.  The preferred outcome would be to have the override functions in stagebase.py be the sole copies and reduce code duplication.  But the comment indicates the overrides are still needed in the stage target modules.  As such, my patches are basically just ports of what I have been using in catalyst-2.0.18-r4 for the last two years.

And these changes don't add any specific ovverides themselves.  They enable overrides to be set in a spec file and carried into the chroot's make.conf.  Without them, ASFLAGS is completely ignored, and stage3 won't honor CHOST, which *does* cause problems on mips, as well as ignoring CFLAGS and other variables, which further breaks things.

I'm not looking to try to rewrite the logic right now (tempting, however), due to lack of time.  I've been using catalyst2 for the last few stage run attempts since ~2017, and got most of the bugs in the mips stuff sorted out (I think).  So now to move to catalyst3 to make sure that works.  Still have to hack out the asciidoc stuff due to a python2.7/python3.7 conflict (blame dev-libs/glib-utils), but that patch is local to my setup.