Re: [gentoo-dev] ARM64 stable keyword

2014-04-23 Thread William Hubbs
On Tue, Apr 22, 2014 at 09:43:24PM +0200, Tom Wijsman wrote:
 On Tue, 22 Apr 2014 22:13:16 +0400
 Mikle Kolyada zlog...@gentoo.org wrote:
  
  22.04.2014 21:59, Mike Gilbert пишет:
 
   Ok, then the stable keyword is going to get lost when I drop old
   versions.
 
  Vapier can  restore stable keywords for newest version if needed, i
  think
 
 Repeating that is a flashing experience for the minor arches users.

How so?

The arm64 profiles are marked exp in profiles.desc, so we don't have to
care about the keyword status.

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] ARM64 stable keyword

2014-04-23 Thread Tom Wijsman
On Wed, 23 Apr 2014 15:50:03 -0500
William Hubbs willi...@gentoo.org wrote:

 The arm64 profiles are marked exp in profiles.desc, so we don't have
 to care about the keyword status.

Ah okay; nevermind then, my concern didn't take that into account.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] ARM64 stable keyword

2014-04-23 Thread Anthony G. Basile

On 04/23/2014 05:04 PM, Tom Wijsman wrote:

On Wed, 23 Apr 2014 15:50:03 -0500
William Hubbs willi...@gentoo.org wrote:


The arm64 profiles are marked exp in profiles.desc, so we don't have
to care about the keyword status.

Ah okay; nevermind then, my concern didn't take that into account.

I like this technique because it allows us to build catalyst stages 
based on stable packages while keeping the entire arch exp.  Eg. with 
mips, I have to build catalyst stages with KEYWORDS=mips ~mips.  I'm 
always on the bleeding edge of the latest packages committed to the 
tree.  Sometimes these builds fail because the ~arch edge is not well 
tested for consistency and I have to resort to masking.  It nicer to 
just build on KEYWORDS=mips and then just stabilize the versions that 
are known to work.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




[gentoo-dev] ARM64 stable keyword

2014-04-22 Thread Mike Gilbert
I see that vapier has been adding arm64 as a stable keyword to lots of packages.

When I am requesting stabilization for newer versions these packages,
is there an arm64 arch team I should copy? If not, these stable
keywords are just going to get lost as old ebuilds get dropped.

For an example, see my last commit to dev-util/scons. I moved the
stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I
am not sure if this was the right thing to do.



Re: [gentoo-dev] ARM64 stable keyword

2014-04-22 Thread Mikle Kolyada

22.04.2014 21:40, Mike Gilbert пишет:
 I see that vapier has been adding arm64 as a stable keyword to lots of 
 packages.

 When I am requesting stabilization for newer versions these packages,
 is there an arm64 arch team I should copy? If not, these stable
 keywords are just going to get lost as old ebuilds get dropped.

 For an example, see my last commit to dev-util/scons. I moved the
 stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I
 am not sure if this was the right thing to do.

   
You should not add this, only vapier and probably armin76 have arm64
hardware (hardware?).  Mike stabilize for minor arches  if needed. (like
sh/s390/m68k).



Re: [gentoo-dev] ARM64 stable keyword

2014-04-22 Thread Mike Gilbert
On Tue, Apr 22, 2014 at 2:01 PM, Mikle Kolyada zlog...@gentoo.org wrote:

 22.04.2014 21:40, Mike Gilbert пишет:
 I see that vapier has been adding arm64 as a stable keyword to lots of 
 packages.

 When I am requesting stabilization for newer versions these packages,
 is there an arm64 arch team I should copy? If not, these stable
 keywords are just going to get lost as old ebuilds get dropped.

 For an example, see my last commit to dev-util/scons. I moved the
 stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I
 am not sure if this was the right thing to do.


 You should not add this, only vapier and probably armin76 have arm64
 hardware (hardware?).  Mike stabilize for minor arches  if needed. (like
 sh/s390/m68k).


Ok, then the stable keyword is going to get lost when I drop old versions.



Re: [gentoo-dev] ARM64 stable keyword

2014-04-22 Thread Mikle Kolyada

22.04.2014 21:59, Mike Gilbert пишет:
 On Tue, Apr 22, 2014 at 2:01 PM, Mikle Kolyada zlog...@gentoo.org wrote:
 22.04.2014 21:40, Mike Gilbert пишет:
 I see that vapier has been adding arm64 as a stable keyword to lots of 
 packages.

 When I am requesting stabilization for newer versions these packages,
 is there an arm64 arch team I should copy? If not, these stable
 keywords are just going to get lost as old ebuilds get dropped.

 For an example, see my last commit to dev-util/scons. I moved the
 stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I
 am not sure if this was the right thing to do.


 You should not add this, only vapier and probably armin76 have arm64
 hardware (hardware?).  Mike stabilize for minor arches  if needed. (like
 sh/s390/m68k).

 Ok, then the stable keyword is going to get lost when I drop old versions.

Vapier can  restore stable keywords for newest version if needed, i think



Re: [gentoo-dev] ARM64 stable keyword

2014-04-22 Thread Tom Wijsman
On Tue, 22 Apr 2014 22:13:16 +0400
Mikle Kolyada zlog...@gentoo.org wrote:
 
 22.04.2014 21:59, Mike Gilbert пишет:

  Ok, then the stable keyword is going to get lost when I drop old
  versions.

 Vapier can  restore stable keywords for newest version if needed, i
 think

Repeating that is a flashing experience for the minor arches users.

Stabilizing on minor arches this way feels more like a regression, than
that it is an improvement; the promise for a stable experience can't be
fulfilled like that. Searching for broken packages and/or versions and
masking them on the architecture in question could work out better; you
spare out time because you only monitor new versions in general, as
well as attempt to discover breakage instead of discovering stability.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D