Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Patrick McLean]

On Mon, 1 Mar 2021 22:54:45 -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.
> 
> 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).
> 
Excellent, this will eliminate one source of annoyance with our
workflow. Perhaps we should document this in the wiki:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow

That way new developers, or developers setting up a new machine will
have instructions on setting this up.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Matt Turner]

On Tue, Mar 2, 2021 at 3:12 PM Michael Orlitzky  wrote:
>
> On Tue, 2021-03-02 at 14:02 -0500, Matt Turner wrote:
> > On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky  wrote:
> > > 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?
> >
> > Why don't we change 30 thousand ebuilds rather than use this script?
> >
>
> If we're going to enforce a format, it makes more sense to sed things
> into the easy format once than it does to leave things in the hard
> format forever and maintain a custom tool that makes the hard format
> more like the easy format.

Sorry, I'm not interested in engaging on this topic. Please start a new thread.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Matt Turner]

On Tue, Mar 2, 2021 at 2:36 PM Alessandro Barbieri
 wrote:
>
> Il Mar 2 Mar 2021, 20:03 Matt Turner  ha scritto:
>>
>> On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky  wrote:
>> > 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?
>>
>> Why don't we change 30 thousand ebuilds rather than use this script?
>
>
> IMO before this the keyword mechanism should be reworked to be three-state:
> 1 Arch known working
> 2 Arch known not working
> 3 Arch untested/status unknown
>
> And let the user choose to use packages from 3 or not

Are you actually replying to me? I was restating mjo's question to
demonstrate the absurdity, not suggesting a different course of
action.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Michał Górny]

On Tue, 2021-03-02 at 15:16 -0500, Michael Orlitzky wrote:
> On Tue, 2021-03-02 at 20:42 +0100, Michał Górny wrote:
> > 
> > Are you volunteering to fix all the tools to support the new format
> > correctly?
> > 
> 
> When you already spend all day fixing other peoples' software, this
> doesn't sound that scary.
> 
> The PMS says that KEYWORDS is whitespace-separated. Probably only
> repoman/pkgcheck would require trivial changes. Anything not enforcing
> ::gentoo policy should (ha ha) already support the PMS format.

Thank you for your detailed research.  However, you seem to have missed
ekeyword and nattka.  And the fact that we still don't have a proper
bash parsing library that could reliably edit complex bash in ebuilds.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Michael Orlitzky]

On Tue, 2021-03-02 at 20:42 +0100, Michał Górny wrote:
> 
> Are you volunteering to fix all the tools to support the new format
> correctly?
> 

When you already spend all day fixing other peoples' software, this
doesn't sound that scary.

The PMS says that KEYWORDS is whitespace-separated. Probably only
repoman/pkgcheck would require trivial changes. Anything not enforcing
::gentoo policy should (ha ha) already support the PMS format.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Michael Orlitzky]

On Tue, 2021-03-02 at 14:02 -0500, Matt Turner wrote:
> On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky  wrote:
> > 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?
> 
> Why don't we change 30 thousand ebuilds rather than use this script?
> 

If we're going to enforce a format, it makes more sense to sed things
into the easy format once than it does to leave things in the hard
format forever and maintain a custom tool that makes the hard format
more like the easy format.

With everything currently on one line, QA could easy change them all at
once in one big commit.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Michał Górny]

On Tue, 2021-03-02 at 00:10 -0500, 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?

Are you volunteering to fix all the tools to support the new format
correctly?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Brian Evans]

On 3/2/2021 2:36 PM, Alessandro Barbieri wrote:
Il Mar 2 Mar 2021, 20:03 Matt Turner > ha scritto:


On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky mailto:m...@gentoo.org>> wrote:
 >                                 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?

Why don't we change 30 thousand ebuilds rather than use this script?


IMO before this the keyword mechanism should be reworked to be three-state:
1 Arch known working
2 Arch known not working
3 Arch untested/status unknown

And let the user choose to use packages from 3 or not

This is how it already is.  1 and 3 are common but 2 is uncommon except 
for binary only packages.


Brian



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Alessandro Barbieri]

Il Mar 2 Mar 2021, 20:03 Matt Turner  ha scritto:

> On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky  wrote:
> > 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?
>
> Why don't we change 30 thousand ebuilds rather than use this script?
>

IMO before this the keyword mechanism should be reworked to be three-state:
1 Arch known working
2 Arch known not working
3 Arch untested/status unknown

And let the user choose to use packages from 3 or not

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Matt Turner]

On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky  wrote:
> 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?

Why don't we change 30 thousand ebuilds rather than use this script?

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Matt Turner]

On Tue, Mar 2, 2021 at 6:11 AM Wolfgang E. Sanyer
 wrote:
> Git diff has --color-word, doesn't this suggest that it has the capability of 
> identifying these word-by-word changes?

No, git diff has that feature. That doesn't imply that the default
merge driver has that feature.

> Is there perhaps a merge option that is being overlooked?

At least not one the upstream git developers know about. (I asked)

Re: [gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch

[Ultrabug]

On 02/03/2021 16:05, Michał Górny wrote:

Hi,



Hi



I don't really want to remove it entirely or revert all the work we've
put into testing packages with it -- but I think we should move it to
~arch at the very least.

WDYT?



I agree with you, I'd drop it back to ~arch too.

Thanks for your work on keeping pypy up.

[gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch

[Michał Górny]

Hi,

I think I've made a mistake by stabilizing PyPy(3), and I would like to
drop it back to ~arch (and stable-mask the relevant flags).

Roughly, there are 4 problems with it:

1. The current stable (both Gentoo and upstream) is PyPy3.6 that is
equivalent to CPython 3.6.  Yes, the one we removed already.  People
using this version are already hitting issues because of upstreams
dropping py3.6 support or us failing to provide proper compatibility.

2. The next branch, PyPy3.7 is still in alpha state upstream.  It has
a few major bugs, e.g. the regex engine is sometimes slightly broken. 
The stdlib tests are mostly broken (compared to moderately broken
in 3.6).

3. To the best of my knowledge, there's no work hapenning to have
PyPy3.8, so it will keep being behind CPython.

4. PyPy upstream doesn't merge CPython stdlib changes timely, nor takes
care of vulnerabilities inherited from CPython.

5. PyPy3 doesn't give the same ABI stability guarantees as CPython,
and our choice not to slot between PyPy3 versions doesn't help (and it's
not worth changing considering all the other points).  Upgrading PyPy3
involves intermittent breakage, and people using it with Portage (which
is my fault) experience fatal breakage.


Honestly, I've tried to improve PyPy in the past but I don't really have
time or motivation to do this continuously.  PyPy is an interesting
project, and it has its isolated uses.  However, I don't think it's
ready as a general-purpose Python interpreter for production
environments.

I don't really want to remove it entirely or revert all the work we've
put into testing packages with it -- but I think we should move it to
~arch at the very least.

WDYT?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

[Wolfgang E. Sanyer]

Git diff has --color-word, doesn't this suggest that it has the capability
of identifying these word-by-word changes?

Is there perhaps a merge option that is being overlooked?

El mar., 2 de marzo de 2021 12:21 a. m., Sam James 
escribió:

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

[gentoo-dev] Package up for grabs: dev-python/python-backoff

[Zac Medico]

We have and ebuild for this package up for grabs:

https://pypi.org/project/backoff/

No open bugs and no reverse dependencies:

https://bugs.gentoo.org/buglist.cgi?quicksearch=python-backoff
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature