Re: [gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

might be nitpick, but..

On 08/13/2015 05:17 AM, Mike Frysinger wrote:

> +Your best option is to generate new keys using newer types such as
> rsa +or ecdsa or ed25519.  RSA keys will give you the greatest
> portability +with other clients/servers while ed25519 will get you
> the best security +with OpenSSH (but requires recent versions of
> client & server).

Strictly speaking DSA/DSS is newer than RSA (FIPS-186-1 came in early
90's, RSA around since 70s, although the ElGamal signature scheme was
around before that). ECC gives a better performance on the same
security level when comparing to DSA/RSA, however claiming better
security in general isn't necessarily valid, Ed25519 is a signature
scheme over Curve25519 which is a 256 bit curve generally considered
to be 128 bit security level, roughly comparable to a 3072 bit RSA key.

(as a side note, it seems OpenSSH was not updated for FIPS-186-3 that
adds other key lengths to DSA, but refers to DSA to mean FIPS-186-2)




- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVzEChAAoJECULev7WN52F9RgH/2ogCdlZv+RoY7fwaTrviyFK
oAzDRubkCPuIFAuERgqpkPlnu692tnNXXtJ6w4krSpg4lFSeh7KPPYM/C9dA++V4
7/oyCuOiQ6pxcQlHa1dTpCQjdWAOE5SL0os4Fy81hVGAvZgPGubRQSelBe9UUE4U
tP7Z+5FW/bnX91K0OZEl75qoKvLT4xqhWNUiLG3V1aUCN+DC7ZaSJkoC27vd+l+b
iqetcOzudojT4DyltO+dIkzQeSlaMF6qZnmq+MJU5m9b8U9ACw30YalD8awumN21
6cK0nOOxQI4M0VRLjl+9xMLrYnuQbeJnN3JBZpKnTcZ5S3hs0DPfhvTcAv0pyaw=
=LHJd
-END PGP SIGNATURE-

[gentoo-dev] Cleaning up integration of external repos into ::gentoo

[Michał Górny]

Hi,

Now that we have the official git repository, I've switched user-facing
git mirrors from rsync->git to the real git. As a result, users are now
complaining that some random Gentoo metadata has disappeared.

As you may have noticed already, I am *really* unhappy about adding
special conditionals with hardcoded URLs (and ugly mixing stuff) for
Gentoo. So if you really don't want to put the stuff into the repo,
please at least:

1. Move DTDs to a git repository (seriously, I don't want to have to
touch CVS).

2. Strip the year from gentoo-news [1]. I think we have all
the agreement to proceed there. I will prepare a GLEP update today,
and if given OK, I can update the repo, and the scripts.

3. Provide a machine-readable description where those files/directories
come from. Not sure how that should look but how about something along
the lines of repos.conf:

  metadata/external-repos.conf::

[gentoo-news]
location = metadata/news
sync-type = git
sync-uri = https://anongit.gentoo.org/proj/gentoo-news.git

[herds]
location = metadata/herds.xml
# or do we want to use git here?
sync-type = http
sync-uri = https://api.gentoo.org/packages/herds.xml

Comments?

[1]:https://bugs.gentoo.org/show_bug.cgi?id=523828

-- 
Best regards,
Michał Górny



pgpJejyuOfkmP.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Frysinger]

On 13 Aug 2015 09:00, Kristian Fiskerstrand wrote:
> On 08/13/2015 05:17 AM, Mike Frysinger wrote:
> > +Your best option is to generate new keys using newer types such as
> > rsa +or ecdsa or ed25519.  RSA keys will give you the greatest
> > portability +with other clients/servers while ed25519 will get you
> > the best security +with OpenSSH (but requires recent versions of
> > client & server).
> 
> Strictly speaking DSA/DSS is newer than RSA (FIPS-186-1 came in early
> 90's, RSA around since 70s, although the ElGamal signature scheme was
> around before that).

i'll rephrase:
-Your best option is to generate new keys using newer types such as rsa
+Your best option is to generate new keys using strong algos such as rsa

> ECC gives a better performance on the same
> security level when comparing to DSA/RSA, however claiming better
> security in general isn't necessarily valid, Ed25519 is a signature
> scheme over Curve25519 which is a 256 bit curve generally considered
> to be 128 bit security level, roughly comparable to a 3072 bit RSA key.

using ed25519 allows you to build openssh w/USE=-ssl which does get you
better security due to the smaller attack surface.  but the point of the
news item is to push people in the right direction w/out getting into a
dissertation on the nuances/details that people realistically won't grok
and won't make a difference to them.  if they're experts/interested, it
should be easy to locate additional material (including the linked page).
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [PATCH] profiles: linux: enable USE=seccomp by default

[Mike Frysinger]

---
 profiles/default/linux/make.defaults | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/profiles/default/linux/make.defaults 
b/profiles/default/linux/make.defaults
index 7ad3bdb..be2f6a1 100644
--- a/profiles/default/linux/make.defaults
+++ b/profiles/default/linux/make.defaults
@@ -17,6 +17,9 @@ USE="berkdb crypt ipv6 ncurses nls pam readline ssl tcpd zlib"
 # make sure toolchain has sane defaults 
 USE="${USE} fortran openmp"
 
+# Security ftw.
+USE="${USE} seccomp"
+
 # 2010/10/21 - Ole Markus With 
 # These USE flags were originally inserted here because of PHP
 # and were later removed by me. Reinserting the USE flags again because they 
are
-- 
2.4.4

Re: [gentoo-dev] Why gcc-config is a separate utility, not a module for eselect?

[Mike Frysinger]

On 02 Mar 2015 16:57, viv...@gmail.com wrote:
> good memory,
> maybe someone could write a frontend in eselect to gcc-config, to have a
> proved manager _and_ everything in one place.

done for the next release
https://bugs.gentoo.org/507870
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Daniel Campbell (zlg)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/11/2015 07:32 AM, Michał Górny wrote:
> Hello, everyone.
> 
> Now that we're officially on git and can officially use pull
> requests to provide rapid community interaction, it'd be convenient
> to have a little better framework for pinging package maintainers.
> 
> With the unofficial mirror/pull request project, I was either
> looking for project member GitHub accounts and pinging found
> project members by name, or talking to them directly on IRC.
> However, with the growth in number of pull requests this will
> become more and more inconvenient. Therefore, I think it's time to
> be able to mirror teams willing to work with GitHub community there
> for easier 'pings'.
> 
> I have two ideas right now:
> 
> 1. creating GitHub Gentoo project teams corresponding to willing
> Gentoo teams,
> 
> 2. preparing lists of GitHub usernames on project wiki pages.
> 
> Solution 1. is cleaner. In this case, we create GitHub teams under 
> the Gentoo projects, and add appropriate Gentoo developers having 
> GitHub accounts to the teams. Then, in PRs we can just ping the
> whole team like @Gentoo/Qt or like.
> 
> Solution 2. avoids adding any GitHub teams. In this case, in team
> wiki page we collect team member usernames like "@Pesa,
> @kensington, ..." so we could copy-paste it to pull requests. We
> still require extra effort when 'assigning' PRs but at least I
> don't have to lookup the same people over and over again.
> 
> With some Wiki people help, we could even implement updating
> GitHub teams automatically following Wiki member changes.
> 
> Your thoughts?
> 

Sounds good, but my GitHub nick doesn't match my dev nick, and that
nick is taken on GitHub. What do?

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVzEjGAAoJEAEkDpRQOeFwtagP/3TSjgxe/X2UoWelHfkWE55k
KpmEhbzMBi6Q9WApJ2gv1700zmw2wh/M9xwjFgXor7jDY65opOq7mH1NWZ3Qt/nE
e9BR+HxJ4sJLYAVmuXcV4yPK5VftK8kf2lq0XsiJh+jlCWOZ1opKf3wXJOcN9/1I
xB9e3nG4i25Xk9XEIRLX0fWDcu03YvQjP11Zb/FxUYhc29gr0b3am7FLGGgeCUmo
pRPLcPm+9JvxzCy0n9PofFgoZBtt7RFkOobK8aOC+MM1xSBoSf/r8iQ8bKLXrApY
LB4YltxbTWCbFAi7dwmQInhbw73K4cIK1Id5UooiOkFnDz1o8FhKE9Y9jRlvsqMM
rLgKBJD12ZwlDPSN5Zomu2U7A42hCQ8AemWaOBR6oyh/yiy8Jw1jKI7Apdi43EIU
iA5DUGdvwpRd47N5LXQAXfVBw3t4GJzznyTgzpDAFLojqX22Q9jtmFXh/qi87d+f
O2dyziqGwQyP06j1XxNvHLKaIidUCPwh+ienB9+J5JvokPVXPyhcwRKnfpsBRaWR
B+98s7o8nJMhkgzGGIBdvSLlgs7PcIBnYemoqtTYTvIjGPCWEpSx1JK7KKV1Ueid
qcmf48TAtdnFyJ0fpPFFyMbvUjFp88+mOrM3ziGWosTIRfWRQppNgnPhS5XRyTv1
ntkGum5DLHVN3ltpFEXS
=Jgfc
-END PGP SIGNATURE-

Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Michał Górny]

