Re: [gentoo-dev] Understanding the LINGUAS variable and use-expand

[Mike Gilbert]

On Wed, Feb 8, 2012 at 12:04 PM, Mart Raudsepp  wrote:
> On K, 2012-02-08 at 11:32 -0500, Mike Gilbert wrote:
>> I am considering simplifying www-client/chromium from the current mess
>> based on the linguas USE flags to basically just this:
>>
>> if [[ ${LINGUAS} ]]; then
>>   for x in *.pak; do
>>     mylang=${x%.pak}
>>     mylang=%{x/-/_}
>>     has $mylang $LINGUAS || rm $x
>>   done
>> fi

> I think users could be surprised a bit about cases where you have
> variants or dialects, e.g currently as IUSE=linguas_fr_FR, when users
> only have LINGUAS=fr - in gettext they often don't have a fr_FR.po, just
> fr.po; if locale has LC_MESSAGE and LANG at fr_FR, it will look at "fr"
> if more specific fr_FR not found.
> I define things like LINGUAS="en en_US et et_EE" to be really sure, but
> I doubt many users do that (but that's just a guess).
> If it's exposed via IUSE, then they can at least have some visual cue of
> that.
> I guess it wouldn't be a concern if we had a tool to set the LINGUAS
> that handled this variant logic nicely, or just educating users in
> documentation, make.conf.example comments and so on.

Thanks for catching that Mart. I think I have addressed the dialect
issue by more directly emulating the autoconf macro. See below.

I would greatly appreciate any additional feedback anyone has on this subject.


New code, currently used (experimentally) in
google-chrome-19.0.1049.3_alpha123257.ebuild:

 if [[ "%UNSET%" != "${LINGUAS-%UNSET}" ]]; then
   local found desiredlang presentlang pak pakname

   pushd "${CHROME_HOME}locales" > /dev/null || die

   for pak in *.pak; do
 pakname="${pak%.pak}"
 pakname="${pakname/-/_}"
 presentlang="$(chromium_lang "${pakname}")"

 # Do not issue warning for en_US locale. This is the fallback
 # locale so it should always be installed.
 if [[ "${presentlang}" == "en_US" ]]; then
   continue
 fi

 found=
 for desiredlang in ${LINGUAS}; do
   if [[ "${desiredlang}" == "${presentlang}"* ]]; then
 found=1
 break
   fi
 done

 if [[ -z ${found} ]]; then
   rm "${pak}" || die
 fi
   done

   popd > /dev/null
 fi

Re: [gentoo-dev] preserve_old_lib and I'm even more lazy

[Mike Gilbert]

On Fri, Feb 24, 2012 at 7:31 PM, Richard Yao  wrote:
>> Am I the only paranoid person who moves them rather than unlinking
>> them?  Oh, if only btrfs were stable...
>
> Is this a reference to snapshots? You can use ZFS for those. The
> kernel modules are only available in the form of  ebuilds right
> now, but they your data should be safe unless you go out of your way
> to break things (e.g. putting the ZIL/SLOG on a tmpfs). Alternatively,
> there is XFS, which I believe also supports snapshots.
>

I've been using btrfs exclusively for about 6 months, and I don't
*think* I've lost anything... :)

Re: [gentoo-dev] rfc: virtual/modutils and module-init-tools

[Mike Gilbert]

On Sat, Feb 25, 2012 at 1:01 AM, William Hubbs  wrote:
> If not, once the dependencies are correct, I propose
> dropping virtual/modutils from the system set.

If we drop it from the system set, the kernel modules section of the
handbook should be updated.

Re: [gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Mike Gilbert]

On Sat, Feb 25, 2012 at 3:28 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> As such, I disagree with floppym that the handbook's kernel module
> section needs updating for this, too.  The handbook doesn't even deal
> with non-default dev-managers, nor does it mention module-init-tools, it
> just assumes it's there.  Udev, as the default dev-manager, will be
> pulling in kmod already, with its default module-init-tools compatibility
> meaning no change in documentation necessary.  Only if we're going to
> start giving users dev-manager alternatives in the handbook does it
> become an issue, and while that would be nice, I don't think it's
> necessary for this change.

Yes, I did not think that through. If kmod gets pulled in via udev in
the stage3 tarballs, the docs are fine as-is.

[gentoo-dev] Add gnu-alpha to thirdpartymirrors

[Mike Gilbert]

Any objections to adding "gnu-alpha" to thirdpartymirrors? See the
mirrors marked as (alpha) here:

http://www.gnu.org/prep/ftp.html

I'm prepping an ebuild for grub-2.00_beta0, which would use the new mirror.

[gentoo-dev] Re: [gentoo-python] New eclass for Python

[Mike Gilbert]

On Tue, Feb 28, 2012 at 4:13 PM, Krzysztof Pawlik  wrote:
> Hello,
>
> After some work during weekend on Python packages I've decided to start a
> rewrite of Python/distutils eclass for installing Python packages. My main 
> goal
> was simplicity and functionality similar to ruby-ng.eclass (thanks Ruby team 
> for
> your great work!). Python team members already contributed comments and
> suggestions and helped me to make the eclass better, thank you!
>
> Highlights:
>  - *SIMPLE*next
>  - uses PYTHON_TARGETS use-expand (no more python-updater, wh!)
>  - EAPI4 required, uses REQUIRED_USE
>  - <400 lines of code including documentation
>  - should work for >95% of packages (my educated guess)
>  - did I mention it's *SIMPLE*?
>  - easy to maintain & read so it's also easy to use
>
> Important thing: I'm not aiming at having 100% functionality of current
> python.eclass+distutils.eclass in the new one, I think that simplicity is more
> important that supporting every possible, obscure case that's out there.
>
> I'm attaching the eclass itself and two ebuilds using it, code is also 
> available
> in my overlay at 
> http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=summary
>
> If there are no objections then during the weekend (March 3, 4) I will add 
> this
> to portage (after finishing remaining TODO items, PyPy requires 4G of 
> RAM(!!)).
>
> --
> Krzysztof Pawlik    key id: 0xF6A80E46
> desktop-misc, java, vim, kernel, python, apache...
>

# Phase function: src_unpack
python-distutils-ng_src_unpack() {
[[ "${PYTHON_OPTIONAL}" = "yes" ]] && { use python || return; }

if type python_unpack &> /dev/null; then
# This should not run anything specific to any single Python
# implementation, keep it generic:
python_unpack_all
else
[[ -n ${A} ]] && unpack ${A}
fi
}

I think you meant to write "if type python_unpack_all".

More to the point, I don't actually understand why this function
exists. It doesn't actually do anything that default_src_unpack does
not do already. Exporting it will clobber any vcs eclasses if the
inherit order is wrong.

Re: [gentoo-dev] Re: [gentoo-python] New eclass for Python

[Mike Gilbert]

On Wed, Feb 29, 2012 at 12:39 PM, Krzysztof Pawlik  wrote:
> On 29/02/12 09:11, Dirkjan Ochtman wrote:
>> On Tue, Feb 28, 2012 at 22:13, Krzysztof Pawlik  wrote:
>>> If there are no objections then during the weekend (March 3, 4) I will add 
>>> this
>>> to portage (after finishing remaining TODO items, PyPy requires 4G of 
>>> RAM(!!)).
>>
>> Can we perhaps just name it python-r2 rather than python-distutils-ng?
>> Seems descriptive enough...
>
> Yes and no - it's named python-distutils because main focus was this
> combination, it can work for other cases too, it's just that it combines
> functionality from both old eclasses. Besides I like the name, but I can be
> convinced to name it python-r2.eclass.
>

The distutils-based packages are a good starting point. The name is a
good fit for that.

Looking forward, I think it might make sense to move some of the
functionality to a "core" python eclass that would just be for utility
functions -- similar to the python/distutils split we have now. This
would be used in ebuilds that are not primarily based around distutils
(setup.py).

Re: [gentoo-dev] The end of net-zope

[Mike Gilbert]

On Wed, Feb 29, 2012 at 3:51 AM, Dirkjan Ochtman  wrote:
> Tomorrow, March 1, is the deadline for removing almost all of the
> Zope/Plone packages from the portage tree (those who still want them
> can get them from Arfrever's Progress overlay).
>
> Since only one or two packages would remain in the category, do we
> want the category to stay around, or should it be removed from the
> tree? We could move the remaining packages to dev-python.
>
> Similarly, there is an empty herd. Do we have a procedure for
> end-of-lifeing herds?
>

Arfrever pinged me to add him to the net-zope herd as a proxy
maintainer for the remaining zope packages. Are there any objections
to this?

Re: [gentoo-dev] The end of net-zope

[Mike Gilbert]

On Thu, Mar 1, 2012 at 4:48 PM, Dirkjan Ochtman  wrote:
> On Thu, Mar 1, 2012 at 19:50, Mike Gilbert  wrote:
>> Arfrever pinged me to add him to the net-zope herd as a proxy
>> maintainer for the remaining zope packages. Are there any objections
>> to this?
>
> What remaining packages? Just zope-fixers, zope-interface and zc-buildout?
>
> I don't think that would be helpful.
>

Yeah, never mind.

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Mike Gilbert]

On Wed, Mar 7, 2012 at 3:41 PM, Ulrich Mueller  wrote:
> Again, the proposal comes in two variants:
> 2a) It is combined with a one time change of the file extension, like
>    .ebuild -> .eb.
> 2b) The usual EAPI assignment statement in the ebuild is still
>    required, at least for a transition period.
>

Just throwing my opinion in:

I like proposal 2 better than proposal 1. Placing a regex-based
constraint on a bash variable assignment doesn't feel right to me.

I slightly prefer 2a over 2b because it feels cleaner. I'm sure it
will break some tools, but I don't have a good feel for the scope of
that breakage.

[gentoo-dev] New eclass proposal: chromium.eclass

[Mike Gilbert]

I moved some of the functions currently implemented in the ebuilds for
www-client/chromium and www-client/google-chrome into a new eclass
"chromium.eclass".

This will allow the two packages to share some code, and it will reduce
the size of each chromium ebuild by around 4K (18K -> 14K).

I have attached a copy of the eclass and its manpage. You may also view
the eclass in my overlay:

https://bitbucket.org/floppym/floppym-overlay/src/default/eclass/chromium.eclass

Here is how it would be used in the www-client/chromium package:

https://bitbucket.org/floppym/floppym-overlay/changeset/fbf6de591da7

Please review.
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: chromium.eclass
# @MAINTAINER:
# Chromium Herd 
# @AUTHOR:
# Mike Gilbert 
# @BLURB: Shared functions for chromium and google-chrome

inherit eutils fdo-mime gnome2-utils linux-info

EXPORT_FUNCTIONS pkg_preinst pkg_postinst pkg_postrm

# @FUNCTION: chromium_check_kernel_config
# @USAGE:
# @DESCRIPTION:
# Ensures the system kernel is configured for full Chromium functionality.
chromium_check_kernel_config() {
has "${EAPI:-0}" 0 1 2 3 && die "EAPI=${EAPI} is not supported"

if [[ "${MERGE_TYPE}" == "source" || "${MERGE_TYPE}" == "binary" ]]; 
then
# Warn if the kernel does not support features needed for 
sandboxing.
# Bug #363987.
ERROR_PID_NS="PID_NS is required for sandbox to work"
ERROR_NET_NS="NET_NS is required for sandbox to work"
CONFIG_CHECK="~PID_NS ~NET_NS"
check_extra_config
fi
}

# @ECLASS-VARIABLE: CHROMIUM_LANGS
# @DEFAULT_UNSET
# @DESCRIPTION:
# List of language packs available for this package.

_chromium_set_linguas_IUSE() {
[[ ${EAPI:-0} == 0 ]] && die "EAPI=${EAPI} is not supported"

local lang
for lang in ${CHROMIUM_LANGS}; do
# Default to enabled since we bundle them anyway.
# USE-expansion will take care of disabling the langs the user 
has not
# selected via LINGUAS.
IUSE+=" +linguas_${lang}"
done
}

if [[ ${CHROMIUM_LANGS} ]]; then
_chromium_set_linguas_IUSE
fi

_chromium_crlang() {
local x
for x in "$@"; do
case $x in
es_LA) echo es-419 ;;
*) echo "${x/_/-}" ;;
esac
done
}

_chromium_syslang() {
local x
for x in "$@"; do
case $x in
es-419) echo es_LA ;;
*) echo "${x/-/_}" ;;
esac
done
}

_chromium_strip_pak() {
local x
for x in "$@"; do
echo "${x%.pak}"
done
}

# @FUNCTION: chromium_remove_language_paks
# @USAGE:
# @DESCRIPTION:
# Removes pak files from the current directory for languages that the user has
# not selected via the LINGUAS variable.
# Also performs QA checks to ensure CHROMIUM_LANGS has been set correctly.
chromium_remove_language_paks() {
local crlangs=$(_chromium_crlang ${CHROMIUM_LANGS})
local present_crlangs=$(_chromium_strip_pak *.pak)
local present_langs=$(_chromium_syslang ${present_crlangs})
local lang

# Look for missing pak files.
for lang in ${crlangs}; do
if ! has ${lang} ${present_crlangs}; then
eqawarn "LINGUAS warning: no .pak file for ${lang} 
(${lang}.pak not found)"
fi
done

# Look for extra pak files.
# Remove pak files that the user does not want.
for lang in ${present_langs}; do
if [[ ${lang} == en_US ]]; then
continue
fi
if ! has ${lang} ${CHROMIUM_LANGS}; then
eqawarn "LINGUAS warning: no ${lang} in LANGS"
continue
fi
if ! use linguas_${lang}; then
rm -v "$(_chromium_crlang ${lang}).pak" || die
fi
done
}

chromium_pkg_preinst() {
gnome2_icon_savelist
}

