[gentoo-dev] News Item: Future Support of hardened-sources Kernel

2015-10-18 Thread Anthony G. Basile

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: hardened/linux/amd64
Display-If-Profile: hardened/linux/amd64/no-multilib
Display-If-Profile: hardened/linux/amd64/no-multilib/selinux
Display-If-Profile: hardened/linux/amd64/selinux
Display-If-Profile: hardened/linux/amd64/x32
Display-If-Profile: hardened/linux/arm/armv6j
Display-If-Profile: hardened/linux/arm/armv7a
Display-If-Profile: hardened/linux/ia64
Display-If-Profile: hardened/linux/musl/amd64
Display-If-Profile: hardened/linux/musl/amd64/x32
Display-If-Profile: hardened/linux/musl/arm/armv7a
Display-If-Profile: hardened/linux/musl/mips
Display-If-Profile: hardened/linux/musl/mips/mipsel
Display-If-Profile: hardened/linux/musl/ppc
Display-If-Profile: hardened/linux/musl/x86
Display-If-Profile: hardened/linux/powerpc/ppc32
Display-If-Profile: hardened/linux/powerpc/ppc64/32bit-userland
Display-If-Profile: hardened/linux/powerpc/ppc64/64bit-userland
Display-If-Profile: hardened/linux/uclibc/amd64
Display-If-Profile: hardened/linux/uclibc/arm/armv7a
Display-If-Profile: hardened/linux/uclibc/mips
Display-If-Profile: hardened/linux/uclibc/mips/mipsel
Display-If-Profile: hardened/linux/uclibc/ppc
Display-If-Profile: hardened/linux/uclibc/x86
Display-If-Profile: hardened/linux/x86
Display-If-Profile: hardened/linux/x86/selinux

For many years, the Grsecurity team [1] has been supporting two versions of
their security patches against the Linux kernel, a stable and a testing
version, and Gentoo has made both of these available to our users 
through the

hardened-sources package.  However, on August 26 of this year, the team
announced they would no longer be making the stable version publicly
available, citing trademark infringement by a major embedded systems company
as the reason. [2]  The stable patches are now only available to sponsors of
Grsecurity and can no longer be distributed in Gentoo.  However, the 
team did
assure us that they would continue to release and support the testing 
version

as they have in the past.

What does this means for users of hardened-sources?  Gentoo will continue to
make the testing version available through our hardened-sources package 
but we

will have to drop support for the 3.x series.  In a few days, those ebuilds
will be removed from the tree and you will be required to upgrade to a 4.x
series kernel.  Since the hardened-sources package only installs the kernel
source tree, you can continue using a currently built 3.x series kernel but
bear in mind that we cannot support you, nor will upstream.  Also keep 
in mind

that the 4.x series will not be as reliable as the 3.x series was, so
reporting bugs promptly will be even more important.  Gentoo will 
continue to
work closely with upstream to stay on top of any problems, but be 
prepared for

the occasional "bad" kernel.  The more reporting we receive from our users,
the better we will be able to decide which hardened-sources kernels to mark
stable and which to drop.

Refs.
[1] https://grsecurity.net
[2] https://grsecurity.net/announce.php

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




