Re: [gentoo-dev] Package up for grabs: net-vpn/libreswan

[Hans de Graaff]

On Sun, 2017-05-07 at 15:28 -0400, Mike Gilbert wrote:
> I used to use this package for an IPSec/L2TP VPN to my office, but we
> migrated onto Cisco AnyConnect. I now use net-vpn/openconnect
> regularly and have not been able to test libreswan since the switch.
> 
> libreswan has no open bugs, but there is a pending version bump
> (3.20).

It looks like there are no other takers so I'll reluctantly take this
since we're using it at work to manage VPN connections.

Hans

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Kristian Fiskerstrand]

On 05/20/2017 12:43 AM, Kent Fredric wrote:
> ef2b2458815ba4e4694e0d5f3bbce239505ffbc8 - 2015-12-20
> 
> Idella4's last commit on this package.
> 
> 3d70356565d3213c370e1f64a85b55c3ded259f5 - 2016-01-06
> 
> Patricks first direct commit to this package.
> 
> <>
> 
> e6175815b5792f09acd90627af5fe23f616ad245 - 2016-09-02
> 
> Patrick adds himself and Tomas, and removes Proxy Maint.
> 
> ^^^ 
> 
> This last commit is, as I understand, where most this conflict comes
> from.

fwiw, Thomas explicitly requested proxy-maint to stay on as maintainer
at this point. "Given this information, I'd
like to return the proxy maintainers team to the metadata so I'm able to
open PR via github and manage changes even without Patrick."


> 
> But it makes more sense to realise who the primary proxied maintainer
> was at this time, who can be considered "owning" the package, and has
> the right to dictate which gentoo dev's maintain their packages for
> them.

At some point they likely should establish a project and discuss things
internally before making changes. But on a post-hoc-basis the
determination will need to be based on documented history.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Kent Fredric]

On Fri, 19 May 2017 19:27:15 +0200
Kristian Fiskerstrand  wrote:

> As far as I can see you were never the maintainer of at least
> app-misc/elasticsearch (I didn't check other possibly related
> packages), it was first proxied maintained through chainsaw, then
> later through proxy-maintainers herd (since 2015) which was converted
> to the project once herds were deprecated. I don't notice you showing
> up in the git log (with cvs history grafted) until 2016 in a commit
> that removed proxy maint seemingly without corrabolation, and as such
> got reverted.

It probably helps better understand what's going on if you pay careful
attention, not to the name "Patrick" but to Ferenc Erki.

Given they're working side-by-side and so there's room for Patrick to
be operating in the capacity indicated by Ferenc without it necessarily
being visible in the history ( leading to confusion )

Then a few small, but important changes become apparent:

40258029bda18564b0d3e21f0644ffcd40fd4974 - 2015-06-12 ( Gentoo history )

Chainsaw adds Ferenc as a maintainer, where Chainsaw opts to be the
proxy.

20c1bcbaa6346c6e4643f50b904deaa8e9c06af2 - 2015-12-16

Idella4 adds proxy-maint with Chainsaws ack

f279fce9617b2e3ddbf3ef99df8f65629617e959 - 2015-12-16

Idella4 removes Chainsaw, assumingly part of the previous change,
moving the proxy from Chainsaw to Proxy-Maint project.

ef2b2458815ba4e4694e0d5f3bbce239505ffbc8 - 2015-12-20

Idella4's last commit on this package.

3d70356565d3213c370e1f64a85b55c3ded259f5 - 2016-01-06

Patricks first direct commit to this package.

<>

e6175815b5792f09acd90627af5fe23f616ad245 - 2016-09-02

Patrick adds himself and Tomas, and removes Proxy Maint.

^^^ 

This last commit is, as I understand, where most this conflict comes
from.

Because to an untrained eye, in isolation looks like an antagonistic
dev just going in and changing stuff they have no right to change.

But it makes more sense to realise who the primary proxied maintainer
was at this time, who can be considered "owning" the package, and has
the right to dictate which gentoo dev's maintain their packages for
them.

And it certainly makes sense given the working relationship and the
existing commit history of contribution, that Patrick is already
functioning as a primary maintainer at this point, working under the
assumption that he just does what Ferenc wants.

