[gentoo-dev] Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Michał Górny posted on Mon, 02 Feb 2015 15:06:40 +0100 as excerpted: > FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg > tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will > exactly get used. Much less confusion. +1 > Thirdly, this opens space for having more than two different > implementations in the future without having to reset the system. +100 =:^) Having to go thru this yet /again/ doesn't sound like fun! > As for the downsides: > > 1. there is a number of non-meaningful flag combinations. > FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be blocked > via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. > > 2. There is some more work to get ebuilds correct (REQUIRED_USE). > However, this is a minor issue compared to the potential mistakes in > interpretation of USE='ffmpeg' and USE='libav'. ffmpeg-chooser.eclass ?? Seriously, this sounds like a lot of boilerplate that's ultimately headed for a lot of ebuilds. Implement it ONCE in an eclass and have a simple inherit that's easy to do and standardizes all the messages, required_use conditions, etc. Special-cases such as breaks-with-one-of-them could then be per-ebuild handled with a simple declarative syntax. Set ffchooser_broken_impl=X before the inheritance and let the eclass handle it. Alternatively, keep the eclass simple for the handles-both case and let people special-case-code the one-broken case. What's nice about the eclass idea is that implemented correctly it's forward compatible with the additional implementations possibility as well. Just add the Nth implementation once, to the eclass, and all the ebuilds automatically support it. And if a few break, a quick ffchooser_broken_impl=Z before the inherit gets them working again, complete with standardized error messages, etc. =:^) -- 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] Portage news announcement review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 02 Feb 2015 23:21:53 +0100 Manuel Rüger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 02.02.2015 22:58, Brian Dolbec wrote: > > > > sys-apps/portage-2.2.16 is ready for release and is just waiting > > for the news announcement about the new plug-in sync system being > > used and the changes in it's operation. > > > > Attached is the news announcement for review. > > > > > Please replace "3rd party" with "third party" to increase readability. > > Cheers, > > Manuel Done. Attached is an updated news item. changes: - replaced 3rd party with third party - re-wrapped text at 72 columns (was at 80) (ulm on irc) - Added missed info for native postsync.d and repo.postsync.d hooks - Minor editing to improve clarity, reduce length - Added Migration section. (rich0) - -- Brian Dolbec -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJU0BxNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7Y8gkQALMyQsUOwAb+PFB7pMybYH3N mpPd/yvqr8kHhWDGv+3+M8dvFfYfmct7VZbYacsCy9NNqvzAmWLopUg0UVuLP3Mc Y8HqpQ23fyIkzCNdpCWK9oOgE+PGb01IwhvRS+SA9tBrSxx/N5Z7ogFyfMbbtClQ tVdDRw+v3UsRAsRJQp2OOu4vK+qPeMahoZQToAe21XXlziX6D7SvvkwjNeP9IDBB j5DHOFI3QvnKZSc6x7EygXW6zp8/C9DvT8eml4FmUUL6foMC1FFkW+n4OzrFRnqr 67tqwjSr9mEI02MmEAjqsFBnsd5H0RyXQvLlvzV7zNFW3w6+vRBHBRKhaIDSMJDn IlZS+qeq5nI4V+eyG2tRVnHKdBuvenS3Z98GUJA3N7/hXfzII4K2jqCJghZHQnrK QIj5PF0n62DDMQ1zZbVJi9a+ILuMy/KVCXNoi8V/Tvk9j76v8vskscWYmNMtNU+W +83iTmRzSxJrEwKl4sHhOVK6GSaJIoTrAt80eJeo7M1ZsnR+82j8GUzpZdSoH8rL 2crw83Mzj5+XvVARzDUth9Td8hbSNqZBqB/Ge+6RUDdN/rHkFMPHAloZ9lDkFBi0 9NptBAIwLL4GxwgxCMazJWaYPdenO1pVmpAdoJXKaYOlF+ZBB0GxPn+XftQqZcMZ L3K03pWGVDh9tcufcqfj =R6VU -END PGP SIGNATURE- sync.news Description: Binary data
Re: [gentoo-dev] Portage news announcement review
Note: not a Gentoo dev, just a confused user On Mon, Feb 2, 2015 at 7:44 PM, Brian Dolbec wrote: > Note: >If you have default portage settings for location, sync-type then >it should use the backup defaults and sync the gentoo repo still. > What are the 'backup defaults'? Are you using 'for location, sync-type' as a shorthand for 'for location and sync-type'? I'm confused if 'and sync the gentoo repo still' is a mistake or if you mean 'and still sync the gentoo repo' (I think dropping the 'still' completely is more clear)
Re: [gentoo-dev] Portage news announcement review
On Mon, 2 Feb 2015 19:24:38 -0500 Rich Freeman wrote: > On Mon, Feb 2, 2015 at 4:58 PM, Brian Dolbec > wrote: > > > > sys-apps/portage-2.2.16 is ready for release and is just waiting > > for the news announcement about the new plug-in sync system being > > used and the changes in it's operation. > > > > Attached is the news announcement for review. > > You might want to give specific instructions on how to migrate. If > somebody just uses /usr/portage without anything fancy, do they have > to do anything? How about if they have 15 layman repos installed > using layman -a? What if they have a local overlay? > > If the answer is that everything that used to work still works, it > might not hurt to just say that. > > -- > Rich > I can and partially did already. quote: Operation: Primary control of all sync operations has been moved from emerge to emaint. "emerge --sync" now just calls the emaint sync module with the --auto option. This --auto option performs a sync on only those repositories with the auto-sync setting set to 'yes' or 'true'. If it is absent, then emerge --sync may not sync anything. Note: If you have default portage settings for location, sync-type then it should use the backup defaults and sync the gentoo repo still. I'll add the bit for layman overlays, but with the changes suggested here and irc it is at 100 lines now. I'll keep it short. P.S. caught me just in time, I was about to send the updated version. -- Brian Dolbec
Re: [gentoo-dev] Portage news announcement review
On Mon, Feb 2, 2015 at 4:58 PM, Brian Dolbec wrote: > > sys-apps/portage-2.2.16 is ready for release and is just waiting for the > news announcement about the new plug-in sync system being used and the > changes in it's operation. > > Attached is the news announcement for review. You might want to give specific instructions on how to migrate. If somebody just uses /usr/portage without anything fancy, do they have to do anything? How about if they have 15 layman repos installed using layman -a? What if they have a local overlay? If the answer is that everything that used to work still works, it might not hurt to just say that. -- Rich
Re: [gentoo-dev] toolchain.eclass: need to revert fixincludes commit
Il 02/02/2015 23:30, Pacho Ramos ha scritto: > El sáb, 31-01-2015 a las 16:48 -0500, Anthony G. Basile escribió: >> Hi everyone, >> >> We need to revert the following change to toolchain.eclass: >> >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.647&r2=1.648 >> >> It turns out that bsd and prefix need fixincludes while building gcc >> itself, so disabling their build will make gcc unbuildable on those >> systems. Only after gcc is built can you dump them. I did test on many >> exotic systems, but did not look at gentoo/fbsd. >> >> See bug #536878. Thanks Ryan and Fabian. >> >> I'll revert after feedback. >> > Please remember to add a comment to the eclass with the reference to not > forget in the future why fixincludes stuff is needed ;) > > fixincludes only on prefix and bsd is doable/acceptable?
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 05:47 PM, Michał Górny wrote: > > For feature flag, name is the only issue. Currently USE=ffmpeg serves > that purpose and I think changing that would have a very high cost > (and cause a lot of bikeshed), esp. if we would end up reusing the flag > for another purpose. So most likely leave it as-is. Agreed. > For implementation flags, we have three options: > > a. one binary 'libav' flag that switches between the two > implementations, > This is what I was trying to convey earlier. > > non-meaningful flag combinations: > >USE="-ffmpeg libav" -> doesn't give you libav > > Except I wouldn't name the implementation flag "libav" because that's confusing. Name it ffmpeg-impl-libav or whatever's allowed by the PMS. Then, USE="-ffmpeg ffmpeg-impl-libav" -> doesn't give you libav is not weird.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 15:06:40
Michał Górny napisał(a):
> The idea is that instead of having USE=libav (that's tangential to
> USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking
> either ffmpeg or libav. Now, why...
Ok, since this is going to be a long night, a quick summary of
the alternatives.
First of all, plain USE='ffmpeg libav' where each one signifies one of
the impls. This can't work because we already have packages that depend
on, say, 'app-misc/tracker[ffmpeg]'. If we replaced that with two
optional flags, we'd have to do '|| ( tracker[ffmpeg] tracker[libav]
)'. And || () deps are pretty much fragile, don't support := operator
and cause unpredictable blockers during dependency resolution. So this
can't work.
Secondly, global variables that are not USE flags. They can't work
since the dependencies in ebuilds need to be consistent and can not be
affected by external variables.
Thirdly, || () blocks. I already listed above why they must not be used.
So, after throwing all technically unsound solutions, we are left with
having to have exactly one *feature flag* -- the flag that enables
ffmpeg-or-libav support in the packages that have it optional, and one
or more *implementation flags* that select the implementation when more
than one can be used.
For feature flag, name is the only issue. Currently USE=ffmpeg serves
that purpose and I think changing that would have a very high cost
(and cause a lot of bikeshed), esp. if we would end up reusing the flag
for another purpose. So most likely leave it as-is.
For implementation flags, we have three options:
a. one binary 'libav' flag that switches between the two
implementations,
b. two regular unary flags that select one of the implementations,
c. two USE_EXPAND unary flags that select one of the implementations.
A. binary 'libav' flag (or similar)
default set in profiles:
USE="${USE} libav"
user changes impl to ffmpeg:
USE="-libav"
portage output:
media-video/foo USE="... ffmpeg ... libav ..."
ebuild code:
IUSE="ffmpeg libav"
RDEPEND="
ffmpeg? (
!libav? ( media-video/ffmpeg:0= )
libav? ( media-video/libav:0= )
)"
non-meaningful flag combinations:
USE="-ffmpeg libav" -> doesn't give you libav
B. two regular unary flags (i'm going to use ffmpeg/libav here but
the names would likely have to be different)
default set in profiles:
USE="${USE} libav"
user changes impl to ffmpeg:
USE="-libav ffmpeg"
portage output:
media-video/foo USE="... avcodec ... libav ... -ffmpeg ..."
ebuild code:
IUSE="avcodec ffmpeg libav"
RDEPEND="
avcodec? (
ffmpeg? ( media-video/ffmpeg:0= )
libav? ( media-video/libav:0= )
)"
REQUIRED_USE="avcodec? ( ^^ ( ffmpeg libav ) )"
non-meaningful flag combinations:
USE="-avcodec *" -> doesn't give you libav or ffmpeg
disallowed flag combinations:
USE="avcodec -ffmpeg -libav" -> no implementation selected
USE="avcodec ffmpeg libav" -> multiple implementations selected
C. two USE_EXPAND unary flags
default set in profiles:
FFMPEG_IMPL="libav"
user changes impl to ffmpeg:
FFMPEG_IMPL=ffmpeg
portage output:
media-video/foo USE="... ffmpeg ..." FFMPEG_IMPL="libav -ffmpeg"
ebuild code (yeah, pain to type -- but only once...):
IUSE="ffmpeg ffmpeg_impl_ffmpeg ffmpeg_impl_libav"
RDEPEND="
ffmpeg? (
ffmpeg_impl_ffmpeg? ( media-video/ffmpeg:0= )
ffmpeg_impl_libav? ( media-video/libav:0= )
)"
REQUIRED_USE="ffmpeg? ( ^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav ) )"
non-meaningful flag combinations:
USE="-ffmpeg" FFMPEG_IMPL="*" -> doesn't give you libav or ffmpeg
disallowed flag combinations:
USE="ffmpeg" FFMPEG_IMPL="-ffmpeg -libav" -> no implementation selected
USE="ffmpeg" FFMPEG_IMPL="ffmpeg libav" -> multiple implementations selected
--
Best regards,
Michał Górny
pgpFc6utuRKj0.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] toolchain.eclass: need to revert fixincludes commit
El sáb, 31-01-2015 a las 16:48 -0500, Anthony G. Basile escribió: > Hi everyone, > > We need to revert the following change to toolchain.eclass: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.647&r2=1.648 > > It turns out that bsd and prefix need fixincludes while building gcc > itself, so disabling their build will make gcc unbuildable on those > systems. Only after gcc is built can you dump them. I did test on many > exotic systems, but did not look at gentoo/fbsd. > > See bug #536878. Thanks Ryan and Fabian. > > I'll revert after feedback. > Please remember to add a comment to the eclass with the reference to not forget in the future why fixincludes stuff is needed ;)
Re: [gentoo-dev] Portage news announcement review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02.02.2015 22:58, Brian Dolbec wrote: > > sys-apps/portage-2.2.16 is ready for release and is just waiting > for the news announcement about the new plug-in sync system being > used and the changes in it's operation. > > Attached is the news announcement for review. > > Please replace "3rd party" with "third party" to increase readability. Cheers, Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUz/iAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcl/wP/2r3gixo3A7jWYBb9nINzMVB HzbwzlYYdE/HFGm6TQnT4DcP4QUiRze70Jr5H4mNsoD0Sw7lOL0cSb5B+jTsIYGc qHp4DBRFJmA2fXEt2YUPFBrV4B4+9IGPWph3+kJpcolFTGmngNpBaacc17t0td07 YSMySK7DJyeC5ihHyXqiVEaj45AH+C/Ho4l6vzm1H0+UneKLyNOdPTQ20I38VYLw 1yeJx4eoltK7T53MyG9uFLnjOgM4r9x2Ak0IMu/oQ5b1GnB0bfa+KxP2ZMhjbdIf esiEAbgcme2mIHMvyQZ6RLIhMdGxixhPtbM639KkOBE+6SLSHSoG8nUGFxbc5Ron cCxeIy2kk5H269EAd/jnl1QdP2f6XvOCohoYyc7fHIxTPVGWc+quYTIbZDJx4bXY cnXBL6dFSjab/VCL3ICWo7Pjlmc47QvsK/peEz0mttjRVQizrjb5uLZ5weA29lFt L8w5yRJ01RY7EpGwfc7eaN+7GoUY0wlZYQ/1aBCErhz3/vZ+/enJ6NCat4/lyp49 RNABQlyZrijz2GLGC7dv8ts54pxUQ/QB1VTgNNnnCm/2wA/n462yXZKg4Z40RLNX 9ACOr0trMEOnsYaB8LHZ/2FRa753ehf4+8hRc1I181Hh96y8pYQ18sjsFhbJeEAf g/yDygjBv9mpxGB6DPYt =taxX -END PGP SIGNATURE-
[gentoo-dev] Portage news announcement review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 sys-apps/portage-2.2.16 is ready for release and is just waiting for the news announcement about the new plug-in sync system being used and the changes in it's operation. Attached is the news announcement for review. - -- Brian Dolbec -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUz/MnXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YnvIP/2427hQXe7mAKYhBQg3e7pcB Toxcx1k8qLOChQY2+9v856mKOT4yoe5yV16QV9K5Um1yyWb5e3xOeQT04SBBHJwn xYNrK/vrmdWZhvjox3PCNh5Biwa3Xy+QJlJl1LSVfGIBLxQw1oj4eQy9S/GWuq2Y ZJYrDOZjYkiwQuxDN8uxHtErdUpAQKYEvGYgoLUiLkrkpABcxwUNjacdR4C6hX5j vHcVoa7yVZe3i9Ph+GiHRQgYguNQ0G7C8ttgSAtRl2w17ggEHZVodJcfooUzUiRo IIgM0xAZ79G0Ux8lxK327IaRZZA+e6mHicf64yBvnfjQUeXFyarYvrtlKrEYc/cW O9T8tRysP/UC8CBCeH0ZftYWVgdCLRdiMGtkDpe6Sc5ub0u1nFOgtyUjNDx8h8Oa r8ky9Fo8YJBb4KcsCK6adChHbAQk+3Psl5sDQLZDJJmfFeyq1Murk/5tkI5K10TS edDxrv4R2z/zj2czKyO8MLy4TvWRF8inATf5nxEoEWcIdWlws2hdRjigslxCcrGf TbMLqShgN0e8gSrWz6vps+D2R1+mIRwTbLR46iBCt/45lgU0J4LJWjXN+Jpq//5K Wef3m4FuyqQR61hw/v0RfOi8TTgIJSp+8fw/sbMOx84iii+N6eZ8LoNzctRNmAt0 M7dQUwCmdlZKnnUZ9RP2 =uuiP -END PGP SIGNATURE- sync.news Description: Binary data
[gentoo-dev] Last rites: dev-php/PEAR-MDB2_Driver_sqlite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Brian Evans (02 Feb 2015) # Last rites bug 538584 # >=dev-lang/php-5.4 no longer includes the extension needed # In preparation of dev-lang/php:5.3 removal, Removal in 30 days dev-php/PEAR-MDB2_Driver_sqlite -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJUz+C7AAoJENH3ge/59KO2i+sP/04B1CRauIacsP3EFEgYLOcP y0dH9DMF3o5eI1Qbzjg2mv5xHNTyptWiHVbJkyc21MGSaetfT1JB5l5fTQdOWqdL cLGn0pKJ+cHiqBhGM9ajxGdzjQiYT9GQpmxA9qM9bHcEjyRjB0jCNadtZp2Ombgq pNB5+HXZ8e77QEfET052c+T2g7KrGOPGM9zoT8pOfngJvnsqms9EdiGet8a8Mu0x rj+clfQJbIpP+aXv9r+nTn1vbrW4HHKdC2pn36UDqhV3GGzOc0ZXe7Z0KwcrbL/F 1roNyjkabaLhdv6T0xxRG4ld3rI5rwvLzd0HE2pMfLAKiyLhiUSTEKEuzxNPy2bc Sc92sI6tI9ajPrLnH4SMoO/mHCvgAHtC5a6ibQ2wsoStPLN4ZAAJEcj+AM5oEXRi M8I6BCMI//138yyyas9c/DmpVe166Dp4yCsRxVlai8A4dL6/jPoAmBn80I90ZE00 qD+A8TV8SRmlED2s/s4DPKxST0aNZEhijoMT81knWN5uii+44SwiSrjJ9Z1gr+Tf MSFpCwIaZRaut5sK+RJsq2FTas76vKdT5JiVnTNYMu5ZU+Zj99JfhTEnI/RFu1x4 5EByxTN00EOG2ViAntlTQ+oqpTjdHX3GlsKdBP6mh7xH2axvF+cMn4mDjuO+cNSq 0VhWnGa5EBetkYShHUpH =slUH -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command
On Mon, 2 Feb 2015 19:53:14 +0100
Toralf Förster wrote:
> Signed-off-by: Toralf Förster
> ---
> pym/portage/news.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/pym/portage/news.py b/pym/portage/news.py
> index 2c45f85..ec10feb 100644
> --- a/pym/portage/news.py
> +++ b/pym/portage/news.py
> @@ -421,5 +421,5 @@ def display_news_notifications(news_counts):
>
> if newsReaderDisplay:
> print(colorize("WARN", " *"), end=' ')
> - print("Use " + colorize("GOOD", "eselect news") + "
> to read news items.")
> + print("Use " + colorize("GOOD", "eselect news read")
> + " to view new items.") print()
Wrong list. Plus it's already applied and in git.
--
Brian Dolbec
[gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command
Signed-off-by: Toralf Förster
---
pym/portage/news.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pym/portage/news.py b/pym/portage/news.py
index 2c45f85..ec10feb 100644
--- a/pym/portage/news.py
+++ b/pym/portage/news.py
@@ -421,5 +421,5 @@ def display_news_notifications(news_counts):
if newsReaderDisplay:
print(colorize("WARN", " *"), end=' ')
- print("Use " + colorize("GOOD", "eselect news") + " to read
news items.")
+ print("Use " + colorize("GOOD", "eselect news read") + " to
view new items.")
print()
--
2.2.2
Re: [gentoo-dev] Regarding my final year thesis
Jan Matejka: > On Fri, 16 Jan 2015 21:00:24 +0100 > Luca Barbato wrote: > >> On 16/01/15 18:30, Jan Matejka wrote: >>> On Fri, 07 Nov 2014 10:49:13 +0100 >>> Luca Barbato wrote: >>> On 07/11/14 06:06, Harsh Bhatt wrote: >>> Also make might enjoy improvements. >>> >>> shake? > >> Anything written in haskell tend to be impractical to deploy. > > http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf > Yep, I too think that statement above is incorrect. Also have a look at https://wiki.haskell.org/Haskell_in_industry Microsoft, Google, Facebook, Nvidia...
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 18:18:14 Alexis Ballier napisał(a): > On Mon, 2 Feb 2015 18:08:01 +0100 > Ulrich Mueller wrote: > > > > On Mon, 2 Feb 2015, Alexis Ballier wrote: > > > > > On Mon, 2 Feb 2015 17:14:22 +0100 > > > Ulrich Mueller wrote: > > > > >> Why? When you have USE="-ffmpeg", the libav flag is a "don't care" > > >> which is ignored. "ffmpeg" controls the feature, "libav" chooses > > >> the implementation. This is very clear from the flags' descriptions > > >> and was also well explained in the (N-1) news item. > > > > > Would you offer me a beer each time I'll point you at some user > > > doing USE='-ffmpeg libav' because he wants libav only ? :) > > > > "-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set > > per-package, whereas typically there would be only a global setting of > > "libav". It is quite a similar situation to what we had with openmotif > > and lesstif, where the motif flag enabled the feature, and the lesstif > > flag chose the implementation. > > Even though I got the ffmpeg/libav flags right, the motif situation > actually always confused me :/ > > > Or is it the name of the flag that is causing confusion? That could be > > changed. > > I guess the flag name isn't helping indeed. The initial proposal wanted > to preserve the meaning of the 'ffmpeg' useflag, breaking the symmetry > between ffmpeg & libav flags. Michal proposed the 'libavcodec' flag to > restore it, but IMHO this was even worse. If you happen to have an idea > of a correct name for a flag that enables some of 'libavcodec, > libavutil, libavformat, libswscale, libavresample, libswresample or > libavdevice' support, then please shout. > > What I find interesting in this proposal is that ffmpeg useflag keeps > its old meaning, and we have a symmetric setting for choosing the > implementation. Yes. And think of the beauty of: FFMPEG_IMPL=ffmpeg FFMPEG_IMPL=libav You may even imagine it a regular string config, not a USE_EXPAND! Wes has compared this to ruby & python. One USE=python|ruby on some packages to enable the optional support, and generic globally set RUBY/PYTHON_TARGETS. -- Best regards, Michał Górny pgpCfkGuerDXT.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Regarding my final year thesis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 16 Jan 2015 21:00:24 +0100 Luca Barbato wrote: > On 16/01/15 18:30, Jan Matejka wrote: > > On Fri, 07 Nov 2014 10:49:13 +0100 > > Luca Barbato wrote: > > > >> On 07/11/14 06:06, Harsh Bhatt wrote: > > > >> Also make might enjoy improvements. > > > > shake? > > Anything written in haskell tend to be impractical to deploy. http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf > tup managed to get lots of great ideas spoiled by being impractically > extremist in tracking the directory changes. I don't know what tup is but I'm guessing it's an application. Are you judging a language to be impractical because one application made (allegedly) a bad design decision? - -- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJUz7MtAAoJEIN+7RD5ejahmuoH/1CYfKRdrgtcms2U1Rcio2HQ oJsDY+5SZerGSJrnnohd7l/FHbxcA51H04IUws22GlJ7OnIlVRD/IuYlAyLogc9m bvg/Tt/OuRavHqdhi5JmJfQqYUVZJiEBQok5jG9Aa6+0+d1rPYzUQFsbNQ4ywO12 LLdVATR/2ovrEgVNmgUJQlfeZy6Axo3MwHbBRjsoi+2eKlSVBwKmAQMvpifLr5bI 8l2hOa7CGis02uWa8t8JixZ3XSkqrcjExGQYcBbWdCYVulfXgUbz0pNkQipOCOh+ +bNzubNDOGMSyiJ1mmtRG46vEKhgefns+IvxEhiOIIeJajPJR+R3EU0cV2LAvD0= =+ORA -END PGP SIGNATURE-
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015 18:08:01 +0100 Ulrich Mueller wrote: > > On Mon, 2 Feb 2015, Alexis Ballier wrote: > > > On Mon, 2 Feb 2015 17:14:22 +0100 > > Ulrich Mueller wrote: > > >> Why? When you have USE="-ffmpeg", the libav flag is a "don't care" > >> which is ignored. "ffmpeg" controls the feature, "libav" chooses > >> the implementation. This is very clear from the flags' descriptions > >> and was also well explained in the (N-1) news item. > > > Would you offer me a beer each time I'll point you at some user > > doing USE='-ffmpeg libav' because he wants libav only ? :) > > "-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set > per-package, whereas typically there would be only a global setting of > "libav". It is quite a similar situation to what we had with openmotif > and lesstif, where the motif flag enabled the feature, and the lesstif > flag chose the implementation. Even though I got the ffmpeg/libav flags right, the motif situation actually always confused me :/ > Or is it the name of the flag that is causing confusion? That could be > changed. I guess the flag name isn't helping indeed. The initial proposal wanted to preserve the meaning of the 'ffmpeg' useflag, breaking the symmetry between ffmpeg & libav flags. Michal proposed the 'libavcodec' flag to restore it, but IMHO this was even worse. If you happen to have an idea of a correct name for a flag that enables some of 'libavcodec, libavutil, libavformat, libswscale, libavresample, libswresample or libavdevice' support, then please shout. What I find interesting in this proposal is that ffmpeg useflag keeps its old meaning, and we have a symmetric setting for choosing the implementation. Alexis.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 11:00:59 Michael Orlitzky napisał(a): > On 02/02/2015 10:50 AM, Michał Górny wrote: > > > > Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. > > > > We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then > ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. Wasn't that your point in the first mail? > > Maybe a little cleaner but still relies on the implicit thing. Not to > > mention the user is supposed to set either: > > > > FFMPEG_IMPL=libav > > > > or: > > > > FFMPEG_IMPL= > > > > which is nowhere close to sane :). > > > > With only one flag, why bother with the USE_EXPAND? Because otherwise we're back to USE=libav, only named different and illegally as well (PMS sez _ is reserved for USE_EXPAND). -- Best regards, Michał Górny pgpoluzNtkCla.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 18:08:01 Ulrich Mueller napisał(a): > > On Mon, 2 Feb 2015, Alexis Ballier wrote: > > > On Mon, 2 Feb 2015 17:14:22 +0100 > > Ulrich Mueller wrote: > > >> Why? When you have USE="-ffmpeg", the libav flag is a "don't care" > >> which is ignored. "ffmpeg" controls the feature, "libav" chooses > >> the implementation. This is very clear from the flags' descriptions > >> and was also well explained in the (N-1) news item. > > > Would you offer me a beer each time I'll point you at some user > > doing USE='-ffmpeg libav' because he wants libav only ? :) > > "-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set > per-package, whereas typically there would be only a global setting of > "libav". It is quite a similar situation to what we had with openmotif > and lesstif, where the motif flag enabled the feature, and the lesstif > flag chose the implementation. It is valid but USE=libav is then unexpectedly meaningless :). This thread alone shows how confused users are by it. > Or is it the name of the flag that is causing confusion? That could be > changed. Maybe. But there's no good solution for that either. My USE=avcodec idea brought many complaints... But even then, regular USE flags for this kind of global switch don't work well. Maybe we should do the Arfrever thing. USE=ffmpeg-or-libav and USE=ffmpeg-instead-of-libav. This will avoid most of the confusion, though ffmpeg users will complain that we don't have USE=libav-instead-of-ffmpeg instead. -- Best regards, Michał Górny pgpHfJ_0thvus.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
> On Mon, 2 Feb 2015, Alexis Ballier wrote: > On Mon, 2 Feb 2015 17:14:22 +0100 > Ulrich Mueller wrote: >> Why? When you have USE="-ffmpeg", the libav flag is a "don't care" >> which is ignored. "ffmpeg" controls the feature, "libav" chooses >> the implementation. This is very clear from the flags' descriptions >> and was also well explained in the (N-1) news item. > Would you offer me a beer each time I'll point you at some user > doing USE='-ffmpeg libav' because he wants libav only ? :) "-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set per-package, whereas typically there would be only a global setting of "libav". It is quite a similar situation to what we had with openmotif and lesstif, where the motif flag enabled the feature, and the lesstif flag chose the implementation. Or is it the name of the flag that is causing confusion? That could be changed. Ulrich pgpizrRHeh90a.pgp Description: PGP signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015 17:14:22 +0100 Ulrich Mueller wrote: > > On Mon, 2 Feb 2015, Alexis Ballier wrote: > > > Ulrich Mueller wrote: > > >> In a nutshell, you have a binary choice here, namely ffmpeg or > >> libav as implementation, and instead of one USE flag you want to > >> introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of > >> the 4 possible combinations only 2 are valid. So you need a > >> REQUIRED_USE to forbid some combinations. > > > We already have three possibilities: ffmpeg, libav or none (only for > > some packages but they do exist). > > Right. > > > With the N-1th proposal, it was overseen that USE="-ffmpeg libav" > > should be forbidden by REQUIRED_USE. > > Why? When you have USE="-ffmpeg", the libav flag is a "don't care" > which is ignored. "ffmpeg" controls the feature, "libav" chooses the > implementation. This is very clear from the flags' descriptions and > was also well explained in the (N-1) news item. Would you offer me a beer each time I'll point you at some user doing USE='-ffmpeg libav' because he wants libav only ? :) > > With the N-1th proposal, we had two bits (USE='ffmpeg libav') to > > code 3 states. With the above proposal, we have a kind of unary > > coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means > > '$x'. > > Yes, but you would then have 3 bits (i.e. 8 combinations) to code only > 3 possible states. Yes, unary is very inefficient :) My real answer is: I don't know, I'm fine with both, but IMHO we should aim at something natural and straightforward for users. (and if I can get free beer, that's even better :) ) Alexis.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
> On Tue, 3 Feb 2015, Ben de Groot wrote: > Please restore the news item and unmask the revbumps, so we can get on > with business. :) +1 pgpf349IEiEzV.pgp Description: PGP signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
> On Mon, 2 Feb 2015, Alexis Ballier wrote: > Ulrich Mueller wrote: >> In a nutshell, you have a binary choice here, namely ffmpeg or >> libav as implementation, and instead of one USE flag you want to >> introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of >> the 4 possible combinations only 2 are valid. So you need a >> REQUIRED_USE to forbid some combinations. > We already have three possibilities: ffmpeg, libav or none (only for > some packages but they do exist). Right. > With the N-1th proposal, it was overseen that USE="-ffmpeg libav" > should be forbidden by REQUIRED_USE. Why? When you have USE="-ffmpeg", the libav flag is a "don't care" which is ignored. "ffmpeg" controls the feature, "libav" chooses the implementation. This is very clear from the flags' descriptions and was also well explained in the (N-1) news item. -ffmpeg -libav -> none -ffmpeg +libav -> none +ffmpeg -libav -> ffmpeg +ffmpeg +libav -> libav > With the N-1th proposal, we had two bits (USE='ffmpeg libav') to > code 3 states. With the above proposal, we have a kind of unary > coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means > '$x'. Yes, but you would then have 3 bits (i.e. 8 combinations) to code only 3 possible states. > I understand your point; I'm not entirely convinced which one is > better, but I'm tempted by the simplicity for users of the above > unary proposal. Ulrich pgpQD5Sh7BzBx.pgp Description: PGP signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 3 February 2015 at 00:00, Michael Orlitzky wrote: > On 02/02/2015 10:50 AM, Michał Górny wrote: >> >> Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. >> > > We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then > ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. > > > >> Maybe a little cleaner but still relies on the implicit thing. Not to >> mention the user is supposed to set either: >> >> FFMPEG_IMPL=libav >> >> or: >> >> FFMPEG_IMPL= >> >> which is nowhere close to sane :). >> > > With only one flag, why bother with the USE_EXPAND? > > Actually, after reading this conversation, I don't think we need the USE_EXPAND. The current solution with USE="ffmpeg libav" works. It may not be the cleanest, but the other solution proposed here doesn't add that much. Please restore the news item and unmask the revbumps, so we can get on with business. :) -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 09:06 AM, Michał Górny wrote: > Hi, everyone. > > Just after the news item got published, user Wes mailed me with > a suggestion. While I think someone mentioned it earlier > in the bikesheds over ffmpeg, I have completely forgotten about it > and now I'd like to reconsider it. For this reason, I've reverted > the news item while it's still fresh and p.masked the revbumps. > > The idea is that instead of having USE=libav (that's tangential to > USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking > either ffmpeg or libav. Now, why... > > > First of all, one of the key points in my news item is that users need > to keep consistent state of USE=libav throughout all the packages. Wes > pointed out that users are more likely to consider a dedicated variable > (USE_EXPAND) in make.conf global than a regular USE flag. Which makes > it more likely for them to end up in terrible state full of blockers. > > Secondly, it avoids the confusion of having USE=ffmpeg and USE=libav > being used for completely different purposes. This is not only > confusing by users who need to set USE='ffmpeg libav' if they want > libav, but also confusing to developers who may end up using the two > flags to signify the two implementations. Think of the mess of USE='gtk > gtk3'. I might not have followed this discussion close enough; wasn't the end result that USE='ffmpeg' uses ffmpeg and USE='libav' uses libav? As in there will be no more USE='ffmpeg libav' in the future, only USE='libav' for libav? > > FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg > tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will > exactly get used. Much less confusion. I would agree except that as far as I know ffmpeg and libav are not trying to be binary compatible. > > Fourthly, there's the case of implicity. Right now USE=-libav implies > ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda > weird since it's supposedly the non-default. With this solution, USE=-* > will result in explicit error asking user to select an implementation. > > As for the downsides: > > 1. there is a number of non-meaningful flag combinations. > FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be > blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. > > 2. There is some more work to get ebuilds correct (REQUIRED_USE). > However, this is a minor issue compared to the potential mistakes in > interpretation of USE='ffmpeg' and USE='libav'. > > > What are your thoughts? > During the earlier discussion, I was of the opinion that USE='ffmpeg' should just cause a dependency on virtual/ffmpeg and that would solve all the problems. I don't think this is right, though; if ffmpeg and libav are not trying for (or actively avoiding) binary compatibility, why not treat them as separate projects and just add RDEPEND='!media-video/ffmpeg' to libav's ebuild and vice versa? Just my two cents. I'm not a developer, but this seems like the simplest solution to me. Alec
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 10:50 AM, Michał Górny wrote: > > Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. > We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. > Maybe a little cleaner but still relies on the implicit thing. Not to > mention the user is supposed to set either: > > FFMPEG_IMPL=libav > > or: > > FFMPEG_IMPL= > > which is nowhere close to sane :). > With only one flag, why bother with the USE_EXPAND?
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015 15:12:50 +0100 Ulrich Mueller wrote: > > What are your thoughts? > > In a nutshell, you have a binary choice here, namely ffmpeg or libav > as implementation, and instead of one USE flag you want to introduce > two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible > combinations only 2 are valid. So you need a REQUIRED_USE to forbid > some combinations. We already have three possibilities: ffmpeg, libav or none (only for some packages but they do exist). With the N-1th proposal, it was overseen that USE="-ffmpeg libav" should be forbidden by REQUIRED_USE. With the N-1th proposal, we had two bits (USE='ffmpeg libav') to code 3 states. With the above proposal, we have a kind of unary coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means '$x'. I understand your point; I'm not entirely convinced which one is better, but I'm tempted by the simplicity for users of the above unary proposal. Alexis.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 10:44:46 Michael Orlitzky napisał(a): > On 02/02/2015 09:12 AM, Ulrich Mueller wrote: > > > >> What are your thoughts? > > > > In a nutshell, you have a binary choice here, namely ffmpeg or libav > > as implementation, and instead of one USE flag you want to introduce > > two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible > > combinations only 2 are valid. So you need a REQUIRED_USE to forbid > > some combinations. > > > > Please spare us of this. > > > > Why do we need two flags for this? Wouldn't a single global > USE=ffmpeg_impl_libav have exactly the desired behavior? Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. I mean: ffmpeg? ( !libav? ( ffmpeg ) libav? ( ffmpeg ) ) (or without the outer 'ffmpeg?'). In your variant: ffmpeg? ( !ffmpeg_impl_libav? ( ffmpeg ) ffmpeg_impl_libav? ( ffmpeg ) ) Maybe a little cleaner but still relies on the implicit thing. Not to mention the user is supposed to set either: FFMPEG_IMPL=libav or: FFMPEG_IMPL= which is nowhere close to sane :). -- Best regards, Michał Górny pgps1Uqc3SzWL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 09:12 AM, Ulrich Mueller wrote: > >> What are your thoughts? > > In a nutshell, you have a binary choice here, namely ffmpeg or libav > as implementation, and instead of one USE flag you want to introduce > two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible > combinations only 2 are valid. So you need a REQUIRED_USE to forbid > some combinations. > > Please spare us of this. > Why do we need two flags for this? Wouldn't a single global USE=ffmpeg_impl_libav have exactly the desired behavior?
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 08:54:04 Gordon Pettey napisał(a): > Having USE="ffmpeg" at all is the source of any confusion in case somebody > is using libav. Either with an expand set (which seems wasted just for two > options) or two regular flags, just force one or none. There is absolutely > no sense in having USE="ffmpeg" on for a system using libav. If things were that simple, you wouldn't need me :P. This would mean that the flags have two slightly different uses. They either enable ffmpeg or libav when it is optional, or they choose between ffmpeg or libav when it is not. Not that bad? Now if we want to default to libav, we set USE=libav. Oh wait, that enables optional libav support in all packages. And if we don't do that, a number of packages with obligatory ffmpeg/libav support doesn't install by default. Users have real trouble setting their preferences too. If they prefer ffmpeg, they need to change that for every package in question or they implicitly enable the optional support for all packages. -- Best regards, Michał Górny pgp2s0QAAxlmT.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Having USE="ffmpeg" at all is the source of any confusion in case somebody is using libav. Either with an expand set (which seems wasted just for two options) or two regular flags, just force one or none. There is absolutely no sense in having USE="ffmpeg" on for a system using libav. On Mon, Feb 2, 2015 at 8:12 AM, Ulrich Mueller wrote: > > On Mon, 2 Feb 2015, Michał Górny wrote: > > > FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg > > tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will > > exactly get used. Much less confusion. > > > Thirdly, this opens space for having more than two different > > implementations in the future without having to reset the system. Maybe > > this isn't something worth considering but -- as I see it -- the first > > big fork starts a precedent, and both current versions suck :). > > > Fourthly, there's the case of implicity. Right now USE=-libav implies > > ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda > > weird since it's supposedly the non-default. With this solution, USE=-* > > will result in explicit error asking user to select an implementation. > > > As for the downsides: > > > 1. there is a number of non-meaningful flag combinations. > > FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be > > blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. > > > 2. There is some more work to get ebuilds correct (REQUIRED_USE). > > However, this is a minor issue compared to the potential mistakes in > > interpretation of USE='ffmpeg' and USE='libav'. > > > > What are your thoughts? > > In a nutshell, you have a binary choice here, namely ffmpeg or libav > as implementation, and instead of one USE flag you want to introduce > two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible > combinations only 2 are valid. So you need a REQUIRED_USE to forbid > some combinations. > > Please spare us of this. > > Ulrich >
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/ruby: ruby-1.9.3_p551.ebuild ruby-2.2.0.ebuild ChangeLog ruby-2.0.0_p598.ebuild ruby-2.1.5.ebuild
Cool.
However, this should be done in a revbump, so that we do not rely on
dynamic deps. And it's reasonable to assume that people want to update
for this change.
Hans de Graaff (graaff):
> graaff 15/01/19 20:07:18
>
> Modified: ruby-1.9.3_p551.ebuild ruby-2.2.0.ebuild ChangeLog
> ruby-2.0.0_p598.ebuild ruby-2.1.5.ebuild
> Log:
> Change the virtual/rubygems dependency to refer to the RUBY_TARGET in
> preparation of removing the version-specific slots.
>
> (Portage version: 2.2.14/cvs/Linux x86_64, signed Manifest commit with key
> 0x8883FA56A308A8D7!)
>
> Revision ChangesPath
> 1.11 dev-lang/ruby/ruby-1.9.3_p551.ebuild
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ruby-1.9.3_p551.ebuild?rev=1.11&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ruby-1.9.3_p551.ebuild?rev=1.11&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ruby-1.9.3_p551.ebuild?r1=1.10&r2=1.11
>
> Index: ruby-1.9.3_p551.ebuild
> ===
> RCS file: /var/cvsroot/gentoo-x86/dev-lang/ruby/ruby-1.9.3_p551.ebuild,v
> retrieving revision 1.10
> retrieving revision 1.11
> diff -u -r1.10 -r1.11
> --- ruby-1.9.3_p551.ebuild6 Dec 2014 16:51:35 - 1.10
> +++ ruby-1.9.3_p551.ebuild19 Jan 2015 20:07:18 - 1.11
> @@ -1,6 +1,6 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/dev-lang/ruby/ruby-1.9.3_p551.ebuild,v
> 1.10 2014/12/06 16:51:35 ago Exp $
> +# $Header: /var/cvsroot/gentoo-x86/dev-lang/ruby/ruby-1.9.3_p551.ebuild,v
> 1.11 2015/01/19 20:07:18 graaff Exp $
>
> EAPI=4
>
> @@ -58,7 +58,7 @@
>
> DEPEND="${RDEPEND}"
> PDEPEND="
> - virtual/rubygems:ruby19
> + virtual/rubygems[ruby_targets_ruby19]
> rdoc? ( >=dev-ruby/rdoc-3.9.4[ruby_targets_ruby19] )
> xemacs? ( app-xemacs/ruby-modes )"
>
>
>
>
> 1.3 dev-lang/ruby/ruby-2.2.0.ebuild
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ruby-2.2.0.ebuild?rev=1.3&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ruby-2.2.0.ebuild?rev=1.3&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ruby-2.2.0.ebuild?r1=1.2&r2=1.3
>
> Index: ruby-2.2.0.ebuild
> ===
> RCS file: /var/cvsroot/gentoo-x86/dev-lang/ruby/ruby-2.2.0.ebuild,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- ruby-2.2.0.ebuild 14 Jan 2015 06:45:24 - 1.2
> +++ ruby-2.2.0.ebuild 19 Jan 2015 20:07:18 - 1.3
> @@ -1,6 +1,6 @@
> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/dev-lang/ruby/ruby-2.2.0.ebuild,v 1.2
> 2015/01/14 06:45:24 graaff Exp $
> +# $Header: /var/cvsroot/gentoo-x86/dev-lang/ruby/ruby-2.2.0.ebuild,v 1.3
> 2015/01/19 20:07:18 graaff Exp $
>
> EAPI=5
>
> @@ -51,7 +51,7 @@
>
> DEPEND="${RDEPEND}"
> PDEPEND="
> - virtual/rubygems:ruby22
> + virtual/rubygems[ruby_targets_ruby22]
> >=dev-ruby/json-1.8.1[ruby_targets_ruby22]
> >=dev-ruby/rake-0.9.6[ruby_targets_ruby22]
> rdoc? ( >=dev-ruby/rdoc-4.0.1[ruby_targets_ruby22] )
>
>
>
> 1.698dev-lang/ruby/ChangeLog
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ChangeLog?rev=1.698&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ChangeLog?rev=1.698&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-lang/ruby/ChangeLog?r1=1.697&r2=1.698
>
> Index: ChangeLog
> ===
> RCS file: /var/cvsroot/gentoo-x86/dev-lang/ruby/ChangeLog,v
> retrieving revision 1.697
> retrieving revision 1.698
> diff -u -r1.697 -r1.698
> --- ChangeLog 14 Jan 2015 06:45:24 - 1.697
> +++ ChangeLog 19 Jan 2015 20:07:18 - 1.698
> @@ -1,6 +1,11 @@
> # ChangeLog for dev-lang/ruby
> # Copyright 1999-2015 Gentoo Foundation; Distributed under the GPL v2
> -# $Header: /var/cvsroot/gentoo-x86/dev-lang/ruby/ChangeLog,v 1.697
> 2015/01/14 06:45:24 graaff Exp $
> +# $Header: /var/cvsroot/gentoo-x86/dev-lang/ruby/ChangeLog,v 1.698
> 2015/01/19 20:07:18 graaff Exp $
> +
> + 19 Jan 2015; Hans de Graaff ruby-1.9.3_p551.ebuild,
> + ruby-2.0.0_p598.ebuild, ruby-2.1.5.ebuild, ruby-2.2.0.ebuild:
> + Change the virtual/rubygems dependency to refer to the RUBY_TARGET in
> + preparation of removing the version-specific slots.
>
>14 Jan 2015; Hans de Graaff ruby-2.2.0.ebuild:
>The broken sse2 detection
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
> On Mon, 2 Feb 2015, Michał Górny wrote: > FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg > tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will > exactly get used. Much less confusion. > Thirdly, this opens space for having more than two different > implementations in the future without having to reset the system. Maybe > this isn't something worth considering but -- as I see it -- the first > big fork starts a precedent, and both current versions suck :). > Fourthly, there's the case of implicity. Right now USE=-libav implies > ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda > weird since it's supposedly the non-default. With this solution, USE=-* > will result in explicit error asking user to select an implementation. > As for the downsides: > 1. there is a number of non-meaningful flag combinations. > FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be > blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. > 2. There is some more work to get ebuilds correct (REQUIRED_USE). > However, this is a minor issue compared to the potential mistakes in > interpretation of USE='ffmpeg' and USE='libav'. > What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. Please spare us of this. Ulrich pgpIkVFI7ycMJ.pgp Description: PGP signature
[gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Hi, everyone. Just after the news item got published, user Wes mailed me with a suggestion. While I think someone mentioned it earlier in the bikesheds over ffmpeg, I have completely forgotten about it and now I'd like to reconsider it. For this reason, I've reverted the news item while it's still fresh and p.masked the revbumps. The idea is that instead of having USE=libav (that's tangential to USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking either ffmpeg or libav. Now, why... First of all, one of the key points in my news item is that users need to keep consistent state of USE=libav throughout all the packages. Wes pointed out that users are more likely to consider a dedicated variable (USE_EXPAND) in make.conf global than a regular USE flag. Which makes it more likely for them to end up in terrible state full of blockers. Secondly, it avoids the confusion of having USE=ffmpeg and USE=libav being used for completely different purposes. This is not only confusing by users who need to set USE='ffmpeg libav' if they want libav, but also confusing to developers who may end up using the two flags to signify the two implementations. Think of the mess of USE='gtk gtk3'. FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will exactly get used. Much less confusion. Thirdly, this opens space for having more than two different implementations in the future without having to reset the system. Maybe this isn't something worth considering but -- as I see it -- the first big fork starts a precedent, and both current versions suck :). Fourthly, there's the case of implicity. Right now USE=-libav implies ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda weird since it's supposedly the non-default. With this solution, USE=-* will result in explicit error asking user to select an implementation. As for the downsides: 1. there is a number of non-meaningful flag combinations. FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. 2. There is some more work to get ebuilds correct (REQUIRED_USE). However, this is a minor issue compared to the potential mistakes in interpretation of USE='ffmpeg' and USE='libav'. What are your thoughts? -- Best regards, Michał Górny pgpeNeJbZBumV.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] git-r3.eclass: respect EVCS_UMASK
Dnia 2015-02-02, o godz. 10:46:34
Ulrich Mueller napisał(a):
> > On Sun, 1 Feb 2015, I wrote:
>
> > On Sun, 1 Feb 2015, Michał Górny wrote:
>
> >>> + local restore_umask=":"
> >>> + if [[ ${EVCS_UMASK} ]]; then
> >>> + restore_umask=$(umask -p)
> >>> + umask "${EVCS_UMASK}" || die "Bad options to umask:
> >>> ${EVCS_UMASK}"
> >>> + fi
> >>> mkdir "${GIT_DIR}" || die
> >>> git init --bare || die
> >>> + ${restore_umask} || die
>
> >> And this has ugly implicit pattern expansion. Don't do such things.
> >> Ever. Even if you want to split commands.
>
> > Please show me how this could possibly cause any problem here.
> > restore_umask can only have well-defined values, either ":" or
> > the output of "umask -p" which is intended to be used this way.
>
> Anyway, since you don't seem to like the way it is coded, I've
> attached an updated patch.
Yes, I like the old fashion way a lot more ;). Thanks.
--
Best regards,
Michał Górny
pgpCCWAJMSsPw.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] about the stable requests
On Sat, 31 Jan 2015 14:40:47 +0100 Agostino Sarubbo wrote: > Looks like everyone is file stable requests with own > rules or better to say is without common rules. What is the problem? > I'd like to document a sort of best-practice(s) on > our wiki. > Who want to partecipate? It's a wiki. Nothing is stopping you from drafting anything and then proposing to make that into something canonical. jer
Re: [gentoo-dev] [PATCH] git-r3.eclass: respect EVCS_UMASK
> On Sun, 1 Feb 2015, I wrote:
> On Sun, 1 Feb 2015, Michał Górny wrote:
>>> + local restore_umask=":"
>>> + if [[ ${EVCS_UMASK} ]]; then
>>> + restore_umask=$(umask -p)
>>> + umask "${EVCS_UMASK}" || die "Bad options to umask:
>>> ${EVCS_UMASK}"
>>> + fi
>>> mkdir "${GIT_DIR}" || die
>>> git init --bare || die
>>> + ${restore_umask} || die
>> And this has ugly implicit pattern expansion. Don't do such things.
>> Ever. Even if you want to split commands.
> Please show me how this could possibly cause any problem here.
> restore_umask can only have well-defined values, either ":" or
> the output of "umask -p" which is intended to be used this way.
Anyway, since you don't seem to like the way it is coded, I've
attached an updated patch.
Ulrich
Index: git-r3.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/git-r3.eclass,v
retrieving revision 1.47
diff -u -B -p -r1.47 git-r3.eclass
--- git-r3.eclass 28 Jul 2014 14:13:50 - 1.47
+++ git-r3.eclass 2 Feb 2015 07:34:09 -
@@ -131,6 +131,17 @@ fi
# @DESCRIPTION:
# If non-empty, this variable prevents any online operations.
+# @ECLASS-VARIABLE: EVCS_UMASK
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Set this variable to a custom umask. This is intended to be set by
+# users. By setting this to something like 002, it can make life easier
+# for people who do development as non-root (but are in the portage
+# group), and then switch over to building with FEATURES=userpriv.
+# Or vice-versa. Shouldn't be a security issue here as anyone who has
+# portage group write access already can screw the system over in more
+# creative ways.
+
# @ECLASS-VARIABLE: EGIT_BRANCH
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -309,8 +320,16 @@ _git-r3_set_gitdir() {
addwrite "${EGIT3_STORE_DIR}"
if [[ ! -d ${GIT_DIR} ]]; then
+ local saved_umask
+ if [[ ${EVCS_UMASK} ]]; then
+ saved_umask=$(umask)
+ umask "${EVCS_UMASK}" || die "Bad options to umask:
${EVCS_UMASK}"
+ fi
mkdir "${GIT_DIR}" || die
git init --bare || die
+ if [[ ${saved_umask} ]]; then
+ umask "${saved_umask}" || die
+ fi
fi
}
@@ -507,7 +526,11 @@ git-r3_fetch() {
fi
# try to fetch from the remote
- local r success
+ local r success saved_umask
+ if [[ ${EVCS_UMASK} ]]; then
+ saved_umask=$(umask)
+ umask "${EVCS_UMASK}" || die "Bad options to umask:
${EVCS_UMASK}"
+ fi
for r in "${repos[@]}"; do
einfo "Fetching ${r} ..."
@@ -668,6 +691,9 @@ git-r3_fetch() {
break
fi
done
+ if [[ ${saved_umask} ]]; then
+ umask "${saved_umask}" || die
+ fi
[[ ${success} ]] || die "Unable to fetch from any of EGIT_REPO_URI"
# submodules can reference commits in any branch
pgp9EwitgkORW.pgp
Description: PGP signature