Dnia 2015-08-13, o godz. 00:35:39
"Daniel Campbell (zlg)"  napisał(a):

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 08/11/2015 07:32 AM, Michał Górny wrote:
> > Hello, everyone.
> > 
> > Now that we're officially on git and can officially use pull
> > requests to provide rapid community interaction, it'd be convenient
> > to have a little better framework for pinging package maintainers.
> > 
> > With the unofficial mirror/pull request project, I was either
> > looking for project member GitHub accounts and pinging found
> > project members by name, or talking to them directly on IRC.
> > However, with the growth in number of pull requests this will
> > become more and more inconvenient. Therefore, I think it's time to
> > be able to mirror teams willing to work with GitHub community there
> > for easier 'pings'.
> > 
> > I have two ideas right now:
> > 
> > 1. creating GitHub Gentoo project teams corresponding to willing
> > Gentoo teams,
> > 
> > 2. preparing lists of GitHub usernames on project wiki pages.
> > 
> > Solution 1. is cleaner. In this case, we create GitHub teams under 
> > the Gentoo projects, and add appropriate Gentoo developers having 
> > GitHub accounts to the teams. Then, in PRs we can just ping the
> > whole team like @Gentoo/Qt or like.
> > 
> > Solution 2. avoids adding any GitHub teams. In this case, in team
> > wiki page we collect team member usernames like "@Pesa,
> > @kensington, ..." so we could copy-paste it to pull requests. We
> > still require extra effort when 'assigning' PRs but at least I
> > don't have to lookup the same people over and over again.
> > 
> > With some Wiki people help, we could even implement updating
> > GitHub teams automatically following Wiki member changes.
> > 
> > Your thoughts?
> > 
> 
> Sounds good, but my GitHub nick doesn't match my dev nick, and that
> nick is taken on GitHub. What do?

Like most of the developers. Don't worry, we'll find you if you are in
the organization. If you're not, we'd probably keep looking by surname.

-- 
Best regards,
Michał Górny



pgpMYKgxZJxIZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

11.08.2015 16:49, Michael Palimaka пишет:
>> You think that REQUIRED_USE is abusive to users: fine. Point accepted.
>> I think that provided DEPEND strings if they will be typed at every
>> single qt-related ebuild that needs them are abusive to developers.
>>
>> So, maybe we should wrap them into eclass and stop riding our own
>> bicycles...
>>
>> And then - use apropriate one-liner where it's needed, providing
>> reasonable default and NOT confusing users with overmanaging their
>> package.use
>>
> 
> Please read Ben's original post again. Dependency strings are not the topic.
> 
> 

If introducing new USE-flags or ignoring using REQUIRED_USE leads to
blowing the DEPEND variable, adding pain for the developers - it is the
topic, definitely

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

11.08.2015 17:56, Ian Stakenvicius пишет:
> On 11/08/15 08:58 AM, Sergey Popov wrote:
>> 11.08.2015 15:30, Michael Palimaka пишет:
>>> On 11/08/15 20:10, Sergey Popov wrote:
 Err, i have read the whole thread and still does not get a
 point, why i am wrong.
>>>
>>> You clearly have not. The reasoning behind Qt team's policy is
>>> described on the page and has been reiterated on this list. You
>>> are undermining what little confidence there is in the QA team by
>>> making decisions with no consultation about problems you do not
>>> understand.
>>>
 It's old battle like we have beforce with "gtk" meaning "any
 versions of GTK flag". This behaviour should be killed with
 fire.

 Let's me reiterate some of the cases:

 1. Package can be build without Qt GUI at all, but either Qt4
 or Qt5 can be chosen, but not both.

 Fix this with REQUIRED_USE, do not enable any of Qt flags by
 default
>>>
>>> Problem: this requires manual intervention if the user has both
>>> qt4 and qt5 USE flags enabled.
>>>
> 
>> User choice of using USE flags is NOT a problem
> 

 2. Package can not be build without Qt GUI - either Qt4 or Qt5
 is required, but not both

 Same thing here, different REQUIRED_USE operator. But - enable
 one of the flags by default to ease life of users.
>>>
>>> Problem: this requires manual intervention if the user has both
>>> qt4 and qt5 USE flags enabled.
> 
>> Same here
> 

 3. Package can be build with Qt4 or Qt5 or both AT THE SAME
 TIME(if such package even exists?)

 Do not use REQUIRED_USE here, not needed.

 Now, please tell me, where am i wrong?

>>>
>>> The problem is manual intervention is required if the user has
>>> both qt4 and qt5 USE flags enabled - and this is a common
>>> configuration. It is not acceptable to make a user manually add
>>> numerous package.use entries when all they want to do is install
>>> KDE.
> 
>> And here
> 
>>> I agree Qt's policy is not a perfect solution, but in the absence
>>> of some feature allowing a preference to be set when there is a
>>> conflict it's the best we've got.
>>>
> 
>> If you want to go this way, then please provide helper functions
>> in eclasses to set dependencies properly for all common use cases.
>> That will ease life both of developers and users.
> 
> 
> Why do you need this?
> 
> #1, if you really want RDEPEND to only include the deps the package
> will actually use, then you do this:
> 
> old:
> 
> qt5? ( list of qt5 atoms )
> qt4? ( list of qt4 atoms )
> 
> ..to new:
> 
> qt5? ( list of qt5 atoms )
> !qt5? (
>   qt4? ( list of qt4 atoms )
> )
> 
> 
> BUT I would advise against this.  If a user has specified both qt4 and
> qt5 in USE, then I see no problem with the VDB having both qt4 and qt5
> atoms listed as dependencies.  End-users that want a clean VDB can
> just make sure they only enable one flag, but end-users that don't
> care will have packages that just work.
> 

great, in that case emerge --depclean becomes completely useless,
because of unneeded vdb deps. Those DEPENDs that i have provided was at
least consistent in terms of dependencies(that does not mean that they
are not ugly, though)

>> Leaving constructing of dependencies to developers in all cases
>> will cause only pain in your solution.
> 
> It really wont, see above.  At minimum, it's barely any more work than
> it is with a REQUIRED_USE based solution.
> 

I repeat that i said earlier: if this voodoo magic will be hidden in
some eclass - it is fine. If developers will be forced to add this
depstring over and over again - it will be PITA.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

11.08.2015 18:02, Ian Stakenvicius пишет:
> On 11/08/15 09:04 AM, Sergey Popov wrote:
>> 11.08.2015 15:32, Michael Palimaka пишет:
>>> On 11/08/15 20:17, Sergey Popov wrote:
 09.08.2015 23:28, Ulrich Mueller пишет:
> I disagree with this. Really, REQUIRED_USE should be used
> sparingly, and IMHO the above is not a legitimate usage case
> for it.

 So, you prefer to make ugly mess of deps here like i posted
 before or introduce some really unneded USE-flag like 'gui',
 'qt', etc. to make users even more confused?

 Really, look at man-db ebuild. Especially on berkdb and gdbm
 USE flags. And dependency string like this:

 !berkdb? ( !gdbm? ( sys-libs/gdbm ) )

 One sentence: "WHAT THE HELL?"

 Imagine that it would be dozen of flags. Is it fun to mess with
 deps like this for you?
>>>
>>> Shall we ban this too?
>>>
>>> ffmpeg? ( libav? ( media-video/libav:= ) !libav? (
>>> media-video/ffmpeg:0= ) )
>>>
>>>
>>>
>>>
> 
>> No, because ffmpeg here is a feature AND name of concrete
>> realization. Not ideal case as i would said, but it is acceptable.
> 
>> You want to migrate to such decision? Like:
> 
>> qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) )
> 
>> Fine by me, if you would ask.
> 
>> As i said one message earlier: Something like $(qt_use_default
>> qtgui 5)
> 
>> which will generate something like this:
> 
>> qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) 
>> !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
> 
>> would help too.
> 
> Woah -- why would qt5 be a dep when both flags are off?  If you have a
> package that -needs- one version enabled, then in that case I do fully
> support REQUIRED_USE="|| ( qt4 qt5 )".  '||' being the one-or-more-of
> operator.
> 
> The other alternative here would be that there is no qt5 flag, just a
> qt4 one, and the qt4 one toggles qt5 off and qt4 on.  And that just
> isn't pretty, so let's not do that.
> 
> And using this form of REQUIRED_USE I believe (if I understand what
> QA's and QT's stances are on this) is not in conflict with either
> group, right?
> 
> 
> 
> 

Again - i am talking about package that CAN not be build without ANY of
Qt GUIs.

If it can be build without GUIs at all - THAT'S A DIFFERENT STORY and
solution for it is diffirent

Sorry for the caps, but i am a bit tired of repeating myself.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: useflag policies

[Sergey Popov]

12.08.2015 22:14, Peter Stuge пишет:
> May I suggest instead:
> 
> qt? (
>   qt5? ( dev-lang/qt$something:5 )
>   qt4? ( dev-lang/qt$something:4 )
> )

And what would be if USE="qt -qt4 -qt5"? Should we introduce a
REQUIRED_USE for that? Well, congrats then, USE qt becomes useless,
cause it does not improve the situation in case of 'at-most-one-of'
implementation.

e.g.

REQUIRED_USE="qt? ( ^^ ( qt4 qt5 ) )" simple shrinked to current
REQUIRED_USE="^^ ( qt4 qt5 )"

Again, it's about packages that can not be build with both
implementations at the same time

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Cleaning up integration of external repos into ::gentoo

[Andrew Savchenko]

On Thu, 13 Aug 2015 09:12:30 +0200 Michał Górny wrote:
> Hi,
> 
> Now that we have the official git repository, I've switched user-facing
> git mirrors from rsync->git to the real git. As a result, users are now
> complaining that some random Gentoo metadata has disappeared.
> 
> As you may have noticed already, I am *really* unhappy about adding
> special conditionals with hardcoded URLs (and ugly mixing stuff) for
> Gentoo. So if you really don't want to put the stuff into the repo,
> please at least:

IMO the best way will be to put mandatory stuff in the
repo/gentoo.git.
 
> 1. Move DTDs to a git repository (seriously, I don't want to have to
> touch CVS).
> 
> 2. Strip the year from gentoo-news [1]. I think we have all
> the agreement to proceed there. I will prepare a GLEP update today,
> and if given OK, I can update the repo, and the scripts.
> 
> 3. Provide a machine-readable description where those files/directories
> come from. Not sure how that should look but how about something along
> the lines of repos.conf:
> 
>   metadata/external-repos.conf::
> 
> [gentoo-news]
> location = metadata/news
> sync-type = git
> sync-uri = https://anongit.gentoo.org/proj/gentoo-news.git
> 
> [herds]
> location = metadata/herds.xml
> # or do we want to use git here?
> sync-type = http
> sync-uri = https://api.gentoo.org/packages/herds.xml
> 
> Comments?
> 
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=523828
> 


Best regards,
Andrew Savchenko


pgpNLZPekZdtL.pgp
Description: PGP signature

Re: [gentoo-dev] Cleaning up integration of external repos into ::gentoo

[Rich Freeman]

On Thu, Aug 13, 2015 at 5:26 AM, Andrew Savchenko  wrote:
> On Thu, 13 Aug 2015 09:12:30 +0200 Michał Górny wrote:
>> Hi,
>>
>> Now that we have the official git repository, I've switched user-facing
>> git mirrors from rsync->git to the real git. As a result, users are now
>> complaining that some random Gentoo metadata has disappeared.
>>
>> As you may have noticed already, I am *really* unhappy about adding
>> special conditionals with hardcoded URLs (and ugly mixing stuff) for
>> Gentoo. So if you really don't want to put the stuff into the repo,
>> please at least:
>
> IMO the best way will be to put mandatory stuff in the
> repo/gentoo.git.

Tend to agree.  The main reason not to would be if they were
maintained by different groups and we wanted to control access.  If
"news" were about PR that might be a real issue, but the GLEP news is
more about package notifications, and the security team probably also
needs tree access as well, so at least at present I'm not sure I see
the need to separate them.  GLSA state is also pretty closely
associated with tree state so it really seems like it should be in the
tree.

If we do go the route of a machine-readable external-repos.conf or
something like that then perhaps it would make sense to have the
client just sync this directly, rather than gluing it all together
before sending it to them.  That would also simplify things.

-- 
Rich

Re: [gentoo-dev] Re: Referencing bug reports in git

[Ben de Groot]

I vote for a simple

Bug: 333531

If it is going to be any longer than that, then you need to make sure
it is part of the commit message template magic. Because I'm surely
not the only one who is lazy and thus averse to typing anything longer
for the most common use case: Gentoo bugs.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Re: Referencing bug reports in git

[Rich Freeman]

On Thu, Aug 13, 2015 at 7:19 AM, Ben de Groot  wrote:
> I vote for a simple
>
> Bug: 333531
>
> If it is going to be any longer than that, then you need to make sure
> it is part of the commit message template magic. Because I'm surely
> not the only one who is lazy and thus averse to typing anything longer
> for the most common use case: Gentoo bugs.
>

++ laziness

I don't mind it being a URL, but stick the header in the template (way
easier to delete it than to type it),

If it is a URL, please make it whatever is already in my browser
address bar.  A nice shorthand URL looks pretty but it isn't so pretty
if I have to edit it instead of just hitting copy/paste.  When I'm
fixing bugs I have the bug open in a browser already, since the next
step after committing the fix is going to be closing the bug.

Otherwise, I really don't care.  "Bug" gets the job done.  I haven't
seen any recent proposals that include the "X-" but that is one thing
I'd definitely avoid per the RFC.

-- 
Rich

[gentoo-dev] Re: useflag policies

[Michael Palimaka]

On 13/08/15 18:17, Sergey Popov wrote:
> 11.08.2015 16:49, Michael Palimaka пишет:
>>> You think that REQUIRED_USE is abusive to users: fine. Point accepted.
>>> I think that provided DEPEND strings if they will be typed at every
>>> single qt-related ebuild that needs them are abusive to developers.
>>>
>>> So, maybe we should wrap them into eclass and stop riding our own
>>> bicycles...
>>>
>>> And then - use apropriate one-liner where it's needed, providing
>>> reasonable default and NOT confusing users with overmanaging their
>>> package.use
>>>
>>
>> Please read Ben's original post again. Dependency strings are not the topic.
>>
>>
> 
> If introducing new USE-flags or ignoring using REQUIRED_USE leads to
> blowing the DEPEND variable, adding pain for the developers - it is the
> topic, definitely
> 

Seriously, read the original post again. It's about handling of packages
that offer a choice between qt4 and qt5 and how to present that to the user.

It's not about the size of dependency strings, banning REQUIRED_USE,
project policy enforcement or anything else. If you wish to discuss
those topics please create a new thread and stop derailing this one.

Re: [gentoo-dev] .gitignore

[wireless]

On 08/12/2015 09:52 PM, Mike Frysinger wrote:

On 12 Aug 2015 18:27, Brian Dolbec wrote:

2)  There is another alternate location that you can define files to
ignore locally without having to commit them to .gitignore.
Consider .gitignore a global setting.  There is another setting
inside .git/info/exclude which is a local config file that will persist
and not be affected by pulls.

   So please use that for local exclusions you want to add and not try to
   force them into a global .gitignore which is part of the repo.
   Something that seems to be hotly debated. ;)


as i stated, there's no reason for these paths to ever be committed.
conversely, some people (not unreasonably so) will place files in there
that have historically had known meanings.  adding these to the global
gitignore is simply the right thing to do and negatively impacts no one.
-mike


As a gentoo user now coding again, I find the need to have things 
"logically organized" really helps in my efforts. Like most others, I 
get codes from a variety of places and try to follow the 'logical gentoo 
organization'. I use /usr/local/portage extensively for ebuilds

that I develop. There is also /opt/ which seems to collect up a variety
of ebuilds. Some, are there as part of their lineage that nobody bothered
to change (net-analyzer/jffnms) others are there for license or 'fit' 
reasons   Maybe a survey of codes placed into /opt/ should also be 
examined as part of these migration efforts?



I also experiment around with a variety of sources and I think (old bsd 
habits) that these should also be under /usr/local/. My point is this::
please keep in mind those that use gentoo for software development 
outside the dev teams as they have needs for logical organization that 
mostly follows the 'gentoo way' as you devs finalize the 'gentoo way' 
for code(s) management. Combined with this is the need to organize where
the gentoo community should push their ebuilds  which will end up being 
pushed towards the portage tree. I.E. clearly define the pathways like 
Sunrise, user-overlays and the corresponding admin semantics. Otherwise 
we'll end up with lots of viable but unique pathways and that will just 
add to the support burden on lists like gentoo user and for those 
mentors as well as the 'preferred or consensus' configuration for git by 
user's coding needs.



hth,
James

Re: [gentoo-dev] .gitignore

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/08/15 09:27 PM, Brian Dolbec wrote:
> 2)  There is another alternate location that you can define files
> to ignore locally without having to commit them to .gitignore. 
> Consider .gitignore a global setting.  There is another setting 
> inside .git/info/exclude which is a local config file that will
> persist and not be affected by pulls.
> 
> So please use that for local exclusions you want to add and not
> try to force them into a global .gitignore which is part of the
> repo. Something that seems to be hotly debated. ;)

...but are you saying then that there would be a case where we want
dev's to be able to commit these paths into the tree??  I would
think we would want these in global .gitignore primarily because we
want to be sure no errant newbie dev (or newtogit dev) that happens
to use one of these paths ends up committing something that adds them.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXMprMACgkQAJxUfCtlWe3ZQAD/d9x9H5z3GrfXhhxaoeuWRcWb
XqAVzBr0tpkuwUFwl4oA/2uIJWkWGZU9ny7J6Px3kA1axl8hEGoJJnKDwJL9CKzz
=Rrq6
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/08/15 04:24 AM, Sergey Popov wrote:
> 11.08.2015 17:56, Ian Stakenvicius пишет:
>> BUT I would advise against this.  If a user has specified both
>> qt4 and qt5 in USE, then I see no problem with the VDB having
>> both qt4 and qt5 atoms listed as dependencies.  End-users that
>> want a clean VDB can just make sure they only enable one flag,
>> but end-users that don't care will have packages that just
>> work.
>> 
> 
> great, in that case emerge --depclean becomes completely
> useless, because of unneeded vdb deps. Those DEPENDs that i have
> provided was at least consistent in terms of dependencies(that
> does not mean that they are not ugly, though)
> 

No it doesn't.  It's true that it doesn't end up providing a
necessarily fully clean system when both flags are enabled, but
there's nothing to keep end-users (or the profiles, when they
change) from disabling the qt4 flag on their own terms to get a
cleaner system.

My entire point here is using the BFH of REQUIRED_USE to force
end-users to take manual action on emerge, just because some dev's
want them to have a cleaner system via --depclean, -especially- when
there aren't any conflicts between the qt4 and qt5 deps being
installed at the same time, is to the detriment of end users much
more than the extra libs in the system image.

If qt4 and qt5 libs collided or conflicted, then this would be a
different story, but they don't.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXMqToACgkQAJxUfCtlWe3tDgEAjPRuf+zAFhYWYNyLefIptPnT
0y3Z2UuOIBO2Bdmqp1oBAJgIMpH5c95dKXkskL/UzvYhgdG4Z8vPDbCjKc/NMZ8g
=j8+H
-END PGP SIGNATURE-

Re: [gentoo-dev] .gitignore