Proxy-Maint are the unwanted element in this equation, but it seems to
me proxy-maint over-reacted based on not having the full picture, and
so both sides have some miscommunication and misunderstanding about
what the other is doing.

Everything *after* that commit looks like after-the-fact
edit-wars+confusion.



pgpWUeV1ZmTES.pgp
Description: OpenPGP digital signature

[gentoo-dev] Integrating Ada into toolchain.eclass, again

[Luke A. Guest]

Hi,

I posted a bug back in August,
https://bugs.gentoo.org/show_bug.cgi?id=592060, to discuss adding Ada
support into Gentoo's toolchain.eclass. The reasons for this are twofold:

1) GNAT is supplied with the source of GCC and should be available in
Gentoo's sys-devel/gcc with USE=ada
2) Automatically gain cross compilers with sys-devel/crossdev, also has
been tested with my patch.

I saw a few new dev-ada packages being added to the tree yesterday. I
don't check this ml often, but just checking and seeing the various
discussions on Ada. I wonder why my bug has been ignored, surely the bug
tracker should've been checked first by Alfredo? He basically wanted
this as well.

** Current problems **

The above link provides other links and discussion including an error
I'm getting compiling GCC 6.x within emerge only. There are new
bootstraps for amd64 (so far) also.

** GNAT GPL **

I think that if anyone wants GNAT GPL versions, they should be installed
in /opt and bought into a person's environment manually by the people
using these compilers. I only really consider this compiler useful as a
means for testing source that fails with bug boxes using the FSF GCC due
to the fact that software built with GNAT GPL is automatically GPL v3.

** Roadmap **

I would suggest the following, but is fluid as it starts off really
messy due to cyclic dependencies:

* Add my patch to the toolchain.eclass to get at least part of the
problem sorted out, a start.
* Build bootstraps for the other platforms and at various compiler
versions, this is simple enough to do.
* Purge all current Ada/GNAT stuff from the portage tree as it's really
old and tbh, a mess.
* Start discussing the problem of a Gentoo Ada policy, this is mentioned
by Steve Arnold in the above link, he has started on an eclass for gnatmake.
* For 4.9.x and early 5.x compilers, add gnatutils, this is removed in
later versions of the tools as apparently it's not required anymore.
* gprbuild needs to be bootstrapped by makefile where it builds it's own
gnatutils and xmlada
* eselect plugin for applications built with GNAT, they will need to be
slotted where they use shared libs which were also Ada sources.
* gpr.eclass  so other ebuilds can use the various gpr tools for building.
* gnatcoll, xmlada, asis ebuilds added to dev-ada
* gprbuild really needs to be rebuilt using the installed tools and libs.
* other libs.
* gps ebuild.
* Extend USE=ada to other Gentoo targets, more gnatboot strap compilers.

** Bootstraps **

Steve has bootstraps built for amd64, x86, arm for gcc-4.9, I have added
5.4 and 6.3 for amd64 in
https://www.dropbox.com/sh/stljjvpj9201n8t/AAAzVG67ppskZ9UKiWTWz9Q_a?dl=0,
I've not looked into a canadian cross with Gentoo yet, it's on the todo
list I suppose.

Thoughts?

Thanks,
Luke.

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Kristian Fiskerstrand]

On 05/19/2017 06:50 PM, Patrick Lauer wrote:
> 
> I have no idea how I could have fixed this without the QA+Comrel
> banhammer combo, which is a totally insane "fix" to a problem that
> shouldn't even exist. But I see no other options how to make people
> understand that "No means no".
> 
> Is this the new normal?

