Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Samuel Bernardo]

Hi William,

How about overlays using the eclass, will this changes only apply to EAPI 8?

Thanks,

Samuel

On 5/10/20 10:16 PM, William Hubbs wrote:
> All,
>
> now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from
> go-module.eclass.
>
> This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> warning advising people to migrate their ebuilds to EGO_SUM.
>
> This patch makes migrating mandatory by forcing ebuilds to die if they
> have EGO_VENDOR set and are using go-module.eclass.
>
> Thoughts?
>
> William Hubbs (1):
>   eclass/go-module.eclass: remove EGO_VENDOR support
>
>  eclass/go-module.eclass | 81 +++--
>  1 file changed, 6 insertions(+), 75 deletions(-)
>



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members

[Jimi Huotari]

On Tue, 12 May 2020 06:20:40 -0400
Aisha Tammy  wrote:

> Oh, very sorry if I came out that way. I wasn't being passive aggressive.
> Sometimes I write things the wrong way. I should have definitely written 
> it better :(

For what it is worth, I didn't read your message in that way at all, and
still couldn't read it that way at all after a message from someone who
did.

> >> Just wanted to know why the devs are required to use gpg keys, glep63
> >> [1]
> >> but even when the server has the public keys, they aren't published
> >> properly.
> >>
> >> From a proper security perspective, I would have though something 
> >> like WKD[2] would have been implemented on the server side for
> >> automated
> >> authentication.  
> > 
> > WKD is implemented and I don't know a single case where it wouldn't
> > work.  If it doesn't work for you, then I dare say it's more likely to
> > be a problem with your setup.  However, if it's a problem on our end,
> > I'd really appreciate a bug report before calling us retarded.
> > 
> > In fact, the link you've posted actually lists gentoo.org as one
> > of the few organizations implementing WKD.
> >   
> Oh my, now I really feel bad. I definitely don't want to call anyone
> retarded or any such words. I never like to use very strong words such
> as those. While I agree I should've worded it better, please don't make
> it look like I am name calling and insulting everybody, and being a jerk
> in general. So I would really love it if you don't put those words in my
> mouth for me.

Joking a little: I wonder if they were actually responding to a different
message, because again, I don't see anything like this being said.  :]

Anyblue, that's just how I read it, and I wanted to suggest you to not
feel /too/ bad about it, especially now that you've made the intention
more clear-like.

These things happen with words written.


pgpGhIAXgV21G.pgp
Description: OpenPGP digital signature

[gentoo-dev] Gentoo clang team

[Alexander Bilyak]

Hello everyone in this mailing list.

I apologize for myself as I am not sure if it is the right place to write,
but anyway...
I am the (only) maintainer of gentoo-clang
 overlay.
Recently I've found this bug (#408963) . So
I guess I am not alone working on enabling clang as system compiler for
entire system.
Here (#502464)  I've found Michał
Górny mentioned
gentoo clang team, but I could not found any mailing list or other
reference to them.
Could someone please tell me where I could find them cause I really want to
put my work in a good use.

Thanks,
Alexander

Re: [gentoo-dev] Gentoo clang team

[Sam James]

> On 12 May 2020, at 14:48, Alexander Bilyak  wrote:
> 
> Hello everyone in this mailing list.
> 
> I apologize for myself as I am not sure if it is the right place to write, 
> but anyway...
> I am the (only) maintainer of gentoo-clang 
>  overlay.
> Recently I've found this bug (#408963) . So I 
> guess I am not alone working on enabling clang as system compiler for entire 
> system.
> Here (#502464)  I've found Michał Górny 
> mentioned gentoo clang team, but I could not found any mailing list or other 
> reference to them.
> Could someone please tell me where I could find them cause I really want to 
> put my work in a good use.

Have a look at https://wiki.gentoo.org/wiki/Project:LLVM 
 and #gentoo-llvm on Freenode. I’m 
sure any help would be appreciated.

> 
> Thanks,
> Alexander

Re: [gentoo-dev] Gentoo clang team

[Alexander Bilyak]

Hi Sam,
Thanks for your reply
I've seen project LLVM but I was concerned it is about porting LLVM to
Gentoo, not about making Gentoo LLVM/Clang - compatible. There even was no
such thing in their TODO list.
Anyway, thanks. I'll try reach them.


вт, 12 мая 2020 г. в 15:51, Sam James :

>
> On 12 May 2020, at 14:48, Alexander Bilyak 
> wrote:
>
> Hello everyone in this mailing list.
>
> I apologize for myself as I am not sure if it is the right place to write,
> but anyway...
> I am the (only) maintainer of gentoo-clang
>  overlay.
> Recently I've found this bug (#408963) .
> So I guess I am not alone working on enabling clang as system compiler for
> entire system.
> Here (#502464)  I've found Michał Górny 
> mentioned
> gentoo clang team, but I could not found any mailing list or other
> reference to them.
> Could someone please tell me where I could find them cause I really want
> to put my work in a good use.
>
>
> Have a look at https://wiki.gentoo.org/wiki/Project:LLVM and #gentoo-llvm
> on Freenode. I’m sure any help would be appreciated.
>
>
> Thanks,
> Alexander
>
>
>

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Mike Gilbert]

On Mon, May 11, 2020 at 6:58 PM William Hubbs  wrote:
>
> On Mon, May 11, 2020 at 09:51:45AM -0400, Mike Gilbert wrote:
> > On Sun, May 10, 2020 at 5:16 PM William Hubbs  wrote:
> > >
> > > All,
> > >
> > > now that go 1.14.2 is stable, I want to remove the EGO_VENDOR support from
> > > go-module.eclass.
> > >
> > > This was kept when the EGO_SUM support was added on 4 Mar, with a qa
> > > warning advising people to migrate their ebuilds to EGO_SUM.
> > >
> > > This patch makes migrating mandatory by forcing ebuilds to die if they
> > > have EGO_VENDOR set and are using go-module.eclass.
> > >
> > > Thoughts?
> >
> > It seems like you're being very lazy about this. At a minimum, you
> > should do the following:
>
> I will respond to your points below, but first, I take offense to your
> accusation of me being lazy especially since it seems pretty obvious you
> didn't attempt to research my work before you said it.

The phrasing of your original email, combined with a question you
asked in IRC lead me to the wrong conclusion. Sorry about that.

Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members

[Aisha Tammy]

On 5/12/20 1:24 AM, Michał Górny wrote:
> W dniu pon, 11.05.2020 o godzinie 20∶20 -0400, użytkownik Aisha Tammy
> napisał:
>> Hi devs@,
>>  Seems like for some reason the gentoo.org does not publish the 
>> gpg public keys of the senders, even though it is signed correctly.
> 

Oh, very sorry if I came out that way. I wasn't being passive aggressive.
Sometimes I write things the wrong way. I should have definitely written 
it better :(

>>
>> Just wanted to know why the devs are required to use gpg keys, glep63
>> [1]
>> but even when the server has the public keys, they aren't published
>> properly.
>>
>> From a proper security perspective, I would have though something 
>> like WKD[2] would have been implemented on the server side for
>> automated
>> authentication.
> 
> WKD is implemented and I don't know a single case where it wouldn't
> work.  If it doesn't work for you, then I dare say it's more likely to
> be a problem with your setup.  However, if it's a problem on our end,
> I'd really appreciate a bug report before calling us retarded.
> 
> In fact, the link you've posted actually lists gentoo.org as one
> of the few organizations implementing WKD.
> 
Oh my, now I really feel bad. I definitely don't want to call anyone retarded
or any such words. I never like to use very strong words such as those.
While I agree I should've worded it better, please don't make it look like
I am name calling and insulting everybody, and being a jerk in general.
So I would really love it if you don't put those words in my mouth for me.

I actually thought that this was the proper channel to ask for these things.
Maybe the dev mailing list was not the proper place, I didn't think about
it being perceived as accusatory. I mostly thought it would be related to 
a bug or an oversight.


It is 110% possible for my setup to have mistakes. I even said as much.
I would love to fix that.

Indeed, because the link actually mentioned that gentoo.org has setup
WKD that is why I was a bit surprised when some of the keys were not found.

>> Why do you claim that?  How did you verify it? 

I am using enigmail + thunderbird which I thought would have should be making 
proper requests for the WKD keys and it reported that for some of the emails
sent from devs they keys were not found on the keyserver.

I will be doing a lot more debugging today and will try to see where things 
went 
wrong on my end. Now that you say it has been implemented properly, I feel that
I should do a lot more work on my side :)

>>
>> Maybe I am missing something about how to verify the keys of the
>> maintainers
>> who are sending announcements but it irks me a teensy bit when i have
>> signed
>> mails and I can't ~~trust~~ verify the signatures.
>>
>>
> 
> You are missing that WKD does not provide authentication, and if it
> were, it would be considered thoroughly insecure.  Authentication
> in OpenPGP is generally provided via web of trust.  For Gentoo
> developers, you can also use our Authority Keys [3,4,5].
> 

This is actually an interesting point. It might be better to discuss that over 
irc.
The web of trust is actually a topic which I have some weird thoughts over.

Best,
Aisha

>>
>> [1] 
>> https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys
>> [2] https://wiki.gnupg.org/WKD
> 
> [3] https://www.gentoo.org/downloads/signatures/
> [4] https://www.gentoo.org/glep/glep-0079.html
> [5] https://wiki.gentoo.org/wiki/Project:Infrastructure/Authority_Keys
> 
> 

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[William Hubbs]

On Mon, May 11, 2020 at 10:47:23PM -0700, Matt Turner wrote:
> On Mon, May 11, 2020 at 4:00 PM William Hubbs  wrote:
> >
> > On Tue, May 12, 2020 at 01:45:45AM +0300, Andreas K. Hüttel wrote:
> > > > This patch makes migrating mandatory by forcing ebuilds to die if they
> > > > have EGO_VENDOR set and are using go-module.eclass.
> > >
> > > You can't commit this as long as there is a single such ebuild in the 
> > > tree.
> >
> > Sure, and I'm working on migrating them.
> 
> I think all the replies to this thread could have been avoided by just
> saying that in your initial email. :)

I didn't have a problem with what dilfridge said or even with the list
of points floppym came up with. My issue was more with the tone of
floppym's reply, and that has been resolved. :-)

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[William Hubbs]

On Tue, May 12, 2020 at 11:41:45AM +0100, Samuel Bernardo wrote:
> Hi William,
> 
> How about overlays using the eclass, will this changes only apply to EAPI 8?
 
 Hi Samuel,

 this change will apply to all users of the eclass.

 Overlays are not considered blockers for in-tree eclass work.

Also, keepin mind that there was a qa warning in place for this issue
for 3 months, so overlay owners should have been able to see that and
migrate their ebuilds to EGO_SUM.

 That being said, if any overlay owner would like my assistance with
 migrating their ebuilds, I have no problem with showing them how.

 Thanks,

 William


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Samuel Bernardo]

Hi William,

On 5/12/20 4:38 PM, William Hubbs wrote:
>  Hi Samuel,
>
>  this change will apply to all users of the eclass.
>
>  Overlays are not considered blockers for in-tree eclass work.
>
> Also, keepin mind that there was a qa warning in place for this issue
> for 3 months, so overlay owners should have been able to see that and
> migrate their ebuilds to EGO_SUM.
Yes, I confirm that I'm aware of that. Thank you for your good work!
>  That being said, if any overlay owner would like my assistance with
>  migrating their ebuilds, I have no problem with showing them how.

No problem from my side, I have already do that.

My concern was about the others, for instance go-overlay that I have
enabled.

Should it be possible to run a QA check to create a bug request to
remember the update of those ebuilds in the overlays?

This would reduce the bug management task when searching for related bugs.

>  Thanks,
>
>  William

Thanks,

Samuel





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Joonas Niilola]

On 5/12/20 8:36 PM, Samuel Bernardo wrote:
>
> My concern was about the others, for instance go-overlay that I have
> enabled.
>
> Should it be possible to run a QA check to create a bug request to
> remember the update of those ebuilds in the overlays?
>
> This would reduce the bug management task when searching for related bugs.
>
Nothing stops you from doing that, and reporting any issues you find to
overlay maintainers. This is probably doable with a single grep. We
_cannot_ cater all the overlays. There has been enough time to react.

-- juippis




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass

[Samuel Bernardo]

Hi,

On 5/12/20 6:40 PM, Joonas Niilola wrote:
> On 5/12/20 8:36 PM, Samuel Bernardo wrote:
>> My concern was about the others, for instance go-overlay that I have
>> enabled.
>>
>> Should it be possible to run a QA check to create a bug request to
>> remember the update of those ebuilds in the overlays?
>>
>> This would reduce the bug management task when searching for related bugs.
>>
> Nothing stops you from doing that, and reporting any issues you find to
> overlay maintainers. This is probably doable with a single grep. We
> _cannot_ cater all the overlays. There has been enough time to react.
>
> -- juippis

Maybe I understand wrongly, but I had received in the past automatic bug
reports from Gentoo QA check related to my overlay. My suggestion is to
use the Gentoo QA to automatically report that, since with the new merge
with the removal of EGO_VENDOR that would be validated automatically in
future Gentoo QA check runs over the overlays at overlays.gentoo.org.