[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-10-18 23:59 UTC

2015-10-18 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2015-10-18 23:59 UTC.

Removals:
dev-haskell/deepseq  20151017-11:04 slyfox bb7b94d
net-irc/xchat-otr20151016-06:58 polynomial-c   1d86444

Additions:
dev-cpp/antlr-cpp20151014-13:35 chewi  28eb80a
dev-java/super-csv   20151014-07:47 monsieurp  10bf020
dev-libs/libintl 20151012-23:14 vapier 2bb8a68
dev-ml/io-page   20151016-12:32 tomboy64   e7d338b
dev-ml/mirage-profile20151016-12:32 tomboy64   8138ac1
dev-ml/ocaml-cstruct 20151016-12:31 tomboy64   f379f26
dev-ml/ocaml-dns 20151016-12:06 tomboy64   c020237
dev-ml/ocaml-pcap20151016-12:29 aballier   80692cd
dev-ml/ocaml-uri 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 prometheanfire b0d3d2d
dev-python/capturer  20151015-06:43 jlec   eaefe8a
dev-python/castellan 20151015-06:51 prometheanfire 639ea09
dev-python/doc8  20151015-06:32 prometheanfire 8e1739e
dev-python/logutils  20151015-08:23 prometheanfire 161d4d9
dev-python/os-brick  20151015-07:55 prometheanfire a0a1c20
dev-python/oslo-reports  20151015-07:48 prometheanfire a84c140
dev-python/oslo-versionedobjects 20151015-07:27 prometheanfire f63023a
dev-python/pecan 20151015-08:29 prometheanfire 0fe82c1
dev-python/PyContracts   20151015-13:55 jlec   f05d383
dev-python/python-editor 20151015-05:22 prometheanfire 8bf053b
dev-python/restructuredtext-lint 20151015-06:31 prometheanfire 3fe22f1
dev-python/ryu   20151015-08:33 prometheanfire d9a4db9
dev-qt/qtbluetooth   20151017-17:51 kensington 199fea5
kde-base/kactivitymanagerd   20151017-18:16 kensington 443880e
media-fonts/nanum20151013-07:35 amadio 861189c
media-libs/libyami   20151015-10:43 aballier   d7ee607
media-video/harvid   20151015-06:59 aballier   1ea11df
net-libs/onion   20151015-07:51 aballier   62710b3
sci-chemistry/prody  20151012-08:02 jlec   6be6484
sys-apps/grepcidr20151017-14:00 idl0r  cf14d4f

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
dev-haskell/deepseq,removed,slyfox,20151017-11:04,bb7b94d
net-irc/xchat-otr,removed,polynomial-c,20151016-06:58,1d86444
Added Packages:
dev-ml/ocaml-dns,added,tomboy64,20151016-12:06,c020237
dev-python/automaton,added,prometheanfire,20151018-06:48,b0d3d2d
dev-ml/mirage-profile,added,tomboy64,20151016-12:32,8138ac1
kde-base/kactivitymanagerd,added,kensington,20151017-18:16,443880e
dev-qt/qtbluetooth,added,kensington,20151017-17:51,199fea5
dev-ml/ocaml-pcap,added,aballier,20151016-12:29,80692cd
dev-ml/io-page,added,tomboy64,20151016-12:32,e7d338b
dev-ml/ocaml-uri,added,tomboy64,20151016-12:25,7a3d130
sys-apps/grepcidr,added,idl0r,20151017-14:00,cf14d4f
dev-ml/stringext,added,tomboy64,20151016-12:01,b494a03
dev-ml/ocaml-cstruct,added,tomboy64,20151016-12:31,f379f26
dev-ml/qcheck,added,tomboy64,20151016-11:59,9b55086
dev-ml/ocplib-endian,added,tomboy64,20151016-12:20,182769d
dev-python/PyContracts,added,jlec,20151015-13:55,f05d383
media-libs/libyami,added,aballier,20151015-10:43,d7ee607
dev-python/ryu,added,prometheanfire,20151015-08:33,d9a4db9
dev-python/pecan,added,prometheanfire,20151015-08:29,0fe82c1
dev-python/logutils,added,prometheanfire,20151015-08:23,161d4d9
dev-python/capturer,added,jlec,20151015-06:43,eaefe8a
dev-python/os-brick,added,prometheanfire,20151015-07:55,a0a1c20
dev-python/oslo-reports,added,prometheanfire,20151015-07:48,a84c140
dev-python/oslo-versionedobjects,added,prometheanfire,20151015-07:27,f63023a
net-libs/onion,added,aballier,20151015-07:51,62710b3
media-video/harvid,added,aballier,20151015-06:59,1ea11df
dev-python/castellan,added,prometheanfire,20151015-06:51,639ea09
dev-python/doc8,added,prometheanfire,20151015-06:32,8e1739e
dev-python/restructuredtext-lint,added,prometheanfire,20151015-06:31,3fe22f1
dev-python/python-editor,added,prometheanfire,20151015-05:22,8bf053b
dev-cpp/antlr-cpp,added,chewi,20151014-13:35,28eb80a
dev-java/super-csv,added,monsieurp,20151014-07:47,10bf020
media-fonts/nanum,added,amadio,20151013-07:35,861189c
dev-libs/libintl,added,vapier,20151012-23:14,2bb8a68
sci-chemistry/prody,added,jlec,20151012-08:02,6be6484

Done.

Re: [gentoo-dev] xf86-input-evdev patch problem

2015-10-18 Thread Cor Legemaat
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/master/x11-drivers/x
> > f86-input-evdev/xf86-input-evdev-2.9.2-r1.ebuild
> >  it compile and install fine but with it installed neither the 
> > keyboard nor mouse is working. If I am correct it should install
> > 100% 
> > the same as from gentoo without the "debounce" use flag but it
> > gives 
> > the same symptoms.
> >  
> > What am I doing wrong?
> 
> So the problem here is the "inherit linux-info xorg-2" line.
> The xorg-2 eclass defines few default phase functions which you have
> overridden.
> 
> If you want to patch the source you should be doing something like
> this:
> src_prepare() {
>   use debounce && epatch ${FILESDIR}/your-patch
> 
>   xorg-2_src_prepare # this will call the xorg-2 eclass
>   #defined phase function to do the rest of the work
> }
> 
> Alternatively, if you just want to apply that patch, you are probably
> better off using epatch_user.
> Drop your patch in
> /etc/portage/patches/x11-drivers/xf86-input-evdev/your-name.patch
> and the eclasses will automatically apply the patch. you do not have
> to
> make your own ebuild just to apply the patch.
> 
> This has more info: https://wiki.gentoo.org/wiki//etc/portage/patches
> 
> -- Jason
> 
Needed to add the xorg-2 functions to al the custom functions in the
ebuild but that was the problem.

Tnx.

Regards:
Cor



Re: [gentoo-dev] [RFC] Allow SLOT documentation in metadata.xml

2015-10-18 Thread hasufell
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=551e00fc42ed21f6a6ff6129b5b85e64725d9665



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ciaran McCreesh
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 a direct copy of the epatch API, we took this as
an opportunity to tidy up the behaviour to make it do something easy to
understand and sensible, rather than being full of scary voodoo
heuristics which are rarely necessary (and when they are, fixing your
patches is easy) and which have weird effects that you don't know
about until it's too late.

Of course, this is part of the larger debate on "as much as possible in
the PM" versus "as much as possible in the tree". The main "in the PM"
argument is "less breakage and better testing"; the main "in the tree"
argument is that things going spectacularly wrong for users every now
and again is fine because it lets developers have new useless toys
slightly faster. (This is a totally unbiased and entirely comprehensive
summary of the debate.)

> or simply using 'epatch "${PATCHES[@]}"' when proper patches do not
> fit in what you call 'all the useful features': I haven't seen any,
> so that I know where to stand on using that feature or not. It is
> simply inferior and deemed unfixable until next EAPI.

It would be nice if eutils defined epatch to die for EAPI 6...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 used by default phase functions, for user patches, etc.

For user patches, I agree, but it can be very loosely defined and
left implementation dependent instead of mandated by PMS. For default
phases, see below.

> Rather than it being a direct copy of the epatch API, we took this as
> an opportunity to tidy up the behaviour to make it do something easy
> to understand and sensible, rather than being full of scary voodoo
> heuristics which are rarely necessary (and when they are, fixing your
> patches is easy) and which have weird effects that you don't know
> about until it's too late.

Makes sense, but it equally applies to 'patch', or worse: I've seen
many patches working with some 'patch' version and being rejected by
other versions. I've never seen anything like that caused by epatch
itself.

> Of course, this is part of the larger debate on "as much as possible
> in the PM" versus "as much as possible in the tree". The main "in the
> PM" argument is "less breakage and better testing"; the main "in the
> tree" argument is that things going spectacularly wrong for users
> every now and again is fine because it lets developers have new
> useless toys slightly faster. (This is a totally unbiased and
> entirely comprehensive summary of the debate.)

clearly unbiased :)

The main "in the PM" argument is "everything must be discussed until it
is perfect, and if it happens not to be later on then start again the
process and it'll be fixed next year"; the main "in the tree" argument
is about admitting that no code is perfect nor can do everything we
need from its inception but can be fixed and improved easily.


There are things that must be properly specified, for which PMS does a
very good job at, but others that are just implementation details which
IMHO have nothing to do with a spec: default phases could very well be
defined by an implicit 'inherit default-phase-functions' applying to
all ebuilds and be done with the specification, interoperability
problems, etc.
You'd tell me we then would have no guarantee that changing something
in that eclass wouldn't break an obscure ebuild, which is true, but
heh, isn't it the whole point of eclasses ? :)
(or rather, this eclass can have very strict pre-commit review &
testing rules)

[...]



[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sci-geosciences/grass/, sci-geosciences/grass/files/

2015-10-18 Thread Michał Górny
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:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2fa849db
> 
> sci-geosciences/grass: bump to -7.0.1
> 
> Inherit python-single-r1 eclass, three USE flags added and two removed
> to update new configure options; set slot operators on required deps,
> patches to fix build issues; install desktop file via make_desktop_entry,
> tidy EAPI style vars
> set new proxy-maintainer 'wraeth', add proxy-maintainers herd in metadata
> along with new use flags
> 
> Gentoo bug: #514514

(followed by a revbump)

This commit has introduced serious depgraph breakage:

https://qa-reports.gentoo.org/output/gentoo-ci/0279869/1.html#l1243

In other words, newly committed grass has ~ppc* keywords while xdrfile
does not have them. Please hurry to fix it, and use repoman properly
before pushing.

-- 
Best regards,
Michał Górny



pgpVtTGQDJame.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 eapply_user will always get called?  Isn't that
> equivalent to the halting problem?

yes, repoman can't do this

> 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 functions in eclasses as you want, and the
> check still works.

yes, and make the PM die in eapi6 if not called or called more than once



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 draft of EAPI 6 is ready. I shall post it as a series of
> > > 22 patches following this message in the gentoo-pms mailing list.
> > > 
> > > Please review. The goal is to have the draft ready for approval
> > > in the council's November meeting.
> > 
> > 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 even defining eapply in PMS ?  
> 
> How many decades, exactly? ;-)

from 1.5 to 1.6 I'd say :p

[...]
> > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > extracts -p0 patches by default here. Or when $S is actually a
> > subdir of a repository, this will make standard git format-patch
> > generated patches unusable.  
> 
> The poor man's autodetection implemented in epatch was... well, poor.
> It had its corner cases when it failed hard, it was complex and made
> error handling PITA (which patch invocation really failed?!).

There's a log for understanding which invocation failed.

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

> It's beneficial to keep patches with predictable directory structure.
> And after all, you can use 'eapply -pN' explicitly. And yes, I know
> you hate having to think instead of having some random hidden
> implicit, likely-to-fail logic do it for you.

Well, there's that, but I also wonder why every single ebuild uses
epatch and not 'patch -p1 < ...'  directly if epatch is so bad...

But my point was not there: I still fail to understand why we should
set in stone something not so well tested in comparison to epatch, that
doesn't seem to provide any gain besides a default phase that an eclass
can also provide, that has less features and that can't be
changed/fixed easily.

Alexis.



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Michał Górny
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 since my first message didn't make it to
> > > > -dev-announce.]
> > > > 
> > > > The first draft of EAPI 6 is ready. I shall post it as a series of
> > > > 22 patches following this message in the gentoo-pms mailing list.
> > > > 
> > > > Please review. The goal is to have the draft ready for approval
> > > > in the council's November meeting.  
> > > 
> > > 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 even defining eapply in PMS ?
> > 
> > How many decades, exactly? ;-)  
> 
> from 1.5 to 1.6 I'd say :p
> 
> [...]
> > > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > > extracts -p0 patches by default here. Or when $S is actually a
> > > subdir of a repository, this will make standard git format-patch
> > > generated patches unusable.
> > 
> > The poor man's autodetection implemented in epatch was... well, poor.
> > It had its corner cases when it failed hard, it was complex and made
> > error handling PITA (which patch invocation really failed?!).  
> 
> There's a log for understanding which invocation failed.

Yes, and it is a very friendly log which contains a few invocations,
each having some random failures and successes. Guessing is usually
faster.

> > 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 ebuilds, and they need
to apply patches sometimes.

> > It's beneficial to keep patches with predictable directory structure.
> > And after all, you can use 'eapply -pN' explicitly. And yes, I know
> > you hate having to think instead of having some random hidden
> > implicit, likely-to-fail logic do it for you.  
> 
> Well, there's that, but I also wonder why every single ebuild uses
> epatch and not 'patch -p1 < ...'  directly if epatch is so bad...

Because 'patch -p1 < ... || die' needs to be repeated multiple times
for each file. Simple as that.

> But my point was not there: I still fail to understand why we should
> set in stone something not so well tested in comparison to epatch, that
> doesn't seem to provide any gain besides a default phase that an eclass
> can also provide, that has less features and that can't be
> changed/fixed easily.

epatch is not well tested. Some of its branches are. Some of its code
was changed due to failures. We're reusing the parts of epatch that
make sense.

Otherwise, epatch would take more space in PMS than all stuff about
ebuilds added together, would require change in EAPI every 6 months,
plus a number of bugfix releases due to broken implementations of
over-complex concept.

-- 
Best regards,
Michał Górny



pgp31Q6G2g8mH.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Michał Górny
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 fail where epatch wouldn't
> while it should have ?

I already told you. When -p1 patch only adds files, epatch is going to
merrily apply it as -p0.

-- 
Best regards,
Michał Górny



pgploNCPfjHVR.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Michał Górny
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' different to an 'epatch' that has been
> > > widely tested for decades now ? Or even defining eapply in PMS ?
> > 
> > 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 the idea behind base.eclass :)
> why not just improving it ?

Let me Ciaran the answer for you: because we want a stable API. We
don't want random eclass that random developer will randomly change
every second month, accidentally breaking a number of ebuilds.

> or give proper scoping to inherit wrt EXPORT_FUNCTIONS, ala python:
> 'from base inherit src_prepare'

bugs.gentoo.org -> PMS/EAPI, and block 'Future EAPI'.

> > > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > > extracts -p0 patches by default here. Or when $S is actually a
> > > subdir of a repository, this will make standard git format-patch
> > > generated patches unusable.
> > 
> > Limiting the level to -p1 (and not doing autodetection) was a design
> > decision. eapply is really meant for simple cases like default
> > src_prepare applying patches listed in the PATCHES variable.
> > For anything that is more complicated there will still be epatch.  
> 
> 
> yes, I understand that, but this one was more intended for the
> rationale and for eapply_user:
> - why should I ever call eapply instead of epatch ?

Because it's built-in, simpler, faster and more failure-proof.

> - why should I ever want eapi6 src_prepare instead of
>   base_src_prepare ?

base.eclass is deprecated. You are going to get in trouble for using
it.

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

> As for eapply_user: Since it seems perfectly fine to have eapply_user a
> noop, and most parts are implementation defined, why mandating
> eapply_user to use such a limited eapply instead of leaving it
> implementation defined ?

Principle of least surprise. Reusability of patches.

-- 
Best regards,
Michał Górny



pgpeKpOn9ShP_.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 ebuilds, and they
> need to apply patches sometimes.

Yes, that's why I find '-p1 relative to $S' inconsistent. Nothing wrong
with -p1, but $S is from ebuild. If you avoid '$S', then you must also
drop -p1, simple as that :)

> > > It's beneficial to keep patches with predictable directory
> > > structure. And after all, you can use 'eapply -pN' explicitly.
> > > And yes, I know you hate having to think instead of having some
> > > random hidden implicit, likely-to-fail logic do it for you.
> > 
> > Well, there's that, but I also wonder why every single ebuild uses
> > epatch and not 'patch -p1 < ...'  directly if epatch is so bad...  
> 
> Because 'patch -p1 < ... || die' needs to be repeated multiple times
> for each file. Simple as that.

Honestly, I have serious doubts that's the only reason :=)

> > But my point was not there: I still fail to understand why we should
> > set in stone something not so well tested in comparison to epatch,
> > that doesn't seem to provide any gain besides a default phase that
> > an eclass can also provide, that has less features and that can't be
> > changed/fixed easily.  
> 
> epatch is not well tested. Some of its branches are. Some of its code
> was changed due to failures. We're reusing the parts of epatch that
> make sense.
> 
> Otherwise, epatch would take more space in PMS than all stuff about
> ebuilds added together, would require change in EAPI every 6 months,
> plus a number of bugfix releases due to broken implementations of
> over-complex concept.


I don't claim that epatch should go to PMS nor that eapply is bad: I
actually agree that for PMS something like eapply is way much better
than epatch.
What I do claim, however, is that PMS is not the place to throw random
widely used functions that can very well be defined in eclasses and
improved without going through all the PMS paperwork (which paperwork
is good for its purpose, but like for multilib, should be avoided when
possible).

Alexis.



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ulrich Mueller
> 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 functions in eclasses as you want,
> and the check still works.

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} phase.

Ulrich


pgpeT8MxPrshT.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Michał Górny
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
> > > rather desirable.
> > 
> > Consistency is desirable. There is world outside ebuilds, and they
> > need to apply patches sometimes.  
> 
> Yes, that's why I find '-p1 relative to $S' inconsistent. Nothing wrong
> with -p1, but $S is from ebuild. If you avoid '$S', then you must also
> drop -p1, simple as that :)

Relative to cwd.

-- 
Best regards,
Michał Górny



pgp1SNf_etuI4.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 even defining eapply in PMS ?  
> 
> 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 the idea behind base.eclass :)
why not just improving it ?

or give proper scoping to inherit wrt EXPORT_FUNCTIONS, ala python:
'from base inherit src_prepare'

> > I can understand "eapply is a function that applies patches" isn't
> > nice for a spec., but we've already seen in the past gnu patch
> > changing behavior wrt what is an acceptable patch between versions,
> > bsd 'patch' command behaves slightly differently than gnu patch
> > (read: is unusable with epatch), etc.
> > One can argue that gnu patch changing behavior is part of life, but
> > what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd
> > patch, 'gpatch' is gnu patch; we use profile.bashrc to alias patch
> > to gpatch for ebuilds, but I don't think profile.bashrc should mess
> > up with what is mandated by PMS.  
> 
> The spec for eapply mentions that it will accept GNU patch options,
> but maybe we should be more explicit and say that eapply must call
> GNU patch.

ok; or just make it explicit that eapply must run with ebuild env (since
gnu patch is already required in ebuild env)

> > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > extracts -p0 patches by default here. Or when $S is actually a
> > subdir of a repository, this will make standard git format-patch
> > generated patches unusable.  
> 
> Limiting the level to -p1 (and not doing autodetection) was a design
> decision. eapply is really meant for simple cases like default
> src_prepare applying patches listed in the PATCHES variable.
> For anything that is more complicated there will still be epatch.


