[gentoo-dev] [PATCH v1 3/4] metadata.dtd: update the restrict attribute explanation per GLEP 68

[Göktürk Yüksek]

Signed-off-by: Göktürk Yüksek 
---
 metadata.dtd | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/metadata.dtd b/metadata.dtd
index a3c06ff..8ef1396 100644
--- a/metadata.dtd
+++ b/metadata.dtd
@@ -68,9 +68,10 @@
 
 
-- 
2.7.3

[gentoo-dev] [PATCH v1 4/4] metadata: update the slot element name attribute explanation per GLEP 68

[Göktürk Yüksek]

Signed-off-by: Göktürk Yüksek 
---
 metadata.dtd | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/metadata.dtd b/metadata.dtd
index 8ef1396..6d38729 100644
--- a/metadata.dtd
+++ b/metadata.dtd
@@ -20,7 +20,10 @@
   
 
 
-  
+  
   
 
 
-- 
2.7.3

[gentoo-dev] [PATCH v1 2/4] metadata.dtd: set the lang attribute default value to "en" per GLEP 68

[Göktürk Yüksek]

Also mention that the attribute value must be a valid ISO 639-1
language code.

Signed-off-by: Göktürk Yüksek 
---
 metadata.dtd | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/metadata.dtd b/metadata.dtd
index b608852..a3c06ff 100644
--- a/metadata.dtd
+++ b/metadata.dtd
@@ -42,7 +42,7 @@
 
 
 
-  
+  
 
 
@@ -57,14 +57,14 @@
   
 
 
-
-  
-  
-  
-  
+
+  
+  
+  
+  
 
 

[gentoo-dev] [PATCH v1 1/4] metadata.dtd: Remove obsolete element per GLEP 68

[Göktürk Yüksek]

Signed-off-by: Göktürk Yüksek 
---
 metadata.dtd | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/metadata.dtd b/metadata.dtd
index 7626a57..b608852 100644
--- a/metadata.dtd
+++ b/metadata.dtd
@@ -3,7 +3,7 @@
 
 
 
-
+
 
 
   
@@ -13,9 +13,6 @@
 explicit type) for Gentoo maintainers is prohibited. -->
   
 
-  
-  
-
   
   
 
-- 
2.7.3

Re: [gentoo-dev] Reminder: ALLARCHES

[Rich Freeman]

On Sat, Apr 30, 2016 at 8:53 PM, Daniel Campbell  wrote:
>
> As you said, however, it's a choice of the maintainer. Things like Perl
> and Python may be less prone to this issue since they're meant to be
> portable.
>

The concept is that the maintainer will only use this when this is the
case.  The goal is to cut down on stabilization burden esp for minor
arches on stuff that should be arch independent.  I don't think we
formalized a ton of rules - maintainers should know when it is safe to
use.

-- 
Rich

[gentoo-dev] Gentoo's gitolite hooks: increasing security & increased functionality awareness

[Robin H. Johnson]

Hi all,

The gitolite hooks for GPG-signed pushes have been very successful since
we launched them with the Gentoo repo, so I'd like to roll them out to
more repos.

Additionally, in an effort to simplify configuration, we're going to
default to a number of hooks being enabled (but they will do nothing
without a little bit of extra config), and some of these may be useful
to developers, so I'm making them more widely known.

Initial repos & repo namespaces for improved security:
--
data/* (all public, includes GLSA & news repos)
foundation/* (all private)
infra/* (mostly private)
pr-private

Default hooks:
--
require-signed-push: required all Git pushes to be GPG-signed. Will be
incrementally enabled on repos where all committers are Gentoo
developers.

save-push-signatures: record Git signed pushes in the repository
(downloaded automatically if you add 'fetch =
+refs/push-certs:refs/push-certs/origin' to your gitconfig remote for
repo/gentoo).

gentoo-commits: Send email to the gentoo-commits mailing list; Enabled
for public repos only (can also email other destinations).

Default hooks w/ config required:
-
gentoo-mirror - mirrors a repo to Github or any other external location.

notify-webhook - Sends Github-style PushEvent [1] Webhook messages.
Source available at [2]. Please file a bug if you want a Webhook URL
added to a repo that you own.

Further proposed hooks:
---
I'd like to consider enabling require-signed-commit on all of the same
repos where require-signed-push is used, in the same vein that GitHub
added support for a 'Verified' flag on commits. This hook so far has
only ever been enabled on repo/gentoo, and only verifies standalone
commits & the left-hand side of merges (eg the one onto master). Further
improvements first might include optionally requiring ALL commits to be
signed (not for use on repo/gentoo, but valuable for other repos).

[1] https://developer.github.com/v3/activity/events/types/#pushevent
[2] Upstream code https://github.com/metajack/notify-webhook
[3] https://github.com/blog/2144-gpg-signature-verification

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


signature.asc
Description: Digital signature

Re: [gentoo-dev] Reminder: ALLARCHES

[Matthew Thode]

On 04/30/2016 07:53 PM, Daniel Campbell wrote:
> On 04/30/2016 02:16 PM, Andreas K. Huettel wrote:
>>
>> Hi all,
>>
>> just as a small reminder, to ease the load on all arch teams:
>>
>> If a stablerequest has the keyword ALLARCHES set, then
>> * the first arch that tests successfully and stabilizes
>> * can and *should* immediately stabilize for all requested arches!
>>
>> Whether this keyword is set on a bug is decision of the package maintainer.
>>
>> For example, Perl team sets ALLARCHES normall for all pure-perl packages
>> (i.e., no compilation / gcc involved).
>>
>> Here's an example how this was used:
>> https://bugs.gentoo.org/show_bug.cgi?id=578408
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3709cb5a784b213511fa
>>
>> Cheers, Andreas
>>
>>
> 
> A package working on one arch won't necessarily guarantee that it works
> correctly on all other arches. Shouldn't we at least make sure we're
> testing on the relevant arch? For example, I don't have any hppa
> hardware. If I stabilized for amd64, why should I stabilize for hppa? I
> can't in good faith claim that it'll work fine for hppa because I've not
> tested it.
> 
> As you said, however, it's a choice of the maintainer. Things like Perl
> and Python may be less prone to this issue since they're meant to be
> portable.
> 
> My apologies if my concern is misplaced.
> 
> ~zlg
> 
Yes, this is mainly for interpreted languages (python/perl/ruby/etc)

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Reminder: ALLARCHES

[Daniel Campbell]

On 04/30/2016 02:16 PM, Andreas K. Huettel wrote:
> 
> Hi all,
> 
> just as a small reminder, to ease the load on all arch teams:
> 
> If a stablerequest has the keyword ALLARCHES set, then
> * the first arch that tests successfully and stabilizes
> * can and *should* immediately stabilize for all requested arches!
> 
> Whether this keyword is set on a bug is decision of the package maintainer.
> 
> For example, Perl team sets ALLARCHES normall for all pure-perl packages
> (i.e., no compilation / gcc involved).
> 
> Here's an example how this was used:
> https://bugs.gentoo.org/show_bug.cgi?id=578408
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3709cb5a784b213511fa
> 
> Cheers, Andreas
> 
>

A package working on one arch won't necessarily guarantee that it works
correctly on all other arches. Shouldn't we at least make sure we're
testing on the relevant arch? For example, I don't have any hppa
hardware. If I stabilized for amd64, why should I stabilize for hppa? I
can't in good faith claim that it'll work fine for hppa because I've not
tested it.

As you said, however, it's a choice of the maintainer. Things like Perl
and Python may be less prone to this issue since they're meant to be
portable.

My apologies if my concern is misplaced.

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



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Reminder: ALLARCHES

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hi all, 

just as a small reminder, to ease the load on all arch teams:

If a stablerequest has the keyword ALLARCHES set, then 
* the first arch that tests successfully and stabilizes 
* can and *should* immediately stabilize for all requested arches!

Whether this keyword is set on a bug is decision of the package maintainer. 

For example, Perl team sets ALLARCHES normall for all pure-perl packages 
(i.e., no compilation / gcc involved).

Here's an example how this was used:
https://bugs.gentoo.org/show_bug.cgi?id=578408
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3709cb5a784b213511fa

Cheers, Andreas

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXJSC6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkdcQP/1FnN5/j7c53rrHMvRRKBApm
5N0MQKz6d5HPeid27XcsUq65vfvDaCRJrlbD03jsirtMdYtkaMfA2WNTO90n8BoD
1m3T+rf28s8yPmRby+EO7xLogAdyfT3XAiKc3y1sCbF2yPgfYJsU9A3X3N+GO1Vq
QvhTWYiTMVKKdMcQxWvislYRMjuuFSHFW3IjLKepHmfJMrBiSgWx7c/JXL1/BpRt
de5CtpTwcPTL8hMM38TvFH8KTtXdpVklDiaSM5++GJhaZD04kCjj07ln1bO16CIK
vgUvc6VGxncEQpL3pTAPN00o4W70u78RRQEsP2i3ro8DHnQOOAmrDliIGUYb6XI0
1tl6l68QJN/oTJDTvvSWBSRTy1lBTm7T4HqX7Y0ikiN3o/Ygx9uvbJP8ZPGm9I7a
alIFFfgqz1LylRiH06TeplsZESv0cONWbvLs8o/kzQiIhzu/mrRzEl+DZKsudZA7
YKOkaVJlHOSrEvLM+7hY8mKa5BD1p4b7X+4yd9o+bXSXIyTw3dP1kdAHta9+x6ew
iYKA25rsFVSaiA3VOOtOlz046TZVzI64RZCQHIA4YaisIksJ1Gu86Y7yPRtimN0v
f+CdRb4zo26dJCWb1H/wosdXDka2YO3iBlfdVEACZCLQh9YjLk1oy5OowMf12LPI
lurmnVDeK9XHLgH8E4Xr
=VoVS
-END PGP SIGNATURE-

[gentoo-dev] Re : Cannot see my eclass modifications

[Farid BENAMROUCHE]

Hi all,
 
 I'm currently developping a patch for user.eclass, but I'm
 banging my head against a wall...
 
 So for testing first, I've setup an overlay, and I now that
 it is taken in account by portage (If I rename portage's
 user.eclass, emerge is still working. If I remove my
 overlay, emerge complains about missing user eclass. So my
 overlay is actually working)
 I've modified enewgroup and egetent for example and put some
 einfo and also modified some other stuffs to be sure that
 I'm entering the function
 
 Then emerge sys-power/nut, I can see the pkg-setup traces,
 just after the call to enewgroup... but still cannot see my
 eclass modifications!
 I tried to modify directly the
 /usr/portage/eclass/user.eclass file, but still the same
 issue...
 I'm totally puzzled about this point! I'm most likely
 missing a stupid point somewhere...
 
 Anyone knows what could be the problem? Please let me know
 what traces/info you need and I will post them.
 
 Thank you!
 

Re: [gentoo-dev][PATCH] dev-lang/go-1.6.2: enable go-bootstrap tarball for ppc64le #581278

[Mike Frysinger]

On 28 Apr 2016 13:28, Leno Hou wrote:
> --- a/dev-lang/go/go-1.6.2.ebuild
> +++ b/dev-lang/go/go-1.6.2.ebuild
> @@ -88,6 +88,16 @@ go_arch()
>   case "${portage_arch}" in
>   x86)echo 386;;
>   x64-*)  echo amd64;;
> + ppc64)
> + case "$(tc-endian $@)" in

the quote nesting is incorrect.  you want:
case $(tc-endian "$@") in

> + little)
> + echo ppc64le
> + ;;
> + big)
> + echo ppc64
> + ;;
> + esac
> + ;;

up to William, but seems like a one liner would be fine:
[[ $(tc-endian "$@") == "big" ]] && echo ppc64 || echo ppc64le
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68

[Michał Górny]

On Sat, 30 Apr 2016 02:36:18 -0400
Göktürk Yüksek  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Michał Górny:
> > On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek
> >  wrote:
> >   
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
> >> 
> >> Brian Dolbec:  
> >>> On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek 
> >>>  wrote:
> >>>   
>  --- metadata.dtd | 5 + 1 file changed, 1 insertion(+), 4 
>  deletions(-)
>  
>  diff --git a/metadata.dtd b/metadata.dtd index
>  7626a57..b608852 100644 --- a/metadata.dtd +++ b/metadata.dtd
>  @@ -3,7 +3,7 @@ 
>  
>   -  (maintainer|natural-name|longdescription|slots|use|upstream)*  
>  )> +  (maintainer|longdescription|slots|use|upstream)* )>    pkgmetadata pkgname CDATA "">  @@ -13,9 +13,6
>  @@ explicit type) for Gentoo maintainers is prohibited. -->
>    "unknown">  
>  
>  -   -    (#PCDATA)  
> > -   
>    
> >>> 
> >>> Isn't this almost obsolete?  it's now xmlschema...  And I hope
> >>> to have the new repoman with it out this weekend :)  
> >> 
> >> Does GLEP 68 explicitly declare metadata.dtd obsolete? I see that
> >> the example metadata.xml on the GLEP is missing DOCTYPE, are we
> >> getting rid of those too?  
> > 
> > No, and I don't know.
> > 
> > metadata.dtd is still required by many tools, and as such it makes 
> > sense to keep it. However, we may want to put some warning that
> > it's not very strict, and allows major structural violations due
> > to technical limitations.
> >   
> After a discussion with ulm on IRC, we agreed that the following makes
> sense: "the format of the metadata is defined in GLEP 68. the syntax
> is defined in metadata.dtd. The xml-schema can be used for stricter
> validation checks." If you have no objections, I will update devmanual
> based on this description.

What is the precise difference between 'format' and 'syntax' here? I'm
no native English speaker, and I don't see any obvious split of
responsibility between the two here, and I'm pretty sure this will be
quite confusing for other people as well.

-- 
Best regards,
Michał Górny



pgpzbUrr_wgtw.pgp
Description: OpenPGP digital signature