[Brian Dolbec]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 13 Aug 2015 10:16:19 -0400
Ian Stakenvicius  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 12/08/15 09:27 PM, Brian Dolbec wrote:
> > 2)  There is another alternate location that you can define files
> > to ignore locally without having to commit them to .gitignore. 
> > Consider .gitignore a global setting.  There is another setting 
> > inside .git/info/exclude which is a local config file that will
> > persist and not be affected by pulls.
> > 
> > So please use that for local exclusions you want to add and not
> > try to force them into a global .gitignore which is part of the
> > repo. Something that seems to be hotly debated. ;)
> 
> ...but are you saying then that there would be a case where we want
> dev's to be able to commit these paths into the tree??  I would
> think we would want these in global .gitignore primarily because we
> want to be sure no errant newbie dev (or newtogit dev) that happens
> to use one of these paths ends up committing something that adds them.
> 
>

No, there clearly should be some things that are commonly present
that should never be committed.  Those common things should be in a
global .gitignore.  I did not read the entire thread(s) but it seemed
there was more bikeshedding that was necessary.  I had not seen
mention of an alternate git ignore setting that could be used without
the need to have a locally modified .gitignore that someone must
constantly refrain from committing with git constantly reminding them
it has been modified and lest they be chastised for committing it ;)  


- -- 
Brian Dolbec 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVzK0NXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG
QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YCDMP+gKPxS1ZrxJ7zdsIekegOBbm
2EeI9X5oD/F3sZGx7GVcpn+0Niry1Cyr69ZS31tdbMR9cFQNeR0TfofbEx66EaSW
FS/tzqAV8MV5OFcdSrQeQsSEUEXQcQHpTDl6NMLEKkVL3fWaqa/HJJvuw3x4OvMp
iJby8FCuZP9k8xu7M4X/etbKN5b/a6AW3CyLYqFkTx/QXE7yvKKeURFsYyqbdZQs
vgvg+jIutq9JsOvk+wOdr97rnu2lZ1qMRhgTjk/dM26aIU/oGfC7VwaN88rka6O0
KteeFUAIXRE1Q9RSi2tJDiwqGkNJYMqBFI4pxIRCV+0Nj76vV0EwuHBhtIn8ANsr
mEjhpuXb/RXr9+7FrNCJc75czJGu2lCz28REhdc8gyk+nwTbis4xrqAlovcrIk7T
MgbUXQqflL4+dhgPMRvR2qaS5NtCBjoFAlNoc6xkB0O/G+SJC1LDQquUd5SkPU0A
pdbrlqsona5PLR3bZx7HyySVkVFQDv04/cOo6kdu+u5fo3FOcbpgCVsyOpcjMIjR
tGdTaKLLkSJJP0HOVl61qhg9KRYy1FsVvxdb/WHi5X4g7o7qMfuQPps6TKXgtBqW
AICQB+v5yc5NFeS06v0sdKtVXxbM00d1KmpkEi6F6SaRQCh1lQY7sI16EOtt4iii
oaA+oQuTSCf7sJEUFkGV
=gYWV
-END PGP SIGNATURE-

[gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[William Hubbs]

All,

I understood the usefulness of this line to some when we were using CVS
since it expanded into the ebuild revision, date, etc.

This expansion doesn't take place under git, so now I don't understand
the usefulness of this line. If I have missed something, can someone
fill me in, or if it isn't useful any more can we consider removing it?

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Mikle Kolyada]

13.08.2015 18:36, William Hubbs пишет:
> All,
>
> I understood the usefulness of this line to some when we were using CVS
> since it expanded into the ebuild revision, date, etc.
>
> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line. If I have missed something, can someone
> fill me in, or if it isn't useful any more can we consider removing it?
>
> Thanks,
>
> William
>
Hmm, the same question here. As far as i remember git does not depend on
any ebuild's header.

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Matthias Maier]

> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line. If I have missed something, can someone
> fill me in, or if it isn't useful any more can we consider removing it?

It is possible to define custom keyword expansions for $Id$ with
.gitattributes (man gitattributes /ident).

This might be of some use when converting a given git checkout to a tree
snapshot, etc.

Best,
Matthias



signature.asc
Description: PGP signature

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Mike Frysinger]

On 13 Aug 2015 10:36, William Hubbs wrote:
> I understood the usefulness of this line to some when we were using CVS
> since it expanded into the ebuild revision, date, etc.
> 
> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line. If I have missed something, can someone
> fill me in, or if it isn't useful any more can we consider removing it?

delete it and be done
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Tyler Pohl]

Can someone please tell me how to get off this mailing list?  Please please
please
On Aug 13, 2015 8:37 AM, "William Hubbs"  wrote:

> All,
>
> I understood the usefulness of this line to some when we were using CVS
> since it expanded into the ebuild revision, date, etc.
>
> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line. If I have missed something, can someone
> fill me in, or if it isn't useful any more can we consider removing it?
>
> Thanks,
>
> William
>
>

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Matt Turner]

On Thu, Aug 13, 2015 at 9:18 AM, Tyler Pohl  wrote:
> Can someone please tell me how to get off this mailing list?  Please please
> please

Well first you don't reply to an unrelated topic...

But the instructions are here:
https://www.gentoo.org/get-involved/mailing-lists/instructions.html

(the thing you find by googling something like "gentoo unsubscribe")

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Rich Freeman]

On Thu, Aug 13, 2015 at 12:12 PM, Mike Frysinger  wrote:
> On 13 Aug 2015 10:36, William Hubbs wrote:
>> I understood the usefulness of this line to some when we were using CVS
>> since it expanded into the ebuild revision, date, etc.
>>
>> This expansion doesn't take place under git, so now I don't understand
>> the usefulness of this line. If I have missed something, can someone
>> fill me in, or if it isn't useful any more can we consider removing it?
>
> delete it and be done

When I asked a few days ago the arugment was made that it will be
expanded when the ebuilds hit rsync, and then users can reference
these when submitting bugs so that devs know what revision they're
using/etc.  It was stated that this was a highly-requested feature.

I'm still personally leaning towards delete it and be done for a few reasons:

1.  If the user syncs from git and not from rsync (which I suspect
will be come steadily more popular - git is very efficient at syncing
though it takes more space), then they won't get the hash, though they
can of course just ask git for it.

2.  Users don't routinely attach ebuilds to bugs, so we'll still be
pestering them for this info.

3.  That hash doesn't provide any kind of at-a-glance info anyway.
You're going to to have to ask git what it is.  It is a unique ID for
the file though.

I think IDs embedded in files make more sense for workflows that
envision a lot of out-of-git work, since they tie back into the git
tree.  If you stay in git all the time, they're redundant.

But, the biggest reason IMHO is that it is in-band signaling and I can
forsee all the issues we ran into with cvs keywords.  The git
validation and migration work constantly ran into this as probably our
#1 unfixable problem, and Robin's go-live emails indicated that we
still had tons of patches that had keyword expansion issues.  The job
of an scm should be to store files and regurgitate them on request.
If you ask it to also mangle their contents you're inevitably asking
it to mangle their contents in ways you didn't forsee.

-- 
Rich

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Ulrich Mueller]

> On Thu, 13 Aug 2015, Rich Freeman wrote:

> On Thu, Aug 13, 2015 at 12:12 PM, Mike Frysinger  wrote:
>> delete it and be done

+1

> When I asked a few days ago the arugment was made that it will be
> expanded when the ebuilds hit rsync, and then users can reference
> these when submitting bugs so that devs know what revision they're
> using/etc.  It was stated that this was a highly-requested feature.

If this is "a highly-requested feature" then some discussion or other
reference to it should exist in mailing lists. I can neither remember
nor can I find such a discussion.

So, could someone please provide a pointer to when and where keeping
the $Id$ line was requested?

Ulrich


pgpX0gJGUPvFi.pgp
Description: PGP signature

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Michał Górny]

Dnia 2015-08-13, o godz. 19:13:06
Ulrich Mueller  napisał(a):

> > On Thu, 13 Aug 2015, Rich Freeman wrote:
> 
> > On Thu, Aug 13, 2015 at 12:12 PM, Mike Frysinger  wrote:
> >> delete it and be done
> 
> +1
> 
> > When I asked a few days ago the arugment was made that it will be
> > expanded when the ebuilds hit rsync, and then users can reference
> > these when submitting bugs so that devs know what revision they're
> > using/etc.  It was stated that this was a highly-requested feature.
> 
> If this is "a highly-requested feature" then some discussion or other
> reference to it should exist in mailing lists. I can neither remember
> nor can I find such a discussion.
> 
> So, could someone please provide a pointer to when and where keeping
> the $Id$ line was requested?

Just to be clear, Infra did it and replaced all $Header$ with $Id$.
Removing it right now without discussion with them would be wrong.

-- 
Best regards,
Michał Górny



pgpHf5ldqRplA.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

On Thu, 13 Aug 2015 08:44:58 +0800
Patrick Lauer  wrote:
> On 08/12/15 22:38, William Hubbs wrote:
> > I always wondered why pkg_pretend never caught on.
> 
> Because, in a way, it triggers at the wrong point of the merge.
> 
> emerge -pv fnurk => dependencies look ok
> 
> emerge fnurk => pkg_pretend bails out ... eh?!
> 
> (This would be a little bit confusing, if not actively hostile, and
> useflags + required_use are a lot more 'natural' to the emerge
> workflow)

Uh, the point of the 'pretend' bit in the name is that it *is* run when
you do emerge -p.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Mike Gilbert]

On Thu, Aug 13, 2015 at 1:13 PM, Ulrich Mueller  wrote:
>> On Thu, 13 Aug 2015, Rich Freeman wrote:
>
>> On Thu, Aug 13, 2015 at 12:12 PM, Mike Frysinger  wrote:
>>> delete it and be done
>
> +1
>
>> When I asked a few days ago the arugment was made that it will be
>> expanded when the ebuilds hit rsync, and then users can reference
>> these when submitting bugs so that devs know what revision they're
>> using/etc.  It was stated that this was a highly-requested feature.
>
> If this is "a highly-requested feature" then some discussion or other
> reference to it should exist in mailing lists. I can neither remember
> nor can I find such a discussion.

FYI, there has been one bug report about it since the git migration happened.

https://bugs.gentoo.org/show_bug.cgi?id=557386

To quote the reporter:

"Whilst many users may not care, this makes it much more difficult to
tell whether a change has been made to an ebuild without a
version-bump - and in my specific case, I maintain an overlay repo
which attempts to track upstream, and this has removed my ability to
(again, easily) tell if a minor update has been made to an ebuild I've
overlaid."

[gentoo-dev] rsync->git mirror discontinued, repo mirror & CI updates

[Michał Górny]

Hello, everyone.

The official git migration inspired some real changes in the semi-
related Git mirror [1] and Repo mirror & CI [2] projects. In this mail,
I'd like to shortly summarize what changed and how to proceed forward.

TL;DR, short summary:

1. rsync->git mirror has been disabled and the project obsoleted.

2. Pull requests are now handled on official repo mirror [3].

3. User syncing can be done via cache-enabled mirror [4] maintained by
'Repository mirror & CI' project. The mirror has less lag than the old
one, and is updated every 20 minutes.

4. All user syncing mirrors [5] now retain history from git & svn,
and can be used with layman using alternative repositories.xml [6].

5. Travis CI is not used at the moment. However, repo mirror & CI runs
pkgcheck every 30 minutes and publishes the results at [11].


rsync->git mirror
=

The rsync->git mirror has been officially disabled. Since the Gentoo
repository is now in git, there is no point in mirroring from rsync.
All the remaining Pull Requests were closed with an explanatory note
referring to the new official mirror.

I'd like to thank all the people who run and supported the mirror,
and to all our contributors. You've been doing a great job, and made
this effort beneficial to Gentoo. Hope to see you soon on the new
mirror :).


Pull requests on the official mirror


While the reference copy of our repository [7] is hosted by our
Infrastructure, we are also running an official GitHub mirror [3].
The mirror is updated by gitolite automatically on each push,
and therefore is always up-to-date and does not require any effort from
Gentoo developers.

The official mirror also accepts pull requests from our community.
Unlike with the rsync->git mirror, the commits can be merged directly
in the repository, making contributing via pull requests much closer to
being a Gentoo developer.

For users willing to contribute, I suggest reading our Git workflow
[8] documentation and either the key requirements listed in GLEP 63 [9],
or the instructions for generating matching keys [10]. If you can
provide a nicely fit commit with proper message and signature, you
can get all the kudos :).

For developers willing to help, proper reviews and assignments of pull
requests is always welcome. We'd like pull requests to provide both
the means to contribute easily and efficiently, and to help our users
improve their ebuild skills and join the developer community in
the future! So if you decide to fix minor issues with the contributions
yourself, please leave an explanatory comment so that the contributor
does not repeat the same mistake.

Please also remember to ping package maintainers. We usually do that
through @-highlights in comments. The developers who are direct package
maintainers can be referenced directly (@mgorny), while teams and
projects can be referenced via GitHub teams (@Gentoo/qt). Sadly, only
a handful of the teams is mirrored on GitHub right now and organization
admin rights are required to add new teams, so you'd have to ping one
of the 'Owners' (usually me) to mirror more as necessary.


User syncing mirror
===

Being the development repository, the official git mirror lacks
metadata cache and other external resources and therefore is not
suitable for user syncing. For this goal, I recommend using
the syncing mirror [4] that has been provided by the Repository mirror
& CI project [2] for some time already.

This mirror combines the development repository history with
pre-generated caches. Currently it misses the external resources
(DTDs, GLEPs, news items, herds.xml) but there is an ongoing effort of
finding a clean way to merge them.

The mirror also preserves the original commit signatures, though the
merge commits and cache update commits are not signed at the moment.
For verification, I recommend verifying top-most original commit
signature and 'git diff'-ing HEAD to it to confirm that only caches were
modified/added.

It should be also noted that since the mirror is created from
the original repository rather than from poorly-timed rsync snapshots
of the repository, it has less lag.


Repository mirror updates
=

Given the necessity of improving Gentoo repository mirroring, I've
prepared and deployed a few improvements to the repository mirrors [5].

First of all, the mirroring scripts now output a repositories.xml [6]
file that can be used as a drop-in replacement for the official list,
replacing the upstream source locations with our mirrors. So if you'd
like layman to sync using mirrors with pre-generated metadata cache,
just use the following in layman.cfg:

  overlays  :
https://api.gentoo.org/overlays/repositories.xml
https://gentoo.github.io/repo-qa-check-results/repositories.xml

Secondly, the mirrors now preserve the commit history from the upstream
repository. The commits from the original repository are merged into
the mirror using

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Ulrich Mueller]

> On Thu, 13 Aug 2015, Michał Górny wrote:

> Dnia 2015-08-13, o godz. 19:13:06
> Ulrich Mueller  napisał(a):

>> If this is "a highly-requested feature" then some discussion or
>> other reference to it should exist in mailing lists. I can neither
>> remember nor can I find such a discussion.
>> 
>> So, could someone please provide a pointer to when and where
>> keeping the $Id$ line was requested?

> Just to be clear, Infra did it and replaced all $Header$ with $Id$.
> Removing it right now without discussion with them would be wrong.

I guess nobody suggests to remove it without discussion.

Still, I'd like to see some evidence for the above claim that keeping
the Id was highly requested.

Ulrich


pgpEoMQAd2AAA.pgp
Description: PGP signature

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

[Andrew Savchenko]

On Thu, 13 Aug 2015 19:13:06 +0200 Ulrich Mueller wrote:
> > On Thu, 13 Aug 2015, Rich Freeman wrote:
> 
> > On Thu, Aug 13, 2015 at 12:12 PM, Mike Frysinger  wrote:
> >> delete it and be done
> 
> +1

+1 to remove this CVS remnant. It was needed before, it is not
really needed now.
 
Best regards,
Andrew Savchenko


pgp0tGaNtp_On.pgp
Description: PGP signature

[gentoo-dev] Infra plans regarding $Id$ - official answer...

[Robin H. Johnson]

On Thu, Aug 13, 2015 at 10:36:16AM -0500, William Hubbs wrote:
> I understood the usefulness of this line to some when we were using CVS
> since it expanded into the ebuild revision, date, etc.
> 
> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line. If I have missed something, can someone
> fill me in, or if it isn't useful any more can we consider removing it?
The following is the official answer of Infra, regarding the $Id$
expansion.

The intent is that the ONLY place the keywords are expanded, will be in
the rsync export. FUTURE tense, it's not ready yet.

If there is demand (and I think the consensus is
actually the OPPOSITE), we could also have it expand on your local
checkouts.

It expands to the hash of the blob of that file; and from that, you can
identify which commits the blob exists in.

The primary use case of it is to allow users to easily see what version
of a given ebuild they are using.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Maxim Koltsov]

11 авг. 2015 г. 17:33 пользователь "Michał Górny" 
написал:
>
> Hello, everyone.
>
> Now that we're officially on git and can officially use pull requests
> to provide rapid community interaction, it'd be convenient to have
> a little better framework for pinging package maintainers.
>
> With the unofficial mirror/pull request project, I was either looking
> for project member GitHub accounts and pinging found project members by
> name, or talking to them directly on IRC. However, with the growth in
> number of pull requests this will become more and more inconvenient.
> Therefore, I think it's time to be able to mirror teams willing to work
> with GitHub community there for easier 'pings'.
>
> I have two ideas right now:
>
> 1. creating GitHub Gentoo project teams corresponding to willing Gentoo
> teams,
>
> 2. preparing lists of GitHub usernames on project wiki pages.
>
> Solution 1. is cleaner. In this case, we create GitHub teams under
> the Gentoo projects, and add appropriate Gentoo developers having
> GitHub accounts to the teams. Then, in PRs we can just ping the whole
> team like @Gentoo/Qt or like.
>
> Solution 2. avoids adding any GitHub teams. In this case, in team wiki
> page we collect team member usernames like "@Pesa, @kensington, ..." so
> we could copy-paste it to pull requests. We still require extra effort
> when 'assigning' PRs but at least I don't have to lookup the same
> people over and over again.
>
> With some Wiki people help, we could even implement updating GitHub
> teams automatically following Wiki member changes.
>
> Your thoughts?

Hi Michał!
Mirroring teams on GH is a great idea. I have a question though.
Is it OK that highlight links from GH emails and GH pages (like
'@gentoo/qt',  etc) lead to GitHub's 404 page?

> --
> Best regards,
> Michał Górny
> 

[gentoo-dev] git history older than "proj/gentoo: Initial commit" (56bd759)

[Paweł Hajdan, Jr.]

I'd like to start with: kudos for the very skilfully performed migration
from CVS to git! I just committed a simple changed and it worked great.

I was curious and started exploring the repo a little bit, and the
initial commit says:

> This commit is the start of the NEW history.
> Any historical data is intended to be grafted onto this point.

Is the historical data available now? Is it still work in progress?

I've checked the following two places looking for related documentation
but didn't find anything:




Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Rich Freeman]

On Thu, Aug 13, 2015 at 3:43 PM, Robin H. Johnson  wrote:
>
> The intent is that the ONLY place the keywords are expanded, will be in
> the rsync export. FUTURE tense, it's not ready yet.
>

Will that include any case where the string "$Id$" appears in a patch file?

That is the main source of problems here.

Really, anytime what the dev tests and commits is different from what
the users see is a potential source of problems.

-- 
Rich

Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Michał Górny]

Dnia 2015-08-13, o godz. 22:53:11
Maxim Koltsov  napisał(a):

> 11 авг. 2015 г. 17:33 пользователь "Michał Górny" 
> написал:
> >
> > Hello, everyone.
> >
> > Now that we're officially on git and can officially use pull requests
> > to provide rapid community interaction, it'd be convenient to have
> > a little better framework for pinging package maintainers.
> >
> > With the unofficial mirror/pull request project, I was either looking
> > for project member GitHub accounts and pinging found project members by
> > name, or talking to them directly on IRC. However, with the growth in
> > number of pull requests this will become more and more inconvenient.
> > Therefore, I think it's time to be able to mirror teams willing to work
> > with GitHub community there for easier 'pings'.
> >
> > I have two ideas right now:
> >
> > 1. creating GitHub Gentoo project teams corresponding to willing Gentoo
> > teams,
> >
> > 2. preparing lists of GitHub usernames on project wiki pages.
> >
> > Solution 1. is cleaner. In this case, we create GitHub teams under
> > the Gentoo projects, and add appropriate Gentoo developers having
> > GitHub accounts to the teams. Then, in PRs we can just ping the whole
> > team like @Gentoo/Qt or like.
> >
> > Solution 2. avoids adding any GitHub teams. In this case, in team wiki
> > page we collect team member usernames like "@Pesa, @kensington, ..." so
> > we could copy-paste it to pull requests. We still require extra effort
> > when 'assigning' PRs but at least I don't have to lookup the same
> > people over and over again.
> >
> > With some Wiki people help, we could even implement updating GitHub
> > teams automatically following Wiki member changes.
> >
> > Your thoughts?
> 
> Hi Michał!
> Mirroring teams on GH is a great idea. I have a question though.
> Is it OK that highlight links from GH emails and GH pages (like
> '@gentoo/qt',  etc) lead to GitHub's 404 page?

It seems that team pages are only visible to team members and admins,
for some reason. I don't see any option to change that so I suppose
that's how GitHub works...

-- 
Best regards,
Michał Górny



pgppySBwUVQA5.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] git history older than "proj/gentoo: Initial commit" (56bd759)

[Dirkjan Ochtman]

On Thu, Aug 13, 2015 at 9:55 PM, "Paweł Hajdan, Jr."
 wrote:
> Is the historical data available now? Is it still work in progress?

Good question!

I'd all be interested in some ballpark figures about the size of such a thing.

Cheers,

Dirkjan

Re: [gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Gilbert]

On Wed, Aug 12, 2015 at 11:17 PM, Mike Frysinger  wrote:
> ---
>  .../2015-08-13-openssh-weak-keys.en.txt| 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 
> 2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt
>
> diff --git 
> a/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt 
> b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt
> new file mode 100644
> index 000..8dece5e
> --- /dev/null
> +++ b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt
> @@ -0,0 +1,26 @@
> +Title: OpenSSH 7.0 disables ssh-dss keys by default
> +Author: Mike Frysinger 
> +Content-Type: text/plain
> +Posted: 2015-08-13
> +Revision: 1
> +News-Item-Format: 1.0
> +Display-If-Installed: net-misc/openssh
> +
> +Starting with the 7.0 release of OpenSSH, support for ssh-dss keys has
> +been disabled by default at runtime.  If you rely on these key types,
> +you will have to take corrective action or risk being locked out.
> +
> +Your best option is to generate new keys using newer types such as rsa
> +or ecdsa or ed25519.  RSA keys will give you the greatest portability
> +with other clients/servers while ed25519 will get you the best security
> +with OpenSSH (but requires recent versions of client & server).
> +
> +If you are stuck with DSA keys, you can re-enable support locally by
> +updating your sshd_config file with a line like so:
> +   PubkeyAcceptedKeyTypes=+ssh-dss
> +
> +Be aware though that eventually OpenSSH will drop support for DSA keys
> +entirely, so this is only a stop gap solution.
> +
> +More details can be found on OpenSSH's website:
> +   http://www.openssh.com/legacy.html

I think this should also mention that PubkeyAcceptedKeyTypes applies
to the ssh client, and can be added to ~/.ssh/config.

Re: [gentoo-dev] git history older than "proj/gentoo: Initial commit" (56bd759)

[Rich Freeman]

On Thu, Aug 13, 2015 at 3:55 PM, "Paweł Hajdan, Jr."
 wrote:
> I'd like to start with: kudos for the very skilfully performed migration
> from CVS to git! I just committed a simple changed and it worked great.
>
> I was curious and started exploring the repo a little bit, and the
> initial commit says:
>
>> This commit is the start of the NEW history.
>> Any historical data is intended to be grafted onto this point.
>
> Is the historical data available now? Is it still work in progress?
>

The official version is still pending.

My unofficial version (which as far as I can tell is about as good as
it is going to get, but consider it draft) is at:
https://github.com/gentoo/gentoo-gitmig-20150809-draft

(The official version will no doubt be hosted on pure-FOSS infra.)

You can graft them using git replace --graft I believe, though I
haven't actually tried this.  In theory you can do this as many times
as you wish as improved historical migrations come along, and as long
as you get rid of all the refs to the old heads git will eventually
garbage-collect the junk.

There are 2M commits, and probably about 10x as many objects.  A
bundle is 1.7G (and is compressed), so expect a clone to take a while.
I have to say that github has gotten better at handling it - my first
pushes of migrations a year ago would die with an error and then the
repo would just show up in github a few hours later.  Now the pushes
succeed and the repo shows up fairly quickly after they are finished.


-- 
Rich

[gentoo-dev] Last rites: Nepomuk & Co / virtuoso.eclass

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Eclass:
virtuoso.eclass is only used by dev-db/virtuoso-odbc and
dev-db/virtuoso-server. Will be removed in 30 days as well.

Packages:
# Johannes Huber  (13 Aug 2015)
# Nepomuk removal. Announced via portage news item on 2015/08/11.
# Removal in 30 days. Please switch to the default semantic desktop
# search engine Baloo by globally enabling semantic-destkop use
# flag or by using one of the provided kde/plasma desktop profiles.
dev-db/virtuoso-odbc
dev-db/virtuoso-jdbc
dev-db/virtuoso-server
dev-libs/shared-desktop-ontologies
dev-libs/soprano
dev-util/plasmate
kde-apps/nepomuk
kde-base/nepomuk-core
kde-base/nepomuk-widgets
kde-misc/ksoprano
kde-misc/nepomukshell
kde-misc/pgame
media-video/bangarang

- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVzRCfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vqV8P/04gM1nVzt5R12rSw4OqVJdb
JQM/I87X6qZ2xMk9H7VrUsNMgPjSHMQe2uYFoTFzAvoF1JaE2lgGAgP5yIKiP1qs
d3s8tTJGnUxRNeJlLNgB1Hd/lNC0IdWqYGhq6eN+NJ3goSL3AEgKWO5VnQDcaPfO
MzqQLEhr5lrWErX3LGjqpGKgDpU9tkP2pQXLZUVsLrBjyZGN32oeYP29s2jPK84A
+B3QwcLflnI2RlnaMYuXOnDjVryJilttUqkUG16n5Zm14dVq2IxQ1iJ45HlJNiz5
8JThOc7akiG3+WMQ9Tl3woYjxUcbN/zdFbjLc5QWkCudbWHvnriRV/Nz8WdSbMaA
REkaVAQVeEVr5bGOVHJ5YS5VDzikRq1P0CTWERWn+lHcut2AVpavrtQVZBM/u/t/
DoCrSh5KSLSZckzxkJeP1WSJubTesI/KiRlRzlCUg8O3TUvKEqIumL4ZkpFx7U4m
NCPkXG4KnZpWY6UZBhjbPSsHwYSUACLgRlMna9fIzDwdsqBLMnGyiyzP5fXhicsN
BcOha7+QBCaWjX0nZZWb/BQDpnQNkVLniV8cHN/M4OK/QK4O3mpZ767HSOUho/2S
FxpeT8BycZRm5IQP/2nBtsI5n/L+AHtTiuhU3jk1ySc/zAK/W6td0xmgVB40Adby
dkZ5XQ99LfXBtrRdZAzS
=Zuh2
-END PGP SIGNATURE-

[gentoo-dev] Re: .gitignore

[Duncan]

wireless posted on Thu, 13 Aug 2015 08:33:13 -0500 as excerpted:

> On 08/12/2015 09:52 PM, Mike Frysinger wrote:
>> On 12 Aug 2015 18:27, Brian Dolbec wrote:
>>> 2)  There is another alternate location that you can define files to
>>> ignore locally without having to commit them to .gitignore.
>>> Consider .gitignore a global setting.  There is another setting inside
>>> .git/info/exclude which is a local config file that will persist and
>>> not be affected by pulls.
>>
>> as i stated, there's no reason for these paths to ever be committed.
>> conversely, some people (not unreasonably so) will place files in there
>> that have historically had known meanings.  adding these to the global
>> gitignore is simply the right thing to do and negatively impacts no
>> one.
> 
> As a gentoo user now coding again, I find the need to have things
> "logically organized" really helps in my efforts. Like most others, I
> get codes from a variety of places and try to follow the 'logical gentoo
> organization'. I use /usr/local/portage extensively for ebuilds that I
> develop. There is also /opt/ which seems to collect up a variety of
> ebuilds


Confused...

