Re: [gentoo-dev] [RFC] New eclass: mate

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/11/2016 08:14 PM, NP-Hardass wrote:
> On 04/11/2016 01:09 AM, NP-Hardass wrote:
>> Greetings all,
> 
>> As all potential new eclasses are supposed to be discussed here,
>> I thought I'd file a message and see if anyone had anything to 
>> contribute on the matter.
> 
>> I'm in the midst of a major version bump for the entirety of the 
>> MATE desktop environment, consisting of 40-50 packages.  There is
>> a huge amount of repetition in my ebuilds, and a lot of things
>> are formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits,
>> src_prepare, etc).  As such, I think that moving all of that to
>> an eclass would greatly simplify my life and my ebuilds, so I
>> thought I'd look into creating an eclass.
> 
>> Any opinions either way?   Thanks in advance.
> 
> 
> 
> 
> A little background, MATE is a fork of GNOME, so there are many
> things in common, however, the two aren't always in sync.  As such,
> there is often code reuse, but not always.  For example, GNOME has
> deprecated GNOME_DEBUG macros whereas MATE has not done so yet.
> 
> Attached are two eclasses mate-desktop.org.eclass and mate.eclass.
> 
> mate-desktop.org.eclass mimics the gnome.org eclass.  It defines a 
> couple of useful variables, as well as sets SRC_URI or
> EGIT_REPO_URI for a live ebuild.
> 
> mate.eclass is supposed to parallel gnome2.eclass.  A couple of
> notes: mate-desktop.org.eclass is necessary to override all of the
> defaults in gnome.org.eclass which are not applicable to MATE. The
> src_prepare function is borrowed from autotools-utils.  With EAPI
> 6, if any user is capable of modifying the build system via
> eapply_user, I'd like to be able to detect and regenerate the build
> system accordingly. Additionally, upstream does not supply
> Makefiles or configure scripts for live ebuilds, so I always have
> to run eautoreconf in those cases. Stubs: Well, you will probably
> notice that I have stubs to the gnome2 remaining functions.  This
> was done for several reasons.  1) in the event that the gnome2
> eclass goes in a different direction than MATE, it's easy to switch
> our own implementation, and 2) if I don't and I have reference to
> the gnome2 eclass, I have to explicitly inherit it in all ebuilds,
> which somewhat defeats the point the indirection gained by having
> the mate eclass.   I'd have to inherit gnome2 mate mate-desktop.org
> in every ebuild to ensure that everything is inherited properly.
> It's a little bit messy, but still doable.  But for the previous
> reason, built in independence from the gnome eclass if needed, it
> seems much easier to me to stub out gnome2 in the meantime .
> 
> 
Added new function to wrap around a MATE autotools function
mate-doc-common and add it to src_prepare

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDFeaAAoJEBzZQR2yrxj7LIgP+QGFJ+xdigWpxSDIIqabwozT
qL6hwvAQVHe3gBjGvs3FPOo+FJgzteQE4pRhhkU+g+Zgs9z1f7NIQQZbMwfVrHg+
KYKdufL4Wd2rF/X1qAf5EOqToBxZxpEYH0rPlfirOE4WA0HC5Gke0fwppeu6L8S3
7+N68ZdPKYnJ55+FZAiQCuy9QX3gDHsKhSpd1P4q5+Fi6D+qGYFalOlhhtW6qiOR
Rv41/xEabUha4V9H7YG5j+rROL5mSFchIT6wzx5dDTwQKS2dTclcqEbuS/k45E44
aemZFfb6l8Ymg+o28sCidPlOYyVaF5j7VbIAHNwEN4DNlbbpOJKAE5wTc6zrAyv5
zRVmmlxMlJvwr26faQsKgEGcVTWenmyCDeguSwgDetv1oQrzHtkI9lJMoUdRW39S
5nNp3mA2isUVmQIZRidAnPIJwLWBo7pmRZ67leCuK1UXGvGQWFDKXzPcRShTZRYb
nnE5VamFBlZtfpAnuoLYhNf9i21GJ/SJMxEwWNutdhf343qogfOk+Q7cKuYATEwm
OP499WmH7WNNjMnQiiyj9fC3epXslHN9ibYNoq1tf1Q3s5wIvzJ0ivcD9HZxxERv
usYALHiK1YZrjGpy3Tm1+pt44jwCRt+hVBL+2fpez3ZOpPqRjW24KCnM1ZHILbx4
CSPRFgrQnPUMI4/r6Ew9
=JV4I
-END PGP SIGNATURE-
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome2
# and autotools-utils eclasses
# @BLURB: Provides phases for MATE based packages.
# @DESCRIPTION:
# Exports portage base functions used by ebuilds written for packages using the
# MATE framework. Occassionally acts as a wrapper to gnome2 due to the
# fact that MATE is a GNOME fork. For additional functions, see 
gnome2-utils.eclass.

