# Hans de Graaff (09 Jul 2017)
# Upstream has removed the code and the published gem.
# Removal in 30 days.
dev-ruby/modernizr
signature.asc
Description: This is a digitally signed message part
On Sat, Jul 8, 2017 at 6:39 PM, William L. Thomson Jr.
wrote:
> On Sat, 8 Jul 2017 18:30:10 -0700
> Zac Medico wrote:
>
>> On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr.
>> wrote:
>> > On Sat, 8 Jul 2017 16:35:34 -0700
>> > Zac Medico wrote:
>> >
>> >> For live-rebuild, it would be
>> >
On Sat, 8 Jul 2017 18:30:10 -0700
Zac Medico wrote:
> On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr.
> wrote:
> > On Sat, 8 Jul 2017 16:35:34 -0700
> > Zac Medico wrote:
> >
> >> For live-rebuild, it would be
> >> much nicer to have a framework that automatically triggers rebuilds
> >
On Sat, 8 Jul 2017 20:27:38 -0400
"Walter Dnes" wrote:
>
> > Though I will have to see what happens if a package is listed in
> > more than one set. I think there is a hierarchy there.
>
> I tried "emerge -pv --unmerge @palemoon_build", and it was ready to
> delete all the stuff, including gc
On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr.
wrote:
> On Sat, 8 Jul 2017 16:35:34 -0700
> Zac Medico wrote:
>
>> For live-rebuild, it would be
>> much nicer to have a framework that automatically triggers rebuilds
>> when upstream changes are detected, like smart-live-rebuild.
>
> Which
On Sat, Jul 8, 2017 at 8:27 PM, Walter Dnes wrote:
>
> Let's say I try to do this as a meta package. So in my overlay I
> create a category "meta-set" and a file "meta-set/pmbuild-0.ebuild"
>
> EAPI=5
> SLOT="0"
> KEYWORDS="amd64 x86"
> DEPEND="
>>=app-arch/zip-2.3
>>=dev-lang/p
On Sun, 9 Jul 2017 01:10:11 +0100
Ciaran McCreesh wrote:
> On Sat, 8 Jul 2017 19:58:13 -0400
> "William L. Thomson Jr." wrote:
> > On Sun, 9 Jul 2017 00:49:57 +0100
> > Ciaran McCreesh wrote:
> > > On Sat, 8 Jul 2017 19:39:33 -0400
> > > "William L. Thomson Jr." wrote:
> > > > The two wa
On Fri, Jul 07, 2017 at 01:07:57PM -0400, William L. Thomson Jr. wrote
> On Fri, 7 Jul 2017 12:57:17 -0400
> Brian Evans wrote:
>
> > Beware of sets.. if you put toolchain packages in a set and later
> > do 'emerge --unmerge @custom-set' , emerge will happily destroy
> > your toolchain.
>
> That
On Sat, 8 Jul 2017 19:58:13 -0400
"William L. Thomson Jr." wrote:
> On Sun, 9 Jul 2017 00:49:57 +0100
> Ciaran McCreesh wrote:
> > On Sat, 8 Jul 2017 19:39:33 -0400
> > "William L. Thomson Jr." wrote:
> > > The two ways are not the same, and there is a reason sets exist in
> > > the first plac
On Sun, 9 Jul 2017 00:49:57 +0100
Ciaran McCreesh wrote:
> On Sat, 8 Jul 2017 19:39:33 -0400
> "William L. Thomson Jr." wrote:
> > The two ways are not the same, and there is a reason sets exist in
> > the first place. People seem to be over looking that fact. I did
> > not add sets. They are no
On Sat, 8 Jul 2017 19:39:33 -0400
"William L. Thomson Jr." wrote:
> The two ways are not the same, and there is a reason sets exist in the
> first place. People seem to be over looking that fact. I did not add
> sets. They are not new. I am simply trying to expand their use.
Sets exist because p
On Sat, 8 Jul 2017 16:35:34 -0700
Zac Medico wrote:
> On Sat, Jul 8, 2017 at 4:09 PM, William L. Thomson Jr.
> wrote:
> > Sets are also used for package rebuilds, like x11-module-rebuild,
> > live-rebuild, and others.
>
> Usually there are better ways to trigger rebuilds.
Those have nothing
On Sat, 8 Jul 2017 19:24:46 -0400
Rich Freeman wrote:
>
> I don't see why a package manager couldn't offer the same
> functionality for a meta package. As was pointed out the set behavior
> for unmerging isn't always desirable.
Your missing that sets maybe made by the user, Making a meta ebuild
On Sat, Jul 8, 2017 at 4:09 PM, William L. Thomson Jr.
wrote:
> Sets are also used for package rebuilds, like x11-module-rebuild,
> live-rebuild, and others.
Usually there are better ways to trigger rebuilds. For example, slot
operator dependencies for rebuilds due to subslot changes, and
--newus
On Sat, Jul 8, 2017 at 7:09 PM, William L. Thomson Jr.
wrote:
> On Sat, 8 Jul 2017 18:34:55 -0400
> Rich Freeman wrote:
>>
>> What do sets get us that packages do not? Why not move the other
>> direction and just have packages instead of sets?
>
> The blog entry I provided a link to I think made
On Sat, 8 Jul 2017 18:34:55 -0400
Rich Freeman wrote:
>
> What do sets get us that packages do not? Why not move the other
> direction and just have packages instead of sets?
The blog entry I provided a link to I think made the best case example
of usage of sets and their benefits.
https://maku
On 07/08/2017 03:29 PM, Michał Górny wrote:
> On sob, 2017-07-08 at 15:21 -0700, Daniel Campbell wrote:
>> On 07/08/2017 02:43 AM, Michał Górny wrote:
>>> Hi, everyone.
>>>
>>> I think the affairs have settled enough and I've finished filling
>>> in the pre-GLEP for REQUIRED_USE auto-enforcing. It'
On Fri, Jul 7, 2017 at 10:21 PM, Michael Palimaka wrote:
>
> Bug #272488[0] proposed a PROPERTIES="set" feature to combine the power
> of sets with the flexibility of ebuilds.
>
> 1: https://bugs.gentoo.org/show_bug.cgi?id=272488
>
What do sets get us that packages do not? Why not move the other
On sob, 2017-07-08 at 15:21 -0700, Daniel Campbell wrote:
> On 07/08/2017 02:43 AM, Michał Górny wrote:
> > Hi, everyone.
> >
> > I think the affairs have settled enough and I've finished filling
> > in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
> > the algorithms, rationale and se
On 07/08/2017 02:43 AM, Michał Górny wrote:
> Hi, everyone.
>
> I think the affairs have settled enough and I've finished filling
> in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
> the algorithms, rationale and separated reference implementation.
>
> If there are no major concerns
For anyone interested in such, I opened a feature request bug for
allowing use of sets in profile packages.
https://bugs.gentoo.org/show_bug.cgi?id=624300
P.S.
Miss posted on wrong thread... thus duplicate, sorry!
--
William L. Thomson Jr.
pgpkQZ6BpgeJj.pgp
Description: OpenPGP digital signa
On sob, 2017-07-08 at 23:56 +0200, Michał Górny wrote:
> On sob, 2017-07-08 at 22:34 +0200, Alexis Ballier wrote:
> > Unless I'm missing something, rationale seems more about cases rejected
> > by the restricted syntax. Numbers I'm talking about is the # of rejected
> > constraints vs accepted (and
For anyone interested in such, I opened a feature request bug for
allowing use of sets in profile packages.
https://bugs.gentoo.org/show_bug.cgi?id=624300
--
William L. Thomson Jr.
pgp04RTMoMwAV.pgp
Description: OpenPGP digital signature
On 07/08/2017 11:31 PM, Michał Górny wrote:
> Nobody said anything about the next EAPI. The GLEP doesn't say a word
> about introducing it in a future EAPI.
>
> We're adding this as an optional (default off) FEATURE into Portage
> and we'll see how it works. As far as I'm concerned, we can enable
On sob, 2017-07-08 at 22:34 +0200, Alexis Ballier wrote:
> On Sat, 08 Jul 2017 20:44:24 +0200
> Michał Górny wrote:
>
> > On sob, 2017-07-08 at 16:12 +0200, Alexis Ballier wrote:
> > > On Sat, 08 Jul 2017 11:43:39 +0200
> > > Michał Górny wrote:
> > >
> > > > Hi, everyone.
> > > >
> > > > I
On sob, 2017-07-08 at 20:58 +0200, Ulrich Mueller wrote:
> > > > > > On Sat, 08 Jul 2017, Michał Górny wrote:
> > On sob, 2017-07-08 at 12:26 +0200, Ulrich Mueller wrote:
> > > Section "Processing algorithm":
> > >
> > > > 2. Check whether the REQUIRED_USE constraint matches restrictions
> > > > s
On Sat, 08 Jul 2017 20:44:24 +0200
Michał Górny wrote:
> On sob, 2017-07-08 at 16:12 +0200, Alexis Ballier wrote:
> > On Sat, 08 Jul 2017 11:43:39 +0200
> > Michał Górny wrote:
> >
> > > Hi, everyone.
> > >
> > > I think the affairs have settled enough and I've finished filling
> > > in the
Move the GNOME2_ECLASS_GLIB_SCHEMAS conditional from
gnome2_schemas_update straight into the implementation of gnome2.eclass
postinst/postrm.
This variable is set in preinst to indicate whether any files were
installed. However, the updater itself does not use the list in any way
and updates all t
On Sat, 8 Jul 2017 21:05:57 +0200
Ulrich Mueller wrote:
> > On Sat, 8 Jul 2017, Ciaran McCreesh wrote:
>
> > On Sat, 8 Jul 2017 16:39:29 +0200
> > Alexis Ballier wrote:
> >> Indeed, makes sense. Would it also make sense to have some more
> >> logical meaning in a future EAPI ? I mean, i
The original GNOME2_ECLASS_ICONS patch has moved the condition from
gnome2_icon_cache_update to postinst phases of functions using
the preinst/postinst logic but accidentally omitted postrm. Include it
there as well to restore the old behavior.
---
eclass/gnome2.eclass| 4 +++-
eclass/kde4-bas
> On Sat, 8 Jul 2017, Ciaran McCreesh wrote:
> On Sat, 8 Jul 2017 16:39:29 +0200
> Alexis Ballier wrote:
>> Indeed, makes sense. Would it also make sense to have some more
>> logical meaning in a future EAPI ? I mean, in every context I've ever
>> seen, applying a rule to the empty set is the
> On Sat, 08 Jul 2017, Michał Górny wrote:
> On sob, 2017-07-08 at 12:26 +0200, Ulrich Mueller wrote:
>> Section "Processing algorithm":
>>
>> > 2. Check whether the REQUIRED_USE constraint matches restrictions
>> > set in #Restrictions on REQUIRED_USE format. If it does not, report
>> > a RE
On sob, 2017-07-08 at 16:12 +0200, Alexis Ballier wrote:
> On Sat, 08 Jul 2017 11:43:39 +0200
> Michał Górny wrote:
>
> > Hi, everyone.
> >
> > I think the affairs have settled enough and I've finished filling
> > in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
> > the algorithms,
On sob, 2017-07-08 at 12:26 +0200, Ulrich Mueller wrote:
> > > > > > On Sat, 08 Jul 2017, Michał Górny wrote:
> > The pre-GLEP for review is here:
> > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse
>
> On first glance:
>
> Section "Processing algorithm":
>
> > 2. Check whether the REQUIRED
On sob, 2017-07-08 at 18:58 +0100, Ciaran McCreesh wrote:
> On Sat, 8 Jul 2017 16:39:29 +0200
> Alexis Ballier wrote:
> > > As much as I hate the weird || ( use ? ( ) ) and empty block rules,
> > > it would be worse to have them apply in some situations but not
> > > others.
> >
> > Indeed, mak
On Sat, 8 Jul 2017 16:39:29 +0200
Alexis Ballier wrote:
> > As much as I hate the weird || ( use ? ( ) ) and empty block rules,
> > it would be worse to have them apply in some situations but not
> > others.
>
> Indeed, makes sense. Would it also make sense to have some more
> logical meaning i
On Sat, 8 Jul 2017 15:23:39 +0100
Ciaran McCreesh wrote:
> On Sat, 8 Jul 2017 16:14:09 +0200
> Alexis Ballier wrote:
> > On Sat, 8 Jul 2017 13:01:39 +0100
> > Ciaran McCreesh wrote:
> > > On Sat, 8 Jul 2017 13:49:56 +0200
> > > Alexis Ballier wrote:
> > > > On Sat, 8 Jul 2017 12:26:59 +0
On Sat, 8 Jul 2017 16:14:09 +0200
Alexis Ballier wrote:
> On Sat, 8 Jul 2017 13:01:39 +0100
> Ciaran McCreesh wrote:
> > On Sat, 8 Jul 2017 13:49:56 +0200
> > Alexis Ballier wrote:
> > > On Sat, 8 Jul 2017 12:26:59 +0200
> > > Ulrich Mueller wrote:
> > > > | * An any-of group (||) evaluat
On Sat, 8 Jul 2017 13:01:39 +0100
Ciaran McCreesh wrote:
> On Sat, 8 Jul 2017 13:49:56 +0200
> Alexis Ballier wrote:
> > On Sat, 8 Jul 2017 12:26:59 +0200
> > Ulrich Mueller wrote:
> > > | * An any-of group (||) evaluates to true if at least one of the
> > > | items in it evaluates to true.
>
On Sat, 08 Jul 2017 11:43:39 +0200
Michał Górny wrote:
> Hi, everyone.
>
> I think the affairs have settled enough and I've finished filling
> in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
> the algorithms, rationale and separated reference implementation.
>
> If there are no ma
On Sat, 8 Jul 2017 13:49:56 +0200
Alexis Ballier wrote:
> On Sat, 8 Jul 2017 12:26:59 +0200
> Ulrich Mueller wrote:
> > | * An any-of group (||) evaluates to true if at least one of the
> > | items in it evaluates to true.
> > | * An exactly-one-of group (^^) evaluates to true if exactly one of
>
On Sat, 8 Jul 2017 12:26:59 +0200
Ulrich Mueller wrote:
> | * An any-of group (||) evaluates to true if at least one of the
> | items in it evaluates to true.
> | * An exactly-one-of group (^^) evaluates to true if exactly one of
> | the items in it evaluates to true, and all the remaining items
> On Sat, 08 Jul 2017, Michał Górny wrote:
> The pre-GLEP for review is here:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse
On first glance:
Section "Processing algorithm":
| 2. Check whether the REQUIRED_USE constraint matches restrictions
| set in #Restrictions on REQUIRED_USE f
Hi, everyone.
I think the affairs have settled enough and I've finished filling
in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
the algorithms, rationale and separated reference implementation.
If there are no major concerns raised, I will soon start working
on writing an optimized
44 matches
Mail list logo