yes, I understand that, but this one was more intended for the
rationale and for eapply_user:
- why should I ever call eapply instead of epatch ?
- why should I ever want eapi6 src_prepare instead of
  base_src_prepare ?
- what do I, as en ebuild writer, gain from this?
- what does the PM gain from this ?

As for eapply_user: Since it seems perfectly fine to have eapply_user a
noop, and most parts are implementation defined, why mandating
eapply_user to use such a limited eapply instead of leaving it
implementation defined ?


Alexis.



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 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 even defining
> > > > eapply in PMS ?  
> > > 
> > > 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 the idea behind base.eclass :)
> > why not just improving it ?  
> 
> Let me Ciaran the answer for you: because we want a stable API. We
> don't want random eclass that random developer will randomly change
> every second month, accidentally breaking a number of ebuilds.

The concept of stable API when you rely on external tools, esp. tools
like patch full of heuristics, is flawed already.

[...]
> > yes, I understand that, but this one was more intended for the
> > rationale and for eapply_user:
> > - why should I ever call eapply instead of epatch ?  
> 
> Because it's built-in, simpler, faster and more failure-proof.

"built-in, simpler, faster": this has never been an argument but why
not :) (we wouldnt use bash if it were...)
"more failure-proof" has yet to be asserted in the field

> > - why should I ever want eapi6 src_prepare instead of
> >   base_src_prepare ?  
> 
> base.eclass is deprecated. You are going to get in trouble for using
> it.

From this I understand that it suffices that I step up as its
maintainer :p

> > - 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 fail where epatch wouldn't
while it should have ?

> > As for eapply_user: Since it seems perfectly fine to have
> > eapply_user a noop, and most parts are implementation defined, why
> > mandating eapply_user to use such a limited eapply instead of
> > leaving it implementation defined ?  
> 
> Principle of least surprise. Reusability of patches.

A noop is fine, but if PM does implement it, PM must abort if a -p2
patch appears in an implementation defined directory: Something sounds
wrong here.



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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.  Then you can have as many
> > levels of conditionals and nested functions in eclasses as you want,
> > and the check still works.  
> 
> 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} phase.

yes please



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Michał Górny
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.  Then you can have as many
> > levels of conditionals and nested functions in eclasses as you want,
> > and the check still works.  
> 
> 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} phase.

How about:

In EAPIs listed in table blah blah blah, \t{eapply\_user} must
be called exactly once in the \t{src\_prepare} phase.

Which emphasizes that eclass or default may do it instead of ebuild.

-- 
Best regards,
Michał Górny



pgpro6aCEkY_T.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ulrich Mueller
> 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} phase.

> How about:

> In EAPIs listed in table blah blah blah, \t{eapply\_user} must
> be called exactly once in the \t{src\_prepare} phase.

> Which emphasizes that eclass or default may do it instead of ebuild.

Yeah, that's better actually. We need not reference the table again
though, since we do it in the sentence before.

In EAPIs where it is supported, \t{eapply\_user} must be called
exactly once in the \t{src\_prepare} phase.

Ulrich


pgpsRb5DR7kBx.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 subdirectory, eapply
> will work fine while epatch may add the subdir at a random level of
> your source tree. Happened to me already.
> 

I think setting EPATCH_OPTS="-p1" will just give you eapply :)



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Rich Freeman
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.
>

See also:
http://cr.yp.to/qmail/guarantee.html

> 5. Don't parse.
>
> I have discovered that there are two types of command interfaces in
> the world of computing: good interfaces and user interfaces.
>
> The essence of user interfaces is parsing: converting an unstructured
> sequence of commands, in a format usually determined more by
> psychology than by solid engineering, into structured data.
>
> When another programmer wants to talk to a user interface, he has
> to quote: convert his structured data into an unstructured sequence
> of commands that the parser will, he hopes, convert back into the
> original structured data.
>
> This situation is a recipe for disaster. The parser often has bugs: it
> fails to handle some inputs according to the documented interface. The
> quoter often has bugs: it produces outputs that do not have the right
> meaning. Only on rare joyous occasions does it happen that the parser
> and the quoter both misinterpret the interface in the same way.

When you have programs talking to programs it makes far more sense to
just spell things out correctly vs having the receiving program try to
guess what the calling program meant.

-- 
Rich



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Rich Freeman
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 exceptionally bad)?

Nope.  It isn't perfect, and I'm fine with that.

> Maybe the ebuild
> author doesn't even provide a live ebuild and there's no example for
> doing the right thing wrt random build systems patches. How about other
> build systems? You simply cannot do this properly.

I think you can do it properly.  I don't think you can do it in a
manner that is guaranteed to never fail.  IMO there is a difference.

>
> I think we are encouraging bad practice with this feature by making it
> part of PMS, causing users to file bugs because their random patches
> don't work with someones ebuilds.

Such bugs can be closed.  The intent is to provide a useful feature to
users, not to support the resulting binaries.  This isn't magic - it
is a tool for those who know how to use it, much like the rest of
Gentoo.  Forking ebuilds is far more hassle, even if it is more
powerful.

> If people need to hack on ebuilds, there are already numerous ways to do
> that, including doing it properly. Why add another one that is still not
> consistently thought through?

I'm not sure what makes this "not consistently thought through."  The
fact is that every objection you're raising was raised the first time
this came up.  I at least was well aware of all of them when I voted
to add this to EAPI6.  The issue seemingly isn't that it wasn't
thought through, but rather that those who did think through it didn't
agree with you on the decision.  That's ok - we'll never agree on
everything.

Believe it or not it is possible for two intelligent people to
thoughtfully consider the same data and come to different decisions.
This isn't deductive logic, and it isn't science until something has
been tried.

-- 
Rich



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 to the wrong directory.
> > 
> > Why not, but when exactly would eapply fail where epatch wouldn't
> > while it should have ?  
> 
> I already told you. When -p1 patch only adds files, epatch is going to
> merrily apply it as -p0.

that's one documented usage of EPATCH_OPTS or epatch args I think



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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.  Then you can have as many
> > levels of conditionals and nested functions in eclasses as you want,
> > and the check still works.  
> 
> 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} phase.


what mgorny wrote in the other thread makes me think:
please add that cwd must be $S when calling eapply_user, or something
fixed, otherwise behavior will be inconsistent across ebuilds



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Rich Freeman
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, all ebuilds must run
>>> \t{eapply\_user} in the \t{src\_prepare} phase.
>
>> How about:
>
>> In EAPIs listed in table blah blah blah, \t{eapply\_user} must
>> be called exactly once in the \t{src\_prepare} phase.
>
>> Which emphasizes that eclass or default may do it instead of ebuild.
>
> Yeah, that's better actually. We need not reference the table again
> though, since we do it in the sentence before.
>
> In EAPIs where it is supported, \t{eapply\_user} must be called
> exactly once in the \t{src\_prepare} phase.

++

-- 
Rich



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Rich Freeman
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 that with hooks too (which is not very clean tbh). But at
> that point, you probably want to actually fork the ebuild in an overlay
> if you need to mess with phase internals instead of relying on some
> magic that the ebuild writer might or might not have done properly.
>

This sounds like "if it isn't done perfectly it isn't worth doing."
If you're going to start by assuming that devs will always design
ebuilds incorrectly, then you might as well just fork all of Gentoo
into your overlay.  :)

People already find epatch_user useful, and I think moving it to PMS
will just make it more consistently useful.  Sure, there will be
mistakes, but right now epatch_user is optional, and in the future it
could be considered a QA issue.

-- 
Rich



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sci-geosciences/grass/, sci-geosciences/grass/files/

2015-10-18 Thread Andreas K. Huettel
-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 introduced serious depgraph breakage:
> https://qa-reports.gentoo.org/output/gentoo-ci/0279869/1.html#l1243
> 
> In other words, newly committed grass has ~ppc* keywords while xdrfile
> does not have them. Please hurry to fix it, and use repoman properly
> before pushing.

Heh. This is fallout since the DEPENDENCY.BADMASKED message has been 
deactivated is repoman. 

