Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...
> On 2 Mar 2021, at 05:10, Michael Orlitzky wrote: > > On Mon, 2021-03-01 at 22:54 -0500, Matt Turner wrote: >> tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, >> called merge-driver-ekeyword that can automatically resolve git merge >> conflicts involving the KEYWORDS=... line in ebuilds. >> >> Since the KEYWORDS=... assignment is a single line, > > Is that enforced? If not, will the merge driver handle other formats > correctly? And if it is... why don't we just enforce putting each > keyword on a separate line instead, so that we don't have this problem > in the first place? Yeah, it’s policy: https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0105. I also removed all of the trivial infringers not long ago: https://github.com/gentoo/gentoo/pull/19467. There aren’t many left. Anyway, yes, the format is still a pain because diff doesn’t handle it well. But I don’t really want to see ebuilds become longer... sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...
On Mon, 2021-03-01 at 22:54 -0500, Matt Turner wrote: > tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, > called merge-driver-ekeyword that can automatically resolve git merge > conflicts involving the KEYWORDS=... line in ebuilds. > > Since the KEYWORDS=... assignment is a single line, Is that enforced? If not, will the merge driver handle other formats correctly? And if it is... why don't we just enforce putting each keyword on a separate line instead, so that we don't have this problem in the first place?
[gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...
tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, called merge-driver-ekeyword that can automatically resolve git merge conflicts involving the KEYWORDS=... line in ebuilds. Since the KEYWORDS=... assignment is a single line, git struggles to handle conflicts. When rebasing a series of commits that modify the KEYWORDS=... it's usually easier to throw them away and reapply on the new tree than it is to manually handle conflicts during the rebase. git allows a 'merge driver' program to handle conflicts; this program handles conflicts in the KEYWORDS=... assignment. E.g., given an ebuild with these keywords: KEYWORDS="~alpha amd64 arm arm64 ~hppa ppc ppc64 x86" One developer drops the ~alpha keyword and pushes to gentoo.git, and another developer stabilizes hppa. Without this merge driver, git requires the second developer to manually resolve the conflict which is tedious and prone to mistakes when rebasing a long series of patches. With the custom merge driver, it automatically resolves the conflict. To use the merge driver, configure your gentoo.git as such: gentoo.git/.git/config: [merge "keywords"] name = KEYWORDS merge driver driver = merge-driver-ekeyword %O %A %B %P gentoo.git/.git/info/attributes: *.ebuild merge=keywords With that configured, git merge conflicts on the KEYWORDS=... line will be resolved automatically (e.g. during git pull --rebase). Enjoy! signature.asc Description: PGP signature
[gentoo-dev] Last rites: games-strategy/0ad-data
# Sam James (2021-02-28) # games-strategy/0ad-data has been merged # into games-strategy/0ad for simplicity. # Note that in most cases, the latter uses # upstream pre-built assets anyway. # Nothing should really be using this. # bug #735352, bug #768930 # Removal in 14 days. games-strategy/0ad-data signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Non-maintainer commits and CI
> On 7 Jan 2021, at 14:28, Agostino Sarubbo wrote: > > Hello, > > it happens frequently that CI discovers failure(s) in non-maintainer commits. > > The most striking examples are maintainer-needed, proxy-maint and general pull > request where who made the change has no visibility on the new bug. > > Do you think that is a good idea to CC everyone involved in the commit? > Hi all, Following up on this, ago has implemented this after I brought it up to him - thank you ago! The committer will be CCed on bugs and upon requests this can be disabled where maintainer is a member of a project alias (to avoid receive mail from both herd and CC). If needed, we could revisit this and turn it into a whitelist or something, but for now, the aim is to just blacklist “alive” projects where people read the alias. Best, Sam signature.asc Description: Message signed with OpenPGP
[gentoo-portage-dev] [PATCH] emerge: make --binpkg-respect-use=y imply --autounmask-use=n
If --binpkg-respect-use=y is given explicitly, then it implies
--autounmask-use=n, because these options naturally oppose
eachother.
Bug: https://bugs.gentoo.org/773469
Signed-off-by: Zac Medico
---
lib/_emerge/create_depgraph_params.py | 22 ++---
lib/portage/tests/resolver/test_useflags.py | 20 +--
man/emerge.1| 11 +++
3 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/lib/_emerge/create_depgraph_params.py
b/lib/_emerge/create_depgraph_params.py
index 25dd2a1b4..267600fb6 100644
--- a/lib/_emerge/create_depgraph_params.py
+++ b/lib/_emerge/create_depgraph_params.py
@@ -41,12 +41,22 @@ def create_depgraph_params(myopts, myaction):
# binpkg_changed_deps: reject binary packages with outdated deps
myparams = {"recurse" : True}
+ binpkg_respect_use = myopts.get("--binpkg-respect-use")
+ if binpkg_respect_use is not None:
+ myparams["binpkg_respect_use"] = binpkg_respect_use
+ elif "--usepkgonly" not in myopts:
+ # If --binpkg-respect-use is not explicitly specified, we enable
+ # the behavior automatically (like requested in bug #297549), as
+ # long as it doesn't strongly conflict with other options that
+ # have been specified.
+ myparams["binpkg_respect_use"] = "auto"
+
autounmask_keep_keywords = myopts.get("--autounmask-keep-keywords")
autounmask_keep_masks = myopts.get("--autounmask-keep-masks")
autounmask = myopts.get("--autounmask")
autounmask_license = myopts.get('--autounmask-license', 'y' if
autounmask is True else 'n')
- autounmask_use = myopts.get('--autounmask-use')
+ autounmask_use = 'n' if myparams.get('binpkg_respect_use') == 'y' else
myopts.get('--autounmask-use')
if autounmask == 'n':
autounmask = False
else:
@@ -153,16 +163,6 @@ def create_depgraph_params(myopts, myaction):
'--update' in myopts:
myparams['rebuilt_binaries'] = True
- binpkg_respect_use = myopts.get('--binpkg-respect-use')
- if binpkg_respect_use is not None:
- myparams['binpkg_respect_use'] = binpkg_respect_use
- elif '--usepkgonly' not in myopts:
- # If --binpkg-respect-use is not explicitly specified, we enable
- # the behavior automatically (like requested in bug #297549), as
- # long as it doesn't strongly conflict with other options that
- # have been specified.
- myparams['binpkg_respect_use'] = 'auto'
-
binpkg_changed_deps = myopts.get('--binpkg-changed-deps')
if binpkg_changed_deps is not None:
myparams['binpkg_changed_deps'] = binpkg_changed_deps
diff --git a/lib/portage/tests/resolver/test_useflags.py
b/lib/portage/tests/resolver/test_useflags.py
index d66da0866..b799e62ff 100644
--- a/lib/portage/tests/resolver/test_useflags.py
+++ b/lib/portage/tests/resolver/test_useflags.py
@@ -46,15 +46,23 @@ class UseFlagsTestCase(TestCase):
success = True,
mergelist = ["dev-libs/A-1"]),
- # In the unit test case for bug 773469, the
--autounmask-backtrack option
- # is needed in order to trigger the
--binpkg-respect-use=y behavior that
- # appears confusingly similar to --binpkg-respect-use=n
behavior.
+ # For bug 773469, we wanted --binpkg-respect-use=y to
trigger a
+ # slot collision. Instead, a combination of default
--autounmask-use
+ # combined with --autounmask-backtrack=y from
EMERGE_DEFAULT_OPTS
+ # triggered this behavior which appeared confusingly
similar to
+ #--binpkg-respect-use=n behavior.
+ #ResolverPlaygroundTestCase(
+ # ["dev-libs/C", "dev-libs/D"],
+ # options={"--usepkg": True,
"--binpkg-respect-use": "y", "--autounmask-backtrack": "y"},
+ # success=True,
+ # use_changes={"dev-libs/C-1": {"abi_x86_32":
True}},
+ # mergelist=["[binary]dev-libs/C-1",
"[binary]dev-libs/D-1"],
ResolverPlaygroundTestCase(
["dev-libs/C", "dev-libs/D"],
options={"--usepkg": True,
"--binpkg-respect-use": "y", "--autounmask-backtrack": "y"},
- success=True,
- use_changes={"dev-libs/C-1": {"abi_x86_32":
True}},
- mergelist=["[binary]dev-libs/C-1",
"[binary]dev-libs/D-1"],
+ success=False,
+