What do /opt and /usr/local/portage have to do with the gentoo 
repo's .gitignore, which should only need ignore settings for locations 
inside the main tree, /usr/portage by default?  A .gitignore listing for 
/usr/portage/local and /usr/portage/distfiles, etc, makes sense, since 
that's inside the default tree location.  But /opt and /usr/local/portage 
aren't inside that default location and are thus about as apropos to that 
as the price of tea on Mars, aren't they?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Robin H. Johnson]

On Thu, Aug 13, 2015 at 03:59:37PM -0400, Rich Freeman wrote:
> On Thu, Aug 13, 2015 at 3:43 PM, Robin H. Johnson  wrote:
> > The intent is that the ONLY place the keywords are expanded, will be in
> > the rsync export. FUTURE tense, it's not ready yet.
> Will that include any case where the string "$Id$" appears in a patch file?
Those should be ripped out with extreme prejudice, ditto other
identifiers.

I'm thinking of having an explicit whitelist for expansion, but need to
figure out more consistency for some parts to do it.

> That is the main source of problems here.
> 
> Really, anytime what the dev tests and commits is different from what
> the users see is a potential source of problems.
If you want that, then you can expand it on your local systems.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Rich Freeman]

On Thu, Aug 13, 2015 at 7:28 PM, Robin H. Johnson  wrote:
> On Thu, Aug 13, 2015 at 03:59:37PM -0400, Rich Freeman wrote:
>> On Thu, Aug 13, 2015 at 3:43 PM, Robin H. Johnson  wrote:
>> > The intent is that the ONLY place the keywords are expanded, will be in
>> > the rsync export. FUTURE tense, it's not ready yet.
>> Will that include any case where the string "$Id$" appears in a patch file?
> Those should be ripped out with extreme prejudice, ditto other
> identifiers.
>

Seems like this should be a repoman warning at the very least,
assuming we keep them at all.

>
>> That is the main source of problems here.
>>
>> Really, anytime what the dev tests and commits is different from what
>> the users see is a potential source of problems.
> If you want that, then you can expand it on your local systems.
>

The problem with this is that it depends on every dev doing something.

The original purpose of this was so that people could tell if a file
changes without it being revbumped?  If so, rather than parsing an
sha1 out of the file, why not just hash the file yourself?

-- 
Rich

Re: [gentoo-dev] Re: .gitignore

[wireless]

On 08/13/2015 05:28 PM, Duncan wrote:

wireless posted on Thu, 13 Aug 2015 08:33:13 -0500 as excerpted:


On 08/12/2015 09:52 PM, Mike Frysinger wrote:

On 12 Aug 2015 18:27, Brian Dolbec wrote:

2)  There is another alternate location that you can define files to
ignore locally without having to commit them to .gitignore.
Consider .gitignore a global setting.  There is another setting inside
.git/info/exclude which is a local config file that will persist and
not be affected by pulls.


as i stated, there's no reason for these paths to ever be committed.
conversely, some people (not unreasonably so) will place files in there
that have historically had known meanings.  adding these to the global
gitignore is simply the right thing to do and negatively impacts no
one.


As a gentoo user now coding again, I find the need to have things
"logically organized" really helps in my efforts. Like most others, I
get codes from a variety of places and try to follow the 'logical gentoo
organization'. I use /usr/local/portage extensively for ebuilds that I
develop. There is also /opt/ which seems to collect up a variety of
ebuilds



Confused...

What do /opt and /usr/local/portage have to do with the gentoo
repo's .gitignore, which should only need ignore settings for locations
inside the main tree, /usr/portage by default?  A .gitignore listing for
/usr/portage/local and /usr/portage/distfiles, etc, makes sense, since
that's inside the default tree location.  But /opt and /usr/local/portage
aren't inside that default location and are thus about as apropos to that
as the price of tea on Mars, aren't they?



/distfiles/
/local/
/packages/


Other postings in this thread mention /var/ and /usr/
My bad, I thought those official directories  that were up for 
discussion on gitignore relevancy?


> /usr/portage/local was the original location for the user's own
> personal ebuild space - an "overlay" if you will.
> /usr/portage/distfiles and /usr/portage/packages are there because
> that's where ports has put them for decades, and no-one has gotten
> around to changing it in portage yet. FreeBSD defines the use of /usr
> very differently to what Linux users are used to.
>
> Those dirs really should be in /var/portage, and the user's overlay
> has no business being under main tree itself


Ok, so why is net-analyzer/jffnms found in /usr/portage/distfiles yet it 
is installed in /opt/ ?  If jffnms was (properly) installed like other 
net-analyzer packages, would it not be in the portage tree? There is no 
reason for it to remain in /opt/, that I'm aware of.

But jffnms could benefit form gitignore as other packages do, regardless
of where it is installed.


Looking at the documentation for gitignore it would seem that the 
benefits of using gitignore on those /opt/ packages could be useful; so 
would it not be up to the particular package maintainer to make that 
decision? Regardless of where non-devs develop packages for gentoo,

using gitignore might be useful during the development of the packages,
particularly if it is destine for the portage tree (eventually).

Apologies in advance if I have missed some key points already 
established by the gentoo dev community I'm certainly no whiz with git*.




James

Re: [gentoo-dev] rsync->git mirror discontinued, repo mirror & CI updates

[Joseph Booker]

On Thu, Aug 13, 2015 at 1:42 PM, Michał Górny  wrote:

> Please also remember to ping package maintainers. We usually do that
> through @-highlights in comments. The developers who are direct package
> maintainers can be referenced directly (@mgorny), while teams and
> projects can be referenced via GitHub teams (@Gentoo/qt). Sadly, only
> a handful of the teams is mirrored on GitHub right now and organization
> admin rights are required to add new teams, so you'd have to ping one
> of the 'Owners' (usually me) to mirror more as necessary.
>

Is there any way to reference a team (or even view a list of them) without
being a member of the "Gentoo" organization already?

Re: [gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Frysinger]

On 13 Aug 2015 17:18, Mike Gilbert wrote:
> On Wed, Aug 12, 2015 at 11:17 PM, Mike Frysinger  wrote:
> > +If you are stuck with DSA keys, you can re-enable support locally by
> > +updating your sshd_config file with a line like so:
> > +   PubkeyAcceptedKeyTypes=+ssh-dss
> 
> I think this should also mention that PubkeyAcceptedKeyTypes applies
> to the ssh client, and can be added to ~/.ssh/config.

it applies to both.  if the server doesn't have it, it won't accept what
the client offers.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] git history older than "proj/gentoo: Initial commit" (56bd759)

[Mike Frysinger]

On 13 Aug 2015 17:29, Rich Freeman wrote:
> On Thu, Aug 13, 2015 at 3:55 PM, "Paweł Hajdan, Jr." wrote:
> > I'd like to start with: kudos for the very skilfully performed migration
> > from CVS to git! I just committed a simple changed and it worked great.
> >
> > I was curious and started exploring the repo a little bit, and the
> > initial commit says:
> >
> >> This commit is the start of the NEW history.
> >> Any historical data is intended to be grafted onto this point.
> >
> > Is the historical data available now? Is it still work in progress?
> >
> 
> The official version is still pending.
> 
> My unofficial version (which as far as I can tell is about as good as
> it is going to get, but consider it draft) is at:
> https://github.com/gentoo/gentoo-gitmig-20150809-draft
> 
> (The official version will no doubt be hosted on pure-FOSS infra.)

so we don't have to waste git server resources on it, we could create a git
bundle and mirror that and use http/https to redistribute.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] git history older than "proj/gentoo: Initial commit" (56bd759)

[Rich Freeman]

On Thu, Aug 13, 2015 at 8:38 PM, Mike Frysinger  wrote:
> On 13 Aug 2015 17:29, Rich Freeman wrote:
>> On Thu, Aug 13, 2015 at 3:55 PM, "Paweł Hajdan, Jr." wrote:
>> > I'd like to start with: kudos for the very skilfully performed migration
>> > from CVS to git! I just committed a simple changed and it worked great.
>> >
>> > I was curious and started exploring the repo a little bit, and the
>> > initial commit says:
>> >
>> >> This commit is the start of the NEW history.
>> >> Any historical data is intended to be grafted onto this point.
>> >
>> > Is the historical data available now? Is it still work in progress?
>> >
>>
>> The official version is still pending.
>>
>> My unofficial version (which as far as I can tell is about as good as
>> it is going to get, but consider it draft) is at:
>> https://github.com/gentoo/gentoo-gitmig-20150809-draft
>>
>> (The official version will no doubt be hosted on pure-FOSS infra.)
>
> so we don't have to waste git server resources on it, we could create a git
> bundle and mirror that and use http/https to redistribute.

Absolutely true.  Since it is static it would be pretty trivial to
mirror, bittorrent, or whatever.

-- 
Rich

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Kent Fredric]

On 14 August 2015 at 07:59, Rich Freeman  wrote:
> Will that include any case where the string "$Id$" appears in a patch file?


Surely that can be avoided by using a git attributes specification
that only applies to  */*/*.ebuild ?

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Dean Stephens]

On 08/13/15 02:15, Michał Górny wrote:
> Dnia 2015-08-12, o godz. 22:43:24 Dean Stephens
>  napisał(a):
> 
>> On 08/11/15 10:32, Michał Górny wrote:
>>> Hello, everyone.
>>> 
>>> Now that we're officially on git and can officially use pull 
>>> requests to provide rapid community interaction, it'd be
>>> convenient to have a little better framework for pinging
>>> package maintainers.
>>> 
>>> With the unofficial mirror/pull request project, I was either 
>>> looking for project member GitHub accounts and pinging found 
>>> project members by name, or talking to them directly on IRC. 
>>> However, with the growth in number of pull requests this will 
>>> become more and more inconvenient. Therefore, I think it's time
>>> to be able to mirror teams willing to work with GitHub
>>> community there for easier 'pings'.
>>> 
>>> I have two ideas right now:
>>> 
>>> 1. creating GitHub Gentoo project teams corresponding to
>>> willing Gentoo teams,
>>> 
>>> 2. preparing lists of GitHub usernames on project wiki pages.
>>> 
>>> Solution 1. is cleaner. In this case, we create GitHub teams
>>> under the Gentoo projects, and add appropriate Gentoo
>>> developers having GitHub accounts to the teams. Then, in PRs we
>>> can just ping the whole team like @Gentoo/Qt or like.
>>> 
>>> Solution 2. avoids adding any GitHub teams. In this case, in
>>> team wiki page we collect team member usernames like "@Pesa, 
>>> @kensington, ..." so we could copy-paste it to pull requests.
>>> We still require extra effort when 'assigning' PRs but at least
>>> I don't have to lookup the same people over and over again.
>>> 
>>> With some Wiki people help, we could even implement updating 
>>> GitHub teams automatically following Wiki member changes.
>>> 
>>> Your thoughts?
>>> 
>> Why not use LDAP?
> 
> Because:
> 
> a) LDAP is PITA,
> 
> b) therefore almost nobody cares to update team listings except
> for occasional updates when they happen to need to change SSH keys
> or something,
> 
> c) team listings in LDAP are cleartext and completely random.
> 
So, to rephrase, you intend to hammer another LDAP shaped peg into a
wiki shaped hole because you can't be bothered to write some simple
wrappers for managing the data in LDAP; though you are perfectly
willing to offload work onto the wiki team to support your idea.

Exactly why should that be considered an acceptable solution?

Re: [gentoo-dev] .gitignore

[Patrick McLean]

On Thu, 13 Aug 2015 07:43:24 -0700
Brian Dolbec  wrote:
> 
> No, there clearly should be some things that are commonly present
> that should never be committed.  Those common things should be in a
> global .gitignore.  I did not read the entire thread(s) but it seemed
> there was more bikeshedding that was necessary.  I had not seen
> mention of an alternate git ignore setting that could be used without
> the need to have a locally modified .gitignore that someone must
> constantly refrain from committing with git constantly reminding them
> it has been modified and lest they be chastised for committing it ;)  
> 

We should have common editor artifacts and backup files in there, I
generally use this in just about every repository I touch:

*~
.*.sw[po]
.*.un~
*#
.#*

This should cover vim and emacs, if there other editors that like to
drop files around, we should consider adding those as well.0

Re: [gentoo-dev] rsync->git mirror discontinued, repo mirror & CI updates

[Michał Górny]

Dnia 2015-08-13, o godz. 20:28:11
Joseph Booker  napisał(a):

> On Thu, Aug 13, 2015 at 1:42 PM, Michał Górny  wrote:
> 
> > Please also remember to ping package maintainers. We usually do that
> > through @-highlights in comments. The developers who are direct package
> > maintainers can be referenced directly (@mgorny), while teams and
> > projects can be referenced via GitHub teams (@Gentoo/qt). Sadly, only
> > a handful of the teams is mirrored on GitHub right now and organization
> > admin rights are required to add new teams, so you'd have to ping one
> > of the 'Owners' (usually me) to mirror more as necessary.
> >
> 
> Is there any way to reference a team (or even view a list of them) without
> being a member of the "Gentoo" organization already?

To be honest, I have no clue :). But I guess not.

Sadly, I'm not a GitHub expert and I can't really see anything useful
in the documentation. Teams seem private to its members
and organization admins, and I don't see any option to change that. It
may be simply that some Gentoo developers are ashamed to admit they're
part of Gentoo organization.

I don't know if team highlights work at all if you don't see
the releveant team either. I guess for new we'd have to stay with
developers having to highlight teams for you. Which kinda resembles
what happens on Bugzilla ;).

-- 
Best regards,
Michał Górny



pgpZCvRKKR_AN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Michał Górny]

Dnia 2015-08-14, o godz. 13:55:47
Kent Fredric  napisał(a):

> On 14 August 2015 at 07:59, Rich Freeman  wrote:
> > Will that include any case where the string "$Id$" appears in a patch file?
> 
> 
> Surely that can be avoided by using a git attributes specification
> that only applies to  */*/*.ebuild ?

Don't force the implicit expansion on all developers and users forking
the repo.

-- 
Best regards,
Michał Górny



pgpAspkJeF7g_.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Michał Górny]

Dnia 2015-08-13, o godz. 23:56:23
Dean Stephens  napisał(a):

> On 08/13/15 02:15, Michał Górny wrote:
> > Dnia 2015-08-12, o godz. 22:43:24 Dean Stephens
> >  napisał(a):
> > 
> >> On 08/11/15 10:32, Michał Górny wrote:
> >>> Hello, everyone.
> >>> 
> >>> Now that we're officially on git and can officially use pull 
> >>> requests to provide rapid community interaction, it'd be
> >>> convenient to have a little better framework for pinging
> >>> package maintainers.
> >>> 
> >>> With the unofficial mirror/pull request project, I was either 
> >>> looking for project member GitHub accounts and pinging found 
> >>> project members by name, or talking to them directly on IRC. 
> >>> However, with the growth in number of pull requests this will 
> >>> become more and more inconvenient. Therefore, I think it's time
> >>> to be able to mirror teams willing to work with GitHub
> >>> community there for easier 'pings'.
> >>> 
> >>> I have two ideas right now:
> >>> 
> >>> 1. creating GitHub Gentoo project teams corresponding to
> >>> willing Gentoo teams,
> >>> 
> >>> 2. preparing lists of GitHub usernames on project wiki pages.
> >>> 
> >>> Solution 1. is cleaner. In this case, we create GitHub teams
> >>> under the Gentoo projects, and add appropriate Gentoo
> >>> developers having GitHub accounts to the teams. Then, in PRs we
> >>> can just ping the whole team like @Gentoo/Qt or like.
> >>> 
> >>> Solution 2. avoids adding any GitHub teams. In this case, in
> >>> team wiki page we collect team member usernames like "@Pesa, 
> >>> @kensington, ..." so we could copy-paste it to pull requests.
> >>> We still require extra effort when 'assigning' PRs but at least
> >>> I don't have to lookup the same people over and over again.
> >>> 
> >>> With some Wiki people help, we could even implement updating 
> >>> GitHub teams automatically following Wiki member changes.
> >>> 
> >>> Your thoughts?
> >>> 
> >> Why not use LDAP?
> > 
> > Because:
> > 
> > a) LDAP is PITA,
> > 
> > b) therefore almost nobody cares to update team listings except
> > for occasional updates when they happen to need to change SSH keys
> > or something,
> > 
> > c) team listings in LDAP are cleartext and completely random.
> > 
> So, to rephrase, you intend to hammer another LDAP shaped peg into a
> wiki shaped hole because you can't be bothered to write some simple
> wrappers for managing the data in LDAP; though you are perfectly
> willing to offload work onto the wiki team to support your idea.
> 
> Exactly why should that be considered an acceptable solution?

Don't ask me. I was against keeping the official listings in MediaWiki,
I already complained that we can't list developers who are refusing to
create a Wiki account and that we lack any proper API to access those
listings.

Not to mention the second copy of partial metastructure in herds.xml
which I wanted removed but people liked it very much, thank you.

-- 
Best regards,
Michał Górny



pgpsAAGuAvATL.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] .gitignore

[Michał Górny]

Dnia 2015-08-13, o godz. 21:17:22
Patrick McLean  napisał(a):

> On Thu, 13 Aug 2015 07:43:24 -0700
> Brian Dolbec  wrote:
> > 
> > No, there clearly should be some things that are commonly present
> > that should never be committed.  Those common things should be in a
> > global .gitignore.  I did not read the entire thread(s) but it seemed
> > there was more bikeshedding that was necessary.  I had not seen
> > mention of an alternate git ignore setting that could be used without
> > the need to have a locally modified .gitignore that someone must
> > constantly refrain from committing with git constantly reminding them
> > it has been modified and lest they be chastised for committing it ;)  
> > 
> 
> We should have common editor artifacts and backup files in there, I
> generally use this in just about every repository I touch:
> 
> *~
> .*.sw[po]
> .*.un~
> *#
> .#*
> 
> This should cover vim and emacs, if there other editors that like to
> drop files around, we should consider adding those as well.0

set directory=~/tmp,/var/tmp

It's usually a bad idea to leave temporary files in cwd :P.

-- 
Best regards,
Michał Górny



pgpv6_zcfy7eg.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] .gitignore

[Ben de Groot]

On 14 August 2015 at 14:02, Michał Górny  wrote:
> Dnia 2015-08-13, o godz. 21:17:22
> Patrick McLean  napisał(a):
>> We should have common editor artifacts and backup files in there, I
>> generally use this in just about every repository I touch:
>>
>> *~
>> .*.sw[po]
>> .*.un~
>> *#
>> .#*
>>
>> This should cover vim and emacs, if there other editors that like to
>> drop files around, we should consider adding those as well.0
>
> set directory=~/tmp,/var/tmp
>
> It's usually a bad idea to leave temporary files in cwd :P.

It is. But how many people actually bother to change the defaults?

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Kent Fredric]

On 14 August 2015 at 17:45, Michał Górny  wrote:
> Don't force the implicit expansion on all developers and users forking
> the repo.


You wouldn't, I thought we were talking about $Id$ only being expanded
on the git->rsync transition, and people worrying that $Id$ would be
expanded in patches, where the sensible thing would be to carefully
filter which files $Id$ expansion happens instead of relying on all
files in all folders to not have patterns that just happen to match
$Id(: .*)$


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL