On Mon, 2015-10-12 at 15:03 +0800, Jason Zaman wrote:
> On Mon, Oct 12, 2015 at 06:56:27AM +0200, Cor Legemaat wrote:
> > Hi:
> >
> > I created a ebuild with a patch for xf86-input-evdev to try and
> > debounce my mouse button. The ebuild is at
> > https://github.com/cor-mt/portage-overlay/blob
Hi everyone, for your consideration:
Title: Future Support of hardened-sources Kernel
Content-Type: text/plain
Posted: 2015-10-21
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-kernel/hardened-sources
Display-If-Keyword: hardened
Display-If-Keyword: pax_kernel
Display-If-Profile: har
20151016-12:25 tomboy64 7a3d130
dev-ml/ocplib-endian 20151016-12:20 tomboy64 182769d
dev-ml/qcheck20151016-11:59 tomboy64 9b55086
dev-ml/stringext 20151016-12:01 tomboy64 b494a03
dev-python/automaton 20151018-06:48
On Sun, 18 Oct 2015 19:36:09 +0100
Ciaran McCreesh wrote:
> On Sun, 18 Oct 2015 20:19:12 +0200
> Alexis Ballier wrote:
> > what I was trying to understand is what is the usefulness of eapply
> > vs epatch
>
> The point of eapply is that it's inside the package manager, so it can
> safely be u
On 10/18/2015 08:21 PM, Alexis Ballier wrote:
>
>
> btw, once this is committed, please consider adding or asking for a
> repoman warning when subslot is defined but metadata.xml is not filled
>
Almost forgot: it has been committed yesterday:
https://gitweb.gentoo.org/data/dtd.git/commit/?id=55
On Sun, 18 Oct 2015 20:19:12 +0200
Alexis Ballier wrote:
> what I was trying to understand is what is the usefulness of eapply
> vs epatch
The point of eapply is that it's inside the package manager, so it can
safely be used by default phase functions, for user patches, etc.
Rather than it being
On Mon, 12 Oct 2015 19:19:32 +0200
Julian Ospald wrote:
> The following patch tries to address the lack of slot
> documentation, since getting the slots of a dependency
> right seems like a common problem.
>
> Things that I was particularly not sure about: the 'subslots'
> element. Having a sub-
On Sun, 18 Oct 2015 19:06:33 +0100
Ciaran McCreesh wrote:
> On Sun, 18 Oct 2015 20:00:11 +0200
> Alexis Ballier wrote:
> > On Sun, 18 Oct 2015 13:44:30 +0100
> > Ciaran McCreesh wrote:
> > [...]
> > > > - why should I ever want eapi6 src_prepare instead of
> > > > base_src_prepare ?
> >
On Sun, 18 Oct 2015 20:00:11 +0200
Alexis Ballier wrote:
> On Sun, 18 Oct 2015 13:44:30 +0100
> Ciaran McCreesh wrote:
> [...]
> > > - why should I ever want eapi6 src_prepare instead of
> > > base_src_prepare ?
> >
> > Well base.eclass is supposed to be being removed, and is allegedly
> > b
On Sun, 18 Oct 2015 13:44:30 +0100
Ciaran McCreesh wrote:
[...]
> > - why should I ever want eapi6 src_prepare instead of
> > base_src_prepare ?
>
> Well base.eclass is supposed to be being removed, and is allegedly
> banned for all new ebuilds...
>
> But the big gain for everyone is in repl
On Sun, Oct 18, 2015 at 8:44 AM, Ciaran McCreesh
wrote:
>
> But the big gain for everyone is in replacing a weird, overly clever
> and highly fragile collection of weirdness that's designed to mostly
> accept any dodgy input, with one that just gets you to give it a sane
> input to begin with.
>
On Sun, 18 Oct 2015 10:31:09 +0200
Alexis Ballier wrote:
> > The rationale is that we cannot apply patches in the default
> > src_prepare() unless there is a patch function in the package
> > manager itself. Obviously the default phase cannot call a function
> > from an eclass.
>
> well, that was
On Sun, Oct 18, 2015 at 8:05 AM, hasufell wrote:
>
> If you are messing with the build system in a patch, there is no
> guarantee that eautoreconf will be enough. It might or might not be true
> (see net-irc/hexchat for an example). Are we going to run eautoreconf
> unconditionally then (which is
On 10/18/2015 01:43 PM, Rich Freeman wrote:
> On Sun, Oct 18, 2015 at 7:37 AM, hasufell wrote:
>> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>>> On Sat, 17 Oct 2015 14:49:36 +0200
>>> hasufell wrote:
You can apply the patches post_unpack or post_src_prepare witht hooks.
What's the p
On Sun, 18 Oct 2015 13:54:05 +0200
"Andreas K. Huettel" wrote:
> Am Sonntag, 18. Oktober 2015, 11:23:56 schrieb Alexis Ballier:
>
> >
> > Why not, but when exactly would eapply fail where epatch wouldn't
> > while it should have ?
> >
>
> Different issue but- if your patch only adds a subdi
Am Sonntag, 18. Oktober 2015, 11:23:56 schrieb Alexis Ballier:
>
> Why not, but when exactly would eapply fail where epatch wouldn't
> while it should have ?
>
Different issue but- if your patch only adds a subdirectory, eapply will work
fine while epatch may add the subdir at a random level o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Sonntag, 18. Oktober 2015, 09:23:10 schrieb Michał Górny:
>
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2fa849db
> >
> > sci-geosciences/grass: bump to -7.0.1
> >
(...)
> (followed by a revbump)
> This commit has intro
On Sun, Oct 18, 2015 at 7:37 AM, hasufell wrote:
> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>> On Sat, 17 Oct 2015 14:49:36 +0200
>> hasufell wrote:
>>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>>> What's the problem?
>>
>> Running autorecrap.
>>
>
> You can do
On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
> On Sat, 17 Oct 2015 14:49:36 +0200
> hasufell wrote:
>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>> What's the problem?
>
> Running autorecrap.
>
You can do that with hooks too (which is not very clean tbh). But at
t
On Sun, Oct 18, 2015 at 6:17 AM, Ulrich Mueller wrote:
>> On Sun, 18 Oct 2015, Michał Górny wrote:
>
>> On Sun, 18 Oct 2015 11:54:40 +0200
>> Ulrich Mueller wrote:
>
>>> So the question is if we should add a sentence like the following to
>>> the spec:
>>>
>>> In EAPIs where it is supported,
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Rich Freeman wrote:
>
> > That would be another reason to have the PM do the check. All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.
On Sun, 18 Oct 2015 12:07:45 +0200
Michał Górny wrote:
> On Sun, 18 Oct 2015 11:23:56 +0200
> Alexis Ballier wrote:
>
> > > > - what do I, as en ebuild writer, gain from this?
> > >
> > > Reliable patching. Unlike epatch, eapply will not succeed when
> > > the patch unexpectedly applied
On Sun, 18 Oct 2015 12:09:10 +0200
Michał Górny wrote:
> On Sun, 18 Oct 2015 11:34:15 +0200
> Alexis Ballier wrote:
>
> > On Sun, 18 Oct 2015 11:01:27 +0200
> > Michał Górny wrote:
> > [...]
> > > > > It's trivial to change patch to -p1 (I think patchutils can do
> > > > > that).
> >
> On Sun, 18 Oct 2015, Michał Górny wrote:
> On Sun, 18 Oct 2015 11:54:40 +0200
> Ulrich Mueller wrote:
>> So the question is if we should add a sentence like the following to
>> the spec:
>>
>> In EAPIs where it is supported, all ebuilds must run
>> \t{eapply\_user} in the \t{src\_prepare}
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Rich Freeman wrote:
>
> > That would be another reason to have the PM do the check. All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.
On Sun, 18 Oct 2015 11:34:15 +0200
Alexis Ballier wrote:
> On Sun, 18 Oct 2015 11:01:27 +0200
> Michał Górny wrote:
> [...]
> > > > It's trivial to change patch to -p1 (I think patchutils can do
> > > > that).
> > >
> > > It is. But the above cases were not whether it is possible, but
> >
On Sun, 18 Oct 2015 11:23:56 +0200
Alexis Ballier wrote:
> > > - what do I, as en ebuild writer, gain from this?
> >
> > Reliable patching. Unlike epatch, eapply will not succeed when
> > the patch unexpectedly applied to the wrong directory.
>
> Why not, but when exactly would eapply fai
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Rich Freeman wrote:
>
> > That would be another reason to have the PM do the check. All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.
> On Sat, 17 Oct 2015, Rich Freeman wrote:
> That would be another reason to have the PM do the check. All it
> has to do is set an internal flag when it is called, and then check
> the flag before starting the next phase. Then you can have as many
> levels of conditionals and nested functio
On Sun, 18 Oct 2015 11:01:27 +0200
Michał Górny wrote:
[...]
> > > It's trivial to change patch to -p1 (I think patchutils can do
> > > that).
> >
> > It is. But the above cases were not whether it is possible, but
> > rather desirable.
>
> Consistency is desirable. There is world outside
On Sun, 18 Oct 2015 10:48:47 +0200
Michał Górny wrote:
> On Sun, 18 Oct 2015 10:31:09 +0200
> Alexis Ballier wrote:
>
> > On Sat, 17 Oct 2015 22:47:28 +0200
> > Ulrich Mueller wrote:
> >
> > > > On Sat, 17 Oct 2015, Alexis Ballier wrote:
> > >
> > > > Sorry for coming very la
On Sun, 18 Oct 2015 10:47:01 +0200
Alexis Ballier wrote:
> On Sat, 17 Oct 2015 23:24:47 +0200
> Michał Górny wrote:
>
> > On Sat, 17 Oct 2015 22:08:38 +0200
> > Alexis Ballier wrote:
> >
> > > On Fri, 16 Oct 2015 20:42:20 +0200
> > > Ulrich Mueller wrote:
> > >
> > > > [Resending sinc
On Sun, 18 Oct 2015 10:31:09 +0200
Alexis Ballier wrote:
> On Sat, 17 Oct 2015 22:47:28 +0200
> Ulrich Mueller wrote:
>
> > > On Sat, 17 Oct 2015, Alexis Ballier wrote:
> >
> > > Sorry for coming very late on this, but what is the rationale behind
> > > setting in stone an 'eapply' d
On Sat, 17 Oct 2015 23:24:47 +0200
Michał Górny wrote:
> On Sat, 17 Oct 2015 22:08:38 +0200
> Alexis Ballier wrote:
>
> > On Fri, 16 Oct 2015 20:42:20 +0200
> > Ulrich Mueller wrote:
> >
> > > [Resending since my first message didn't make it to
> > > -dev-announce.]
> > >
> > > The first d
On Sat, 17 Oct 2015 18:16:33 -0400
Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 8:52 AM, Ulrich Mueller
> wrote:
> >
> > That eapply_user is called can be enforced by repoman, or by a QA
> > warning.
> >
>
> I hate to reply again on the same topic, but how would repoman even
> know whether e
On Sat, 17 Oct 2015 22:47:28 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Alexis Ballier wrote:
>
> > Sorry for coming very late on this, but what is the rationale behind
> > setting in stone an 'eapply' different to an 'epatch' that has been
> > widely tested for decades now ? Or
On Wed, 14 Oct 2015 15:12:00 + (UTC)
"Ian Delaney" wrote:
> commit: 2fa849db86f415ee6eca0a7fb965c88606ace3e6
> Author: Ian Delaney gentoo org>
> AuthorDate: Wed Oct 14 15:11:05 2015 +
> Commit: Ian Delaney gentoo org>
> CommitDate: Wed Oct 14 15:11:49 2015 +
> URL:
37 matches
Mail list logo
