Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-08-13 Thread Tom Wijsman
On Wed, 30 Jul 2014 13:48:37 +0200
Luis Ressel ara...@aixah.de wrote:

 I think I'd rather go with the original workflow. Okay, perhaps
 package.masking - is a bit uncommon and clutters package.mask, but
 it's not all *that* bad and it eases the workflow.

Depends on whose workflow you are referring to; it doesn't affect the
maintainer, but the clutter can be a pain if you attempt to keep the
p.mask size low. Having package.mask as a directory would be a solution
to this; however, there's not much other need for it to be a directory.

-- 
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] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-31 Thread Michael Haubenwallner

Am 2014-07-30 19:33, schrieb Samuli Suominen:
 
 On 30/07/14 20:29, Michael Haubenwallner wrote:
 Am 2014-07-30 14:33, schrieb Samuli Suominen:
 There is no need to package.mask if proper if -logic is used, like, for
 example,

 if [[ ${PV} == * ]]; then
 inherit git-r3
 KEYWORDS=
 else
 KEYWORDS=~amd64 ~arm ~arm64 ~x86
 fi

 Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
 the KEYWORDS
 ready, and 1.2.3 and  ebuilds can be identical
 Which instance of the KEYWORDS line is touched by the ekeyword tool these 
 days?

 To have ekeyword touch the else-part in the release ebuild, what about this:

 if [[ ${PV} == * ]]; then
   inherit vcs...
   :; KEYWORDS=
 else
   KEYWORDS=...
 fi

 /haubi/

 
 You are propably looking for this,
 http://bugs.gentoo.org/show_bug.cgi?id=321475
 

Indeed, thanks!

/haubi/



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-30 Thread Duncan
Denis Dupeyron posted on Tue, 29 Jul 2014 07:58:26 -0600 as excerpted:

 [H]ere is what I was instructed to teach recruits back when I became a
 recruiter in 2006 or 2007, and what competent developers have been doing
 since even before I was a developer:
 
 The package.mask file is only for temporary masking, even if more or
 less long term. Anything that should be permanently masked has no place
 in the tree. Live ebuilds should not be keyworded, reflecting the fact
 that the code they're pulling has not be tested for any architecture due
 to it being live. Moreover, live ebuilds should not be masked as this
 results in unnecessary cruft in the package.mask file.

Thanks.  That makes sense, tho it does conflict with content-touchless 
bumps from the live ebuild.

In the context of that policy and a content-touchless-bump goal, I 
suppose I'd script the bump, pulling keywords from the highest previous 
version, prepending the ~ as necessary and inserting them in the keywords 
line after copying the file from the live-ebuild .  That wouldn't be 
content-touchless, but the touch would be automated so as to avoid 
mistakes and unnecessary work.

-- 
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] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-30 Thread Luis Ressel
On Wed, 30 Jul 2014 09:38:16 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 In the context of that policy and a content-touchless-bump goal, I 
 suppose I'd script the bump, pulling keywords from the highest
 previous version, prepending the ~ as necessary and inserting them in
 the keywords line after copying the file from the live-ebuild .  That
 wouldn't be content-touchless, but the touch would be automated so as
 to avoid mistakes and unnecessary work.

That proposed script reminds me of http://xkcd.com/1319/. ;)

I think I'd rather go with the original workflow. Okay, perhaps
package.masking - is a bit uncommon and clutters package.mask, but
it's not all *that* bad and it eases the workflow.


Regards,
Luis Ressel


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-30 Thread Samuli Suominen

On 30/07/14 14:48, Luis Ressel wrote:
 On Wed, 30 Jul 2014 09:38:16 + (UTC)
 Duncan 1i5t5.dun...@cox.net wrote:

 In the context of that policy and a content-touchless-bump goal, I 
 suppose I'd script the bump, pulling keywords from the highest
 previous version, prepending the ~ as necessary and inserting them in
 the keywords line after copying the file from the live-ebuild .  That
 wouldn't be content-touchless, but the touch would be automated so as
 to avoid mistakes and unnecessary work.
 That proposed script reminds me of http://xkcd.com/1319/. ;)

 I think I'd rather go with the original workflow. Okay, perhaps
 package.masking - is a bit uncommon and clutters package.mask, but
 it's not all *that* bad and it eases the workflow.


 Regards,
 Luis Ressel

There is no need to package.mask if proper if -logic is used, like, for
example,

if [[ ${PV} == * ]]; then
inherit git-r3
KEYWORDS=
else
KEYWORDS=~amd64 ~arm ~arm64 ~x86
fi

Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
the KEYWORDS
ready, and 1.2.3 and  ebuilds can be identical