Anyway I can do as you suggests.

Thanks




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members

[desultory]

On 05/12/20 01:24, Michał Górny wrote:
> W dniu pon, 11.05.2020 o godzinie 20∶20 -0400, użytkownik Aisha Tammy
> napisał:
>> Hi devs@,
>>  Seems like for some reason the gentoo.org does not publish the 
>> gpg public keys of the senders, even though it is signed correctly.
> 
> Why do you claim that?  How did you verify it?  Why are you jumping
> straight to passive-aggressive accusations without asking nicely first?
> 
That last question could very much be asked of you because of your
asking it of them. They needed information, at least some of which you
did give, not clutching of pearls and baseless protestations of offense.

>>
>> Just wanted to know why the devs are required to use gpg keys, glep63
>> [1]
>> but even when the server has the public keys, they aren't published
>> properly.
>>
>> From a proper security perspective, I would have though something 
>> like WKD[2] would have been implemented on the server side for
>> automated
>> authentication.
> 
> WKD is implemented and I don't know a single case where it wouldn't
> work.  If it doesn't work for you, then I dare say it's more likely to
> be a problem with your setup.  However, if it's a problem on our end,
> I'd really appreciate a bug report before calling us retarded.
> 
Given that they did not call anyone any names, retarded or otherwise,
one could make the case that you are making a personal attack against
them by smearing them and their postings; at best that hurts your
argument as a supposedly affronted party. So, please, try to not
construct offense out of whole cloth to be performatively perturbed at;
it serves no purpose beyond making the lists less useful due to
increased noise and making social norms in Gentoo (especially on the
lists) that much less congenial.

> In fact, the link you've posted actually lists gentoo.org as one
> of the few organizations implementing WKD.
> 
>>
>> Maybe I am missing something about how to verify the keys of the
>> maintainers
>> who are sending announcements but it irks me a teensy bit when i have
>> signed
>> mails and I can't ~~trust~~ verify the signatures.
>>
>>
> 
> You are missing that WKD does not provide authentication, and if it
> were, it would be considered thoroughly insecure.  Authentication
> in OpenPGP is generally provided via web of trust.  For Gentoo
> developers, you can also use our Authority Keys [3,4,5].
> 
>>
>> [1] 
>> https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys
>> [2] https://wiki.gnupg.org/WKD
> 
> [3] https://www.gentoo.org/downloads/signatures/
> [4] https://www.gentoo.org/glep/glep-0079.html
> [5] https://wiki.gentoo.org/wiki/Project:Infrastructure/Authority_Keys
> 
>