Seems like the ebuild was committed with no errors from repoman first (since 
all sci-geosciences/grass was pmasked) and then the mask limited to =6, 
exposing the breakage.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJWI4fPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5DXoP/3vjRwqgxnzpTZWuHkOI42gh
ztwGCPvEcfhvMpQfs9p3xQTOY+2dtV+dYOPjaZ8azUZiX4hdX2AH71gjfIPMN8lP
lESIGFQXHErxaFOAPlCA/ZRETCAXoDVRRmSLhcYAWU9Mx+aIC7h5cXmz61FEqkB9
TzE32+2p89b0Mgc9gMdxlxOCfkiwGctM/yoyafX6qDi+2KE3VqhTTEDRnZj1Rm0x
o3KNfEiIJcPasla+CFQetbzKnIJuk+kH5QFE+ezj9GrKjeTBNqjHP8ZLjFub+Azi
N3mupb78b4rJiulnyvXvOpsOk6Hhanh6es1/emc5//MYtpaebQwc/5OxhXe2a04V
gm6RjYfEqlbXOUxrc3P5fBdQe5KBY7dXJVtGaLlo/xmmg5vB77ZN+lC08yd0q6eC
rwu3o2OfrBL8u9XMp/5cePA1LBnLt5ZVkC7ayIkUak8QFFmCJEm+UooKBH+Yd6LF
h7OnRuG4aKzfnSkAjMoUYiEwo86Nwmy2MaSDK8AFcwiNKYyEOojSMIBniE7aGC44
NyvyGsoFRYWZVfa8La8EMQq+4adCxUJFgI+92FVqYGMQInROQrv4PYcEPamNoz37
CFfId4QLJCm04/CSJYBCqCuVtrDjglJ9HruD0bZv9dEu0GZAcixPs0ibbY26GwRA
Dpa3o14VsmCE8PGK2BxQ
=dn7N
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Andreas K. Huettel
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 of your source tree. 
Happened to me already.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/




Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread hasufell
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 problem?
>>>
>>> Running autorecrap.
>>>
>>
>> You can do that with hooks too (which is not very clean tbh). But at
>> that point, you probably want to actually fork the ebuild in an overlay
>> if you need to mess with phase internals instead of relying on some
>> magic that the ebuild writer might or might not have done properly.
>>
> 
> This sounds like "if it isn't done perfectly it isn't worth doing."
> If you're going to start by assuming that devs will always design
> ebuilds incorrectly, then you might as well just fork all of Gentoo
> into your overlay.  :)
> 
> People already find epatch_user useful, and I think moving it to PMS
> will just make it more consistently useful.  Sure, there will be
> mistakes, but right now epatch_user is optional, and in the future it
> could be considered a QA issue.
> 

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 exceptionally bad)? Maybe the ebuild
author doesn't even provide a live ebuild and there's no example for
doing the right thing wrt random build systems patches. How about other
build systems? You simply cannot do this properly.

I think we are encouraging bad practice with this feature by making it
part of PMS, causing users to file bugs because their random patches
don't work with someones ebuilds.

If people need to hack on ebuilds, there are already numerous ways to do
that, including doing it properly. Why add another one that is still not
consistently thought through?

EAPI shouldn't be patchwork.



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ciaran McCreesh
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 the idea behind base.eclass :)
> why not just improving it ?

No, the idea behind base.eclass was that somehow ebuilds were "object
oriented", and that whenever you had "object oriented" you had to have
a single base class for everything.

It was a silly idea and we should all be glad it has been forgotten.

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

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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).
> > > > 
> > > > It is. But the above cases were not whether it is possible, but
> > > > rather desirable.  
> > > 
> > > Consistency is desirable. There is world outside ebuilds, and they
> > > need to apply patches sometimes.
> > 
> > Yes, that's why I find '-p1 relative to $S' inconsistent. Nothing
> > wrong with -p1, but $S is from ebuild. If you avoid '$S', then you
> > must also drop -p1, simple as that :)  
> 
> Relative to cwd.
> 

which is the same, or even worse, since ebuilds can 'cd' whenever they
want



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread hasufell
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
that point, you probably want to actually fork the ebuild in an overlay
if you need to mess with phase internals instead of relying on some
magic that the ebuild writer might or might not have done properly.



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ciaran McCreesh
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
> > banned for all new ebuilds...
> > 
> > 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.
> > 
> 
> removing features is certainly not a gain for me
> 
> after all, the safest program is the one that does nothing

It's a good thing we've left in all the useful features, then.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 ?
> > > 
> > > 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 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.
> > >   
> > 
> > removing features is certainly not a gain for me
> > 
> > after all, the safest program is the one that does nothing  
> 
> It's a good thing we've left in all the useful features, then.
> 

A strict subset of it, indeed; what I was trying to understand is what
is the usefulness of eapply vs epatch or simply using 'epatch
"${PATCHES[@]}"' when proper patches do not fit in what you call 'all
the useful features': I haven't seen any, so that I know where to stand
on using that feature or not. It is simply inferior and deemed
unfixable until next EAPI.



Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Alexis Ballier
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 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.
> 

removing features is certainly not a gain for me

after all, the safest program is the one that does nothing



Re: [gentoo-dev] [RFC] Allow SLOT documentation in metadata.xml

2015-10-18 Thread Alexis Ballier
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-element for 'slot' seemed even more
> messy, so I tried to make this as simple as possible, so
> that maintainers don't get angry and give up when trying
> to document their slots. However, this is a little bit
> at the expense of correctness, because you cannot
> document different subslot naming schemes if they differ
> between slots of a single package (does such thing even exist
> in the tree?).
> 


btw, once this is committed, please consider adding or asking for a
repoman warning when subslot is defined but metadata.xml is not filled