# Check EAPI only
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Inherit happens below after declaration of GNOME2_LA_PUNT

# @ECLASS-VARIABLE: MATE_LA_PUNT
# @DESCRIPTION:
# Available values for MATE_LA_PUNT:
# - "no": will not clean any .la files
# - "yes": will run prune_libtool_files --modules
# - If it is not set, it will run prune_libtool_files
# MATE_LA_PUNT is a stub to GNOME2_LA_PUNT
GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}

inherit autotools gnome2 mate-desktop.org

case "${EAPI:-0}" in
5|6)
EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst pkg_postinst pkg_postrm
;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Autotools requires our MATE m4 files

Re: [gentoo-dev] [RFC] New eclass: mate

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/11/2016 01:09 AM, NP-Hardass wrote:
> Greetings all,
> 
> As all potential new eclasses are supposed to be discussed here, I 
> thought I'd file a message and see if anyone had anything to 
> contribute on the matter.
> 
> I'm in the midst of a major version bump for the entirety of the
> MATE desktop environment, consisting of 40-50 packages.  There is a
> huge amount of repetition in my ebuilds, and a lot of things are
> formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare,
> etc).  As such, I think that moving all of that to an eclass would
> greatly simplify my life and my ebuilds, so I thought I'd look into
> creating an eclass.
> 
> Any opinions either way?   Thanks in advance.
> 
> 
> 

A little background, MATE is a fork of GNOME, so there are many things
in common, however, the two aren't always in sync.  As such, there is
often code reuse, but not always.  For example, GNOME has deprecated
GNOME_DEBUG macros whereas MATE has not done so yet.

Attached are two eclasses mate-desktop.org.eclass and mate.eclass.

mate-desktop.org.eclass mimics the gnome.org eclass.  It defines a
couple of useful variables, as well as sets SRC_URI or EGIT_REPO_URI
for a live ebuild.

mate.eclass is supposed to parallel gnome2.eclass.  A couple of notes:
mate-desktop.org.eclass is necessary to override all of the defaults
in gnome.org.eclass which are not applicable to MATE. The src_prepare
function is borrowed from autotools-utils.  With EAPI 6, if any user
is capable of modifying the build system via eapply_user, I'd like to
be able to detect and regenerate the build system accordingly.
Additionally, upstream does not supply Makefiles or configure scripts
for live ebuilds, so I always have to run eautoreconf in those cases.
Stubs: Well, you will probably notice that I have stubs to the gnome2
remaining functions.  This was done for several reasons.  1) in the
event that the gnome2 eclass goes in a different direction than MATE,
it's easy to switch our own implementation, and 2) if I don't and I
have reference to the gnome2 eclass, I have to explicitly inherit it
in all ebuilds, which somewhat defeats the point the indirection
gained by having the mate eclass.   I'd have to inherit gnome2 mate
mate-desktop.org in every ebuild to ensure that everything is
inherited properly.  It's a little bit messy, but still doable.  But
for the previous reason, built in independence from the gnome eclass
if needed, it seems much easier to me to stub out gnome2 in the meantime
.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDD34AAoJEBzZQR2yrxj7ELkQAJK78s2tNt67XR7fgIYWZkTa
a52MsFdW5e14yqKZAmKZqIde3zRo65BAoa15BVscM2o9iH1CtJolbrq0i603OBej
RGt5RkgOqmUYg8lU/z1fyX7PLzm3ukTBSNQ0Y5m5jofo2sbg4WMFiaaQkmvChnQd
TA5dI+nMzz8gfQJvXoorj+JZziOikH4i8lsge2QKP7IUDe16fjUO8VM8J+5v4uk+
XXeIPFq3PXoHeGW9jLo9jibapntDlPOStoalY5dRIkIZSpe124TfVhCSOMeuWtRB
VzvvaW+D2MFL9NU2WcsQtU8H71CY/bZl3qPiA9n6OcFowIyVXBP9W7lhpcBmWbYx
HIsI8UEXriuMJPhiZ/mzkEKaXohElcvbolvQigejGCxzJVQ1fxpoHINXaN/KCEQ8
fxsKeLCM/toPuFcqjru1znZb05cLm1UAcN15YK3ldrcJNGY9tPxHj09dt74eIWor
49HZeFSftef637vFA+3NEN9aVVRyd9O9Fc+wK8FI7ki3O2br4SoOw122NUfjFWoB
4xguWOJjspcbxobzK7nzrKhTYLDhh+oymTj4TLmmzvTo3zgBgYhbVJNP5HoycfPB
nZBzYZIht0bl/BbdGvdOyDVacLG+X7QlWKcx/bUmcrv3rih59D8XrtzlVhOavvhW
RZ4Wo+feNwXrLN9aOfcL
=GGgO
-END PGP SIGNATURE-
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome2
# and autotools-utils eclasses
# @BLURB: Provides phases for MATE based packages.
# @DESCRIPTION:
# Exports portage base functions used by ebuilds written for packages using the
# MATE framework. Occassionally acts as a wrapper to gnome2 due to the
# fact that MATE is a GNOME fork. For additional functions, see 
gnome2-utils.eclass.