That's what this thread was originally about... That's how x265's ebuild
work, just like eg.
media-libs/xine-lib or sys-fs/udev ebuilds does

(It just seemed this was unclear to some replying in this thread.)

- Samuli



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-30 Thread Luis Ressel
On Wed, 30 Jul 2014 15:33:19 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:

 There is no need to package.mask if proper if -logic is used, like,
 for example,
 
 if [[ ${PV} == * ]]; then
 inherit git-r3
 KEYWORDS=
 else
 KEYWORDS=~amd64 ~arm ~arm64 ~x86
 fi
 
 Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
 the KEYWORDS
 ready, and 1.2.3 and  ebuilds can be identical
 
 That's what this thread was originally about... That's how x265's
 ebuild work, just like eg.
 media-libs/xine-lib or sys-fs/udev ebuilds does
 
 (It just seemed this was unclear to some replying in this thread.)
 
 - Samuli
 
 

Thanks for the clarification. This approach seems to be the optimum.


Regards,
Luis Ressel


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-30 Thread Michael Haubenwallner

Am 2014-07-30 14:33, schrieb Samuli Suominen:
 
 There is no need to package.mask if proper if -logic is used, like, for
 example,
 
 if [[ ${PV} == * ]]; then
 inherit git-r3
 KEYWORDS=
 else
 KEYWORDS=~amd64 ~arm ~arm64 ~x86
 fi
 
 Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
 the KEYWORDS
 ready, and 1.2.3 and  ebuilds can be identical

Which instance of the KEYWORDS line is touched by the ekeyword tool these days?

To have ekeyword touch the else-part in the release ebuild, what about this:

if [[ ${PV} == * ]]; then
  inherit vcs...
  :; KEYWORDS=
else
  KEYWORDS=...
fi

/haubi/



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-30 Thread Samuli Suominen

On 30/07/14 20:29, Michael Haubenwallner wrote:
 Am 2014-07-30 14:33, schrieb Samuli Suominen:
 There is no need to package.mask if proper if -logic is used, like, for
 example,

 if [[ ${PV} == * ]]; then
 inherit git-r3
 KEYWORDS=
 else
 KEYWORDS=~amd64 ~arm ~arm64 ~x86
 fi

 Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
 the KEYWORDS
 ready, and 1.2.3 and  ebuilds can be identical
 Which instance of the KEYWORDS line is touched by the ekeyword tool these 
 days?

 To have ekeyword touch the else-part in the release ebuild, what about this:

 if [[ ${PV} == * ]]; then
   inherit vcs...
   :; KEYWORDS=
 else
   KEYWORDS=...
 fi

 /haubi/


You are propably looking for this,
http://bugs.gentoo.org/show_bug.cgi?id=321475



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-30 Thread William Hubbs
On Wed, Jul 30, 2014 at 07:29:22PM +0200, Michael Haubenwallner wrote:
 
 Am 2014-07-30 14:33, schrieb Samuli Suominen:
  
  There is no need to package.mask if proper if -logic is used, like, for
  example,
  
  if [[ ${PV} == * ]]; then
  inherit git-r3
  KEYWORDS=
  else
  KEYWORDS=~amd64 ~arm ~arm64 ~x86
  fi
  
  Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
  the KEYWORDS
  ready, and 1.2.3 and  ebuilds can be identical
 
 Which instance of the KEYWORDS line is touched by the ekeyword tool these 
 days?
 
 To have ekeyword touch the else-part in the release ebuild, what about this:
 
 if [[ ${PV} == * ]]; then
   inherit vcs...
   :; KEYWORDS=
 else
   KEYWORDS=...
 fi

Actually you can even go further since KEYWORDS is an optional variable:

if [[ ${PV} == * ]]; then
  inherit vcs...
else
  KEYWORDS=...
fi

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-29 Thread Denis Dupeyron
On Mon, Jul 28, 2014 at 6:49 PM, Alex Xu alex_y...@yahoo.ca wrote:
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9view=markup#l9

Thanks, Alex. This makes more sense now.

Denis.



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-29 Thread Denis Dupeyron
On Mon, Jul 28, 2014 at 8:41 PM, Duncan 1i5t5.dun...@cox.net wrote:
 AFAIK, gentoo policy is that live ebuilds should always be masked so as
 never to be automatically pulled in without a deliberate unmasking of the
 live ebuild, but whether that's masked due to lack of keywords (ebuild),
 or due to hard-mask (package.mask) is I believe up to the maintainer.

The policy apparently disappeared in the shuffling of documentation
which occurred over the years. But here is what I was instructed to
teach recruits back when I became a recruiter in 2006 or 2007, and
what competent developers have been doing since even before I was a
developer:

The package.mask file is only for temporary masking, even if more or
less long term. Anything that should be permanently masked has no
place in the tree. Live ebuilds should not be keyworded, reflecting
the fact that the code they're pulling has not be tested for any
architecture due to it being live. Moreover, live ebuilds should not
be masked as this results in unnecessary cruft in the package.mask
file.

Denis.



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-29 Thread Samuli Suominen

On 29/07/14 03:15, Denis Dupeyron wrote:
 On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org 
 wrote:
 x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
 x265-.ebuild:KEYWORDS=~amd64 ~x86

 As in... You forgot to add ~arm to -.ebuild
 Wait, what? Live ebuilds are keyworded now?

 Denis.


I should have propably only mailed this to maekke, but CC'd the mailing
list because this
has been a trend lately, people outright ignore * ebuilds and the
preparations
done there for the upcoming releases when they commit non-maintainer
bumps like,
well, I don't want to give examples as that'd be pointing fingers
Just that some people think it's better to have poorly done version bump
to get latest,
than live with *correct* older version, and thiskind of thinking really
needs to die...
There is nothing wrong with old, long as it works

- Samuli



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-28 Thread Samuli Suominen

On 27/07/14 22:01, Markus Meier (maekke) wrote:
 maekke  14/07/27 19:01:15

   Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild
 x265-0.8.ebuild
   Log:
   add ~arm, bug #510340

Package bumping is done by, eg.:

# cp x265-.ebuild x265-1.3.ebuild

And then,

# grep *.ebuild

x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
x265-.ebuild:KEYWORDS=~amd64 ~x86

As in... You forgot to add ~arm to -.ebuild



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-28 Thread Samuli Suominen

On 28/07/14 09:41, Samuli Suominen wrote:
 On 27/07/14 22:01, Markus Meier (maekke) wrote:
 maekke  14/07/27 19:01:15

   Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild
 x265-0.8.ebuild
   Log:
   add ~arm, bug #510340
 Package bumping is done by, eg.:

 # cp x265-.ebuild x265-1.3.ebuild

 And then,

 # grep *.ebuild

 x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
 x265-.ebuild:KEYWORDS=~amd64 ~x86

 As in... You forgot to add ~arm to -.ebuild


Fixed that for you.



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-28 Thread Markus Meier
On Mon, 28 Jul 2014 11:02:58 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:

 
 On 28/07/14 09:41, Samuli Suominen wrote:
  On 27/07/14 22:01, Markus Meier (maekke) wrote:
  maekke  14/07/27 19:01:15
 
Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild
  x265-0.8.ebuild
Log:
add ~arm, bug #510340
  Package bumping is done by, eg.:
 
  # cp x265-.ebuild x265-1.3.ebuild
 
  And then,
 
  # grep *.ebuild
 
  x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
  x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
  x265-.ebuild:KEYWORDS=~amd64 ~x86
 
  As in... You forgot to add ~arm to -.ebuild
 
 
 Fixed that for you.
 

Thanks.


Regards,
Markus


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-28 Thread Denis Dupeyron
On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
 x265-.ebuild:KEYWORDS=~amd64 ~x86

 As in... You forgot to add ~arm to -.ebuild

Wait, what? Live ebuilds are keyworded now?

Denis.



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-28 Thread Alex Xu
On 28/07/14 08:15 PM, Denis Dupeyron wrote:
 On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org 
 wrote:
 x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
 x265-.ebuild:KEYWORDS=~amd64 ~x86

 As in... You forgot to add ~arm to -.ebuild
 
 Wait, what? Live ebuilds are keyworded now?
 
 Denis.
 

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9view=markup#l9



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-28 Thread Duncan
Denis Dupeyron posted on Mon, 28 Jul 2014 18:15:20 -0600 as excerpted:

 On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org
 wrote:
 x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86
 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86
 x265-.ebuild:   KEYWORDS=~amd64 ~x86

 As in... You forgot to add ~arm to -.ebuild
 
 Wait, what? Live ebuilds are keyworded now?

AFAIK, gentoo policy is that live ebuilds should always be masked so as 
never to be automatically pulled in without a deliberate unmasking of the 
live ebuild, but whether that's masked due to lack of keywords (ebuild), 
or due to hard-mask (package.mask) is I believe up to the maintainer.

For packages like this one where normal version-bumps start with the live 
ebuild (which after all should have been updated as development 
proceeded, upstream), simply copying it to the appropriate version-number 
ebuild, keeping it ~arch-keyworded on all archs where the non-live 
version is at least ~arch-keyworded, and using package.mask to force the 
masking, makes the most sense since then a version bump can literally 
amount to no more than an ebuild copy and manifest (tho obviously the 
maintainer will test it too, but ideally won't have to actually touch the 
content of the file).

-- 
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