As far as I can see you were never the maintainer of at least
app-misc/elasticsearch (I didn't check other possibly related packages),
it was first proxied maintained through chainsaw, then later through
proxy-maintainers herd (since 2015) which was converted to the project
once herds were deprecated. I don't notice you showing up in the git log
(with cvs history grafted) until 2016 in a commit that removed proxy
maint seemingly without corrabolation, and as such got reverted.

I'm really struggling to understand what you're trying to say here, if
it is "can I take any package I want without consulting with existing
maintainers", then yes, its the normal (its not new)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Patrick Lauer]

On 05/19/2017 03:10 PM, Michał Górny wrote:

On Wed, 2017-05-17 at 18:38 +0200, Patrick Lauer wrote:

Bonus mention:
bbdc5412061adf598ed935697441a7d6b05f7614
 app-admin/logstash-bin: drop old

 Signed-off-by: Andrew Savchenko 

That removed the versions I was using, so I better maintain the versions
I use in an overlay. Well ok then.



I'm sorry that the situation turned out badly for you. However, I would
like to point out that problems like this are rarely unilateral,
and usually involve issues on both ends.

I'd like to ask you a very simple question: what did you do to ensure
that the versions you are using are not accidentally removed?

I could have a few ideas, such as:

a. slotting the package to indicate that multiple versions might be
meaningful,

b. opening a bug requesting the old version to be kept,

c. leaving a comment in the ebuild (unlikely to help but still),

d. just mailing proxy-maint@ to let us know of the issue.



I tried removing proxy-maint from metadata after multiple discussions 
failed. Extra happiness towards monsieurp "but the GH PR is over 3 days 
old, I have to commit" and gokturk "Yes I understand. I commit anyway"


This has been an uphill struggle since about October, around New Year I 
stopped actively caring, and since these two commits:


12c3eacda7c4d23686eaf10eab21d810cc95ea49
f42d6679c038c3efcc257d38547267d01823aea9

I see no way to fix this situation that doesn't involve a review board 
in front of all proxy-maint commits. Because we discussed this in IRC, 
and still ... "but is open bug"



However, as far as I'm aware none of this happened. Note that I might
have missed the mail, or it might have been sent before I joined --
correct me if that is the case.


There were multiple discussions in IRC, which the involved people 
usually forgot within about 20 minutes and then resumed doing stuff.


I tried removing proxy-maint from metadata, which was reverted (sooo how 
does one *not* have constant interference?)



As Alec pointed out, it is a normal procedure in Gentoo to remove old
versions of software if there is no explicit indication that they need
to be kept. Therefore, I don't see anything wrong with the proxied
maintainer wishing to clean the old versions up and/or not requesting
your explicit permission for that. If you needed the old versions, you
should have made that clear.


One could ask, maybe. I guess I can (mis)understand this to mean that I 
can do with packages with you in metadata what I want because ... err... 
shiny!



I should also point out that the steps you've taken (and listed in this
mail) are not really relevant. They make you look like a sloppy
maintainer, and a bad Gentoo developer at the best -- and I doubt anyone
would connect removing proxy-maint team with a necessity of keeping
an old version.


The cooperation that I had with ferki was pretty good (mostly because we 
sat next to each other in the office). The contributions from Tomas were 
on average pretty ok, just needed some minor cleanups here and there.


The blind "but PR is open for 3 days" commits from proxy-maint made it 
extremely hard to review what changed in a timely manner, so that I 
basically didn't want to care for this pile of stupid for the last, 
ahem, 6 months or so. Especially since whenever I wanted to review 
things some joker made some new changes which made me go "eh whut how 
you? banana banana!" so I pushed reviewing a week into the future and ...


I have no idea how I could have fixed this without the QA+Comrel 
banhammer combo, which is a totally insane "fix" to a problem that 
shouldn't even exist. But I see no other options how to make people 
understand that "No means no".


Is this the new normal?

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Patrick Lauer]

On 05/18/2017 07:17 PM, Alec Warner wrote:



On Wed, May 17, 2017 at 12:38 PM, Patrick Lauer > wrote:

Ohey,

as you might have noticed I've just corrected the metadata.xml of
all elasticsearch-related packages.
For some strange reason I was listed there as maintainer, but since
no one wanted to listen to my ideas I guess I wasn't. So now last
person who touched it gets stuck with it.

Since proxy-maint refuses to be removed from packages (especially
since they were unconditionally added to all packages with a
non-gentoo-dev maintainer in metadata) they are the de facto
maintainers, and overrule everything else.
I've tried multiple strategies including removing them from
metadata, but ... see app-admin/elasticsearch, proxy-maint is like
the toe fungus that always comes back (e.g. commit
f0925c10834464e62ce7209f2afa7797b594d350 )

Sometimes it's almost absurdly funny, especially when you commit
RESTRICT="test" because tests fail reliably just to have that reverted.
(See dev-python/elasticsearch-py )

Bonus mention:
bbdc5412061adf598ed935697441a7d6b05f7614
app-admin/logstash-bin: drop old

Signed-off-by: Andrew Savchenko >

That removed the versions I was using, so I better maintain the
versions I use in an overlay. Well ok then.


I don't quite get this gripe. Gentoo is a rolling distro. Versions of
things "you are using" get removed and replaced with newer versions all
the time. Why is this a big deal now?



I "was" package maintainer and relied on these versions.

If I as maintainer have no control over such things, why am I 
maintainer, and why do I need an overlay?



... that sounds exquisitely confused, I have no idea why this discussion 
even exists.

Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine

[Mike Gilbert]

On Thu, May 18, 2017 at 12:31 AM, Marty Plummer  wrote:
> On Thu, May 18, 2017 at 07:16:43AM +0300, Alon Bar-Lev wrote:
>> On 18 May 2017 at 07:10, Marty Plummer  wrote:
>> > On Thu, May 18, 2017 at 06:53:48AM +0300, Alon Bar-Lev wrote:
>> >> On 18 May 2017 at 06:54, Marty Plummer  wrote:
>> >> > Greetings,
>> >> >
>> >> > As the subject states, compiling dev-libs/libressl for 
>> >> > x86_64-w64-mingw32
>> >> > target via crossdev ends up calling wine to run checks, which fails with
>> >> > an access violation, and as such emerge cannot finish.
>> >> >
>> >> > Would it be an acceptable change to disable emake check for mingw-w64
>> >> > crossdev targets?
>> >> >
>> >>
>> >> Why do you enable tests?
>> >>
>> > I did not, there is no use flag for dev-libs/libressl I can use to
>> > disable tests. if there is a global flag I should disable, I'd be
>> > greatly appreciative of it.
>> >
>>
>> If you enable tests globally, then you can disable them for a specific
>> build using:
>> FEATURES="-test" emerge ...
>>
> it seems that dev-libs/libressl does not respect this action, just tried
> again with FEATURES="-test" and had the same result.
>

>From your build log, wine is being called during the compile phase,
not the test phase, so FEATURES="test" has no effect.

In any case, you should file a bug report on bugzilla.

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Michał Górny]

On Wed, 2017-05-17 at 18:38 +0200, Patrick Lauer wrote:
> Bonus mention:
> bbdc5412061adf598ed935697441a7d6b05f7614
>  app-admin/logstash-bin: drop old
> 
>  Signed-off-by: Andrew Savchenko 
> 
> That removed the versions I was using, so I better maintain the versions 
> I use in an overlay. Well ok then.
> 

I'm sorry that the situation turned out badly for you. However, I would
like to point out that problems like this are rarely unilateral,
and usually involve issues on both ends.

I'd like to ask you a very simple question: what did you do to ensure
that the versions you are using are not accidentally removed?

I could have a few ideas, such as:

a. slotting the package to indicate that multiple versions might be
meaningful,

b. opening a bug requesting the old version to be kept,

c. leaving a comment in the ebuild (unlikely to help but still),

d. just mailing proxy-maint@ to let us know of the issue.

However, as far as I'm aware none of this happened. Note that I might
have missed the mail, or it might have been sent before I joined --
correct me if that is the case.

As Alec pointed out, it is a normal procedure in Gentoo to remove old
versions of software if there is no explicit indication that they need
to be kept. Therefore, I don't see anything wrong with the proxied
maintainer wishing to clean the old versions up and/or not requesting
your explicit permission for that. If you needed the old versions, you
should have made that clear.

I should also point out that the steps you've taken (and listed in this
mail) are not really relevant. They make you look like a sloppy
maintainer, and a bad Gentoo developer at the best -- and I doubt anyone
would connect removing proxy-maint team with a necessity of keeping
an old version.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part