chromium_pkg_postinst() {
fdo-mime_desktop_database_update
gnome2_icon_cache_update

# For more info see bug #292201, bug #352263, bug #361859.
elog
elog "Depending on your desktop environment, you may need"
elog "to install additional packages to get icons on the Downloads 
page."
elog
elog "For KDE, the required package is kde-base/oxygen-icons."
elog
elog "For other desktop environments, try one of the following:&

Re: [gentoo-dev] RFD : .ebuild is only bash

[Mike Gilbert]

On Mon, Mar 12, 2012 at 5:49 PM, Alec Warner  wrote:
> On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric  wrote:
>> On 13 March 2012 10:14, Ulrich Mueller  wrote:
 On Mon, 12 Mar 2012, James Broadhead wrote:
>>>
 I'm sure that it's been considered already, but what are the arguments
 against embedding the EAPI on a per-package (default) or per-version
 basis in metadata.xml. It IS metadata after all.
>>>
>>> You can find a recent discussion in bug 402167, comment #4 and
>>> following. 
>>
>> I note that there is a link to the council minutes, with the reason
>> for voting "no" against GLEP55 being "it has issues that are
>> unsolved", but I don't see any reference to said issues.
>>
>> Is the actual IRC transcript available? Because I'd hate for this
>> decision to have been made on the assumption of issues which didn't
>> really exist.
>
> The previous council's decision does not prevent this same glep from
> going to the council again (decisions are not forever.)
> Some folks seem to think that taking glep55 back to the council is not
> allowed somehow (or is perhaps futile, but that is a different issue
> ;p) Having the full notes would be helpful in determining why it was
> turned down back then; I'm sure a copy of the notes exist.

http://www.gentoo.org/proj/en/council/
http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt

Re: Anybody willing to take care of sgml herd? (Was: Re: [gentoo-dev] media-optical, net-zope, sgml, text-markup herds are empty)

[Mike Gilbert]

On Sun, Mar 18, 2012 at 1:28 PM, Pacho Ramos  wrote:
> Is anyone willing to join the herd? If not, maybe somebody could take a
> few packages if they want to take care of only a set of them and not all
> the beast :-/

I took a look at the sgml bugs list, and most of them seem pretty
straightforward. I'll add myself and work on them as I have time.

Please don't let that stop you if you are thinking of picking up any
of the packages in pacho's list.

[gentoo-dev] Documentation for sys-boot/grub:2

[Mike Gilbert]

I believe the only thing keeping GRUB 2 masked is a lack of
"documentation". By this, I assume people are referring to the
handbook.

I have created a very minimal "quick start" guide that could be
adapted for the handbook. It relies on the grub2-mkconfig command
auto-detecting most things, which actually works pretty well.

http://wiki.gentoo.org/wiki/GRUB2_Quick_Start

scarabeus created a guide a while back that goes into slightly more detail:

http://dev.gentoo.org/~scarabeus/grub-2-guide.xml

The wiki also has a longer GRUB2 guide. This goes into some of the
more exotic setups. However, some of it is poorly written and I find
editing it quite tedious.

http://wiki.gentoo.org/wiki/GRUB2

So, my question to the community: what level of documentation do we
want to put in the handbook?

If the intent is just to get people up and running on Gentoo, I think
adapting the quick start guide from the wiki is enough. grub2.info has
a very detailed reference; I think we can refer people to that for
manual/advanced configuration.

Is there any other issue with grub:2 that would keep me from unmasking
(adding keywords) on x86 and amd64? I plan on waiting for the 2.00
release.

Re: [gentoo-dev] Fix spurious dep to eselect-python

[Mike Gilbert]

On Tue, Mar 20, 2012 at 12:41 PM, Arfrever Frehtes Taifersar Arahesis
 wrote:
> 2012-03-20 05:29:20 Luca Barbato napisał(a):
>> Hi, I tried to avoid depending on eselect-python if the useflag is disabled.
>>
>> Please test and review.
>
> The proper fix is to make python.eclass add dependency on 
> app-admin/eselect-python only when
> ${CATEGORY}/${PN} is dev-lang/python, dev-java/jython or dev-python/pypy. See 
> bug #341037.
>

Could you provide a patch against gentoo-x86 python.eclass for that? I
think you may have already done that, but things said in IRC get
forgotten.

Re: [gentoo-dev] Fix spurious dep to eselect-python

[Mike Gilbert]

On Tue, Mar 20, 2012 at 5:05 PM, Alexis Ballier  wrote:
> On Tue, 20 Mar 2012 17:57:29 -0300
> Alexis Ballier  wrote:
>
>> On Tue, 20 Mar 2012 20:35:17 +0100
>> Arfrever Frehtes Taifersar Arahesis  wrote:
>>
>> > 2012-03-20 17:53:56 Michał Górny napisał(a):
>> > > On Tue, 20 Mar 2012 17:41:39 +0100
>> > > Arfrever Frehtes Taifersar Arahesis  wrote:
>> > >
>> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
>> > > > > Hi, I tried to avoid depending on eselect-python if the
>> > > > > useflag is disabled.
>> > > > >
>> > > > > Please test and review.
>> > > >
>> > > > The proper fix is to make python.eclass add dependency on
>> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
>> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
>> > > > #341037.
>> > >
>> > > Couldn't we just push that dependency to the specific ebuilds?
>> >
>> > We want to control required version (>=20091230 in case of
>> > app-admin/eselect-python) in 1 place.
>> >
>>
>> this can be achieved by setting a variable that said ebuilds will
>> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN in
>> an eclass for this.
>>
>
> or also by adding a new python-implementation.eclass instead of
> polluting an eclass used by hundreds of packages for only 3 special
> ones...
>

A four-way if-then statement is not what I would call "complex". This
was already present in the eclass anyway, so there is no additional
"pollution".

I have already committed Arfrever's patch. If anyone wants to move the
dependency into the ebuilds, you are welcome to do so; patching the
eclass was just faster/easier.

Re: [gentoo-dev] Fix spurious dep to eselect-python

[Mike Gilbert]

On Tue, Mar 20, 2012 at 5:20 PM, Alexis Ballier  wrote:
> On Tue, 20 Mar 2012 17:09:55 -0400
> Mike Gilbert  wrote:
>
>> On Tue, Mar 20, 2012 at 5:05 PM, Alexis Ballier 
>> wrote:
>> > On Tue, 20 Mar 2012 17:57:29 -0300
>> > Alexis Ballier  wrote:
>> >
>> >> On Tue, 20 Mar 2012 20:35:17 +0100
>> >> Arfrever Frehtes Taifersar Arahesis  wrote:
>> >>
>> >> > 2012-03-20 17:53:56 Michał Górny napisał(a):
>> >> > > On Tue, 20 Mar 2012 17:41:39 +0100
>> >> > > Arfrever Frehtes Taifersar Arahesis 
>> >> > > wrote:
>> >> > >
>> >> > > > 2012-03-20 05:29:20 Luca Barbato napisał(a):
>> >> > > > > Hi, I tried to avoid depending on eselect-python if the
>> >> > > > > useflag is disabled.
>> >> > > > >
>> >> > > > > Please test and review.
>> >> > > >
>> >> > > > The proper fix is to make python.eclass add dependency on
>> >> > > > app-admin/eselect-python only when ${CATEGORY}/${PN} is
>> >> > > > dev-lang/python, dev-java/jython or dev-python/pypy. See bug
>> >> > > > #341037.
>> >> > >
>> >> > > Couldn't we just push that dependency to the specific ebuilds?
>> >> >
>> >> > We want to control required version (>=20091230 in case of
>> >> > app-admin/eselect-python) in 1 place.
>> >> >
>> >>
>> >> this can be achieved by setting a variable that said ebuilds will
>> >> append to (R)DEPEND; no need for complex 'if then else' on CAT/PN
>> >> in an eclass for this.
>> >>
>> >
>> > or also by adding a new python-implementation.eclass instead of
>> > polluting an eclass used by hundreds of packages for only 3 special
>> > ones...
>> >
>>
>> A four-way if-then statement is not what I would call "complex". This
>> was already present in the eclass anyway, so there is no additional
>> "pollution".
>
> a four-way if-then with pattern matching / strcmp is slower than a
> constant variable assignment; it could matter when this is done
> everytime an ebuild inheriting it is sourced. it probably doesnt, but
> imho, its good practice to keep global scope code in eclasses as simple
> as possible.
>

Ah right. It is now being executed in global scope, so there is a
slight performance degradation there. Point taken.

Re: [gentoo-dev] Re: Documentation for sys-boot/grub:2

[Mike Gilbert]

On Tue, Mar 20, 2012 at 5:34 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Talking about which, should I actively pursue bug filing on it yet?  With
> gentoo, upstream, or both?  If you're actively wanting those bugs now,
> please do put an elog to that effect in the ebuild, and I'll start being
> particular about stuff like help cat working, and filing bugs if it
> doesn't!
>

By all means, please file your bugs!

I will probably refer you upstream for most of them, so please
register for an account on savannah.gnu.org. If you are reasonably
sure that your issue is not caused by something Gentoo-specific, you
file them upstream immediately.

Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.

[Mike Gilbert]

On Fri, Mar 23, 2012 at 4:15 AM, Alexis Ballier  wrote:

> DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]"
> DEPEND="${RDEPEND}"

That looks like a typo.

> oasis_src_compile() {
>   oasis_src_compile_no_doc
>   if has doc ${IUSE} && use doc; then
>   ocaml setup.ml -doc || die
>   fi
> }

This should probably call use_if_iuse from eutils.eclass, which
handles IUSE="[+-]doc".

Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.

[Mike Gilbert]

On Fri, Mar 23, 2012 at 12:02 PM, Ciaran McCreesh
 wrote:
> On Fri, 23 Mar 2012 11:58:47 -0400
> Mike Gilbert  wrote:
>> > oasis_src_compile() {
>> >     oasis_src_compile_no_doc
>> >     if has doc ${IUSE} && use doc; then
>> >             ocaml setup.ml -doc || die
>> >     fi
>> > }
>>
>> This should probably call use_if_iuse from eutils.eclass, which
>> handles IUSE="[+-]doc".
>
> Actually, neither way works. The spec says:
>
>    Global variables must only contain invariant values
>    (see~\ref{sec:metadata-invariance}). If a global variable's value is
>    invariant, it may have the value that would be generated at any
>    given point in the build sequence.
>
> So you can't rely upon IUSE having the "merged" value in an eclass.
>

use_if_iuse is called from functions in several eclasses already in
the tree. See chromium, kde4-base, qt4-build, and toolchain.

Are all of these usages incorrect? Do you have an alternate solution?

Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.

[Mike Gilbert]

On Fri, Mar 23, 2012 at 12:52 PM, Ciaran McCreesh
 wrote:
> On Fri, 23 Mar 2012 12:50:51 -0400
> Mike Gilbert  wrote:
>> use_if_iuse is called from functions in several eclasses already in
>> the tree. See chromium, kde4-base, qt4-build, and toolchain.
>>
>> Are all of these usages incorrect? Do you have an alternate solution?
>
> We had this discussion when the function was introduced, and we were
> assured that it "would only be used correctly"... The correct solution
> is probably to have ebuilds define a variable like "OASIS_WANT_DOCS",
> and to use that.
>

Ah. I'll have to review chromium.eclass then; I think I'm doing it wrong.

Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[Mike Gilbert]

On Mon, Mar 26, 2012 at 1:08 PM, "Paweł Hajdan, Jr."
 wrote:
> I posted this issue here because it's not obvious what to do with it.
> That version of pybugz worked for me before (20 February 2012).
>
> Any ideas?
>

I'm guessing it was broken by the upgrade from Bugzilla 4.0 to Bugzilla 4.2.

I think you should file a bug for pybugz. :)

Long term, we may want to consider porting pybugz to use Bugzilla's
XML-RPC api to avoid such breakage.

Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[Mike Gilbert]

On Tue, Mar 27, 2012 at 4:04 AM, Ian Whyman  wrote:
> On 27 March 2012 08:33, Dirkjan Ochtman  wrote:
>> On Mon, Mar 26, 2012 at 20:44, Alec Warner  wrote:
 Long term, we may want to consider porting pybugz to use Bugzilla's
 XML-RPC api to avoid such breakage.
>>>
>>> XML-RPC is shit.
>>
>> https://wiki.mozilla.org/Bugzilla:REST_API
>>
>
> Shame that it requires custom patches to BZ, personally I think the
> preferable (and offically supported) method would be JSON-RPC[1]
>
> Ian
>
> 1.http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService/Server/JSONRPC.html
>

Quoting that page:

Please note that everything about this JSON-RPC interface is
EXPERIMENTAL. If you want a fully stable API, please use the
Bugzilla::WebService::Server::XMLRPC|XML-RPC interface.

This is why I suggested the XML-RPC api.

[gentoo-dev] Add USE_PYTHON to profiles/info_vars

[Mike Gilbert]

python.eclass looks at the USE_PYTHON variable to determine which
python versions to target when building python packages which support
installation for multiple python abis. Having it in the emerge --info
output would be useful for diagnosing python-related bugs.

Any objections?

Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change

[Mike Gilbert]

On Wed, Apr 4, 2012 at 2:32 AM, justin  wrote:
> 2.
> suid it (bad in my view)
> 3.
> file capabilities (can this be done with portage)
>

iotop is a python script, so these were not really options anyway.
Unless you wrote a wrapper in C or something. :)

Re: [gentoo-dev] New eclass for Python

[Mike Gilbert]

On Wed, Apr 4, 2012 at 4:50 AM, Corentin Chary  wrote:
> I have a package that depends on python-dateutil:python-2 for
> python2_x and python-dateutil:python-3 for python3_x.
> Would it be possible to have virtual targets like "python, python2,
> python3, pypi, jithon" ?
>

With regards to python-dateutil: As of python-dateutil-2.1, there are
no longer separate slots for python-2 and python-3. As well, I masked
the only version (2.0) with SLOT=python-3.

For future compatibility, you should remove the slot from your
dependencies and just depend on dev-python/python-dateutil.

Re: [gentoo-dev] New eclass for Python

[Mike Gilbert]

On Wed, Apr 4, 2012 at 4:50 AM, Corentin Chary  wrote:
> I have a feature request for distutil-ng (or maybe it's already
> possible but I don't know how).
>
> I have a package that depends on python-dateutil:python-2 for
> python2_x and python-dateutil:python-3 for python3_x.
> Would it be possible to have virtual targets like "python, python2,
> python3, pypi, jithon" ?
>

One way to implement this would be to have a separate function that
you would call to generate abi-specific dependencies.

Re: [gentoo-dev] New eclass for Python

[Mike Gilbert]

On Wed, Apr 4, 2012 at 8:07 PM, Brian Harring  wrote:
> On Wed, Apr 04, 2012 at 10:41:03AM -0400, Mike Gilbert wrote:
>> On Wed, Apr 4, 2012 at 4:50 AM, Corentin Chary  
>> wrote:
>> > I have a feature request for distutil-ng (or maybe it's already
>> > possible but I don't know how).
>> >
>> > I have a package that depends on python-dateutil:python-2 for
>> > python2_x and python-dateutil:python-3 for python3_x.
>> > Would it be possible to have virtual targets like "python, python2,
>> > python3, pypi, jithon" ?
>> >
>>
>> One way to implement this would be to have a separate function that
>> you would call to generate abi-specific dependencies.
>
> Think through the performance implications of that, and the fact that
> moves control/decisions outside of the PM resolvers purview.
>
> If it's use controlled and is part of metadata, sure, but anything
> else?  Not so much. :)

All I'm talking about is a function or function(s) to generate deps like these:

python2_6? ( dev-python/python-dateutil[python2_6] )
python2_7? ( dev-python/python-dateutil[python2_7] )

I'm not sure how that would affect "performance".

Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[Mike Gilbert]

On Thu, Apr 5, 2012 at 5:59 PM, William Hubbs  wrote:
> Hi all,
>
> here is a quick update on this:
>
> On Mon, Mar 26, 2012 at 01:20:38PM -0400, Mike Gilbert wrote:
>> On Mon, Mar 26, 2012 at 1:08 PM, "Paweł Hajdan, Jr."
>>  wrote:
>> > I posted this issue here because it's not obvious what to do with it.
>> > That version of pybugz worked for me before (20 February 2012).
>> >
>> > Any ideas?
>> >
>>
>> I'm guessing it was broken by the upgrade from Bugzilla 4.0 to Bugzilla 4.2.
>>
>> I think you should file a bug for pybugz. :)
>>
>> Long term, we may want to consider porting pybugz to use Bugzilla's
>> XML-RPC api to avoid such breakage.
>
> Agreed, and I think that is going to happen sooner than longterm.
>
> I now have a project on my github account called PyZilla, which is a
> library for communicating with BugZilla via xmlrpc.  [1] However, it
> does not work with python 2.7, which is what I would like.
>
> I emailed the original author since he hadn't worked on this library in
> a year, and I was given permission to take over maintainership because
> he said he doesn't have time to work on it.
>
> So, any patches to make this work with python-2.7 are welcome. :-)
>
> William
>
> [1] https://github.com/williamh/PyZilla
>

