Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

2012-09-08 Thread Arfrever Frehtes Taifersar Arahesis
2012-09-04 22:50:16 Michał Górny napisał(a):
> + local slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}

When BOOST_MAX_VERSION is non-empty, then it should be used in the following 
way:

  [[ "${BOOST_MAX_VERSION}" =~ ^[[:digit:]]+\.[[:digit:]]+$ ]] || die "Invalid 
BOOST_MAX_VERSION"
  atom="$(best_version 
"

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


[gentoo-dev] Perl: please don't delete packlists

2012-09-08 Thread Matthias Bethke
I just tried (and failed) to pack a script with App::FatPacker and
noticed Gentoo follows the bad example of most other distributions in
removing all .packlist files from Perl module installations.

These files are the only system-independent way of determining which
modules belong together as part of a CPAN distribution, e.g. to find
that Template::Parser belongs to the Template Toolkit proper while
Template::Timer is an external add-on. FatPacker needs them to determine
which modules to pack into the archive that makes a standalone script
not requiring any external non-core modules, and so do various other
bits such as Module::Installed.

Can we please keep these? It's not like a handful of files with a couple
hundred bytes per installed module at worst made any significant
difference in either disk use or search times, but removing them is a
Bad Idea that probably came from Debian and needlessly breaks stuff.

I solved my problem by 

a) removing the patches to ExtUtils::MakeMaker that delete packlist
creation from the perl and vendor targets in generated makefiles, and

b) modifying perl-module.eclass so it removes only empty *.bs files:

--- /usr/portage/eclass/perl-module.eclass.orig 2012-09-01 08:26:44.245212715 
-0600
+++ /usr/portage/eclass/perl-module.eclass  2012-09-01 10:22:10.308419665 
-0600
@@ -123,7 +123,7 @@
--installdirs=vendor \
--libdoc= \
--destdir="${D}" \
-   --create_packlist=0 \
+   --create_packlist=1 \
"${myconf_local[@]}"
einfo "perl Build.PL" "$@"
perl Build.PL "$@" <<< "${pm_echovar}" \
@@ -341,8 +341,7 @@
debug-print-function $FUNCNAME "$@"
perl_set_version
if [[ -d ${D}/${VENDOR_ARCH} ]] ; then
-   find "${D}/${VENDOR_ARCH}" -type f -a \( -name .packlist \
-   -o \( -name '*.bs' -a -empty \) \) -delete
+   find "${D}/${VENDOR_ARCH}" -type f -a \( -name '*.bs' -a -empty 
\) -delete
find "${D}" -depth -mindepth 1 -type d -empty -delete
fi
 }

The perl_delete_packlist() function should probably not be called that any more
as it only deals with DynaLoader files now but that would require changing a
few ebuilds as well:

dev-libs/libprelude
www-apache/mod_perl
net-analyzer/rrdtool

I think Gentoo of all distributions should aim to  provide software as
"original" as possible. If there are any reasons that I have ignored so
far why people would want the current behavior, how about I make this
patch conditional on a new use flag?

cheers,
Matthias


signature.asc
Description: Digital signature


Re: [gentoo-dev] Unified DEPENDENCIES concept

2012-09-08 Thread Matt Turner
On Fri, Sep 7, 2012 at 4:45 AM, Ciaran McCreesh
 wrote:
> Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner,
> and since the Exherbo documentation doesn't seem to suffice to explain
> the idea here, here's some more details on the DEPENDENCIES proposal.

I like this. It seems well planned and thought out and very flexible.
If I understand correctly paludis already supports this, so a working
implementation is already available which is clearly beneficial for a
proposal.

Thanks a lot, Ciaran, for writing this up.

Matt



[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)

2012-09-08 Thread Duncan
Jorge Manuel B. S. Vicetto posted on Sat, 08 Sep 2012 18:05:07 + as
excerpted:

> Starting next week, new stages will have make.conf and make.profile
> moved from /etc to /etc/portage. This is a change in the installation
> defaults, that will only affect new installs so it doesn't affect
> current systems.
> 
> Current users don't need to do anything. But if you want to follow the
> preferred location, you may want to take the chance to move the files in
> your system(s) to the new location.

While the following reads somewhat smoother to me, maybe it's /just/ me, 
so another opinion would be appreciated.  The current wording is already 
clear, so just going with it is fine with me.


Starting next week, new stages will locate make.conf and make.profile in
/etc/portage instead of /etc.  This change to the installation defaults 
only affects new systems and both locations will continue to be 
supported. Whether you wish to move the files to their new /etc/portage 
location is therefore entirely up to you.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




Re: [gentoo-dev] python-distutils-ng.eclass: allow useflag dependencies for python

2012-09-08 Thread Michał Górny
On Sat, 08 Sep 2012 15:04:53 +0200
hasufell  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> > Where are your use cases?
> 
> qgrep PYTHON_USE_WITH

That gives more cases than your solution can handle...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] making USE=upnp a global flag