# Check EAPI only
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Inherit happens below after declaration of GNOME2_LA_PUNT

# @ECLASS-VARIABLE: MATE_LA_PUNT
# @DESCRIPTION:
# Available values for MATE_LA_PUNT:
# - "no": will not clean any .la files
# - "yes": will run prune_libtool_files --modules
# - If it is not set, it will run prune_libtool_files
# MATE_LA_PUNT is a stub to GNOME2_LA_PUNT
GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}

inherit autotools gnome2 mate-desktop.org

case "${EAPI:-0}" in
5|6)
EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst pkg_postinst pkg_postrm
;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Autotools requires our MATE m4 files
DEPEND=">=mate-base/mate-common-${MATE_BRANCH}"


# Wrapper function for handling phases when python is available as bindings only
# @FUNCTION: python_cond_func_wrap
# @DESCRIPTION: Wraps a function for conditional python use, to 

[gentoo-dev] [warning] the bug queue has 82 bugs

[Alex Alexander]

Our bug queue has 82 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-dev] Re: usr merge

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/04/16 01:18 PM, »Q« wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400 waltd...@waltdnes.org wrote:
> 
>> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
>> 
>>> It was simply a recognition that we were already in a state
>>> where booting a system without /usr mounted early can cause
>>> problems.
>> 
>> For certain edge cases... yes.  But they were already using 
>> initramfs or merging /usr into /.  I'm talking about the 95%
>> who don't really need it.
> 
> Booting without /usr mounted early is something Gentoo already
> doesn't support and can't support, right?
> 
> 

It still works for a number of basic cases, but per the Council's
decision quite a while ago, dev's have zero obligation to ensure it
continues to work -- in effect this means it can break at any time.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcLstQACgkQAJxUfCtlWe2I+AEAyVX2Zh8YDbbCfTtCJ8C3Y1Gk
8OX3on1uKDCFeybThAgA/3g/uI2WyPhdayARsNNGQuX8tD+ejv/mpZjY2UUJPSpv
=3e1w
-END PGP SIGNATURE-

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Monday, April 11, 2016 01:10:15 AM Raymond Jennings wrote:
> Please don't do this.  I want my system left alone.

Please don't top-post, I want to have a logical flow of the text.


> On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld  wrote:
> > On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > > On Sun, 10 Apr 2016 02:09:35 +0200
> > > 
> > > "J. Roeleveld"  wrote:
> > > > I actually write my own initramfs because neither dracut not
> > > > genkernel end up with a convenient boot system.
> > > > 
> > > > I have 2 disks, both encrypted.
> > > > I prefer only to enter the decryption password once. Both Dracut and
> > > > Genkernel insist on asking for the password/key for every single disk.
> > > 
> > > Dracut on RHEL actually handles this out of the box. Might be worth
> > > finding out how.
> > 
> > Might have even been fixed in a more recent version of Dracut.
> > I just have passed the point where I am interested in it enough to try it.
> > The
> > initramfs I use gets embedded into the kernel and doesn't need any kernel
> > parameters to work.
> > 
> > It does what it needs to do with minimal work. The simplicity should also
> > make
> > it faster than the scripts generated by either Dracut or genkernel. (As
> > they
> > need to parse the kernel cmdline and try to figure out static details on
> > the
> > fly)
> > 
> > --
> > Joost

Please d

Re: [gentoo-dev] usr merge

[Raymond Jennings]

Please don't do this.  I want my system left alone.



On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld  wrote:

> On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > On Sun, 10 Apr 2016 02:09:35 +0200
> >
> > "J. Roeleveld"  wrote:
> > > I actually write my own initramfs because neither dracut not
> > > genkernel end up with a convenient boot system.
> > >
> > > I have 2 disks, both encrypted.
> > > I prefer only to enter the decryption password once. Both Dracut and
> > > Genkernel insist on asking for the password/key for every single disk.
> >
> > Dracut on RHEL actually handles this out of the box. Might be worth
> > finding out how.
>
> Might have even been fixed in a more recent version of Dracut.
> I just have passed the point where I am interested in it enough to try it.
> The
> initramfs I use gets embedded into the kernel and doesn't need any kernel
> parameters to work.
>
> It does what it needs to do with minimal work. The simplicity should also
> make
> it faster than the scripts generated by either Dracut or genkernel. (As
> they
> need to parse the kernel cmdline and try to figure out static details on
> the
> fly)
>
> --
> Joost

Re: [gentoo-dev] [RFC] New eclass: mate

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/10/2016 10:09 PM, NP-Hardass wrote:
> Greetings all,
> 
> As all potential new eclasses are supposed to be discussed here, I 
> thought I'd file a message and see if anyone had anything to 
> contribute on the matter.
> 
> I'm in the midst of a major version bump for the entirety of the
> MATE desktop environment, consisting of 40-50 packages.  There is a
> huge amount of repetition in my ebuilds, and a lot of things are
> formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare,
> etc).  As such, I think that moving all of that to an eclass would
> greatly simplify my life and my ebuilds, so I thought I'd look into
> creating an eclass.
> 
> Any opinions either way?   Thanks in advance.
> 
> 
> 
Sounds like a prime use case for an eclass. If I were in your position
I'd be sure to get reviews from more experienced eclass writers along
the way to make sure you're not setting yourself up for bad API design.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXC07lAAoJEAEkDpRQOeFwqA4P/0GRudtO39UawnAQRW+N3/Un
JyyFN5Oej9bIJpMYyE7tz77N1SdUjla6yW/2WaL/HtzTeeETjp/ThlOXvweYE367
mCz7OJ/q9Fo20TGfPaBI0xIvlcmv+BDdTpjJc1czRlC+1j+mLa9RDG+byMiwnQIa
QVK3sUYAvypQqGIOZSlM4nCRwVT1CSBnSDlaJqlUIUJNciY9iqXyKwzCX0xUJCpo
pQHH2S05Bhx8c0rpK0x/MkqfhTAaLBPQDd/7Szozuy/MTb3Zx3aIV4bE0Z5D5uYq
B5ReTw0D0/cZqi9dA5HeEqMwEJJm6DRvs/km9bX07LDsIm0otvMCho3LzUY76SyS
4wtbNrHVBdQmM1XF9RdJ8Nd6HA3oozBwgs7tNRj0mLNG0irpc4q3CdC0ZYjklYVZ
KzTS2f7j1nnBvMynVYehlhNLUzpKwnUNIo1SFLrc5W/3ZQb9RtuwUYerP6sSoL8E
och22zjtD8PesT5exTXf5M3DRB5xO6kDcdCdzASdEpdjcLrCt3aDZTejhFrIAiJq
0LpdiZMyeC/z8bLKVGpMuBcZkD+eI9YzzdGC4FDU8AnEV17lGZfptqbUcGYL82wC
9FdlXieeTUuFWwIq0uM1gm4Sr1RMZ0/+Y/dqQBAKM+gFbZ8V+th5c8nKbdDt+I4o
4WOoBEg3fMnwPxga7DGT
=ks2J
-END PGP SIGNATURE-

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> On Sun, 10 Apr 2016 02:09:35 +0200
> 
> "J. Roeleveld"  wrote:
> > I actually write my own initramfs because neither dracut not
> > genkernel end up with a convenient boot system.
> > 
> > I have 2 disks, both encrypted.
> > I prefer only to enter the decryption password once. Both Dracut and
> > Genkernel insist on asking for the password/key for every single disk.
> 
> Dracut on RHEL actually handles this out of the box. Might be worth
> finding out how.

Might have even been fixed in a more recent version of Dracut.
I just have passed the point where I am interested in it enough to try it. The 
initramfs I use gets embedded into the kernel and doesn't need any kernel 
parameters to work.

It does what it needs to do with minimal work. The simplicity should also make 
it faster than the scripts generated by either Dracut or genkernel. (As they 
need to parse the kernel cmdline and try to figure out static details on the 
fly)

--
Joost

signature.asc
Description: This is a digitally signed message part.