Heh, I have been working on a similar concept, and I actually have a
working implementation. I am able to successfully search, log in, and
create new bugs. I just pushed this to my github.

https://github.com/floppym/BugzillaProxy

I have not taken the time to integrate it into pybugz. If you want to
take it from here, that would be great. Or I'm happy to help too; I'm
just not quite sure how to integrate it.

Side note: I have noticed that the xml-rpc interface does not allow
you to search on all available Bugzilla fields. The most obvious
missing field is the CC list.

Re: [gentoo-dev] Packages up for grabs due mrness retirement

[Mike Gilbert]

On 04/06/2012 06:02 PM, Pacho Ramos wrote:
> net-misc/openswan

I'll take this; I use it to connect to a Microsoft L2TP server for work.

If anyone wants to co-maintain you are welcome to do so.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] pybugz call for testers

[Mike Gilbert]

On Tue, Apr 10, 2012 at 5:17 PM, William Hubbs  wrote:
> Here is the documentation for their search command [1]. It would
> probably be better for us to open a bug against bugzilla itself and
> request those changes be put in the api.
>

I did some digging on Bugzilla's Bugzilla. There is already a bug open
with patches to expose additional search functionality via the web
service api. This bug has open since 2009, but it has seen some recent
activity (within the last few months).

https://bugzilla.mozilla.org/show_bug.cgi?id=475754

Re: [gentoo-dev] pybugz call for testers

[Mike Gilbert]

On Wed, Apr 11, 2012 at 7:55 AM, "Paweł Hajdan, Jr."
 wrote:
> On 4/10/12 11:17 PM, William Hubbs wrote:
>> On Tue, Apr 10, 2012 at 10:45:14PM +0200, "Paweł Hajdan, Jr." wrote:
>>> On 4/10/12 7:54 PM, William Hubbs wrote:
 I can name a couple of issues that are api limitations that we can't do
 anything about:
 - you can't search on cc: or keywords fields.
>>> That's going to be a problem for arch testing needs (e.g. STABLEREQ
>>> keyword and x86@ cc-ed). How about doing the searches "the old way" that
>>> allowed the above.
>>
>> That is not so easy to do since we have completely gotten rid of the old
>> method of communicating with bugzilla. That method was not reliable and
>> had broken several times with bugzilla upgrades, but using the web
>> services will be more stable.
>
> Right, scraping HTML that way was obviously brittle, but at least it
> worked (in the pragmatic sense). Without that functionality, the
> batch-stabilization tools I and other devs use would be broken.
>
> If possible, please restore the old code, possibly marked as deprecated
> and not officially supported (best effort, patches welcome is fine), and
> named maybe search_brittle or something similar.
>

Do you need the command line front end for your arch testing
utilities, or are you using the bugzilla.py module directly? If the
latter, I think it would be possible to restore the old bugzilla.py
module, possibly with a different name.

If you actually need the front end (bugz and cli.py), it would
probably be easier for you to just have two copies of pybugz: an old
version for searching and a new version for making changes.

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Mike Gilbert]

On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long
 wrote:
> Rich Freeman wrote:
>>> The Council has voted that Gentoo continue to support that subset,
>>> without an initramfs.
>>
> (The "subset of users" being those who do not need udev before localmount.)
>
>> Citation, please?
>>
>
>  New udev and separate /usr partition
>  In my opinion, a separate /usr partition has been a supported
> configuration for a very long time and should remain so.
>  Chainsaw: So to clarify a universal initramfs is not enough?
>  Betelgeuse: No. That is additional work for a clearly broken
> package.
>
> So we must support separate /usr *without* an initramfs.
>
>  who's going to either "port" udev as necessary, or maintain an
> old version forever?
>  I will keep an old version going until the end of time.
>  dberkholz: My plan is to patch reasonable behaviour back into
> udev, and going with the upstream releases as long as it is feasible.
>
> To confirm again, that this is about without initramfs:
>  sure i can. maintain old udev-XXX forever, put an elog in new
> udev that says "if you want separate /usr without initramfs, install old
> udev, mask new, or whatever"
>
> And again, I ask: if it were *not* about running udev without an initramfs,
> then why would anyone even be discussing the possibility of patching or
> forking?
>

Here is my interpretation: the council voted on the following question:

 The question is: "Decide on whether a separate /usr is still a supported
  configuration."

It did not decide the method that would be used to accomplish this. A
few council members (Chainsaw mainly) expressed a desire to do it
without an initramfs, but an official stance on this was not put
forward.

You are reading into it more that you should.

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Mike Gilbert]

On 04/22/2012 05:28 AM, Steven J Long wrote:
> Ulrich Mueller wrote:
> 
>> | 3. New udev and separate /usr partition (30 minutes)
>> | 
>> |See [4]: "Decide on whether a separate /usr is still a supported
>> |configuration. If it is, newer udev can not be stabled and
>> |alternatives should be investigated. If it isn't, a lot of
>> |documentation will have to be updated. (And an alternative should
>> |likely still be provided.)"
>> |
>> | [4]
>> | [ project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>>
> From the first reply:
> 
> "To clarify, the question is whether or not we support a separate /usr 
> _without_ mounting it early via an initramfs."
> 
> I hope that settles that particular issue.
> 

Hmm... I see that in Zac's reply, thanks for that.

Unfortunately, from what I can tell, that clarification was not actually
part of the proposed agenda [5], nor was it directly referenced. So the
subject of the vote still seems open to interpretation.

Ultimately, the council's only "power" is to stop things from happening
under threat of expulsion from the project. I think it would be a
mistake for this particular council vote to be used as the sole
justification for preventing devs from committing changes that would
require an initramfs for separate /usr support. It simply does not seem
clear enough for that.

[5]
http://archives.gentoo.org/gentoo-project/msg_ac95bed78694852cd09f20a07437b805.xml



signature.asc
Description: OpenPGP digital signature

Re: profiles/updates/ 'move' lacks support for versioned syntax (was: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo)

[Mike Gilbert]

On Mon, Apr 23, 2012 at 8:49 AM, Samuli Suominen  wrote:
> On 04/23/2012 03:28 PM, Duncan wrote:
>>
>> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>>
>>> Title: The default JPEG implementation
>>
>>
>> [...]
>>
>>> All users are recommended to migrate:
>>>
>>> # emerge -C media-libs/jpeg:0
>>> # emerge -1 media-libs/libjpeg-turbo
>
>>
>>
>> There's no way to use portage's automatic block-resolving ability here to
>> avoid that, I take it?
>
>
> Too bad profiles/updates/ doesn't support versioned syntax[1] like,
>
> 'move =media-libs/jpeg-8* media-libs/libjpeg-turbo'
>

I don't think a package move is appropriate here anyway. That would
just move the files in vdb without actually building/installing
libjpeg-turbo.

Re: [gentoo-dev] Re: RFC: A tiny news item for migrating to libjpeg-turbo

[Mike Gilbert]

On Mon, Apr 23, 2012 at 8:28 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Samuli Suominen posted on Mon, 23 Apr 2012 14:22:53 +0300 as excerpted:
>
>> Title: The default JPEG implementation
>
> [...]
>
>> All users are recommended to migrate:
>>
>> # emerge -C media-libs/jpeg:0
>> # emerge -1 media-libs/libjpeg-turbo
>
> That of course leaves the system without a jpeg library between the jpeg
> unmerge and the completion of the libjpeg-turbo merge.  If the build
> process fails for some reason...
>
> There's no way to use portage's automatic block-resolving ability here to
> avoid that, I take it?
>

This works for me.

floppym@naomi ~ % emerge -pv1 -j1 libjpeg-turbo

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N ] media-libs/libjpeg-turbo-1.2.0-r1  USE="-java
-static-libs" 0 kB
[uninstall ] media-libs/jpeg-8d  USE="-static-libs"
[blocks b  ] media-libs/jpeg:0 ("media-libs/jpeg:0" is blocking
media-libs/libjpeg-turbo-1.2.0-r1)

Re: [gentoo-dev] Chromium bundled code

[Mike Gilbert]

On Mon, Apr 30, 2012 at 1:30 PM, Mike Frysinger  wrote:
> On Monday 30 April 2012 12:32:35 Matt Turner wrote:
>> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
>> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> >> doing it wrong.  I don't like how Google develops Android in the dark,
>> >> or that they bundle 1GB of third-party stuff in their Chromium source
>> >> and distribute a favored binary-only derivative.
>> >
>> > err, they distribute a Chromium source tarball, and their build system
>> > includes flags to use the system versions of those bundled libs if you so
>> > choose.  i think this is a perfectly fine compromise.
>>
>> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
>> libraries
>
> to be sure the system ones get used
>
>> and still has TODOs in place to use the system's ffmpeg,
>> hunspell, (Open?)SSL, SQLite, and libvpx.
>
> it's on going work :).  ffmpeg/libvpx are a bit harder as Chromium syncs 
> faster
> than they make releases i believe.
> -mike

Right. Generally, the bundled ffmpeg does not correspond to an
official upstream release.

ffmpeg upstream is not afraid of making API changes, so it has proven
quite difficult to make chromium work with all versions on ffmpeg in
portage, plus the bundled snapshot. When we were using the system lib,
it would break nearly every time a new major version of chromium was
forked.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/default/bsd: ChangeLog profile.bashrc

[Mike Gilbert]

On Wed, May 2, 2012 at 11:08 AM, Samuli Suominen  wrote:
> Oops, something went wrong here. Please fix your terminal/editor encoding to
> unicode.
>

I have two questions:

1. Was this a repoman or echangelog generated entry?
2. If so, do these tools need to be fixed to always generate UTF-8?

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/default/bsd: ChangeLog profile.bashrc

[Mike Gilbert]

On Wed, May 2, 2012 at 4:38 PM, Mike Frysinger  wrote:
> On Wednesday 02 May 2012 14:04:57 Mike Gilbert wrote:
>> On Wed, May 2, 2012 at 11:08 AM, Samuli Suominen wrote:
>> > Oops, something went wrong here. Please fix your terminal/editor encoding
>> > to unicode.
>>
>> I have two questions:
>>
>> 1. Was this a repoman or echangelog generated entry?
>
> repoman can't commit to profiles/

Oh, duh.

>> 2. If so, do these tools need to be fixed to always generate UTF-8?
>
> i don't think either of these tools process the whole file.  it just prepends
> new content.  i could be wrong.

It looks like echangelog slurps the whole ChangeLog into memory, makes
the necessary edits, and then barfs it back out.

Re: [gentoo-dev] Chromium bundled code

[Mike Gilbert]

On Fri, May 4, 2012 at 2:03 PM, Luca Barbato  wrote:
> On 04/05/12 01:37, Alec Warner wrote:
>> I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
>> and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
>> totally OK and you are free to use whatever software you prefer. I
>> somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
>> dbus / etc requirements.
>
> If dbus and libudev are just for fringe features might be nice disable
> them. I wonder if there isn't already a setting for it. chrome for
> android won't use them anyway.
>

I don't see a user-controllable setting for dbus or udev. Rather, it
checks for OS == "Linux".

My 2 cents: The Chromium project really doesn't have any motivation to
make it optional since their end product is Google Chrome and they
target a given version of Ubuntu. I think a patch to make them
optional might be accepted, but it probably isn't going to happen
otherwise.

Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1

[Mike Gilbert]

On Fri, May 4, 2012 at 2:29 PM, hasufell  wrote:
> On 05/04/2012 08:00 PM, Johannes Huber wrote:
>> Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
>>> # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable
>>> verbose messages during compilation.
>>>
>>> By default this is deactivated which is inconvenient imo and
>>> results in pastes having minimum information. I have to tell
>>> users every time to recompile with CMAKE_VERBOSE=1 so that I have
>>> proper information on what is going on.
>>>
>>> Are there any arguments against this being default?
>>
>> In 95-99% of the build failures we get in kde herd the information
>> is sufficient. So from my point of view the current behaviour is
>> good.
>>
>> Greetings
>>
>
> I think that as an argument pro CMAKE_VERBOSE=1 because that would
> cover 100% instead of 95-99.
>

I only maintain a couple of cmake-based ebuilds, but I find having the
full compiler command line useful. Without it, I have to guess at what
was actually run.

Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1

[Mike Gilbert]

On Fri, May 4, 2012 at 3:25 PM, Johannes Huber  wrote:
> Am Freitag, 4. Mai 2012, 14:41:42 schrieb Mike Gilbert:
>> On Fri, May 4, 2012 at 2:29 PM, hasufell  wrote:
>> > On 05/04/2012 08:00 PM, Johannes Huber wrote:
>> >> Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
>> >>> # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable
>> >>> verbose messages during compilation.
>> >>>
>> >>> By default this is deactivated which is inconvenient imo and
>> >>> results in pastes having minimum information. I have to tell
>> >>> users every time to recompile with CMAKE_VERBOSE=1 so that I have
>> >>> proper information on what is going on.
>> >>>
>> >>> Are there any arguments against this being default?
>> >>
>> >> In 95-99% of the build failures we get in kde herd the information
>> >> is sufficient. So from my point of view the current behaviour is
>> >> good.
>> >>
>> >> Greetings
>> >
>> > I think that as an argument pro CMAKE_VERBOSE=1 because that would
>> > cover 100% instead of 95-99.
>>
>> I only maintain a couple of cmake-based ebuilds, but I find having the
>> full compiler command line useful. Without it, I have to guess at what
>> was actually run.
>
> How about bump docs for that use case? For example
> http://www.gentoo.org/proj/en/qa/backtraces.xml
>

As far as I can tell, such documentation is largely ignored unless
users are pointed to it by a comment on a bug. It would be nice to
avoid having to wait for the user to respond with the updated build
log.

[gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile

[Mike Gilbert]

To make ebuilds utilizing python-distutils-ng.eclass usable
"out-of-the-box", the python team would like to add the following to
make.defaults in the base profile.

PYTHON_TARGETS="python2_7"

See also bug 415575 [1].

Any objections?

I would also like to include python3_2, but I do not think this will be
possible due to dev-lang/python:3.2 not being stabilized on several
arches. Perhaps this could be set in arch-specific profiles? Would that
work?

[1] https://bugs.gentoo.org/show_bug.cgi?id=415575



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile

[Mike Gilbert]

On 5/14/2012 12:50 AM, Ben de Groot wrote:
> On 14 May 2012 04:27, Mike Gilbert  wrote:
>> To make ebuilds utilizing python-distutils-ng.eclass usable
>> "out-of-the-box", the python team would like to add the following to
>> make.defaults in the base profile.
>>
>> PYTHON_TARGETS="python2_7"
>>
>> See also bug 415575 [1].
>>
>> Any objections?
> 
> I think this is a good addition.
> 
>> I would also like to include python3_2, but I do not think this will be
>> possible due to dev-lang/python:3.2 not being stabilized on several
>> arches. Perhaps this could be set in arch-specific profiles? Would that
>> work?
> 
> I don't see how python:3.2 is useful for most of our users. And I
> especially don't see how having two python versions installed (but
> only one active) is useful for most of our users. So let's make
> sure only one version gets pulled in, unless specifically
> configured by the user.

So long as any installed package depends on dev-lang/python without
specifying a version, the user will end up with python-3 unless they
mask it. There is no easy way out of that situation at this point; I
think it would basically require renaming >=dev-lang/python-3 to
something else.

If we acknowledge that users have both python:3.2 and python:2.7
installed most of the time, I think it makes sense to set the default
value of PYTHON_TARGETS to match that expectation.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile

[Mike Gilbert]

On 5/14/2012 11:17 AM, Pacho Ramos wrote:
> Would be too difficult to finally fix ebuilds to properly convet
> shebangs and so and then, be able to have a proper system even when
> python3 is main interpreter?

Yeah, python_convert_shebangs is an easy fix for most cases.

> Personally, I run with it as main interpreter to catch failures, and try
> to fix them when possible, maybe all devs should do the same to fix
> packages still not working at all.

Thanks for that, the help is appreciated.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Adding PYTHON_TARGETS=python2_7 to base profile

[Mike Gilbert]

On 5/13/2012 4:27 PM, Mike Gilbert wrote:
> To make ebuilds utilizing python-distutils-ng.eclass usable
> "out-of-the-box", the python team would like to add the following to
> make.defaults in the base profile.
> 
> PYTHON_TARGETS="python2_7"
> 
> See also bug 415575 [1].
> 
> Any objections?
> 

Seeing no objections to this part, I plan to add
PYTHON_TARGETS="python2_7" to the base profile in the next day or so.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: enhancement for doicon/newicon in eutils.eclass

[Mike Gilbert]

On Mon, May 21, 2012 at 1:30 AM, hasufell  wrote:
> On 05/21/2012 02:01 AM, Jonathan Callen wrote:
>> On 05/20/2012 07:49 PM, hasufell wrote:
>>> On 05/21/2012 01:36 AM, Alexis Ballier wrote:
 On Mon, 21 May 2012 01:24:13 +0200 hasufell
  wrote:

> I want support for installing icons into the appropriate
> directories which are under /usr/share/icons/... and not
> just pixmaps.
>
> proposal attached + diff
>
> This should not break existing ebuilds. Tested a bit and
> open for review now.

 maybe i missed something but cant you just make doicon a
 newicon wrapper and remove all that code duplication ?

>>
>>> I don't see how. "doicon" supports installing multiple icons
>>> with one command, as well as directories. That does not work for
>>> "newicon".
>>
>>
>>
>> Normally, new* is a wrapper for do* that does something like:
>>
>> newfoo() { # argument checking omitted... cp -P "${1}" "${T}/${2}"
>> dofoo "${T}/${2}" }
>>
>>
>
> That does not use "newins" like the old function. Why would I want to
> change that?
>

An alternative would be to factor the common code into a third
function, and call that from doicon and newicon.

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Mike Gilbert]

On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky  wrote:
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?
>

Portage currently defaults to running the build process as root. The
entire point of this thread is that Zac wants to change the default to
build as the portage user (FEATURES="userpriv" in make.globals).

Re: [gentoo-dev] [PATCH] games.eclass: allow EAPI=4

[Mike Gilbert]

On Tue, May 29, 2012 at 3:36 PM, hasufell  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/29/2012 09:00 PM, Sergei Trofimovich wrote:
>> Nice to drop '|| die' and have REQUIRED_USE in games ebuilds
>>
>> OK to push?
>>
>> Thanks!
>>
>
> +1 for bumping
>
> but is this known to not break anything?

The easiest way to determine that is to remove the die from the eclass
and start bumping ebuilds to EAPI=4. Any issues can be addressed as
ebuilds are migrated.

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Mike Gilbert]

On 6/13/2012 12:00 PM, Ian Stakenvicius wrote:
> Hey all - I'd like to propose that enewuser forces updates to a user's
> home dir and shell whenever it is called, so that if this changes with
> new versions of an ebuild it is dealt with automatically rather than
> having to modify them in pkg_postinst/pkg_setup directly.
> 

Can you give an example of a case where modifying the home directory
and/or shell is necessary? I don't really understand how this is useful.

Also, grobian raised a good point in that the sysadmin may have changed
it manually. It might be better to ewarn and make the user deal with it.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Mike Gilbert]

On 6/13/2012 2:32 PM, Ian Stakenvicius wrote:
> On 13/06/12 02:09 PM, Fabian Groffen wrote:
>> On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote:
>>> Hey all - I'd like to propose that enewuser forces updates to a
>>> user's home dir and shell whenever it is called, so that if this
>>> changes with new versions of an ebuild it is dealt with
>>> automatically rather than having to modify them in
>>> pkg_postinst/pkg_setup directly.
> 
>> What if some admin purposely changed home or shell for a system
>> account? Would be quite annoying if every update would reset that,
>> wouldn't it?
> 
> 
> 
> 
> I considered this case, and that it might be more appropriate to
> duplicate 'enewuser' into a new call 'eforceuser' (or similar) which
> could be used instead of 'enewuser' in cases when the currently
> provided user settings should be forced.
> 
> I decided against this as it seems also to make sense that users
> created by portage should be controlled by portage.
> 
> I suppose probably the best means of handling this would be to somehow
> detect whether or not the current user settings are default and only
> apply the updates if they are; however a means of doing that (which
> would be transparent to the ebuild) is somewhat beyond my knowledge
> and abilities.
> 

Just a thought: You could introduce a variable that would disable the
forced updates. This could be set in make.conf by any users who prefer
not to have their passwd database updated automatically.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: esethome

[Mike Gilbert]

On Fri, Jun 15, 2012 at 10:05 AM, Peter Stuge  wrote:
> Fabian Groffen wrote:
>> > > >>> +       if [[ ! -n $(egetent passwd "${euser}") ]] ; then
>> > > >>
>> > > >> "! -n" -> "-z"
>> > > >
>> > > > Does the $() argument ever need to be double quoted, or do all
>> > > > versions of bash actually have the string argument optional even
>> > > > though that's not what the man page reads?
>> > >
>> > > Ever?  Yes, but only if what is being returned can contain spaces
>> >
>> > Sorry, I should have mentioned that I had the case of the empty
>> > string in mind.
>>
>> Here for the same reason, the difference between [[ and [ is essential.
>
> It's not clear to me why?
>
> [] is shorthand for test. Both test and [[]] in my man bash read:
>
> --8<--
> Expressions are composed of the primaries described .. under
> CONDITIONAL EXPRESSIONS.
> -->8--
>
> There it says:
> --8<--
> Conditional expressions are used by the [[ compound command and
> the test and [ builtin commands
> -->8--
>
> and:
> --8<--
>       -z string
>              True if the length of string is zero.
>       string
>       -n string
>              True if the length of string is non-zero.
> -->8--
>
> ..which does not at all make it clear that the string is actually
> optional?
>
> Under Command Substitution it says:
> --8<--
> Embedded newlines are not deleted, but they may be removed during
> word splitting.
> ..
> If the substitution appears within double quotes, word splitting
> and pathname expansion are not performed on the results.
> -->8--
>
> ..confirming that there is some processing of the substitution.
>
>
> I also did the tests before asking the question. I'm not trying to
> say that the code doesn't work on my system. I'm asking if it will
> work the same on every version of bash, in spite of what seems to
> be a conflict between real world and documentation.
>
>
> //Peter

Word splitting does not occur within double brackets. This is
documented in the bash manual.

http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs

This causes empty output from a command substitution within double
brackets to be treated as a zero-length string.

Re: [gentoo-dev] ebuild laziness and binpkg overhead

[Mike Gilbert]

On Tue, Jun 19, 2012 at 11:21 PM, Mike Frysinger  wrote:
> On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
>> On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
>> > i've noticed a growing trend where people put setup of variables into
>> > pkg_setup that only matter to src_* funcs presumably so they don't
>> > have to call the respective src_* func from an inherited eclass.
>> > unfortunately this adds pointless overhead to binpkgs.  can we please
>> > move away from this practice ?
>>
>> Like this?
>
> not quite
>
>>  * ERROR: cat/pkg-version failed (prepare phase):
>>  *   python_set_active_version() can be used only in pkg_setup() phase
>>  *
>>  * Call stack:
>>  *     ebuild.sh, line   85:  Called src_prepare
>>  *   environment, line 5885:  Called python_set_active_version '2'
>>  *   environment, line 5603:  Called die
>>  * The specific snippet of code:
>>  *           die "${FUNCNAME}() can be used only in pkg_setup() phase";
>>  *
>>
>> Shouldn't that be in src_prepare already, or does python.eclass do
>> something rather important here while installing a binpkg?
>
> Gentoo's python integration is an ugly beast.  in this case, i believe it's
> screwing with your $ROOT which means it has to be in pkg_* (let's quietly
> ignore what happens if you try to emerge two ebuilds which need conflicting
> versions of python active).
> -mike

python_set_active_version basically just sets the EPYTHON and
PYTHON_ABI variables; nothing in ${ROOT} is modified.

The variables are used in python_pkg_setup to implement use-flag
checks for PYTHON_USE_WITH, and also in python_mod_optimize which is
called in pkg_postinst.

Re: [gentoo-dev] RFC: PROPERTIES=funky-slots

[Mike Gilbert]

On Sat, Jun 23, 2012 at 9:21 AM, Ciaran McCreesh
 wrote:
> There's been a move towards using slots for "clever" things that don't
> fit the traditional way of how slots worked. Examples include the new
> gtk2 / gtk3 handling and Ruby gems virtuals.
>
> Aside from being abusive, this screws things up for Paludis users.
> Paludis tends to bring in newer versions when possible (so that users
> aren't stuck with an old GCC forever), and allows the user to select
> when new slots are brought in. When suddenly a few packages are using
> slots and versions to "mean" something other than what they used to,
> this makes the feature unusable.
>
> Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES
> value called "funky-slots", which should be set on every version of any
> package that uses slots in an unconventional manner. This probably
> doesn't need EAPI control, since package manglers are free to ignore
> PROPERTIES tokens. It won't solve the abuse, but it will allow the
> impact upon users to be lessened.
>
> --
> Ciaran McCreesh

I don't quite understand why this would be necessary.

Would "funky-slots" just be used in situations where ebuilds with the
same PV but different PVR have different slots?

Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only
used in libraries; applications use slot deps to select which one they
need. Paludis should not remove the -r200 version if it is still
referenced in the depgraph, correct?

Re: [gentoo-dev] RFC: PROPERTIES=funky-slots

[Mike Gilbert]

On Sat, Jun 23, 2012 at 10:02 AM, Mike Gilbert  wrote:
> On Sat, Jun 23, 2012 at 9:21 AM, Ciaran McCreesh
>  wrote:
>> There's been a move towards using slots for "clever" things that don't
>> fit the traditional way of how slots worked. Examples include the new
>> gtk2 / gtk3 handling and Ruby gems virtuals.
>>
>> Aside from being abusive, this screws things up for Paludis users.
>> Paludis tends to bring in newer versions when possible (so that users
>> aren't stuck with an old GCC forever), and allows the user to select
>> when new slots are brought in. When suddenly a few packages are using
>> slots and versions to "mean" something other than what they used to,
>> this makes the feature unusable.
>>
>> Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES
>> value called "funky-slots", which should be set on every version of any
>> package that uses slots in an unconventional manner. This probably
>> doesn't need EAPI control, since package manglers are free to ignore
>> PROPERTIES tokens. It won't solve the abuse, but it will allow the
>> impact upon users to be lessened.
>>
>> --
>> Ciaran McCreesh
>
> I don't quite understand why this would be necessary.
>
> Would "funky-slots" just be used in situations where ebuilds with the
> same PV but different PVR have different slots?
>
> Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only
> used in libraries; applications use slot deps to select which one they
> need. Paludis should not remove the -r200 version if it is still
> referenced in the depgraph, correct?

Or maybe you are saying that Paludis will not automatically install a
new slot for a package that is already installed, even when referenced
by a slot dep?

[gentoo-dev] grub:2 keywords

[Mike Gilbert]

An official release of grub-2.00 should be coming pretty soon. I would
like to keyword this for ~amd64 and ~x86 shortly after it hits the tree.
I don't do much work on base system packages, so I would like some
advice on how to make this as smooth as possible.

My main concern is that many people probably have sys-boot/grub in
@world. If grub:2 is made visible, portage will install it, and will
remove grub-0.97 on the next depclean. This could be a little confusing,
but should not cause any immediate damage since the copy of grub-0.97
installed in the MBR and /boot would remain intact.

Is this worthy of a news item? Or I just blog about it?

Anything else I need to think about here?

Note: The Gentoo Documentation Project has indicated that they do not
want to add anything to the handbook until we are somewhat close to
stabilizing grub:2. That's at least a couple months away.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Mon, Jun 25, 2012 at 11:19 AM, Doug Goldstein  wrote:
> Since Grub Legacy and Grub 2 are slotted, Portage won't remove the
> older version. Even if it removes the older one, everything necessary
> is installed into /boot and the MBR already.

Portage will remove the older slot the next time the user runs emerge
--depclean unless sys-boot/grub:0 is added to the world file. I'm
looking for a good way to communicate this to the user.

How about this: For ~arch, we do an ewarn in pkg_postinst if grub:0 is
installed. For stable, we do a news item.

>
> The best route forward would be to instruct people to use
> grub2-install (but whatever the flag is to prevent MBR installation).
> Have people generate their grub.cfg with grub2-mkconfig and then put a
> chain loader into the Grub Legacy configs so that they can test Grub 2
> and then once they test it tell them to install Grub 2 into the MBR
> and remove Grub Legacy.

Yeah, I vaguely remember trying this when I first installed grub:2.
You can prevent the MBR installation by stubbing out the grub-setup
call. For example:

grub2-install --grub-setup=/bin/true /dev/sda

You would then load /boot/grub2/i386-pc/core.img just like a Linux
kernel from menu.lst.

If you (or anyone) wants to test and verify that this actually works,
that would be great.

>
> I'll gladly work with you on this. IMHO, it might be a good plan to
> unmask and ~arch one of the release candidates with an aim to get Grub
> 2.0.0 fully released with docs.

That sounds like a good idea.

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Mon, Jun 25, 2012 at 1:02 PM, Michał Górny  wrote:
> On Mon, 25 Jun 2012 00:15:59 -0400
> Mike Gilbert  wrote:
>
>> An official release of grub-2.00 should be coming pretty soon. I would
>> like to keyword this for ~amd64 and ~x86 shortly after it hits the
>> tree. I don't do much work on base system packages, so I would like
>> some advice on how to make this as smooth as possible.
>>
>> My main concern is that many people probably have sys-boot/grub in
>> @world. If grub:2 is made visible, portage will install it, and will
>> remove grub-0.97 on the next depclean. This could be a little
>> confusing, but should not cause any immediate damage since the copy
>> of grub-0.97 installed in the MBR and /boot would remain intact.
>>
>> Is this worthy of a news item? Or I just blog about it?
>>
>> Anything else I need to think about here?
>>
>> Note: The Gentoo Documentation Project has indicated that they do not
>> want to add anything to the handbook until we are somewhat close to
>> stabilizing grub:2. That's at least a couple months away.
>
> I guess you could prepare some docs already, and put them e.g.
> on the Wiki. Then it would be a really good idea to release a news item
> and point users to those information and inform them about possible
> choices.
>

There is already an elog message referring users to the wiki:

http://wiki.gentoo.org/wiki/GRUB2_Quick_Start

Re: [gentoo-dev] Re: grub:2 keywords

[Mike Gilbert]

On Mon, Jun 25, 2012 at 10:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Mike Gilbert posted on Mon, 25 Jun 2012 12:56:25 -0400 as excerpted:
>
>> On Mon, Jun 25, 2012 at 11:19 AM, Doug Goldstein 
>> wrote:
>>> Since Grub Legacy and Grub 2 are slotted, Portage won't remove the
>>> older version. Even if it removes the older one, everything necessary
>>> is installed into /boot and the MBR already.
>>
>> Portage will remove the older slot the next time the user runs emerge
>> --depclean unless sys-boot/grub:0 is added to the world file. I'm
>> looking for a good way to communicate this to the user.
>>
>> How about this: For ~arch, we do an ewarn in pkg_postinst if grub:0 is
>> installed. For stable, we do a news item.
>
> Here's a bit of a different idea:
>
> Changing the bootloader is really a profile level change.  If appropriate
> grub2-defaulted new profiles are created, and the old ones set to specify
> grub:0 as their default bootloader and then deprecated, this will
> automatically both provide the appropriate upgrade preparation required
> hint, and allow users to upgrade on their own schedule during the usual
> profile deprecation period.
>

Profiles do not set a "default bootloader" so I have no idea what you
are talking about.

Installing grub:2 does not replace grub:0 until the user actually runs
grub2-install, so you can already upgrade on your own schedule.

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Fri, Jun 29, 2012 at 1:13 AM, Mike Frysinger  wrote:
> On Monday 25 June 2012 00:15:59 Mike Gilbert wrote:
>> An official release of grub-2.00 should be coming pretty soon. I would
>> like to keyword this for ~amd64 and ~x86 shortly after it hits the tree.
>> I don't do much work on base system packages, so I would like some
>> advice on how to make this as smooth as possible.
>>
>> My main concern is that many people probably have sys-boot/grub in
>> @world. If grub:2 is made visible, portage will install it, and will
>> remove grub-0.97 on the next depclean. This could be a little confusing,
>> but should not cause any immediate damage since the copy of grub-0.97
>> installed in the MBR and /boot would remain intact.
>>
>> Is this worthy of a news item? Or I just blog about it?
>>
>> Anything else I need to think about here?
>
> do we have automatic migration/updating in place like with grub1 ?  that was
> the biggest reason i didn't unleash it for automatic installing on people's
> systems.
> -mike

No, the grub2 ebuild does not automatically install the files in /boot.

grub2-install performs this step, and must be run by the user. It also
installs the MBR and embeds the core image in unused disk sectors.
This way the MBR/core image is always kept in sync with the files in
/boot/grub2.

I don't really see a way to reliably call grub2-install from the
ebuild, and I think this would be a bit unfriendly to the user anyway.

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Fri, Jun 29, 2012 at 11:32 AM, Mike Frysinger  wrote:
> On Friday 29 June 2012 01:59:37 Mike Gilbert wrote:
>> On Fri, Jun 29, 2012 at 1:13 AM, Mike Frysinger  wrote:
>> > On Monday 25 June 2012 00:15:59 Mike Gilbert wrote:
>> >> An official release of grub-2.00 should be coming pretty soon. I would
>> >> like to keyword this for ~amd64 and ~x86 shortly after it hits the tree.
>> >> I don't do much work on base system packages, so I would like some
>> >> advice on how to make this as smooth as possible.
>> >>
>> >> My main concern is that many people probably have sys-boot/grub in
>> >> @world. If grub:2 is made visible, portage will install it, and will
>> >> remove grub-0.97 on the next depclean. This could be a little confusing,
>> >> but should not cause any immediate damage since the copy of grub-0.97
>> >> installed in the MBR and /boot would remain intact.
>> >>
>> >> Is this worthy of a news item? Or I just blog about it?
>> >>
>> >> Anything else I need to think about here?
>> >
>> > do we have automatic migration/updating in place like with grub1 ?  that
>> > was the biggest reason i didn't unleash it for automatic installing on
>> > people's systems.
>>
>> No, the grub2 ebuild does not automatically install the files in /boot.
>>
>> grub2-install performs this step, and must be run by the user. It also
>> installs the MBR and embeds the core image in unused disk sectors.
>> This way the MBR/core image is always kept in sync with the files in
>> /boot/grub2.
>>
>> I don't really see a way to reliably call grub2-install from the
>> ebuild, and I think this would be a bit unfriendly to the user anyway.
>
> grub1 doesn't seem to have a problem auto-updating itself.  why is grub2 any
> different ?
> -mike

As far as I can tell, grub:0 only half-way updates itself; there is a
large ewarn telling the user that they must take action to install the
new version in the MBR. This seems a bit broken to me.

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Fri, Jun 29, 2012 at 2:08 PM, Rich Freeman  wrote:
> On Fri, Jun 29, 2012 at 12:11 PM, Mike Gilbert  wrote:
>> As far as I can tell, grub:0 only half-way updates itself; there is a
>> large ewarn telling the user that they must take action to install the
>> new version in the MBR. This seems a bit broken to me.
>
> In what way.  As far as I can tell I haven't gotten a grub upgrade in
> the last 5-7 years.  Since it is built static on amd64 (or at least it
> was when I last installed it) nothing ever breaks.  Maybe if I changed
> my boot partition to a different filesystem it might have issues, but
> grub just strikes me as one of those aint-broke-don't-fix things.
>

Right. I was contradicting vapier's statement that grub:0
automatically updates itself. It doesn't.

It does copy all of the images to /boot so that the grub shell can be
used to install an MBR image. grub:2 no longer has an interactive
shell and grub2-install must be used. Therefore, copying files to
/boot in the ebuild is completely pointless.

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Fri, Jun 29, 2012 at 2:38 PM, Rich Freeman  wrote:
> On Fri, Jun 29, 2012 at 2:29 PM, Mike Gilbert  wrote:
>> It does copy all of the images to /boot so that the grub shell can be
>> used to install an MBR image. grub:2 no longer has an interactive
>> shell and grub2-install must be used. Therefore, copying files to
>> /boot in the ebuild is completely pointless.
>
> Does grub2-install place any stage files where they need to be, or are
> they no longer needed?  I haven't experimented with it yet.
>
> Normally grub1 needs to be able to find the stage2 file, and that has
> to be on a partition the stage1.5 can read (I believe stage1.5 is in
> the diagnostic cylinder - it only uses the files in /boot during
> installation).

grub2 eliminates the stage_1_5 files. Instead, a "core" image is built
by grub2-install.

Here's how it works.

1. grub2-install copies all grub modules to /boot/grub2. This can be
any file system readable by GRUB.
2. grub2-install calls grub2-mkimage which combines any modules
necessary to access /boot into core.img.
3. grub2-install calls grub2-bios-setup which installs boot.img into
the MBR and embeds core.img into the sectors immediately after the
MBR.

>
> I'm not sure if grub2 completely eliminates the need to have a
> "normal" partition somewhere, in a situation where raid+lvm+etc are
> used.

You do need a filesystem that grub2 can access through some
combination of modules, and an area in which to embed core.img.

The grub2 manual has a pretty good explanation.

http://www.gnu.org/software/grub/manual/html_node/Installing-GRUB-using-grub_002dinstall.html
http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html
http://www.gnu.org/software/grub/manual/html_node/Images.html

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman  wrote:
> On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao  wrote:
>> GRUB2 does away with the conventional stage files. It also wants a
>> special BIOS Boot Partition in order to function. That is where it
>> stores the equivalent of the stage2 bootcode. That is similar to
>> FreeBSD's bootloader.
>
> Now, that should make for a fun migration!  Fortunately I do have a
> separate boot already, and I guess I can be daring and overwrite it in
> place and trust in grub2 to still find the kernel elsewhere.
>
> Those without a separate boot and without any free space are likely to
> find this to be painful.  Resizing partitions isn't exactly
> risk-free...
>
> Rich
>

I think Richard is incorrect here; grub2 can live on any filesystem,
so long as some combination of modules can access it.

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Fri, Jun 29, 2012 at 3:15 PM, Rich Freeman  wrote:
> On Fri, Jun 29, 2012 at 3:01 PM, Mike Gilbert  wrote:
>> 3. grub2-install calls grub2-bios-setup which installs boot.img into
>> the MBR and embeds core.img into the sectors immediately after the
>> MBR.
>
> Ok, that isn't all that unlike grub1 - that is what stage1.5 is.  It
> just sounds like these aren't static files that are copied out of
> /boot/grub, but rather they're built on-demand from other files there.
>  Grub1 figures out which static stage1.5 you need based on where /boot
> is.  They probably went to a more dynamic model so that they can
> support stuff like LVM+MD+LUKS+etc without having every permutation of
> static code.  I'm not sure how smart the bootloader code ends up being
> - it wouldn't surprise me if at time of install the installer does all
> the work and just loads a simple bootloader on the diagnostic cylinder
> with just enough smarts to find /boot if it hasn't changed.

Spot on. :-)

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Fri, Jun 29, 2012 at 4:56 PM, Richard Yao  wrote:
> On 06/29/2012 03:04 PM, Mike Gilbert wrote:
>> On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman  wrote:
>>> On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao  wrote:
>>>> GRUB2 does away with the conventional stage files. It also wants a
>>>> special BIOS Boot Partition in order to function. That is where it
>>>> stores the equivalent of the stage2 bootcode. That is similar to
>>>> FreeBSD's bootloader.
>>>
>>> Now, that should make for a fun migration!  Fortunately I do have a
>>> separate boot already, and I guess I can be daring and overwrite it in
>>> place and trust in grub2 to still find the kernel elsewhere.
>>>
>>> Those without a separate boot and without any free space are likely to
>>> find this to be painful.  Resizing partitions isn't exactly
>>> risk-free...
>>>
>>> Rich
>>>
>>
>> I think Richard is incorrect here; grub2 can live on any filesystem,
>> so long as some combination of modules can access it.
>>
>
> Do you know what function the BIOS Boot Partion serves? It is necessary
> when using GRUB2's ZFS support. I was under the impression that it
> stored boot code.
>

Based on a Google search I think "BIOS Boot Partition" is a GPT thing.
Not relevent if you have an MBR partition table.

Re: [gentoo-dev] grub:2 keywords

[Mike Gilbert]

On Mon, Jul 2, 2012 at 2:57 PM, Jeroen Roovers  wrote:
> On Fri, 29 Jun 2012 15:15:23 -0400
> Rich Freeman  wrote:
>
>> On Fri, Jun 29, 2012 at 3:01 PM, Mike Gilbert 
>> wrote:
>> > 3. grub2-install calls grub2-bios-setup which installs boot.img into
>> > the MBR and embeds core.img into the sectors immediately after the
>> > MBR.
>>
>> Ok, that isn't all that unlike grub1 - that is what stage1.5 is.  It
>> just sounds like these aren't static files that are copied out of
>> /boot/grub, but rather they're built on-demand from other files there.
>>  Grub1 figures out which static stage1.5 you need based on where /boot
>> is.  They probably went to a more dynamic model so that they can
>> support stuff like LVM+MD+LUKS+etc without having every permutation of
>> static code.  I'm not sure how smart the bootloader code ends up being
>> - it wouldn't surprise me if at time of install the installer does all
>> the work and just loads a simple bootloader on the diagnostic cylinder
>> with just enough smarts to find /boot if it hasn't changed.
>
> And if in this complex transition something goes wrong, we could opt
> for the solution Ubuntu provided years ago, which was to add to the
> grub1 boot loader configuration an entry which would call the grub2
> boot loader, so that grub2's correct function could be ascertained
> before the definitive switch to grub2 and removal of the grub1 code.
>

That is exactly what Doug (cardoe) proposed, and he is working on the
docs for that.

Re: [gentoo-dev] base.eclass

[Mike Gilbert]

On Sun, Jul 8, 2012 at 1:54 PM, Ciaran McCreesh
 wrote:
> On Sun, 08 Jul 2012 19:49:25 +0200
> René Neumann  wrote:
>> I'd like just to receive a short clarification about the 'status' of
>> base.eclass: Is this eclass expected to be available everywhere, i.e.
>> should each eclass make sure it imports and incorporates it. Or is it
>> just an eclass like the others and ebuilds should make sure they
>> inherit it if needed?
>
> base.eclass is a historical mistake, from before the design of eclasses
> was fully figured out and moved into the package manager. Unfortunately,
> rather than letting it die, people keep putting things in it and using
> it...

I think it would be a good idea to remove the second sentence of the
description, which is clearly false.

# @DESCRIPTION:
# The base eclass defines some default functions and variables. Nearly
# everything else inherits from here.

Re: [gentoo-dev] RFC: virtual/libudev

[Mike Gilbert]

On Wed, Jul 11, 2012 at 2:26 PM, Thomas Sachau  wrote:
> Michał Górny schrieb:
>> On Tue, 10 Jul 2012 21:23:39 +0200
>> Thomas Sachau  wrote:
>>
>>> Michał Górny schrieb:
 Hello, all.

 Since nowadays udev is bundled within systemd, we start having two
 libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
 the long story short, I would like to introduce a virtual for
 libudev which would pull in either of those two.

 There are three USE flags used in conditionals when depending on
 udev:
 - gudev - for glib wrapper on udev,
 - hwdb - to pull in hwids,
 - static-libs.

 The former two were previously provided by 'extras' USE flag,
 and the third was unconditional.

 I'm attaching an example virtual/libudev which does the job. Sadly,
 because of the 'extras' compatibility it's a big ugly conditional.

 An alternative would be to provide separate virtual/libudev
 and virtual/libgudev; and maybe changing ebuilds not to depend on
 [hwids] but rather pull in sys-apps/hwids directly (since that's
 what the flag does).

 What are you thoughts?
>>>
>>> As discussed on IRC, there is still no consensus for installing the
>>> udev files with systemd, which is the beginning for the block and the
>>> virtual. So we should first sort that point out, before we even start
>>> to think about an ebuild for an udev virtual.
>>
>> Do you have a technical or policy reason prohibiting me from maintaining
>> a systemd ebuild following the upstream policies?
>
> How about this simple one: The udev ebuild does already install udev, so
> why should we have another package also installing the same thing,
> resulting in a blocker, the need to switch from one package to another
> and the need for package maintainers to switch their dependencies?

Just to put a number to this, there are currently 126 packages in the
tree with a dependency on sys-fs/udev.

> Since William already said, that he will move the udev installation to
> /usr/lib, i dont see any technical reason left to not simply depend on
> the udev ebuild.
> And if you fear issues about not knowing which parts to install, then
> just check the files installed by the udev ebuild, remove them from your
> systemd ebuild and you are done.

This means that systemd users end up building the udev components
twice, and throwing away the second copy. You don't seem to care about
this, but I think it is a valid concern.

I am guessing that systemd is or will become very sensitive to any
change in udev's API, so each systemd version would have to depend
exactly on the corresponding udev version. This means that a systemd
version bump could be stuck waiting on the corresponding udev version.

I also wonder if incompatibilities may be introduced by passing
different build options in the udev and systemd ebuilds due to having
different use flags enabled, for example. This can be worked around
with use-deps of course, but it is yet another pain point for the
systemd maintainer.

If there were a way to tell the systemd build system to build against
the "system udev", that might avoid the issue, but I doubt systemd
upstream would implement such a thing.

Personally, I think a consolidated systemd/udev package is the best
way to go here. Short of that, the virtual + blockers seems like an
acceptable solution.

Re: [gentoo-dev] RFC: virtual/libudev

[Mike Gilbert]

On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs  wrote:
> On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote:
>> Just to put a number to this, there are currently 126 packages in the
>> tree with a dependency on sys-fs/udev.
>>
>> Personally, I think a consolidated systemd/udev package is the best
>> way to go here. Short of that, the virtual + blockers seems like an
>> acceptable solution.
>
> Thinking on this, I agree with Mike here, and to make it easier for
> maintainers so they don't have to change their dependencies, it should
> be a udev ebuild with a systemd use flag.
>

An alternative to the funky udev[systemd] solution would be to replace
the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement
the requisite logic in the systemd ebuild. This would effectively make
udev a virtual package without the need to modify any other packages.

Re: [gentoo-dev] rfc: udev-rules.eclass

[Mike Gilbert]

On Thu, Jul 12, 2012 at 3:58 PM, Samuli Suominen  wrote:
> Please don't hardcode the path like this, use pkg-config instead:
>
> inherit toolchain-funcs
>
> dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
>

Heh, I didn't realize udev installed a pkg-config file for that. Nice.

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico  wrote:
> On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> Could be that Portage re-exports a sanitized
>> LINGUAS tough, but I doubt it.
>
> Portage does sanitize it if there are any linguas_* flags in IUSE,
> otherwise it lets the variable pass through without sanitizing it.

That's good; we definitely don't want to "sanitize" it if there are no
linuguas_* flags in IUSE. This would break LINUGUAS support for many
autotools/gettext based packages, where the autotools code parses
LINGUAS directly and the ebuild does nothing with it.

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Thu, Jul 19, 2012 at 2:45 AM, Ben de Groot  wrote:
> Today I would like to present to you my proposal for a new eclass with
> helper functions for treating localizations: l10n.eclass (see the
> attached file or [1]). Its functionality can be used in other eclasses
> (such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
>

In a previous thread, I proposed that the linguas_* use flags should
default to enabled (IUSE="+linguas_en_US ...").

This would cause LINGUAS use-expand behavior to more closely mimic the
behavior of the gettext autoconf macros (/usr/share/aclocal/po.m4).

If LINGUAS is unset, all translations are installed.
If LINGUAS is set a subset of translations are install.
If LINGUAS is set to the empty string, no translations are installed.

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
 wrote:
> On Thu, 19 Jul 2012 18:34:41 -0400
> Mike Gilbert  wrote:
>> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico 
>> wrote:
>> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> Could be that Portage re-exports a sanitized
>> >> LINGUAS tough, but I doubt it.
>> >
>> > Portage does sanitize it if there are any linguas_* flags in IUSE,
>> > otherwise it lets the variable pass through without sanitizing it.
>>
>> That's good; we definitely don't want to "sanitize" it if there are no
>> linuguas_* flags in IUSE. This would break LINUGUAS support for many
>> autotools/gettext based packages, where the autotools code parses
>> LINGUAS directly and the ebuild does nothing with it.
>
> If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
> and will be in future EAPIs. Without that, USE dependencies on
> USE_EXPAND variables don't work.

How do you figure that?

The current portage behavior works well enough; if linugas_* is in
IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
fine.

Otherwise, it is treated just like a normal environment variable, and
portage doesn't touch it.

For most gettext packages, there is absolutely no reason that the
ebuild maintainer should have to keep track of every translation
available in a given package across version bumps. If you change this
behavior in a future EAPI, you will break this.

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh
 wrote:
> On Fri, 20 Jul 2012 12:39:21 -0400
> Mike Gilbert  wrote:
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
>>  wrote:
>> > On Thu, 19 Jul 2012 18:34:41 -0400
>> > Mike Gilbert  wrote:
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico 
>> >> wrote:
>> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> >> Could be that Portage re-exports a sanitized
>> >> >> LINGUAS tough, but I doubt it.
>> >> >
>> >> > Portage does sanitize it if there are any linguas_* flags in
>> >> > IUSE, otherwise it lets the variable pass through without
>> >> > sanitizing it.
>> >>
>> >> That's good; we definitely don't want to "sanitize" it if there
>> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
>> >> for many autotools/gettext based packages, where the autotools
>> >> code parses LINGUAS directly and the ebuild does nothing with it.
>> >
>> > If there aren't any linguas_* flags in IUSE, LINGUAS should be
>> > empty, and will be in future EAPIs. Without that, USE dependencies
>> > on USE_EXPAND variables don't work.
>>
>> How do you figure that?
>
> If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, what
> happens?
>

Firstly, if there are no linugas_ flags in IUSE, I can't see any point
in such a dependency.

Given the current behavior, I believe the dependency would always
satisfied due to the (+). That seems fine to me.

>> The current portage behavior works well enough; if linugas_* is in
>> IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
>> fine.
>>
>> Otherwise, it is treated just like a normal environment variable, and
>> portage doesn't touch it.
>
> It's not a normal environment variable, and it never has been.
>

It was a normal variable before someone added it to USE_EXPAND. From
cvs, it looks like that happened in 2005 or so.

>> For most gettext packages, there is absolutely no reason that the
>> ebuild maintainer should have to keep track of every translation
>> available in a given package across version bumps. If you change this
>> behavior in a future EAPI, you will break this.
>
> Don't use a USE_EXPAND variable if you don't want USE_EXPAND behaviour.
>

I beleive LINGUAS originates from the autoconf macros (po.m4) provided
by the gettext package. I believe we added it to USE_EXPAND some time
after it was implemented in gettext. This "just works" given the
current portage behavior.

Perhaps we need to provide a cleaner way for ebuilds to specify if a
given variable should be treated as a USE_EXPAND or not.

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
 wrote:
> On Thu, 19 Jul 2012 18:34:41 -0400
> Mike Gilbert  wrote:
>> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico 
>> wrote:
>> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> Could be that Portage re-exports a sanitized
>> >> LINGUAS tough, but I doubt it.
>> >
>> > Portage does sanitize it if there are any linguas_* flags in IUSE,
>> > otherwise it lets the variable pass through without sanitizing it.
>>
>> That's good; we definitely don't want to "sanitize" it if there are no
>> linuguas_* flags in IUSE. This would break LINUGUAS support for many
>> autotools/gettext based packages, where the autotools code parses
>> LINGUAS directly and the ebuild does nothing with it.
>
> If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
> and will be in future EAPIs. Without that, USE dependencies on
> USE_EXPAND variables don't work.
>

Do you mean that LINGUAS will be empty, or unset (undefined) in an
ebuild context? The difference is significant here.

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 2:03 PM, Ciaran McCreesh
 wrote:
> On Fri, 20 Jul 2012 13:55:46 -0400
> Mike Gilbert  wrote:
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
>>  wrote:
>> > On Thu, 19 Jul 2012 18:34:41 -0400
>> > Mike Gilbert  wrote:
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico 
>> >> wrote:
>> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> >> Could be that Portage re-exports a sanitized
>> >> >> LINGUAS tough, but I doubt it.
>> >> >
>> >> > Portage does sanitize it if there are any linguas_* flags in
>> >> > IUSE, otherwise it lets the variable pass through without
>> >> > sanitizing it.
>> >>
>> >> That's good; we definitely don't want to "sanitize" it if there
>> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
>> >> for many autotools/gettext based packages, where the autotools
>> >> code parses LINGUAS directly and the ebuild does nothing with it.
>> >
>> > If there aren't any linguas_* flags in IUSE, LINGUAS should be
>> > empty, and will be in future EAPIs. Without that, USE dependencies
>> > on USE_EXPAND variables don't work.
>>
>> Do you mean that LINGUAS will be empty, or unset (undefined) in an
>> ebuild context? The difference is significant here.
>
> For EAPIs before 5, LINGUAS contains *at least* the things in IUSE
> intersected with the ones the user has enabled, with the linguas_
> stripped. It's not just "the environment variable in make.conf", since a
> user might put linguas_en in package.use.
>
> For EAPIs 5 and onwards, LINGUAS contains only those things, and
> definitely won't contain anything else.

Let me rephrase my question: If the user has not enabled any of the
linguas flags via make.conf or package.use, will the LINGUAS variable
be empty or unset in the ebuild environment?

Re: [gentoo-dev] UTF-8 locale by default

[Mike Gilbert]

On Wed, Aug 1, 2012 at 8:20 PM, Walter Dnes  wrote:
> We're ignoring a very basic question here... what problems does
> shipping with a POSIX locale cause that would be fixed by setting a UTF8
> default locale???  I want a real answer.  Not something along the lines
> of "But daddy, all the other kids are doing it".
>

Try reading the rest of the thread before posting a rant.

Diego mentioned the python issue. As well, there are many test suites
that malfunction without a UTF-8 or en_US.UTF-8 locale. If you hunt
through Bugzilla, you can probably dig up other issues.

Re: [gentoo-dev] UTF-8 locale by default

[Mike Gilbert]

On Thu, Aug 2, 2012 at 2:21 PM, Diego Elio Pettenò
 wrote:
> On 01/08/2012 23:42, Fabian Groffen wrote:
>> Honestly, if some asian person has whatever charset that I often find in
>> spam messages, but is not UTF-8, are you then going to tell that person
>> to switch to UTF-8 to get those python packages emerged?  I hope not.
>
> Tell that to the Python team I guess. My tinderbox _has_ utf8 locales
> available, but doesn't set in by default -> Python stuff fails to build
> or test -> not going to be fixed with "change your locale" reasoning.
>
> Is it mental? Yes.
> Would I like that to change? Yes.
> Do I care ẃhether that's through the use of cluebyfour on the Python
> team or by setting an utf-8 locale by default? Not in the least.
>

Please apply the cluebyfour to the upstream developers of python and
python modules. :-)

I do try to fix unicode problems if I run into them. However,
sometimes it just isn't worth the effort.

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Mike Gilbert]

On Sun, Aug 12, 2012 at 8:25 AM, Rich Freeman  wrote:
> I think that people get this confused because 99% of linux users have
> an initramfs (and about 2% of Gentoo users it seems), and most
> initramfs implementations DO interpret the root=parameter.  If you
> specify an initramfs then the kernel actually ignores the
> root=parameter entirely, mounting the initramfs as root, and passing
> control to its init.  The initramfs is expected to mount root (or not
> - you could just run the whole system off an initramfs I guess).  Most
> initramfs implementations just parse the root= line on the kernel,
> although it is worth noting that genkernel's initramfs does not and
> uses real_root instead.

Small correction: genkernel's /init script accepts both real_root and
root on the kernel command line. If real_root is not specified, the
value of root is used.

It seems that the real_root option is a remnant of the initrd (not
intramfs) code, where root needed to be a ram disk (/dev/ram0). With
initramfs, the kernel ignores root, so we are free to use it for
specifying the actual root device.

So, when you see grub2-mkconfig generating entries with root=...,
please do not panic; this works just fine. :-)

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Mike Gilbert]

On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
 wrote:
> On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote:
>> Beside the fact that these would probably have looked better in
>> /usr/libexec
>
> See Kay Sievers's comment at
> https://bugs.freedesktop.org/show_bug.cgi?id=51617 :
>
> "/usr/lib// is a directory like /usr/libexec/ or even /bin. It
> shares absolutely zero things with the arch-specific $libdir ,or lib64/.
>
> /usr/lib// is the canonical "application private directory". It
> has the multi-lib or arch-specific rules as /bin.
>

So... where should GRUB2 be installing its modules? Currently they get
installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and
platform are determined by use flags.

Should we drop the get_libdir and put them in /usr/lib/grub instead?
Should I even worry about it?

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

[Mike Gilbert]

On Tue, Aug 28, 2012 at 4:06 AM, Michał Górny  wrote:
> On Tue, 28 Aug 2012 06:26:02 +0200
> Arfrever Frehtes Taifersar Arahesis  wrote:
>
>> 2012-08-28 00:19:28 Michał Górny napisał(a):
>> > --- /dev/null
>> > +++ b/gx86/eclass/boost-utils.eclass
>> > @@ -0,0 +1,43 @@
>> > +# Copyright 1999-2012 Gentoo Foundation
>> > +# Distributed under the terms of the GNU General Public License v2
>> > +# $Header: $
>> > +
>> > +if [[ ! ${_BOOST_ECLASS} ]]; then
>> > +
>> > +# @ECLASS: boost-utils.eclass
>> > +# @MAINTAINER:
>> > +# mgo...@gentoo.org
>>
>> It is better to copy list of maintainers from
>> gentoo-x86/dev-libs/boost/metadata.xml.
>>
>> > +# @BLURB: helper functions for packages using Boost C++ library
>> > +# @DESCRIPTION:
>> > +# Helper functions to be used when building packages using the
>> > Boost C++ +# library collection.
>> > +
>> > +case ${EAPI:-0} in
>> > +   0|1|2|3|4) ;;
>> > +   *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
>> > established." +esac
>>
>> Please accept all EAPIs.
>
> These are EAPIs which are allowed throughout the tree, sorry. Feel free
> to ping Council about adding non-standard EAPIs to eclasses.
>

Is the eclass likely to be incompatible with future EAPIs? If not, I
think it is reasonable to remove this check.

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Mike Gilbert]

On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Thus, not adding it to @system in no way means it's not considered
> mandatory for a normal install, it just means the ultimate goal is to
> have all the deps specified and nothing left in @system, and while
> progress isn't fast by a long shot, the first thing is to ensure we're
> not regressing!
>

If the ultimate goal is to eliminate @system entirely (which it
probably isn't), we will need to revisit the way stage building works.
If understand correctly, a stage3 contains @system and its
dependencies.

The smallest you can really make @system under that circumstance would
be a working toolchain and the utilities necessary to build any other
needed packages. I think that is the goal that most people have been
shooting for lately.

Re: [gentoo-dev] EAPI usage

[Mike Gilbert]

On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky  wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
>>>
>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>>> are valid. If someone would benefit from such a bump, he can file a bug
>>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>>> under no more pressure than usual to do the bump.
>>
>> If you attach a patch and have done the legwork, sure.
>>
>> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
>> noise and it's annoying.  EAPI bump requests for pkgs that need to
>> move forward so an eclass can be cleaned up/moved forward, sure, but
>> arbitrary "please go bump xyz" without a specific reason (and/or
>> legwork done if not) isn't helpful.  Kind of equivalent to zero-day
>> bump requests in my view in terms of usefulness.
>
> Except this is what we have now, and isn't a compromise at all.
>

What use is a bug report requesting an EAPI bump for no reason? There
is no sense in "compromising" and creating such a policy if nobody
actually benefits from it.

Re: [gentoo-dev] bzr.eclass changes, please review

[Mike Gilbert]

On Fri, Sep 14, 2012 at 12:12 PM, Rick "Zero_Chaos" Farina
 wrote:
> I didn't mean to pick on bzr.eclass, I think it's always wrong to do
> this.  And you picked out the exact reasoning I did "I'm not sure if it
> would be worth the effort to compute a more accurate argument for
> addwrite." I think it is worth the effort to do it right.  I mean
> (purposeful exaggeration here) we could save the addwrite entirely by
> just "killall sandbox" or we could prevent from reoccurring by
> restricting the sandbox feature. Any time you do "addwrite /" you
> completely defeat the entire purpose of sandbox.  It's not write (get it?).
>
> I'm not saying this is an emergency nor should it hold back any changes
> you need to make to argue with me about it. However, if you were to do
> it right that would be cool. Otherwise we could all start fixing our
> sandbox issues by just doing "addwrite /" at the top of all ebuilds.
>

The sandbox is mostly useful to prevent build systems from messing
with the live system without the developer's knowledge. It is
perfectly reasonable to disable the sandbox for a single mkdir call
that we have direct control over.

Re: [gentoo-dev] DESCRIPTION="Based on the ${ECLASS} eclass"

[Mike Gilbert]

On Fri, Sep 14, 2012 at 7:43 PM, Rick "Zero_Chaos" Farina
 wrote:
> So just so we are clear, everyone but me thinks that DESCRIPTION="Based
> on the ${ECLASS} eclass" is a completely useful and critically required
> piece of code?
>

I don't think anyone really cares, and it doesn't seem like anyone is
going to get in your way if you want to remove it. Maybe ping each
maintainer, and proceed if they don't object.

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Mike Gilbert]

On Wed, Sep 26, 2012 at 5:59 PM, Michael Mol  wrote:
> On Wed, Sep 26, 2012 at 5:49 PM, Chí-Thanh Christopher Nguyễn
>  wrote:
>> Michael Mol schrieb:
>>> A few months ago, I filed bug 423651 to ask that bzip2 on the install
>>> media be replaced with
>>>  pbzip2.
>>
>> If I understand correctly, pbzip2 depends on bzip2. So what you are
>> asking is that pbzip2 is preferred over bzip2 when both are installed,
>> and that pbzip2 is installed by default?
>
> pbzip2 uses libbzip2, which I understand bzip2 to also be a wrapper around.
>

libbz2 is built and installed by the app-arch/bzip2 package. Thus,
app-arch/pbzip2 depends on app-arch/bzip2, unless someone rips libbz2
out into a separate ebuild.

Re: [gentoo-dev] Let's populate IUSE_IMPLICIT in the base profile

[Mike Gilbert]

On Thu, Sep 13, 2012 at 1:40 AM, Zac Medico  wrote:
> Hi,
>
> The council has approved [1] "Profile IUSE injection" [2] for inclusion
> in EAPI 5, and in latest Portage we have experimental EAPI 5_pre2 [3]
> which implements all of the approved features. So, now would be a good
> time to start populating IUSE_IMPLICIT with whatever values may be
> appropriate.
>
> What values belong there? Some of the flags that appear in
> profiles/base/use.mask might make good candidates, such as prefix and
> selinux. How about other special flags like bootstrap, build, and test?
>

prefix and test make sense to me. I'm not so familiar with the others.

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

[Mike Gilbert]

On Sun, Sep 30, 2012 at 11:44 AM, Gilles Dartiguelongue  wrote:
> Le mercredi 19 septembre 2012 à 10:19 +0200, Michał Górny a écrit :
>>
>> Just to make it clear:
>> - USE=upnp for upnp-igd or nat-pmp,
>> - USE=dlna for the video magic and so on.
>>
>> Do I understand correctly?
>
> No, TV makers and others advertise UPnP as DLNA (digital living network
> appliance) but that actually refers to both port forwarding (eg. used in
> consoles) and to media streaming (eg. PC to TV).
>
> Both flags should most likely start with dlna, then we need to figure
> out a suffix :)
>
> I propose dlna-av and dlna-network.
>
> See [1] if somebody else feels inspired.
>
> [1]
> http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance#DLNA_technology_components
> --
> Gilles Dartiguelongue 
> Gentoo
>
>

Personally, I would prefer that the USE flags be named for the
protocol/feature they enable (upnp-foo) rather than the organization
that certifies devices (dlna-foo). Maybe I'm over-simplifying.

Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc

[Mike Gilbert]

On Fri, Oct 12, 2012 at 4:18 AM, Rich Freeman  wrote:
> On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras  wrote:
>> +1. I want these profiles to *staty*. I am using this profile on my
>> "home boxes". It is the most minimal profile as the rest of the
>> profiles pull in too much useless stuff. What is wrong with these
>> profiles anyway?
>
> Looking at the actual profiles themselves, using server vs the base
> profile makes these changes:
> USE="-perl -python snmp truetype xml"
>

perl and python have not been enabled in the default/linux profile for
some time now:

RCS file: /var/cvsroot/gentoo-x86/profiles/default/linux/make.defaults,v

revision 1.15
date: 2011-10-05 15:22:13 -0400;  author: darkside;  state: Exp;
lines: +2 -2;  commitid: 2e764e8cae624567;
Remove USE={python,perl} from default profile, as discussed/announced.
Bug 250179

Disabling those flags in the server profile is redundant.

[gentoo-dev] Re: reworking python-wrapper and wrapper scripts.

[Mike Gilbert]

On Thu, Oct 18, 2012 at 5:15 AM, Brian Harring  wrote:
> If folks haven't looked at python_generate_wrapper_scripts in
> python.eclass, I'd suggest doing so.  For examples of it's usage, grep
> for 'python_generate_wrapper_scripts' in /usr/bin/; any place you see
> it, look for -${PYTHON_TARGETS} (for example,
> /usr/bin/sphinx-build{,-2.7,-3.2}.
>
> Each usage there is a separate custom script for that specific binary;
> if there is a bug in the script, well, we're screwed- requires
> re-merging the package.
>
> This setup, at least on my hardware, is .04s added to every
> invocation; this is ignoring the inode cost for each, and the issue if
> a bug ever appears in the script generation code (in which case we're
> screwed- would require re-merging the package).
>
> In parallel, we've got python-wrapper (ls /usr/bin/python -l); this is
> provided by eselect-python and basically discern what the active
> python version is, and use that in the absense of any directives.
> This is implemented in C, and is reasonably sane; the overhead for
> that is basically non-existant.
>
> Roughly, I'm proposing we do away with python eclass's
> generate_python_wrapper_scripts generation of a script, instead having
> that just symlink to a binary provided by eselect-python that handles
> this.  This centralizes the implementation (fix in one spot), and
> would allow a c version to be used- basically eliminating the
> overhead.
>
>
> There's a trick to this; currently, those generated scripts hardcode
> the allowed/known python versions for that package.  We obviously have
> to preserve that; I propose we shove it into the symlink path.
>
> Basically, we add a /usr/libexec/python directory; within it, we have
> a wrapper binary (explained below), and a set of symlinks pointing at
> the root of that directory.  To cover our current python versions, the
> following would suffice:
>
> for x in {2.{4,5,6,7},3.{0,1,2,3,4}}-cpy 2.5-jython 2.7-pypy-1.{7,8}
> \2.7-pypy-1.9; do
>   ln -s ./ /usr/libexec/python/$x
> done
>
> While that seems insane, there is a reason; via that, we can encode
> the allowed versions into the symlink.  Using pkgcore's pquery for
> example (which should support cpy: 2.5, 2.6, 2.7, 3.1, 3.2, 3.3)
> instead of a wrapper script at /usr/bin/pquery, we'd have thus:
>
> targets=( 2.{5,6,7}-cpy 3.{1,2,3}-cpy )
> targets=$(IFS=/;echo -n "${targets[*]}")
> # This results in
> # targets=2.5-cpy/2.6-cpy/2.7-cpy/3.1-cpy/3.2-cpy/3.3-cpy
> ln -s "/usr/libexec/python/${targets}/wrapper" \
>   /usr/bin/pquery
>
> /usr/libexec/python/wrapper upon invocation, takes a look at argv[0];
> sees how it was invoked basically.  This will be the /usr/bin/whatever
> pathway.  It reads the symlink, in the process getting the allowed
> versions and preferred order of the versions.
>
> Few notes; vast majority of filesystems will store the symlink target
> into the core inode if at all possible- in doing so, this avoids
> wasting an inode and is only limited by the length of the target.
> That length is capped by PATH_MAX- which can range from 256 to 4k (or
> higher).
>
> For the pquery example above, that comes out to ~73 bytes for the
> symlink pathway; well under PATH_MAX.
>
> For the scenarios where PATH_MAX caps the symlink pathway, or for
> whatever reason we don't want to use that trick, a tree of files
> contained within /usr/libexec/python/ holding the allowed versions for
> the matching pathway would suffice.
>
> Either proposal here would be far faster than what we've got now; also
> will use less space (ancillary benefit).
>
> One subtle aspect here is that if we did this, it makes it possible to
> avoid losing the invocation information- currently if you did
> `/usr/bin/python3.2 $(which sphinx-build) blah`, because of how things
> are implemented now (specifically the two layers of wrappers)- you'll
> get python2.7 running that sphinx-build invocation.
>
> This is wrong (it's directly discarding what the invocation
> requested), although you're only going to see it for scripts that
> do python introspection.
>
> Via doing the restructuring I'm mentioning above, that issue can be
> fixed, while making things faster/saner.
>
> On a related note; we currently install multiple versions of the same
> script- the only difference being the shebang.  If one ignores the
> shebang, in some cases this is necessary- where the script is 2to3
> translated, and the code for py2k vs py3k differs.  For most, the only
> difference is in the shebang however.
>
> While it's minor in space savings, it's possible to eliminate that
> redundancy via a shebang target that looks at the pathway it was
> invoked via.  Fairly easy actually, and basically zero overhead if
> done.
>
> Either way, thoughts?
>
> What I'm proposing isn't perfect, but I'm of the view it's a step up
> from what's in place now- and via centralizing this crap, makes it
> easier to change/maintain this going forward as necessary.
> ~harring

If we are somehow going to elimi

[gentoo-dev] Re: reworking python-wrapper and wrapper scripts.

[Mike Gilbert]

On Thu, Oct 18, 2012 at 3:29 PM, Brian Harring  wrote:
> On Thu, Oct 18, 2012 at 11:28:59AM -0400, Mike Gilbert wrote:
>> Regarding your /usr/bin/python3.2 /usr/bin/sphinx-build example:
>> invoking python on a binary (or a symlink to a binary) isn't going to
>> work at all. So I don't see how you've solved that issue.
>
> Kindly provide reasoning/justification for such a claim in the future-
> saves a round of email ping/ponging, and saves me getting pissy
> towards people if they persist in it. :)
>
> Lecture aside, "nuh uh, it does work!" is appropriate.  I already
> hacked up a prototype locally that works fine and does this via an
> env passing hack- w/ what was proposed, this can be done w/out those
> hacks, and would be faster.
>

When you invoke a command like:

/usr/bin/python3.2 /usr/bin/somebinary

The python3.2 program assumes somebinary is a python script and tries
to parse it. Since somebinary is actually an ELF object, python bombs
out immediately.

Am I missing something fundamental here?

[gentoo-dev] Re: reworking python-wrapper and wrapper scripts.

[Mike Gilbert]

On Thu, Oct 18, 2012 at 4:50 PM, Mike Gilbert  wrote:
> On Thu, Oct 18, 2012 at 3:29 PM, Brian Harring  wrote:
>> On Thu, Oct 18, 2012 at 11:28:59AM -0400, Mike Gilbert wrote:
>>> Regarding your /usr/bin/python3.2 /usr/bin/sphinx-build example:
>>> invoking python on a binary (or a symlink to a binary) isn't going to
>>> work at all. So I don't see how you've solved that issue.
>>
>> Kindly provide reasoning/justification for such a claim in the future-
>> saves a round of email ping/ponging, and saves me getting pissy
>> towards people if they persist in it. :)
>>
>> Lecture aside, "nuh uh, it does work!" is appropriate.  I already
>> hacked up a prototype locally that works fine and does this via an
>> env passing hack- w/ what was proposed, this can be done w/out those
>> hacks, and would be faster.
>>
>
> When you invoke a command like:
>
> /usr/bin/python3.2 /usr/bin/somebinary
>
> The python3.2 program assumes somebinary is a python script and tries
> to parse it. Since somebinary is actually an ELF object, python bombs
> out immediately.
>
> Am I missing something fundamental here?

Oh, perhaps you are suggesting that /usr/bin/python3.2 would no longer
be the actual python binary, but instead be a link to your wrapper
program? It's really not clear to me.

[gentoo-dev] Maintainer needed: dev-libs/icu

[Mike Gilbert]

This library is used for processing Unicode text in several high-profile
packages, including Chromium and other Webkit browsers, PHP, boost, and
many more.

Fair warning: ICU tends to break several packages with every major
release, so thorough testing is needed when bumping it.

This package is currently being maintained by proxy by a former Gentoo
developer, Arfrever. Given this package's potential to cause problems,
this situation is not ideal.

It would be really great if an active Gentoo developer would step
forward and take care of this one.

--
Mike Gilbert



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS

[Mike Gilbert]

On Mon, Oct 29, 2012 at 10:45 AM, Michał Górny  wrote:
> Hello,
>
> Since some ebuilds are using that variable already and we still didn't
> inform most of our users if and how they should set it, I'd like to
> commit the following news item:
>
> Title: PYTHON_TARGETS deployment
> Author: Michał Górny 
> Content-Type: text/plain
> Posted: 2012-10-29
> Revision: 1
> News-Item-Format: 1.0
>
> Lately, a new Python eclasses were deployed and the way of supporting
> multiple Python implementations changes with ebuilds being migrated
> to them. While before the implementations being installed were used
> by default, the migrated packages will instead use explicit choice based
> on PYTHON_TARGETS USE flags. This may require action from some of our
> users.
>
> If you are running a modern system with Python 2.7 & 3.2, and you didn't
> set USE_PYTHON, then you don't have to do anything. The defaults
> will fit you.
>
> Otherwise, you will want to set PYTHON_TARGETS in your make.conf file.
> This is a regular USE_EXPAND variable listing requested Python
> implementations like:
>
> PYTHON_TARGETS="python2_7 python3_2 pypy1_9 jython2_5"
>
> The variable should list all requested Python implementations.
> A complete list of possible values can be obtained using a command like:
>
> emerge -1pv dev-python/python-exec
>

Good idea to inform users.

Is there a way to have this news item go away, say after a year or so?
Every time I do a fresh install, I get hit with a couple of
"perpetual" news items, and it is a little annoying.

Re: [gentoo-dev] Maintainer needed: dev-libs/icu

[Mike Gilbert]

On Mon, Oct 29, 2012 at 3:33 PM, Christoph Junghans  wrote:
> 2012/10/29 Diego Elio Pettenò :
>> On 29/10/2012 10:37, Christoph Junghans wrote:
>>> If Arfrever keeps maintaining it for a while, I will take it.
>>
>> Do remember that whatever you commit, _You_ take responsibility for it.
>> After a screwup, the answer "I didn't do anything, I just committed what
>> Arfrever gave me" is not a good answer.
> Ok, I should have been more precise here. I will take it, but as I am
> new to the insides of icu, it will take me a bit to
> understand/fix/workaround it's issues and for that time having
> Arfrever will be more than useful.
>

Arfrever will probably continue to send patches, but we need someone
who can dig in deeper than I have been. Just make sure you verify and
test everything he sends you, and have someone with a tinderbox test
it on version bumps.

I'm also happy to help in whatever way I can, other than having my
name attached to it. :-)

[gentoo-dev] Re: [PATCH] Check for USE_PYTHON <-> PYTHON_TARGETS equiv.

[Mike Gilbert]

On Mon, Nov 5, 2012 at 6:59 AM, Michał Górny  wrote:
> ---
>  gx86/eclass/python-r1.eclass | 66 
> 
>  1 file changed, 66 insertions(+)
>
> diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
> index 0d6ef4c..6d4eb33 100644
> --- a/gx86/eclass/python-r1.eclass
> +++ b/gx86/eclass/python-r1.eclass
> @@ -363,6 +363,70 @@ python_copy_sources() {
> done
>  }
>
> +# @FUNCTION: _python_check_USE_PYTHON
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Check whether USE_PYTHON and PYTHON_TARGETS are in sync. Output
> +# warnings if they are not.
> +_python_check_USE_PYTHON() {
> +   if [[ ! ${_PYTHON_USE_PYTHON_CHECKED} ]]; then
> +   _PYTHON_USE_PYTHON_CHECKED=1
> +
> +   local USE_PYTHON=${USE_PYTHON}
> +
> +   if [[ ! ${USE_PYTHON} ]]; then
> +   # default to selected Python2+3
> +   if has_version app-admin/eselect-python; then
> +   local py2=$(eselect python show --python2)
> +   local py3=$(eselect python show --python3)
> +
> +   USE_PYTHON="${py2#python} ${py3#python}"
> +   fi
> +   fi
> +
> +   local impl warned
> +   for impl in "${PYTHON_COMPAT[@]}"; do
> +   local abi
> +   case "${impl}" in
> +   python*)
> +   abi=${impl#python}
> +   ;;
> +   jython*)
> +   abi=${impl#jython}-jython
> +   ;;
> +   pypy*)
> +   abi=2.7-pypy-${impl#pypy}
> +   ;;
> +   *)
> +   die "Unexpected Python 
> implementation: ${impl}"
> +   ;;
> +   esac
> +
> +   has "${abi/_/.}" ${USE_PYTHON}
> +   local has_abi=${?}
> +   use "python_targets_${impl}"
> +   local has_impl=${?}
> +
> +   if [[ ${has_abi} != ${has_impl} ]]; then
> +   if [[ ! ${warned} ]]; then
> +   ewarn "PYTHON_TARGETS <-> USE_PYTHON 
> inconsistency found. This may result"
> +   ewarn "in missing modules when trying 
> to use Python packages. Please ensure"
> +   ewarn "that the same implementations 
> are listed in both variables."
> +   ewarn
> +
> +   warned=1
> +   fi
> +
> +   if [[ ${has_abi} == 0 ]]; then
> +   ewarn "Implementation ${impl} 
> disabled but ${abi/_/.} in USE_PYTHON"
> +   else
> +   ewarn "Implementation ${impl} enabled 
> but ${abi/_/.} not in USE_PYTHON"
> +   fi
> +   fi
> +   done
> +   fi
> +}
> +
>  # @FUNCTION: python_foreach_impl
>  # @USAGE:  [...]
>  # @DESCRIPTION:
> @@ -376,6 +440,8 @@ python_copy_sources() {
>  python_foreach_impl() {
> debug-print-function ${FUNCNAME} "${@}"
>
> +   _python_check_USE_PYTHON
> +
> local impl
> local bdir=${BUILD_DIR:-${S}}
>
> --
> 1.7.12.4
>

We should not encourage users to set USE_PYTHON if it has not been set
already; the variable is pretty much undocumented, and should probably
stay that way. If USE_PYTHON is unset, we should advise them to update
PYTHON_TARGETS to match their active python2 and python3 versions
(from eselect python).

Re: [gentoo-dev] Re: [PATCH] Check for USE_PYTHON <-> PYTHON_TARGETS equiv.

[Mike Gilbert]

On Mon, Nov 5, 2012 at 10:32 AM, Michał Górny  wrote:
> On Mon, 5 Nov 2012 10:22:22 -0500
> Mike Gilbert  wrote:
>
>> On Mon, Nov 5, 2012 at 6:59 AM, Michał Górny  wrote:
>> > ---
>> >  gx86/eclass/python-r1.eclass | 66 
>> > 
>> >  1 file changed, 66 insertions(+)
>> >
>> > diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
>> > index 0d6ef4c..6d4eb33 100644
>> > --- a/gx86/eclass/python-r1.eclass
>> > +++ b/gx86/eclass/python-r1.eclass
>> > @@ -363,6 +363,70 @@ python_copy_sources() {
>> > done
>> >  }
>> >
>> > +# @FUNCTION: _python_check_USE_PYTHON
>> > +# @INTERNAL
>> > +# @DESCRIPTION:
>> > +# Check whether USE_PYTHON and PYTHON_TARGETS are in sync. Output
>> > +# warnings if they are not.
>> > +_python_check_USE_PYTHON() {
>> > +   if [[ ! ${_PYTHON_USE_PYTHON_CHECKED} ]]; then
>> > +   _PYTHON_USE_PYTHON_CHECKED=1
>> > +
>> > +   local USE_PYTHON=${USE_PYTHON}
>> > +
>> > +   if [[ ! ${USE_PYTHON} ]]; then
>> > +   # default to selected Python2+3
>> > +   if has_version app-admin/eselect-python; then
>> > +   local py2=$(eselect python show --python2)
>> > +   local py3=$(eselect python show --python3)
>> > +
>> > +   USE_PYTHON="${py2#python} ${py3#python}"
>> > +   fi
>> > +   fi
>> > +
>> > +   local impl warned
>> > +   for impl in "${PYTHON_COMPAT[@]}"; do
>> > +   local abi
>> > +   case "${impl}" in
>> > +   python*)
>> > +   abi=${impl#python}
>> > +   ;;
>> > +   jython*)
>> > +   abi=${impl#jython}-jython
>> > +   ;;
>> > +   pypy*)
>> > +   abi=2.7-pypy-${impl#pypy}
>> > +   ;;
>> > +   *)
>> > +   die "Unexpected Python 
>> > implementation: ${impl}"
>> > +   ;;
>> > +   esac
>> > +
>> > +   has "${abi/_/.}" ${USE_PYTHON}
>> > +   local has_abi=${?}
>> > +   use "python_targets_${impl}"
>> > +   local has_impl=${?}
>> > +
>> > +   if [[ ${has_abi} != ${has_impl} ]]; then
>> > +   if [[ ! ${warned} ]]; then
>> > +   ewarn "PYTHON_TARGETS <-> 
>> > USE_PYTHON inconsistency found. This may result"
>> > +   ewarn "in missing modules when 
>> > trying to use Python packages. Please ensure"
>> > +   ewarn "that the same 
>> > implementations are listed in both variables."
>> > +   ewarn
>> > +
>> > +   warned=1
>> > +   fi
>> > +
>> > +   if [[ ${has_abi} == 0 ]]; then
>> > +   ewarn "Implementation ${impl} 
>> > disabled but ${abi/_/.} in USE_PYTHON"
>> > +   else
>> > +   ewarn "Implementation ${impl} 
>> > enabled but ${abi/_/.} not in USE_PYTHON"
>> > +   fi
>> > +   fi
>> > +   done
>> > +   fi
>> > +}
>> > +
>> >  # @FUNCTION: python_foreach_impl
>> >  # @USAGE:  [...]
>> >  # @DESCRIPTION:
>> > @@ -376,6 +440,8 @@ python_copy_sources() {
>> >  python_foreach_impl() {
>> > debug-print-function ${FUNCNAME} "${@}"
>> >
>> > +   _python_check_USE_PYTHON
>> > +
>> > local impl
>> > local bdir=${BUILD_DIR:-${S}}
>> >
>> > --
>> > 1.7.12.4
>> >
>>
>> We should not encourage users to set USE_PYTHON if it has not been set
>> already; the variable is pretty much undocumented, and should probably
>> stay that way. If USE_PYTHON is unset, we should advise them to update
>> PYTHON_TARGETS to match their active python2 and python3 versions
>> (from eselect python).
>
> As in change the output in !USE_PYTHON branch? Something like 'please
> set PYTHON_TARGETS or eselect new python'?
>

Yep, that sounds good to me.

Re: [gentoo-dev] [PATCH] Check for USE_PYTHON <-> PYTHON_TARGETS equiv.

[Mike Gilbert]

On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring  wrote:
> On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
>> And in case anyone wondered, the output looks like this:
>>
>>  * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
>>  * in missing modules when trying to use Python packages. Please ensure
>>  * that the same implementations are listed in both variables.
>>  *
>>  * Implementation python2_5 disabled but 2.5 in USE_PYTHON
>>  * Implementation python3_1 disabled but 3.1 in USE_PYTHON
>>  * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON
>
> If you're going to complain to users about flags being disabled in
> USE_PYTHON, use the actual flag name.
>

Those are the correct flag names.

> Also... hopefully you typo'd, but 2.5-jython?  Where was it decided
> the naming there was being shifted around?  None of the code in the
> eclasses backs that text up from what I can tell.
>

That's no typo.

2.5-jython is the PYTHON_ABI from python.eclass. It means "version 2.5
of the python language as implemented by jython". The intent is to
allow for it to be matched by a glob pattern like "2.*" in
RESTRICT_PYTHON_ABIS.

We have basically abandoned the PYTHON_ABI concept with the new
eclass. Instead, we have values in PYTHON_TARGETS, which match up to
an implementation and version. For example: jython2_5, for
dev-java/jython-2.5.

> As floppym said; this flag isn't documented, so you're making it
> fairly hard to actually comment/review on what you're doing here- we
> just see glimpses of random patches, without knowing exactly what you
> intend overall.
>

I think the scope of people who can review this is limited to those
that have some understanding of how python.eclass functions; a limited
subset indeed. ;-)

USE_PYTHON is a variable in python.eclass that python devs use to
install python packages for any arbitrary python implementation,
without using eselect python. sys-apps/portage knows nothing about it,
and your typical user doesn't do anything with it.

PYTHON_TARGETS is a similar variable that was introduced in python-r1
(python-distutils-ng actually). It is a use-expanded variable so that
portage can actually use its values for dependency resolution.

> Documenting your end goal (moving people to USE_PYTHON? etc) is kind
> of necessary; normal rules of review reply, you want reviews, you make
> sure your reviewers know wtf you're trying to do and ultimately why.
>

The end goal here is to migrate ebuilds to PYTHON_TARGETS. We can't
migrate every package in the tree at once, so this check is being
proposed to ensure that the user's settings for python.eclass
(USE_PYTHON or eselect python --python{2,3}) and python-r1.eclass
(PYTHON_TARGETS use-expand) match up.

If they are out-of-sync, users may get build errors about missing
modules. For instance, if dev-python/setuptools is installed with
PYTHON_TARGETS="python2_7", but the user has python3.2 selected via
eselect, they may get an error when they try to install packages using
python.eclass if they depend on dev-python/setuptools.

As we migrate more python libraries to python-r1, we can utilize
use-deps to move this into the dependency resolver. This is something
that was not possible with the old python.eclass.

Re: [gentoo-dev] [PATCH] Check for USE_PYTHON <-> PYTHON_TARGETS equiv.

[Mike Gilbert]

On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring  wrote:
> On Mon, Nov 05, 2012 at 05:50:24PM -0500, Mike Gilbert wrote:
>> On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring  wrote:
>> > On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
>> >> And in case anyone wondered, the output looks like this:
>> >>
>> >>  * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
>> >>  * in missing modules when trying to use Python packages. Please ensure
>> >>  * that the same implementations are listed in both variables.
>> >>  *
>> >>  * Implementation python2_5 disabled but 2.5 in USE_PYTHON
>> >>  * Implementation python3_1 disabled but 3.1 in USE_PYTHON
>> >>  * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON
>> >
>> > If you're going to complain to users about flags being disabled in
>> > USE_PYTHON, use the actual flag name.
>> >
>>
>> Those are the correct flag names.
>
> Use flags can't have '.' in them, so no, that's not the correct flag
> name; if you're going to tell folk "blah is not in USE_PYTHON", be
> *accurate*- meaning dropp the /_/./ substitution.
>

USE_PYTHON does not enumerate USE flags. It contains a list of PYHTON_ABIs.

>
>> > Also... hopefully you typo'd, but 2.5-jython?  Where was it decided
>> > the naming there was being shifted around?  None of the code in the
>> > eclasses backs that text up from what I can tell.
>> >
>>
>> That's no typo.
>>
>> 2.5-jython is the PYTHON_ABI from python.eclass. It means "version 2.5
>> of the python language as implemented by jython". The intent is to
>> allow for it to be matched by a glob pattern like "2.*" in
>> RESTRICT_PYTHON_ABIS.
>
> I'd forgotten that python eclass has PYTHON_ABI it ordered w/ the
> python version first.
>
>
>> > As floppym said; this flag isn't documented, so you're making it
>> > fairly hard to actually comment/review on what you're doing here- we
>> > just see glimpses of random patches, without knowing exactly what you
>> > intend overall.
>> >
>>
>> I think the scope of people who can review this is limited to those
>> that have some understanding of how python.eclass functions; a limited
>> subset indeed. ;-)
>
> Y'all want reviews, then you need to help your reviewers.  Really is
> that simple.
>
> Plus, bluntly, nobody wants another scenario of python.eclass w/ no
> one understanding it.
>
> Meaning what y'all are trying to develop/push, has to be
> documented/understood by everyone.  Strongly suspect this is why there
> isn't any real review occurring for these patches coming in- no one
> particularly knows wtf y'all are going with this.
>
>
>> USE_PYTHON is a variable in python.eclass that python devs use to
>> install python packages for any arbitrary python implementation,
>> without using eselect python. sys-apps/portage knows nothing about it,
>> and your typical user doesn't do anything with it.
>
> Eh, two things;
>
> 1) info_vars; portage actually does report on it for emerge --info.
> If it's internal (no users should be setting it), then you should
> revert your addition of it to info_vars.
>

That's intended for use in bug reports, so members of the python team
can confirm the user's configuration. When I say it is to be used by
devs, I mean that developers and "power users" set it in make.conf,
not that it is set in ebuids.

> 2) nothing in the tree actually uses it.  Literally, niadda- just a
> dead code section in python.eclass hinged on the var being exported.
> Raising the question of why y'all are adding error reporting for this,
> and what this is supposed to sort.
>

Every ebuild in the tree which inherits python.eclass and sets
SUPPORT_PYTHON_ABIS utilizes USE_PYTHON if it has been set in the
environment or in make.conf. I think you misinterpreted my meaning
here.

> Not particularly digging the fact this warning y'all want to add is
> ran everytime python_foreach_impl is fired also; meaning this will
> spam logs if it ever hits.
>
>
>> > Documenting your end goal (moving people to USE_PYTHON? etc) is kind
>> > of necessary; normal rules of review reply, you want reviews, you make
>> > sure your reviewers know wtf you're trying to do and ultimately why.
>> >
>>
>> The end goal here is to migrate ebuilds to PYTHON_TARGETS. We can't
>> migrate every package in the tree at once, so this check