2012-09-08 Thread Michał Górny
On Sat, 8 Sep 2012 10:37:49 -0700
Mike Frysinger  wrote:

> i'm surprised this hasn't happened already.  currently at 18 users
> (and i'm adding another), so time to make global.  i'll use the
> description:
> upnp: Enable support for the Universal Plug and Play (UPnP) network
> protocol

Not sure about that description. It's whole stack of protocols which
usually benefit from more refined description.

On the other hand, the local descriptions in the tree show that some
people simply don't care and you are guessing what it does anyway...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)

2012-09-08 Thread Jorge Manuel B. S. Vicetto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here is the second draft for this news item.


On 06-09-2012 03:52, Jorge Manuel B. S. Vicetto wrote:
> Hi.
> 
> Following the July 24th thread about changing the default location
> of make.conf and make.profile in the new stages, I propose to
> commit 2 news items in 2 or 3 days. The first one (this one) is
> directed to all users and informs about the change and what to do.
> The second one (next email) will be directed to catalyst users. 
> This news item should be presented to as many users as possible. 
> Following Fabian's request in the previous thread, I'm trying to 
> restrict it to default/linux profiles only. I don't know if it's 
> possible to filter with default/linux/*, if there are other 
> alternatives or if we will have to list *all* relevant profiles
> (the latter case is not appealing).
> 
> Does anyone have any comments about this news item?


Title: make.conf and make.profile move
Author: Jorge Manuel B. S. Vicetto 
Content-Type: text/plain
Posted: 2012-09-08
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-apps/portage
Display-If-Keyword: alpha
Display-If-Keyword: amd64
Display-If-Keyword: arm
Display-If-Keyword: hppa
Display-If-Keyword: ia64
Display-If-Keyword: m68k
Display-If-Keyword: mips
Display-If-Keyword: ppc
Display-If-Keyword: ppc64
Display-If-Keyword: s390
Display-If-Keyword: sh
Display-If-Keyword: sparc
Display-If-Keyword: x86

Starting next week, new stages will have make.conf and make.profile
moved from /etc to /etc/portage. This is a change in the installation
defaults, that will only affect new installs so it doesn't affect
current systems.

Current users don't need to do anything. But if you want to follow the
preferred location, you may want to take the chance to move the files
in your system(s) to the new location.


- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQS4jTAAoJEC8ZTXQF1qEP9rkP/iaaHIZ43sBXim1Eb8lW4u/U
E4Us9pzrdCqTiPdHZWzGpdsaUgJdFEVcF/6S+TMByJV5WZM17vcy0wI/9Fm92UKH
/stZvOlECnCkCoASxSSzyjyfHOwio1G5A6oLWtfhTS8Mbbf28bny71iCgQN+MjDO
2asva5e04tEbe2yd/cQZfObf6npCmSb+tg94N8+dAu42uwtjZ1Zp1TcUZ0mP/PY9
2vs8joOOxvpnv5Azf8oz4p/g5dxWXVbGjZeJV7sBZKGbu2wpmeQsjYX3suE8r5gz
d3ZMRFkGwYEmVWVXp4qNS36sik6h8++PsWPS+RJy/6W7IfWh21DHXVYrmEvPAxOU
gSqJXPKwHu9a5DsVNf2fbgnDhOirx7gSgQBl2SwPZdpQ6Ts60h/Epn6oeDs8AXF0
B4MXQJUZV8AzXR7GQXnYDAIO+5FMyAPXJdxQ9MpoCP/ENrd+RBETiLDc6C7zfino
DDxB2tUtA5pFx4scpJaOE2ZAD3vVSBG7cravSTHgD3xEnyf9elblAIzaE3ADYzgL
5UkR4kEcnzGuSOYUR0uZqrp7Xyz+Pb661bFbindzCpmqEaoOUQfkdBum+SD7eG8y
h7XDzVBK0aNqsZ3STTfRn7OtJ5en7tUQJbznm69+DXz24WVk/r2zNr7NyWoNu/+J
0RKE6fzAHjTC6laxHJf5
=o5GT
-END PGP SIGNATURE-



[gentoo-dev] making USE=upnp a global flag

2012-09-08 Thread Mike Frysinger
i'm surprised this hasn't happened already.  currently at 18 users
(and i'm adding another), so time to make global.  i'll use the
description:
upnp: Enable support for the Universal Plug and Play (UPnP) network protocol

app-misc/tracker: Add support for video extraction via media-libs/gupnp-dlna.
gnome-extra/nautilus-sendto: Enables support for sending files over
upnp using net-libs/gupnp-av
kde-base/kdelibs: Enable UPnP support
media-plugins/grilo-plugins: Build support for UPnP devices using
net-libs/gupnp and net-libs/gupnp-av
media-sound/rhythmbox: Build a plugin for local network music sharing
which uses UPnP protocols using media-video/coherence,
dev-python/louie, and dev-python/twisted
media-video/totem: Enable DLNA support through media-video/coherence
media-video/vlc: Enables support for Intel UPnP stack.
net-libs/farsight2: Enable UPnP IGD support
net-libs/farstream: Enable UPnP IGD support
net-libs/libnice: Enable UPnP IGD support
net-misc/tor: Enable Universal Plug and Play
net-p2p/amule: Enables support for Intel UPnP stack.
net-p2p/bitcoin-qt: Enable Universal Plug and Play
net-p2p/bitcoind: Enable Universal Plug and Play
net-p2p/eiskaltdcpp: Forward ports using UPnP
net-p2p/ktorrent: Forward ports using UPnP
net-p2p/leechcraft-eiskaltdcpp: Forward ports using UPnP
www-servers/pshs: Enable port forwarding using UPnP via net-libs/miniupnpc
-mike



Re: [gentoo-dev] python-distutils-ng.eclass: allow useflag dependencies for python

2012-09-08 Thread hasufell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> Where are your use cases?

qgrep PYTHON_USE_WITH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQS0J1AAoJEFpvPKfnPDWzktAH/jY5/hfkIv6Gn+mRBg3ROtKh
EQ0vAJV3ZXSsIlO7UOxJf79wj1TqiApAhXvUxs5orJKOuCqc3Pfq41KNV/KfyRiS
zno/4sSVvgU6udSGx3BScbDIQi6T7bQKquP3FalDw30v2/xDqYdTPFCx+qfRG0Eu
erquQOiMs2OzBBzQn95xnjGaWN7Z9QBmkdIS3pC4hB2hIGOQmBEskRCQVtA9mfog
wM5war7DpTUsyrcJb67LZy0AeACN42xHJ7KFMkqVYp1WkT7Y04LmWmCjUJfSK7Yt
osZ2r/SUpCHQ1cJ5LM5DunboV7j2DZGzyNvCM2N3phnfYbQWAxhWoI4Idc4YzqE=
=KICW
-END PGP SIGNATURE-



Re: [gentoo-dev] Unified DEPENDENCIES concept

2012-09-08 Thread Michael Orlitzky
On 09/08/2012 02:43 AM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 18:55:10 -0400 Michael Orlitzky
>  wrote:
>> I think that dependencies are ultimately not hierarchical
> 
> Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so
> any new syntax would have to be able to deal with that.
> 

The deps in both cases are just a collection of atom/type pairs, so
anything possible in one must be possible in the other. I think this
means, if USE=bar, then we need either a or (b and c)? It could be
written,

|| (
  a: bar? ( build run )
  b,c: bar? ( build run )
)

Or if we wanted to make it even easier, allow the USE conditional at
the top level like we do now:

bar? ( || (
  a: ( build run )
  b,c: ( build run )
))

I'm just wondering if it wouldn't be nicer to think in terms of
package atoms instead of the dependency types. Right now, we've got
buckets named DEPEND, RDEPEND, etc. and we put the package atoms in
those buckets. The above syntax would make the package atoms the
buckets, and we would be putting the dependency types into the buckets
instead.



Re: [gentoo-dev] doheader function for EAPI 5?

2012-09-08 Thread Sergey Popov
31.08.2012 12:35, "Paweł Hajdan, Jr." wrote:
> I'm somewhat interested. Here's the current code dev-lang/v8 uses to
> install headers:
>
> insinto /usr
> doins -r include || die
>
> Using e.g. "doheader include/*" is slightly prettier IMHO, but it's not
> a big deal.
I am also voting for such function.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Unified DEPENDENCIES concept

2012-09-08 Thread Michał Górny
On Fri, 07 Sep 2012 18:55:10 -0400
Michael Orlitzky  wrote:

> On 09/07/2012 07:45 AM, Ciaran McCreesh wrote:
> > Since DEPENDENCIES hasn't been written up in a Gentoo-friendly
> > manner, and since the Exherbo documentation doesn't seem to suffice
> > to explain the idea here, here's some more details on the
> > DEPENDENCIES proposal.
> > 
> 
> It seems to me that the problem this solves is just one of ontology.
> It's analogous to trying to stick files named "foo", "bar", "baz",
> etc. into directories named "depend", "rdepend", "hdepend", and so on.
> 
> There are a few well-known ways to organize things in a hierarchy, and
> which one is most efficient depends on the categories and objects that
> you have. Given the way that most software is built (see:
> COMMON_DEPEND), I think DEPENDENCIES would work better than what we're
> doing now, but it also seems more complex.
> 
> I think that dependencies are ultimately not hierarchical, and this
> can force duplication in DEPENDENCIES as well. Has anyone considered
> tagging the package atoms with a list of dependency types? For
> example,
> 
>   * foo/bar: ( build run host )
>   * baz/one: baz? ( build )
>   * baz/two, baz/three: baz? ( build run )
>   ...
> 
> This would eliminate duplication of the objects (package atoms) in
> favor of duplication of the categories (dependency types). Since the
> package atoms are what we really care about, I think the tradeoff is
> beneficial. Maintainers get to express each dependency exactly once.

This is nowhere near friendly to a developer...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature